rfc2406：IP 封裝安全有效載荷（ESP）

組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：sword（sword zxl1025@chinese.com）
譯文發布時間：2001-5-11
著作權：本中文翻譯文檔著作權歸中國互動出版網所有。可以用於非商業用途自由轉載，但必須保留本文檔的翻譯及著作權資訊。

Network Working Group
Request for Comments: 2406
Obsoletes: 1827
Category: Standards Track

S. Kent
BBN Corp
R. Atkinson
@Home Network
November 1998

備忘錄狀態

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

著作權資訊

Copyright (C) The Internet Society (1998). All Rights Reserved.

1. 介紹

封裝安全有效載荷頭在IPv4和IPv6中提供一種混合的安全服務。ESP可以單獨應用，與IP驗證頭(AH)結合使用，或者採用嵌套形式，例如，隧道模式的應用(參看 "Security Architecture for the Internet Protocol" [KA97a]，下面使用“安全架構文檔”代替)。安全服務可以在一對通訊主機之間，一對通訊的安全網關之間，或者一個安全網關和一台主機之間實現。在各種網路環境中如何使用ESP和AH的詳細細節，參看安全架構文檔。

ESP頭可以插在IP頭之後、上層協議頭之前(傳送模式)，或者在封裝的IP頭之前(隧道模式)。下面將詳細介紹這些模式。

ESP提供機密性、資料來源驗證、不需連線的完整性、抗重播服務(一種部分序列完整性的形式)和有限資訊流機密性。提供的這組服務由SA建立時選擇的選項和實現的位置來決定，機密性的選擇與所有其他服務相獨立。但是，確保機密性而不保證完整性/驗證(在ESP或者單獨在AH中)可能使資訊易受到某種活動的、破壞機密性服務的攻擊(參看[Bel96])。資料來源驗證和不需連線的完整性(下面統一稱作“驗證”引用它們)是相互關聯的服務，它們作為一個選項與機密性(可選擇的)結合提供給使用者。只有選擇資料來源驗證時才可以選擇抗重播服務，由接收方單獨決定抗重播服務的選擇。（儘管預設要求發送方增加抗重播服務使用的序號，但只有當接收方檢查序號，服務才是有效。）資訊流機密性要求選擇隧道模式，如果在安全網關上實現資訊流機密性是最有效，這裡資訊聚集能夠掩飾真正的源-目的模式。注意儘管機密性和驗證是可選的，但它們中必須至少選擇一個。

假定讀者熟悉安全架構文檔中描述的術語和概念。特別是，讀者應該熟悉ESP和AH提供的安全服務的定義，SA定義，ESP可以和驗證（AH）頭結合使用的方式，以及ESP和AH使用的不同密鑰管理選項。（至於最後一項，ESP和AH要求的當前密鑰管理選項是通過IKE進行的手工建立密鑰和自動建立密鑰[HC98]。）

關鍵字MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,SHOULD NOT, RECOMMENDED, MAY,和OPTIONAL, 當它們出現在本文檔時，由RFC2119中的描述解釋它們的含義[Bra97]。

2. 封裝安全有效載荷分組格式

ESP頭緊緊跟在協議頭（IPv4，IPv6，或者擴充）之後，協議頭的協議欄位（IPv4）將是50，或者協議的下一個頭(IPv6，擴充)欄位[STD-2]值是50。

 

*如果加密同步資料，例如初始化向量（IV，參看2.3節），包含在有效載荷欄位中，通常它本身並不加密，雖然常常把它作為密文的一部分。

下面小節定義了頭格式中的欄位。“可選項”意味著如果沒有選擇它，該欄位被忽略。即它既不被包含在傳送的分組中，也不會在完整性校正值(ICV，參看2.7)計算中出現。建立SA時決定是否選擇某個選項，因此ESP分組的格式對於給定的SA是確定的，整個SA存活期間也是確定的。相對而言，“強制性”欄位總是出現在ESP分組格式中，對所有SA均如此。

2.1 安全參數索引SPI

SPI是一個任意的32位值，它與目的IP地址和安全性通訊協定（ESP）結合，唯一地標識這個資料報的SA。從1至255的這組SPI值是由Internet Assigned Numbers Authority (IANA)保留給將來使用的；除了分配的SPI值的使用由RFC指定，否則，一般IANA不會分配保留的SPI值。通常在建立SA時目的系統選擇SPI（詳細內容請參看安全架構文檔）。SPI欄位是強制性的。

