本文檔狀態(tài)：

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

版權(quán)聲明

Copyright(C)TheInternetSociety(1998).AllRightsReserved.

目錄列表

1.介紹..................................................2
2.封裝安全有效載荷分組格式..................3
2.1安全參數(shù)索引................................4
2.2序列號.........................................4
2.3有效載荷數(shù)據(jù).............................................5
2.4填充（供加密使用）.................................5
2.5填充長度...............................................7
2.6下一個頭..............................................7
2.7驗證數(shù)據(jù)......................................7
3.封裝安全協(xié)議處理....................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序列號產(chǎn)生.........................12
3.3.4完整性校驗值計算..................12
3.3.5分片......................................13
3.4入站分組處理...............................13
3.4.1重組.........................................13
3.4.2SA查找........................13
3.4.3序列號確認(rèn).......................14
3.4.4完整性校驗值確認(rèn).................15

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

1.介紹

封裝安全有效載荷頭在ipv4和IPv6中提供一種混合的安全服務(wù)。ESP可以單獨應(yīng)用，與IP
驗證頭(AH)結(jié)合使用，或者采用嵌套形式，例如，隧道模式的應(yīng)用(參看"SecurityArchitecturefor
theInternetProtocol"[KA97a]，下面使用“安全架構(gòu)文檔”代替)。安全服務(wù)可以在一對通信主機(jī)
之間，一對通信的安全網(wǎng)關(guān)之間，或者一個安全網(wǎng)關(guān)和一臺主機(jī)之間實現(xiàn)。在各種網(wǎng)絡(luò)環(huán)境中如
何使用ESP和AH的具體細(xì)節(jié)，參看安全架構(gòu)文檔。

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

ESP提供機(jī)密性、數(shù)據(jù)源驗證、無連接的完整性、抗重播服務(wù)(一種部分序列完整性的形式)
和有限信息流機(jī)密性。提供的這組服務(wù)由SA建立時選擇的選項和實現(xiàn)的位置來決定，機(jī)密性的
選擇與所有其他服務(wù)相獨立。但是，確保機(jī)密性而不保證完整性/驗證(在ESP或者單獨在AH中)
可能使信息易受到某種活動的、破壞機(jī)密性服務(wù)的攻擊(參看[Bel96])。數(shù)據(jù)源驗證和無連接的完
整性(下面統(tǒng)一稱作“驗證”引用它們)是相互關(guān)聯(lián)的服務(wù)，它們作為一個選項與機(jī)密性(可選擇的)
結(jié)合提供給用戶。只有選擇數(shù)據(jù)源驗證時才可以選擇抗重播服務(wù)，由接收方單獨決定抗重播服務(wù)
的選擇。（盡管默認(rèn)要求發(fā)送方增加抗重播服務(wù)使用的序列號，但只有當(dāng)接收方檢查序列號，服
務(wù)才是有效的。）信息流機(jī)密性要求選擇隧道模式，假如在安全網(wǎng)關(guān)上實現(xiàn)信息流機(jī)密性是最有
效的，這里信息聚集能夠掩飾真正的源-目的模式。注重盡管機(jī)密性和驗證是可選的，但它們中
必須至少選擇一個。

假定讀者熟悉安全架構(gòu)文檔中描述的術(shù)語和概念。非凡是，讀者應(yīng)該熟悉ESP和AH提供的
安全服務(wù)的定義，SA定義，ESP可以和驗證（AH）頭結(jié)合使用的方式，以及ESP和AH使用
的不同密鑰治理選項。（至于最后一項，ESP和AH要求的當(dāng)前密鑰治理選項是通過IKE進(jìn)行的
手工建立密鑰和自動建立密鑰[HC98]。）

要害字MUST,MUSTNOT,REQUIRED,SHALL,SHALLNOT,SHOULD,SHOULDNOT,
RECOMMENDED,MAY,和OPTIONAL,當(dāng)它們出現(xiàn)在本文檔時，由RFC2119中的描述解釋它
們的含義[Bra97]。

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

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


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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

2.1安全參數(shù)索引SPI

SPI是一個任意的32位值，它與目的IP地址和安全協(xié)議（ESP）結(jié)合，唯一地標(biāo)識這個數(shù)據(jù)
報的SA。從1至255的這組SPI值是由InternetAssignedNumbersAuthority(IANA)保留給將來
使用的；除了分配的SPI值的使用由RFC指定，否則，一般IANA不會分配保留的SPI值。通
常在建立SA時目的系統(tǒng)選擇SPI（具體內(nèi)容請參看安全架構(gòu)文檔）。SPI字段是強(qiáng)制性的。

SPI的值為0是保留給本地、特定實現(xiàn)使用的，不答應(yīng)在線路上發(fā)送。例如，密鑰治理實現(xiàn)
可以使用SPI的0值表示當(dāng)IPsec實現(xiàn)要求它的密鑰治理實體建立新SA，但SA仍然沒有建立時，
“沒有SA存在”。

2.2序列號SequenceNumber

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

發(fā)送方的計數(shù)器和接收方的計數(shù)器在一個SA建立時被初始化為0。（使用給定SA發(fā)送的第
一個分組的序列號1；序列號如何產(chǎn)生的細(xì)節(jié)參看3.3.3節(jié)）假如激活抗重播服務(wù)（默認(rèn)地），傳
送的序列號必須決不答應(yīng)循環(huán)。因此，在SA上傳送第2的32次方個分組之前，發(fā)送方計數(shù)器
和接收方計數(shù)器必須重新置位（通過建立新SA和獲取新密鑰）

2.3有效載荷數(shù)據(jù)PayloadData

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

注重關(guān)于確保IV存在時（實際）密文對齊：

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

2.4填充(供加密使用)

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

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

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

發(fā)送方可以增加0至255個字節(jié)的填充。ESP分組的填充字段是可選的，但是所有實現(xiàn)必須
支持填充字段的產(chǎn)生和消耗。

a.為了確保加密位是算法塊大小（上面第一個加重號）的倍數(shù)，填充計算應(yīng)用于除
IV之外的有效載荷數(shù)據(jù)、填充長度和下一個頭字段。

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

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

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

2.5填充長度PadLength

填充長度字段指明緊接其前的填充字節(jié)的個數(shù)。有效值范圍是0至255，0表明沒有填充字節(jié)。
填充長度字段是強(qiáng)制性的。

2.6下一個頭

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

2.7驗證數(shù)據(jù)

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

3.封裝安全協(xié)議處理

3.1ESP頭定位

類似于AH，ESP有兩種使用方式：傳送模式或者隧道模式。前者僅在主機(jī)中實現(xiàn)，提供對
上層協(xié)議的保護(hù)，不提供對IP頭的保護(hù)。（傳送模式中，注重安全架構(gòu)文檔中定義的“堆棧中的
塊”或者“線路中的塊”實現(xiàn)，入站和出站IP分片可能要求IPsec實現(xiàn)執(zhí)行額外的IP重組/分片，
以便遵照這個規(guī)范，提供透明IPsec支持。當(dāng)存在多個接口時，在這些實現(xiàn)內(nèi)部執(zhí)行這些操作要
非凡小心。）

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


ESP應(yīng)用前
----------------------------
IPv4原始IP頭
(所有選項)TCP數(shù)據(jù)
----------------------------

ESP應(yīng)用后
-------------------------------------------------
IPv4原始IP頭ESPESPESP
(所有選項)頭部TCP數(shù)據(jù)尾部驗證
-------------------------------------------------
<-----已加密---->
<------已驗證----->

IPv6中，ESP被看作端到端的有效載荷，因而應(yīng)該出現(xiàn)在逐跳，路由和分片擴(kuò)展頭之后。
目的選項擴(kuò)展頭既可以在ESP頭之前，也可以在ESP頭之后，這由期望的語義決定。但是，因
為ESP僅保護(hù)ESP之后的字段，通常它可能愿意把目的選項頭放在ESP頭之后。下面數(shù)據(jù)報圖
示了典型IPv6分組中ESP傳送模式位置。
ESP應(yīng)用前
---------------------------------------
IPv6假如有
原始IP頭擴(kuò)展頭TCP數(shù)據(jù)
---------------------------------------

ESP應(yīng)用后
---------------------------------------------------------
IPv6原始逐跳，目的*目的ESPESP
IP頭路由，分片ESP選項*TCP數(shù)據(jù)尾部驗證
---------------------------------------------------------
<----已加密---->
<----已驗證---->

*=假如存在，應(yīng)該在ESP之前，ESP之后，或者ESP和AH頭以各種模
式組合。IPsec架構(gòu)文檔描述了必須支持的SA組合。

隧道模式ESP可以在主機(jī)或者安全網(wǎng)關(guān)上實現(xiàn)。ESP在安全網(wǎng)關(guān)（保護(hù)用戶傳輸流量）實現(xiàn)
時必須采用隧道模式。隧道模式中，“內(nèi)部”IP頭裝載最終的源和目的地址，而“外部”IP頭可
能包含不同的IP地址，例如安全網(wǎng)關(guān)地址。ESP保護(hù)整個內(nèi)部IP分組，其中包括整個內(nèi)部IP
頭。相對于外部IP頭，隧道模式的ESP位置與傳送模式中ESP位置相同。下面數(shù)據(jù)報圖示了典
型IPv4和IPv6分組中ESP隧道模式的位置。

-----------------------------------------------------------
IPv4新IP頭*原始IP頭*ESPESP
(所有選項)ESP(所有選項)TCP數(shù)據(jù)尾部驗證
-----------------------------------------------------------
<---------已加密---------->
<-----------已驗證---------->

------------------------------------------------------------
IPv6新*新擴(kuò)展原始*原始擴(kuò)展ESPESP
IP頭頭*ESPIP頭頭*TCP數(shù)據(jù)尾部驗證
------------------------------------------------------------
<---------已加密----------->
<----------已驗證---------->

*=假如存在，外部IP頭/擴(kuò)展的結(jié)構(gòu)和內(nèi)部IP頭/擴(kuò)展的修改在下面討論。

3.2算法

強(qiáng)制實現(xiàn)算法在第5節(jié)描述，“一致性要求”。但也可以支持其他算法。注重盡管機(jī)密性和驗
證是可選的，但是至少要從這兩種服務(wù)中選擇其一，因此相應(yīng)的兩種算法不答應(yīng)同時為NULL。

3.2.1加密算法

采用的加密算法由SA指定。ESP使用對稱加密算法。因為到達(dá)的IP分組可能失序，每個分
組必須攜帶所有要求的數(shù)據(jù)，以便答應(yīng)接收方為解密建立加密同步。這個數(shù)據(jù)可能明確地裝載在
有效載荷字段，例如作為IV（上面描述的），或者數(shù)據(jù)可以從分組頭推導(dǎo)出來。因為ESP預(yù)備了
明文填充，ESP采用的加密算法可以顯示塊或者流模式特性。注重因為加密（機(jī)密性）是可選的，
這個算法可以為“NULL”。

3.2.2驗證算法

ICV計算使用的驗證算法由SA指定。點對點通信時，合適的驗證算法包括基于對稱加密算
法（例如DES）的或者基于單向散列函數(shù)（例如md5或SHA-1）的鍵控消息鑒別碼（MAC）。
對于多點傳送通信，單向散列算法與不對稱數(shù)字簽名算法結(jié)合使用比較合適，雖然目前性能和空
間的考慮阻止了這種算法的使用。注重驗證是可選的，這個算法可以是“NULL”。

3.3出站分組處理

傳送模式中，發(fā)送方把上層協(xié)議信息封裝在ESP頭/尾中，保留了指定的IP頭（和IPv6中所
有IP擴(kuò)展頭）。隧道模式中，外部和內(nèi)部IP頭/擴(kuò)展頭以各種方式相關(guān)。封裝處理期間外部IP
頭/擴(kuò)展頭的構(gòu)建在安全架構(gòu)文檔中描述。假如安全策略要求不止一個IPsec頭擴(kuò)展，安全頭應(yīng)用
的順序必須由安全策略定義。

3.3.1SA查找

只有當(dāng)IPsec實現(xiàn)確定與某個調(diào)用ESP處理的SA相關(guān)聯(lián)時，ESP才應(yīng)用于一個出站分組。
確定對出站分組采取哪些IPsec處理的過程在安全架構(gòu)文檔中描述。

3.3.2分組加密

在本節(jié)中，由于格式化的含意，我們依據(jù)經(jīng)常采用的加密算法來講述。需要理解采用NULL
加密算法提供的“沒有機(jī)密性”。因此發(fā)送方：
1.封裝（到ESP有效載荷字段）：
-傳送模式–只有原始上層協(xié)議信息。
-隧道模式–整個原始IP數(shù)據(jù)報。
2.增加所有需要的填充。
3.使用SA指明的密鑰，加密算法，算法模式和加密同步數(shù)據(jù)（假如需要）加密結(jié)果。
-假如指出顯式加密同步數(shù)據(jù)，例如IV，它經(jīng)由算法規(guī)范輸入到加密算法中，并放在有
效載荷字段中。
-假如指出隱式加密同步數(shù)據(jù)，例如IV，它被創(chuàng)建并經(jīng)由算法規(guī)范輸入加密算法。

構(gòu)建外部IP頭的確切步驟依靠于模式（傳輸或者隧道），并在安全架構(gòu)文檔中描述。

假如選擇驗證，驗證之前首先執(zhí)行加密，而加密并不包含驗證數(shù)據(jù)字段。這種處理順序易于
在分組解密之前，接收方迅速檢測和拒絕分組重播或偽造分組，因而潛在地降低拒絕服務(wù)攻擊的
影響。同時它也考慮了接收方并行分組處理的可能性，即加密可以與驗證并發(fā)執(zhí)行。注重因為驗
證數(shù)據(jù)不受加密保護(hù)，必須采用一種鍵控的驗證算法計算ICV。

3.3.3序列號產(chǎn)生

當(dāng)SA建立時，發(fā)送方的計數(shù)器初始化為0。發(fā)送方為這個SA增加序列號，把新值插入到序
列號字段中。采用給定SA發(fā)送的第一個分組具有序列號1。

假如激活抗重播服務(wù)（默認(rèn)），發(fā)送方核查確保在序列號字段插入新值之前計數(shù)器沒有循環(huán)。
換言之，發(fā)送方不答應(yīng)在一個SA上發(fā)送一個引起序列號循環(huán)的分組。傳輸一個可能導(dǎo)致序列號
溢出的分組的嘗試是可審核事件。（注重這種序列號治理方式不需要使用模運(yùn)算）

發(fā)送方假定抗重播服務(wù)是一種默認(rèn)支持，除非接收方另外通告（參看3.4.3）。因此，假如計
數(shù)器已經(jīng)循環(huán)，發(fā)送方將建立新SA和密鑰（除非SA被配置為手工密鑰治理）。

假如抗重播服務(wù)被禁止，發(fā)送方不需要監(jiān)視或者把計數(shù)器置位，例如，手工密鑰治理情況下
（參看第5節(jié)）。但是，發(fā)送方仍然增加計數(shù)器的值，當(dāng)它達(dá)到最大值時，計數(shù)器返回0開始。

3.3.4完整性校驗值計算

假如SA選擇驗證，發(fā)送方在ESP分組上計算ICV但不包含驗證數(shù)據(jù)。因此SPI、序列號、
有效載荷數(shù)據(jù)、填充（假如存在）、填充長度和下一個頭字段都包含在ICV計算中。注重因為加
密比驗證先執(zhí)行，最后4個字段將是密文形式。

一些驗證算法中，ICV計算實現(xiàn)所使用的字節(jié)串必須是算法指定的塊大小的倍數(shù)。假如這個
字節(jié)串長度與算法要求的塊大小不匹配，必須在ESP分組末端添加隱含填充，（下一個頭字段之
后）在ICV計算之前添加。填充八位組必須是0值。算法規(guī)范指定塊大小（和因此的填充長度）。
這個填充不隨分組傳輸。注重MD5和SHA-1內(nèi)部填充協(xié)定，它們被看作有1字節(jié)的塊大小。

3.3.5分片

假如需要，IPsec實現(xiàn)內(nèi)部ESP處理之后執(zhí)行分片。因此傳送模式ESP應(yīng)用于整個IP數(shù)據(jù)報
（而不是IP片段）。ESP處理過的分組本身可以在途中由路由器分片，這樣的片段接收方必須在
ESP處理之前重組。隧道模式時，ESP應(yīng)用于一個IP分組，它的有效載荷可能是一個已分片的
IP分組。例如，安全網(wǎng)關(guān)或者“堆棧中的塊”或者“線路上的塊”IPsec實現(xiàn)（安全架構(gòu)文檔中
定義）可以把隧道模式ESP應(yīng)用到這樣的片段中。

注重：傳送模式—3.1節(jié)開始提及的，堆棧中的塊和線路上的塊實現(xiàn)可以由本地IP層首先重
組已分片的分組，接著應(yīng)用IPsec，再把結(jié)果分組分片。

注重：對于IPv6–堆棧中的塊和線路上的塊實現(xiàn)，有必要查看所有擴(kuò)展頭來確定是否有一個
分片的頭，從而決定分組是否需要在IPsec處理之前重組。

3.4入站分組處理

3.4.1重組

假如要求，在ESP處理之前進(jìn)行重組。假如提供給ESP處理的分組是一個IP分片，即OFFSET
字段值非0，或者M(jìn)OREFRAGMENTS標(biāo)志位置位，接收方必須丟棄分組；這是可審核事件。
該事件的核查日志表項應(yīng)該包含SPI的值，接收日期/時間，源地址，目的地址，序列號和（IPv6）
信息流ID。

注重：對于分組重組，當(dāng)前IPv4規(guī)范不要求OFFSET字段清為0或者M(jìn)OREFRAGMENTS
標(biāo)志清空。為了已重組的分組由IPsec處理（與外觀上看是一個分片而丟棄相對應(yīng)），IP代碼必
須在它重組一個分組之后完成這兩件事情。

3.4.2SA查找

收到一個（已重組的）包含ESP頭的分組時，根據(jù)目的IP地址、安全協(xié)議（ESP）和SPI，
接收方確定適當(dāng)?shù)模ú欢ㄏ虻模㏒A。（這個過程更具體的細(xì)節(jié)在安全架構(gòu)文檔中描述）SA指出
序列號字段是否被校驗，驗證數(shù)據(jù)字段是否存在，它將指定解密和ICV計算（假如適用）使用
的算法和密鑰。

