IP 封裝安全有效載荷 (ESP)

本文檔狀態：

ThisdocumentspecifiesanInternetstandardstrackprotocolforthe
Internetcommunity,andrequestsdiscussionandsuggestionsfor
improvements.Pleaserefertothecurrenteditionofthe"Internet
OfficialProtocolStandards"(STD1)forthestandardizationstate
andstatusofthisprotocol.Distributionofthismemoisunlimited.

版權聲明

Copyright(C)TheInternetSociety(1998).AllRightsReserved.

目錄列表

1.介紹..................................................2
2.封裝安全有效載荷分組格式..................3
2.1安全參數索引................................4
2.2序列號.........................................4
2.3有效載荷數據.............................................5
2.4填充（供加密使用）.................................5
2.5填充長度...............................................7
2.6下一個頭..............................................7
2.7驗證數據......................................7
3.封裝安全協議處理....................7
3.1ESP頭定位......................................7
3.2算法..............................................10
3.2.1加密算法..............................10
3.2.2驗證算法..........................10
3.3出站分組處理..............................10
3.3.1SA查找........................11
3.3.2分組加密..................................11
3.3.3序列號產生.........................12
3.3.4完整性校驗值計算..................12
3.3.5分片......................................13
3.4入站分組處理...............................13
3.4.1重組.........................................13
3.4.2SA查找........................13
3.4.3序列號確認.......................14
3.4.4完整性校驗值確認.................15

3.4.5分組解密..................................16
4.審核.....................................................17
5.一致性要求.....................................18
6.安全考慮事項......................................18
7.與RFC1827的不同....................................18
致謝................................................19
參考書目......................................................19
Disclaimer......................................................20
作者信息..............................................21
版權聲明........................................22

1.介紹