SPI的值為0是保留給本地、特定實現使用的，不允許線上路上發送。例如，密鑰管理實現可以使用SPI的0值表示當IPsec實現要求它的密鑰管理實體建立新SA，但SA仍然沒有建立時，“沒有SA存在”。

2.2 序號Sequence Number

這個無符號的、32位欄位包含一個單調遞增的計數器值（序號）。它是強制性的，即使接收方沒有選擇啟用一個特定SA的抗重播服務，它也總是存在。序號欄位由接收方處理，即發送方必須總是傳輸這個欄位，但接收方不需要對其操作（參看下面“入站分組處理”中序號確認的討論）。

發送方的計數器和接收方的計數器在一個SA建立時被初始化為0。（使用給定SA發送的第一個分組的序號1；序號如何產生的細節參看3.3.3節）如果啟用抗重播服務（預設地），傳送的序號必須決不允許迴圈。因此，在SA上傳送第2的32次方個分組之前，發送方計數器和接收方計數器必須重新置位（通過建立新SA和擷取新密鑰）

2.3 有效載荷資料Payload Data

有效載荷資料是變長欄位，它包含下一個頭欄位描述的資料。有效載荷資料欄位是強制性的，它的長度是位元組的整數倍。如果加密有效載荷的演算法要求加密同步資料，例如初始化向量（IV），那麼這個資料可以明確地裝載在有效載荷欄位。任何要求這樣明確的、每分組同步資料的密碼編譯演算法必須指出同步資料的長度、結構和位置，這是指定ESP中演算法如何使用的某個RFC的一部分。如果這種同步資料是隱式的，派生資料的演算法必須是RFC的一部分。

注意關於確保IV存在時（實際）密文對齊：
對於一些基於IV模式的操作，接收方把IV作為密文的開始，直接把IV傳給演算法。這些模式中，（實際）密文是否開始對齊對於接收方並不重要。
某些情況下，接收方從密文中單獨讀入IV。此時，演算法規範必須解決（實際）密文對齊如何?。

2.4 填充(供加密使用)

幾種因素要求或者啟用填充欄位的使用。
如果採用的密碼編譯演算法要求明文是某個數量位元組的倍數，例如塊密碼（block cipher）的塊大小，使用填充欄位填充明文（包含有效載荷資料、填充長度和下一個頭欄位，以及填充）以達到演算法要求的長度。
不管密碼編譯演算法要求如何，也可以要求填充欄位來確保結果密文以4位元組邊界終止。特別是，填充長度欄位和下一個頭欄位必須在4位元組字內靠右對齊，如所示的ESP分組格式，從而確保驗證資料欄位（如果存在）以4位元組邊界對齊。
除了演算法要求或者上面提及的對齊原因之外，填充欄位可以用於隱藏有效載荷實際長度，支援（部分）資訊流機密性。但是，包含這種額外的填充欄位佔據一定的頻寬，因而小心使用。

發送方可以增加0至255個位元組的填充。ESP分組的填充欄位是可選的，但是所有實現必須支援填充欄位的產生和消耗。
為了確保加密位是演算法塊大小（上面第一個加重號）的倍數，填充計算應用於除IV之外的有效載荷資料、填充長度和下一個頭欄位。
為了確保驗證資料以4位元組邊界對齊（上面第二個加重號），填充計算應用於包含IV的有效載荷資料、填充長度和下一個頭欄位。

如果需要填充位元組，但是密碼編譯演算法沒有指定填充內容，則必須採用下列預設處理。填充位元組使用一系列（無符號、1位元組）整數值初始化。附加在明文之後的第一個填充位元組為1，後面的填充位元組按單調遞增：1,2,3,…。當採用這種填充方案時，接收方應該檢查填充欄位。（選擇這種方案是由於它相對簡單，硬體實現容易。在沒有其他完整性措施實施情況下，如果接收方檢查解密的填儲值，這種方案粉碎了某種形式的“剪下和粘貼”攻擊，提供有限的保護。）

