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有效载荷字段）：
               - 传送模式