WDIFF

draft-ietf-ipsec-auth-header-00.txt --> draft-ietf-ipsec-auth-header-01.txt

Network Working Group Randall Atkinson Stephen Kent, BBN Corp
Internet Draft cisco Systems
draft-ietf-ipsec-auth-header-00.txt 4 June 1996 Randall Atkinson, @Home Network
draft-ietf-ipsec-auth-header-01.txt July 21 1997

IP Authentication Header

STATUS OF THIS MEMO

Status of This Memo

This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its working groups. 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.
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts
as reference material or to cite them other than as a "working draft"
or "work in progress". Please check the I-D abstract listing
contained in each Internet Draft directory to learn the current
status of this or any other Internet Draft.

This particular Internet Draft is a product of the IETF's IPng and IPsec
Working Groups. Group. It is intended that a future version of this draft
will be submitted for consideration as a standards-track document.
Distribution of this document is unlimited.

0. ABSTRACT
This document describes a mechanism for providing cryptographic
authentication for IPv4 and IPv6 datagrams. An

Kent, Atkinson [Page 1]

Internet Draft IP Authentication Header
(AH) is inserted after the IP header being authenticated and before
the other information being authenticated. 21 July, 1997

Table of Contents

1. INTRODUCTION

The Introduction......................................................3
2. Authentication Header is a mechanism for providing strong
integrity, authentication, and replay protection for IP datagrams.

Confidentiality, and protection from traffic analysis are not
provided by the Format......................................4
2.1 Next Header...................................................4
2.2 Payload Length................................................4
2.3 Reserved......................................................5
2.4 Security Parameters Index (SPI)...............................5
2.5 Sequence Number...............................................5
2.6 Authentication Header. Users desiring
confidentiality should consider using the IP Encapsulating Data ..........................................5
3. Authentication Header Processing..................................6
3.1 Authentication Header Location...............................6
3.2 Outbound Packet Processing...................................8
3.2.1 Security
Protocol (ESP) either in lieu of or in conjunction with the Association Lookup.............................8
3.2.2 Sequence Number Generation..............................8
3.2.3 Integrity Check Value Calculation.......................9
3.2.3.1 Handling Mutable Fields............................9
3.2.3.1.1 ICV Computation for IPv4......................9
3.2.3.1.1.1 Base Header Fields........................9
3.2.3.1.1.2 Options..................................10
3.2.3.1.2 ICV Computation for IPv6.....................10
3.2.3.1.2.1 Base Header Fields.......................10
3.2.3.1.2.2 Extension Headers -- Options.............11
3.2.3.1.2.3 Extension Headers -- non-Options.........11
3.2.3.2 Padding...........................................11
3.2.3.2.1 Authentication Header. [Atk95b] This document assumes the reader has Data Padding..................11
3.2.3.2.2 Implicit Packet Padding......................12
3.2.3.3 Authentication Algorithms.........................12
3.2.4 Fragmentation..........................................12
3.3 Inbound Packet Processing...................................13
3.3.1 Reassembly.............................................13
3.3.2 Security Association Lookup............................13
3.3.3 Sequence Number Verification...........................13
3.3.4 Integrity Check Value Verification.....................14
4. Auditing.........................................................15
5. Conformance Requirements.........................................15
6. Security Considerations..........................................16
7. Differences from RFC 1826........................................16
Acknowledgements....................................................17
Appendix A -- Mutability of IP Options/Extension Headers............18
1. IPv4 Options..................................................18
2. IPv6 Extension Headers........................................19
References..........................................................21
Disclaimer..........................................................22
Author Information..................................................22

Kent, Atkinson [Page 1] 2]

Internet Draft IP Authentication Header 4 June 1996

previously read the related IP Security Architecture document which
defines the overall security architecture for IP and provides
important background information for this specification. [Atk95a]

1.1 Overview 21 July, 1997

1. Introduction

The IP Authentication Header seeks (AH) is used to provide security by adding connectionless
integrity and data origin authentication information to an for IP datagram. datagrams (hereafter
referred to as just "authentication"), and to provide protection
against replays. This authentication
information latter, optional service may be selected, by
the receiver, when a Security Association is calculated using all established. 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 IP datagram
(including not only value of these fields, when the IP Header but also other headers and
packet arrives at the user
data) which do receiver, may not change in transit. Fields or options which need
to change in transit (e.g "hop count", "time to live", "ident",
"fragment offset", or "routing pointer") are considered to be zero
for predictable by the calculation
transmitter. The values of such fields cannot be protected by AH.
Thus the authentication data. This provides
significantly more security than protection provided to the IP header by AH is currently present in IPv4 and
might somewhat
piecemeal.

AH may be sufficient 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 needs Internet
Protocol" [KA97a], hereafter referred to as the Security Architecture
document). Security services can be provided between a pair of many users.

Use
communicating hosts, between a pair of this specification will increase communicating security
gateways, or between a security gateway and a host. ESP may be used
to provide the IP protocol processing
costs in participating end systems same security services, and will it also increase the
communications latency. provides a
confidentiality (encryption) service. The increased latency is primarily due to
the calculation of primary difference between
the authentication data provided by the sender ESP and AH is the
calculation and comparison extent of the authentication data by the receiver
for each
coverage. Specifically, ESP does not protect any IP datagram containing an Authentication Header. The impact
will vary with authentication algorithm used and other factors.

In order for the Authentication Header header fields
unless those fields are encapsulated by ESP (tunnel mode). For more
details on how to work properly without
changing the entire Internet infrastructure, use AH and ESP in various network environments, see
the authentication data Security Architecture document [KA97a].

It is carried in its own payload. Systems assumed that aren't participating in
the authentication ignore the Authentication Data. When used with
IPv6, the Authentication Header reader is placed after familiar with the Fragmentation terms and
End-to-End headers and before the transport-layer headers. The
information concepts
described in the other IP headers is used to route Security Architecture document. In particular, the datagram
from origin to destination. When used
reader should be familiar with IPv4, the Authentication
Header immediately follows an IPv4 header.