任何要求填充欄位但不同於上述預設方法的密碼編譯演算法，必須在一個指定ESP中演算法如何使用的RFC中定義填充欄位內容（例如，0或者隨機數）和所有要求接收方對這些填充位元組的處理。這種情況下，填充欄位的內容將由相應演算法RFC中定義和選擇的密碼編譯演算法和模式決定。相關的演算法RFC可以指定接收方必須檢查填充欄位或者接收方必須通知發送方接收方如何處理填充欄位。

2.5 填充長度Pad Length

填充長度欄位指明緊接其前的填充位元組的個數。有效值範圍是0至255，0表明沒有填充位元組。填充長度欄位是強制性的。

2.6 下一個頭

下一個頭是一個8位欄位，它標識有效載荷欄位中包含的資料類型，例如，IPv6中的擴充頭或者上層協議標識符。該欄位值從Internet Assigned Numbers Authority (IANA)最新“Assigned Numbers” [STD-2] RFC 定義的IP協議號集當中選擇。下一個頭欄位是強制性的。

2.7 驗證資料

驗證資料是可變長欄位，它包含一個完整性校正值（ICV），ESP分組中該值的計算不包含驗證資料本身。欄位長度由選擇的驗證函式指定。驗證資料欄位是可選的，只有SA選擇驗證服務，才包含驗證資料欄位。驗證演算法規範必須指定ICV長度、驗證的比較規則和處理步驟。

3. 封裝安全性通訊協定處理

3.1 ESP 頭定位

類似於AH，ESP 有兩種使用方式：傳送模式或者隧道模式。前者僅在主機中實現，提供對上層協議的保護，不提供對IP頭的保護。（傳送模式中，注意安全架構文檔中定義的“堆棧中的塊”或者“線路中的塊”實現，入站和出站IP分區可能要求IPsec實現執行額外的IP重組/分區，以便遵照這個規範，提供透明IPsec支援。當存在多個介面時，在這些實現內部執行這些操作要特別小心。）

傳送模式中，ESP插在IP頭之後，上層協議之前，例如TCP，UCP，ICMP等，或者在任何已經插入的IPsec頭之前。IPv4中，意指把ESP放在IP頭（和它包含的任何其他選項）之後, 但是在上層協議之前。（注意術語“傳輸”模式不應該曲解為把它的應用限制在TCP和UDP中。例如ICMP報文可能使用“傳輸”模式或者“隧道”模式發送。）下面資料報圖示了典型IPv4分組中ESP傳送模式位置，以“表示出外形上尖銳對照”為基礎。（“ESP尾部”包含所有填充，加填充長度和下一個頭欄位。）

 

IPv6中，ESP被看作端到端的有效載荷，因而應該出現在逐跳，路由和分區擴充頭之後。目的選項擴充頭既可以在ESP頭之前，也可以在ESP頭之後，這由期望的語義決定。但是，因為ESP僅保護ESP之後的欄位，通常它可能願意把目的選項頭放在ESP頭之後。下面資料報圖示了典型IPv6分組中ESP傳送模式位置。

 

* =如果存在，應該在ESP之前，ESP之後，或者ESP和AH頭以各種模式組合。IPsec架構文檔描述了必須支援的SA組合。

隧道模式ESP可以在主機或者安全網關上實現。ESP在安全網關（保護使用者傳輸串流量）實現時必須採用隧道模式。隧道模式中，“內部”IP頭裝載最終的源和目的地址，而“外部”IP頭可能包含不同的IP地址，例如安全網關地址。ESP保護整個內部IP分組，其中包括整個內部IP頭。相對於外部IP頭，隧道模式的ESP位置與傳送模式中ESP位置相同。下面資料報圖示了典型IPv4和IPv6分組中ESP隧道模式的位置。

 

* = 如果存在，外部IP頭/擴充的結構和內部IP頭/擴充的修改在下面討論。

3.2 演算法

強制實現演算法在第5節描述，“一致性要求”。但也可以支援其他演算法。注意儘管機密性和驗證是可選的，但是至少要從這兩種服務中選擇其一，因此相應的兩種演算法不允許同時為NULL。

3.2.1 密碼編譯演算法

採用的密碼編譯演算法由SA指定。ESP使用對稱式加密演算法。因為到達的IP分組可能失序，每個分組必須攜帶所有要求的資料，以便允許接收方為解密建立加密同步。這個資料可能明確地裝載在有效載荷欄位，例如作為IV（上面描述的），或者資料可以從分組頭推匯出來。因為ESP準備了明文填充，ESP採用的密碼編譯演算法可以顯示塊或者流模式特性。注意因為加密（機密性）是可選的，這個演算法可以為“NULL”

