5.2 安全報文協議

5.2.1 鑒別頭協議AH

5.2.1.1 概述

鑒別頭協議AH用于為IP數據報文提供無連接的完整性、數據源鑒別和抗重放攻擊服務。AH為IP頭提供盡可能多的鑒別，同時為上層協議數據提供鑒別。對于抗重放攻擊服務，AH依靠一個單調遞增的抗重放攻擊序列號來完成。AH不能提供機密性服務，因此本標準規定AH不能單獨使用，而應和封裝安全載荷協議ESP嵌套使用。

5.2.1.2 AH頭格式

AH頭格式見圖27，該格式里的所有字段都是強制的，并且被包括在完整性校驗值（ICV）計算中。AH頭緊跟在IP協議頭（IPv4、IPv6、或者擴展）之后，在IP協議頭中的協議字段（IPv4）或者下一個頭（IPv6，擴展）字段的值是51。

圖27 AH頭格式

下一個頭：下一個頭是一個1字節的字段，該字段指定了鑒別頭后面下一個載荷的類型。這個字段的值是由Internet分配數字機構（IANA）的最新“分配數字”[STD-2]中定義的IP協議數字集合分配的。

載荷長度：載荷長度是一個1字節的字段，該字段的值是AH頭的長度減去“2”，長度值以4字節為單位。

保留：保留字段是一個2字節的字段，留給將來使用。該字段應被設置成“0”，并且參與完整性校驗值ICV的計算。

安全參數索引（SPI）：安全參數索引SPI是一個4字節值，它與目的IP地址和安全協議共同標識了這個數據報文的安全關聯。從1至255范圍內的SPI值是保留給將來使用的，“0”值保留給本地的特定實現使用并且不能在網絡上傳送，通信協商得到的SPI值不能小于256。

序列號：序列號是一個無符號的4字節單調遞增計數器，發送方對使用該SA的每個數據報文進行計數，接收方必須檢測這個字段來實現SA的抗重放攻擊服務。發送方的計數器和接收方的計數器在建立一個SA時被初始化為0，該序列號在一個SA生存期內不能循環使用，在這個計數器溢出之前，通信的雙方應協商出一個新的SA來使這個字段復位為0。

鑒別數據：鑒別數據是一個變長字段，它是一個完整性校驗值ICV，用于校驗整個IP報文的完整性（可變字段除外）。該字段的長度必須是4字節的整數倍，具體長度取決于所使用的完整性校驗算法。

5.2.1.3 鑒別頭AH的處理

5.2.1.3.1 AH頭的位置

AH頭在傳輸模式和隧道模式中分別有不同的放置位置。

在IPv4環境中使用傳輸模式，AH頭應放在原IP頭之后, 上層協議ESP之前，如圖28所示。

圖28 IPv4的AH傳輸模式

在IPv6環境中使用傳輸模式，AH頭被看作是一個端到端的載荷，因而應該出現在逐跳（hop-by-hop）、路由（routing）和分片擴展頭（fragmentation extensionheaders）之后。目的選項擴展頭（destination options extension header）既可以出現在AH頭之前，也可以在AH頭之后。如圖29所示。

圖29 IPv6的AH傳輸模式

在隧道模式中，AH頭保護整個IP報文，包括整個原IP報文以及新建外部IP頭的部分字段。圖30和圖31分別表示了隧道模式中典型的IPv4和IPv6報文的AH頭的位置。

圖30 IPv4的AH隧道模式

圖31 IPv6的AH隧道模式

5.2.1.3.2 出站報文處理

5.2.1.3.2.1 概述

出站報文的處理包括查找SA、產生序列號、計算完整性校驗值、鑒別數據字段的填充和分片等過程。

5.2.1.3.2.2 查找SA

應根據本地策略查找SA，只有當一個IPSec實現確定了報文與該SA相關聯后，AH才應用于一個出站報文。否則應開始新的密鑰交換過程，建立SA。

5.2.1.3.2.3 產生序列號

當建立一個SA時，發送方的序列號計數器初始化為0，每發送一個報文之前，該計數器加1，并且把這個計數器值賦予序列號字段。當該計數器計數達到最大值前，應生成新的SA。