If a symmetric authentication algorithm is used definitions of security services
offered by AH and intermediate
authentication is desired, then ESP, the nodes performing such
intermediate authentication would need to concept of Security Associations, the ways
in which AH can be provided used in conjunction with ESP, and the
appropriate keys. Possession of those keys would permit any one of
those systems to forge traffic claiming to be from the legitimate
sender different
key management options available for AH and ESP. (With regard to the legitimate receiver or to modify
last topic, the contents of
otherwise legitimate traffic. In some environments such intermediate
authentication might be desirable. [BCCH94] If an asymmetric
authentication algorithm is used current key management options required for both AH
and the routers ESP are aware of the
appropriate public keys and authentication algorithm, then the
routers possessing the authentication public key could authenticate
the traffic being handled without being able to forge or modify
otherwise legitimate traffic. Also, Path MTU Discovery MUST be used manual keying and the "Don't Fragment" bit must be set when intermediate automated keying via Oakley/ISAKMP.)

Kent, Atkinson [Page 2] 3]

Internet Draft IP Authentication Header 4 June 1996

authentication of the 21 July, 1997

2. Authentication Header is desired and IPv4 is Format

The protocol header (IPv4, IPv6, or Extension) immediately preceding the
AH header will contain the value 51 in
use because with this method it is not possible to authenticate a
fragment of a packet. [MD90] [Kno93]

1.2 Requirements Terminology

In this document, 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Authentication Data (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The following subsections define the words fields that are used to define comprise the
significance of each particular requirement AH
format. All the fields described here are usually capitalised.
These words are:

- MUST

This word or mandatory, i.e., they are
always present in the adjective "REQUIRED" means that AH format and are included in the item ICV
computation.

2.1 Next Header

The Next Header is an
absolute requirement 8-bit field that identifies the type of the specification.

- SHOULD

This word or
next payload after the adjective "RECOMMENDED" means that there might
exist valid reasons in particular circumstances to ignore Authentication Header. The value of this item,
but
field is chosen from the full implications should be understood and set of IP Protocol Numbers defined in the case carefully
weighed before taking a different course.

- MAY

This word or
most recent "Assigned Numbers" [STD-2] RFC from the adjective "OPTIONAL" means that this item is truly
optional. One vendor might choose to include Internet Assigned
Numbers Authority (IANA).

2.2 Payload Length

This 8-bit field specifies the item because a
particular marketplace requires it or because it enhances length of AH, in 32-bit words (4-byte
units), minus "2," i.e., the
product, for example; another vendor may omit fixed portion (as defined in the same item.

2. SECURITY ASSOCIATION MANAGEMENT

Security association management is an important part
original AH spec) of AH is not counted. (Since the IP
security architecture. It Sequence Number
field is important for always present, the fixed portion of AH to be able to work
with multiple security association management protocols (e.g. unicast
vs. multicast). Also, there is a long history in now three 32-bit
words. However, the "minus 2" length adjustment has been retained
for backwards compatibility.) In the public
literature "standard" case of subtle flaws in key management algorithms and
protocols. Hence, a 96-bit
authentication value plus the 3 32-bit word fixed portion, this
length field will be "4". A "null" authentication algorithm may be
used only for debugging purposes. Its use would result in a "1"
value for this field, as there would be no corresponding
Authentication Data field.

Kent, Atkinson [Page 4]

Internet Draft IP Authentication Header tries 21 July, 1997

2.3 Reserved

This 16-bit field is reserved for future use. It MUST be set to decouple the
security association management mechanisms from the security protocol
mechanisms. The only coupling between
"zero." (Note that the key management protocol
and value is included in the security protocol Authentication Data
calculation, but is with otherwise ignored by the recipient.)

2.4 Security Parameters Index
(SPI), which (SPI)

The SPI is described an arbitrary 32-bit value that uniquely identifies the
Security Association for this datagram, relative to the destination
IP address contained in more detail below. This decoupling
permits several different the IP header with which this security management mechanisms header
is associated, and relative to be used.
More importantly, it permits the security or key management protocol
to be changed or corrected without unduly impacting the security protocol implementations. employed. The security management mechanism is used to negotiate a number
set of
parameters for each "Security Association", including not only the

Atkinson [Page 3]

Internet Draft IP Authentication Header 4 June 1996

keys but also other information (e.g. SPI values in the authentication algorithm
and mode) used range 1 through 255 are reserved by the communicating parties. The security management
mechanism creates and maintains
Internet Assigned Numbers Authority (IANA) for future use; a logical table containing reserved
SPI value will not normally be assigned by IANA unless the
several parameters for each current security association. An
implementation use of the IP Authentication Header will need to read that
logical table
assigned SPI value is specified in an RFC. It is ordinarily selected
by the destination system upon establishment of security parameters to determine how to process each
datagram containing an Authentication Header (e.g. to determine which
algorithm/mode and key to use in authentication). SA (see the
Security Associations Architecture document for more details). (A zero value may
be used for local debugging purposes, but no AH packets should be
transmitted with a zero SPI value.)

2.5 Sequence Number

This unsigned 32-bit field contains a monotonically increasing
counter value (sequence number). The sender's counter and the
receiver's counter are unidirectional. A bidirectional
communications session will normally have one Security Association in
each direction. For example, initialized to 0 when an SA is established.
(The first packet sent using a TCP session exists between two
systems A and B, there given SA will normally have a Sequence Number
of 1; see Section 3.2.2 for more details on how the Sequence Number
is generated.) The transmitted Sequence Number must never be one Security Association from
A allowed
to B cycle. Thus the sender's counter and the receiver's counter MUST
be reset (by establishing a new SA and thus a separate second Security Assocation from B new key) prior to A. The the
transmission of 2^32nd packet on an SA.

This field is always present, even if the receiver assigns does not elect to
enable the SPI value anti-replay service for a specific SA, in order to ensure
8-byte alignment for the IPv6 environment, when the Security Association with
that sender. The other parameters default integrity
algorithms are employed.

Processing of the Security Association are
determined in a manner specified by Sequence Number field is at the security management
mechanism. Section 4 discretion of the
receiver, i.e., the sender MUST always transmit this document describes in detail field, but the
process
receiver need not act upon it (see the discussion of selecting Sequence Number
Verification in the "Inbound Processing" section below).

2.6 Authentication Data

This is a Security Association for an outgoing packet
and identifying variable-length field that contains the Security Assocation Integrity Check
Value (ICV) for an incoming this packet. The IP Security Architecture document describes key management field must be an integral multiple
of 32 bits in
more detail. It includes specification length. The details of the key management
requirements for implementations of this protocol, and is
incorporated here by reference. [Atk95a]

3. AUTHENTICATION HEADER SYNTAX

The ICV computation are

Kent, Atkinson [Page 5]

Internet Draft IP Authentication Header (AH) 21 July, 1997

described in Section 3.2.3 below. This field may appear after any other headers
which are examined at each hop, and before any other headers which
are not examined at include explicit
padding. This padding is included to ensure that the length of the
AH header is an intermediate hop. The IPv4 integral multiple of 32 bits (IPv4) or IPv6 header
immediately preceding 64 bits
(IPv6). All implementations MUST support such padding. Details of
how to compute the required padding length are provided below.

3. Authentication Header will contain the
value 51 in its Next Processing

3.1 Authentication Header (or Protocol) field. [STD-2] Note that Location

Like ESP, AH
uses daisy-chained optional headers even for IPv4 just as IPv6 daisy-
chains all optional headers. may be employed in two ways: transport mode or tunnel
mode. The following header combinations are NOT valid at any time:
1. [IP][AH][AH][upper-layer protocol]
2. [IP][ESP][AH][upper-layer protocol]
Regarding case 1, one should former mode is applicable only have a single AH present in such a
packet. Regarding case 2, one instead uses an ESP transform (e.g.
[Hugh96]) that provides strong integrity to host implementations and authentication
protections
provides protection for upper layer protocols, in addition to confidentiality.

Example high-level diagrams of valid
selected IP datagrams with header fields. (In this mode, note that for "bump-in-
the-stack" or "bump-in-the-wire" implementations, as defined in the
Authentication Header follow.

+-------------+--------------------+-------------+--------+----------------+

Atkinson [Page 4]

Internet Draft
Security Architecture document, inbound and outbound IP Authentication Header 4 June 1996

| IPv6 Header 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.)

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, e.g., ESP. In the
context of IPv4, this calls for placing AH after the IP header (and
any options that it contains), but before the upper layer protocol.
(Note that the term "transport" mode should not be misconstrued as
restricting its use to TCP and UDP. For example, an ICMP message MAY
be sent using either "transport" mode or "tunnel" mode.) The
following diagram illustrates AH transport mode positioning for a
typical IPv4 packet, on a "before and after" basis.

AFTER APPLYING AH
---------------------------------
IPv4 |orig IP hdr | | | |
|(any options)| AH | TCP | Data |
+-------------+--------------------+-------------+--------+----------------+

Figure 1:
---------------------------------
|<------- authenticated ------->|
except for mutable fields

In the IPv6 Example context, AH is viewed as an end-to-end payload, and thus

Kent, Atkinson [Page 5] 6]