3.2.2 驗證演算法

ICV計算使用的驗證演算法由SA指定。點對點通訊時，合適的驗證演算法包括基於對稱式加密演算法（例如DES）的或者基於單向散列函數（例如MD5或SHA-1）的鍵控訊息鑒別碼（MAC）。對於多點傳送通訊，單向散列演算法與不對稱數位簽章演算法結合使用比較合適，雖然目前效能和空間的考慮阻止了這種演算法的使用。注意驗證是可選的，這個演算法可以是“NULL”。

3.3 出站分組處理

傳送模式中，發送方把上層協議資訊封裝在ESP頭/尾中，保留了指定的IP頭（和IPv6中所有IP擴充頭）。隧道模式中，外部和內部IP頭/擴充頭以各種方式相關。封裝處理期間外部IP頭/擴充頭的構建在安全架構文檔中描述。如果安全性原則要求不止一個IPsec頭擴充，安全頭應用的順序必須由安全性原則定義。

3.3.1 SA尋找

只有當IPsec實現確定與某個調用ESP處理的SA相關聯時，ESP才應用於一個出站分組。確定對出站分組採取哪些IPsec處理的過程在安全架構文檔中描述。

3.3.2 區塊編碼器

在本節中，由于格式化的含意，我們依據經常採用的密碼編譯演算法來講述。需要理解採用NULL密碼編譯演算法提供的“沒有機密性”。因此發送方：

1. 封裝（到ESP有效載荷欄位）：
傳送模式 –只有原始上層協議資訊。
隧道模式 – 整個原始IP資料報。

2. 增加所有需要的填充。

3. 使用SA指明的密鑰，密碼編譯演算法，演算法模式和加密同步資料（如果需要）加密結果。
如果指出顯式加密同步資料，例如IV，它經由演算法規範輸入到密碼編譯演算法中，並放在有效載荷欄位中。
如果指出隱式加密同步資料，例如IV，它被建立並經由演算法規範輸入密碼編譯演算法。

構建外部IP頭的確切步驟依賴於模式（傳輸或者隧道），並在安全架構文檔中描述。

如果選擇驗證，驗證之前首先執行加密，而加密並不包含驗證資料欄位。這種處理順序易於在分組解密之前，接收方迅速檢測和拒絕分組重播或偽造分組，因而潛在地降低拒絕服務的攻擊的影響。同時它也考慮了接收方並行分組處理的可能性，即加密可以與驗證並發執行。注意因為驗證資料不受加密保護，必須採用一種鍵控的驗證演算法計算ICV。

3.3.3 序號產生

當SA建立時，發送方的計數器初始化為0。發送方為這個SA增加序號，把新值插入到序號欄位中。採用給定SA發送的第一個分組具有序號1。

如果啟用抗重播服務（預設），發送方核查確保在序號欄位插入新值之前計數器沒有迴圈。換言之，發送方不允許在一個SA上發送一個引起序號迴圈的分組。傳輸一個可能導致序號溢出的分組的嘗試是可審核事件。（注意這種序號管理方式不需要使用模運算）

發送方假定抗重播服務是一種預設支援，除非接收方另外通告（參看3.4.3）。因此，如果計數器已經迴圈，發送方將建立新SA和密鑰（除非SA被配置為手工密鑰管理）。

如果抗重播服務被禁止，發送方不需要監視或者把計數器置位，例如，手工密鑰管理情況下（參看第5節）。但是，發送方仍然增加計數器的值，當它達到最大值時，計數器返回0開始。

3.3.4 完整性校正值計算

如果SA選擇驗證，發送方在ESP分組上計算ICV但不包含驗證資料。因此SPI、序號、有效載荷資料、填充（如果存在）、填充長度和下一個頭欄位都包含在ICV計算中。注意因為加密比驗證先執行，最後4個欄位將是密文形式。

一些驗證演算法中，ICV計算實現所使用的位元組串必須是演算法指定的塊大小的倍數。如果這個位元組串長度與演算法要求的塊大小不匹配，必須在ESP分組末端添加隱含填充，（下一個頭欄位之後）在ICV計算之前添加。填充八位組必須是0值。演算法規範指定塊大小（和因此的填充長度）。這個填充不隨分組傳輸。注意MD5和SHA-1內部填充協定，它們被看作有1位元組的塊大小。

