RFC 4302 IP Authentication Header(IP认证首部)（未完待续）

本备忘录状态

版权提示

摘要

目录

1.简介

        本文档假定读者熟悉因特网协议体系架构（后来被称为安全架构的文档）中的术语和概念。读者尤其应该熟悉封装安全载荷（ESP）协议和IP认证首部（AH）中的安全服务定义、安全协会的概念、ESP和AH协议协同工作的方式以及两者密钥管理的差异。

        文档中涉及的诸如MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL,等关键字的含义在RFC2119中已经给出解释。

        IP认证首部（AH）用来提供IP报文无连接完整性和数据源认证（后来称为完整性）以及防重放保护。当安全联盟（SA）建立后，防重放可以作为接受者的一个可选服务。（协议默认需要发送者增长序列号用于防重放，但是该功能只有在接收方检查序列号时才有效。）然而，为了使用扩展序列号特性，AH在SA管理协议中强制提出需求来协商这个新特性。（详见下面2.5.1节）。

        AH为IP头和下一层协议数据提供尽可能多的认证。然而，IP头中某些域在传输过程中会发生变化，报文发送者可能无法预知当报文到达接受者时这些域值会发生那些变化。AH无法对这种域值提供保护。因此，AH对IP头的保护是零散的。（见附录A）

        AH可以单独使用，也可以同IP封装安全载荷（ESP）协同应用[Ken-ESP]，或者以嵌套的方式应用（见安全架构文档[Ken-Arch]）。安全服务可以提供在一对主机之间、安全网关之间、或者安全网关和主机之间。ESP可以提供相同的放重发和相似的完整性保护，此外，它还可以提供加密服务。ESP和AH提供的完整性保护是有差异的，主要体现在保护的内容范围上。并且，除非IP首部域是由ESP封装的（例如，使用隧道模式），否则ESP不提供对IP首部任何域提供保护。如果想要了解在复杂网络中使用AH和ESP的细节信息，请参阅安全架构文档[Ken-Arch]。

2. 认证头格式

        AH头紧前面的协议头（IPv4、IPv6或者IPv6扩展）中协议（IPv4）或者下一层头（IPv6，扩展）中的值应该是51[DH98]。



        图  1.  AH格式

下列表格就是包含AH（图1列举）的域，以及在完整性计算中包含的其他域，可以用来作为被ICV覆盖的域和传输内容。



        [1] - M  = 强制的

        [2] - 参阅3.3.3节，“完整性校验值计算 ”，检查IP头域的细节。

        [3] - ICV计算之前清零（计算后显示ICV结果）

        [4] - 如果是隧道模式 ->IP 数据段

                如果是传输模式->下一层头和数据

        下列的各个章节定义了包含AH格式的各种域。这里描述的所有域都需要是强制性的，例如他们都必须采用AH格式，都需要进行完整性检查计算（ICV）（参阅2.6节和3.3.3节）。

        注意：IPsec中所有的加密程序的数据需要采用规范的网络字节序（参阅 RFC791附录），同样生成规范网络字节序的输出。IP报文同样采用网络字节序传输。

        AH不包含版本号，因此如果涉及向后兼容，两个IPsec对等体之间必须使用一种信号机制寻址以便保证AH版本的匹配，比如，IKE[IKEv2]或者不同信号通道的配置机制。

2.1. 下一层头

        下一层头是一个8bit的域，用来识别认证头后面负载的类型。这个域的取值选自因特网号码分配局（IANA）Web页中定义的一系列IP协议号。比如，4表示IPv4,41表示IPv6，6表示TCP。

2.2. 负载长度

        这个8bit的域用来指定AH占32bit（4字节为单位）的长度，减去“2”。例如，一个完整算法产生96bit的认证值，它的长度域将是“4”（3个32bit混合域加上3个32bit的ICV，再减去2）。对于IPv6，头部商都必须是多个八位位组。（注意，虽然IPv6[DH98]将AH描述为一种扩展头，但是它的长度要使用32bit作为单元，而不是其他IPv6扩展头所使用的64bit。）参阅2.6节“完整性检查值（ICV）”，关于这个域的填充描述，和3.3.3.2.1节，“ICV填充”。

2.3. 保留字段

        这个16bit的域用来保留给未来使用。发送者必须将该域清零，接收者也应该忽略该域（注意，ICV计算包括该值，但是接收者会忽略它）。

2.4. 安全参数索引（SPI）

        SPI是一个任意的32bit值，接收者用它来识别SA携带的传入数据包。对于单播SA，SPI自己就可以识别一个SA，或者也可以同IPsec协议类型配合使用（这里就是AH）。对于单播SA，SPI的值是有接收者产生的，它能否足以独立识别SA或者是否必须同IPsec协议配置使用是一个本地行为。SPI域是必须的，并且这种入方向流量到单播SA的映射机制必须被所有AH实现支持。

        如果IPsec的实现支持组播，它必须支持组播SA使用下列算法将入方向IPsec数据映射到SA。只支持单播流量的实现不必采用这种解析程序。

        在很多安全组播架构中，例如[RFC3740],一种中央组控制器/关键字服务器向组分配安全联盟SPI。这种SPI分配方式并不和关键字管理子系统协商，这样的子系统在包含组的独立终端系统里面。因此，组安全联盟和单播安全联盟可能同时使用相同的SPI 。具有组播功能的IPsec即使在存在SPI冲突的环境中也必须能够正确的解析入方向流量。   

        每个安全联盟数据库（SPD）中的实体[Ken-Arch]必须指明SA查找除了使用SPI之外，还是否使用目的地址，目的地址和源地址，IP 地址。组播SA查询不使用这个协议域。每个入方向IPsec保护的数据包必须执行SAD的搜索，由此来找到符合最长匹配SA标识符的SA实体。所谓最长匹配，就是如果两个或者更多SAD实体同SPI值相同，那么还需要比较目的地址，目的地址和源地址，IP地址（正如SAD实体指明的那样）。这就意味SAD搜索的逻辑顺序是这样的：

        1.基于｛SPI，目的地址，源地址｝搜索SAD。如果存在SAD实体符合要求，那么就处理相应的入方向AH数据包。否则进行步骤2.

        2.基于｛SPI，目的地址｝搜索SAD。如果存在SAD实体符合要求，那么就处理相应的入方向AH数据包。否则进行步骤3.

        3.如果接收者使用独立的空间维护AH和ESP，那么就基于｛SPI｝搜索SAD，否则基于｛SPI，协议｝搜索SAD。如果存在SAD实体符合要求，那么就处理相应的入方向AH数据包。否则丢弃报文并记录审计事件。