Internet Draft IP Authentication Header 4 June 1996

When used with IPv6, the Authentication Header normally appears 21 July, 1997

should appear after the
IPv6 Hop-by-Hop Header and the Fragmentation Header hop-by-hop, routing, and just before the
IPv6 Destination Options Header. If neither the Hop-by-Hop Header nor
the Fragmentation Header are present in the packet, the Authentication
Header might not directly follow such (in that case, non-existent) fragmentation extension
headers. The Authentication Header does always fall in that logical position within
the IP packet. Fragmentation always occurs after AH processing and
reassembly occurs destination options extension header(s) could appear
either before or after the AH processing, so if header depending on the Fragmentation Header
exists in semantics
desired. The following diagram illustrates AH transport mode
positioning for a packet the Authentication Header MUST NOT precede the
Fragmentation Header.

+-------------+--------------+-------------------------------+ typical IPv6 packet.

BEFORE APPLYING AH
---------------------------------------
IPv6 | IPv4 Header | Auth Header ext hdrs | Upper Protocol (e.g TCP, UDP) |
+-------------+--------------+-------------------------------+

Figure 2: IPv4 Example

* = if present, could be before AH, after AH, or both
** = hop by hop, routing, fragmentation headers

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 IPv4 header, unless an in-line IP-layer key management technique Security Architecture document).
When AH is implemented in use for that packet. a security gateway (to protect subscriber
transit traffic), tunnel mode must be used. In tunnel mode, the latter case, the Authentication
Header MUST always follow that inline IP-layer key management header.
It is NOT valid in any other location.

3.1 Authentication Header Syntax

The authentication data is
"inner" IP header carries the output 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 authentication
algorithm calculated over the entire inner IP packet, including the entire inner IP datagram as described in
more detail later in this document.
header. The authentication calculation
must treat the Authentication Data field itself and all fields that
are normally modified position of AH in transit (e.g. TTL or Hop Limit) tunnel mode, relative to the outer IP
header, is the same as if those
fields contained all zeros. All other Authentication Header fields
are included for AH in the authentication calculation normally. transport mode. The following
diagram illustrates AH tunnel mode positioning for typical IPv4 and
IPv6 packets.

Kent, Atkinson [Page 7]

Internet Draft IP Authentication Header has the following syntax:

+---------------+---------------+---------------+---------------+ 21 July, 1997

------------------------------------------------
IPv4 | Next Header new IP hdr* | Length | RESERVED orig IP hdr* |
+---------------+---------------+---------------+---------------+ | Security Parameters Index |
+---------------+---------------+---------------+---------------+
|(any options)| AH | (any options) |TCP |
+ Authentication Data (variable number of 32-bit words) |
------------------------------------------------
|<-- authenticated except for mutable fields ->|

--------------------------------------------------------------
IPv6 | |
+---------------+---------------+---------------+---------------+
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8

Atkinson [Page 6]

Figure 3: Authentication Header syntax

* = construction of outer IP hdr/extensions and modification
of inner IP hdr/extensions is discussed below.

3.2 Outbound Packet Processing

In transport mode, the Authentication Header

NEXT HEADER
8 bits wide. Identifies transmitter inserts the next payload AH header after the Authentication
Header. The values in this field are the set of IP Protocol Numbers
header and before an upper layer protocol header, as defined in the most recent RFC from described above.
In tunnel mode, the Internet Assigned Numbers
Authority (IANA) describing "Assigned Numbers" [STD-2].

