RFC2406 IP 封装安全有效载荷 (ESP)

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
译者：sword（sword  zxl1025@chinese.com）
译文发布时间：2001-5-11
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保留
本文档的翻译及版权信息。


Network Working Group                                            S. Kent
Request for Comments: 2406                                      BBN Corp
Obsoletes: 1827                                              R. Atkinson
Category: Standards Track                                  @Home Network
                                                           November 1998

IP 封装安全有效载荷 (ESP)
(RFC 2406 IP Encapsulating Security Payload (ESP))

本文档状态：

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

版权声明

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

目录列表

   1. 介绍..................................................2
   2. 封装安全有效载荷分组格式..................3
      2.1  安全参数索引................................4
      2.2  序列号 .........................................4
      2.3  有效载荷数据.............................................5
      2.4  填充（供加密使用）.................................5
      2.5  填充长度...............................................7
      2.6  下一个头..............................................7
      2.7  验证数据......................................7
   3. 封装安全协议处理....................7
      3.1  ESP头定位......................................7
      3.2  算法..............................................10
         3.2.1  加密算法..............................10
         3.2.2  验证算法..........................10
      3.3  出站分组处理..............................10
         3.3.1  SA查找........................11
         3.3.2  分组加密..................................11
         3.3.3  序列号产生.........................12
         3.3.4  完整性校验值计算..................12
         3.3.5  分片......................................13
      3.4  入站分组处理...............................13
         3.4.1  重组.........................................13
         3.4.2  SA查找........................13
         3.4.3  序列号确认.......................14
         3.4.4  完整性校验值确认.................15

         3.4.5  分组解密..................................16
   4. 审核.....................................................17
   5. 一致性要求.....................................18
   6. 安全考虑事项......................................18
   7. 与 RFC 1827的不同....................................18
   致谢................................................19
   参考书目......................................................19
   Disclaimer......................................................20
   作者信息..............................................21
   版权声明........................................22

1.  介绍

   封装安全有效载荷头在IPv4和IPv6中提供一种混合的安全服务。ESP可以单独应用，与IP
