1.摘要
因特網(wǎng)安全關(guān)聯(lián)和關(guān)密鑰的治理協(xié)議(ISAKMP)為因特網(wǎng)安全關(guān)聯(lián)治理和密鑰建立定義一個框架。這個框架由定義了的交換，有效負載，和在給定解釋域(DOI)以內(nèi)發(fā)生的處理指南組成。這個文件定義因特網(wǎng)ip安全DOI(IPSECDOI),它用具體例子說明IP適合同ISAKMP一起使用,當IP使用ISAKMP商定安全關(guān)聯(lián)。
關(guān)于IPSECDOI的先前版本的變化的列表，請見7節(jié)。
2.介紹
在ISAKMP以內(nèi)，解釋的域被用來通過使用ISAKMP組織有聯(lián)系的協(xié)議來商議安全關(guān)聯(lián)。共享一個DOI的安全協(xié)議選擇安全協(xié)議和從一個普通的，名字空間轉(zhuǎn)變的密碼并且共享關(guān)密鑰的交換協(xié)議標識符。他們也共享DOI特定的有效負載數(shù)據(jù)內(nèi)容的普通解釋,包括安全關(guān)聯(lián)和鑒定有效負載。
總的來說,ISAKMP把下列要求放在一個DOI定義上：
o為DOI特定的協(xié)議標識符定義命名方案
o為狀況域定義解釋
o定義適用的安全策略集合
o為DOI特定的SA屬性的定義句法(階段II）
o為DOI特定的有效負載內(nèi)容定義句法
o定義附加的密鑰交換類型,假如需要
o定義附加的通知消息類型,假如需要
這個文件的剩余部分為使用IP安全(IPSEC)協(xié)議提供認證,完整性，或為IP包的機密在合作主機系統(tǒng)或防火墻之間送的請求,進行了具體實例化。
對于全面的IPSEC體系結(jié)構(gòu)描述，見[ARCH],[AH],和[ESP]。
3.術(shù)語和定義
要害詞必須,不能,要求,將,將不,應(yīng)該,應(yīng)該不,推薦,可能和可選,當他們再文檔中出現(xiàn)時,被解釋成如[RFC2119]所描述的。
4．IPSEC
4.1IPSEC命名方案
在ISAKMP以內(nèi)，所有的Doi的必須在“分配的數(shù)字”RFC[STD-2]內(nèi)同IANA一起被登記。IANA為因特網(wǎng)IP安全DOI(IPSECDOI)分配的數(shù)字是一個(1)。在IPSECDOI以內(nèi)，所有聞名的標識符必須在IPSECDOI下面與IANA一起被登記。除非另外注明,在這個文件以內(nèi)的所有表參考為IPSECDOI而被分配數(shù)字的IANA。對于IPSECDOI聯(lián)系到IANA注冊表的進一步的信息,見節(jié)6。
所有的多字節(jié)二進制代碼值在網(wǎng)絡(luò)字節(jié)順序被存儲。
4.2IPSEC狀況定義
在ISAKMP以內(nèi)，狀況提供能被響應(yīng)者用來作出一條關(guān)于怎么處理到來的安全關(guān)聯(lián)信息請求策略的決定。對于IPSECDOI，狀況域是一個有下列值的4字節(jié)位掩碼。
狀況 值
--------------
SIT_IDENTITY_ONLY 0x01
SIT_SECRECY 0x02
SIT_INTEGRITY 0x04
4.2.1SIT_IDENTITY_ONLY
SIT_IDENTITY_ONLY類型指定,安全關(guān)聯(lián)將被在聯(lián)系的鑒定有效負載中提供的源身份信息所標記。對于各種各樣的鑒定的完全描述見節(jié)4.6.2。所有的IPSECDOI實現(xiàn)必須支持SIT_IDENTITY_ONLY,由在至少一次階段IOakley交換中包含鑒定有效負載([IKE],節(jié)5),并且必須放棄任何不包括鑒定的安裝有效負載關(guān)聯(lián)。
假如一個開始者既不支持SIT_SECRECY也不支持SIT_INTEGRITY，狀況僅僅由4字節(jié)狀況位圖組成并且不包括標記的域標識符域(圖1,節(jié)4.6.1)或任何隨后的標簽信息。相反的,假如開始者支持SIT_SECRECY或SIT_INTEGRITY，標記的域標識符必須在狀況有效負載時被包括。
4.2.2SIT_SECRECY
SIT_SECRECY類型指定安全關(guān)聯(lián)在要求標記秘密的環(huán)境中正被商議。假如SIT_SECRECY在狀況位圖中出現(xiàn)，狀況域?qū)⒈蛔兞块L度數(shù)據(jù)跟隨,他們包括敏感級別和分隔空間位掩碼。關(guān)于安全關(guān)聯(lián)有效負載格式的完全的描述,見節(jié)4.6.1。
假如一個開始者不支持SIT_SECRECY，SIT_SECRECY狀況位圖不能被設(shè)置并且秘密級別或范疇位圖將被包括。
假如一個應(yīng)答者不支持SIT_SECRECY，環(huán)境不支持的標志信息有效負載應(yīng)該被返回并且安全關(guān)聯(lián)安裝必須被放棄。
4.2.3SIT_INTEGRITY
SIT_INTEGRITY類型指定安全關(guān)聯(lián)在要求標記完整性的環(huán)境中正被商議。假如SIT_INTEGRITY在狀況位圖中出現(xiàn)，狀況域?qū)⒈蛔兞块L度數(shù)據(jù)跟隨,他們包括完整級別和分隔空間位掩碼。假如SIT_SECRECY也用于關(guān)聯(lián),完整信息立即遵從變長秘密級別和類別。關(guān)于安全關(guān)聯(lián)有效負載格式的完全的描述,見節(jié)4.6.1。
假如一個開始者不支持SIT_INTEGRITY，SIT_INTEGRITY狀況位圖不能被設(shè)置并且無完整性級別或范疇位圖將被包括。
假如一個應(yīng)答者不支持SIT_INTEGRITY，環(huán)境不支持的標志信息有效負載應(yīng)該被返回并且安全關(guān)聯(lián)安裝必須被放棄。
4.3IPSEC安全策略要求
IPSECDOI不在任何實現(xiàn)上強加特定的安全策略要求。主機系統(tǒng)策略問題將在這個文件的范圍以外。
然而,當設(shè)計一個IPSECDOI主機實現(xiàn)時，在下面的章節(jié)涉及的一些問題必須被考慮。這節(jié)自然應(yīng)該被認為僅僅參考。
4.3.1密鑰治理問題
選擇來實現(xiàn)ISAKMP的許多系統(tǒng)將努力為一個聯(lián)合的IKE密鑰治理新進程提供執(zhí)行的保護域，這被期望。在保護模式多用戶操作系統(tǒng)上，這個密鑰治理進程將多半作為分開的特權(quán)進程存在。
在這個環(huán)境中，介紹密鑰材料到TCP/IP核的形式化的API可以是合乎需要的。IP安全體系結(jié)構(gòu)不放任何結(jié)構(gòu)要求,或在一個主機TCP/IP核和它的密鑰治理供給商之間流動。
4.3.2靜態(tài)的密鑰問題
實現(xiàn)靜態(tài)密鑰的主機系統(tǒng),或由IPSEC直接使用，或為認證目的(見[IKE]節(jié)5.4)，當它不在保護的內(nèi)存域或由TCP/IP核使用時,應(yīng)該采取步驟保護靜態(tài)的密鑰材料。
例如,在一臺膝上計算機上，一個人可能選擇在一家配置存儲器存儲靜態(tài)的密鑰,自己,在一個私人的口令下面加密了。
依靠操作系統(tǒng)和安裝的實用程序軟件,一旦靜態(tài)的密鑰裝載進TCP/IP核，他們被保護是不可能的，然而他們不能在沒有滿足一些附加形式的認證下而在起始的系統(tǒng)開始輕易重獲
4.3.3主機策略問題
假設(shè)IPSEC的轉(zhuǎn)變在一夜間發(fā)生，是不現(xiàn)實的。主機系統(tǒng)必須預(yù)備實現(xiàn)靈活的策略表,策略表描述哪個系統(tǒng)他們需要安全地通話和他們要求通話安全的系統(tǒng)。一些觀點認為代理防火墻地址可以被要求。
一條最小的途徑可能是IP地址，網(wǎng)絡(luò)掩碼，和安全要求標志或標志的一張靜態(tài)表。
一個更靈活的實現(xiàn)可能由一列通配符DNS的命名(例如"*.foo.bar'),一個在里/外位掩碼，和一個可選的防火墻地址組成。通配符DNS名字將被用來匹配到來或出去的IP地址,里/外位掩碼將被用來決定安全是否將被使用,和哪個方向，并且可選的防火墻地址將被用來顯示通道模式是否需要通過中間防火墻與目標系統(tǒng)談話。
4.3.4證書治理
實現(xiàn)一個基于證書的認證計劃的主機系統(tǒng)將需要一個機制來獲得和治理證書數(shù)據(jù)庫。
安全的DNS是是一個證書分發(fā)機制,然而安全的DNS地區(qū)的普遍應(yīng)用,在短術(shù)語中，有許多值得懷疑的原因。更可能的是，主機將
需要進口他們通過的安全,out-of-band機制獲得證書的權(quán)能,和出口自己的證書給另外的系統(tǒng)使用。
然而,手工證書治理不能被執(zhí)行以便防止介紹動態(tài)的證書發(fā)現(xiàn)機制或協(xié)議的權(quán)能成為可行的。
4.4IPSEC分配數(shù)
下列節(jié)為IPSECDOI列出分配的數(shù)字：狀況標識符,協(xié)議標識符,轉(zhuǎn)變標識符，AH，ESP，并且IPCOMP轉(zhuǎn)變標識符,安全協(xié)會屬性類型值,標記的域標識符，ID有效負載類型值，和通知消息類型值。
4.4.1IPSEC安全協(xié)議標識符
ISAKMP建議句法被特定的設(shè)計來答應(yīng)多重的階段II安全協(xié)議的同時協(xié)商在一個單個的協(xié)商內(nèi)適用。作為結(jié)果，下面被列出了的協(xié)議組形成了能同時被協(xié)商的協(xié)議集合。它是決定什么協(xié)議能被協(xié)商在一起的一個主機策略決定。
下列表為IPSECDOI而在ISAKMP建議有效負載中引用的安全協(xié)議標識符列出值的。
協(xié)議ID 值
----------- -----
保留 0
PROTO_ISAKMP 1
PROTO_IPSEC_AH 2
PROTO_IPSEC_ESP 3
PROTO_IPCOMP 4
4.4.1.1PROTO_ISAKMP
PROTO_ISAKMP類型指定在階段I的ISAKMP協(xié)議期間要求的消息保護。在IPSECDOI中被使用的特定的保護機制在[IKE]中被描述。在IPSECDOI以內(nèi)的所有的實現(xiàn)必須支持PROTO_ISAKMP。
NB：ISAKMP保留該值一(1),越過所有的DOI定義。
4.4.1.2PROTO_IPSEC_AH
PROTO_IPSEC_AH類型指定IP包認證。缺省AH轉(zhuǎn)變提供數(shù)據(jù)起源認證,完整保護,和重放探測。對于出口控制考慮，機密不能被任何PROTO_IPSEC_AH轉(zhuǎn)變所提供。
4.4.1.3PROTO_IPSEC_ESP
PROTO_IPSEC_ESP類型指定IP包機密。假如要求認證，必須作為ESP的部分被提供轉(zhuǎn)變。缺省ESP轉(zhuǎn)變包括數(shù)據(jù)起源認證,完整保護,重放探測,和機密性。
4.4.1.4PROTO_IPCOMP
如在[IPCOMP]里面定義的,PROTO_IPCOMP類型指定IP有效負載壓縮。
4.4.2IPSECISAKMP轉(zhuǎn)變標識符
作為一個ISAKMP階段I協(xié)商的部分,開始者的密鑰的交換提供的選擇被用來作一些主機系統(tǒng)策略描述。實際的密鑰交換機制選擇被用來做標準的ISAKMP建議有效負載。下列表格列出對于IPSECDOI的為建議有效負載定義的ISAKMP階段I轉(zhuǎn)變標識符。
轉(zhuǎn)變 值
--------- -----
保留 0
KEY_IKE 1
在ISAKMP和IPSECDOI框架內(nèi)除IKE(Oakley)以外定義密鑰的建立協(xié)議，是可能的。這個文件的先前版本定義了基于一個通用密鑰的分發(fā)中心(KDC)的使用的手工密鑰和計劃。這些標識符從當前的文件被移走了。
IPSECDOI還能在以后被擴大到為附加的non-Oakley密鑰建立協(xié)議包括關(guān)于ISAKMP和IPSEC的值,例如Kerberos[RFC-1510]或組密鑰治理協(xié)議(GKMP)[RFC-2093]。
4.4.2.1KEY_IKE
KEY_IKE類型指定混合的ISAKMP/OakleyDiffie-Hellman密鑰的交換(IKE),如在[IKE]文件定義。在IPSECDOI以內(nèi)的所有的實現(xiàn)必須支持KEY_IKE。
4.4.3IPSECAH轉(zhuǎn)變標識符
認證頭協(xié)議(AH)定義一個強制的和若干可選的轉(zhuǎn)變用于提供認證,完整性,和重放探測。下列表列出定義的AH轉(zhuǎn)變標識符為IPSECDOI的ISAKMP建議有效負載。
注重：認證算法屬性必須被指定認明適當?shù)腍保護組。例如,AH_md5最好能被想作使用MD5的通用AH轉(zhuǎn)變。為了AH請求HMAC構(gòu)造,一個人指定AH_MD5轉(zhuǎn)變ID,伴隨著認證算法屬性設(shè)置到HMAC-MD5。這被顯示使用"Auth(HMAC-MD5)"標志在下列節(jié)。
轉(zhuǎn)變ID 值
----------- -----
保留 0-1
AH_MD5 2
AH_SHA 3
AH_DES 4
注重：所有的mandatory-to-implement算法被列出作為必須實現(xiàn)(例如AH_MD5)在下列節(jié)。所有另外的算法是可選的并且可能在任何非凡的應(yīng)用中被實現(xiàn)。
4.4.3.1AH_MD5
AH_MD5類型指定使用MD5的通用AH轉(zhuǎn)變。實際的保護組被決定與SA聯(lián)系表一致。通用的MD5轉(zhuǎn)變當前未定義。
在IPSECDOI內(nèi)的所有的實現(xiàn)必須與Auth一起支持AH_MD5(HMAC-MD5)屬性。這組被定義為HMAC-MD5-96轉(zhuǎn)變,如在[HMACMD5]中描述的。
與Auth一起的AH_MD5類型(KPDK)屬性指定了AH轉(zhuǎn)變(密鑰/墊/數(shù)據(jù)/密鑰)描述在RFC-1826。
有任何另外的認證算法的AH_MD5的使用屬性值當前未定義。
4.4.3.2AH_SHA
AH_SHA類型指定使用SHA-1的通用AH轉(zhuǎn)變。實際的保護組決定為與聯(lián)系的SA屬性表一致。通用的SHA轉(zhuǎn)變當前未定義。
在IPSECDOI以內(nèi)的所有的實現(xiàn)必須與Auth一起支持AH_SHA(HMAC-SHA)屬性。這組被定義為描述在[HMACSHA]中的HMAC-SHA-1-96轉(zhuǎn)變。
與任何另外的認證算法屬性值一起使用的AH_SHA當前未定義。
4.4.3.3AH_DES
AH_DES類型指定使用DES的通用AH轉(zhuǎn)變。實際的保護組決定為與聯(lián)系的SA屬性表一致。通用的DES轉(zhuǎn)變當前未定義。
IPSECDOI定義AH_DES和Auth(DES-MAC)屬性為DES-MAC轉(zhuǎn)變。實現(xiàn)不需要支持這種模式.
與任何另外的認證算法屬性值一起使用的AH_DES當前未定義。
4.4.4IPSECESP轉(zhuǎn)變標識符
包含的安全有效負載(ESP)定義一個強制的和用于常提供數(shù)據(jù)機密可選的許多轉(zhuǎn)變。下列表格列出定義的對于IPSECDOI為ISAKMP建議有效負載的ESP轉(zhuǎn)變標識符。
注重：什么時候認證,完整保護,和重放探測被要求,認證算法屬性必須被指定來認明適當?shù)腅SP保護組。例如,請求有3DES的HMAC-MD5認證，一個人指定ESP_3DES屬性轉(zhuǎn)變ID并且設(shè)置把認證算法屬性設(shè)置為HMAC-MD5。對于附加處理的要求，見節(jié)4.5（認證算法）。
轉(zhuǎn)變ID 值
------------ -----
保留 0
ESP_DES_IV64 1
ESP_DES 2
ESP_3DES 3
ESP_RC5 4
ESP_IDEA 5
ESP_CAST 6
ESP_BLOWFISH 7
ESP_3IDEA 8
ESP_DES_IV32 9
ESP_RC4 10
ESP_NULL 11
注重：在下列節(jié)中所有的mandatory-to-implement算法被列出作為必須實現(xiàn)(例如ESP_DES)。所有另外的算法是可選的并且可能在任何非凡的應(yīng)用中被實現(xiàn)。
4.4.4.1ESP_DES_IV64
ESP_DES_IV64類型指定定義在RFC-1827和使用一個64比特IV中的RFC-1829DES-CBC轉(zhuǎn)變
4.4.4.2ESP_DES
ESP_DES類型指定使用DES-CBC的一個通用的DES轉(zhuǎn)變。實際的保護組定義得與SA屬性表一致。一個通用轉(zhuǎn)變當前未定義。
在IPSECDOI內(nèi)的所有實現(xiàn)必須與Auth(HMAC-MD5)一起支持ESP_DES屬性。這組被定義為[DES]轉(zhuǎn)變,由HMACMD5[HMACMD5]提供認證和完整性了。
4.4.4.3ESP_3DES
ESP_3DES類型指定一個通用的triple-DES轉(zhuǎn)變。實際的保護組定義得與SA屬性表一致。通用轉(zhuǎn)變當前未定義。
在IPSECDOI內(nèi)的所有的實現(xiàn)強烈支持ESP_3DES和Auth(HMAC-MD5)屬性。這組被定義為[ESPCBC]轉(zhuǎn)變,由HMACMD5[HMACMD5]提供認證和完整性。
4.4.4.4ESP_RC5
ESP_RC5類型指定定義在[ESPCBC]RC5的轉(zhuǎn)變。
4.4.4.5ESP_IDEA
ESP_IDEA類型指定定義在[ESPCBC]的IDEA轉(zhuǎn)變。
4.4.4.6ESP_CAST
ESP_CAST類型指定定義在[ESPCBC]的CAST轉(zhuǎn)變。
4.4.4.7ESP_BLOWFISH
ESP_BLOWFISH類型指定定義在[ESPCBC]的BLOWFISH轉(zhuǎn)變。
4.4.4.8ESP_3IDEA
ESP_3IDEA類型為triple-IDEA保留。
4.4.4.9ESP_DES_IV32
ESP_DES_IV32類型指定定義在RFC-1827和使用一32位的IV的RFC-1829的DES-CBC轉(zhuǎn)變。
4.4.4.10ESP_RC4
ESP_RC4類型為RC4保留。
4.4.4.11ESP_NULL
ESP_NULL類型沒有指定任何機密被ESP提供。當ESP被用于僅僅要求認證,完整性,和重放探測的通道包時，ESP_NULL被使用。
在IPSECDOI內(nèi)的所有實現(xiàn)必須支持ESP_NULL。ESPNULL轉(zhuǎn)變在[ESPNULL]中被定義。為得到關(guān)聯(lián)ESP_NULL使用的附加要求,見節(jié)4.5認證算法屬性描述。
4.4.5IPSECIPCOMP轉(zhuǎn)變標識符
IP壓縮(IPCOMP)轉(zhuǎn)變定義了能被協(xié)商為IP有效負載壓縮([IPCOMP])所提供的可選壓縮算法。下列表列出已定義的IPCOMP內(nèi),為ISAKMP建議有效負載轉(zhuǎn)變標識符
IPSECDOI
轉(zhuǎn)變ID 值
------------ -----
保留 0
IPCOMP_OUI 1
IPCOMP_DEFLATE 2
IPCOMP_LZS 3
4.4.5.1IPCOMP_OUI
IPCOMP_OUI類型指定專利的壓縮轉(zhuǎn)變。IPCOMP_OUI類型必須由進一步認明特定供給商算法的屬性伴隨。
4.4.5.2IPCOMP_DEFLATE
IPCOMP_DEFLATE類型指定“zlib”縮小算法的使用如在[降低]中指定。
4.4.5.3IPCOMP_LZS
IPCOMP_LZS類型指定Stac電子學LZS算法的使用如在[LZS]中指定的。
4.5IPSEC安全關(guān)聯(lián)屬性
下列SA屬性定義被使用在一個IKE協(xié)商的相II。屬性類型可以是基本(B)或可變的長度(V)。這些屬性編碼被定義在基層的ISAKMP說明中。
描述為基本的屬性不能被編碼為變量。假如他們的值適合在兩個字節(jié)中，可變的長度屬性可以被編碼為基本屬性。屬性上關(guān)于IPSECDOI的進一步信息編碼見[IKE]。列出在[IKE]的所有限制也適用于IPSECDOI。
屬性類型
類 值 類型
-------------------------------------------------
SA生命類型 1 B
SA生命持續(xù)時間 2 V
組描述 3 B
封裝模式 4 B
認證算法 5 B
密鑰長度 6 B
密鑰Rounds 7 B
壓縮字典大小 8 B
壓縮私人的算法 9 V
類值
SA生命類型
SA持續(xù)時間
為了全面安全關(guān)聯(lián)而指定生命時間。當SA到期時，在關(guān)聯(lián)下面協(xié)商所有的密鑰(AH或ESP)必須重新協(xié)商。生命類型值是：
保留 0
第二 1
K字節(jié) 2
值3-61439被保留到IANA中。值61440-65535為私有使用。對于一種給定的生命類型，生命持續(xù)時間屬性的值定義了部件一生的實際長度--或很多秒，或能被保護的很多Kbytes。
假如未非凡指出，缺省值將被假定為28800秒(8小時)。
SA生命持續(xù)時間屬性必須總是遵從描述持續(xù)時間單位的SA生命類型。
對于一生通知聯(lián)系的附加信息見節(jié)4.5.4。
組描述
指定在一個PFSQM協(xié)商被使用的Oakley組。關(guān)于支持值的列表，見附錄一的[IKE]。
封裝模式
保留 0
隧道 1
運輸 2
值3-61439被保留到IANA。值61440-65535為私人使用。
假如未非凡指出，缺省值將被假定為未非凡指出(主機依靠)。
認證算法
保留 0
HMAC-MD5 1
HMAC-SHA 2
DES-MAC 3
KPDK 4
值5-61439被保留到IANA。值61440-65535為私人使用。
當它必須被指定來正確的認明適用的AH或ESP轉(zhuǎn)變時,Auth算法沒有缺省值,除了在下列情況中。
當協(xié)商的ESP時，Auth算法屬性不能被包括在建議中。
當協(xié)商沒有機密的ESP時，Auth算法屬性必須被包括在建議中并且ESP轉(zhuǎn)變的ID必須是ESP_NULL。
密鑰的長度
保留 0
密鑰長度沒有缺省值,如它必須為使用可變密鑰長度的密碼轉(zhuǎn)變而被指定。對于固定長度的密碼，密鑰長度屬性不能被傳送。
密鑰的Rounds
保留 0
密鑰的Rounds沒有缺省值,如它必須為使用rounds變化數(shù)字密碼的轉(zhuǎn)變被指定。
壓縮字典大小
保留 0
指定log2為字典大小的最大值。
字典大小沒有缺省值。
壓縮私人算法
指定私人供給商壓縮算法。首先的3(3)字節(jié)必須是被分配了的company_id的一個IEEE(OUI)。下一個字節(jié)可以是供給商特定的壓縮子類型,跟隨著供給商零或更多字節(jié)的數(shù)據(jù)。
4.5.1要求的屬性支持
保證基本的互操作性,所有的實現(xiàn)必須預(yù)備協(xié)商下列所有屬性。
SA生命類型
SA持續(xù)時間
Auth算法
4.5.2分析要求的屬性(一生)
答應(yīng)靈活的語義,IPSECDOI要求一個遵守ISAKMP的實現(xiàn)必須正確分析包含相同屬性類多重例子的屬性表，只要不同的屬性入口不與對方?jīng)_突。當前,要求處理的唯一屬性是生命類型和持續(xù)時間。
為了知道這為什么重要,下列例子顯示一個二進制4入口編碼指定100MB或24小時的SA一生的屬性表。（見節(jié)3.3[ISAKMP]為屬性的完全描述編碼格式。）
屬性#1：
0x80010001（AF=1,類型=SA生命類型,值=秒）
屬性#2：
0x00020004(AF=0,類型=SA持續(xù)時間,長度=4個字節(jié))0x00015180值=0x15180=86400秒=24小時)
屬性#3：
0x80010002（AF=1,類型=SA生命類型,值=KB）
屬性#4：
0x00020004(AF=0,類型=SA持續(xù)時間,長度=4個字節(jié))0x000186A0(值=0x186A0=100000KB=100MB)
假如沖突屬性被檢測到,ATTRIBUTES-NOT-SUPPORTED通知有效負載應(yīng)該被返回并且安全關(guān)聯(lián)安裝必須被放棄。
4.5.3屬性協(xié)商
假如實現(xiàn)收到一個它不支持的定義了的IPSECDOI屬性(或?qū)傩灾?,一個ATTRIBUTES-NOT-SUPPORT應(yīng)該被發(fā)送并且安全關(guān)聯(lián)安裝必須被放棄的，除非屬性值在保留的范圍內(nèi)。
假如實現(xiàn)在保留范圍收到屬性值，實現(xiàn)可能選擇繼續(xù)基于本地的策略。
4.5.4一生通知
當一個開始者提供比應(yīng)答者基于他們的本地的策略所需的大的SA一生時，應(yīng)答者有3種選擇：1)協(xié)商全部失敗;2)完成協(xié)商但是使用比被提供的更短的一生;3)完成協(xié)商并且送一份建議通知到顯示應(yīng)答者真實一生的開始者。應(yīng)答者實際上做的選擇是實現(xiàn)特定的或基于本地的策略。
在后者情況中保證互操作性,當應(yīng)答者希望通知開始者時，IPSECDOI僅僅要求下列：假如開始者提供的SA一生與應(yīng)答者愿意接受的長，應(yīng)答者應(yīng)該在包括應(yīng)答者IPSECSA有效負載的交換包括ISAKMP通知的有效負載。節(jié)4.6.3.1為必須被用于這個目的消息類型的RESPONDER-LIFETIME通知定義有效負載布局。
4.6IPSEC有效負載內(nèi)容
下列節(jié)描述其數(shù)據(jù)表示依靠于適用的DOI的那些ISAKMP有效負載。
4.6.1安全關(guān)聯(lián)有效負載
下列圖表為IPSECDOI說明安全關(guān)聯(lián)有效負載的內(nèi)容。對于狀況位圖的描述見節(jié)4.2。
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！下一個有效負載！保留！有效負載長度！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！解釋的域(IPSEC）
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！狀況(位圖）！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！標記的域標識符！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！秘密長度(在字節(jié)）！保留！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~秘密級別
~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！秘密連接。長度(在位中)！保留！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~秘密范疇位圖~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！完整長度(在字節(jié)）！保留！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~完整級別
~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！Integ。連接。長度(按位）！保留！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~完整范疇位圖~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
圖1：安全關(guān)聯(lián)有效負載格式
安全關(guān)聯(lián)有效負載被定義如下：
o下一個有效負載(1字節(jié))在消息中的下一個有效負載的有效負載類型標識符。假如當前的有效負載是在消息的最后，這域?qū)⑹橇?0)。
o保留(1字節(jié))-閑置,必須是零(0)。
o有效負載長度(2字節(jié))-長度,字節(jié)，當前的有效負載，包括通用的頭。
o解釋的域(4字節(jié))-指定IPSECDOI,它被分配了值一(1)。
o狀況(4字節(jié))-位掩碼過去常解釋安全關(guān)聯(lián)有效負載的剩余部分。關(guān)于值的完全表見節(jié)4.2。
o標記過的域標識符(4字節(jié))-被分配了數(shù)字的IANA被用來解釋秘密和完整性信息。
o密文長度(2個字節(jié))-在字節(jié)上,指定秘密級別標識符長度，排除墊位。
o保留(2個字節(jié))-閑置,必須是零(0)。
o秘密級別(可變長度)-指定要求的強制秘密級別。秘密級別必須填(0)來在下一條32位邊界上排列。
o秘密類別長度(2個字節(jié))-指定長度,按位，秘密類別(分隔空間)位圖,排除墊位。
o保留(2個字節(jié))-閑置,必須是零(0)。
o秘密類別位圖(可變長度)-一個位圖被用來指明被要求的秘密類別(分隔空間)。位圖必須填(0),在下一條32位邊界上排列。
o完整長度(2個字節(jié))-指定長度,按字節(jié)，完整級別標識符，排除墊位。
o保留(2個字節(jié))-閑置,必須是零(0)。
o完整級別(可變長度)-指定要求的強制完整級別。完整級別必須填(0)在下一條32位的邊界上排列。
o完整類別長度(2個字節(jié))-指定長度,按位，完整類別(分隔空間)位圖,排除墊位。
o保留(2字節(jié))-閑置,必須是零(0)。
o完整類別位圖(可變長度)-一個位圖被用來指明被要求的完整類別(分隔空間)。位圖必須填(0),在下一條32位的邊界上排列。
4.6.1.1IPSEC標記了的域標識符
下列表列出標記域標識符域的分配的值,它被包含在關(guān)聯(lián)有效負載的安全狀況域中。
域 值
------ -----
保留 0
4.6.2鑒定有效負載內(nèi)容
鑒定有效負載被用來認明安全關(guān)聯(lián)的開始者。開始者的身份應(yīng)該被應(yīng)答者使用來決定關(guān)聯(lián)要求的正確主機系統(tǒng)安全策略。例如,一臺主機可能選擇沒有要求從某個集合IP地址機密認證和完整性,和另一范圍IP地址地完全機密性認證。鑒定有效負載提供能被應(yīng)答者用來作出決定的信息。
在階段期I協(xié)商期間，ID端口和協(xié)議域必須被設(shè)置為零或上到500的UDP。假如實現(xiàn)收到任何另外的值，這必須被當作一個錯誤并且安安全關(guān)聯(lián)裝必須被放棄。這個事件應(yīng)該是auditable。
下列圖表說明鑒定有效負載的內(nèi)容。
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！下一個有效負載！保留！有效負載長度！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！ID類型！協(xié)議ID！端口！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~鑒定數(shù)據(jù)~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
圖2：鑒定有效負載格式
鑒定有效負載域被定義如下：
o下一個有效負載(1字節(jié))-在消息中關(guān)于下一個有效負載的有效負載類型標識符。假如當前的有效負載是消息的最后一個，這域?qū)⑹橇?0)。
o保留(1字節(jié))-閑置,必須是零(0)。
o有效負載長度(2字節(jié))-長度,按字節(jié)，鑒定數(shù)據(jù)，包括通用頭。
o鑒定類型(1字節(jié))-描述在鑒定數(shù)據(jù)域發(fā)現(xiàn)的身份信息值。
o協(xié)議ID(1字節(jié))-指定一個聯(lián)系的IP值協(xié)議ID(例如UDP/TCP)。零值意味著協(xié)議ID域應(yīng)該被忽略。
o端口(2字節(jié))-指定一個聯(lián)系的端口值。零值意味著協(xié)議ID域應(yīng)該被忽略。
o鑒定數(shù)據(jù)(可變長度)-值,如由鑒定類型顯示的。
4.6.2.1鑒定類型值
下列表格列出了鑒定有效負載中為鑒定類型域分配的值。
ID類型 值
------- -----
保留 0
ID_IPV4_ADDR 1
ID_FQDN 2
ID_USER_FQDN 3
ID_IPV4_ADDR_SUBNET 4
ID_IPV6_ADDR 5
ID_IPV6_ADDR_SUBNET 6
ID_IPV4_ADDR_RANGE 7
ID_IPV6_ADDR_RANGE 8
ID_DER_ASN1_DN 9
ID_DER_ASN1_GN 10
ID_KEY_ID 11
對于ID實體是可變長度的類型，ID實體的大小在ID有效負載頭中以大小被計算。
當IKE交換被證實使用證書時(任何格式),任何被用來輸入到本地策略決定的Id必須被包含在交換用來認證的證書中。
4.6.2.2ID_IPV4_ADDR
ID_IPV4_ADDR類型指定單個4(4)字節(jié)的IPv4地址。
4.6.2.3ID_FQDN
ID_FQDN類型指定一個完全合格的域名字符串。一個ID_FQDN例子是，“foo.bar.com”。字符串不能包含任何終止符。
4.6.2.4ID_USER_FQDN
這個ID_USER_FQDN類型指定一個有很高權(quán)限的用戶名字符串，ID_USER_FQDN的一個例子是"piper@foo.bar.com".這個字符串不應(yīng)該包含任何界限。
4.6.2.5ID_IPV4_ADDR_SUBNET
這個ID_IPV4_ADDR_SUBNET類型具體說明IPV4地址的排列，它表現(xiàn)為兩個四位的八位位組值。第一個值是IPV4的地址。第二個值是IPV4的網(wǎng)絡(luò)面具。非凡注重這個網(wǎng)絡(luò)面具中的ones(1s)指示的相應(yīng)的位被固定，而zeros(0s)指示一個通配符位。
4.6.2.6ID_IPV6_ADDR
這個ID_IPV6_ADDR類型指定一個單一的16位八位位組Ipv6地址。
4.6.2.7ID_IPV6_ADDR_SUBNET
這個ID_IPV6_ADDR_SUBNET類型具體說明Ipv6地址的排列，它被描繪為兩個16位的八位位組的值。第一個值是一個Ipv6的地址。第二個值是Ipv6的網(wǎng)絡(luò)面具。非凡注重網(wǎng)絡(luò)面具中的ones（1s）指示地址中的相應(yīng)位被固定，而zeros(0s)指示一個通配符位。
4.6.2.8ID_IPV4_ADDR_RANGE
這個ID_IPV4_ADDR_RANGE類型具體說明一個IPV4地址的排列，它表現(xiàn)為兩個四位的八位位組值。第一個值開始于Ipv4地址，第二值結(jié)束于IPV4的地址。在兩個指定地址中的所有地址被認為在這個列表之中。
4.6.2.9ID_IPV6_ADDR_RANGE
這個ID_IPV6_ADDR_RANGE類型具體說明Ipv6地址的排列，它表現(xiàn)為兩個16位的八位位組值。第一個值開始于IPV6地地址，第二個值結(jié)束IPV6地址。在兩個指定地址中的所有地址被認為在這個列表之中。
4.6.2.10ID_DER_ASN1_DN
這個ID_DER_ASN1_DN類型具體說明二進制的DER，它是以ASN.1X.500來編碼的，它的證書被交換來建立這個SA.
4.6.2.11ID_DER_ASN1_GN
這個4.6.2.11ID_DER_ASN1_GN類型具體說明二進制的DER，它是以ASN.1X.500來編碼的，它的證書被交換來建立SA。
4.6.2.12ID_KEY_ID
這個ID_KEY_ID類型具體說明不透明的字節(jié)流，它可能被用來通過指定必須的的賣主信息來鑒別哪一個共享的密鑰應(yīng)被用來鑒別侵權(quán)的談判模式。
4.6.3IPSEC通報信息類型
ISAKMP定義兩塊通報信息代碼，一個是錯誤的，另一個是狀態(tài)信息。ISAKMP也分配每塊中的一部分在DOL里作為私有用途。這個IPSECDOI為自己的用途定義下列私有信息。
通報信息-錯誤類型值
----------------------------------
保留的8192

通報信息-狀態(tài)類型值
-----------------------------------
RESPONDER-LIFETIME24576
REPLAY-STATUS24577
INITIAL-CONTACT24578

通知狀態(tài)信息MUST送到ISAKMPSA的保護下：在最后主要交換模式里任何一個作為有效載荷；在主要模式下的分離的信息交換或侵權(quán)的模式過程是完成的；或在任何快的模式交換里作為有效載荷。這些信息不應(yīng)該被送到侵權(quán)的模式交換中，因為侵權(quán)模式不提供必須的保護來約束通報狀態(tài)信息交換。
非凡注重：一個通報的有效載荷僅僅在快的模式下被完全保護，在那兒整個有效載荷被包含在HASH（n）分類中。在主要模式立，當通報信息被加密了，它不是普遍的包含在這個HASH(n)分類歷。結(jié)果，在主模式密文里，一個積極的攻擊能引起通報信息類型被改動。（這是真的，一般的，對于任何主模式交換里的最后的信息）當這個風險很小時，一個跟改過的通報信息可能引起接收者中斷整個談判，他想到發(fā)送者碰到了一個致命的錯誤。
4.6.3.1RESPONDER-LIFETIME
這個RESPONDER-LIFETIME狀態(tài)信息可能被用來協(xié)調(diào)由接受者選擇的IPSECSAlifetime。
當它存在時，通報有效載荷應(yīng)該有下列格式：
。有效載荷長度－發(fā)送有效載荷的長度＋數(shù)據(jù)大小（var）
。DOI-發(fā)送到IPSECDOI(1)
。ID協(xié)議－從選擇的SA發(fā)送到選擇的協(xié)議ID
。SPI大小-發(fā)送16（兩個eight-octetISAKMPcookies)或4（一個IPSECSPI）
。通報信息類型－發(fā)動RESPONDER-LIFETIME(Section4.6.3)
。SPI-發(fā)送兩個ISAKMPcookies或者道發(fā)送者的IPSECSPI
。告示數(shù)據(jù)－包含一個ISAKMP屬性列表,這個列表帶有回答者實際的SAlifetime(s)
執(zhí)行時注重：通知數(shù)據(jù)領(lǐng)域包含一個屬性列表，它說明通知數(shù)據(jù)域有零長度并且通報有效載荷有相連的屬性列表。
4.6.3.2REPLAY-STATUS
這個REPLAY-STATUS狀態(tài)信息可能被用來對接受者的選擇作肯定證實，看他是否實現(xiàn)anti-replay的發(fā)現(xiàn)。
當它出現(xiàn)時，這個通知有效載荷應(yīng)該有下列格式：
o有效載荷長度-設(shè)定有效載荷的長度+數(shù)據(jù)的大小(4）
oDOI-設(shè)定到IPSECDOI(1）
o協(xié)議ID-從選擇的SA選擇了協(xié)議ID集合
oSPI大小-設(shè)定到任何一個16(16)(2個8字節(jié)ISAKMPcookies)或4(4)(一IPSECSPI)
o通知消息類型-到REPLAY-STATUS的集合
oSPI-設(shè)定到2個ISAKMPcookies或到發(fā)送者的入站IPSECSPI
o通知數(shù)據(jù)-4字節(jié)值：
0=不可重放探測
1=啟用重放探測
4.6.3.3INITIAL-CONTACT
當一個方面希望通知其它方這是這是同遙遠系統(tǒng)建立的第一個SA時，INITIAL-CONTACT狀態(tài)消息可以被使用。這條通知消息的接收裝置然后可能選擇刪除任何存在的Sa，它在傳送系統(tǒng)時重新啟動，并且假設(shè)不再為傳送系統(tǒng)的原有Sa存取與他們聯(lián)系的密鑰材料。當使用時，通知數(shù)據(jù)域的內(nèi)容應(yīng)該為空(即有效載荷長度應(yīng)該被設(shè)置為被通知有效載荷的固定長度)。

當前，通知有效載荷必須有下列格式：

o有效載荷長度-設(shè)定有效載荷的長度+數(shù)據(jù)的大小(0）
oDOI-設(shè)定到IPSECDOI(1）
o協(xié)議ID-從選擇的SA選擇了協(xié)議ID集合
oSPI大小-設(shè)定到16(16)(2個8字節(jié)ISAKMPcookies)
o通知消息類型-到INITIAL-CONTACT的集合
oSPI-設(shè)定到2個ISAKMPcookies
o通知數(shù)據(jù)-<不被包括>
4.7IPSEC密鑰交換要求
IPSECDOI不介紹附加的密鑰交換類型。
5．安全考慮
整個備忘錄屬于因特網(wǎng)密鑰交換協(xié)議（IKE）,它以一種安全的并且好鑒定的方式，聯(lián)合ISAKMP([ISAKMP])和[OAKLEY]來提供密鑰材料來源。各種各樣的安全協(xié)議和文件中轉(zhuǎn)換鑒別的非凡討論能在相關(guān)的基礎(chǔ)文件和密碼參考書目中找到。
6．IANA需要考慮的事項
這個文件包含一些需要IANA來維持的“魔法”數(shù)字。這個章節(jié)解釋由IANA來使用的標準，用這個標準在每一個這些列表中分配附加數(shù)字。在前面章節(jié)中沒有明確說明的所有值對IANA來說是保留的。
6.1IPSEC位置定義
這個位置定義是一個32位bitmask，它描繪IPSECSA的建議和商談被實現(xiàn)的環(huán)境。請求分配新位置應(yīng)該由一個RFC來完成，這個RFC由關(guān)聯(lián)位來解釋。
假如這個RFC不在標準軌跡上（也就是說，它是一個報告的或?qū)嶒灥腞FC），它應(yīng)該在RFC被公開和轉(zhuǎn)化標識符被指派之前被明確的回復或被IESG認可。
這個上層的兩位在合作系統(tǒng)中被保留用作私有用途。
6.2IPSEC安全協(xié)議標識符
這個安全協(xié)議標識符適合一個8位值，它標識一個正需要討論的安全協(xié)議。請求分配一個新的安全協(xié)議標識符應(yīng)該由一個RFC來實現(xiàn)，它描敘了這個需要的安全協(xié)議。[AH]和[ESP]是這個安全協(xié)議文件中的例子。
假如這個RFC不在標準軌跡上（也就是說，它是一個報告的或?qū)嶒灥腞FC），它應(yīng)該在這個RFC被公開和這個轉(zhuǎn)化被指岀之前明確的評論和由IESG來認可。
這些值249-255在合作系統(tǒng)中被保留作為私有用途。
6.3IPSECISAKMP轉(zhuǎn)移標志符
這個IPSECISAKMP轉(zhuǎn)移標志符是一個8位的值，它標識一個用來流通的密鑰交換協(xié)議。
請求分配新的ISAKMP轉(zhuǎn)移標志符應(yīng)該由RFC來完成，它描敘這個需要的密鑰交換協(xié)議。[IKE]是一個這種文件中的例子。
假如RFC不在標準軌跡上（也就是說，它是一個報告的或?qū)嶒灥腞FC），它應(yīng)該在RFC被公開和這個轉(zhuǎn)移標識符被分配之前明確的指出和通過IESG來證實。
在合作系統(tǒng)中保留249－255這些值作為私有用途來使用。
6.4IPDECAH轉(zhuǎn)移標識符
這個IPSECAH轉(zhuǎn)移標識符是一個8位值，它鑒別一個特定的算法法則來為AH提供完整保護。請求分配一個新的AH轉(zhuǎn)移標識符應(yīng)該由一個RFC來協(xié)助完成。這個RFC描繪了怎樣在AH框架中用這個運算法則。
假如這個RFC不是在這個標準軌跡上（也就是說,它是一個報告的或?qū)嶒灥腞FC），它應(yīng)該在RFC被公開和這個轉(zhuǎn)移標識符被分配之前被明確的指出和通過IESG來證實。
在合作系統(tǒng)中保留這些值249－255來作為私有用途。
6.5IPSECESP轉(zhuǎn)移標識符
這個IPSECESP轉(zhuǎn)移標識符是一個8位的值，它鑒別一個特定的運算法則用來為ESP提供一個秘密保護。請求分配一個新的ESP轉(zhuǎn)移標識符應(yīng)該由RFC來協(xié)作完成。這個RFC描敘了在ESP框架中怎樣用這個算法.
假如這個RFC不在這個標準軌跡上（也就是說，它不是一個報告的或?qū)嶒灥腞FC），它應(yīng)該在RFC被公開和這個轉(zhuǎn)移標識符被分配之前被明確的指出和通過IESG來證實。
在合作系統(tǒng)中保留這些值249－255來作為私有用途。
6.6IPSECIPCOMP轉(zhuǎn)移標識符
這個IPSECIPCOMP轉(zhuǎn)移標識符是一個8位的值，在ESP之前它標識一個特定的運算法則用來提供IP層壓縮。請求分配一個新的IPCOMP轉(zhuǎn)移標識符應(yīng)該由一個RFC來協(xié)作完成，它描敘了在IPCOMP框架（[IPCOMP]）中怎樣使用運算法則。另外，這個需要的運算法則應(yīng)該被公開，并且在公共范圍內(nèi)。
假如這個RFC不在這個標準軌跡上（也就是說，它是一個報告的或?qū)嶒灥腞FC），它應(yīng)該在RFC被公開和這個轉(zhuǎn)移標識符被分配之前被明確的指出和通過IESG來證實。
因為RFC已被批準出版，這些值1－47就用來保存作運算法則。在合作系統(tǒng)中這些值48－63被保留作為私有用途。這些值64－255被保留作為將來擴展。
6.7IPSEC安全相連屬性
這個IPSEC安全相連屬性由16位類型和其相連的值組成。OPSECSA屬性用來在ISAKMP之間傳遞各種各樣的值。請求分配一個新的OPSECSA屬性應(yīng)該由因特網(wǎng)草案來完成。它描敘了屬性代碼（基礎(chǔ)的/可變長度的）和它的合法值。這個文檔中的第4.5章提供了一個這樣描敘的例子。
在合作系統(tǒng)中這些值32001－32767被保留作為私有用途。
6.8IPSEC標簽范圍標識符
IPSEC標簽范圍標識符是一個32位的值，它鑒別一個namespace，在namespace里秘密層，完整層和各種值都存在。請求分配一個新的OPSEC標簽范圍標識符應(yīng)該得到滿足。不需要合作文件，盡管在適當?shù)臅r候因特網(wǎng)草案可以得到鼓勵。
在合作系統(tǒng)中這些值0x80000000-0xffffffff被保留作為私有用途。
6.9IPSEC標識符類型
這個IPSEC標識符類型是一個8位的值，它被用來作為一個解釋各種長度有效載荷的判別式。請求分配新的OPSEC鑒定類型應(yīng)該由RFC來完成，它描敘了在OPSEC里怎樣使用這個鑒定。
假如RFC不是在標準軌跡上（也就是說，它是一個報告的或?qū)嶒灥腞FC），在RFC被公開和這個轉(zhuǎn)移標識符被分配之前，它應(yīng)該明確的指出和由IESG來證實。
在合作系統(tǒng)中這些值249－255被保留作為私有用途。
6.10OPSEC通報信息類型
OPSEC通報信息類型是一個16位的值。這個值來自ISAKMP為每個DOL保留的值的變化。有一個錯誤信息的變動（8192－16383）和一個不同的狀態(tài)信息的變動（24576－32767）。請求分配新的通報信息類型應(yīng)該由因特網(wǎng)草案來實現(xiàn)，在IPSEC里它描敘了怎樣用這個鑒定類型。
在合作系統(tǒng)中這些值16001－16383和這些值32001－32767被保留作為私有用途。