PAYLOAD LENGTH
8 bits wide. outer and inner IP header/extensions can be
inter-related in a variety of ways. The length construction of the Authentication Data field in 32-bit
words. Minimum value outer IP
header/extensions during the encapsulation process is 0 words, which described in
the Security Architecture document.

3.2.1 Security Association Lookup

AH is applied to an outbound packet only used in after an IPsec
implementation determines that the degenerate
case of a "null" authentication algorithm.

RESERVED
16 bits wide. Reserved packet is associated with an SA
that calls for future use. MUST be set to all zeros
when sent. AH processing. The value process of determining what, if
any, IPsec processing is included applied to outbound traffic is described in
the Authentication Data
calculation, but Security Architecture document.

3.2.2 Sequence Number Generation

The sender's counter is otherwise ignored by the recipient.

SECURITY PARAMETERS INDEX (SPI)

An arbitrary 32-bit value identifying initialized to 0 when an SA is established.
The transmitter increments the security association Sequence Number for this datagram. The Security Parameters Index value 0 is
reserved SA, checks to indicate
ensure that "no security association exists".

The set of Security Parameters Index values in the range 1
through 255 are reserved to counter has not cycled, and inserts the Internet Assigned Numbers
Authority (IANA) for future use. A reserved SPI new value
into the Sequence Number Field. Thus the first packet sent using a
given SA will have a Sequence Number of 1. A transmitter MUST not
normally be assigned by IANA unless
send a packet on an SA if doing so would cause the use of sequence number to
cycle. An attempt to transmit a packet that particular
assigned SPI value is openly specified would result in sequence
number overflow is an RFC.

AUTHENTICATION DATA
This length of auditable event. (Note that this field is variable, but is always an integral
number of 32-bit words.

Many implementations require padding to other alignments, such as
64-bits, in order approach to improve performance. All implementations MUST
support such padding, which is specified by the Destination on a per
SPI basis. The value of the padding field is arbitrarily selected
by the sender and is included in the Authentication Data calculation.

An implementation will
Sequence Number management does not require use the combination of Destination
Address and SPI to locate the Security Association which specifies
the field's size and use. The field retains the same format
for all datagrams of any given SPI and Destination Address pair. modular
arithmetic.)

Kent, Atkinson [Page 7] 8]

Internet Draft IP Authentication Header 4 June 1996 21 July, 1997

3.2.3 Integrity Check Value Calculation

3.2.3.1 Handling Mutable Fields

The Authentication Data fills AH ICV is computed over IP header fields that are either
immutable in transit or that are predictable in value upon arrival at
the field beginning immediately after endpoint for the SPI field. AH SA. The ICV also encompasses the upper level
protocol data, which is assumed to be immutable in transit. If a
field may be modified during transit, the value of the field is longer than necessary set
to store zero for purposes of the
actual authentication data, ICV computation. If a field is mutable,
but its value at the (IPsec) receiver is predictable, then that value
is inserted into the unused bit positions are filled
with unspecified, implementation-dependent values.

Refer to each Authentication Transform specification field for more
information regarding the contents purposes of this field.

3.3 Sensitivity Labeling

As the ICV calculation. The
Authentication Data field also is discussed in greater detail set to zero in the IP Security Architecture
document, IPv6 will normally use implicit Security Labels preparation for this
computation. Note that by replacing each field's value with zero,
rather than omitting the explicit labels field, alignment is preserved for the ICV
calculation. Also, the zero-fill approach ensures that the length of
the fields that are currently used with IPv4. [Ken91]
[Atk95a] In some situations, users MAY choose to carry explicit labels
(for example, IPSO labels as defined by RFC-1108 might so handled cannot be used with
IPv4) in addition to using the implicit labels provided changed during transit, even
though their contents are not explicitly covered by the
Authentication Header. Explicit label options could ICV.

As a new extension header or IPv4 option is created, it will be
defined for
use with IPv6 (e.g. using in its own RFC and SHOULD include (in the IPv6 end-to-end options header or Security
Considerations section) directions for how it should be handled when
calculating the
IPv6 hop-by-hop options header). Implementations MAY support explicit
labels in addition to implicit labels, but implementations are not
required to support explicit labels. AH ICV. If explicit labels are in use,
then the explicit label IPSEC implementation encounters an
extension header that it does not recognize, it MUST be included in zero the authentication
calculation.

4. CALCULATION OF THE AUTHENTICATION DATA whole
header except for the Next Header and Hdr Ext Len fields. The authentication data carried length
of the extension header MUST be computed by 8 * Hdr Ext Len value +
8. 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 contain a flag
indicating mutability, which determines appropriate processing for
such options.)

3.2.3.1.1 ICV Computation for IPv4

3.2.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
Source Address
Destination Address (without loose or strict source routing)

Kent, Atkinson [Page 9]

Internet Draft IP Authentication Header is
usually calculated using a message digest algorithm (for example, MD5)
either encrypting that message digest 21 July, 1997

Mutable but predictable
Destination Address (with loose or keying the message digest
directly. [Riv92] Only algorithms that 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 believed known to be
cryptographically strong one-way functions should be used with
change the value of this field, even though the IP Authentication Header.

Because conventional checksums and CRCs are specification
does not cryptographically strong,
they MUST NOT consider TOS to be used with a mutable header field.

Flags -- This field is excluded since an intermediate router might
set the Authentication Header.

When 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.2.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.2.3.1.2 ICV Computation for IPv6

3.2.3.1.2.1 Base Header Fields

The IPv6 base header fields are classified as follows:

Kent, Atkinson [Page 10]

Internet Draft IP Authentication Header 21 July, 1997

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)
Priority
Flow Label
Hop Limit

3.2.3.1.2.2 Extension Headers -- Options

The IPv6 extension headers (that are options) are explicitly listed
in Appendix A and classified as immutable, mutable but predictable,
or mutable.

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.2.3.1.2.3 Extension Headers -- non-Options

The IPv6 extension headers (that are not options) are explicitly
listed in Appendix A and classified as immutable, mutable but
predictable, or mutable.

3.2.3.2 Padding

3.2.3.2.1 Authentication Data Padding

As mentioned in section 2.6, the Authentication Data field explicitly
includes padding to ensure that the AH header is a multiple of 32
bits (IPv4) or 64 bits (IPv6). If padding is required, its length is
determined by two factors:

- the length of the ICV
- the IP protocol version (v4 or v6)

Kent, Atkinson [Page 11]

Internet Draft IP Authentication Header 21 July, 1997

For example, if a default, 96-bit truncated (see Section 3.2.3.3)
HMAC algorithm is selected no padding is required for either IPv4 nor
for IPv6. However, if a different length ICV is generated, due to
use of a different algorithm, then padding may be required for the
IPv6 environment. The content of the padding field is arbitrarily
selected by the sender. (The padding is arbitrary, but need not be
random to achieve security.) These padding bytes are included in the
Authentication Data calculation, counted as part of the Payload
Length, and transmitted at the end of the Authentication Data field
to enable the receiver to perform the ICV calculation.

3.2.3.2.2 Implicit Packet Padding

For some authentication algorithms, the byte string over which the
ICV computation is performed must be a multiple of a blocksize
specified by the algorithm. If the IP packet length (including AH)
does not match the blocksize requirements for the algorithm, implicit
padding MUST be appended to the end of the packet, prior to ICV
computation. The padding octets MUST have a value of zero. The
blocksize (and hence the length of the padding) is specified by the
algorithm specification. This padding is not transmitted with the
packet.

3.2.3.3 Authentication Algorithms

The authentication algorithm employed for the ICV computation is
specified by the SA. For point-to-point communication, suitable
authentication algorithms include keyed Message Authentication Codes
(MACs) based on symmetric encryption algorithms (e.g., DES) or on
one-way hash functions (e.g., MD5 or SHA-1). For multicast
communication, one-way hash algorithms combined with asymmetric
signature algorithms are appropriate, though performance and space
considerations currently preclude use of such algorithms. As of this
writing, the mandatory-to-implement authentication algorithms are
based on the former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or
HMAC with MD5 [Riv92]. The output of the HMAC computation is
truncated to the leftmost 96 bits. Other algorithms, possibly with
different ICV lengths, MAY be supported.

3.2.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
such fragments must be reassembled prior to AH processing at a
receiver. In tunnel mode, AH is applied to an IP packet, the payload

Kent, Atkinson [Page 12]

Internet Draft IP Authentication Header 21 July, 1997

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.

3.3 Inbound Packet Processing

3.3.1 Reassembly

If required, reassembly is performed prior to AH processing. If a
packet offered to AH for processing appears to be an outgoing IP packet for Authentication, fragment,
i.e., the first step OFFSET field is for non-zero or the sending system to locate MORE FRAGMENTS flag is set,
the appropriate Security Association.
All Security Associations are unidirectional. The selection of receiver MUST discard the
appropriate Security Association for an outgoing IP packet originating at packet; this system is based at least upon the sending userid and an auditable event. The
audit log entry for this event SHOULD include the SPI value,
date/time, Source Address, Destination
Address. For traffic not originating on the security gateway that is
adding Address, and (in IPv6) the
Flow ID.

3.3.2 Security Association Lookup

Upon receipt of a packet containing an IP Authentication Header, the security gateway should select an
receiver determines the appropriate Security Association (unidirectional) SA, based on the source and
destination
address, upper-layer protocol, IP address and port triple. When host-oriented keying
is in use, all sending userids will share the same Security Association to
a given destination. When user-oriented keying SPI. (This process is described in use, then different

Atkinson [Page 8]

Internet Draft IP Authentication Header 4 June 1996

users will use different Security Associations. When session-unique keying
is
more detail in use, different applications of the same user on different sockets
will use different Security Associations. Architecture document.) The Security Association
selected SA dictates
whether the Sequence Number field will indicate which algorithm, algorithm mode, key, be checked, specifies the
algorithm(s) employed for ICV computation, and other
security properties apply indicates the key(s)
required to validate the outgoing packet.

Fields which NECESSARILY are modified during transit from ICV.

If no valid Security Association exists for this session (e.g., the sender
to
receiver has no key), the receiver (e.g. TTL and HEADER CHECKSUM for IPv4 or Hop Limit MUST discard the packet; this is
an auditable event. The audit log entry for IPv6) and whose value at this event SHOULD
include the receiver are not known with certainty
by SPI value, date/time, Source Address, Destination
Address, and (in IPv6) the sender are included in Flow ID.

3.3.3 Sequence Number Verification

All AH implementations MUST support the authentication data calculation but
are processed specially. For these fields which anti-replay service, though
its use may be enabled or disabled on a per-SA basis. (Note that
there are modified during
transit, no provisions for managing transmitted Sequence Number
values among multiple senders directing traffic to a single,
multicast SA. Thus the value carried anti-replay service SHOULD NOT be used in the IP packet a
multi-sender multicast environment that employs a single, multicast
SA.) If an SA establishment protocol such as Oakley/ISAKMP is replaced by
employed, then the value
zero for receiver SHOULD notify the purpose of transmitter, during SA
establishment, if the authentication calculation. By replacing receiver will provide anti-replay protection
and SHOULD inform the field's value with zero rather than omitting these fields,
alignment is preserved for transmitter of the authentication calculation.

The sender MUST compute window size.

If the authentication over receiver has enabled the anti-replay service for this SA, the
receiver packet as that
packet will appear at counter for the receiver. This requirement is placed in
order SA MUST be initialized to allow for future zero when

Kent, Atkinson [Page 13]

Internet Draft IP optional headers which Authentication Header 21 July, 1997

the SA is established. For each received packet, the receiver might MUST
verify that the packet contains a Sequence Number that does not know about but
duplicate the sender necessarily knows about if it is
including such options in Sequence Number of any other packets received during
the packet. life of this SA. This also permits SHOULD be the
authentication first AH check applied to a
packet after it has been matched to an SA, to speed rejection of data that will vary in transit but whose value at
duplicate packets.

Duplicates are rejected through the final receiver is known with certainty by use of a sliding receive window.
(How the sender in advance.

The sender places window is implemented is a local matter, but the calculated authentication data into following
text describes the
Authentication Data field within functionality that the Authentication Header. For purposes implementation must
exhibit.) A MINIMUM window size of Authentication Data computation, the Authentication Data field 32 MUST be supported; but a
window size of 64 is
considered to preferred and SHOULD be filled with zeros.