假如本次會話沒有有效的SA存在（例如接收方?jīng)]有密鑰），接收方必須丟棄分組；這是可審
核事件。該事件的核查日志表項應(yīng)該包含SPI的值、接收的日期/時間、源地址、目的地址、序
列號和（IPv6）明文信息流ID。

3.4.3序列號確認(rèn)

所有ESP實現(xiàn)必須支持抗重播服務(wù)，雖然可以由接收方根據(jù)每個SA激活或者禁止它的使用。
假如SA的驗證服務(wù)沒有激活，這項服務(wù)不答應(yīng)激活。因為否則序列號字段沒有進(jìn)行完整性保護(hù)。
（當(dāng)多個發(fā)送方控制流量到單個SA（不論目的地址是單播、廣播或者組播）時，注重沒有治理
這多個發(fā)送方之間傳輸?shù)男蛄刑栔档拇胧Ｒ虼丝怪夭シ?wù)不應(yīng)該用在多個發(fā)送方使用唯一SA
的環(huán)境中）

假如接收方不激活SA的抗重播服務(wù)，將不對序列號進(jìn)行入站檢查。但是從發(fā)送方觀點來看，
默認(rèn)的是假定接收方激活抗重播服務(wù)。為了避免接收方做不必要的序列號監(jiān)視和SA建立（參看
3.3.3），假如使用SA建立協(xié)議，例如IKE，在SA建立期間，假如接收方不提供抗重播保護(hù)，則
接收方應(yīng)該通告發(fā)送方。

