組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：piex（piex    jintao@bigfoot.com）
譯文發布時間：2002-01-18
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必須保留本文檔的翻譯及版權信息。

Network Working Group                                        R. Atkinson
Request for Comments: 1827                     Naval Research Laboratory
Category: Standards Track                                    August 1995

IP封裝安全載荷（ESP）

本備忘錄的狀態
這篇文檔詳述了Internet community中的一個internet標準棧協議，并且請求對于這個標準棧協議的討論和建議。標準化的狀態和協議的狀態請參考internet官方協議標準（std1）. 發布本備忘錄的發放不受限制。


摘要
此篇文檔描述了IP封裝安全載荷（ESP）。ESP是為IP數據包提供完整性和機密性的一種機制。在某些情況下也可用于IP數據包的安全認證。此機制可用于IPv4和IPv6。

1 介紹
  ESP是為IP數據包提供完整性和機密性的一種機制。它也能在特定的認證算法和算法模型的基礎上提供身份認證。ESP不提供流量分析的不可否認性和保護性服務。IP認證頭（AH）使用一定的認證算法[Atk95b]可以實現不可否認性服務。IP認證頭可以和ESP結合起來使用以提供身份認證的服務。用戶如果只想實現信息完整性和身份認證服務而不想實現機密性服務，則可以選擇IP認證頭（AH）協議來取代ESP。本文假設讀者已經熟悉相關文檔“IP安全架構”，它定義了用于IPv4和IPv6的總的INTERNET層的安全架構，并且提供了對于這篇描述文檔的重要背景。[Atk95a]

1． 1綜述
IP封裝安全載荷（ESP）試圖提供信息的機密性和完整性服務，方法是將被保護的數據加密并把被加密的數據放入IP封裝安全載荷（ESP）的數據部分。根據用戶的安全需求，此機制可以被用于加密傳輸層段（例如：TCP,UDP,ICMP,IGMP）,也可用來加密一個完整的IP數據包。為了保證完整原始數據包的機密性，封裝被保護的數據是必須的。

在共享系統中使用此規范會增長IP協議處理的代價。使用此規范也會增長信息通訊的延遲時間。延遲時間的增長主要是由包含在一個ESP中的每個IP數據包都需要的加密和解密過程引起的。

在隧道模式的ESP中，原始的IP數據包被放置于ESP的被加密部分，然后將完整的ESP幀放入一個數據包內，此數據包有一個未加密的IP報頭。未加密的IP數據報頭中的信息被用來將安全數據包從源地址發送到目的地址。一個未加密的IP路由報頭可以被包括在IP報頭和ESP之間。

在傳輸模式的ESP中，ESP頭被插入到IP數據包中傳輸層協議報頭（例如，TCP,UDP,或者	ICMP）的前面。在此模式下，因為沒有加密的IP報頭或者IP選項所以帶寬被保護。

在IP中，一個IP認證頭可以用來作為一個未加密信息報的頭部或者在一個傳輸模式的ESP信息報中位于IP報頭和ESP報頭之間，也可以作為一個報頭位于一個隧道模式的ESP信息報的加密部分。當一個AH同時出現在純文本的IP報頭和單個信息包的隧道模式ESP頭之內時，未加密的IPv6認證主要被用于向未加密的IP頭的內容提供保護，加密的認證頭被用于向加密的IP信息包提供報頭驗證。本文稍后詳述。

IP封裝安全載荷的組織結構與別的IP有效載荷有很大不同。ESP有效載荷的第一個成分是有效載荷的未加密域。第二個部分是加密的數據。未加密ESP報頭的域通知預期的接收者怎樣合適的解密和處理加密的數據。被加密的數據部分包括用于安全協議的受保護域以及加密封裝的IP數據包。

安全聯合的概念是ESP的重要的基礎部分。它在相關文檔“Security Architecture for the Internet Protocol” 被詳細的描述。執行者應該在讀此篇文檔之前讀那篇文檔。

1．2 需求的術語定義
    在本文檔中，通常被大寫的單詞用來定義一個特定的要求（REQUIREMENT）的重要程度。這些單詞是：