The IPv4 "TIME TO LIVE","HEADER CHECKSUM", "FLAGS", and "TYPE OF SERVICE"
fields are the only fields in the IPv4 base header that are handled
specially for employed as the Authentication Data calculation. Reassembly default.
A window size of
fragmented packets occurs PRIOR to processing 64 or larger MAY be chosen by the local IP
Authentication Header implementation. The "more" bit receiver. If a
larger window size is chosen, it MUST be a multiple of course cleared
upon reassembly.

Hence, no 32. If any
window size other fields in the IPv4 header will vary in transit from than the
perspective default of 64 is employed by the IP Authentication Header implementation. The specially
handled field enumerated above receiver,
it MUST be set reported to all zeros for the
Authentication Data calculation. All other IPv4 base header fields are
processed normally with their actual contents. Because IPv4 packets are
subject to intermediate fragmentation in routers, it is important transmitter during SA negotiation.

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
reassembly "left" edge of IPv4 the window are
rejected. Packets falling within the window are checked against a
list of received packets be performed prior to within the window. An efficient means for
performing this check, based on the Authentication Header
processing. IPv4 Implementations SHOULD use Path MTU Discovery when of a bit mask, is described
in the IP
Authentication Header Security Architecture document.

If the received packet falls within the window and is being used. [MD90] For IPv4, options are normally
zeroed for new, or if the
packet is to the purpose right of the Authentication Data calculation. There are
two exceptions window, then the receiver proceeds to this rule. The IP Security Option (IPSO)
ICV verification. If the ICV validation fails, the receiver MUST be
included in
discard the Authentication Data calculation whenever that option is

Atkinson [Page 9]

Internet Draft received IP Authentication Header 4 June 1996

present in datagram as invalid; this is an IP datagram. [Ken91] auditable
event. The undocumented non-standard CIPSO
option, which has been assigned option number 134 by IANA, also MUST be
included in audit log entry for this event SHOULD include the Authentication data calculation whenever that option is
present in an IP datagram. If a receiving system does not recognise an
IPv4 option that is present in SPI
value, date/time, Source Address, Destination Address, the packet, that option is omitted from
Authentication Data calculation. Sequence
Number, and (in IPv6) the Flow ID. The IPv6 "HOP LIMIT" field receive window is the updated
only field in if the IPv6 base header ICV verification succeeds.

DISCUSSION:

Note that if the packet is handled specially for Authentication Data calculation. The
value of either inside the HOP LIMIT field window and new, or is zero for
outside the purpose of Authentication
Data calculation. All other fields in window on the base IPv6 header MUST be
included in "right" side, the Authentication Data calculation using receiver MUST
authenticate the normal
procedures for calculating packet before updating the Authentication Data. All IPv6 "OPTION
TYPE" values contain a bit which MUST be used to determine whether
that option data will be included in Sequence Number window
data.

3.3.4 Integrity Check Value Verification

The receiver computes the Authentication Data
calculation. This bit is ICV over the third-highest-order bit appropriate fields of the IPv6
OPTION TYPE field. If this bit is set to zero, then
packet, using the corresponding
option specified authentication algorithm, and verifies
that it is the same as the ICV included in the Authentication Data calculation. If this
bit is set to one, then the corresponding option is replaced by all
zero bits
field of the same length as the option for the purpose packet. Details of the computation are provided below.

Kent, Atkinson [Page 14]

Internet Draft IP Authentication Data calculation. The IPv6 Routing Header "Type 0"
will rearrange 21 July, 1997

If the address fields within computed and received ICV's match, then the packet during transit
from source to destination. However, this datagram is not a problem because
the contents of the packet as valid,
and it will appear at is accepted. If the test fails, then the receiver are known
to MUST
discard the sender received IP datagram as invalid; this is an auditable
event. The audit log entry SHOULD include the SPI value, date/time,
Source Address, Destination Address, and to all intermediate hops. Hence, (in IPv6) the IPv6 Routing
Header "Type 0" is included in Flow ID.

DISCUSSION:

Begin by saving the ICV value and replacing it (but not any
Authentication Data calculation
using the normal procedure.

Upon receipt of padding) with zero. Zero all other fields
that may have been modified during transit. (See section 3.2.3.1
for a packet containing an IP Authentication Header, discussion of which fields are zeroed before performing the
receiver first uses
ICV calculation.) Check the Destination Address overall length of the packet, and SPI value if
it requires implicit padding based on the requirements of the
authentication algorithm, append zero-filled bytes to locate the correct Security Association. The receiver then independently
verifies that end of
the Authentication Data field packet as required. Now perform the ICV computation and
compare the received data
packet are consistent. Again, result with the Authentication Data field is
assumed to be zero for saved value. (For the mandatory-to-
implement authentication algorithms, HMAC [KBC97] with SHA-1 [SHA]
or HMAC with MD5 [Riv92], the sole purpose output of making the authentication
computation. Exactly how this is accomplished HMAC computation is algorithm dependent.
If
truncated to the processing of leftmost 96 bits. Other algorithms may have
different ICV lengths.) (If a digital signature and one-way hash
are used for the authentication algorithm indicates ICV computation, the
datagram is valid, then it matching process is accepted. If more
complex and will be described in the algorithm determines specification.)

4. Auditing

Not all systems that the data and the Authentication Header do not match, implement AH will implement auditing. However,
if AH is incorporated into a system that supports auditing, then the
receiver
AH implementation MUST discard the received IP datagram as invalid also support auditing and MUST
record the authentication failure in the allow a system log
administrator to enable or audit log. If
such a failure occurs, disable auditing for AH. For the recorded log data MUST include most
part, the SPI
value, date/time received, clear-text Sending Address, clear-text
Destination Address, granularity of auditing is a local matter. However,
several auditable events are identified in this specification and (if it exists) the clear-text Flow ID. The for
each of these events a minimum set of information that SHOULD be
included in an audit log data 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 include other information about MAY
result in audit log entries. There is no requirement for the failed packet.

Atkinson [Page 10]

Internet Draft IP Authentication Header 4 June 1996
receiver to transmit any message to the purported transmitter in
response to the detection of an auditable event, because of the
potential to induce denial of service via such action.