假如接收方已經(jīng)為這個SA激活了抗重播服務(wù)，SA接收分組計數(shù)器在SA建立時，必須初始
化為0。對于每個接收的分組，接收方必須確認(rèn)分組包含序列號，并且序列號在這個SA生命期
中不重復(fù)任何已接收的其它分組的序列號。這應(yīng)該是分組與某個SA匹配之后，對該分組進(jìn)行的
第一個ESP檢驗，加快重復(fù)分組拒絕。

通過采用滑動接收窗口拒絕分組重復(fù)。（窗口如何實現(xiàn)是本地事情，但是下面內(nèi)容描述了實現(xiàn)
必須展現(xiàn)的功能）必須支持32位的最小窗口大小；但是首選64位窗口大小，且應(yīng)該是默認(rèn)使用
的。其他窗口大小（大于最小窗口）由接收方選擇。（接收方不會通告發(fā)送方窗口大小。）

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

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

討論：

注重假如分組既在窗口內(nèi)且是新的，或者在窗口外邊的“右邊”，接收方必須在更新序列
號窗口數(shù)據(jù)之前驗證分組。

3.4.4完整性校驗值確認(rèn)IntegrityCheckValueVerification

假如選擇驗證，接收方采用指定的驗證算法對ESP分組計算ICV但不包含驗證數(shù)據(jù)字段，確
認(rèn)它與分組驗證數(shù)據(jù)字段中包含的ICV相同。計算細(xì)節(jié)下面提供。