3.3.5 分區

如果需要，IPsec實現內部ESP處理之後執行分區。因此傳送模式ESP應用於整個IP資料報（而不是IP片段）。ESP處理過的分組本身可以在途中由路由器分區，這樣的片段接收方必須在ESP處理之前重組。隧道模式時，ESP應用於一個IP分組，它的有效載荷可能是一個已分區的IP分組。例如，安全網關或者“堆棧中的塊”或者“線路上的塊”IPsec實現（安全架構文檔中定義）可以把隧道模式ESP應用到這樣的片段中。

注意：傳送模式—3.1節開始提及的，堆棧中的塊和線路上的塊實現可以由本地IP層首先重組已分區的分組，接著應用IPsec，再把結果分組分區。

注意：對於IPv6 –堆棧中的塊和線路上的塊實現，有必要查看所有擴充頭來確定是否有一個分區的頭，從而決定分組是否需要在IPsec處理之前重組。

3.4 入站分組處理

3.4.1 重組

如果要求，在ESP處理之前進行重組。如果提供給ESP處理的分組是一個IP分區，即OFFSET欄位值非0，或者MORE FRAGMENTS標誌位置位，接收方必須丟棄分組；這是可審核事件。該事件的核查日誌表項應該包含SPI的值，接收日期/時間，源地址，目的地址，序號和（IPv6）資訊流ID。

注意：對於分組重組，當前IPv4規範不要求OFFSET欄位清為0或者MORE FRAGMENTS標誌清空。為了已重組的分組由IPsec處理（與外觀上看是一個分區而丟棄相對應），IP代碼必須在它重組一個分組之後完成這兩件事情。

3.4.2 SA尋找

收到一個（已重組的）包含ESP頭的分組時，根據目的IP地址、安全性通訊協定（ESP）和SPI，接收方確定適當的（不定向的）SA。（這個過程更詳細的細節在安全架構文檔中描述）SA指出序號欄位是否被校正，驗證資料欄位是否存在，它將指定解密和ICV計算（如果適用）使用的演算法和密鑰。

如果本次會話沒有有效SA存在（例如接收方沒有密鑰），接收方必須丟棄分組；這是可審核事件。該事件的核查日誌表項應該包含SPI的值、接收的日期/時間、源地址、目的地址、序號和（IPv6）明文資訊流ID。

3.4.3 序號確認

所有ESP實現必須支援抗重播服務，雖然可以由接收方根據每個SA啟用或者禁止它的使用。如果SA的驗證服務沒有啟用，這項服務不允許啟用。因為否則序號欄位沒有進行完整性保護。（當多個發送方控制流程量到單個SA（不論目的地址是單播、廣播或者組播）時，注意沒有管理這多個發送方之間傳輸的序號值的措施。因此抗重播服務不應該用在多個發送方使用唯一SA的環境中）

如果接收方不啟用SA的抗重播服務，將不對序號進行入站檢查。但是從發送方觀點來看，預設的是假定接收方啟用抗重播服務。為了避免接收方做不必要的序號監視和SA建立（參看3.3.3），如果使用SA建立協議，例如IKE，在SA建立期間，如果接收方不提供抗重播保護，則接收方應該通告發送方。

如果接收方已經為這個SA啟用了抗重播服務，SA接收分組計數器在SA建立時，必須初始化為0。對於每個接收的分組，接收方必須確認分組包含序號，並且序號在這個SA生命期中不重複任何已接收的其它分組的序號。這應該是分組與某個SA匹配之後，對該分組進行的第一個ESP檢驗，加快重複分組拒絕。

通過採用滑動接收視窗拒絕分組重複。（視窗如何?是本地事情，但是下面內容描述了實現必須展現的功能）必須支援32位的最小視窗大小；但是首選64位視窗大小，且應該是預設使用的。其他視窗大小（大於最小視窗）由接收方選擇。（接收方不會通告發送方視窗大小。）

視窗“右”邊界代表該SA接收的最高的有效序號值。對於序號小於視窗“左”邊界的分組被拒絕。落入視窗內的分組依靠視窗內已接收分組列表進行檢驗。以使用位元遮罩為基礎，實現這種檢驗的有效手段在安全架構文檔中描述。