5.2.1.3.2.4 計算完整性校驗值ICV

接收方采用指定的完整性校驗算法對報文計算ICV。IPv4和IPv6的ICV計算方法分別如下所述：

a） IPv4中的ICV計算

IPv4基本頭字段、IPv4頭的選項、AH頭和上層協議數據都參與ICV計算。

IPv4基本頭字段中，直接參與計算的字段為：版本（Version）、IPv4頭長度(Header Length)、總長度(Total Length)、標識（Identification）、協議(Protocol)、源地址(Source Address)、目的地址(Destination Address)。

IPv4基本頭字段中，在計算ICV之前設置為“0”的字段為：服務類型（TOS）、標志（Flags）、片偏移（Fragment Offset）、生存時間（TTL）、首部校驗和（Header Checksum）。

IPv4頭的整個選項被看作一個單元，選項中的類型和長度字段在傳送中是不變的，但如果有一個字段是屬于可變的，則整個選項用于計算ICV時都要清“0”。

整個AH頭參與ICV計算，其中完整性校驗值字段在計算ICV之前置“0”，在計算后，將計算得到的值賦于該字段。

整個上層協議數據直接參與ICV計算。

b） IPv6中的ICV計算

IPv6基本頭字段、IPv6擴展頭、AH頭和上層協議數據都參與ICV計算。

IPv6基本頭字段中，直接參與計算的字段為：版本（Version）、 載荷長度（Payload Length）、下一個頭（Next Header）、源地址（Source Address）、沒有路由擴展頭的目的地址（Destination Address）。

IPv6基本頭字段中，在計算ICV之前設置為“0”的字段為：類別（Class）、流標簽（Flow Label）、跳極限（Hop Limit）。

IPv6的擴展頭中，在逐跳（Hop-by-Hop）和目的擴展頭（Destination Extension Headers）中的IPv6選項包含有一個比特，該比特指出選項在傳送過程期間是否會改變。對于在路由過程中內容可能變換的任何選項，整個“選項數據（Option Data）”字段在計算和校驗ICV時必須被當作零值的字節串對待。選項類型（Option Type）和選項數據長度（Opt Data Len）被包括進ICV計算。由比特位確定為不變的所有選項都被包括進ICV計算。

整個AH頭參與ICV計算，其中鑒別數據字段在計算ICV之前置“0”，在計算后，將計算得到的值賦于該字段。

整個上層協議數據直接參與ICV計算。

5.2.1.3.2.5 鑒別數據的填充

鑒別數據字段應確保是4字節（IPv4）或8字節（IPv6）的整數倍，否則需要填充。填充應放在鑒別數據字段的最末端，其內容由發送方任意選擇，并且參與ICV計算。

5.2.1.3.2.6 分片

一個IPSec實現在AH處理之后，如果發現IP數據報文長度超過輸出接口的MTU值，則對處理后的數據報文進行分片。

5.2.1.3.3 入站報文處理

5.2.1.3.3.1 概述

入站報文的處理包括重組、查找SA、驗證序列號和驗證完整性校驗值等過程。

5.2.1.3.3.2 重組

如果需要，在AH處理之前要進行IP數據報文重組。AH不處理分片報文，如果提供給AH處理的一個報文是一個分片的IP數據報文，接收方應丟棄該報文。

5.2.1.3.3.3 查找SA

當收到一個包含AH頭的報文時，接收方應根據目的IP地址、AH和SPI來查找SA，查找失敗則丟棄該報文。

5.2.1.3.3.4 驗證序列號

所有AH實現必須支持抗重放攻擊服務，在SA建立時，接收方序列號計數器應初始化為0。對于每個接收到的報文，接收方應確認報文包含一個序列號，并且該序列號在這個SA生命期中不重復，否則應丟棄該報文。

如果該序列號超出接收窗口有效檢查范圍的高端值，則對報文進行完整性校驗。如果校驗通過，接收窗口應相應調整；如果校驗不通過則丟棄該報文。

接收窗口的大小默認為64。

5.2.1.3.3.5 驗證完整性校驗值