验证头(AH)结合使用，或者采用嵌套形式，例如，隧道模式的应用(参看 "Security Architecture for 
the Internet Protocol" [KA97a]，下面使用“安全架构文档”代替)。安全服务可以在一对通信主机
之间，一对通信的安全网关之间，或者一个安全网关和一台主机之间实现。在各种网络环境中如
何使用ESP和AH的详细细节，参看安全架构文档。

   ESP头可以插在IP头之后、上层协议头之前(传送模式)，或者在封装的IP头之前(隧道模式)。
下面将详细介绍这些模式。

   ESP提供机密性、数据源验证、无连接的完整性、抗重播服务(一种部分序列完整性的形式)
和有限信息流机密性。提供的这组服务由SA建立时选择的选项和实现的位置来决定，机密性的
选择与所有其他服务相独立。但是，确保机密性而不保证完整性/验证(在ESP或者单独在AH中)
可能使信息易受到某种活动的、破坏机密性服务的攻击(参看[Bel96])。数据源验证和无连接的完
整性(下面统一称作“验证”引用它们)是相互关联的服务，它们作为一个选项与机密性(可选择的)
结合提供给用户。只有选择数据源验证时才可以选择抗重播服务，由接收方单独决定抗重播服务
的选择。（尽管默认要求发送方增加抗重播服务使用的序列号，但只有当接收方检查序列号，服
务才是有效的。）信息流机密性要求选择隧道模式，如果在安全网关上实现信息流机密性是最有
效的，这里信息聚集能够掩饰真正的源-目的模式。注意尽管机密性和验证是可选的，但它们中
必须至少选择一个。

   假定读者熟悉安全架构文档中描述的术语和概念。特别是，读者应该熟悉ESP和AH提供的
安全服务的定义，SA定义，ESP可以和验证（AH）头结合使用的方式，以及ESP和AH使用
的不同密钥管理选项。（至于最后一项，ESP和AH要求的当前密钥管理选项是通过IKE进行的
手工建立密钥和自动建立密钥[HC98]。）
 
   关键字MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,SHOULD NOT, 
RECOMMENDED, MAY,和OPTIONAL, 当它们出现在本文档时，由RFC2119中的描述解释它
们的含义[Bra97]。

2.  封装安全有效载荷分组格式

   ESP头紧紧跟在协议头（IPv4，IPv6，或者扩展）之后，协议头的协议字段（IPv4）将是50，
或者协议的下一个头(IPv6，扩展)字段[STD-2]值是50。


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
|               安全参数索引              (SPI)                 | ^Auth.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
|                      序列号                                   | |erage
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
|                    有效载荷数据* (可变的)                     | |   ^
~                                                               ~ |   |
|                                                               | |Conf.
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
|               |     填充    (0-255 bytes)                     | |erage*
+-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |   |
|                               |  填充长度     | 下一个头      | v   v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
|                 验证数据            (可变的)                  |
~                                                               ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  *如果加密同步数据，例如初始化向量（IV，参看2.3节），包含在有效载荷字段中，通常它本
身并不加密，虽然常常把它作为密文的一部分。

   下面小节定义了头格式中的字段。“可选项”意味着如果没有选择它，该字段被忽略。即它既
不被包含在传送的分组中，也不会在完整性校验值(ICV，参看2.7)计算中出现。建立SA时决定
是否选择某个选项，因此ESP分组的格式对于给定的SA是确定的，整个SA存活期间也是确定
的。相对而言，“强制性”字段总是出现在ESP分组格式中，对所有SA均如此。 

2.1  安全参数索引SPI

   SPI是一个任意的32位值，它与目的IP地址和安全协议（ESP）结合，唯一地标识这个数据
报的SA。从1至255的这组SPI值是由Internet Assigned Numbers Authority (IANA)保留给将来
使用的；除了分配的SPI值的使用由RFC指定，否则，一般IANA不会分配保留的SPI值。通
常在建立SA时目的系统选择SPI（详细内容请参看安全架构文档）。SPI字段是强制性的。

   SPI的值为0是保留给本地、特定实现使用的，不允许在线路上发送。例如，密钥管理实现
可以使用SPI的0值表示当IPsec实现要求它的密钥管理实体建立新SA，但SA仍然没有建立时，
“没有SA存在”。

2.2  序列号Sequence Number

   这个无符号的、32位字段包含一个单调递增的计数器值（序列号）。它是强制性的，即使接
收方没有选择激活一个特定SA的抗重播服务，它也总是存在。序列号字段由接收方处理，即发
送方必须总是传输这个字段，但接收方不需要对其操作（参看下面“入站分组处理”中序列号确
认的讨论）。

   发送方的计数器和接收方的计数器在一个SA建立时被初始化为0。（使用给定SA发送的第
一个分组的序列号1；序列号如何产生的细节参看3.3.3节）如果激活抗重播服务（默认地），传
送的序列号必须决不允许循环。因此，在SA上传送第2的32次方个分组之前，发送方计数器
和接收方计数器必须重新置位（通过建立新SA和获取新密钥）

2.3  有效载荷数据Payload Data

   有效载荷数据是变长字段，它包含下一个头字段描述的数据。有效载荷数据字段是强制性的，
它的长度是字节的整数倍。如果加密有效载荷的算法要求加密同步数据，例如初始化向量（IV），
那么这个数据可以明确地装载在有效载荷字段。任何要求这样明确的、每分组同步数据的加密算
法必须指出同步数据的长度、结构和位置，这是指定ESP中算法如何使用的某个RFC的一部分。
如果这种同步数据是隐式的，派生数据的算法必须是RFC的一部分。

   注意关于确保IV存在时（实际）密文对齐：

           o 对于一些基于IV模式的操作，接收方把IV作为密文的开始，直接把IV传给算
法。这些模式中，（实际）密文是否开始对齐对于接收方并不重要。
           o 某些情况下，接收方从密文中单独读入IV。此时，算法规范必须解决（实际）密
文对齐如何实现。

2.4  填充(供加密使用)

   几种因素要求或者激活填充字段的使用。
           o 如果采用的加密算法要求明文是某个数量字节的倍数，例如块密码（block cipher）
的块大小，使用填充字段填充明文（包含有效载荷数据、填充长度和下一个头字段，以及填充）
以达到算法要求的长度。

           o 不管加密算法要求如何，也可以要求填充字段来确保结果密文以4字节边界终止。
特别是，填充长度字段和下一个头字段必须在4字节字内右对齐，如上图所示的ESP分组格式，
从而确保验证数据字段（如果存在）以4字节边界对齐。

           o除了算法要求或者上面提及的对齐原因之外，填充字段可以用于隐藏有效载荷实
际长度，支持（部分）信息流机密性。但是，包含这种额外的填充字段占据一定的带宽，因而小
心使用。

   发送方可以增加0至255个字节的填充。ESP分组的填充字段是可选的，但是所有实现必须
支持填充字段的产生和消耗。
  
           a. 为了确保加密位是算法块大小（上面第一个加重号）的倍数，填充计算应用于除
IV之外的有效载荷数据、填充长度和下一个头字段。

           b. 为了确保验证数据以4字节边界对齐（上面第二个加重号），填充计算应用于包
含IV的有效载荷数据、填充长度和下一个头字段。

   如果需要填充字节，但是加密算法没有指定填充内容，则必须采用下列默认处理。填充字节
使用一系列（无符号、1字节）整数值初始化。附加在明文之后的第一个填充字节为1，后面的
填充字节按单调递增：1,2,3,…。当采用这种填充方案时，接收方应该检查填充字段。（选择这种
方案是由于它相对简单，硬件实现容易。在没有其他完整性措施实施情况下，如果接收方检查解
密的填充值，这种方案粉碎了某种形式的“剪切和粘贴”攻击，提供有限的保护。）
  
   任何要求填充字段但不同于上述默认方法的加密算法，必须在一个指定ESP中算法如何使用
的RFC中定义填充字段内容（例如，0或者随机数）和所有要求接收方对这些填充字节的处理。
这种情况下，填充字段的内容将由相应算法RFC中定义和选择的加密算法和模式决定。相关的
算法RFC可以指定接收方必须检查填充字段或者接收方必须通知发送方接收方如何处理填充字
段。

2.5  填充长度Pad Length

   填充长度字段指明紧接其前的填充字节的个数。有效值范围是0至255，0表明没有填充字节。
填充长度字段是强制性的。

2.6  下一个头

   下一个头是一个8位字段，它标识有效载荷字段中包含的数据类型，例如，IPv6中的扩展头
或者上层协议标识符。该字段值从Internet Assigned Numbers Authority (IANA)最新“Assigned 
Numbers” [STD-2] RFC 定义的IP协议号集当中选择。下一个头字段是强制性的。

2.7  验证数据

   验证数据是可变长字段，它包含一个完整性校验值（ICV），ESP分组中该值的计算不包含验
证数据本身。字段长度由选择的验证函数指定。验证数据字段是可选的，只有SA选择验证服务，
才包含验证数据字段。验证算法规范必须指定ICV长度、验证的比较规则和处理步骤。
   
3.  封装安全协议处理

3.1  ESP 头定位

   类似于AH，ESP 有两种使用方式：传送模式或者隧道模式。前者仅在主机中实现，提供对
上层协议的保护，不提供对IP头的保护。（传送模式中，注意安全架构文档中定义的“堆栈中的
块”或者“线路中的块”实现，入站和出站IP分片可能要求IPsec实现执行额外的IP重组/分片，
以便遵照这个规范，提供透明IPsec支持。当存在多个接口时，在这些实现内部执行这些操作要
特别小心。）

   传送模式中，ESP插在IP头之后，上层协议之前，例如TCP，UCP，ICMP等，或者在任何
已经插入的IPsec头之前。IPv4中，意指把ESP放在IP头（和它包含的任何其他选项）之后, 但
是在上层协议之前。（注意术语“传输”模式不应该曲解为把它的应用限制在TCP和UDP中。
例如ICMP报文可能使用“传输”模式或者“隧道”模式发送。）下面数据报图示了典型IPv4分
组中ESP传送模式位置，以“表示出外形上尖锐对照”为基础。（“ESP尾部”包含所有填充，
加填充长度和下一个头字段。）


                 ESP应用前
            ----------------------------
      IPv4  |原始IP头    |     |      |
            |(所有选项)   | TCP | 数据 |
            ----------------------------

                 ESP应用后
            -------------------------------------------------
      IPv4  |原始IP头    | ESP |     |      |   ESP   | ESP|
            |(所有选项   )| 头部| TCP | 数据 |  尾部   |验证|
            -------------------------------------------------
                                |<----- 已加密    ---->|
                          |<------      已验证   ----->|

    IPv6中，ESP被看作端到端的有效载荷，因而应该出现在逐跳，路由和分片扩展头之后。
目的选项扩展头既可以在ESP头之前，也可以在ESP头之后，这由期望的语义决定。但是，因
为ESP仅保护ESP之后的字段，通常它可能愿意把目的选项头放在ESP头之后。下面数据报图
示了典型IPv6分组中ESP传送模式位置。 
                     ESP应用前
            ---------------------------------------
      IPv6  |             | 如果有   |     |      |
            | 原始IP头   |扩展头    | TCP | 数据 |
            ---------------------------------------

                     ESP应用后
            ---------------------------------------------------------
      IPv6  | 原始 |逐跳，     目的* |   |目的 |   |    | ESP   | ESP|
            |IP 头 |路由，分片       |ESP|选项*|TCP|数据|尾部   |验证|
            ---------------------------------------------------------
                                         |<---- 已加密     ---->|
                                     |<---- 已验证         ---->|

                    * =如果存在，应该在ESP之前，ESP之后，或者ESP和AH头以各种模
式组合。IPsec架构文档描述了必须支持的SA组合。

   隧道模式ESP可以在主机或者安全网关上实现。ESP在安全网关（保护用户传输流量）实现
时必须采用隧道模式。隧道模式中，“内部”IP头装载最终的源和目的地址，而“外部”IP头可
能包含不同的IP地址，例如安全网关地址。ESP保护整个内部IP分组，其中包括整个内部IP
头。相对于外部IP头，隧道模式的ESP位置与传送模式中ESP位置相同。下面数据报图示了典
型IPv4和IPv6分组中ESP隧道模式的位置。

            -----------------------------------------------------------
      IPv4  | 新IP头*    |     | 原始IP头 *   |   |    | ESP   | ESP|
            |(所有选项)   | ESP | (所有选项)    |TCP|数据|尾部   |验证|
            -----------------------------------------------------------
                                |<--------- 已加密    ---------->|
                          |<----------- 已验证        ---------->|

            ------------------------------------------------------------
      IPv6  | 新 * |新 扩展 |   | 原始*|原始扩展 |   |    | ESP   | ESP|
            |IP 头 | 头  *  |ESP|IP 头 | 头   *  |TCP|数据|尾部   |验证|
            ------------------------------------------------------------
                                |<--------- 已加密    ----------->|
                            |<---------- 已验证        ---------->|

               * = 如果存在，外部IP头/扩展的结构和内部IP头/扩展的修改在下面讨论。

3.2  算法

   强制实现算法在第5节描述，“一致性要求”。但也可以支持其他算法。注意尽管机密性和验
证是可选的，但是至少要从这两种服务中选择其一，因此相应的两种算法不允许同时为NULL。

3.2.1  加密算法

   采用的加密算法由SA指定。ESP使用对称加密算法。因为到达的IP分组可能失序，每个分
组必须携带所有要求的数据，以便允许接收方为解密建立加密同步。这个数据可能明确地装载在
有效载荷字段，例如作为IV（上面描述的），或者数据可以从分组头推导出来。因为ESP准备了
明文填充，ESP采用的加密算法可以显示块或者流模式特性。注意因为加密（机密性）是可选的，
这个算法可以为“NULL”。 

3.2.2  验证算法

   ICV计算使用的验证算法由SA指定。点对点通信时，合适的验证算法包括基于对称加密算
法（例如DES）的或者基于单向散列函数（例如MD5或SHA-1）的键控消息鉴别码（MAC）。
对于多点传送通信，单向散列算法与不对称数字签名算法结合使用比较合适，虽然目前性能和空
间的考虑阻止了这种算法的使用。注意验证是可选的，这个算法可以是“NULL”。

3.3  出站分组处理

   传送模式中，发送方把上层协议信息封装在ESP头/尾中，保留了指定的IP头（和IPv6中所
有IP扩展头）。隧道模式中，外部和内部IP头/扩展头以各种方式相关。封装处理期间外部IP
头/扩展头的构建在安全架构文档中描述。如果安全策略要求不止一个IPsec头扩展，安全头应用
的顺序必须由安全策略定义。

3.3.1  SA查找

   只有当IPsec实现确定与某个调用ESP处理的SA相关联时，ESP才应用于一个出站分组。
确定对出站分组采取哪些IPsec处理的过程在安全架构文档中描述。

3.3.2  分组加密

   在本节中，由于格式化的含意，我们依据经常采用的加密算法来讲述。需要理解采用NULL
加密算法提供的“没有机密性”。因此发送方：
       1. 封装（到ESP有效载荷字段）：
               - 传送模式 –只有原始上层协议信息。
               - 隧道模式 – 整个原始IP数据报。
       2. 增加所有需要的填充。
3. 使用SA指明的密钥，加密算法，算法模式和加密同步数据（如果需要）加密结果。       
- 如果指出显式加密同步数据，例如IV，它经由算法规范输入到加密算法中，并放在有
效载荷字段中。
       - 如果指出隐式加密同步数据，例如IV，它被创建并经由算法规范输入加密算法。

   构建外部IP头的确切步骤依赖于模式（传输或者隧道），并在安全架构文档中描述。

   如果选择验证，验证之前首先执行加密，而加密并不包含验证数据字段。这种处理顺序易于
在分组解密之前，接收方迅速检测和拒绝分组重播或伪造分组，因而潜在地降低拒绝服务攻击的
影响。同时它也考虑了接收方并行分组处理的可能性，即加密可以与验证并发执行。注意因为验
证数据不受加密保护，必须采用一种键控的验证算法计算ICV。
    
3.3.3  序列号产生

   当SA建立时，发送方的计数器初始化为0。发送方为这个SA增加序列号，把新值插入到序
列号字段中。采用给定SA发送的第一个分组具有序列号1。

   如果激活抗重播服务（默认），发送方核查确保在序列号字段插入新值之前计数器没有循环。
换言之，发送方不允许在一个SA上发送一个引起序列号循环的分组。传输一个可能导致序列号
溢出的分组的尝试是可审核事件。（注意这种序列号管理方式不需要使用模运算）

   发送方假定抗重播服务是一种默认支持，除非接收方另外通告（参看3.4.3）。因此，如果计
数器已经循环，发送方将建立新SA和密钥（除非SA被配置为手工密钥管理）。

   如果抗重播服务被禁止，发送方不需要监视或者把计数器置位，例如，手工密钥管理情况下
（参看第5节）。但是，发送方仍然增加计数器的值，当它达到最大值时，计数器返回0开始。

3.3.4  完整性校验值计算

   如果SA选择验证，发送方在ESP分组上计算ICV但不包含验证数据。因此SPI、序列号、
有效载荷数据、填充（如果存在）、填充长度和下一个头字段都包含在ICV计算中。注意因为加
密比验证先执行，最后4个字段将是密文形式。

   一些验证算法中，ICV计算实现所使用的字节串必须是算法指定的块大小的倍数。如果这个
字节串长度与算法要求的块大小不匹配，必须在ESP分组末端添加隐含填充，（下一个头字段之
后）在ICV计算之前添加。填充八位组必须是0值。算法规范指定块大小（和因此的填充长度）。
这个填充不随分组传输。注意MD5和SHA-1内部填充协定，它们被看作有1字节的块大小。

3.3.5  分片

   如果需要，IPsec实现内部ESP处理之后执行分片。因此传送模式ESP应用于整个IP数据报
（而不是IP片段）。ESP处理过的分组本身可以在途中由路由器分片，这样的片段接收方必须在
ESP处理之前重组。隧道模式时，ESP应用于一个IP分组，它的有效载荷可能是一个已分片的
IP分组。例如，安全网关或者“堆栈中的块”或者“线路上的块”IPsec实现（安全架构文档中
定义）可以把隧道模式ESP应用到这样的片段中。

   注意：传送模式—3.1节开始提及的，堆栈中的块和线路上的块实现可以由本地IP层首先重
组已分片的分组，接着应用IPsec，再把结果分组分片。

   注意：对于IPv6 –堆栈中的块和线路上的块实现，有必要查看所有扩展头来确定是否有一个
分片的头，从而决定分组是否需要在IPsec处理之前重组。

3.4  入站分组处理

3.4.1  重组

   如果要求，在ESP处理之前进行重组。如果提供给ESP处理的分组是一个IP分片，即OFFSET
字段值非0，或者MORE FRAGMENTS标志位置位，接收方必须丢弃分组；这是可审核事件。
该事件的核查日志表项应该包含SPI的值，接收日期/时间，源地址，目的地址，序列号和（IPv6）
信息流ID。

   注意：对于分组重组，当前IPv4规范不要求OFFSET字段清为0或者MORE FRAGMENTS
标志清空。为了已重组的分组由IPsec处理（与外观上看是一个分片而丢弃相对应），IP代码必
须在它重组一个分组之后完成这两件事情。 

3.4.2  SA查找

   收到一个（已重组的）包含ESP头的分组时，根据目的IP地址、安全协议（ESP）和SPI，
接收方确定适当的（不定向的）SA。（这个过程更详细的细节在安全架构文档中描述）SA指出
序列号字段是否被校验，验证数据字段是否存在，它将指定解密和ICV计算（如果适用）使用
的算法和密钥。

   如果本次会话没有有效的SA存在（例如接收方没有密钥），接收方必须丢弃分组；这是可审
核事件。该事件的核查日志表项应该包含SPI的值、接收的日期/时间、源地址、目的地址、序
列号和（IPv6）明文信息流ID。

3.4.3  序列号确认

   所有ESP实现必须支持抗重播服务，虽然可以由接收方根据每个SA激活或者禁止它的使用。
如果SA的验证服务没有激活，这项服务不允许激活。因为否则序列号字段没有进行完整性保护。
（当多个发送方控制流量到单个SA（不论目的地址是单播、广播或者组播）时，注意没有管理
这多个发送方之间传输的序列号值的措施。因此抗重播服务不应该用在多个发送方使用唯一SA
的环境中）

   如果接收方不激活SA的抗重播服务，将不对序列号进行入站检查。但是从发送方观点来看，
默认的是假定接收方激活抗重播服务。为了避免接收方做不必要的序列号监视和SA建立（参看
3.3.3），如果使用SA建立协议，例如IKE，在SA建立期间，如果接收方不提供抗重播保护，则
接收方应该通告发送方。

   如果接收方已经为这个SA激活了抗重播服务，SA接收分组计数器在SA建立时，必须初始
化为0。对于每个接收的分组，接收方必须确认分组包含序列号，并且序列号在这个SA生命期
中不重复任何已接收的其它分组的序列号。这应该是分组与某个SA匹配之后，对该分组进行的
第一个ESP检验，加快重复分组拒绝。

   通过采用滑动接收窗口拒绝分组重复。（窗口如何实现是本地事情，但是下面内容描述了实现
必须展现的功能）必须支持32位的最小窗口大小；但是首选64位窗口大小，且应该是默认使用
的。其他窗口大小（大于最小窗口）由接收方选择。（接收方不会通告发送方窗口大小。）

   窗口“右”边界代表该SA接收的最高的有效序列号值。对于序列号小于窗口“左”边界的
分组被拒绝。落入窗口内的分组依靠窗口内已接收分组列表进行检验。以使用位掩码为基础，实
现这种检验的有效手段在安全架构文档中描述。

   如果接收的分组落入窗口内且是新的，或者如果分组在窗口的右边，那么接收方进行ICV确
认。如果ICV有效性失败，接收方必须把已接收的IP数据报作为非法而丢弃；这是可审核事件。
该事件审核日志表项应该包括SPI值、接收的日期/时间、源地址、目的地址、序列号和（IPv6
中）信息流ID。只有ICV确认成功时，接收方窗口才更新。

   讨论：

      注意如果分组既在窗口内且是新的，或者在窗口外边的“右边”，接收方必须在更新序列
号窗口数据之前验证分组。

3.4.4  完整性校验值确认Integrity Check Value Verification

   如果选择验证，接收方采用指定的验证算法对ESP分组计算ICV但不包含验证数据字段，确
认它与分组验证数据字段中包含的ICV相同。计算细节下面提供。

   如果计算得来的与接收的ICV匹配，那么数据报有效，可以被接收。如果测试失败，接收方
必须作为非法而将接收的IP数据报丢弃；这是可审核事件。日志数据应该包括SPI值、接收的
日期/时间、源地址、目的地址、序列号和（IPv6中）明文信息流ID。

   讨论：

      从删除和保存ICV值（验证数据字段）开始。下一个检查除去验证数据字段之后的ESP
整个长度。如果由于验证算法的块大小而要求隐式填充，把0填充的字节直接附加到下一个头字
段之后的ESP分组尾部。执行ICV计算，采用算法规范定义的比较规则来把结果与保存的值比
较。（例如，如果ICV计算采用数字签名和单向散列，匹配过程更复杂。）

3.4.5  分组解密

   在3.3.2节“分组加密”中，由于格式化的含意，在那里我们依据经常采用的加密讲述。需要
理解使用NULL加密算法提供“非机密性”。因此，接收方：

       1. 采用SA指明的密钥、加密算法、算法模式和加密同步数据（如果存在）解密ESP有
效载荷数据、填充、填充长度和下一个头。
       - 如果指明显式加密同步数据，例如IV，则从有效载荷字段得到加密同步数据，并按照
算法规范将其输入到解密算法中。
       - 如果指明是隐式加密同步数据，例如IV，则构建本地版本IV，并按照算法规范将其输
入到解密算法中。
       2.处理所有加密算法规范中指定的填充。如果采用默认的填充方案（参看2.4节），接收
方应该在把已解密数据传送给下一层之前，以及删除填充之前，检查填充字段。
         
       3. 重新构建原始IP数据报，利用：reconstructs the original IP datagram from:
        -传送模式—原始IP头和ESP有效载荷字段中原始上层协议信息                                                 
- 隧道模式 – 隧道IP头+ESP有效载荷字段中整个IP数据报。

   重新构建原始数据报的确切步骤依赖于模式（传送或者隧道），在安全架构文档中描述。最小
程度上，IPv6环境中，接收方应该确保已解密数据是8字节对齐，使下一个头字段标识的协议
更容易进行处理。

   如果选择验证，确认和解密可以逐个或者并行实现。如果逐个实现，那么ICV验证应该首先
执行。如果并行执行，验证必须在已解密分组被传递进行更进一步处理之前完成。这种处理顺序
利于在解密分组之前，接收方迅速检测和重播分组或伪造分组拒绝，因此潜在地降低了服务拒绝
攻击的影响。

   注意：如果接收方执行解密且与验证并行，小心避免对分组访问和已解密分组重构可能的竞
争条件。

   注意解密“失败”的几种情形：Note that there are several ways in which the decryption can "fail":

        a. 已选择的SA可能不正确—由于SPI，目的地址或者IPsec协议类型字段被篡改而错
误地选择了SA。如果这样的错误把分组映射到另一个现存的SA，则它们将无法辨别已被破坏
的分组，（c情况）。篡改SPI可以通过验证的使用而被检测出来。但是，由于IP目的地址或者
IPsec协议类型字段被篡改，SA不匹配仍然可能发生。

        b. 填充长度或者填充值可能是错误的—不管是否进行验证，错误的填充长度或者填充
值可以被检测出来。

        c. 已加密的ESP分组可能被破坏—如果SA选择进行验证，这可以检测出来。

   在 (a) 或者 (c)情况下，解密操作的错误结果（一个非法IP数据报或者传送层帧）将不必要
被IPsec检测出来，这是后面协议处理的责任。

4.  审核

   不是所有实现ESP的系统实现审核。但是，如果把ESP合并到一个支持审核的系统中，那么
ESP实现必须支持审核，必须允许系统管理员激活或者禁止ESP审核。大部分而言，审核的粒
度是本地的问题。然而，本规范中标识了几个可审核事件，对于这些事件中的每一个，定义了应
该包含在审核日志中的一组最少信息，当然也可以包含额外的信息。本规范中没有明确指出的额
外事件也可以产生审核日志表项。
   
   这里没有要求接收方把任何信息传送给声称的发送方响应审核事件的检测，因为这样做可能
导致服务拒绝。

5.  一致性要求

   要求与本规范一致性或者顺应性的实现必须实现ESP语法和这里描述的处理过程，它必须遵
照安全架构文档的所有要求。如果计算ICV使用的密钥手工分发，抗重播服务的正确提供要求
发送方计数器状态的正确维护，直到密钥更新，如果计数器溢出即将发生，有可能没有自动恢复
措施。因此一个顺应实现不应该与手工键入的SA联合来提供抗重播服务。一个顺应ESP实现必
须支持下列强制实现的算法：

             - CBC模式的DES [MD97]
             - HMAC - MD5 [MG97a]
             - HMAC - SHA-1 [MG97b]
             - NULL 验证算法
             - NULL 加密算法

   因为ESP加密和验证是可选的，对两个“NULL”算法的支持要求维护与协商这些服务的方
式的一致性。注意验证和加密可以单独是“NULL”，但是不允许两者同时是“NULL”。

6. 安全考虑事项

   安全是这个协议设计的中心，因此安全考虑事项贯穿整个规范。使用IPsec协议额外的安全
相关内容在安全架构文档中讨论。

7.  与 RFC 1827的不同

   本文档在几个重要方面不同与RFC 1827 [ATK95] 。主要的不同是，本文档试图为ESP指定
一个完整的框架和上下文，而RFC 1827提供了一个“shell”，通过转换的定义来完善。转换的增
加促进ESP规范重新完善为一个更全面的文档，加入ESP上下文中提供的安全服务选项。因此，
之前在转换文档中定义的字段现在是该基础ESP规范的一部分。例如，用于支持验证（和抗重
播）的字段现在这里定义，即使该服务是可选项。
    
   支持加密的填充字段和下一个协议验证的填充字段现在也在此定义。与这些字段定义一致的
分组处理也包含在文档中。.

致谢

   Many of the concepts embodied in this specification were derived from
   or influenced by the US Government's SP3 security protocol, ISO/IEC's
   NLSP, or from the proposed swIPe security protocol.  [SDNS89, ISO92,
   IB93].

   For over 3 years, this document has evolved through multiple versions
   and iterations.  During this time, many people have contributed
   significant ideas and energy to the process and the documents
   themselves.  The authors would like to thank Karen Seo for providing
   extensive help in the review, editing, background research, and
   coordination for this version of the specification.  The authors
   would also like to thank the members of the IPsec and IPng working
   groups, with special mention of the efforts of (in alphabetic order):
   Steve Bellovin, Steve Deering, Phil Karn, Perry Metzger, David
   Mihelcic, Hilarie Orman, Norman Shulman, William Simpson and Nina
   Yuan.

参考书目

   [ATK95]   Atkinson, R., "IP Encapsulating Security Payload (ESP)",
             RFC 1827, August 1995.

   [Bel96]   Steven M. Bellovin, "Problem Areas for the IP Security
             Protocols", Proceedings of the Sixth Usenix Unix Security
             Symposium, July, 1996.

   [Bra97]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Level", BCP 14, RFC 2119, March 1997.

   [HC98]    Harkins, D., and D. Carrel, "The Internet Key Exchange
             (IKE)", RFC 2409, November 1998.

   [IB93]    John Ioannidis & Matt Blaze, "Architecture and
             Implementation of Network-layer Security Under Unix",
             Proceedings of the USENIX Security Symposium, Santa Clara,
             CA, October 1993.

   [ISO92]   ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
             DIS 11577, International Standards Organisation, Geneva,
             Switzerland, 29 November 1992.

   [KA97a]   Kent, S., and R. Atkinson, "Security Architecture for the
             Internet Protocol", RFC 2401, November 1998.

   [KA97b]   Kent, S., and R. Atkinson, "IP Authentication Header", RFC
             2402, November 1998.

   [MD97]    Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher
             Algorithm With Explicit IV", RFC 2405, November 1998.

   [MG97a]   Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within
             ESP and AH", RFC 2403, November 1998.

   [MG97b]   Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within
             ESP and AH", RFC 2404, November 1998.

   [STD-2]   Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
             1700, October 1994.  See also:
             http://www.iana.org/numbers.html

   [SDNS89]  SDNS Secure Data Network System, Security Protocol 3, SP3,
             Document SDN.301, Revision 1.5, 15 May 1989, as published
             in NIST Publication NIST-IR-90-4250, February 1990.

Disclaimer

   The views and specification here are those of the authors and are not
   necessarily those of their employers.  The authors and their
   employers specifically disclaim responsibility for any problems
   arising from correct or incorrect implementation or use of this
   specification.

作者信息

   Stephen Kent
   BBN Corporation
   70 Fawcett Street
   Cambridge, MA  02140
   USA

   Phone: +1 (617) 873-3988
   EMail: kent@bbn.com

   Randall Atkinson
   @Home Network
   425 Broadway,
   Redwood City, CA  94063
   USA

   Phone: +1 (415) 569-5000
   EMail: rja@corp.home.net

Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

 
[ Index | Search | What's New | Comments | Help ] 
RFC 2406 IP Encapsulating Security Payload (ESP)                  IP 封装安全有效载荷 (ESP)


1
RFC文档中文翻译计划