如果接收的分組落入視窗內且是新的，或者如果分組在視窗的右邊，那麼接收方進行ICV確認。如果ICV有效性失敗，接收方必須把已接收的IP資料報作為非法而丟棄；這是可審核事件。該事件稽核線索表項應該包括SPI值、接收的日期/時間、源地址、目的地址、序號和（IPv6中）資訊流ID。只有ICV確認成功時，接收方視窗才更新。

討論：

注意如果分組既在視窗內且是新的，或者在視窗外邊的“右邊”，接收方必須在更新序號視窗資料之前驗證分組。

3.4.4 完整性校正值確認Integrity Check Value Verification

如果選擇驗證，接收方採用指定的驗證演算法對ESP分組計算ICV但不包含驗證資料欄位，確認它與分組驗證資料欄位中包含的ICV相同。計算細節下面提供。

如果計算得來的與接收的ICV匹配，那麼資料報有效，可以被接收。如果測試失敗，接收方必須作為非法而將接收的IP資料報丟棄；這是可審核事件。日誌資料應該包括SPI值、接收的日期/時間、源地址、目的地址、序號和（IPv6中）明文資訊流ID。

討論：

從刪除和儲存ICV值（驗證資料欄位）開始。下一個檢查除去驗證資料欄位之後的ESP整個長度。如果由於驗證演算法的塊大小而要求隱式填充，把0填充的位元組直接附加到下一個頭欄位之後的ESP分組尾部。執行ICV計算，採用演算法規範定義的比較規則來把結果與儲存的值比較。（例如，如果ICV計算採用數位簽章和單向散列，匹配過程更複雜。）

3.4.5 分組解密

在3.3.2節“區塊編碼器”中，由于格式化的含意，在那裡我們依據經常採用的加密講述。需要理解使用NULL密碼編譯演算法提供“非機密性”。因此，接收方：

1. 採用SA指明的密鑰、密碼編譯演算法、演算法模式和加密同步資料（如果存在）解密ESP有效載荷資料、填充、填充長度和下一個頭。
如果指明顯式加密同步資料，例如IV，則從有效載荷欄位得到加密同步資料，並按照演算法規範將其輸入到解密演算法中。
如果指明是隱式加密同步資料，例如IV，則構建本地版本IV，並按照演算法規範將其輸入到解密演算法中。

2.處理所有密碼編譯演算法規範中指定的填充。如果採用預設的填充方案（參看2.4節），接收方應該在把已解密資料傳送給下一層之前，以及刪除填充之前，檢查填充欄位。

3. 重新構建原始IP資料報，利用：reconstructs the original IP datagram from:
傳送模式—原始IP頭和ESP有效載荷欄位中原始上層協議資訊
隧道模式 – 隧道IP頭+ESP有效載荷欄位中整個IP資料報。

重新構建未經處理資料報的確切步驟依賴於模式（傳送或者隧道），在安全架構文檔中描述。最小程度上，IPv6環境中，接收方應該確保已解密資料是8位元組對齊，使下一個頭欄位標識的協議更容易進行處理。

如果選擇驗證，確認和解密可以逐個或者並行實現。如果逐個實現，那麼ICV驗證應該首先執行。如果並存執行，驗證必須在已解密分組被傳遞進行更進一步處理之前完成。這種處理順序利於在解密分組之前，接收方迅速檢測和重播分組或偽造分組拒絕，因此潛在地降低了服務拒絕攻擊的影響。

注意：如果接收方執行解密且與驗證並行，小心避免對分組訪問和已解密分組重構可能的競爭條件。

注意解密“失敗”的幾種情形：Note that there are several ways in which the decryption can "fail":
已選擇的SA可能不正確—由於SPI，目的地址或者IPsec協議類型欄位被篡改而錯誤地選擇了SA。如果這樣的錯誤把分組映射到另一個現存的SA，則它們將無法辨別已被破壞的分組，（c情況）。篡改SPI可以通過驗證的使用而被檢測出來。但是，由於IP目的地址或者IPsec協議類型欄位被篡改，SA不匹配仍然可能發生。
填充長度或者填儲值可能是錯誤的—不管是否進行驗證，錯誤的填充長度或者填儲值可以被檢測出來。
已加密的ESP分組可能被破壞—如果SA選擇進行驗證，這可以檢測出來。

