S.KentBBNCorpS.KentBBNCorpR.Atkinson@HomeNetworkNovember1998RequestforComments:2406Obsoletes:1827Category:StandardsTrackIP封裝安全有效載荷(ESP)(RFC2406IPEncapsulatingSecurityPayload(ESP))本文檔狀態：ThisdocumentspecifiesanInternetstandardstrackprotocolfortheInternetcommunity,andrequestsdiscussionandsuggestionsforimprovements.Pleaserefertothecurrenteditionofthe"InternetOfficialProtocolStandards"(STD1)forthestandardizationstateandstatusofthisprotocol.Distributionofthismemoisunlimited.版權聲明Copyright(C)TheInternetSociety(1998).AllRightsReserved.目錄列表介紹封裝安全有效載荷分組格式安全參數索引序列號有效載荷數據填充（供加密使用）.填充長度下一個頭驗證數據封裝安全協議處理ESP頭定位算法加密算法驗證算法2344577777101010TOC\o"1-5"\h\z出站分組處理10SA查找11分組加密11序列號產生12完整性校驗值計算12分片133.4.1重組133.4.2SA查找133.4.3序列號確認143.4.4完整性校驗值確認153.4.5分組解密163.4入站分組處理134.審核175.一致性要求18TOC\o"1-5"\h\z6.安全考慮事項187.與RFC1827的不同18致謝19參考書目19Disclaimer作者信息21版權聲明22介紹封裝安全有效載荷頭在IPv4和IPv6中提供一種混合的安全服務。ESP可以單獨應用，與IP驗證頭（AH）結合使用，或者采用嵌套形式，例如，隧道模式的應用（參看"SecurityArchitecturefortheInternetProtocol"［KA97a］，下面使用“安全架構文檔”代替）。安全服務可以在一對通信主機之間，一對通信的安全網關之間，或者一個安全網關和一臺主機之間實現。在各種網絡環境中如何使用ESP和AH的詳細細節，參看安全架構文檔。ESP頭可以插在IP頭之后、上層協議頭之前（傳送模式），或者在封裝的IP頭之前（隧道模式）。下面將詳細介紹這些模式。ESP提供機密性、數據源驗證、無連接的完整性、抗重播服務（一種部分序列完整性的形式）和有限信息流機密性。提供的這組服務由SA建立時選擇的選項和實現的位置來決定，機密性的選擇與所有其他服務相獨立。但是，確保機密性而不保證完整性/驗證（在ESP或者單獨在AH中）可能使信息易受到某種活動的、破壞機密性服務的攻擊（參看［Bel96］）。數據源驗證和無連接的完整性（下面統一稱作“驗證”引用它們）是相互關聯的服務，它們作為一個選項與機密性（可選擇的）結合提供給用戶。只有選擇數據源驗證時才可以選擇抗重播服務，由接收方單獨決定抗重播服務的選擇。（盡管默認要求發送方增加抗重播服務使用的序列號，但只有當接收方檢查序列號，服務才是有效的。）信息流機密性要求選擇隧道模式，如果在安全網關上實現信息流機密性是最有效的，這里信息聚集能夠掩飾真正的源-目的模式。注意盡管機密性和驗證是可選的，但它們中必須至少選擇一個。假定讀者熟悉安全架構文檔中描述的術語和概念。特別是，讀者應該熟悉ESP和AH提供的安全服務的定義，SA定義，ESP可以和驗證（AH）頭結合使用的方式，以及ESP和AH使用的不同密鑰管理選項。（至于最后一項，ESP和AH要求的當前密鑰管理選項是通過IKE進行的手工建立密鑰和自動建立密鑰［HC98］。）關鍵字MUST,MUSTNOT,REQUIRED,SHALL,SHALLNOT,SHOULD,SHOULDNOT,RECOMMENDED,MAY，和OPTIONAL,當它們出現在本文檔時，由RFC2119中的描述解釋它們的含義［Bra97］。封裝安全有效載荷分組格式ESP頭緊緊跟在協議頭（IPv4,IPv6，或者擴展）之后，協議頭的協議字段（IPv4）將是50,或者協議的下一個頭（IPv6，擴展）字段［STD-2］值是50。012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|安全參數索引(SPI)|"Auth.+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Cov-|序列號||erage+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+||有效載荷數據*(可變的)||"|||Conf.++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Cov-||填充（0-255bytes）||erage*+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+||||填充長度|下一個頭|vv+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|驗證數據（可變的）|||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+*如果加密同步數據，例如初始化向量（IV,參看2.3節），包含在有效載荷字段中，通常它本身并不加密，雖然常常把它作為密文的一部分。下面小節定義了頭格式中的字段。“可選項”意味著如果沒有選擇它，該字段被忽略。即它既不被包含在傳送的分組中，也不會在完整性校驗值（ICV，參看2.7）計算中出現。建立SA時決定是否選擇某個選項，因此ESP分組的格式對于給定的SA是確定的，整個SA存活期間也是確定的。相對而言，“強制性”字段總是出現在ESP分組格式中，對所有SA均如此。2.1安全參數索引SPISPI是一個任意的32位值，它與目的IP地址和安全協議（ESP）結合，唯一地標識這個數據報的SA。從1至255的這組SPI值是由InternetAssignedNumbersAuthority（IANA）保留給將來使用的；除了分配的SPI值的使用由RFC指定，否則，一般IANA不會分配保留的SPI值。通常在建立SA時目的系統選擇SPI（詳細內容請參看安全架構文檔）。SPI字段是強制性的。SPI的值為0是保留給本地、特定實現使用的，不允許在線路上發送。例如，密鑰管理實現可以使用SPI的0值表示當IPsec實現要求它的密鑰管理實體建立新SA,但SA仍然沒有建立時，“沒有SA存在”。序列號SequenceNumber這個無符號的、32位字段包含一個單調遞增的計數器值（序列號）。它是強制性的，即使接收方沒有選擇激活一個特定SA的抗重播服務，它也總是存在。序列號字段由接收方處理，即發送方必須總是傳輸這個字段，但接收方不需要對其操作（參看下面“入站分組處理”中序列號確認的討論）。發送方的計數器和接收方的計數器在一個SA建立時被初始化為0。（使用給定SA發送的第一個分組的序列號1；序列號如何產生的細節參看3.3.3節）如果激活抗重播服務（默認地），傳送的序列號必須決不允許循環。因此，在SA上傳送第2的32次方個分組之前，發送方計數器和接收方計數器必須重新置位（通過建立新SA和獲取新密鑰）有效載荷數據PayloadData有效載荷數據是變長字段，它包含下一個頭字段描述的數據。有效載荷數據字段是強制性的，它的長度是字節的整數倍。如果加密有效載荷的算法要求加密同步數據，例如初始化向量（IV），那么這個數據可以明確地裝載在有效載荷字段。任何要求這樣明確的、每分組同步數據的加密算法必須指出同步數據的長度、結構和位置，這是指定ESP中算法如何使用的某個RFC的一部分。如果這種同步數據是隱式的，派生數據的算法必須是RFC的一部分。注意關于確保IV存在時（實際）密文對齊：o對于一些基于IV模式的操作，接收方把IV作為密文的開始，直接把IV傳給算法。這些模式中，（實際）密文是否開始對齊對于接收方并不重要。o某些情況下，接收方從密文中單獨讀入IV。此時，算法規范必須解決（實際）密文對齊如何實現。填充（供加密使用）幾種因素要求或者激活填充字段的使用。o如果采用的加密算法要求明文是某個數量字節的倍數，例如塊密碼（blockcipher）的塊大小，使用填充字段填充明文（包含有效載荷數據、填充長度和下一個頭字段，以及填充）以達到算法要求的長度。o不管加密算法要求如何，也可以要求填充字段來確保結果密文以4字節邊界終止。特別是，填充長度字段和下一個頭字段必須在4字節字內右對齊，如上圖所示的ESP分組格式，從而確保驗證數據字段（如果存在）以4字節邊界對齊。o除了算法要求或者上面提及的對齊原因之外，填充字段可以用于隱藏有效載荷實際長度，支持（部分）信息流機密性。但是，包含這種額外的填充字段占據一定的帶寬，因而小心使用。發送方可以增加0至255個字節的填充。ESP分組的填充字段是可選的，但是所有實現必須支持填充字段的產生和消耗。為了確保加密位是算法塊大小（上面第一個加重號）的倍數，填充計算應用于除IV之外的有效載荷數據、填充長度和下一個頭字段。為了確保驗證數據以4字節邊界對齊（上面第二個加重號），填充計算應用于包含IV的有效載荷數據、填充長度和下一個頭字段。如果需要填充字節，但是加密算法沒有指定填充內容，則必須采用下列默認處理。填充字節使用一系列（無符號、1字節）整數值初始化。附加在明文之后的第一個填充字節為1，后面的填充字節按單調遞增：1,2,3,…。當采用這種填充方案時，接收方應該檢查填充字段。（選擇這種方案是由于它相對簡單，硬件實現容易。在沒有其他完整性措施實施情況下，如果接收方檢查解密的填充值，這種方案粉碎了某種形式的“剪切和粘貼”攻擊，提供有限的保護。）任何要求填充字段但不同于上述默認方法的加密算法，必須在一個指定ESP中算法如何使用的RFC中定義填充字段內容（例如，0或者隨機數）和所有要求接收方對這些填充字節的處理。這種情況下，填充字段的內容將由相應算法RFC中定義和選擇的加密算法和模式決定。相關的算法RFC可以指定接收方必須檢查填充字段或者接收方必須通知發送方接收方如何處理填充字段。填充長度PadLength填充長度字段指明緊接其前的填充字節的個數。有效值范圍是0至255，0表明沒有填充字節。填充長度字段是強制性的。下一個頭下一個頭是一個8位字段，它標識有效載荷字段中包含的數據類型，例如，IPv6中的擴展頭或者上層協議標識符。該字段值從InternetAssignedNumbersAuthority（IANA）最新“AssignedNumbers”[STD-2]RFC定義的IP協議號集當中選擇。下一個頭字段是強制性的。驗證數據驗證數據是可變長字段，它包含一個完整性校驗值（ICV）,ESP分組中該值的計算不包含驗證數據本身。字段長度由選擇的驗證函數指定。驗證數據字段是可選的，只有SA選擇驗證服務，才包含驗證數據字段。驗證算法規范必須指定ICV長度、驗證的比較規則和處理步驟。封裝安全協議處理ESP頭定位類似于AH,ESP有兩種使用方式：傳送模式或者隧道模式。前者僅在主機中實現，提供對上層協議的保護，不提供對IP頭的保護。（傳送模式中，注意安全架構文檔中定義的“堆棧中的塊”或者“線路中的塊”實現，入站和出站IP分片可能要求IPsec實現執行額外的IP重組/分片,以便遵照這個規范，提供透明IPsec支持。當存在多個接口時，在這些實現內部執行這些操作要特別小心。）傳送模式中，ESP插在IP頭之后，上層協議之前，例如TCP,UCP，ICMP等，或者在任何已經插入的IPsec頭之前°IPv4中，意指把ESP放在IP頭（和它包含的任何其他選項）之后，但是在上層協議之前。（注意術語“傳輸”模式不應該曲解為把它的應用限制在TCP和UDP中。例如ICMP報文可能使用“傳輸”模式或者“隧道”模式發送。）下面數據報圖示了典型IPv4分組中ESP傳送模式位置，以“表示出外形上尖銳對照”為基礎。（“ESP尾部”包含所有填充，加填充長度和下一個頭字段。）ESP應用前IPv4丨原始IP頭||||（所有選項）|TCP|數據|ESP應用后IPv4|原始IP頭|ESP|||ESP|ESP||（所有選項）|頭部|TCP|數據|尾部|驗證||<已加密>||<已驗證>|IPv6中，ESP被看作端到端的有效載荷，因而應該出現在逐跳，路由和分片擴展頭之后。目的選項擴展頭既可以在ESP頭之前，也可以在ESP頭之后，這由期望的語義決定。但是，因為ESP僅保護ESP之后的字段，通常它可能愿意把目的選項頭放在ESP頭之后。下面數據報圖示了典型IPv6分組中ESP傳送模式位置。ESP應用前IPv6||如果有||||原始IP頭|擴展頭|TCP|數據|ESP應用后IPv6|原始|逐跳，目的*||目的|||ESP|ESP||IP頭丨路由，分片|ESP|選項*|TCP|數據丨尾部|驗證||<已加密>||<已驗證>|*=如果存在，應該在ESP之前，ESP之后，或者ESP和AH頭以各種模式組合。IPsec架構文檔描述了必須支持的SA組合。隧道模式ESP可以在主機或者安全網關上實現。ESP在安全網關（保護用戶傳輸流量）實現時必須采用隧道模式。隧道模式中，“內部”IP頭裝載最終的源和目的地址，而“外部”IP頭可能包含不同的IP地址，例如安全網關地址。ESP保護整個內部IP分組，其中包括整個內部IP頭。相對于外部IP頭，隧道模式的ESP位置與傳送模式中ESP位置相同。下面數據報圖示了典型IPv4和IPv6分組中ESP隧道模式的位置。IPv4|新IP頭*||（所有選項）|ESP|原始IP頭*|||（所有選項）|TCP|數|ESP據|尾部|ESP||驗證||<已加密->||<已驗證->|IPv6|新*|新擴展||原始*|原始擴展|||ESP|ESP||IP頭|頭*|ESP|IP頭丨頭*|TCP|數據|尾部|驗證||<已加密-->||<--已驗證->|*=如果存在，外部IP頭/擴展的結構和內部IP頭/擴展的修改在下面討論。算法強制實現算法在第5節描述，“一致性要求”。但也可以支持其他算法。注意盡管機密性和驗證是可選的，但是至少要從這兩種服務中選擇其一，因此相應的兩種算法不允許同時為NULL。加密算法采用的加密算法由SA指定。ESP使用對稱加密算法。因為到達的IP分組可能失序，每個分組必須攜帶所有要求的數據，以便允許接收方為解密建立加密同步。這個數據可能明確地裝載在有效載荷字段，例如作為IV（上面描述的），或者數據可以從分組頭推導出來。因為ESP準備了明文填充，ESP采用的加密算法可以顯示塊或者流模式特性。注意因為加密（機密性）是可選的，這個算法可以為“NULL”。驗證算法ICV計算使用的驗證算法由SA指定。點對點通信時，合適的驗證算法包括基于對稱加密算法（例如DES）的或者基于單向散列函數（例如MD5或SHA-1）的鍵控消息鑒別碼（MAC）。對于多點傳送通信，單向散列算法與不對稱數字簽名算法結合使用比較合適，雖然目前性能和空間的考慮阻止了這種算法的使用。注意驗證是可選的，這個算法可以是“NULL”。出站分組處理傳送模式中，發送方把上層協議信息封裝在ESP頭/尾中，保留了指定的IP頭（和IPv6中所有IP擴展頭）。隧道模式中，外部和內部IP頭/擴展頭以各種方式相關。封裝處理期間外部IP頭/擴展頭的構建在安全架構文檔中描述。如果安全策略要求不止一個IPsec頭擴展，安全頭應用的順序必須由安全策略定義。SA查找只有當IPsec實現確定與某個調用ESP處理的SA相關聯時，ESP才應用于一個出站分組。確定對出站分組采取哪些IPsec處理的過程在安全架構文檔中描述。分組加密在本節中，由于格式化的含意，我們依據經常采用的加密算法來講述。需要理解采用NULL加密算法提供的“沒有機密性”。因此發送方：封裝（到ESP有效載荷字段）：-傳送模式-只有原始上層協議信息。-隧道模式-整個原始IP數據報。增加所有需要的填充。使用SA指明的密鑰，加密算法，算法模式和加密同步數據（如果需要）加密結果。-如果指出顯式加密同步數據，例如IV，它經由算法規范輸入到加密算法中，并放在有效載荷字段中。-如果指出隱式加密同步數據，例如IV，它被創建并經由算法規范輸入加密算法。構建外部IP頭的確切步驟依賴于模式（傳輸或者隧道），并在安全架構文檔中描述。如果選擇驗證，驗證之前首先執行加密，而加密并不包含驗證數據字段。這種處理順序易于在分組解密之前，接收方迅速檢測和拒絕分組重播或偽造分組，因而潛在地降低拒絕服務攻擊的影響。同時它也考慮了接收方并行分組處理的可能性，即加密可以與驗證并發執行。注意因為驗證數據不受加密保護，必須采用一種鍵控的驗證算法計算ICV。序列號產生當SA建立時，發送方的計數器初始化為0。發送方為這個SA增加序列號，把新值插入到序列號字段中。采用給定SA發送的第一個分組具有序列號1。如果激活抗重播服務（默認），發送方核查確保在序列號字段插入新值之前計數器沒有循環。換言之，發送方不允許在一個SA上發送一個引起序列號循環的分組。傳輸一個可能導致序列號溢出的分組的嘗試是可審核事件。（注意這種序列號管理方式不需要使用模運算）發送方假定抗重播服務是一種默認支持，除非接收方另外通告（參看3.4.3）。因此，如果計數器已經循環，發送方將建立新SA和密鑰（除非SA被配置為手工密鑰管理）。如果抗重播服務被禁止，發送方不需要監視或者把計數器置位，例如，手工密鑰管理情況下（參看第5節）。但是，發送方仍然增加計數器的值，當它達到最大值時，計數器返回0開始。完整性校驗值計算如果SA選擇驗證，發送方在ESP分組上計算ICV但不包含驗證數據。因此SPI、序列號、有效載荷數據、填充（如果存在）、填充長度和下一個頭字段都包含在ICV計算中。注意因為加密比驗證先執行，最后4個字段將是密文形式。一些驗證算法中，ICV計算實現所使用的字節串必須是算法指定的塊大小的倍數。如果這個字節串長度與算法要求的塊大小不匹配，必須在ESP分組末端添加隱含填充，（下一個頭字段之后）在ICV計算之前添加。填充八位組必須是0值。算法規范指定塊大小（和因此的填充長度）。這個填充不隨分組傳輸。注意MD5和SHA-1內部填充協定，它們被看作有1字節的塊大小。分片如果需要，IPsec實現內部ESP處理之后執行分片。因此傳送模式ESP應用于整個IP數據報（而不是IP片段）。ESP處理過的分組本身可以在途中由路由器分片，這樣的片段接收方必須在ESP處理之前重組。隧道模式時，ESP應用于一個IP分組，它的有效載荷可能是一個已分片的IP分組。例如，安全網關或者“堆棧中的塊”或者“線路上的塊”IPsec實現（安全架構文檔中定義）可以把隧道模式ESP應用到這樣的片段中。注意：傳送模式一3.1節開始提及的，堆棧中的塊和線路上的塊實現可以由本地IP層首先重組已分片的分組，接著應用IPsec,再把結果分組分片。注意：對于IPv6-堆棧中的塊和線路上的塊實現，有必要查看所有擴展頭來確定是否有一個分片的頭，從而決定分組是否需要在IPsec處理之前重組。入站分組處理重組如果要求，在ESP處理之前進行重組。如果提供給ESP處理的分組是一個IP分片，即OFFSET字段值非0,或者MOREFRAGMENTS標志位置位，接收方必須丟棄分組；這是可審核事件。該事件的核查日志表項應該包含SPI的值，接收日期/時間，源地址，目的地址，序列號和（IPv6）信息流ID。注意：對于分組重組，當前IPv4規范不要求OFFSET字段清為0或者MOREFRAGMENTS標志清空。為了已重組的分組由IPsec處理（與外觀上看是一個分片而丟棄相對應），IP代碼必須在它重組一個分組之后完成這兩件事情。SA查找收到一個（已重組的）包含ESP頭的分組時，根據目的IP地址、安全協議（ESP）和SPI，接收方確定適當的（不定向的）SA。（這個過程更詳細的細節在安全架構文檔中描述）SA指出序列號字段是否被校驗，驗證數據字段是否存在，它將指定解密和ICV計算（如果適用）使用的算法和密鑰。如果本次會話沒有有效的SA存在（例如接收方沒有密鑰），接收方必須丟棄分組；這是可審核事件。該事件的核查日志表項應該包含SPI的值、接收的日期/時間、源地址、目的地址、序列號和（IPv6）明文信息流ID。序列號確認所有ESP實現必須支持抗重播服務，雖然可以由接收方根據每個SA激活或者禁止它的使用。如果SA的驗證服務沒有激活，這項服務不允許激活。因為否則序列號字段沒有進行完整性保護。（當多個發送方控制流量到單個SA（不論目的地址是單播、廣播或者組播）時，注意沒有管理這多個發送方之間傳輸的序列號值的措施。因此抗重播服務不應該用在多個發送方使用唯一SA的環境中）如果接收方不激活SA的抗重播服務，將不對序列號進行入站檢查。但是從發送方觀點來看，默認的是假定接收方激活抗重播服務。為了避免接收方做不必要的序列號監視和SA建立（參看3.3.3），如果使用SA建立協議，例如IKE，在SA建立期間，如果接收方不提供抗重播保護，貝9接收方應該通告發送方。如果接收方已經為這個SA激活了抗重播服務，SA接收分組計數器在SA建立時，必須初始化為0。對于每個接收的分組，接收方必須確認分組包含序列號，并且序列號在這個SA生命期中不重復任何已接收的其它分組的序列號。這應該是分組與某個SA匹配之后，對該分組進行的第一個ESP檢驗，加快重復分組拒絕。通過采用滑動接收窗口拒絕分組重復。（窗口如何實現是本地事情，但是下面內容描述了實現必須展現的功能）必須支持32位的最小窗口大小；但是首選64位窗口大小，且應該是默認使用的。其他窗口大小（大于最小窗口）由接收方選擇。（接收方不會通告發送方窗口大小。）窗口“右”邊界代表該SA接收的最高的有效序列號值。對于序列號小于窗口“左”邊界的分組被拒絕。落入窗口內的分組依靠窗口內已接收分組列表進行檢驗。以使用位掩碼為基礎，實現這種檢驗的有效手段在安全架構文檔中描述。如果接收的分組落入窗口內且是新的，或者如果分組在窗口的右邊，那么接收方進行ICV確認。如果ICV有效性失敗，接收方必須把已接收的IP數據報作為非法而丟棄；這是可審核事件。該事件審核日志表項應該包括SPI值、接收的日期/時間、源地址、目的地址、序列號和（IPv6中）信息流ID。只有ICV確認成功時，接收方窗口才更新。討論：注意如果分組既在窗口內且是新的，或者在窗口外邊的“右邊”，接收方必須在更新序列號窗口數據之前驗證分組。完整性校驗值確認IntegrityCheckValueVerification如果選擇驗證，接收方采用指定的驗證算法對ESP分組計算ICV但不包含驗證數據字段，確認它與分組驗證數據字段中包含的ICV相同。計算細節下面提供。如果計算得來的與接收的ICV匹配，那么數據報有效，可以被接收。如果測試失敗，接收方必須作為非法而將接收的IP數據報丟棄；這是可審核事件。日志數據應該包括SPI值、接收的日期/時間、源地址、目的地址、序列號和（IPv6中）明文信息流ID。討論：從刪除和保存ICV值（驗證數據字段）開始。下一