－MUST（必須）
這個單詞和近意詞"REQUIRED"意謂它們所指的項在規范中是絕對必須,不可缺少的。

  －SHOULD(應該)
    此單詞和近意詞“RECOMMENDED"修飾的條款，在特定的環境下，由于某些合理原因存在，是可以忽略的。但是此條款的完整含義必須被理解，在采取不同的方針之前，應該特別重視所處的場合。

     －MAY（可以）
    這個單詞和它的近意詞“OPTIONAL"意謂著它們所指的特定項確實是可選的。一個產品提供商（vendor）可能為了一個特別的商務用途的需要或者增強它的產品（例如：別的商家可能忽略此項目）而將此項條目包括進來。

2 密鑰管理
  密鑰管理是IP安全架構的一個重要部分。然而，一個特定的密鑰管理協議并沒有包括在本篇說明文檔中，這是因為長期以來，在各種公開的著作中，涉及到密鑰管理的算法和協議存在很多細微的錯誤。IP盡量分離密鑰管理機制和安全協議機制之間的關聯。在密鑰管理機制和安全協議機制之間的唯一聯系是安全參數索引（SPI），SPI在后面將更詳盡的描述。這種分離允許幾種不同的密鑰管理機制被使用。更重要的是，它允許在密鑰管理協議被更換或者修正的時候，安全協議機制不會受到過度的影響。因此，一個IP的密鑰管理協議不會在本文檔中詳述。在IP安全架構中將會更詳盡的描述密鑰管理并且詳述用于IP的密鑰管理需求。參考文獻[Atk95a]包容了這些密鑰管理需求。
  
密鑰管理機制被用于協商每個安全關聯中的參數。這些參數不僅包括密鑰本身而且還包括其他的信息（例如：加密算法和加密模型，安全分類的級別，等等），所有的這些都將被通信的雙方所使用。密鑰管理協議的實現通常創造和維護一個邏輯表，此表中包含了每個當前安全關聯中的參數。一個ESP的實現通常需要通過讀安全參數表來決定如何處理每一個包含ESP的數據包（例如：采取哪個算法或模型以及何種密鑰）。

3 封裝安全有效載荷的語法

封裝安全有效載荷（ESP）可能出現在IP頭之后和最后傳輸層協議之前的任何地方。IANA（Internet Assigned Numbers Authority，負責全球Internet的IP地址編號分配的機構）已經分配了協議號50給ESP[STD-2]。ESP 頭前的那個報頭總是在它的NEXT Header（IPV6）或者協議（IPV4）域中寫入值50。ESP由一個未加密的報頭和加密的數據部分組成。加密的數據既包括被保護的ESP 頭也包括被保護的用戶數據。而用戶數據或者是一個完整的IP 數據包，也可能僅僅是一個上層協議部分（例如： TCP 或者 UDP）。一個安全數據包的高層圖表如下所示：


  |<--        Unencrypted              -->|<----    Encrypted   ------>|
  +-------------+--------------------+------------+---------------------+
  | IP Header   | Other IP Headers   | ESP Header | encrypted data      |
  +-------------+--------------------+------------+---------------------+

  ESP報頭的更詳細的圖表如下所示

  +-------------+--------------------+------------+---------------------+
  |             Security Association Identifier (SPI), 32 bits          |
  +=============+====================+============+=====================+
  |             Opaque Transform Data, variable length                  |
  +-------------+--------------------+------------+---------------------+


加密和認證算法以及與它們相關聯的不透明變換數據的精確格式被稱作變換（“transform”）。ESP格式被設計成為支持新的變換，從而可以在將來支持新的或者額外的加密算法。變換被自身詳細說明，而不是在此篇文檔的主體部分被詳述。用于與IP一起使用的強制轉換被定義在一個獨立文檔中[KMS95]。別的可選變換存在于別的說明文檔中，附加的變換可能在將來定義。

3．1 封裝安全有效載荷的域

SPI 是一個32位的偽隨機值，它用來確定數據包的安全關聯。如果不建立安全關聯，SPI 域的值就應該是0x00000000。一個SPI 類似于別的安全協議中的SAID。因為 在此處SPI 的語意和別的安全協議中的SAID不是完全相同，所以名字不一樣。

SPI的值的集合中，從0x00000001到 0x000000FF 是被保留給 IANA 的，以用于將來的使用。除非在一篇 RFC 中公開的說明一個特定的被保留的 SPI 值已經被分配，否則保留的 SPI 值通常不能被分配。
SPI 是唯一的強制的不受約束的變換域。特定的變換可能有別的對于變換來說是獨有的域。變換在此篇文檔中不會被詳述。