7．改變Log
7.1從V9中改變
。為[IPCOMP],[DEFLATE],和[LZS]增加明顯的參考書目。
。因為ISAKMP"SPI"，答應(yīng)RESPONDER-LIFETIME和REPLAY-STATUS在IPSECSPI中直接指出。
。附加的填料排除秘密和完整地長度正文。
?？梢韵蚯皡⒖嫉?.5章和第4.4.4章。
。更新文件參考書目。

7.2從V8中改變
。更新IPCOMP標識符變化來更好地反映OPCOMP草案。
。更新IANA考慮的每個Jeff/Ted's暗示的正文。
。除去DES-MACID([DESMAC])的參考書目。
。更正通報章節(jié)中的bug；ISAKMP通報值是16位的。

7.3從V7中變化
。更正IPCOMP(IP有效載荷壓縮)的名字。
。更正[ESPCBC]的參考書目。
。在圖1中附加不可見的秘密層和完整層。
。移出涉及到PF_KEY和ARCFOUR的ID。
。更新基礎(chǔ)的/各種各樣的正文來排列[IKE].
。更新參考文件并且為[ARCH]增加引子指示。
。更新通知需求；移出一些侵權(quán)的參考書目。
。額外的澄清對通報有效載荷的保護。
?；謴蚏ESERVED到ESP轉(zhuǎn)移ID的位置；移出ESP_NULL.
。額外需要ESP_NULL的支持和[ESPNULL]的參考。
。附加的用AH/ESP來澄清AuthAlg。
。附加的約束來反對用沖突的AH/Auth聯(lián)合體。