接收方采用指定的完整性校驗算法對報文計算ICV，計算方法和參與計算的內容與出站報文計算ICV的一致。計算的結果與報文中的ICV進行比較。如果一致，則接收到的數據報文是有效的，否則接收方應將收到的數據報文丟棄。

5.2.1.3.3.6 匹配安全策略

檢查數據包是否符合設置的安全策略要求。

5.2.2 封裝安全載荷ESP

5.2.2.1 概述

封裝安全載荷ESP提供了機密性、數據源鑒別、無連接的完整性、抗重放攻擊服務和有限信息流量的保護。當ESP單獨使用時、必須同時選擇機密性和數據源鑒別服務，當ESP和AH結合使用時不應選擇數據源鑒別服務。

5.2.2.2 ESP頭

5.2.2.2.1 ESP頭格式

ESP頭格式見圖32，其位置緊接在IPv4、IPv6或者擴展協議之后，在頭中的協議（IPv4）字段或者下一個頭（IPv6，擴展）字段的值是50。

圖32 ESP頭格式

5.2.2.2.2 安全參數索引SPI

安全參數索引SPI是一個4字節值，它與目的IP地址和安全協議共同標識了這個數據報文的安全關聯。從1至255范圍內的SPI值是保留給將來使用的，“0”值保留給本地的特定實現使用并且不能在網絡上傳送，通信協商得到的SPI值不能小于256。

5.2.2.2.3 序列號

序列號是一個無符號的4字節單調遞增計數器，發送方對使用該SA的每個數據報文進行計數，接收方必須檢測這個字段來實現SA的抗重放攻擊服務。發送方的計數器和接收方的計數器在建立一個SA時被初始化為0，該序列號在一個SA生存期內不能循環使用，在這個計數器溢出之前，通信的雙方應協商出一個新的SA來使這個字段復位為0。

5.2.2.2.4 載荷數據

載荷數據是一個變長的字段，它包含初始化向量IV和下一個頭字段所描述的數據，其長度單位為字節。

IV應置于載荷數據首部。

5.2.2.2.5 填充字段

如果載荷數據的長度不是加密算法的分組長度的整數倍，則需要對不足的部分進行填充，填充以字節為單位。如果需要，也可以提供更多的填充數據，但必須符合加密算法分組長度的要求。

填充的方法和內容應由指定的加密算法規定。如果加密算法沒有規定，則附加在報文之后的第一個字節為１，后續的填充字節按單調遞增的順序拼湊。

5.2.2.2.6 填充長度

填充長度字段指出了填充字節的個數。有效值范圍是0至255，其中0表明沒有填充字節。

5.2.2.2.7 下一個頭

下一個頭是一個1字節的字段，該字段指定了ESP頭后面下一個載荷的類型。這個字段的值是由Internet分配數字機構（IANA）的最新“分配數字”[STD-2]中定義的IP協議數字集合分配的。

5.2.2.2.8 鑒別數據

鑒別數據是一個變長字段，它是一個完整性校驗值ICV，是對ESP報文去掉ICV外的其余部分進行完整性校驗計算所得的值。該字段的長度由選擇的完整性校驗算法決定。鑒別數據字段是可選的，只有當SA選擇了完整性校驗服務時才包含鑒別數據字段。

5.2.2.3 封裝安全載荷ESP的處理

5.2.2.3.1 ESP頭的位置

ESP頭在傳輸模式和隧道模式中分別有不同的放置位置。

在IPv4環境中使用傳輸模式，ESP應放在IP頭和它包含的所有選項之后和上層協議之前，如圖33所示,圖中“數據”包含“載荷數據”和“填充”，“ESP尾”包含“填充長度”和“下一個頭”字段。

圖33 IPv4的ESP傳輸模式

在IPv6環境中使用傳輸模式，ESP被看作是一個端到端的載荷，因而應該出現在逐跳（hop-by-hop）、路由（routing）和分片擴展頭（fragmentation extensionheaders）之后，如圖34所示，圖中“數據”包含“載荷數據”和“填充”，“ESP尾”包含“填充長度”和“下一個頭”字段。

