Network Working Group S. Kent
Request for Comments: 2402 BBN Corp
Obsoletes: 1826 R. Atkinson
Category: Standards Track @Home Network
November 1998
Network Working Group S. Kent
Request for Comments: 2402 BBN Corp
Obsoletes: 1826 R. Atkinson
Category: Standards Track @Home Network
November 1998
IP Authentication Header
IP认证头
Status of this Memo
本备忘录的状况
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Table of Contents
目录
1. Introduction......................................................2
2. Authentication Header Format......................................3
2.1 Next Header...................................................4
2.2 Payload Length................................................4
2.3 Reserved......................................................4
2.4 Security Parameters Index (SPI)...............................4
2.5 Sequence Number...............................................5
2.6 Authentication Data ..........................................5
3. Authentication Header Processing..................................5
3.1 Authentication Header Location...............................5
3.2 Authentication Algorithms....................................7
3.3 Outbound Packet Processing...................................8
3.3.1 Security Association Lookup.............................8
3.3.2 Sequence Number Generation..............................8
3.3.3 Integrity Check Value Calculation.......................9
3.3.3.1 Handling Mutable Fields............................9
3.3.3.1.1 ICV Computation for IPv4.....................10
3.3.3.1.1.1 Base Header Fields.......................10
3.3.3.1.1.2 Options..................................11
3.3.3.1.2 ICV Computation for IPv6.....................11
3.3.3.1.2.1 Base Header Fields.......................11
3.3.3.1.2.2 Extension Headers Containing Options.....11
3.3.3.1.2.3 Extension Headers Not Containing Options.11
3.3.3.2 Padding...........................................12
3.3.3.2.1 Authentication Data Padding..................12
1. Introduction......................................................2
2. Authentication Header Format......................................3
2.1 Next Header...................................................4
2.2 Payload Length................................................4
2.3 Reserved......................................................4
2.4 Security Parameters Index (SPI)...............................4
2.5 Sequence Number...............................................5
2.6 Authentication Data ..........................................5
3. Authentication Header Processing..................................5
3.1 Authentication Header Location...............................5
3.2 Authentication Algorithms....................................7
3.3 Outbound Packet Processing...................................8
3.3.1 Security Association Lookup.............................8
3.3.2 Sequence Number Generation..............................8
3.3.3 Integrity Check Value Calculation.......................9
3.3.3.1 Handling Mutable Fields............................9
3.3.3.1.1 ICV Computation for IPv4.....................10
3.3.3.1.1.1 Base Header Fields.......................10
3.3.3.1.1.2 Options..................................11
3.3.3.1.2 ICV Computation for IPv6.....................11
3.3.3.1.2.1 Base Header Fields.......................11
3.3.3.1.2.2 Extension Headers Containing Options.....11
3.3.3.1.2.3 Extension Headers Not Containing Options.11
3.3.3.2 Padding...........................................12
3.3.3.2.1 Authentication Data Padding..................12
3.3.3.2.2 Implicit Packet Padding......................12
3.3.4 Fragmentation..........................................12
3.4 Inbound Packet Processing...................................13
3.4.1 Reassembly.............................................13
3.4.2 Security Association Lookup............................13
3.4.3 Sequence Number Verification...........................13
3.4.4 Integrity Check Value Verification.....................15
4. Auditing.........................................................15
5. Conformance Requirements.........................................16
6. Security Considerations..........................................16
7. Differences from RFC 1826........................................16
Acknowledgements....................................................17
Appendix A -- Mutability of IP Options/Extension Headers............18
A1. IPv4 Options.................................................18
A2. IPv6 Extension Headers.......................................19
References..........................................................20
Disclaimer..........................................................21
Author Information..................................................22
Full Copyright Statement............................................22
3.3.3.2.2 Implicit Packet Padding......................12
3.3.4 Fragmentation..........................................12
3.4 Inbound Packet Processing...................................13
3.4.1 Reassembly.............................................13
3.4.2 Security Association Lookup............................13
3.4.3 Sequence Number Verification...........................13
3.4.4 Integrity Check Value Verification.....................15
4. Auditing.........................................................15
5. Conformance Requirements.........................................16
6. Security Considerations..........................................16
7. Differences from RFC 1826........................................16
Acknowledgements....................................................17
Appendix A -- Mutability of IP Options/Extension Headers............18
A1. IPv4 Options.................................................18
A2. IPv6 Extension Headers.......................................19
References..........................................................20
Disclaimer..........................................................21
Author Information..................................................22
Full Copyright Statement............................................22
The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "authentication"), and to provide protection against replays. This latter, optional service may be selected, by the receiver, when a Security Association is established. (Although the default calls for the sender to increment the Sequence Number used for anti-replay, the service is effective only if the receiver checks the Sequence Number.) AH provides authentication for as much of the IP header as possible, as well as for upper level protocol data. However, some IP header fields may change in transit and the value of these fields, when the packet arrives at the receiver, may not be predictable by the sender. The values of such fields cannot be protected by AH. Thus the protection provided to the IP header by AH is somewhat piecemeal.
IP认证头（AH）用于为IP数据报提供无连接完整性和数据源认证（以下简称“认证”），并提供防止重播的保护。当建立安全关联时，接收方可以选择后一种可选服务。（虽然默认情况下要求发送方增加用于反重播的序列号，但只有在接收方检查序列号时，服务才有效。）AH为尽可能多的IP头以及上层协议数据提供身份验证。然而，一些IP报头字段可能在传输过程中发生变化，并且当数据包到达接收方时，发送方可能无法预测这些字段的值。AH不能保护这些字段的值。因此，AH向IP报头提供的保护有些零碎。
AH may be applied alone, in combination with the IP Encapsulating Security Payload (ESP) [KA97b], or in a nested fashion through the use of tunnel mode (see "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. ESP may be used to provide the same security services, and it also provides a confidentiality (encryption) service. The primary difference between the authentication provided by ESP and AH is the extent of the coverage. Specifically, ESP does not protect any IP header fields
AH可单独应用，与IP封装安全有效载荷（ESP）[KA97b]结合使用，或通过使用隧道模式以嵌套方式应用（请参阅“互联网协议的安全体系结构”[KA97a]，以下称为安全体系结构文件）。可以在一对通信主机之间、一对通信安全网关之间或安全网关与主机之间提供安全服务。ESP可用于提供相同的安全服务，并且还提供保密（加密）服务。ESP和AH提供的身份验证的主要区别在于覆盖范围。特别是，ESP不保护任何IP头字段
unless those fields are encapsulated by ESP (tunnel mode). For more details on how to use AH and ESP in various network environments, see the Security Architecture document [KA97a].
除非这些字段由ESP（隧道模式）封装。有关如何在各种网络环境中使用AH和ESP的更多详细信息，请参阅安全体系结构文档[KA97a]。
It is assumed that the reader is familiar with the terms and concepts described in the Security Architecture document. In particular, the reader should be familiar with the definitions of security services offered by AH and ESP, the concept of Security Associations, the ways in which AH can be used in conjunction with ESP, and the different key management options available for AH and ESP. (With regard to the last topic, the current key management options required for both AH and ESP are manual keying and automated keying via IKE [HC98].)
假定读者熟悉安全体系结构文档中描述的术语和概念。特别是，读者应熟悉AH和ESP提供的安全服务的定义、安全关联的概念、AH与ESP结合使用的方式以及AH和ESP可用的不同密钥管理选项。（关于最后一个主题，AH和ESP当前所需的密钥管理选项是通过IKE手动键控和自动键控[HC98]。）
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、推荐、可和可选时，应按照RFC 2119[Bra97]中的说明进行解释。
The protocol header (IPv4, IPv6, or Extension) immediately preceding the AH header will contain the value 51 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2].
AH头前面的协议头（IPv4、IPv6或扩展）将在其协议（IPv4）或下一个头（IPv6、扩展）字段[STD-2]中包含值51。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Authentication Data (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Authentication Data (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following subsections define the fields that comprise the AH format. All the fields described here are mandatory, i.e., they are always present in the AH format and are included in the Integrity Check Value (ICV) computation (see Sections 2.6 and 3.3.3).
以下小节定义了构成AH格式的字段。此处描述的所有字段均为必填字段，即它们始终以AH格式存在，并包含在完整性检查值（ICV）计算中（见第2.6节和第3.3.3节）。
The Next Header is an 8-bit field that identifies the type of the next payload after the Authentication Header. The value of this field is chosen from the set of IP Protocol Numbers defined in the most recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned Numbers Authority (IANA).
下一个报头是一个8位字段，用于标识身份验证报头之后的下一个有效负载的类型。该字段的值从互联网分配号码管理局（IANA）最近的“分配号码”[STD-2]RFC中定义的IP协议号码集中选择。
This 8-bit field specifies the length of AH in 32-bit words (4-byte units), minus "2". (All IPv6 extension headers, as per RFC 1883, encode the "Hdr Ext Len" field by first subtracting 1 (64-bit word) from the header length (measured in 64-bit words). AH is an IPv6 extension header. However, since its length is measured in 32-bit words, the "Payload Length" is calculated by subtracting 2 (32 bit words).) In the "standard" case of a 96-bit authentication value plus the 3 32-bit word fixed portion, this length field will be "4". A "null" authentication algorithm may be used only for debugging purposes. Its use would result in a "1" value for this field for IPv4 or a "2" for IPv6, as there would be no corresponding Authentication Data field (see Section 3.3.3.2.1 on "Authentication Data Padding").
此8位字段以32位字（4字节单位）减去“2”指定AH的长度。（根据RFC 1883，所有IPv6扩展头首先从头长度（以64位字测量）中减去1（64位字），对“Hdr Ext Len”字段进行编码。AH是IPv6扩展头。但是，由于其长度以32位字测量，因此“有效负载长度”是通过减去2（32位字）来计算的。）如果是96位身份验证值加上3 32位字固定部分，则此长度字段将为“4”。“空”身份验证算法只能用于调试目的。它的使用将导致IPv4的该字段值为“1”，IPv6的该字段值为“2”，因为没有相应的身份验证数据字段（请参见第3.3.3.2.1节“身份验证数据填充”）。
This 16-bit field is reserved for future use. It MUST be set to "zero." (Note that the value is included in the Authentication Data calculation, but is otherwise ignored by the recipient.)
此16位字段保留供将来使用。必须将其设置为“零”。（请注意，该值包含在身份验证数据计算中，但收件人会忽略该值。）
The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (AH), uniquely identifies the Security Association for this datagram. The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. It is ordinarily selected by the destination system upon establishment of an SA (see the Security Architecture document for more details).
SPI是一个任意32位值，它与目标IP地址和安全协议（AH）结合使用，唯一标识此数据报的安全关联。范围为1到255的SPI值集由互联网分配号码管理局（IANA）保留，以备将来使用；IANA通常不会指定保留的SPI值，除非RFC中指定使用指定的SPI值。它通常由目标系统在建立SA时选择（有关更多详细信息，请参阅安全体系结构文档）。
The SPI value of zero (0) is reserved for local, implementation-specific use and MUST NOT be sent on the wire. For example, a key management implementation MAY use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established.
SPI值0（0）保留供本地特定于实现的使用，不得通过线路发送。例如，当IPsec实现已请求其密钥管理实体建立新SA，但SA尚未建立时，密钥管理实现可使用零SPI值来表示“不存在安全关联”。
This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). It is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section below).
此无符号32位字段包含单调递增的计数器值（序列号）。它是强制性的，并且始终存在，即使接收方没有选择为特定SA启用反重播服务。序列号字段的处理由接收方自行决定，即发送方必须始终发送此字段，但接收方无需对其采取行动（请参阅下文“入站数据包处理”部分中的序列号验证讨论）。
The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a Sequence Number of 1; see Section 3.3.2 for more details on how the Sequence Number is generated.) If anti-replay is enabled (the default), the transmitted Sequence Number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA.
建立SA时，发送方计数器和接收方计数器初始化为0。（使用给定SA发送的第一个数据包的序列号为1；有关如何生成序列号的更多详细信息，请参阅第3.3.2节。）如果启用了反重播（默认），则决不能允许传输的序列号循环。因此，在SA上传输第2^32个数据包之前，必须重置发送方计数器和接收方计数器（通过建立新SA和新密钥）。
This is a variable-length field that contains the Integrity Check Value (ICV) for this packet. The field must be an integral multiple of 32 bits in length. The details of the ICV computation are described in Section 3.3.2 below. This field may include explicit padding. This padding is included to ensure that the length of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits (IPv6). All implementations MUST support such padding. Details of how to compute the required padding length are provided below. The authentication algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation.
这是一个可变长度字段，包含此数据包的完整性检查值（ICV）。字段长度必须是32位的整数倍。下文第3.3.2节描述了ICV计算的细节。此字段可能包含显式填充。包含此填充是为了确保AH头的长度是32位（IPv4）或64位（IPv6）的整数倍。所有实现都必须支持这种填充。下面提供了有关如何计算所需填充长度的详细信息。认证算法规范必须指定ICV的长度以及验证的比较规则和处理步骤。
Like ESP, AH may be employed in two ways: transport mode or tunnel mode. The former mode is applicable only to host implementations and provides protection for upper layer protocols, in addition to selected IP header fields. (In this mode, note that for "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.)
与ESP一样，AH可采用两种方式：运输模式或隧道模式。前一种模式仅适用于主机实现，除了选定的IP头字段外，还为上层协议提供保护。（在此模式下，请注意，对于“堆栈中的凹凸”或“导线中的凹凸”如安全体系结构文档中所定义的实现，入站和出站IP碎片可能需要IPsec实现来执行额外的IP重组/碎片化，以符合本规范并提供透明的IPsec支持。在这些实现中执行此类操作需要特别小心当使用多个接口时。）
In transport mode, AH is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted. In the context of IPv4, this calls for placing AH after the IP header (and any options that it contains), but before the upper layer protocol. (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP. For example, an ICMP message MAY be sent using either "transport" mode or "tunnel" mode.) The following diagram illustrates AH transport mode positioning for a typical IPv4 packet, on a "before and after" basis.
在传输模式下，AH插入在IP报头之后和上层协议之前，例如TCP、UDP、ICMP等，或者插入在已经插入的任何其他IPsec报头之前。在IPv4的上下文中，这要求将AH放在IP头（及其包含的任何选项）之后，但放在上层协议之前。（请注意，术语“传输”模式不应被误解为仅限于TCP和UDP。例如，可以使用“传输”模式或“隧道”模式发送ICMP消息。）下图说明了典型IPv4数据包的AH传输模式定位，以“之前和之后”为基础。
BEFORE APPLYING AH
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
BEFORE APPLYING AH
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING AH
---------------------------------
IPv4 |orig IP hdr | | | |
|(any options)| AH | TCP | Data |
---------------------------------
|<------- authenticated ------->|
except for mutable fields
AFTER APPLYING AH
---------------------------------
IPv4 |orig IP hdr | | | |
|(any options)| AH | TCP | Data |
---------------------------------
|<------- authenticated ------->|
except for mutable fields
In the IPv6 context, AH is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers. The destination options extension header(s) could appear either before or after the AH header depending on the semantics desired. The following diagram illustrates AH transport mode positioning for a typical IPv6 packet.
在IPv6上下文中，AH被视为端到端有效负载，因此应该出现在逐跳、路由和分段扩展头之后。根据所需的语义，目标选项扩展头可以出现在AH头之前或之后。下图说明了典型IPv6数据包的AH传输模式定位。
BEFORE APPLYING AH
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
BEFORE APPLYING AH
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AFTER APPLYING AH
------------------------------------------------------------
IPv6 | |hop-by-hop, dest*, | | dest | | |
|orig IP hdr |routing, fragment. | AH | opt* | TCP | Data |
------------------------------------------------------------
|<---- authenticated except for mutable fields ----------->|
AFTER APPLYING AH
------------------------------------------------------------
IPv6 | |hop-by-hop, dest*, | | dest | | |
|orig IP hdr |routing, fragment. | AH | opt* | TCP | Data |
------------------------------------------------------------
|<---- authenticated except for mutable fields ----------->|
* = if present, could be before AH, after AH, or both
* =如果存在，可在AH之前、之后或两者
ESP and AH headers can be combined in a variety of modes. The IPsec Architecture document describes the combinations of security associations that must be supported.
ESP和AH头可以以多种模式组合。IPsec体系结构文档描述了必须支持的安全关联的组合。
Tunnel mode AH may be employed in either hosts or security gateways (or in so-called "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document). When AH is implemented in a security gateway (to protect transit traffic), tunnel mode must be used. In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header may contain distinct IP addresses, e.g., addresses of security gateways. In tunnel mode, AH protects the entire inner IP packet, including the entire inner IP header. The position of AH in tunnel mode, relative to the outer IP header, is the same as for AH in transport mode. The following diagram illustrates AH tunnel mode positioning for typical IPv4 and IPv6 packets.
隧道模式AH可用于主机或安全网关（或所谓的“堆栈中的通气”或“线路中的通气”实现，如安全体系结构文档中所定义）。当AH在安全网关中实施（以保护过境交通）时，必须使用隧道模式。在隧道模式下，“内部”IP报头携带最终的源地址和目标地址，“外部”IP报头可能包含不同的IP地址，例如安全网关的地址。在隧道模式下，AH保护整个内部IP数据包，包括整个内部IP报头。隧道模式下AH相对于外部IP报头的位置与传输模式下AH的位置相同。下图说明了典型IPv4和IPv6数据包的AH隧道模式定位。
------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | |
|(any options)| AH | (any options) |TCP | Data |
------------------------------------------------
|<- authenticated except for mutable fields -->|
| in the new IP hdr |
------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | |
|(any options)| AH | (any options) |TCP | Data |
------------------------------------------------
|<- authenticated except for mutable fields -->|
| in the new IP hdr |
--------------------------------------------------------------
IPv6 | | ext hdrs*| | | ext hdrs*| | |
|new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data|
--------------------------------------------------------------
|<-- authenticated except for mutable fields in new IP hdr ->|
--------------------------------------------------------------
IPv6 | | ext hdrs*| | | ext hdrs*| | |
|new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data|
--------------------------------------------------------------
|<-- authenticated except for mutable fields in new IP hdr ->|
* = construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below.
* =下面讨论外部IP hdr/扩展的构造和内部IP hdr/扩展的修改。
The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., DES) or on one-way hash functions (e.g., MD5 or SHA-1). For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are appropriate, though performance and space considerations currently preclude use of such algorithms. The mandatory-to-implement authentication algorithms are described in Section 5 "Conformance Requirements". Other algorithms MAY be supported.
用于ICV计算的认证算法由SA指定。对于点对点通信，合适的认证算法包括基于对称加密算法（例如DES）或单向散列函数（例如MD5或SHA-1）的密钥消息认证码（MAC）。对于多播通信，单向散列算法与非对称签名算法相结合是合适的，尽管性能和空间方面的考虑目前阻碍了此类算法的使用。第5节“一致性要求”中描述了实施认证算法的强制性要求。可能支持其他算法。
In transport mode, the sender inserts the AH header after the IP header and before an upper layer protocol header, as described above. In tunnel mode, the outer and inner IP header/extensions can be inter-related in a variety of ways. The construction of the outer IP header/extensions during the encapsulation process is described in the Security Architecture document.
在传输模式下，发送方在IP报头之后和上层协议报头之前插入AH报头，如上所述。在隧道模式下，外部和内部IP头/扩展可以以多种方式相互关联。安全体系结构文档中描述了封装过程中外部IP头/扩展的构造。
If there is more than one IPsec header/extension required, the order of the application of the security headers MUST be defined by security policy. For simplicity of processing, each IPsec header SHOULD ignore the existence (i.e., not zero the contents or try to predict the contents) of IPsec headers to be applied later. (While a native IP or bump-in-the-stack implementation could predict the contents of later IPsec headers that it applies itself, it won't be possible for it to predict any IPsec headers added by a bump-in-the-wire implementation between the host and the network.)
如果需要多个IPsec头/扩展，则安全头的应用顺序必须由安全策略定义。为了简化处理，每个IPsec头都应该忽略将在以后应用的IPsec头的存在（即，不要将内容归零或尝试预测内容）。（虽然堆栈实现中的本机IP或bump可以预测其自身应用的后续IPsec头的内容，但它无法预测主机和网络之间的有线实现中bump添加的任何IPsec头。）
AH is applied to an outbound packet only after an IPsec implementation determines that the packet is associated with an SA that calls for AH processing. The process of determining what, if any, IPsec processing is applied to outbound traffic is described in the Security Architecture document.
AH仅在IPsec实现确定出站数据包与调用AH处理的SA关联后应用于出站数据包。安全体系结构文档中描述了确定将什么（如果有的话）IPsec处理应用于出站流量的过程。
The sender's counter is initialized to 0 when an SA is established. The sender increments the Sequence Number for this SA and inserts the new value into the Sequence Number Field. Thus the first packet sent using a given SA will have a Sequence Number of 1.
建立SA时，发送方计数器初始化为0。发送方增加此SA的序列号，并将新值插入序列号字段。因此，使用给定SA发送的第一个分组的序列号为1。
If anti-replay is enabled (the default), the sender checks to ensure that the counter has not cycled before inserting the new value in the Sequence Number field. In other words, the sender MUST NOT send a packet on an SA if doing so would cause the Sequence Number to cycle. An attempt to transmit a packet that would result in Sequence Number overflow is an auditable event. (Note that this approach to Sequence Number management does not require use of modular arithmetic.)
如果启用了反重播功能（默认设置），则发送方会进行检查，以确保在序列号字段中插入新值之前计数器没有循环。换句话说，如果这样做会导致序列号循环，则发送方不得在SA上发送数据包。试图传输可能导致序列号溢出的数据包是可审核事件。（请注意，这种序列号管理方法不需要使用模运算。）
The sender assumes anti-replay is enabled as a default, unless otherwise notified by the receiver (see 3.4.3). Thus, if the counter has cycled, the sender will set up a new SA and key (unless the SA was configured with manual key management).
除非接收方另有通知（见3.4.3），否则发送方假定默认启用了反重播功能。因此，如果计数器已循环，发送方将设置新的SA和密钥（除非SA配置了手动密钥管理）。
If anti-replay is disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5.) However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero.
如果禁用了反重放功能，则发送方无需监控或重置计数器，例如，在手动钥匙管理的情况下（参见第5节）。但是，发送方仍会增加计数器，当计数器达到最大值时，计数器会回滚到零。
The AH ICV is computed over: o IP header fields that are either immutable in transit or that are predictable in value upon arrival at the endpoint for the AH SA o the AH header (Next Header, Payload Len, Reserved, SPI, Sequence Number, and the Authentication Data (which is set to zero for this computation), and explicit padding bytes (if any)) o the upper level protocol data, which is assumed to be immutable in transit
AH ICV通过：o IP报头字段进行计算，这些字段在传输过程中是不可变的，或者在到达AH SA的端点时值是可预测的。o AH报头（下一个报头、有效负载Len、Reserved、SPI、序列号和身份验证数据（该计算设置为零）以及显式填充字节（如果有））o上层协议数据，假定在传输过程中是不可变的
If a field may be modified during transit, the value of the field is set to zero for purposes of the ICV computation. If a field is mutable, but its value at the (IPsec) receiver is predictable, then that value is inserted into the field for purposes of the ICV calculation. The Authentication Data field is also set to zero in preparation for this computation. Note that by replacing each field's value with zero, rather than omitting the field, alignment is preserved for the ICV calculation. Also, the zero-fill approach ensures that the length of the fields that are so handled cannot be changed during transit, even though their contents are not explicitly covered by the ICV.
如果一个字段在运输过程中可能被修改，为了ICV计算的目的，该字段的值被设置为零。如果字段是可变的，但其在（IPsec）接收器处的值是可预测的，则该值将插入该字段以用于ICV计算。身份验证数据字段也设置为零以准备此计算。请注意，通过将每个字段的值替换为零，而不是忽略该字段，可以为ICV计算保留对齐。此外，零填充方法确保这样处理的字段长度在传输过程中不会改变，即使ICV未明确涵盖其内容。
As a new extension header or IPv4 option is created, it will be defined in its own RFC and SHOULD include (in the Security Considerations section) directions for how it should be handled when calculating the AH ICV. If the IP (v4 or v6) implementation encounters an extension header that it does not recognize, it will discard the packet and send an ICMP message. IPsec will never see the packet. If the IPsec implementation encounters an IPv4 option that it does not recognize, it should zero the whole option, using the second byte of the option as the length. IPv6 options (in Destination extension headers or Hop by Hop extension header) contain a flag indicating mutability, which determines appropriate processing for such options.
创建新的扩展标头或IPv4选项时，将在其自己的RFC中定义，并应包括（在“安全注意事项”部分中）计算AH ICV时应如何处理的说明。如果IP（v4或v6）实现遇到无法识别的扩展头，它将丢弃该数据包并发送ICMP消息。IPsec将永远看不到数据包。如果IPsec实现遇到无法识别的IPv4选项，则应使用该选项的第二个字节作为长度，将整个选项归零。IPv6选项（在目标扩展标头或逐跳扩展标头中）包含一个指示可变性的标志，该标志确定了对此类选项的适当处理。
The IPv4 base header fields are classified as follows:
IPv4基本标头字段分类如下：
Immutable Version Internet Header Length Total Length Identification Protocol (This should be the value for AH.) Source Address Destination Address (without loose or strict source routing)
不可变版本Internet标头长度总长度标识协议（这应该是AH的值。）源地址目标地址（无松散或严格的源路由）
Mutable but predictable Destination Address (with loose or strict source routing)
可变但可预测的目标地址（具有松散或严格的源路由）
Mutable (zeroed prior to ICV calculation) Type of Service (TOS) Flags Fragment Offset Time to Live (TTL) Header Checksum
可变（ICV计算前归零）服务类型（TOS）标志片段偏移生存时间（TTL）标头校验和
TOS -- This field is excluded because some routers are known to change the value of this field, even though the IP specification does not consider TOS to be a mutable header field.
TOS——因为某些IP不考虑TOS是可变的头字段，所以某些路由器被认为改变了该字段的值，因此排除了这个字段。
Flags -- This field is excluded since an intermediate router might set the DF bit, even if the source did not select it.
标志——此字段被排除，因为中间路由器可能会设置DF位，即使源没有选择它。
Fragment Offset -- Since AH is applied only to non-fragmented IP packets, the Offset Field must always be zero, and thus it is excluded (even though it is predictable).
片段偏移量——由于AH仅应用于非片段化IP数据包，偏移量字段必须始终为零，因此它被排除在外（即使它是可预测的）。
TTL -- This is changed en-route as a normal course of processing by routers, and thus its value at the receiver is not predictable by the sender.
TTL——这是路由器在正常处理过程中更改的，因此发送方无法预测其在接收方的值。
Header Checksum -- This will change if any of these other fields changes, and thus its value upon reception cannot be predicted by the sender.
报头校验和——如果这些字段中的任何一个发生了变化，那么它的值将发生变化，因此发送方无法预测它在接收时的值。
For IPv4 (unlike IPv6), there is no mechanism for tagging options as mutable in transit. Hence the IPv4 options are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. For IPv4, the entire option is viewed as a unit; so even though the type and length fields within most options are immutable in transit, if an option is classified as mutable, the entire option is zeroed for ICV computation purposes.
对于IPv4（与IPv6不同），没有将选项标记为传输中可变的机制。因此，IPv4选项在附录A中明确列出，并分类为不可变、可变但可预测或可变。对于IPv4，整个选项被视为一个单元；因此，即使大多数选项中的类型和长度字段在传输过程中是不可变的，但如果某个选项被分类为可变的，则出于ICV计算的目的，整个选项将归零。
The IPv6 base header fields are classified as follows:
IPv6基本标头字段分类如下：
Immutable Version Payload Length Next Header (This should be the value for AH.) Source Address Destination Address (without Routing Extension Header)
不可变版本有效负载长度下一个标头（这应该是AH的值。）源地址目标地址（不带路由扩展标头）
Mutable but predictable Destination Address (with Routing Extension Header)
可变但可预测的目标地址（带路由扩展标头）
Mutable (zeroed prior to ICV calculation) Class Flow Label Hop Limit
可变（ICV计算前归零）类流标签跃点限制
IPv6 options in the Hop-by-Hop and Destination Extension Headers contain a bit that indicates whether the option might change (unpredictably) during transit. For any option for which contents may change en-route, the entire "Option Data" field must be treated as zero-valued octets when computing or verifying the ICV. The Option Type and Opt Data Len are included in the ICV calculation. All options for which the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH95] for more information.
逐跳和目标扩展标头中的IPv6选项包含一个位，指示该选项在传输过程中是否可能发生更改（不可预测）。对于内容可能在途中更改的任何选项，在计算或验证ICV时，必须将整个“选项数据”字段视为零值八位字节。期权类型和期权数据Len包含在ICV计算中。位表示不变性的所有选项都包括在ICV计算中。有关更多信息，请参阅IPv6规范[DH95]。
The IPv6 extension headers that do not contain options are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable.
附录A中明确列出了不包含选项的IPv6扩展头，并将其分类为不可变、可变但可预测或可变。
As mentioned in section 2.6, the Authentication Data field explicitly includes padding to ensure that the AH header is a multiple of 32 bits (IPv4) or 64 bits (IPv6). If padding is required, its length is determined by two factors:
如第2.6节所述，身份验证数据字段明确包含填充，以确保AH头是32位（IPv4）或64位（IPv6）的倍数。如果需要填充，其长度由两个因素决定：
- the length of the ICV - the IP protocol version (v4 or v6)
- ICV的长度-IP协议版本（v4或v6）
For example, if the output of the selected algorithm is 96-bits, no padding is required for either IPv4 or for IPv6. However, if a different length ICV is generated, due to use of a different algorithm, then padding may be required depending on the length and IP protocol version. The content of the padding field is arbitrarily selected by the sender. (The padding is arbitrary, but need not be random to achieve security.) These padding bytes are included in the Authentication Data calculation, counted as part of the Payload Length, and transmitted at the end of the Authentication Data field to enable the receiver to perform the ICV calculation.
例如，如果所选算法的输出为96位，则IPv4或IPv6都不需要填充。但是，如果由于使用不同的算法而生成不同长度的ICV，则可能需要根据长度和IP协议版本进行填充。填充字段的内容由发送方任意选择。（填充是任意的，但不必是随机的，以实现安全性。）这些填充字节包括在认证数据计算中，作为有效负载长度的一部分计算，并在认证数据字段的末尾发送，以使接收器能够执行ICV计算。
For some authentication algorithms, the byte string over which the ICV computation is performed must be a multiple of a blocksize specified by the algorithm. If the IP packet length (including AH) does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the packet, prior to ICV computation. The padding octets MUST have a value of zero. The blocksize (and hence the length of the padding) is specified by the algorithm specification. This padding is not transmitted with the packet. Note that MD5 and SHA-1 are viewed as having a 1-byte blocksize because of their internal padding conventions.
对于某些身份验证算法，执行ICV计算的字节字符串必须是算法指定的块大小的倍数。如果IP数据包长度（包括AH）与算法的块大小要求不匹配，则必须在ICV计算之前将隐式填充添加到数据包的末尾。填充八位字节的值必须为零。块大小（以及填充的长度）由算法规范指定。此填充不随数据包一起传输。注意，MD5和SHA-1被视为具有1字节的块大小，因为它们的内部填充约定。
If required, IP fragmentation occurs after AH processing within an IPsec implementation. Thus, transport mode AH is applied only to whole IP datagrams (not to IP fragments). An IP packet to which AH has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to AH processing at a receiver. In tunnel mode, AH is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (see the Security Architecture document for details) may apply tunnel mode AH to such fragments.
如果需要，IP碎片会在IPsec实现中的AH处理之后发生。因此，传输模式AH仅应用于整个IP数据报（而不是IP片段）。应用了AH的IP分组本身可能在路由中被路由器分段，并且在接收机处进行AH处理之前必须重新组装这些分段。在隧道模式下，AH应用于IP分组，其有效载荷可以是分段的IP分组。例如，安全网关或“堆栈中的通气”或“线路中的通气”IPsec实现（有关详细信息，请参阅安全体系结构文档）可以将隧道模式AH应用于此类片段。
If there is more than one IPsec header/extension present, the processing for each one ignores (does not zero, does not use) any IPsec headers applied subsequent to the header being processed.
如果存在多个IPsec头/扩展，则对每个IPsec头/扩展的处理将忽略（不为零，不使用）在处理头之后应用的任何IPsec头。
If required, reassembly is performed prior to AH processing. If a packet offered to AH for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID.
如果需要，在AH处理之前进行重新组装。如果提供给AH进行处理的分组似乎是IP片段，即偏移字段为非零或设置了“更多片段”标志，则接收机必须丢弃该分组；这是一个可审核的事件。此事件的审核日志条目应包括SPI值、日期/时间、源地址、目标地址和（在IPv6中）流ID。
NOTE: For packet reassembly, the current IPv4 spec does NOT require either the zero'ing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. In order for a reassembled packet to be processed by IPsec (as opposed to discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet.
注意：对于数据包重组，当前的IPv4规范既不要求偏移量字段为零，也不要求清除MORE FRAGMENTS标志。为了让IPsec处理重新组装的数据包（而不是作为明显的片段丢弃），IP代码必须在重新组装数据包后完成这两件事。
Upon receipt of a packet containing an IP Authentication Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address, security protocol (AH), and the SPI. (This process is described in more detail in the Security Architecture document.) The SA indicates whether the Sequence Number field will be checked, specifies the algorithm(s) employed for ICV computation, and indicates the key(s) required to validate the ICV.
在接收到包含IP认证报头的分组时，接收机基于目的地IP地址、安全协议（AH）和SPI来确定适当的（单向）SA。（此过程在安全体系结构文档中有更详细的描述。）SA指示是否检查序列号字段，指定ICV计算所采用的算法，并指示验证ICV所需的密钥。
If no valid Security Association exists for this session (e.g., the receiver has no key), the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID.
如果此会话不存在有效的安全关联（例如，接收方没有密钥），则接收方必须丢弃该数据包；这是一个可审核的事件。此事件的审核日志条目应包括SPI值、日期/时间、源地址、目标地址和（在IPv6中）流ID。
All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.)
所有AH实现都必须支持反重播服务，尽管其使用可能由接收方根据每个SA启用或禁用。（请注意，对于将流量定向到单个SA的多个发送方之间的传输序列号值，没有管理规定（无论目标地址是单播、广播还是多播）。因此，不应在使用单个SA的多发送方环境中使用反重播服务。）
If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number. However, from the perspective of the sender, the default is to assume that anti-replay is enabled at the receiver. To avoid having the sender do unnecessary sequence number monitoring and SA setup (see section 3.3.2), if an SA establishment protocol such as IKE is employed, the receiver SHOULD notify the sender, during SA establishment, if the receiver will not provide anti-replay protection.
如果接收器未为SA启用反重播，则不会对序列号执行入站检查。但是，从发送方的角度来看，默认情况是假定在接收方启用了反重播。为避免发送方进行不必要的序列号监控和SA设置（参见第3.3.2节），如果采用了诸如IKE之类的SA建立协议，则接收方应在SA建立期间通知发送方，如果接收方不提供防重放保护。
If the receiver has enabled the anti-replay service for this SA, the receiver packet counter for the SA MUST be initialized to zero when the SA is established. For each received packet, the receiver MUST verify that the packet contains a Sequence Number that does not duplicate the Sequence Number of any other packets received during the life of this SA. This SHOULD be the first AH check applied to a packet after it has been matched to an SA, to speed rejection of duplicate packets.
如果接收器已为此SA启用了反重播服务，则在建立SA时，必须将SA的接收器数据包计数器初始化为零。对于每个接收到的分组，接收机必须验证该分组包含的序列号与在该SA的生命周期内接收到的任何其他分组的序列号不重复。这应该是与SA匹配后应用于数据包的第一个AH检查，以加快重复数据包的拒绝。
Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.) A MINIMUM window size of 32 MUST be supported; but a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the MINIMUM) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.)
通过使用滑动接收窗口拒绝重复项。（如何实现窗口是一个局部问题，但以下文本描述了实现必须展示的功能。）必须支持最小窗口大小32；但窗口大小为64是首选，应作为默认值使用。接收器可以选择另一个窗口大小（大于最小值）。（接收者不会将窗口大小通知发送者。）
The "right" edge of the window represents the highest, validated Sequence Number value received on this SA. Packets that contain Sequence Numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window. An efficient means for performing this check, based on the use of a bit mask, is described in the Security Architecture document.
窗口的“右”边缘表示此SA上接收到的最高已验证序列号值。包含序列号低于窗口“左”边缘的数据包将被拒绝。根据窗口内接收的数据包列表检查窗口内的数据包。安全体系结构文档中描述了基于位掩码的使用来执行该检查的有效方法。
If the received packet falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID. The receive window is updated only if the ICV verification succeeds.
如果接收到的数据包落在窗口内并且是新的，或者如果数据包在窗口的右侧，则接收机进行ICV验证。如果ICV验证失败，接收方必须将接收到的IP数据报丢弃为无效；这是一个可审核的事件。此事件的审核日志条目应包括SPI值、日期/时间、源地址、目标地址、序列号和（在IPv6中）流ID。仅当ICV验证成功时，才会更新接收窗口。
DISCUSSION:
讨论：
Note that if the packet is either inside the window and new, or is outside the window on the "right" side, the receiver MUST authenticate the packet before updating the Sequence Number window data.
请注意，如果数据包在窗口内且是新的，或者在“右侧”的窗口外，则接收器必须在更新序列号窗口数据之前对数据包进行身份验证。
The receiver computes the ICV over the appropriate fields of the packet, using the specified authentication algorithm, and verifies that it is the same as the ICV included in the Authentication Data field of the packet. Details of the computation are provided below.
接收机使用指定的认证算法，在分组的适当字段上计算ICV，并验证其与分组的认证数据字段中包括的ICV相同。计算详情如下。
If the computed and received ICV's match, then the datagram is valid, and it is accepted. If the test fails, then the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry SHOULD include the SPI value, date/time received, Source Address, Destination Address, and (in IPv6) the Flow ID.
如果计算出的和接收到的ICV匹配，则数据报有效，并被接受。如果测试失败，则接收器必须将接收到的IP数据报视为无效而丢弃；这是一个可审核的事件。审核日志条目应包括SPI值、接收日期/时间、源地址、目标地址和（在IPv6中）流ID。
DISCUSSION:
讨论：
Begin by saving the ICV value and replacing it (but not any Authentication Data padding) with zero. Zero all other fields that may have been modified during transit. (See section 3.3.3.1 for a discussion of which fields are zeroed before performing the ICV calculation.) Check the overall length of the packet, and if it requires implicit padding based on the requirements of the authentication algorithm, append zero-filled bytes to the end of the packet as required. Perform the ICV computation and compare the result with the saved value, using the comparison rules defined by the algorithm specification. (For example, if a digital signature and one-way hash are used for the ICV computation, the matching process is more complex.)
首先保存ICV值并将其替换为零（但不是任何身份验证数据填充）。将传输期间可能已修改的所有其他字段归零。（关于在执行ICV计算之前将哪些字段归零的讨论，请参见第3.3.3.1节。）检查数据包的总长度，如果需要根据认证算法的要求进行隐式填充，则根据需要将零填充字节附加到数据包的末尾。使用算法规范定义的比较规则，执行ICV计算并将结果与保存的值进行比较。（例如，如果数字签名和单向散列用于ICV计算，则匹配过程更复杂。）
Not all systems that implement AH will implement auditing. However, if AH is incorporated into a system that supports auditing, then the AH implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for AH. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY
并非所有实施AH的系统都将实施审计。但是，如果AH集成到支持审核的系统中，则AH实现还必须支持审核，并且必须允许系统管理员启用或禁用AH审核。在大多数情况下，审计的粒度是一个局部问题。但是，本规范中确定了几个可审核事件，并且为每个事件定义了应包含在审核日志中的最少信息集。审计日志中还可能包含这些事件的附加信息，本规范中未明确规定的附加事件也可能包含
result in audit log entries. There is no requirement for the receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action.
生成审核日志条目。不要求接收方在检测到可审计事件时向声称的发送方发送任何消息，因为通过这种行为可能导致拒绝服务。
Implementations that claim conformance or compliance with this specification MUST fully implement the AH syntax and processing described here and MUST comply with all requirements of the Security Architecture document. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service would require correct maintenance of the counter state at the sender, until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus a compliant implementation SHOULD NOT provide this service in conjunction with SAs that are manually keyed. A compliant AH implementation MUST support the following mandatory-to-implement algorithms:
声明符合或符合本规范的实现必须完全实现此处描述的AH语法和处理，并且必须符合安全体系结构文档的所有要求。如果用于计算ICV的密钥是手动分发的，则正确提供反重放服务需要在发送方正确维护计数器状态，直到密钥被替换，并且如果计数器溢出即将发生，则可能不会提供自动恢复。因此，兼容实现不应与手动键入的SAs一起提供此服务。符合要求的AH实施必须支持以下强制算法：
- HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b]
- 含MD5[MG97a]的HMAC-含SHA-1[MG97b]的HMAC
Security is central to the design of this protocol, and these security considerations permeate the specification. Additional security-relevant aspects of using the IPsec protocol are discussed in the Security Architecture document.
安全性是该协议设计的核心，这些安全考虑贯穿于规范中。安全体系结构文档中讨论了使用IPsec协议的其他安全相关方面。
This specification of AH differs from RFC 1826 [ATK95] in several important respects, but the fundamental features of AH remain intact. One goal of the revision of RFC 1826 was to provide a complete framework for AH, with ancillary RFCs required only for algorithm specification. For example, the anti-replay service is now an integral, mandatory part of AH, not a feature of a transform defined in another RFC. Carriage of a sequence number to support this service is now required at all times. The default algorithms required for interoperability have been changed to HMAC with MD5 or SHA-1 (vs. keyed MD5), for security reasons. The list of IPv4 header fields excluded from the ICV computation has been expanded to include the OFFSET and FLAGS fields.
AH的本规范在几个重要方面不同于RFC 1826[ATK95]，但AH的基本特征保持不变。RFC1826修订的一个目标是为AH提供一个完整的框架，辅助RFC仅用于算法规范。例如，反重播服务现在是AH不可分割的强制性部分，而不是另一个RFC中定义的转换的功能。现在，任何时候都需要携带序列号以支持此服务。出于安全原因，互操作性所需的默认算法已更改为带有MD5或SHA-1的HMAC（与键控MD5相比）。ICV计算中排除的IPv4标头字段列表已扩展，以包括偏移量和标志字段。
Another motivation for revision was to provide additional detail and clarification of subtle points. This specification provides rationale for exclusion of selected IPv4 header fields from AH coverage and provides examples on positioning of AH in both the IPv4
修改的另一个动机是提供额外的细节和对细微之处的澄清。本规范提供了将所选IPv4报头字段排除在AH覆盖范围之外的基本原理，并提供了有关在IPv4和IPv4中定位AH的示例
and v6 contexts. Auditing requirements have been clarified in this version of the specification. Tunnel mode AH was mentioned only in passing in RFC 1826, but now is a mandatory feature of AH. Discussion of interactions with key management and with security labels have been moved to the Security Architecture document.
和v6上下文。本规范版本中明确了审核要求。隧道模式AH仅在RFC1826中顺便提及，但现在是AH的强制性特征。有关与密钥管理和安全标签交互的讨论已移至安全体系结构文档中。
Acknowledgements
致谢
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, Francis Dupont, Phil Karn, Frank Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William Simpson, and Nina Yuan.
3年多来，本文档通过多个版本和迭代不断发展。在这段时间里，许多人为这一过程和文件本身贡献了重要的思想和精力。作者要感谢Karen Seo在本规范版本的审查、编辑、背景研究和协调方面提供的广泛帮助。作者还要感谢IPsec和IPng工作组的成员，并特别提到以下人员的努力（按字母顺序）：史蒂夫·贝洛文、史蒂夫·迪林、弗朗西斯·杜邦、菲尔·卡恩、弗兰克·卡斯滕霍尔茨、佩里·梅茨格、大卫·米赫尔契奇、希拉里·奥曼、诺曼·舒尔曼、威廉·辛普森和妮娜·袁。
Appendix A -- Mutability of IP Options/Extension Headers
附录A——IP选项/扩展头的可变性
A1. IPv4 Options
A1。IPv4选项
This table shows how the IPv4 options are classified with regard to "mutability". Where two references are provided, the second one supercedes the first. This table is based in part on information provided in RFC1700, "ASSIGNED NUMBERS", (October 1994).
此表显示了IPv4选项如何根据“可变性”进行分类。如果提供了两个参考，则第二个参考将取代第一个参考。本表部分基于RFC1700“分配编号”（1994年10月）中提供的信息。
Opt.
Copy Class # Name Reference
---- ----- --- ------------------------ ---------
IMMUTABLE -- included in ICV calculation
0 0 0 End of Options List [RFC791]
0 0 1 No Operation [RFC791]
1 0 2 Security [RFC1108(historic but in use)]
1 0 5 Extended Security [RFC1108(historic but in use)]
1 0 6 Commercial Security [expired I-D, now US MIL STD]
1 0 20 Router Alert [RFC2113]
1 0 21 Sender Directed Multi- [RFC1770]
Destination Delivery
MUTABLE -- zeroed
1 0 3 Loose Source Route [RFC791]
0 2 4 Time Stamp [RFC791]
0 0 7 Record Route [RFC791]
1 0 9 Strict Source Route [RFC791]
0 2 18 Traceroute [RFC1393]
Opt.
Copy Class # Name Reference
---- ----- --- ------------------------ ---------
IMMUTABLE -- included in ICV calculation
0 0 0 End of Options List [RFC791]
0 0 1 No Operation [RFC791]
1 0 2 Security [RFC1108(historic but in use)]
1 0 5 Extended Security [RFC1108(historic but in use)]
1 0 6 Commercial Security [expired I-D, now US MIL STD]
1 0 20 Router Alert [RFC2113]
1 0 21 Sender Directed Multi- [RFC1770]
Destination Delivery
MUTABLE -- zeroed
1 0 3 Loose Source Route [RFC791]
0 2 4 Time Stamp [RFC791]
0 0 7 Record Route [RFC791]
1 0 9 Strict Source Route [RFC791]
0 2 18 Traceroute [RFC1393]
EXPERIMENTAL, SUPERCEDED -- zeroed
1 0 8 Stream ID [RFC791, RFC1122 (Host Req)]
0 0 11 MTU Probe [RFC1063, RFC1191 (PMTU)]
0 0 12 MTU Reply [RFC1063, RFC1191 (PMTU)]
1 0 17 Extended Internet Proto [RFC1385, RFC1883 (IPv6)]
0 0 10 Experimental Measurement [ZSu]
1 2 13 Experimental Flow Control [Finn]
1 0 14 Experimental Access Ctl [Estrin]
0 0 15 ??? [VerSteeg]
1 0 16 IMI Traffic Descriptor [Lee]
1 0 19 Address Extension [Ullmann IPv7]
EXPERIMENTAL, SUPERCEDED -- zeroed
1 0 8 Stream ID [RFC791, RFC1122 (Host Req)]
0 0 11 MTU Probe [RFC1063, RFC1191 (PMTU)]
0 0 12 MTU Reply [RFC1063, RFC1191 (PMTU)]
1 0 17 Extended Internet Proto [RFC1385, RFC1883 (IPv6)]
0 0 10 Experimental Measurement [ZSu]
1 2 13 Experimental Flow Control [Finn]
1 0 14 Experimental Access Ctl [Estrin]
0 0 15 ??? [VerSteeg]
1 0 16 IMI Traffic Descriptor [Lee]
1 0 19 Address Extension [Ullmann IPv7]
NOTE: Use of the Router Alert option is potentially incompatible with use of IPsec. Although the option is immutable, its use implies that each router along a packet's path will "process" the packet and consequently might change the packet. This would happen on a hop by hop basis as the packet goes from router to router. Prior to being processed by the application to which the option contents are directed, e.g., RSVP/IGMP, the packet should encounter AH processing.
注意：路由器警报选项的使用可能与IPsec的使用不兼容。尽管该选项是不可变的，但它的使用意味着沿着数据包路径的每个路由器将“处理”该数据包，因此可能会更改该数据包。当数据包从一个路由器传送到另一个路由器时，这将在逐跳的基础上发生。在被选项内容被定向到的应用程序（例如RSVP/IGMP）处理之前，分组应该遇到AH处理。
However, AH processing would require that each router along the path is a member of a multicast-SA defined by the SPI. This might pose problems for packets that are not strictly source routed, and it requires multicast support techniques not currently available.
然而，AH处理要求路径上的每个路由器都是SPI定义的多播SA的成员。这可能会给没有严格的源路由的数据包带来问题，并且需要目前不可用的多播支持技术。
NOTE: Addition or removal of any security labels (BSO, ESO, CIPSO) by systems along a packet's path conflicts with the classification of these IP Options as immutable and is incompatible with the use of IPsec.
注意：系统沿数据包路径添加或删除任何安全标签（BSO、ESO、CIPSO）与这些IP选项的分类不一致，并且与IPsec的使用不兼容。
NOTE: End of Options List options SHOULD be repeated as necessary to ensure that the IP header ends on a 4 byte boundary in order to ensure that there are no unspecified bytes which could be used for a covert channel.
注意：应根据需要重复选项列表的结束选项，以确保IP标头在4字节边界上结束，以确保没有可用于隐蔽通道的未指定字节。
A2. IPv6 Extension Headers
A2。IPv6扩展头
This table shows how the IPv6 Extension Headers are classified with regard to "mutability".
此表显示了IPv6扩展头是如何根据“可变性”进行分类的。
Option/Extension Name Reference
----------------------------------- ---------
MUTABLE BUT PREDICTABLE -- included in ICV calculation
Routing (Type 0) [RFC1883]
Option/Extension Name Reference
----------------------------------- ---------
MUTABLE BUT PREDICTABLE -- included in ICV calculation
Routing (Type 0) [RFC1883]
BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING TRANSIT) Hop by Hop options [RFC1883] Destination options [RFC1883]
位指示选项是否可变（在传输过程中发生不可预测的变化）逐跳选项[RFC1883]目标选项[RFC1883]
NOT APPLICABLE Fragmentation [RFC1883]
不适用的碎片[RFC1883]
Options -- IPv6 options in the Hop-by-Hop and Destination Extension Headers contain a bit that indicates whether the option might change (unpredictably) during transit. For any option for which contents may change en-route, the entire "Option Data" field must be treated as zero-valued octets when computing or verifying the ICV. The Option Type and Opt Data Len are included in the ICV calculation. All options for which the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH95] for more information.
选项--逐跳和目标扩展标头中的IPv6选项包含一个位，指示该选项在传输过程中是否可能发生更改（不可预测）。对于内容可能在途中更改的任何选项，在计算或验证ICV时，必须将整个“选项数据”字段视为零值八位字节。期权类型和期权数据Len包含在ICV计算中。位表示不变性的所有选项都包括在ICV计算中。有关更多信息，请参阅IPv6规范[DH95]。
Routing (Type 0) -- The IPv6 Routing Header "Type 0" will rearrange the address fields within the packet during transit from source to destination. However, the contents of the packet as it will appear at the receiver are known to the sender and to all intermediate hops. Hence, the
路由（类型0）——IPv6路由报头“类型0”将在从源到目标的传输过程中重新排列数据包内的地址字段。然而，发送方和所有中间跳都知道数据包将在接收方出现的内容。因此
IPv6 Routing Header "Type 0" is included in the Authentication Data calculation as mutable but predictable. The sender must order the field so that it appears as it will at the receiver, prior to performing the ICV computation.
IPv6路由头“类型0”作为可变但可预测的内容包含在身份验证数据计算中。在执行ICV计算之前，发送方必须对字段进行排序，使其在接收方显示。
Fragmentation -- Fragmentation occurs after outbound IPsec processing (section 3.3) and reassembly occurs before inbound IPsec processing (section 3.4). So the Fragmentation Extension Header, if it exists, is not seen by IPsec.
碎片——碎片发生在出站IPsec处理（第3.3节）之后，重新组装发生在入站IPsec处理（第3.4节）之前。因此，IPsec看不到碎片扩展头（如果存在）。
Note that on the receive side, the IP implementation could leave a Fragmentation Extension Header in place when it does re-assembly. If this happens, then when AH receives the packet, before doing ICV processing, AH MUST "remove" (or skip over) this header and change the previous header's "Next Header" field to be the "Next Header" field in the Fragmentation Extension Header.
请注意，在接收端，IP实现在重新组装时可能会保留碎片扩展头。如果发生这种情况，那么当AH接收到数据包时，在进行ICV处理之前，AH必须“删除”（或跳过）该报头，并将先前报头的“下一个报头”字段更改为碎片扩展报头中的“下一个报头”字段。
Note that on the send side, the IP implementation could give the IPsec code a packet with a Fragmentation Extension Header with Offset of 0 (first fragment) and a More Fragments Flag of 0 (last fragment). If this happens, then before doing ICV processing, AH MUST first "remove" (or skip over) this header and change the previous header's "Next Header" field to be the "Next Header" field in the Fragmentation Extension Header.
请注意，在发送端，IP实现可以为IPsec代码提供一个数据包，该数据包具有偏移量为0（第一个片段）的分段扩展头和0（最后一个片段）的更多片段标志。如果发生这种情况，则在执行ICV处理之前，AH必须首先“删除”（或跳过）此标头，并将上一个标头的“下一个标头”字段更改为碎片扩展标头中的“下一个标头”字段。
References
工具书类
[ATK95] Atkinson, R., "The IP Authentication Header", RFC 1826, August 1995.
[ATK95]Atkinson，R.，“IP认证头”，RFC 1826，1995年8月。
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[Bra97]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[DH95] Deering, S., and B. Hinden, "Internet Protocol version 6 (IPv6) Specification", RFC 1883, December 1995.
[DH95]Deering，S.和B.Hinden，“互联网协议版本6（IPv6）规范”，RFC 1883，1995年12月。
[HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[HC98]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[KA97a] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[KA97a]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[KA97b] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[KA97b]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[MG97a] Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[MG97a]Madson，C.和R.Glenn，“HMAC-MD5-96在ESP和AH中的使用”，RFC 2403，1998年11月。
[MG97b] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[MG97b]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also:
http://www.iana.org/numbers.html
[STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also:
http://www.iana.org/numbers.html
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.
这里的观点和规范是作者的观点和规范，不一定是他们的雇主的观点和规范。作者及其雇主明确否认对因正确或不正确实施或使用本规范而产生的任何问题负责。
Author Information
作者信息
Stephen Kent BBN Corporation 70 Fawcett Street Cambridge, MA 02140 USA
美国马萨诸塞州剑桥福塞特街70号Stephen Kent BBN Corporation 02140
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Randall Atkinson @Home Network 425 Broadway, Redwood City, CA 94063 USA
美国加利福尼亚州红木市百老汇425号Randall Atkinson@Home Network，邮编94063
Phone: +1 (415) 569-5000
EMail: rja@corp.home.net
Phone: +1 (415) 569-5000
EMail: rja@corp.home.net
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。