3．2  ESP 的安全標記
加密的 IP 數據包不必要并且通常也不包含任何明確的安全標簽因為 SPI 指明了敏感級別。這是對當前 IPv4 實施方案的一個改進，當前的實施方案通常在分割模式工作站以及別的需要安全標簽的系統中使用一個明確的敏感標簽[Ken91] [DIA]。在一些情況下，用戶可以選擇在使用 ESP 提供的不明確的標簽的同時添加一個明確的標簽（例如： RFC1108 中定義的IPSO 標簽，可以在IPv4中被使用）。明確標簽的選項能夠被定義與 IPv6 一起使用（例如，使用 IPv6 端到端的選項報頭或者IPv6 的逐跳路由的可選報頭）。ESP 的執行可以同時支持非明確的標簽和明確的標簽，但是不是必須要求支持明確標簽。ESP 在要求提供多級安全的系統中實施的時候必須支持不明確的標簽。

4 封裝安全協議的處理過程

此節描述了當 ESP 在兩個互連的實體間使用時實施的步驟。多播與單播的僅在密鑰管理上不同（細節請看看上面的 SPI定義）。ESP 有兩種使用模式。第一種被稱做隧道模式，在ESP內封裝一個完整的 IP數據包。第二個模式稱為傳輸模式，在ESP內封裝一個傳輸層的幀（如UDP,TCP）。術語傳輸模式一定不能被誤解僅限于TCP 和UDP。例如，一個IMCP 消息在不同環境下既可以通過傳輸模式發送也可以通過隧道模式發送。ESP 的處理過程發生在發送時的 IP 分割之前以及接受時的IP重新組合之后。此節描述了兩種模式的協議處理過程。

4．1 隧道模式下的 ESP

隧道模式下的 ESP報頭跟隨在所有的端到端的報頭之后（例如，認證頭，如果在明文中呈現的話），在它后面就緊接著一個被隧道化的 IP數據包。發送方將原始的IP數據包封裝進ESP，至少使用發送方的用戶ID以及目的地址來定位正確的安全關聯，然后運用合適的加密變換。如果使用基于主機的密鑰產生機制，那么對于一個特定的目的地址來說，一個給定系統上所有的發送用戶擁有相同的安全關聯。如果沒有任何一個密鑰已經被建立，那么密鑰管理機制要為這個連接會話產生一個加密密鑰，此過程要在ESP被使用之前發生。此后，（加密的）ESP作為最終的有效載荷被封裝入一個未加密的IP數據包。如果執行嚴格的紅黑分割，那么可選的載荷和明文IP數據報頭中的地址以及其他的信息可能會和包含在原始數據包（現在已經被加密和封裝了）中的值有所不同。

接收方剝去明文IP報頭以及明文的可選IP載荷（如果有）并且丟棄它們。接下來，接受方結合使用目的地址和SPI值來定位這個信息包的正確的會話密鑰，然后使用這個密鑰來解密這個ESP。

如果對于此會話不存在一個合法的安全關聯（例如，接受方沒有密鑰），接受方必須丟棄這個加密的ESP 并且這個錯誤必須被記錄在系統日志或者審核日志當中。這個系統日志或審核日志應該包括SPI的值，時間，明文的發送地址，明文的目的地址，以及明文的信息流的ID。日志條目也可以包括別的認證數據。接受方可能不想立即通知發送方有錯，因為這樣極有可能被拒絕服務攻擊模式所利用。

如果解密成功，原始的IP數據包被從ESP（已被解密）移出。然后，這個原始的數據包就按照通常的IP協議規范來處理。在要求提供多級安全安全的系統中（例如，一個B1級或分割模式的工作站）,基于接受進程的安全級別以及與安全關聯相關的安全級別，附加的合適強制訪問控制必須被實施。如果這些強制訪問控制失敗了，那么這個信息包應該被丟棄，同時應該使用特定的實施過程將錯誤錄入日志。

4．2 傳輸模式下的ESP
在傳輸模式下，ESP 頭被放置在端到端的頭部之后（例如，認證頭），它后面緊接著的是一個傳輸層的頭（例如：UDP ,TCP, ICMP）。

發送者將原始的傳輸層（例如：UDP,TCP,ICMP）幀封裝入ESP，至少使用發送的用戶ID和目的地址來定位合適的安全關聯，然后運用合適的加密變換。如果使用基于主機的密鑰產生機制，那么對于一個特定的目的地址來說，一個給定系統上所有的發送用戶擁有相同的安全關聯。如果沒有任何一個密鑰已經被建立，那么密鑰管理機制要為這個連接會話產生一個加密密鑰，此過程要在ESP被使用之前發生。此后，（加密的）ESP作為最終的有效載荷被封裝入一個未加密的IP數據包。