7.4從V6中改變
下列這些改變是相對于IPSECDOIV6的。
。附加IANA需要考慮的章節(jié)
。移出多數(shù)IANA數(shù)到IANA需要考慮的章節(jié)。
。附加禁止發(fā)送(V)代碼屬性（B）.
。附加禁止為固定的長度的密碼(例如DES)發(fā)送密鑰長度屬性.
。用IKE取代涉及到ISAKMP/Oakley的參考書目。
。從ESP_ARCFOUR到ESP_RC4進行重命名。
。更新安全考慮章節(jié)。
。更新文檔參考書目。

7.5從V5中變化
下列變化與IPSECDOIV5有關(guān)系：
。在通知正文中改變SPI的大小
。改變REPLAY-ENABLED到REPLAY-STATUS
。從第4.5.4章到第4.6.3.1章中移動RESPONDER-LIFETIME有效載荷的定義
。為第4.6.3.3章附加明確的有效載荷規(guī)劃
。附加執(zhí)行記錄到第4.6.3章中的介紹
。假如MD5成立，改變AH_SHA正文到需要的SHA-1
。更新文檔參考書目

7.6從V4中的變化
下列變化與IPSECDOIV4有關(guān)：
。從AH轉(zhuǎn)移ID到鑒定算法標識符中移動具有兼容性的AHKPDK的鑒定方法
。每一個結(jié)構(gòu)附加REPLAY-ENABLED通知信息類型
。每個列表附加INITIAL-CONTACT通知信息類型
。附加內(nèi)容來確信保護通報狀態(tài)信息
。附加屬性解析章節(jié)永久資格
。附加地澄清永久通知是任選的
。移開私有團體描敘列表（現(xiàn)在指向[IKE]）
。用指向RFC-2119的指針來取代這個術(shù)語
。更新HMACMD5和SHA-1ID參考書目
。更新章節(jié)1（抽象的）
。更新章節(jié)4.4（IPSEC分配的數(shù)）
。在第一個階段附加ID端口/協(xié)議值的約束

