S.KentBBNCorpS.KentBBNCorpR.Atkinson@HomeNetworkNovember1998RequestforComments:2406Obsoletes:1827Category:StandardsTrackIP封裝安全有效載荷(ESP)(RFC2406IPEncapsulatingSecurityPayload(ESP))本文檔狀態(tài)：ThisdocumentspecifiesanInternetstandardstrackprotocolfortheInternetcommunity,andrequestsdiscussionandsuggestionsforimprovements.Pleaserefertothecurrenteditionofthe"InternetOfficialProtocolStandards"(STD1)forthestandardizationstateandstatusofthisprotocol.Distributionofthismemoisunlimited.版權(quán)聲明Copyright(C)TheInternetSociety(1998).AllRightsReserved.目錄列表介紹封裝安全有效載荷分組格式安全參數(shù)索引序列號有效載荷數(shù)據(jù)填充（供加密使用）.填充長度下一個頭驗證數(shù)據(jù)封裝安全協(xié)議處理ESP頭定位算法加密算法驗證算法2344577777101010TOC\o"1-5"\h\z出站分組處理10SA查找11分組加密11序列號產(chǎn)生12完整性校驗值計算12分片133.4.1重組133.4.2SA查找133.4.3序列號確認(rèn)143.4.4完整性校驗值確認(rèn)153.4.5分組解密163.4入站分組處理134.審核175.一致性要求18TOC\o"1-5"\h\z6.安全考慮事項187.與RFC1827的不同18致謝19參考書目19Disclaimer作者信息21版權(quán)聲明22介紹封裝安全有效載荷頭在IPv4和IPv6中提供一種混合的安全服務(wù)。ESP可以單獨應(yīng)用，與IP驗證頭（AH）結(jié)合使用，或者采用嵌套形式，例如，隧道模式的應(yīng)用（參看"SecurityArchitecturefortheInternetProtocol"［KA97a］，下面使用“安全架構(gòu)文檔”代替）。安全服務(wù)可以在一對通信主機(jī)之間，一對通信的安全網(wǎng)關(guān)之間，或者一個安全網(wǎng)關(guān)和一臺主機(jī)之間實現(xiàn)。在各種網(wǎng)絡(luò)環(huán)境中如何使用ESP和AH的詳細(xì)細(xì)節(jié)，參看安全架構(gòu)文檔。ESP頭可以插在IP頭之后、上層協(xié)議頭之前（傳送模式），或者在封裝的IP頭之前（隧道模式）。下面將詳細(xì)介紹這些模式。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］。）關(guān)鍵字MUST,MUSTNOT,REQUIRED,SHALL,SHALLNOT,SHOULD,SHOULDNOT,RECOMMENDED,MAY，和OPTIONAL,當(dāng)它們出現(xiàn)在本文檔時，由RFC2119中的描述解釋它們的含義［Bra97］。封裝安全有效載荷分組格式ESP頭緊緊跟在協(xié)議頭（IPv4,IPv6，或者擴(kuò)展）之后，協(xié)議頭的協(xié)議字段（IPv4）將是50,或者協(xié)議的下一個頭（IPv6，擴(kuò)展）字段［STD-2］值是50。012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|安全參數(shù)索引(SPI)|"Auth.+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Cov-|序列號||erage+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+||有效載荷數(shù)據(jù)*(可變的)||"|||Conf.++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Cov-||填充（0-255bytes）||erage*+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+||||填充長度|下一個頭|vv+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|驗證數(shù)據(jù)（可變的）|||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+*如果加密同步數(shù)據(jù)，例如初始化向量（IV,參看2.3節(jié)），包含在有效載荷字段中，通常它本身并不加密，雖然常常把它作為密文的一部分。下面小節(jié)定義了頭格式中的字段?！翱蛇x項”意味著如果沒有選擇它，該字段被忽略。即它既不被包含在傳送的分組中，也不會在完整性校驗值（ICV，參看2.7）計算中出現(xiàn)。建立SA時決定是否選擇某個選項，因此ESP分組的格式對于給定的SA是確定的，整個SA存活期間也是確定的。相對而言，“強(qiáng)制性”字段總是出現(xiàn)在ESP分組格式中，對所有SA均如此。2.1安全參數(shù)索引SPISPI是一個任意的32位值，它與目的IP地址和安全協(xié)議（ESP）結(jié)合，唯一地標(biāo)識這個數(shù)據(jù)報的SA。從1至255的這組SPI值是由InternetAssignedNumbersAuthority（IANA）保留給將來使用的；除了分配的SPI值的使用由RFC指定，否則，一般IANA不會分配保留的SPI值。通常在建立SA時目的系統(tǒng)選擇SPI（詳細(xì)內(nèi)容請參看安全架構(gòu)文檔）。SPI字段是強(qiáng)制性的。SPI的值為0是保留給本地、特定實現(xiàn)使用的，不允許在線路上發(fā)送。例如，密鑰管理實現(xiàn)可以使用SPI的0值表示當(dāng)IPsec實現(xiàn)要求它的密鑰管理實體建立新SA,但SA仍然沒有建立時，“沒有SA存在”。序列號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)地），傳送的序列號必須決不允許循環(huán)。因此，在SA上傳送第2的32次方個分組之前，發(fā)送方計數(shù)器和接收方計數(shù)器必須重新置位（通過建立新SA和獲取新密鑰）有效載荷數(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)。填充（供加密使用）幾種因素要求或者激活填充字段的使用。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)生和消耗。為了確保加密位是算法塊大?。ㄉ厦娴谝粋€加重號）的倍數(shù)，填充計算應(yīng)用于除IV之外的有效載荷數(shù)據(jù)、填充長度和下一個頭字段。為了確保驗證數(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ā)送方接收方如何處理填充字段。填充長度PadLength填充長度字段指明緊接其前的填充字節(jié)的個數(shù)。有效值范圍是0至255，0表明沒有填充字節(jié)。填充長度字段是強(qiáng)制性的。下一個頭下一個頭是一個8位字段，它標(biāo)識有效載荷字段中包含的數(shù)據(jù)類型，例如，IPv6中的擴(kuò)展頭或者上層協(xié)議標(biāo)識符。該字段值從InternetAssignedNumbersAuthority（IANA）最新“AssignedNumbers”[STD-2]RFC定義的IP協(xié)議號集當(dāng)中選擇。下一個頭字段是強(qiáng)制性的。驗證數(shù)據(jù)驗證數(shù)據(jù)是可變長字段，它包含一個完整性校驗值（ICV）,ESP分組中該值的計算不包含驗證數(shù)據(jù)本身。字段長度由選擇的驗證函數(shù)指定。驗證數(shù)據(jù)字段是可選的，只有SA選擇驗證服務(wù)，才包含驗證數(shù)據(jù)字段。驗證算法規(guī)范必須指定ICV長度、驗證的比較規(guī)則和處理步驟。封裝安全協(xié)議處理ESP頭定位類似于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頭|ESP|||ESP|ESP||（所有選項）|頭部|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|原始|逐跳，目的*||目的|||ESP|ESP||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頭*||（所有選項）|ESP|原始IP頭*|||（所有選項）|TCP|數(shù)|ESP據(jù)|尾部|ESP||驗證||<已加密->||<已驗證->|IPv6|新*|新擴(kuò)展||原始*|原始擴(kuò)展|||ESP|ESP||IP頭|頭*|ESP|IP頭丨頭*|TCP|數(shù)據(jù)|尾部|驗證||<已加密-->||<--已驗證->|*=如果存在，外部IP頭/擴(kuò)展的結(jié)構(gòu)和內(nèi)部IP頭/擴(kuò)展的修改在下面討論。算法強(qiáng)制實現(xiàn)算法在第5節(jié)描述，“一致性要求”。但也可以支持其他算法。注意盡管機(jī)密性和驗證是可選的，但是至少要從這兩種服務(wù)中選擇其一，因此相應(yīng)的兩種算法不允許同時為NULL。加密算法采用的加密算法由SA指定。ESP使用對稱加密算法。因為到達(dá)的IP分組可能失序，每個分組必須攜帶所有要求的數(shù)據(jù)，以便允許接收方為解密建立加密同步。這個數(shù)據(jù)可能明確地裝載在有效載荷字段，例如作為IV（上面描述的），或者數(shù)據(jù)可以從分組頭推導(dǎo)出來。因為ESP準(zhǔn)備了明文填充，ESP采用的加密算法可以顯示塊或者流模式特性。注意因為加密（機(jī)密性）是可選的，這個算法可以為“NULL”。驗證算法ICV計算使用的驗證算法由SA指定。點對點通信時，合適的驗證算法包括基于對稱加密算法（例如DES）的或者基于單向散列函數(shù)（例如MD5或SHA-1）的鍵控消息鑒別碼（MAC）。對于多點傳送通信，單向散列算法與不對稱數(shù)字簽名算法結(jié)合使用比較合適，雖然目前性能和空間的考慮阻止了這種算法的使用。注意驗證是可選的，這個算法可以是“NULL”。出站分組處理傳送模式中，發(fā)送方把上層協(xié)議信息封裝在ESP頭/尾中，保留了指定的IP頭（和IPv6中所有IP擴(kuò)展頭）。隧道模式中，外部和內(nèi)部IP頭/擴(kuò)展頭以各種方式相關(guān)。封裝處理期間外部IP頭/擴(kuò)展頭的構(gòu)建在安全架構(gòu)文檔中描述。如果安全策略要求不止一個IPsec頭擴(kuò)展，安全頭應(yīng)用的順序必須由安全策略定義。SA查找只有當(dāng)IPsec實現(xiàn)確定與某個調(diào)用ESP處理的SA相關(guān)聯(lián)時，ESP才應(yīng)用于一個出站分組。確定對出站分組采取哪些IPsec處理的過程在安全架構(gòu)文檔中描述。分組加密在本節(jié)中，由于格式化的含意，我們依據(jù)經(jīng)常采用的加密算法來講述。需要理解采用NULL加密算法提供的“沒有機(jī)密性”。因此發(fā)送方：封裝（到ESP有效載荷字段）：-傳送模式-只有原始上層協(xié)議信息。-隧道模式-整個原始IP數(shù)據(jù)報。增加所有需要的填充。使用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。序列號產(chǎn)生當(dāng)SA建立時，發(fā)送方的計數(shù)器初始化為0。發(fā)送方為這個SA增加序列號，把新值插入到序列號字段中。采用給定SA發(fā)送的第一個分組具有序列號1。如果激活抗重播服務(wù)（默認(rèn)），發(fā)送方核查確保在序列號字段插入新值之前計數(shù)器沒有循環(huán)。換言之，發(fā)送方不允許在一個SA上發(fā)送一個引起序列號循環(huán)的分組。傳輸一個可能導(dǎo)致序列號溢出的分組的嘗試是可審核事件。（注意這種序列號管理方式不需要使用模運算）發(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開始。完整性校驗值計算如果SA選擇驗證，發(fā)送方在ESP分組上計算ICV但不包含驗證數(shù)據(jù)。因此SPI、序列號、有效載荷數(shù)據(jù)、填充（如果存在）、填充長度和下一個頭字段都包含在ICV計算中。注意因為加密比驗證先執(zhí)行，最后4個字段將是密文形式。一些驗證算法中，ICV計算實現(xiàn)所使用的字節(jié)串必須是算法指定的塊大小的倍數(shù)。如果這個字節(jié)串長度與算法要求的塊大小不匹配，必須在ESP分組末端添加隱含填充，（下一個頭字段之后）在ICV計算之前添加。填充八位組必須是0值。算法規(guī)范指定塊大?。ê鸵虼说奶畛溟L度）。這個填充不隨分組傳輸。注意MD5和SHA-1內(nèi)部填充協(xié)定，它們被看作有1字節(jié)的塊大小。分片如果需要，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處理之前重組。入站分組處理重組如果要求，在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代碼必須在它重組一個分組之后完成這兩件事情。SA查找收到一個（已重組的）包含ESP頭的分組時，根據(jù)目的IP地址、安全協(xié)議（ESP）和SPI，接收方確定適當(dāng)?shù)模ú欢ㄏ虻模㏒A。（這個過程更詳細(xì)的細(xì)節(jié)在安全架構(gòu)文檔中描述）SA指出序列號字段是否被校驗，驗證數(shù)據(jù)字段是否存在，它將指定解密和ICV計算（如果適用）使用的算法和密鑰。如果本次會話沒有有效的SA存在（例如接收方?jīng)]有密鑰），接收方必須丟棄分組；這是可審核事件。該事件的核查日志表項應(yīng)該包含SPI的值、接收的日期/時間、源地址、目的地址、序列號和（IPv6）明文信息流ID。序列號確認(rèn)所有ESP實現(xiàn)必須支持抗重播服務(wù)，雖然可以由接收方根據(jù)每個SA激活或者禁止它的使用。如果SA的驗證服務(wù)沒有激活，這項服務(wù)不允許激活。因為否則序列號字段沒有進(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ù)，貝9接收方應(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)使用的。其他窗口大?。ù笥谧钚〈翱冢┯山邮辗竭x擇。（接收方不會通告發(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ù)之前驗證分組。完整性校驗值確認(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ù)字段）開始。下一