本備忘錄狀态
版權提示
摘要
目錄
1.簡介
本文檔假定讀者熟悉網際網路協定體系架構（後來被稱為安全架構的文檔）中的術語和概念。讀者尤其應該熟悉封裝安全載荷（ESP）協定和IP認證首部（AH）中的安全服務定義、安全協會的概念、ESP和AH協定協同工作的方式以及兩者密鑰管理的差異。
文檔中涉及的諸如MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL,等關鍵字的含義在RFC2119中已經給出解釋。
IP認證首部（AH）用來提供IP封包無連接配接完整性和資料源認證（後來稱為完整性）以及防重放保護。當安全聯盟（SA）建立後，防重放可以作為接受者的一個可選服務。（協定預設需要發送者增長序列号用于防重放，但是該功能隻有在接收方檢查序列号時才有效。）然而，為了使用擴充序列号特性，AH在SA管理協定中強制提出需求來協商這個新特性。（詳見下面2.5.1節）。
AH為IP頭和下一層協定資料提供盡可能多的認證。然而，IP頭中某些域在傳輸過程中會發生變化，封包發送者可能無法預知當封包到達接受者時這些域值會發生那些變化。AH無法對這種域值提供保護。是以，AH對IP頭的保護是零散的。（見附錄A）
AH可以單獨使用，也可以同IP封裝安全載荷（ESP）協同應用[Ken-ESP]，或者以嵌套的方式應用（見安全架構文檔[Ken-Arch]）。安全服務可以提供在一對主機之間、安全網關之間、或者安全網關和主機之間。ESP可以提供相同的放重發和相似的完整性保護，此外，它還可以提供加密服務。ESP和AH提供的完整性保護是有差異的，主要展現在保護的内容範圍上。并且，除非IP首部域是由ESP封裝的（例如，使用隧道模式），否則ESP不提供對IP首部任何域提供保護。如果想要了解在複雜網絡中使用AH和ESP的細節資訊，請參閱安全架構文檔[Ken-Arch]。
2. 認證頭格式
AH頭緊前面的協定頭（IPv4、IPv6或者IPv6擴充）中協定（IPv4）或者下一層頭（IPv6，擴充）中的值應該是51[DH98]。
圖 1. AH格式
下清單格就是包含AH（圖1列舉）的域，以及在完整性計算中包含的其他域，可以用來作為被ICV覆寫的域和傳輸内容。
[1] - M = 強制的
[2] - 參閱3.3.3節，“完整性校驗值計算 ”，檢查IP頭域的細節。
[3] - ICV計算之前清零（計算後顯示ICV結果）
[4] - 如果是隧道模式 ->IP 資料段
如果是傳輸模式->下一層頭和資料
下列的各個章節定義了包含AH格式的各種域。這裡描述的所有域都需要是強制性的，例如他們都必須采用AH格式，都需要進行完整性檢查計算（ICV）（參閱2.6節和3.3.3節）。
注意：IPsec中所有的加密程式的資料需要采用規範的網絡位元組序（參閱 RFC791附錄），同樣生成規範網絡位元組序的輸出。IP封包同樣采用網絡位元組序傳輸。
AH不包含版本号，是以如果涉及向後相容，兩個IPsec對等體之間必須使用一種信号機制尋址以便保證AH版本的比對，比如，IKE[IKEv2]或者不同信号通道的配置機制。
2.1. 下一層頭
下一層頭是一個8bit的域，用來識别認證頭後面負載的類型。這個域的取值選自網際網路号碼配置設定局（IANA）Web頁中定義的一系列IP協定号。比如，4表示IPv4,41表示IPv6，6表示TCP。
2.2. 負載長度
這個8bit的域用來指定AH占32bit（4位元組為機關）的長度，減去“2”。例如，一個完整算法産生96bit的認證值，它的長度域将是“4”（3個32bit混合域加上3個32bit的ICV，再減去2）。對于IPv6，頭部商都必須是多個八位位組。（注意，雖然IPv6[DH98]将AH描述為一種擴充頭，但是它的長度要使用32bit作為單元，而不是其他IPv6擴充頭所使用的64bit。）參閱2.6節“完整性檢查值（ICV）”，關于這個域的填充描述，和3.3.3.2.1節，“ICV填充”。
2.3. 保留字段
這個16bit的域用來保留給未來使用。發送者必須将該域清零，接收者也應該忽略該域（注意，ICV計算包括該值，但是接收者會忽略它）。
2.4. 安全參數索引（SPI）
SPI是一個任意的32bit值，接收者用它來識别SA攜帶的傳入資料包。對于單點傳播SA，SPI自己就可以識别一個SA，或者也可以同IPsec協定類型配合使用（這裡就是AH）。對于單點傳播SA，SPI的值是有接收者産生的，它能否足以獨立識别SA或者是否必須同IPsec協定配置使用是一個本地行為。SPI域是必須的，并且這種入方向流量到單點傳播SA的映射機制必須被所有AH實作支援。
如果IPsec的實作支援多點傳播，它必須支援多點傳播SA使用下列算法将入方向IPsec資料映射到SA。隻支援單點傳播流量的實作不必采用這種解析程式。
在很多安全多點傳播架構中，例如[RFC3740],一種中央組控制器/關鍵字伺服器向組配置設定安全聯盟SPI。這種SPI配置設定方式并不和關鍵字管理子系統協商，這樣的子系統在包含組的獨立終端系統裡面。是以，組安全聯盟和單點傳播安全聯盟可能同時使用相同的SPI 。具有多點傳播功能的IPsec即使在存在SPI沖突的環境中也必須能夠正确的解析入方向流量。
每個安全聯盟資料庫（SPD）中的實體[Ken-Arch]必須指明SA查找除了使用SPI之外，還是否使用目的位址，目的位址和源位址，IP 位址。多點傳播SA查詢不使用這個協定域。每個入方向IPsec保護的資料包必須執行SAD的搜尋，由此來找到符合最長比對SA辨別符的SA實體。所謂最長比對，就是如果兩個或者更多SAD實體同SPI值相同，那麼還需要比較目的位址，目的位址和源位址，IP位址（正如SAD實體指明的那樣）。這就意味SAD搜尋的邏輯順序是這樣的：
1.基于｛SPI，目的位址，源位址｝搜尋SAD。如果存在SAD實體符合要求，那麼就處理相應的入方向AH資料包。否則進行步驟2.
2.基于｛SPI，目的位址｝搜尋SAD。如果存在SAD實體符合要求，那麼就處理相應的入方向AH資料包。否則進行步驟3.
3.如果接收者使用獨立的空間維護AH和ESP，那麼就基于｛SPI｝搜尋SAD，否則基于｛SPI，協定｝搜尋SAD。如果存在SAD實體符合要求，那麼就處理相應的入方向AH資料包。否則丢棄封包并記錄審計事件。