7.7從V3到V4的變化
下列變化與IPSECDOIV3有關(guān)，這個對IPSEC郵寄優(yōu)于MUNICHIETF的列表來說是很有用的：
。為空和ARCFOUR附加轉(zhuǎn)移標識符
。重新命名HMAC運算法則到AUTH運算法則來進行協(xié)調(diào)DES-MAC和ESP可選的鑒定/完整性
。附加AH和ESPDES-MAC運算法則標識符
。移動DEY_MANUAL和KEY_KDC標識符定義
。附加永久MUST隨從屬性到SA類型和SA屬性定義
。附加永久通知何IPSECDOI信息類型表格
。附加可選的鑒定和機密性約束到MAC運算法則屬性定義
。更正屬性解析例子（習慣的過時的屬性）
。更正多個因特網(wǎng)草案文件參考書目
。對每個ipsec列表討論（18－Mar－97）附加ID_KEY_ID
。為PFSQM([IKE]MUST)移動默認團體描敘

致謝
這個文件部分起源于以下人的工作：DouglasMaughan,MarkSchertler,MarkSchneider,JeffTurner,DanHarkins,和DaveCarrel.MattThomas,RoyPereira,GregCarter,和RanAtkinson在很多種案例和正文中也提出了他們的建議。
參考書目
[AH]Kent,S.,andR.Atkinson,"IPAuthenticationHeader",RFC
2402,November1998.

