IPsec Working Group S. Kent
Internet Draft BBN Technologies
Expires September 2002 March 2002
IP Authentication Header
draft-ietf-ipsec-rfc2402bis-00.txt
Status of This Memo
This document is an Internet Draft and is subject to all provisions
of Section 10 of RFC2026. Internet Drafts are working documents of
the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working
documents as Internet Drafts
Internet Drafts are draft documents valid for a maximum of 6 months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as a "work in progress".
The list of current Internet Drafts can be accessed at
http://www.ietf.org/lid-abstracts.html
The list of Internet Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document describes an updated version of the IP Authentication
Header (AH), which is designed to provide authentication services in
IPv4 and IPv6. This document is based upon RFC 2402 (November 1998)
[KA98c]. Section 7 provides a brief review of the differences
between this document and RFC 2402.
Comments should be sent to Stephen Kent (kent@bbn.com).
Kent [Page 1]
Internet Draft IP Authentication Header March 2002
Table of Contents
1. Introduction......................................................3
2. Authentication Header Format......................................4
2.1 Next Header...................................................5
2.2 Payload Length................................................5
2.3 Reserved......................................................5
2.4 Security Parameters Index (SPI)...............................5
2.5 Sequence Number...............................................6
2.5.1 Extended Sequence Number.................................6
2.6 Integrity Check Value (ICV) ..................................7
3. Authentication Header Processing..................................7
3.1 Authentication Header Location...............................7
3.1.1 Transport Mode..........................................7
3.1.2 Tunnel Mode.............................................8
3.2 Authentication Algorithms....................................9
3.3 Outbound Packet Processing...................................9
3.3.1 Security Association Lookup............................10
3.3.2 Sequence Number Generation.............................10
3.3.3 Integrity Check Value Calculation......................11
3.3.3.1 Handling Mutable Fields...........................11
3.3.3.1.1 ICV Computation for IPv4.....................12
3.3.3.1.1.1 Base Header Fields.......................12
3.3.3.1.1.2 Options..................................12
3.3.3.1.2 ICV Computation for IPv6.....................13
3.3.3.1.2.1 Base Header Fields.......................13
3.3.3.1.2.2 Extension Headers Containing Options.....13
3.3.3.1.2.3 Extension Headers Not Containing Options.13
3.3.3.2 Padding & Extended Sequence Numbers...............14
3.3.3.2.1 ICV Padding..................................14
3.3.3.2.2 Implicit Packet Padding & ESN................14
3.3.4 Fragmentation..........................................14
3.4 Inbound Packet Processing...................................15
3.4.1 Reassembly.............................................15
3.4.2 Security Association Lookup............................16
3.4.3 Sequence Number Verification...........................16
3.4.4 Integrity Check Value Verification.....................17
4. Auditing.........................................................18
5. Conformance Requirements.........................................19
6. Security Considerations..........................................19
7. Differences from RFC 1826........................................19
Acknowledgements....................................................19
References..........................................................20
Disclaimer..........................................................20
Author Information..................................................20
Appendix A -- Mutability of IP Options/Extension Headers............21
A1. IPv4 Options.................................................21
A2. IPv6 Extension Headers.......................................22
Appendix B -- Extended (64-bit) Sequence Numbers....................24
Full Copyright Statement............................................30
Kent [Page 2]
Internet Draft IP Authentication Header March 2002
1. Introduction
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.) However, to make use of a new, extended
sequence number feature in an interoperable fashion, AH does impose a
requirement on SA management protocols to be able to negotiate this
new feature (see Section 2.5.1 below).
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.
(See Appendix A.)
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 anti-replay and similar authentication 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 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].
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].)
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].
Kent [Page 3]
Internet Draft IP Authentication Header March 2002
2. Authentication Header Format
The protocol header (IPv4, IPv6, or IPv6 Extension) immediately
preceding the AH header will contain the value 51 in its Protocol
(IPv4) or Next Header (IPv6, Extension) field [STD-2].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Integrity Check Value-ICV (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following table refers to the fields in the preceding figure and
illustrates which fields are covered by the ICV and what is
transmitted.
What What
# of Requ'd Integ is
bytes [1] Covers Xmtd
------ ------ ------ ------
IP Header variable M [2] plain
Next Header 1 M Y plain
Payload Len 1 M Y plain
RESERVED 2 M Y plain
SPI 4 M Y plain
Seq# (low order 32-bits) 4 M Y plain
ICV variable M Y[3] plain
IP datagram [4] variable M or D Y plain
Seq# (high order 32-bits) 4 if ESN Y not xmtd
ICV Padding variable if need Y not xmtd
[1] - M = mandatory; D = dummy
[2] - See section 3.3.3 "Integrity Check Value Calculation" for
details of which IP header fields are covered.
[3] - Zero'd before ICV calculation (resulting ICV placed here
after calculation)
[4] - If tunnel mode -> IP datagram
If transport mode -> next header and data
Kent [Page 4]
Internet Draft IP Authentication Header March 2002
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).
2.1 Next Header
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 on the
web page of Internet Assigned Numbers Authority (IANA), e.g., a value
of 4 indicates IPv4, a value of 41 indicates IPv6, and a value of 6
indicates TCP.
2.2 Payload Length
This 8-bit field specifies the length of AH in 32-bit words (4-byte
units), minus "2". (This means of expressing the length of AH was
selected to allow its use as an IPv6 extension header. Thus the
length computation is consistent with the algorithm described in RFC
1883.) In the case of the "default" integrity algorithm, a 96-bit
authentication value plus the 3 32-bit word fixed portion, this
length field will be "4". See Section 2.6, "Integrity Check Value
(ICV)", for comments on padding of this field, and Section 3.3.3.2.1
"ICV Padding".
2.3 Reserved
This 16-bit field is reserved for future use. It MUST be set to
"zero." (Note that the value is included in the ICV calculation, but
is otherwise ignored by the recipient.)
2.4 Security Parameters Index (SPI)
The SPI is an arbitrary 32-bit value that is used by a receiver to
identify the SA to which an incoming packet is bound. For a unicast
SA, the SPI can be used by itself to specify an SA, or it may be used
in conjunction with the IPsec protocol type (in this case ESP).
Since the SPI value is generated by the receiver, whether the value
is sufficient to identify an SA by itself, or whether it must be used
in conjunction with the IPsec protocol value is a local matter. The
SPI field is mandatory.
For multicast SAs, the SPI (and optionally the protocol ID) in
combination with the destination address is used to select an SA.
This is because multicast SAs are defined by a multicast controller,
not by each IPsec receiver. (See the Security Architecture document
for more details.)
Kent [Page 5]
Internet Draft IP Authentication Header March 2002
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. 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 might
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.)
2.5 Sequence Number
This unsigned 32-bit field contains a counter value that increases by
one for each packet sent, i.e., a per-SA packet sequence number. For
a unicast SA or a single-sender multicast SA, the sender MUST
increment this field for every transmitted packet. Sharing an SA
among multiple senders is deprecated, since there is no general means
of synchronizing packet counters among the senders or meaningfully
managing a receiver packet counter and window in the context of
multiple senders.
The field is mandatory and MUST always be 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, but all AH implementations MUST be
capable of performing the Sequence Number processing described in
Section 3.3.2 "Sequence Number Generation" and Section 3.4.3
"Sequence Number Verification." Thus the sender MUST always transmit
this field, but the receiver need not act upon it.
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.
2.5.1 Extended (64-bit) Sequence Number
To support high-speed IPsec implementations, a new option for
sequence numbers SHOULD be offered, as an extension to the current,
32-bit sequence number field. Use of an Extended Sequence Number
(ESN) SHOULD be negotiated by an SA management protocol, although it
could also be part of the configuration data for a manually
configured SA.
Kent [Page 6]
Internet Draft IP Authentication Header March 2002
The ESN facility allows use of a 64-bit sequence number for an SA.
(See Appendix B, "Managing 64-bit Sequence Numbers", for details.)
Only the low order 32 bits of the sequence number are transmitted in
the AH header of each packet, thus minimizing packet overhead. The
high order 32 bits are maintained as part of the sequence number
counter by both transmitter and receiver and are included in the
computation of the ICV, but are not transmitted.
2.6 Integrity Check Value (ICV)
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 (IPv4) or 64 bits (IPv6) in length. The details of ICV
processing are described in Section 3.3.3 "Integrity Check Value
Calculation" and Section 3.4.4 "Integrity Check Value Verification."
This field may include explicit padding, if required 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 in Section 3.3.3.2 "Padding". The authentication algorithm
specification MUST specify the length of the ICV and the comparison
rules and processing steps for validation.
3. Authentication Header Processing
3.1 Authentication Header Location
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.)
3.1.1 Transport Mode
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
Kent [Page 7]
Internet Draft IP Authentication Header March 2002
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.
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
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
before or after or both before and after the AH header depending on
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 |
------------------------------------------------------------
|<---- 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.
3.1.2 Tunnel Mode
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).
Kent [Page 8]
Internet Draft IP Authentication Header March 2002
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.
------------------------------------------------
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 ->|
* = construction of outer IP hdr/extensions and modification
of inner IP hdr/extensions is discussed below.
3.2 Authentication Algorithms
The authentication 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 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 integrity algorithms are described in Section
5 "Conformance Requirements". Other algorithms MAY be supported.
3.3 Outbound Packet Processing
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.
Kent [Page 9]
Internet Draft IP Authentication Header March 2002
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.)
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) 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 3.4.3) or if the SA was
configured using manual key management. Thus typical behavior of an
ESP 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.
If ESN (see Appendix B) is selected, only the low order 32 bits of
Kent [Page 10]
Internet Draft IP Authentication Header March 2002
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.
3.3.3 Integrity Check Value Calculation
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 (low order 32 bits), 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
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 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
gchanged 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.
Kent [Page 11]
Internet Draft IP Authentication Header March 2002
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)
Type of Service (TOS)
Flags
Fragment Offset
Time to Live (TTL)
Header Checksum
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.
Flags -- This field is excluded since 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
changes, 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
Kent [Page 12]
Internet Draft IP Authentication Header March 2002
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 (This should be the value for AH.)
Source Address
Destination Address (without Routing Extension Header)
Mutable but predictable
Destination Address (with Routing Extension Header)
Mutable (zeroed prior to ICV calculation)
Class
Flow Label
Hop Limit
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 [DH95] 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.
Kent [Page 13]
Internet Draft IP Authentication Header March 2002
3.3.3.2 Padding & 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 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
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.
3.3.3.2.2 Implicit Packet Padding & 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. Note that MD5 and SHA-1
are viewed as having a 1-byte blocksize because of their internal
padding conventions and thus no implicit packet padding is required.
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 IP packet to which AH
has been applied may itself be fragmented by routers en route, and
Kent [Page 14]
Internet Draft IP Authentication Header March 2002
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.
NOTE: For transport mode -- As mentioned at the beginning of Section
3.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 ESP receiver to accept
fragments for reassembly creates denial of service vulnerabilities.
Thus an ESP implementation MAY choose to not support fragmentation
and may mark transmitted packets with the DF bit, to facilitate PMTU
discovery. In any case, an ESP 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 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.
NOTE: For packet reassembly, the current IPv4 spec does NOT require
either the zeroing of the OFFSET field or the clearing of the MORE
Kent [Page 15]
Internet Draft IP Authentication Header March 2002
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, 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 and whether 32 or 64-bit Sequence Numbers are employed for
the SA, specifies the algorithm(s) employed for ICV computation, and
indicates the key(s) required to validate the ICV.
If no valid Security Association exists for this session (e.g., the
receiver has no key to use in the ICV computation) 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.
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.
(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.)
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.
Kent [Page 16]
Internet Draft IP Authentication Header March 2002
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, 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 resynchronization 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
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.
Kent [Page 17]
Internet Draft IP Authentication Header March 2002
Details of the computation are provided below.
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.
DISCUSSION:
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.
Kent [Page 18]
Internet Draft IP Authentication Header March 2002
5. Conformance Requirements
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:
- HMAC with MD5 [MG97a]
- HMAC with SHA-1 [MG97b]
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 1826
This document differs from RFC 2402 in the following ways.
o SPI -- modified to better reflect the differences between
unicast and multicast SA lookups. For unicast, the SPI may be
used alone to select an SA; for multicast, the SPI is combined
with destination address to select an SA.
o Sequence number -- added a new option for a 64-bit sequence
number for very high-speed communications.
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 working group.
Kent [Page 19]
Internet Draft IP Authentication Header March 2002
References
[ATK95] Atkinson, R., "The IP Authentication Header", RFC 1826,
August 1995.
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[DH95] Deering, S., and B. Hinden, "Internet Protocol version 6
(IPv6) Specification", RFC 1883, December 1995.
[HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[KA98a] Kent, S., and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[KA98b] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[KA98c] Kent, S., and R. Atkinson, "IP Authentication Header (AH)",
RFC 2402, November 1998.
[MG97a] Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within ESP
and AH", RFC 2403, November 1998.
[MG97b] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
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 Technologies
10 Moulton Street
Cambridge, MA 02138
USA
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Kent [Page 20]
Internet Draft IP Authentication Header March 2002
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 RFC1700, "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 [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 Protocol [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
Kent [Page 21]
Internet Draft IP Authentication Header March 2002
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.
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 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.
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.
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) [RFC1883]
BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING
TRANSIT)
Hop by Hop options [RFC1883]
Destination options [RFC1883]
NOT APPLICABLE
Fragmentation [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.
Routing (Type 0) -- The IPv6 Routing Header "Type 0" will
rearrange the address fields within the packet during transit from
Kent [Page 22]
Internet Draft IP Authentication Header March 2002
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 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.
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.
Kent [Page 23]
Internet Draft IP Authentication Header March 2002
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:
Kent [Page 24]
Internet Draft IP Authentication Header March 2002
+ 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 zero's 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,
Kent [Page 25]
Internet Draft IP Authentication Header March 2002
+ 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 Section 2.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 Section 2.2. below for
determination of Seqh).
B2.2. Determining the Higher Order Bits (Seqh) of the Sequence Number
Since 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
Section 3 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
If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th + 1
+ Under Case B (Figure 2):
If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th - 1
If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th
B2.3. Pseudo-code Example
The following pseudo-code illustrates the above algorithms for anti-
replay and integrity checks. The values for `Seql', `Tl', `Th' and
`W', are 32-bit unsigned integers. Arithmetic is mod 2^32.
Kent [Page 26]
Internet Draft IP Authentication Header March 2002
If (Tl >= W - 1) Case A
If (Seql >= Tl - W + 1)
Seqh = Th
If (Seql <= Tl)
If (pass replay check)
If (pass integrity check)
Set bit corresponding to Seql
Pass the packet on
Else reject packet
Else reject packet
Else
If (pass integrity check)
Tl = Seql (shift bits)
Set bit corresponding to Seql
Pass the packet on
Else reject packet
Else
Seqh = Th + 1
If (pass integrity check)
Tl = Seql (shift bits)
Th = Th + 1
Set bit corresponding to Seql
Pass the packet on
Else reject packet
Else Case B
If (Seql >= Tl - W + 1)
Seqh = Th - 1
If (pass replay check)
If (pass integrity check)
Set the bit corresponding to Seql
Pass packet on
Else reject packet
Else reject packet
Else
If (Seql <= Tl)
If (pass replay check)
If (pass integrity check)
Set the bit corresponding to Seql
Pass packet on
Else reject packet
Else reject packet
Else
If (pass integrity check)
Tl = Seql (shift bits)
Set the bit corresponding to Seql
Pass packet on
Else reject packet
Kent [Page 27]
Internet Draft IP Authentication Header March 2002
B3. Handling Loss of Synchronization due to Significant Packet Loss
If there is an undetected packet loss of 2^32 or more consecutive
packets on a single SA, then the transmitter and receiver will lose
synchronization of the high order bits, i.e., the equations in
Section 2.2. will fail to yield the correct value. Unless this
problem is detected and addressed, subsequent packets on this SA will
fail authentication checks and be discarded. The following procedure
SHOULD be implemented by any IPsec (ESP or AH) implementation that
supports the ESN option.
Note that this sort of extended traffic loss seems unlikely to occur
if any significant fraction of the traffic on the SA in question is
TCP, because the source would fail to receive ACKs and would stop
sending long before 2^32 packets had been lost. Also, for any bi-
directional application, even ones operating above UDP, such an
extended outage would likely result in triggering some form of
timeout. However, a unidirectional application, operating over UDP
might lack feedback that would cause automatic detection of a loss of
this magnitude, hence the motivation to develop a recovery method for
this case.
The solution we've chosen was selected to:
+ minimize the impact on normal traffic processing
+ avoid creating an opportunity for a new denial of service attack
such as might occur by allowing an attacker to force diversion of
resources to a resynchronization process.
+ limit the recovery mechanism to the receiver -- since anti-replay
is a service only for the receiver, and the transmitter generally
is not aware of whether the receiver is using sequence numbers in
support of this optional service, it is preferable for recovery
mechanisms to be local to the receiver. This also allows for
backwards compatibility.
B3.1. Triggering Resynchronization
For each SA, the receiver records the number of consecutive packets
that fail authentication. This count is used to trigger the
resynchronization process which should be performed in the background
or using a separate processor. Receipt of a valid packet on the SA
resets the counter to zero. The value used to trigger the
resynchronization process is a local parameter. There is no
requirement to support distinct trigger values for different SAs,
although an implementer may choose to do so.
Kent [Page 28]
Internet Draft IP Authentication Header March 2002
B3.2. Resynchronization Process
When the above trigger point is reached, a "bad" packet is selected
for which authentication is retried using successively larger values
for the upper half of the sequence number (Seqh). These values are
generated by incrementing by one for each retry. The number of
retries should be limited, in case this is a packet from the "past"
or a bogus packet. The limit value is a local parameter. (Because
the Seqh value is implicitly placed after the ESP (or AH) payload, it
may be possible to optimize this procedure by executing the integrity
algorithm over the packet up to the end point of the payload, then
compute different candidate ICV's by varying the value of Seqh.)
Successful authentication of a packet via this procedure resets the
consecutive failure count and sets the value of T to that of the
received packet.
This solution requires support only on the part of the receiver,
thereby allowing for backwards compatibility. Also, because
resynchronization efforts would either occur in the background or
utilize an additional processor, this solution does not impact
traffic processing and a denial of service attack cannot divert
resources away from traffic processing.
Kent [Page 29]
Internet Draft IP Authentication Header March 2002
Copyright (C) The Internet Society (2002). All Rights Reserved.
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.
Expires September 2002
Kent [Page 30]