假如計算得來的與接收的ICV匹配，那么數(shù)據(jù)報有效，可以被接收。假如測試失敗，接收方
必須作為非法而將接收的IP數(shù)據(jù)報丟棄；這是可審核事件。日志數(shù)據(jù)應(yīng)該包括SPI值、接收的
日期/時間、源地址、目的地址、序列號和（IPv6中）明文信息流ID。

討論：

從刪除和保存ICV值（驗證數(shù)據(jù)字段）開始。下一個檢查除去驗證數(shù)據(jù)字段之后的ESP
整個長度。假如由于驗證算法的塊大小而要求隱式填充，把0填充的字節(jié)直接附加到下一個頭字
段之后的ESP分組尾部。執(zhí)行ICV計算，采用算法規(guī)范定義的比較規(guī)則來把結(jié)果與保存的值比
較。（例如，假如ICV計算采用數(shù)字簽名和單向散列，匹配過程更復(fù)雜。）

3.4.5分組解密

在3.3.2節(jié)“分組加密”中，由于格式化的含意，在那里我們依據(jù)經(jīng)常采用的加密講述。需要
理解使用NULL加密算法提供“非機(jī)密性”。因此，接收方：

1.采用SA指明的密鑰、加密算法、算法模式和加密同步數(shù)據(jù)（假如存在）解密ESP有
效載荷數(shù)據(jù)、填充、填充長度和下一個頭。
-假如指明顯式加密同步數(shù)據(jù)，例如IV，則從有效載荷字段得到加密同步數(shù)據(jù)，并按照
算法規(guī)范將其輸入到解密算法中。
-假如指明是隱式加密同步數(shù)據(jù)，例如IV，則構(gòu)建本地版本IV，并按照算法規(guī)范將其輸
入到解密算法中。
2.處理所有加密算法規(guī)范中指定的填充。假如采用默認(rèn)的填充方案（參看2.4節(jié)），接收
方應(yīng)該在把已解密數(shù)據(jù)傳送給下一層之前，以及刪除填充之前，檢查填充字段。

