rfc2406.txt

很多RFC的中文文档

   类似于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匹配，那么数据报有效，可以被接收。如果测试失败，接收方