5. CONFORMANCE REQUIREMENTS Conformance Requirements

Implementations that claim conformance or compliance with this
specification MUST fully implement the header AH syntax and processing
described here, MUST support
manual key distribution for use with this option, here and MUST comply with all requirements of the "Security Security
Architecture for document. If the key used to compute an ICV is manually

Kent, Atkinson [Page 15]

Internet Protocol"
[Atk95a], Draft IP Authentication Header 21 July, 1997

distributed, correct provision of the anti-replay service would
require correct maintenance of the counter state at the transmitter,
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 use of following mandatory-to-implement
algorithms (specified in [KBC97]):

- HMAC with MD5
- HMAC with SHA-1

6. Security Considerations

Security is central to the mandatory-to- implement AH
transforms. As design of this writing protocol, and these
security considerations permeate the specification. Additional
security-relevant aspects of using the IPsec protocol are HMAC SHA [CG96] and HMAC MD5
[OG96], discussed
in the Security Architecture document.

7. Differences from RFC 1826

This specification of AH differs from RFC 1826 [ATK95] in several
important respects, but implementers need to consult the most recent version fundamental features of AH remain intact.
One goal of the
"Internet Official Protocol Standards" [STD-1] for current information on
standards status. Implementations MAY also implement other authentication
algorithms.

6. SECURITY CONSIDERATIONS

This entire revision of RFC discusses an authentication mechanism 1826 was to provide a complete
framework for IP.
This mechanism AH, with ancillary RFCs required only for algorithm
specification. For example, the anti-replay service is now an
integral, mandatory part of AH, not a panacea feature of a transform defined
in another RFC. Carriage of a sequence number to support this
service is now required at all times, to meet IPv6 alignment
requirements (even when anti-replay is not enabled for an SA). The
default algorithms required for interoperability have been changed to
HMAC with MD5 or SHA-1 (vs. keyed MD5), for security reasons. The
list of IPv4 header fields excluded from the ICV computation has been
expanded to include the OFFSET and FLAGS fields.

Another motivation for revision was to provide additional detail and
clarification of subtle points. This specification provides
rationale for exclusion of selected IPv4 header fields from AH
coverage and provides examples on positioning of AH in both the IPv4
and v6 contexts. Auditing requirements have been clarified in this
version of the several security issues specification. Tunnel mode AH was mentioned only in any
internetwork, however it does provide a component useful
passing in building RFC 1826, but now is a
secure internetwork.

Users need to understand that the quality mandatory feature of the AH.
Discussion of interactions with key management and with security provided
by this specification depends completely on
labels have been moved to the strength of whichever
cryptographic algorithm Security Architecture document.

Kent, Atkinson [Page 16]

Internet Draft IP Authentication Header 21 July, 1997

Acknowledgements

For over 2 years, this document has been implemented, evolved through multiple versions
and iterations. During this time, many people have contributed
significant ideas and energy to the strength of process and the key
being used, documents
themselves. The authors would like to thank Karen Seo for providing
extensive help in the correctness review, editing, background research, and
coordination for this version of that algorithm's implementation, upon the security specification. The authors
would also like to thank the members of the key management mechanism and its implementation, IPsec and upon the correctness IPng working
groups, with special mention of the efforts of (in alphabetic order):
Steve Bellovin, Steve Deering, Francis Dupont, Phil Karn, Frank
Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, William
Simpson, and Nina Yuan.

Kent, Atkinson [Page 17]

Internet Draft IP Authentication Header and IP
implementations in all of the participating systems. If any 21 July, 1997

Appendix A -- Mutability of these
assumptions do not hold, then little or no real security will be
provided to IP Options/Extension Headers

1. IPv4 Options

This table shows how the user. Implementors IPv4 options are encouraged to use high
assurance methods classified with regard to develop all of
"mutability". Where two references are provided, the security relevant parts 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
their products.

Users interested in confidentiality should consider using the IP
Encapsulating Security Payload (ESP) instead of or in conjunction Router Alert option is potentially incompatible with
this specification. [Atk95b] Users seeking protection from traffic
analysis might consider the
use of appropriate link encryption.
Description and specification of link encryption is outside the scope
of this note. [VK83] Users interested in combining the IP
Authentication Header with the IP Encapsulating Security Payload
should consult IPSEC. Although the IP Encapsulating Security Payload specification
for details.

One particular issue option is immutable, its use implies that in some cases
each router along a packet's path will "process" the packet which causes an
error to be reported back via ICMP and
consequently might be so large as not to
entirely fit within change the ICMP message returned. In such cases, it
might not be possible for packet. This would happen on a hop by
hop basis as the receiver of packet goes from router to router. Prior to being
processed by the ICMP message application to
independently authenticate which the portion of option contents are
directed, e.g., RSVP/IGMP, the returned message. This
could mean packet should encounter AH processing.
However, AH processing would require that each router along the host receiving such an ICMP message would either
trust an unauthenticated ICMP message, which might in turn create some path

Kent, Atkinson [Page 11] 18]

Internet Draft IP Authentication Header 4 June 1996

security problem, or 21 July, 1997

is a member of a multicast-SA defined by the SPI. This might pose
problems for packets that are not trust strictly source routed, and hence it
requires multicast support techniques not react appropriately to
some legitimate ICMP message that should have been reacted to. It 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 not clear incompatible with the use of IPSEC.

2. 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 this issue can 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 fully resolved treated as zero-valued octets when computing or
verifying the ICV. The Option Type and Opt Data Len are
included in the presence of
packets that ICV calculation. All options for which the bit
indicates immutability are included in the same size as or larger than 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 minimum IP MTU.
Similar complications arise if an encrypted packet causes an ICMP
error message during transit from source
to be sent and that destination. However, the contents of the packet is truncated.

Active attacks as it will
appear at the receiver are now widely known to exist the sender and to all
intermediate hops. Hence, the IPv6 Routing Header "Type 0" is
included in the Internet
[CER95]. Authentication Data calculation as mutable but
predictable. The presence of active attacks means transmitter must order the field so that unauthenticated
source routing, either unidirectional (receive-only) or with replies
following it
appears as it will at the original received source route represents a significant
security risk unless all received source routed packets are
authenticated using receiver, prior to performing the ICV
computation.

