組織：中國互動出版網(wǎng)（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）
譯文發(fā)布時間：2002-01-18
版權(quán)：本中文翻譯文檔版權(quán)歸中國互動出版網(wǎng)所有。可以用于非商業(yè)用途自由轉(zhuǎn)載，但必須保留本文檔的翻譯及版權(quán)信息。

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

IP封裝安全載荷（ESP）

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


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

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

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

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

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

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

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

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

安全聯(lián)合的概念是ESP的重要的基礎(chǔ)部分。它在相關(guān)文檔“Security Architecture for the Internet Protocol” 被詳細的描述。執(zhí)行者應(yīng)該在讀此篇文檔之前讀那篇文檔。

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

4 封裝安全協(xié)議的處理過程

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

4．1 隧道模式下的 ESP

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

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

如果對于此會話不存在一個合法的安全關(guān)聯(lián)（例如，接受方?jīng)]有密鑰），接受方必須丟棄這個加密的ESP 并且這個錯誤必須被記錄在系統(tǒng)日志或者審核日志當(dāng)中。這個系統(tǒng)日志或?qū)徍巳罩緫?yīng)該包括SPI的值，時間，明文的發(fā)送地址，明文的目的地址，以及明文的信息流的ID。日志條目也可以包括別的認證數(shù)據(jù)。接受方可能不想立即通知發(fā)送方有錯，因為這樣極有可能被拒絕服務(wù)攻擊模式所利用。

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

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

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

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

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

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

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

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


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

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

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

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

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