圖34 IPv6的ESP傳輸模式

在IPv4 和IPv6中使用隧道模式，ESP保護包括原內部IP頭在內的整個原IP報文，分別如圖35和36所示, 圖中“數據”包含“載荷數據”和“填充”，“ESP尾”包含“填充長度”和“下一個頭”字段。

圖35 IPv4的ESP隧道模式

圖36 IPv6的ESP隧道模式

5.2.2.3.2 出站報文處理

5.2.2.3.2.1 概述

出站報文的處理包括查找SA、封裝、加密報文、產生序列號、計算完整性校驗值和分片等過程，并按照以下順序進行處理。

5.2.2.3.2.2 查找SA

應根據本地策略查找SA，只有當一個IPSec實現確定了報文與該SA相關聯后，ESP才應用于一個出站報文。否則應開始新的密鑰交換過程，建立SA。

5.2.2.3.2.3 封裝

在傳輸模式中，將原始上層協議封裝到ESP載荷字段中。

在隧道模式中，將整個原始IP數據報文封裝到ESP載荷字段中。

5.2.2.3.2.4 加密報文

首先對報文添加所有需要的填充，然后使用由SA指定的密鑰、加密算法、算法模式和IV進行加密，加密范圍包括載荷數據、填充、填充長度和下一個頭。

5.2.2.3.2.5 產生序列號

當建立一個SA時，發送方的序列號計數器初始化為0，每發送一個報文之前，該計數器加1，并且把這個計數器值插入到序列號字段中。當該計數器計數達到最大值前，應生成新的SA。

5.2.2.3.2.6 計算完整性校驗值

如果SA提供完整性校驗服務，發送方在除去鑒別數據字段的ESP報文上計算ICV。將計算后得到的值賦于鑒別數據字段。

5.2.2.3.2.7 分片

一個IPSec實現在ESP處理之后，如果發現IP數據報文長度超過輸出接口的MTU值，則對處理后的數據報文進行分片。

5.2.2.3.3 入站報文處理

5.2.2.3.3.1 概述

入站報文的處理包括重組、查找SA、驗證序列號、驗證完整性校驗值、解密報文和重構等過程，并按以下順序進行處理。

5.2.2.3.3.2 重組

如果需要，在ESP處理之前要進行IP數據報文重組。ESP不處理分片報文，如果提供給ESP處理的一個報文是一個分片的IP數據報文，接收方應丟棄該報文。

5.2.2.3.3.3 查找SA

當收到一個包含ESP頭的報文時，接收方應根據目的IP地址、ESP和SPI來查找SA，查找失敗則丟棄該報文。

5.2.2.3.3.4 驗證序列號

所有ESP實現必須支持抗重放攻擊服務，在SA建立時，接收方序列號計數器應初始化為0。對于每個接收到的報文，接收方應確認報文包含一個序列號，并且該序列號在這個SA生命期中不重復任何已接收的其它報文的序列號，否則應丟棄該報文。

如果該序列號超出接收窗口有效檢查范圍的高端值，則對報文進行完整性校驗。如果校驗通過，接收窗口應相應調整；如果校驗不通過則丟棄該報文。

接收窗口的大小默認為64。

5.2.2.3.3.5 驗證完整性校驗值

接收方采用指定的完整性校驗算法對報文計算ICV，計算方法和參與計算的內容與出站報文計算ICV的一致。計算的結果與報文中的ICV進行比較。如果一致，則接收到的數據報文是有效的，否則接收方應將收到的數據報文丟棄。

5.2.2.3.3.6 解密報文

使用SA指定的密鑰、加密算法、算法模式和IV，對接收報文的加密部分進行解密。根據解密后報文中填充數據的長度及內容判斷是否解密成功，解密失敗則丟棄該報文。

5.2.2.3.3.7 重構

對解密成功的報文，重構原始IP數據報文。

5.2.3 NAT穿越

為了穿越NAT，在UDP報文中封裝和解封裝ESP報文的方法按RFC3948的要求實現。

5.2.4 匹配安全策略

檢查數據包是否符合設置的安全策略要求。