the semantics desired. The following diagram illustrates AH
transport mode positioning for a typical IPv6 packet.
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 |
------------------------------------------------------------
|<--- mutable field processing -->|<-- immutable fields -->|
|<---- authenticated except for mutable fields ----------->|
* = if present, could be before AH, after AH, or both
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.
Note that in transport mode, 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.
3.1.2. Tunnel Mode
In tunnel mode, the "inner" IP header carries the ultimate (IP)
source and destination addresses, while an "outer" IP header contains
the addresses of the IPsec "peers," e.g., addresses of security
gateways. Mixed inner and outer IP versions are allowed, i.e., IPv6
over IPv4 and IPv4 over IPv6. 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.
----------------------------------------------------------------
IPv4 | | | orig IP hdr* | | |
|new IP header * (any options) | AH | (any options) |TCP| Data |
----------------------------------------------------------------
|<- mutable field processing ->|<------ immutable fields ----->|
|<- 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|
--------------------------------------------------------------
|<--- mutable field -->|<--------- immutable fields -------->|
| processing |
|<-- authenticated except for mutable fields in new IP hdr ->|
* = if present, construction of outer IP hdr/extensions and
modification of inner IP hdr/extensions is discussed in
the Security Architecture document.
3.2. Integrity Algorithms
The integrity algorithm employed for the ICV computation is specified
by the SA. For point-to-point communication, suitable integrity
algorithms include keyed Message Authentication Codes (MACs) based on
symmetric encryption algorithms (e.g., AES [AES]) or on one-way hash
functions (e.g., MD5, SHA-1, SHA-256, etc.). For multicast
communication, a variety of cryptographic strategies for providing
integrity have been developed and research continues in this area.
3.3. Outbound Packet Processing
In transport mode, the sender inserts the AH header after the IP
header and before a next layer protocol header, as described above.
In tunnel mode, the outer and inner IP header/extensions can be
interrelated in a variety of ways. The construction of the outer IP
header/extensions during the encapsulation process is described in
the Security Architecture document.
3.3.1. Security Association Lookup
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.
3.3.2. Sequence Number Generation
The sender’s counter is initialized to 0 when an SA is established.
The sender increments the sequence number (or ESN) counter for this
SA and inserts the low-order 32 bits of the value into the Sequence
Number field. Thus, the first packet sent using a given SA will
contain a sequence number of 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. The audit log entry for this event
SHOULD include the SPI value, current date/time, Source Address,
Destination Address, and (in IPv6) the cleartext Flow ID.
The sender assumes anti-replay is enabled as a default, unless
otherwise notified by the receiver (see Section 3.4.3) or if the SA
was configured using manual key management. Thus, typical behavior
of an AH implementation calls for the sender to establish a new SA
when the Sequence Number (or ESN) cycles, or in anticipation of this
value cycling.
If anti-replay is disabled (as noted above), 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. (This behavior is recommended for multi-sender,
multicast SAs, unless anti-replay mechanisms outside the scope of
this standard are negotiated between the sender and receiver.)
If ESN (see Appendix B) is selected, only the low-order 32 bits of
the sequence number are transmitted in the Sequence Number field,
although both sender and receiver maintain full 64-bit ESN counters.
However, the high-order 32 bits are included in the ICV calculation.
Note: If a receiver chooses not to enable anti-replay for an SA, then
the receiver SHOULD NOT negotiate ESN in an SA management protocol.
Use of ESN creates a need for the receiver to manage the anti-replay
window (in order to determine the correct value for the high-order
bits of the ESN, which are employed in the ICV computation), which is
generally contrary to the notion of disabling anti-replay for an SA.
3.3.3. Integrity Check Value Calculation
The AH ICV is computed over:
o IP or extension header fields before the AH header 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 (low-order 32 bits), and the ICV (which is set
to zero for this computation), and explicit padding bytes (if
any))
o everything after AH is assumed to be immutable in transit
o the high-order bits of the ESN (if employed), and any implicit
padding required by the integrity algorithm
3.3.3.1. Handling Mutable Fields
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 Integrity Check Value 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.
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 the Hop-by-Hop Extension Header)
contain a flag indicating mutability, which determines appropriate
processing for such options.
3.3.3.1.1. ICV Computation for IPv4
3.3.3.1.1.1. Base Header Fields
The IPv4 base header fields are classified as follows:
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)
Mutable but predictable
Destination Address (with loose or strict source routing)
Mutable (zeroed prior to ICV calculation)
Differentiated Services Code Point (DSCP)
(6 bits, see RFC 2474 [NBBB98])
Explicit Congestion Notification (ECN)
(2 bits, see RFC 3168 [RFB01])
Flags
Fragment Offset
Time to Live (TTL)
Header Checksum
DSCP - Routers may rewrite the DS field as needed to provide a
desired local or end-to-end service, thus its value upon reception
cannot be predicted by the sender.
ECN - This will change if a router along the route experiences
congestion, and thus its value upon reception cannot be predicted by
the sender.
Flags - This field is excluded because an intermediate router might
set the DF bit, even if the source did not select it.
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).
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.
Header Checksum - This will change if any of these other fields
change, and thus its value upon reception cannot be predicted by the
sender.
3.3.3.1.1.2. Options
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.
3.3.3.1.2. ICV Computation for IPv6
3.3.3.1.2.1. Base Header Fields
The IPv6 base header fields are classified as follows:
Immutable
Version
Payload Length
Next Header
Source Address
Destination Address (without Routing Extension Header)
Mutable but predictable
Destination Address (with Routing Extension Header)
Mutable (zeroed prior to ICV calculation)
DSCP (6 bits, see RFC2474 [NBBB98])
ECN (2 bits, see RFC3168 [RFB01])
Flow Label (*)
Hop Limit
(*) The flow label described in AHv1 was mutable, and in
RFC 2460 [DH98] was potentially mutable. To retain
compatibility with existing AH implementations, the
flow label is not included in the ICV in AHv2.
3.3.3.1.2.2. Extension Headers Containing 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 [DH98] for more
information.
3.3.3.1.2.3. Extension Headers Not Containing Options
The IPv6 extension headers that do not contain options are explicitly
listed in Appendix A and classified as immutable, mutable but
predictable, or mutable.
3.3.3.2. Padding and Extended Sequence Numbers
3.3.3.2.1. ICV Padding
As mentioned in Section 2.6, the ICV field may include explicit
padding if required 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:
- the length of the ICV
- the IP protocol version (v4 or v6)
For example, if the output of the selected algorithm is 96 bits, no
padding is required for IPv4 or 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 ICV calculation,
counted as part of the Payload Length, and transmitted at the end of
the ICV field to enable the receiver to perform the ICV calculation.
Inclusion of padding in excess of the minimum amount required to
satisfy IPv4/IPv6 alignment requirements is prohibited.
3.3.3.2.2. Implicit Packet Padding and ESN
If the ESN option is elected for an SA, then the high-order 32 bits
of the ESN must be included in the ICV computation. For purposes of
ICV computation, these bits are appended (implicitly) immediately
after the end of the payload, and before any implicit packet padding.
For some integrity 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 and the 32
high-order bits of the ESN, if enabled) 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. The document that
defines an integrity algorithm MUST be consulted to determine if
implicit padding is required as described above. If the document
does not specify an answer to this, then the default is to assume
that implicit padding is required (as needed to match the packet
length to the algorithm’s blocksize.) If padding bytes are needed
but the algorithm does not specify the padding contents, then the
padding octets MUST have a value of zero.
3.3.4. Fragmentation
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 IPv4 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. (This does not apply to IPv6, where there is no router-
initiated fragmentation.) 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.
NOTE: For transport mode -- As mentioned at the end of Section 3.1.1,
bump-in-the-stack and bump-in-the-wire implementations may have to
first reassemble a packet fragmented by the local IP layer, then
apply IPsec, and then fragment the resulting packet.
NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire
implementations, it will be necessary to examine all the extension
headers to determine if there is a fragmentation header and hence
that the packet needs reassembling prior to IPsec processing.
Fragmentation, whether performed by an IPsec implementation or by
routers along the path between IPsec peers, significantly reduces
performance. Moreover, the requirement for an AH receiver to accept
fragments for reassembly creates denial of service vulnerabilities.
Thus, an AH implementation MAY choose to not support fragmentation
and may mark transmitted packets with the DF bit, to facilitate Path
MTU (PMTU) discovery. In any case, an AH implementation MUST support
generation of ICMP PMTU messages (or equivalent internal signaling
for native host implementations) to minimize the likelihood of
fragmentation. Details of the support required for MTU management
are contained in the Security Architecture document.
3.4. Inbound Packet Processing
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.
3.4.1. Reassembly
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 nonzero 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.
NOTE: For packet reassembly, the current IPv4 spec does NOT require
either the zeroing 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.
3.4.2. Security Association Lookup
Upon receipt of a packet containing an IP Authentication Header, the
receiver determines the appropriate (unidirectional) SA via lookup in
the SAD. For a unicast SA, this determination is based on the SPI or
the SPI plus protocol field, as described in Section 2.4. If an
implementation supports multicast traffic, the destination address is
also employed in the lookup (in addition to the SPI), and the sender
address also may be employed, as described in Section 2.4. (This
process is described in more detail in the Security Architecture
document.) The SAD entry for the SA also indicates whether the
Sequence Number field will be checked and whether 32- or 64-bit
sequence numbers are employed for the SA. The SAD entry for the SA
also specifies the algorithm(s) employed for ICV computation, and
indicates the key required to validate the ICV.
If no valid Security Association exists for this packet 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.
(Note that SA management traffic, such as IKE packets, does not need
to be processed based on SPI, i.e., one can de-multiplex this traffic
separately based on Next Protocol and Port fields, for example.)
3.4.3. Sequence Number Verification
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.
Anti-replay is applicable to unicast as well as multicast SAs.
However, this standard specifies no mechanisms for providing anti-
replay for a multi-sender SA (unicast or multicast). In the absence
of negotiation (or manual configuration) of an anti-replay mechanism
for such an SA, it is recommended that sender and receiver checking
of the Sequence Number for the SA be disabled (via negotiation or
manual configuration), as noted below.
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, "Sequence Number Generation"), 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.
If the receiver has enabled the anti-replay service for this SA, the
receive 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.
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.
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.
If the ESN option is selected for an SA, only the low-order 32 bits
of the sequence number are explicitly transmitted, but the receiver
employs the full sequence number computed using the high-order 32
bits for the indicated SA (from his local counter) when checking the
received Sequence Number against the receive window. In constructing
the full sequence number, if the low-order 32 bits carried in the
packet are lower in value than the low-order 32 bits of the
receiver’s sequence number counter, the receiver assumes that the
high-order 32 bits have been incremented, moving to a new sequence
number subspace. (This algorithm accommodates gaps in reception for
a single SA as large as 2**32-1 packets. If a larger gap occurs,
additional, heuristic checks for re-synchronization of the receiver’s
sequence number counter MAY be employed, as described in Appendix B.)
If the received packet falls within the window and is not a
duplicate, 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.
A MINIMUM window size of 32 packets MUST be supported, but a window