3.重新構(gòu)建原始IP數(shù)據(jù)報，利用：reconstructstheoriginalIPdatagramfrom:
-傳送模式—原始IP頭和ESP有效載荷字段中原始上層協(xié)議信息
-隧道模式–隧道IP頭+ESP有效載荷字段中整個IP數(shù)據(jù)報。

重新構(gòu)建原始數(shù)據(jù)報的確切步驟依靠于模式（傳送或者隧道），在安全架構(gòu)文檔中描述。最小
程度上，IPv6環(huán)境中，接收方應(yīng)該確保已解密數(shù)據(jù)是8字節(jié)對齊，使下一個頭字段標(biāo)識的協(xié)議
更輕易進(jìn)行處理。

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

注重：假如接收方執(zhí)行解密且與驗證并行，小心避免對分組訪問和已解密分組重構(gòu)可能的競
爭條件。

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

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

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

c.已加密的ESP分組可能被破壞—假如SA選擇進(jìn)行驗證，這可以檢測出來。

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

4.審核

不是所有實現(xiàn)ESP的系統(tǒng)實現(xiàn)審核。但是，假如把ESP合并到一個支持審核的系統(tǒng)中，那么
ESP實現(xiàn)必須支持審核，必須答應(yīng)系統(tǒng)治理員激活或者禁止ESP審核。大部分而言，審核的粒
度是本地的問題。然而，本規(guī)范中標(biāo)識了幾個可審核事件，對于這些事件中的每一個，定義了應(yīng)
該包含在審核日志中的一組最少信息，當(dāng)然也可以包含額外的信息。本規(guī)范中沒有明確指出的額
外事件也可以產(chǎn)生審核日志表項。