Fragmentation -- Fragmentation occurs after outbound IPSEC processing
(section 3.2.4) and reassembly occurs before inbound IPSEC
processing (section 3.3.1). So the Fragmentation Extension

Kent, Atkinson [Page 19]

Internet Draft IP Authentication Header or some other
cryptologic mechanism. It 21 July, 1997

Header, if it exists, is noteworthy not seen by IPSEC.

Note that on the attacks described in
[CER95] include receive side, the IP implementation could leave
a subset of those described Fragmentation Extension Header in [Bel89].

The use of IP tunneling with place when it does
re-assembly. If this happens, then when AH creates multiple pairs of endpoints
that might perform receives the packet,
before doing ICV processing, AH processing. Implementers MUST "remove" (or skip over)
this header and administrators
should carefully consider the impacts of tunneling on authenticity of change the received tunneled packets.

This documented benefited greatly from work done by Bill Simpson, Perry
Metzger, and Phil Karn previous header's "Next Header" field
to make general the approach originally defined
by be the author for SIP, SIPP, and finally IPv6.

The basic concept here is derived "Next Header" field in large part from the SNMPv2
Security Protocol work described in [GM93]. Steve Bellovin, Steve
Deering, Frank Kastenholz, Dave Mihelcic, and Hilarie Orman provided
thoughtful critiques 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 early versions 0 (first fragment) and a More Fragments Flag of 0
(last fragment). If this note. Francis Dupont
discovered happens, then before doing ICV
processing, AH MUST first "remove" (or skip over) this header
and pointed out change the security issue with ICMP previous header's "Next Header" field to be the
"Next Header" field in low IP MTU
links that is noted just above.

REFERENCES
[Atk96a] Randall Atkinson, Security Architecture for the Fragmentation Extension Header.

Kent, Atkinson [Page 20]

Internet Protocol,
Internet Draft, 4 June 1996

[Atk96b] Randall Draft IP Authentication Header 21 July, 1997

References

[ATK95] R. Atkinson, "The IP Encapsulating Security Payload, Internet Draft,
4 June 1996

[Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite",
ACM Computer Communications Review, Vol. 19, No. 2, March 1989. Authentication Header," RFC 1826,
August 1995.

[BCCH94] R. Braden, D. Clark, S. Crocker, & C.Huitema, "Report of
IAB Workshop on Security in the Internet Architecture",
RFC-1636, DDN Network
Information Center, 9 June 1994, pp. 21-34.

[Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP
Protocol Suite", ACM Computer Communications Review, Vol.
19, No. 2, March 1989.

[CER95] Computer Emergency Response Team (CERT), "IP Spoofing
Attacks and Hijacked Terminal Connections", CA-95:01,
January 1995.

Atkinson [Page 12]

Internet Draft IP Authentication Header 4 June 1996 Available via anonymous ftp from
info.cert.org in /pub/cert_advisories.

[CG96] Shu-jen Chang & Rob Glenn, "HMAC SHA IP Authentication with Replay
Protection", Internet Draft, 1 May 1996.

[DH95] Steve Deering & Bob Hinden, "Internet Protocol version 6
(IPv6) Specification", RFC-1883, December 1995.

[GM93] James Galvin & Keith McCloghrie, Security Protocols for
version 2 of the Simple Network Management Protocol
(SNMPv2), RFC-1446,
DDN Network Information Center, April 1993.

[Hugh96] Jim Hughes (Editor), "Combined DES-CBC, HMAC, and Replay
Prevention

[KA97a] Steve Kent, Randall Atkinson, "Security Architecture for
the Internet Protocol", Internet Draft, ?? 1997.

[KA97b] Steve Kent, Randall Atkinson, "IP Encapsulating Security Transform",
Payload (ESP)", Internet Draft, April 1996. ?? 1997.

[KA97c] Steve Kent, Randall Atkinson, "IP Authentication Header",
Internet Draft, ?? 1997.

[KBC97] Hugo Krawczyk, Mihir Bellare, and Ran Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC-2104,
February 1997.

[Ken91] Steve Kent, "US DoD Security Options for the Internet
Protocol", RFC-1108, DDN Network Information Center, November 1991.

[Kno93] Steve Knowles, "IESG Advice from Experience with Path MTU Discovery",
RFC-1435, DDN Network Information Center, March 1993.

[MD90] Jeff Mogul &

[KA97a] Steve Deering, "Path MTU Discovery", RFC-1191,
DDN Network Information Center, November 1990.

[OG96] Mike Oehler & Rob Glenn, "HMAC SHA IP Authentication with Replay
Protection", Kent, Randall Atkinson, "Security Architecture for
the Internet Protocol", Internet Draft, May 1996. ?? 1997.

[Riv92] Ronald Rivest, "The MD5 Message Digest Algorithm," RFC-
1321, April 1992.

[SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995

Kent, Atkinson [Page 21]

Internet Draft IP Authentication Header 21 July, 1997

[STD-1] J. Postel, "Internet Official Protocol Standards", STD-1,
DDN Network Information Center,
March 1996.

[STD-2] J. Reynolds & J. Postel, "Assigned Numbers", STD-2,
DDN Network Information Center, 20
October 1994.

[Riv92] Ronald Rivest, MD5 Digest Algorithm, RFC-1321, DDN Network Information
Center, April 1992.

[VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level Networks",
ACM Computing Surveys, Vol. 15, No. 2, June 1983.

DISCLAIMER

Disclaimer

The views and specification here are those of the author authors and are not
necessarily those of his employer. their employers. The author authors and his employer their
employers specifically disclaim responsibility for any problems
arising from correct or incorrect implementation or use of this
specification.

Atkinson [Page 13]

Internet Draft IP Authentication Header 4 June 1996

AUTHOR INFORMATION

Author Information

Stephen Kent
BBN Corporation
70 Fawcett Street
Cambridge, MA 02140
USA
E-mail: kent@bbn.com
Telephone: +1 (617) 873-3988

Randall Atkinson <rja@cisco.com>
cisco Systems
170 West Tasman
@Home Network
385 Ravendale Drive
San Jose, CA, 95134-1706
Mountain View, CA 94043
USA

Telephone: +1 (408) 526-4000
E-mail: rja@inet.org

Kent, Atkinson [Page 14] 22]

----