在 (a) 或者 (c)情況下，解密操作的錯誤結果（一個非法IP資料報或者傳送層幀）將不必要被IPsec檢測出來，這是後面協議處理的責任。

4. 審核

不是所有實現ESP的系統實現審核。但是，如果把ESP合并到一個支援審核的系統中，那麼ESP實現必須支援審核，必須允許系統管理員啟用或者禁止ESP審核。大部分而言，審核的粒度是本地的問題。然而，本規範中標識了幾個可審核事件，對於這些事件中的每一個，定義了應該包含在稽核線索中的一組最少資訊，當然也可以包含額外的資訊。本規範中沒有明確指出的額外事件也可以產生稽核線索表項。

這裡沒有要求接收方把任何資訊傳送給聲稱的發送方響應審核事件的檢測，因為這樣做可能導致服務拒絕。

5. 一致性要求

要求與本規範一致性或者順應性的實現必須實現ESP文法和這裡描述的處理過程，它必須遵照安全架構文檔的所有要求。如果計算ICV使用的密鑰手工分發，抗重播服務的正確提供要求發送方計數器狀態的正確維護，直到密鑰更新，如果計數器溢出即將發生，有可能沒有自動回復措施。因此一個順應實現不應該與手工鍵入的SA聯合來提供抗重播服務。一個順應ESP實現必須支援下列強制實現的演算法：
CBC模式的DES [MD97]
HMAC - MD5 [MG97a]
HMAC - SHA-1 [MG97b]
NULL 驗證演算法
NULL 密碼編譯演算法

因為ESP加密和驗證是可選的，對兩個“NULL”演算法的支援要求維護與協商這些服務的方式的一致性。注意驗證和加密可以單獨是“NULL”，但是不允許兩者同時是“NULL”。

6. 安全考慮事項

安全是這個協議設計的中心，因此安全考慮事項貫穿整個規範。使用IPsec協議額外的安全相關內容在安全架構文檔中討論。

7. 與 RFC 1827的不同

本文檔在幾個重要方面不同與RFC 1827 [ATK95] 。主要的不同是，本文檔試圖為ESP指定一個完整的架構和上下文，而RFC 1827提供了一個“shell”，通過轉換的定義來完善。轉換的增加促進ESP規範重新完善為一個更全面的文檔，加入ESP上下文中提供的安全服務選項。因此，之前在轉換文檔中定義的欄位現在是該基礎ESP規範的一部分。例如，用於支援驗證（和抗重播）的欄位現在這裡定義，即使該服務是可選項。

支援加密的填充欄位和下一個協議驗證的填充欄位現在也在此定義。與這些欄位定義一致的分組處理也包含在文檔中。.

致謝

Many of the concepts embodied in this specification were derived from or influenced by the US Government's SP3 security protocol, ISO/IEC's NLSP, or from the proposed swIPe security protocol. [SDNS89, ISO92, IB93].

For over 3 years, this document has evolved through multiple versions and iterations. During this time, many people have contributed significant ideas and energy to the process and the documents themselves. The authors would like to thank Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors would also like to thank the members of the IPsec and IPng working groups, with special mention of the efforts of (in alphabetic order): Steve Bellovin, Steve Deering, Phil Karn, Perry Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William Simpson and Nina Yuan.

參考書目
[ATK95] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1995.
[Bel96] Steven M. Bellovin, "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix Unix Security Symposium, July, 1996.
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IB93] John Ioannidis & Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of the USENIX Security Symposium, Santa Clara, CA, October 1993.
[ISO92] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992.
[KA97a] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[KA97b] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[MD97] Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[MG97a] Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[MG97b] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html
[SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, as published in NIST Publication NIST-IR-90-4250, February 1990.

Disclaimer

The views and specification here are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems specification.

作者資訊

Stephen Kent
BBN Corporation
70 Fawcett Street
Cambridge, MA 02140
USA
Phone: +1 (617) 873-3988
EMail: kent@bbn.com

Randall Atkinson
@Home Network
425 Broadway,
Redwood City, CA 94063
USA
Phone: +1 (415) 569-5000
EMail: rja@corp.home.net

Full Copyright Statement

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.