Skip to main content

3.3.3. Integrity Check Value Calculation

The AH ICV is computed over:

  • 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
  • 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))
  • everything after AH is assumed to be immutable in transit
  • 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.

Last updated on