[ARCH]Kent,S.,andR.Atkinson,"SecurityArchitectureforthe
InternetProtocol",RFC2401,November1998.

[DEFLATE]Pereira,R.,"IPPayloadCompressionUsingDEFLATE",RFC
2394,August1998.

[ESP]Kent,S.,andR.Atkinson,"IPEncapsulatingSecurity
Payload(ESP)",RFC2406,November1998.

[ESPCBC]Pereira,R.,andR.Adams,"TheESPCBC-ModeCipher
Algorithms",RFC2451,November1998.

[ESPNULL]Glenn,R.,andS.Kent,"TheNULLEncryptionAlgorithmand
ItsUseWithIPsec",RFC2410,November1998.

[DES]Madson,C.,andN.Doraswamy,"TheESPDES-CBCCipher
AlgorithmWithEXPlicitIV",RFC2405,November1998.

[HMACMD5]Madson,C.,andR.Glenn,"TheUSEOfHMAC-MD5withinESP
andAH",RFC2403,November1998.

[HMACSHA]Madson,C.,andR.Glenn,"TheUseofHMAC-SHA-1-96within
ESPandAH",RFC2404,November1998.

[IKE]Harkins,D.,andD.Carrel,D.,"TheInternetKeyExchange
(IKE)",RFC2409,November1998.

