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.) The receive window size should be increased for higher-speed
environments, irrespective of assurance issues. Values for minimum
and recommended receive window sizes for very high-speed (e.g.,
multi-gigabit/second) devices are not specified by this standard.
3.4.4. Integrity Check Value Verification
The receiver computes the ICV over the appropriate fields of the
packet, using the specified integrity algorithm, and verifies that it
is the same as the ICV included in the ICV field of the packet.
Details of the computation are provided below.
If the computed and received ICVs 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.
Implementation Note:
Implementations can use any set of steps that results in the same
result as the following set of steps. Begin by saving the ICV
value and replacing it (but not any ICV field padding) with zero.
Zero all other fields that may have been modified during transit.
(See Section 3.3.3.1, "Handling Mutable Fields", for a discussion
of which fields are zeroed before performing the ICV calculation.)
If the ESN option is elected for this SA, append the high-order 32
bits of the ESN after the end of the packet. Check the overall
length of the packet (as described above), and if it requires
implicit padding based on the requirements of the integrity
algorithm, append zero-filled bytes to the end of the packet
(after the ESN if present) 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.)
4. Auditing
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
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.
5. Conformance Requirements
Implementations that claim conformance or compliance with this
specification MUST fully implement the AH syntax and processing
described here for unicast traffic, and MUST comply with all
requirements of the Security Architecture document [Ken-Arch].
Additionally, if an implementation claims to support multicast
traffic, it MUST comply with the additional requirements specified
for support of such traffic. 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.
The mandatory-to-implement algorithms for use with AH are described
in a separate RFC [Eas04], to facilitate updating the algorithm
requirements independently from the protocol per se. Additional
algorithms, beyond those mandated for AH, MAY be supported.
6. Security Considerations
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.
7. Differences from RFC 2402
This document differs from RFC 2402 [RFC2402] in the following ways.
o SPI -- modified to specify a uniform algorithm for SAD lookup
for unicast and multicast SAs, covering a wider range of
multicast technologies. For unicast, the SPI may be used
alone to select an SA, or may be combined with the protocol,
at the option of the receiver. For multicast SAs, the SPI is
combined with the destination address, and optionally the
source address, to select an SA.
o Extended Sequence Number -- added a new option for a 64-bit
sequence number for very high-speed communications. Clarified
sender and receiver processing requirements for multicast SAs
and multi-sender SAs.
o Moved references to mandatory algorithms to a separate
document [Eas04].
8. Acknowledgements
The author would like to acknowledge the contributions of Ran
Atkinson, who played a critical role in initial IPsec activities, and
who authored the first series of IPsec standards: RFCs 1825-1827.
Karen Seo deserves special thanks for providing help in the editing
of this and the previous version of this specification. The author
also would like to thank the members of the IPsec and MSEC working
groups who have contributed to the development of this protocol
specification.
9. References
9.1. Normative References
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[DH98] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[Eas04] 3rd Eastlake, D., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4305, December 2005.
[Ken-Arch] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC1108] Kent, S., "U.S. Department of Defense Security Options for
the Internet Protocol", RFC 1108, November 1991.
9.2. Informative References
[AES] Advanced Encryption Standard (AES), Federal Information
Processing Standard 197, National Institutes of Standards
and Technology, November 26, 2001.
[HC03] Holbrook, H. and B. Cain, "Source Specific Multicast for
IP", Work in Progress, November 3, 2002.
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[Ken-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[NBBB98] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[RFB01] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.
[RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP
MTU discovery options", RFC 1063, July 1988.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1385] Wang, Z., "EIP: The Extended Internet Protocol", RFC 1385,
November 1992.
[RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393,
January 1993.
[RFC1770] Graff, C., "IPv4 Option for Sender Directed Multi-
Destination Delivery", RFC 1770, March 1995.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February
1997.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004.
Appendix A: Mutability of IP Options/Extension Headers
A1. IPv4 Options
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 RFC 1700, "ASSIGNED NUMBERS", (October 1994).
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
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 Protocol [RFC1385, DH98 (IPv6)]
0 0 10 Experimental Measurement
1 2 13 Experimental Flow Control
1 0 14 Experimental Access Ctl
0 0 15 ???
1 0 16 IMI Traffic Descriptor
1 0 19 Address Extension
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., Resource Reservation Protocol (RSVP)/Internet Group
Management Protocol (IGMP)), the packet should encounter AH
processing. 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.
NOTE: Addition or removal of security labels (e.g., Basic Security
Option (BSO), Extended Security Option (ESO), or Commercial Internet
Protocol Security Option (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.
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 that could be used for a
covert channel.
A2. IPv6 Extension Headers
This table shows how the IPv6 extension headers are classified with
regard to "mutability".
Option/Extension Name Reference
----------------------------------- ---------
MUTABLE BUT PREDICTABLE -- included in ICV calculation
Routing (Type 0) [DH98]
BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING
TRANSIT)
Hop-by-Hop options [DH98]
Destination options [DH98]
NOT APPLICABLE
Fragmentation [DH98]
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.
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 IPv6 Routing Header "Type 0" is
included in the Integrity Check Value 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.
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.
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.
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.
Appendix B: Extended (64-bit) Sequence Numbers
B1. Overview
This appendix describes an Extended Sequence Number (ESN) scheme for
use with IPsec (ESP and AH) that employs a 64-bit sequence number,
but in which only the low-order 32 bits are transmitted as part of
each packet. It covers both the window scheme used to detect
replayed packets and the determination of the high-order bits of the
sequence number that are used both for replay rejection and for
computation of the ICV. It also discusses a mechanism for handling
loss of synchronization relative to the (not transmitted) high-order
bits.
B2. Anti-Replay Window
The receiver will maintain an anti-replay window of size W. This
window will limit how far out of order a packet can be, relative to
the packet with the highest sequence number that has been
authenticated so far. (No requirement is established for minimum or
recommended sizes for this window, beyond the 32- and 64-packet
values already established for 32-bit sequence number windows.
However, it is suggested that an implementer scale these values
consistent with the interface speed supported by an implementation
that makes use of the ESN option. Also, the algorithm described
below assumes that the window is no greater than 2^31 packets in
width.) All 2^32 sequence numbers associated with any fixed value
for the high-order 32 bits (Seqh) will hereafter be called a sequence
number subspace. The following table lists pertinent variables and
their definitions.
Var. Size
Name (bits) Meaning
---- ------ ---------------------------
W 32 Size of window
T 64 Highest sequence number authenticated so far,
upper bound of window
Tl 32 Lower 32 bits of T
Th 32 Upper 32 bits of T
B 64 Lower bound of window
Bl 32 Lower 32 bits of B
Bh 32 Upper 32 bits of B
Seq 64 Sequence Number of received packet
Seql 32 Lower 32 bits of Seq
Seqh 32 Upper 32 bits of Seq
When performing the anti-replay check, or when determining which
high-order bits to use to authenticate an incoming packet, there are
two cases:
+ Case A: Tl >= (W - 1). In this case, the window is within one
sequence number subspace. (See Figure 1)
+ Case B: Tl < (W - 1). In this case, the window spans two
sequence number subspaces. (See Figure 2)
In the figures below, the bottom line ("----") shows two consecutive
sequence number subspaces, with zeros indicating the beginning of
each subspace. The two shorter lines above it show the higher-order
bits that apply. The "====" represents the window. The "****"
represents future sequence numbers, i.e., those beyond the current
highest sequence number authenticated (ThTl).
Th+1 *********
Th =======*****
--0--------+-----+-----0--------+-----------0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 1 -- Case A
Th ====**************
Th-1 ===
--0-----------------+--0--+--------------+--0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 2 -- Case B
B2.1. Managing and Using the Anti-Replay Window
The anti-replay window can be thought of as a string of bits where
`W’ defines the length of the string. W = T - B + 1 and cannot
exceed 2^32 - 1 in value. The bottom-most bit corresponds to B and
the top-most bit corresponds to T, and each sequence number from Bl
through Tl is represented by a corresponding bit. The value of the
bit indicates whether or not a packet with that sequence number has
been received and authenticated, so that replays can be detected and
rejected.
When a packet with a 64-bit sequence number (Seq) greater than T is
received and validated,
+ B is increased by (Seq - T)
+ (Seq - T) bits are dropped from the low end of the window
+ (Seq - T) bits are added to the high end of the window
+ The top bit is set to indicate that a packet with that sequence
number has been received and authenticated
+ The new bits between T and the top bit are set to indicate that
no packets with those sequence numbers have been received yet.
+ T is set to the new sequence number
In checking for replayed packets,
+ Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND
Seql <= Tl, then check the corresponding bit in the window to
see if this Seql has already been seen. If yes, reject the
packet. If no, perform integrity check (see Appendix B2.2
below for determination of SeqH).
+ Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR
Seql <= Tl, then check the corresponding bit in the window to
see if this Seql has already been seen. If yes, reject the
packet. If no, perform integrity check (see Appendix B2.2
below for determination of Seqh).
B2.2. Determining the Higher-Order Bits (Seqh) of the Sequence Number
Because only `Seql’ will be transmitted with the packet, the receiver
must deduce and track the sequence number subspace into which each
packet falls, i.e., determine the value of Seqh. The following
equations define how to select Seqh under "normal" conditions; see
Appendix B3 for a discussion of how to recover from extreme packet
loss.
+ Under Case A (Figure 1):
If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th