接收方的處理明文IP頭和明文的可選IP 頭（如果有）并且暫時存儲相關信息（例如，源地址和目的地址，信息流ID，路由選項頭），接受方結合使用目的地址和SPI值來定位這個信息包的正確的會話密鑰，然后使用已為此次通信而建立的會話密鑰將ESP 解密。 

如果沒有用于此會話的密鑰或者解密的嘗試失敗，接受方必須丟棄這個加密的ESP 并且這個錯誤必須被記錄在系統日志或者審核日志當中。如果如此的一個失敗發生，這個系統日志或審核日志應該包括SPI的值，接受時間，明文的發送地址，明文的目的地址，以及明文的信息流的ID。日志條目也可以包括別的關于失敗的信息包的信息。如果某些原因的存在而導致解密無法正常工作，那么由此而來的數據就無法被實施中的協議引擎所分析。因此，失敗的機密通常是可以被檢測到的。

如果解密成功，原來的傳輸層（例如，UDP,TCP,ICMP）幀從ESP （已被解密）中移出。明文IP 頭信息和傳輸層頭被結合起來判別數據一個被送往哪一個應用程序。然后數據就象按照一般的IP 協議規范那樣被送給合適的應用程序。在要求提供多級安全安全的系統中（例如，一個B1級或分割模式的工作站）,基于接受進程的安全級別以及與安全關聯相關的安全級別，附加的合適強制訪問控制必須被實施。

4．3 認證
一些變換在提供機密性和信息完整性功能的同時也提供認證功能。當這些變換不被使用時，認證報頭可能與封裝安全載荷一起使用。將認證報頭與ESP結合使用有兩種不同的方法，依賴這兩種方法數據被認證。認證頭的位置闡明了哪一個數據集合正在被認證。

在第一種方法中，被接受的數據包整個被認證，包括它的加密部分和未加密部分。而只有ESP報頭之后的數據是機密的。在此方法中，，發送方首先運用ESP 封裝被保護的數據，然后將明文的IP報頭置于ESP報頭和加密的數據之前。最后，按照通常的方法利用已得出的數據包計算出IP 認證報頭。接收時，接收者首先使用通常的IP 認證頭處理過程對整個數據包進行身份認證。然后，如果身份認證成功，那么就使用通常的IP ESP 處理過程來進行解密。如果解密成功，那么得到的數據就被傳遞給上一層。


如果認證過程僅被應用于隧道模式ESP保護下的數據，那么此IP 認證頭通常會被放置在被保護的數據報之內。然而，如果是使用傳輸模式ESP，IP 認證報頭被放在ESP報頭的前面并且根據整個IP 數據報來計算它。

如果認證報頭被封裝在一個隧道模式的 ESP報頭之內并且兩個報頭都有與它們相關聯的安全分類級別，而這兩個安全分類級別不是相同的，那么一個錯誤就會發生。這個錯誤應該被上面描述的程序過程記錄在系統日志或者審核日志中。一個認證報頭定位在ESP報頭之外的時候，如果它們有不同的安全分類級別并不一定是個錯誤。這可能是合理的因為在數據被ESP加密之后，明文的IP 報頭可能有一個不同的分類級別。

5 一致性要求
符合或與此篇說明文檔相一致的具體實現必須完全執行本篇文章描述的報頭，必須支持伴隨此報頭的手工密鑰發布，必須滿足“Internet協議安全架構”[Atk95]的所有需求,必須支持DES CBC（在伴隨文檔中被詳述，題目是：The ESP DES-CBC Transform[KMS95]）的使用。實施者也可以實現別的ESP變換。實施者應該查詢最近版本的“IAB Official Standards”RFC作為對于本篇文檔狀態的更深層的指導。

6 安全考慮
此篇文檔討論了一個隨IP 使用的安全機制。此機制不是一個萬能的良方，但在創建一個安全的互聯網的時候它確實提供了一個重要而有用的部分。

對于一個使用分組鏈接算法并且缺乏一個健壯的完整性機制的ESP來說，它的加密變換在受到cut-and-paste攻擊（見Bellovin的描述文章）時是脆弱的，除非認證報頭總是出現在使用ESP變換的信息包之內，否則不應該被使用。[Bel95]