[IPCOMP]Shacham,A.,Monsour,R.,Pereira,R.,andM.Thomas,"IP
PayloadCompressionProtocol(IPComp)",RFC2393,August
1998.

[ISAKMP]Maughan,D.,Schertler,M.,Schneider,M.,andJ.Turner,
"InternetSecurityAssociationandKeyManagementProtocol
(ISAKMP)",RFC2408,November1998.

[LZS]Friend,R.,andR.Monsour,"IPPayloadCompressionUsing
LZS",RFC2395,August1998.

[OAKLEY]Orman,H.,"TheOAKLEYKeyDeterminationProtocol",RFC
2412,November1998.

[X.501]ISO/IEC9594-2,"InformationTechnology-OpenSystems
Interconnection-TheDirectory:Models",CCITT/ITU
RecommendationX.501,1993.

[X.509]ISO/IEC9594-8,"InformationTechnology-OpenSystems
Interconnection-TheDirectory:Authentication
Framework",CCITT/ITURecommendationX.509,1993.

Author'sAddress

DerrellPiper
NetworkAlchemy
1521.5PacificAve
SantaCruz,California,95060
UnitedStatesofAmerica

Phone:+1408460-3822
EMail:ddp@network-alchemy.com

全部版權(quán)陳述
版權(quán)（C）因特網(wǎng)社會（1998）。版權(quán)所有
這個文章和它的翻譯可能被復制和提供給別人，并且引出一些評論或者解釋它或援助它執(zhí)行可能被預(yù)備，拷貝，出版和分配，不管是整體的還是局部的，沒有任何限制，提供這上面的版權(quán)告示和包含所有拷貝和起源工作的章節(jié)。但是，這個文章它自己本身不能以任何方式修改，例如通過移走版權(quán)告示或因特網(wǎng)團體或別的因特網(wǎng)組織的參考書目，除了發(fā)展因特網(wǎng)標準的需要，在這種情況下，定義在因特網(wǎng)標準過程中的版權(quán)程序應(yīng)該要有，或者需要翻譯成不同于英語的別的語言。
這個受限的許可同意以上的聲明是永久的，并且它將不會被因特網(wǎng)團體或它的繼任者或設(shè)計者廢除。
包含在這兒的這個文件和通知作為一個基礎(chǔ)來提供。
這個因特網(wǎng)團體和這個因特網(wǎng)工程任務(wù)迫使它公布所有的授權(quán)，表達或隱含，包括但是不限制任何授權(quán)，在這兒信息的用途不破壞任何權(quán)利或任何隱含的購買授權(quán)或一個非凡的目的。