這里沒有要求接收方把任何信息傳送給聲稱的發(fā)送方響應(yīng)審核事件的檢測，因為這樣做可能
導(dǎo)致服務(wù)拒絕。

5.一致性要求

要求與本規(guī)范一致性或者順應(yīng)性的實現(xiàn)必須實現(xiàn)ESP語法和這里描述的處理過程，它必須遵
照安全架構(gòu)文檔的所有要求。假如計算ICV使用的密鑰手工分發(fā)，抗重播服務(wù)的正確提供要求
發(fā)送方計數(shù)器狀態(tài)的正確維護(hù)，直到密鑰更新，假如計數(shù)器溢出即將發(fā)生，有可能沒有自動恢復(fù)
措施。因此一個順應(yīng)實現(xiàn)不應(yīng)該與手工鍵入的SA聯(lián)合來提供抗重播服務(wù)。一個順應(yīng)ESP實現(xiàn)必
須支持下列強(qiáng)制實現(xiàn)的算法：

-CBC模式的DES[MD97]
-HMAC-MD5[MG97a]
-HMAC-SHA-1[MG97b]
-NULL驗證算法
-NULL加密算法

因為ESP加密和驗證是可選的，對兩個“NULL”算法的支持要求維護(hù)與協(xié)商這些服務(wù)的方
式的一致性。注重驗證和加密可以單獨是“NULL”，但是不答應(yīng)兩者同時是“NULL”。

6.安全考慮事項

安全是這個協(xié)議設(shè)計的中心，因此安全考慮事項貫穿整個規(guī)范。使用IPsec協(xié)議額外的安全
相關(guān)內(nèi)容在安全架構(gòu)文檔中討論。

7.與RFC1827的不同

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

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

致謝

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
revokedbytheInternetSocietyoritssuccessorsorassigns.

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