封裝安全有效載荷頭在IPv4和IPv6中提供一種混合的安全服務。ESP可以單獨應用，與IP
驗證頭(AH)結合使用，或者采用嵌套形式，例如，隧道模式的應用(參看"SecurityArchitecturefor
theInternetProtocol"[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]。

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

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


0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----
|安全參數索引(SPI)|^Auth.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Cov-
|序列號||erage
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|----
|有效載荷數據*(可變的)||^
~~||
|||Conf.
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Cov-
||填充(0-255bytes)||erage*
+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+||
||填充長度|下一個頭|vv
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------
|驗證數據(可變的)|
~~
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

2.1安全參數索引SPI

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

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

2.2序列號SequenceNumber

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

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

2.3有效載荷數據PayloadData

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

注意關于確保IV存在時（實際）密文對齊：

o對于一些基于IV模式的操作，接收方把IV作為密文的開始，直接把IV傳給算
法。這些模式中，（實際）密文是否開始對齊對于接收方并不重要。
o某些情況下，接收方從密文中單獨讀入IV。此時，算法規范必須解決（實際）密
文對齊如何實現。

2.4填充(供加密使用)

幾種因素要求或者激活填充字段的使用。
o如果采用的加密算法要求明文是某個數量字節的倍數，例如塊密碼（blockcipher）
的塊大小，使用填充字段填充明文（包含有效載荷數據、填充長度和下一個頭字段，以及填充）
以達到算法要求的長度。

o不管加密算法要求如何，也可以要求填充字段來確保結果密文以4字節邊界終止。
特別是，填充長度字段和下一個頭字段必須在4字節字內右對齊，如上圖所示的ESP分組格式，
從而確保驗證數據字段（如果存在）以4字節邊界對齊。

o除了算法要求或者上面提及的對齊原因之外，填充字段可以用于隱藏有效載荷實
際長度，支持（部分）信息流機密性。但是，包含這種額外的填充字段占據一定的帶寬，因而小
心使用。

發送方可以增加0至255個字節的填充。ESP分組的填充字段是可選的，但是所有實現必須
支持填充字段的產生和消耗。

a.為了確保加密位是算法塊大?。ㄉ厦娴谝粋€加重號）的倍數，填充計算應用于除
IV之外的有效載荷數據、填充長度和下一個頭字段。

b.為了確保驗證數據以4字節邊界對齊（上面第二個加重號），填充計算應用于包
含IV的有效載荷數據、填充長度和下一個頭字段。

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

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

2.5填充長度PadLength

填充長度字段指明緊接其前的填充字節的個數。有效值范圍是0至255，0表明沒有填充字節。
填充長度字段是強制性的。

2.6下一個頭

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

2.7驗證數據

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

3.封裝安全協議處理

3.1ESP頭定位

類似于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頭*||原始IP頭*|||ESP|ESP|
|(所有選項)|ESP|(所有選項)|TCP|數據|尾部|驗證|
-----------------------------------------------------------
|<---------已加密---------->|
|<-----------已驗證---------->|

------------------------------------------------------------
IPv6|新*|新擴展||原始*|原始擴展|||ESP|ESP|
|IP頭|頭*|ESP|IP頭|頭*|TCP|數據|尾部|驗證|
------------------------------------------------------------
|<---------已加密----------->|
|<----------已驗證---------->|

*=如果存在，外部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.1SA查找

只有當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值。算法規范指定塊大?。ê鸵虼说奶畛溟L度）。
這個填充不隨分組傳輸。注意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，或者MOREFRAGMENTS標志位置位，接收方必須丟棄分組；這是可審核事件。
該事件的核查日志表項應該包含SPI的值，接收日期/時間，源地址，目的地址，序列號和（IPv6）
信息流ID。

注意：對于分組重組，當前IPv4規范不要求OFFSET字段清為0或者MOREFRAGMENTS
標志清空。為了已重組的分組由IPsec處理（與外觀上看是一個分片而丟棄相對應），IP代碼必
須在它重組一個分組之后完成這兩件事情。

3.4.2SA查找

收到一個（已重組的）包含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位窗口大小，且應該是默認使用
的。其他窗口大?。ù笥谧钚〈翱冢┯山邮辗竭x擇。（接收方不會通告發送方窗口大小。）

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

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

討論：

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

3.4.4完整性校驗值確認IntegrityCheckValueVerification

如果選擇驗證，接收方采用指定的驗證算法對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數據報，利用：reconstructstheoriginalIPdatagramfrom:
-傳送模式—原始IP頭和ESP有效載荷字段中原始上層協議信息
-隧道模式–隧道IP頭+ESP有效載荷字段中整個IP數據報。

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

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

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

注意解密“失敗”的幾種情形：Notethatthereareseveralwaysinwhichthedecryptioncan"fail":

a.已選擇的SA可能不正確—由于SPI，目的地址或者IPsec協議類型字段被篡改而錯
誤地選擇了SA。如果這樣的錯誤把分組映射到另一個現存的SA，則它們將無法辨別已被破壞
的分組，（c情況）。篡改SPI可以通過驗證的使用而被檢測出來。但是，由于IP目的地址或者
IPsec協議類型字段被篡改，SA不匹配仍然可能發生。

b.填充長度或者填充值可能是錯誤的—不管是否進行驗證，錯誤的填充長度或者填充
值可以被檢測出來。

c.已加密的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.與RFC1827的不同

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

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

致謝

Manyoftheconceptsembodiedinthisspecificationwerederivedfrom
orinfluencedbytheUSGovernment'sSP3securityprotocol,ISO/IEC's
NLSP,orfromtheproposedswIPesecurityprotocol.[SDNS89,ISO92,
IB93].

Forover3years,thisdocumenthasevolvedthroughmultipleversions
anditerations.Duringthistime,manypeoplehavecontributed
significantideasandenergytotheprocessandthedocuments
themselves.TheauthorswouldliketothankKarenSeoforproviding
extensivehelpinthereview,editing,backgroundresearch,and
coordinationforthisversionofthespecification.Theauthors
wouldalsoliketothankthemembersoftheIPsecandIPngworking
groups,withspecialmentionoftheeffortsof(inalphabeticorder):
SteveBellovin,SteveDeering,PhilKarn,PerryMetzger,David
Mihelcic,HilarieOrman,NormanShulman,WilliamSimpsonandNina
Yuan.

參考書目

[ATK95]Atkinson,R.,"IPEncapsulatingSecurityPayload(ESP)",
RFC1827,August1995.

[Bel96]StevenM.Bellovin,"ProblemAreasfortheIPSecurity
Protocols",ProceedingsoftheSixthUsenixUnixSecurity
Symposium,July,1996.

[Bra97]Bradner,S.,"KeywordsforuseinRFCstoIndicate
RequirementLevel",BCP14,RFC2119,March1997.

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

[IB93]JohnIoannidis&MattBlaze,"Architectureand
ImplementationofNetwork-layerSecurityUnderUnix",
ProceedingsoftheUSENIXSecuritySymposium,SantaClara,
CA,October1993.

[ISO92]ISO/IECJTC1/SC6,NetworkLayerSecurityProtocol,ISO-IEC
DIS11577,InternationalStandardsOrganisation,Geneva,
Switzerland,29November1992.

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

[KA97b]Kent,S.,andR.Atkinson,"IPAuthenticationHeader",RFC
2402,November1998.

[MD97]Madson,C.,andN.Doraswamy,"TheESPDES-CBCCipher
AlgorithmWithExplicitIV",RFC2405,November1998.

[MG97a]Madson,C.,andR.Glenn,"TheUseofHMAC-MD5-96within
ESPandAH",RFC2403,November1998.

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

[STD-2]Reynolds,J.,andJ.Postel,"AssignedNumbers",STD2,RFC
1700,October1994.Seealso:
http://www.iana.org/numbers.html

[SDNS89]SDNSSecureDataNetworkSystem,SecurityProtocol3,SP3,
DocumentSDN.301,Revision1.5,15May1989,aspublished
inNISTPublicationNIST-IR-90-4250,February1990.

Disclaimer

Theviewsandspecificationherearethoseoftheauthorsandarenot
necessarilythoseoftheiremployers.Theauthorsandtheir
employersspecificallydisclaimresponsibilityforanyproblems
arisingfromcorrectorincorrectimplementationoruseofthis
specification.

作者信息

StephenKent
BBNCorporation
70FawcettStreet
Cambridge,MA02140
USA

Phone:+1(617)873-3988
EMail:kent@bbn.com

RandallAtkinson
@HomeNetwork
425Broadway,
RedwoodCity,CA94063
USA

Phone:+1(415)569-5000
EMail:rja@corp.home.net

FullCopyrightStatement

Copyright(C)TheInternetSociety(1998).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuclearcase/" target="_blank" >ccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.