WDIFF

draft-ietf-ipsec-arch-sec-01.txt --> draft-ietf-ipsec-arch-sec-02.txt

Security Architecture for the Internet Protocol

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. 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 "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 IP Security
(IPsec) working group. It is intended that a future version of this
draft be submitted to the IESG for publication as a Draft Standard
RFC. Comments about this draft may be sent to the author authors or to the
IPsec WG mailing list <ipsec@tis.com>.

1. INTRODUCTION

This memo describes the security protocols for IP version 4 (IPv4)
and IP version 6 (IPv6) and the services that they provide. Each security
protocol is specified in a separate document. This document also describes
key management requirements for systems implementing these security
protocols. This Distribution of this document
is not an overall unlimited.

Kent, Atkinson [Page 1]

Internet Draft Security Architecture for the
Internet; it addresses only IP-layer security. IP November 1997

Table of Contents

1. Introduction............................................................4
1.1 Technical Definitions

This section provides Summary of Contents of Document.....................................4
1.2 Audience............................................................4
1.3 Related Documents...................................................5
2. Design Objectives.......................................................5
2.1 Goals/Objectives/Requirements/Problem Description...................5
2.2 Caveats and Assumptions.............................................6
3. System Overview ........................................................6
3.1 What IPsec Does.....................................................7
3.2 How IPsec Works.....................................................7
3.3 Where IPsec May Be Implemented......................................8
4. Security Associations...................................................9
4.1 Definition and Scope................................................9
4.2 Security Association Functionality.................................11
4.3 Combining Security Associations....................................12
4.4 Security Association Databases.....................................13
4.4.1 The Security Policy Database (SPD)............................13
4.4.2 Selectors.....................................................16
4.4.3 Security Association Database (SAD)...........................19
4.5 Basic Combinations of Security Associations........................21
4.6 SA and Key Management..............................................23
4.6.1 Manual Techniques.............................................24
4.6.2 Automated SA and Key Management...............................24
4.6.3 Locating a few basic definitions that are applicable Security Gateway...................................25
4.7 Security Associations and Multicast................................26
5. IPsec Traffic Processing...............................................27
5.1 Outbound IPsec Traffic Processing..................................27
5.1.1 Selecting and Using an SA or SA Bundle........................27
5.1.2 Header Construction for Tunnel Mode...........................28
5.1.2.1 IPv4 -- Header Construction for Tunnel Mode..............29
5.1.2.2 IPv6 -- Header Construction for Tunnel Mode..............30
5.2 Processing Inbound IPsec Traffic...................................30
5.2.1 Selecting and Using an SA or SA Bundle...........................30
5.2.2 Handling of AH and ESP tunnels...................................31
6. ICMP Processing (relevant to this document. Other documents provide more definitions IPsec)....................................31
6.1 PMTU/DF Processing.................................................32
6.1.1 DF Bit........................................................32
6.1.2 Path MTU Discovery (PMTU).....................................32
6.1.2.1 Propagation of PMTU......................................33
6.1.2.2 Calculation of PMTU......................................34
6.1.2.3 Granularity of PMTU Processing...........................34
6.1.2.4 PMTU Aging...............................................34
7. Auditing...............................................................35
8. Use in Systems Supporting Information Flow Security....................35
8.1 Relationship Between Security Associations and background
information. [VK83, HA94]

Authentication (of Data Origin) Sensitivity....36
8.2 Sensitivity Consistency Checking...................................36

Kent, Atkinson [Page 1] 2]

Internet Draft Security Architecture for IP 10 November 1996 1997

8.3 Additional MLS Attributes for Security Association Databases.......37
8.4 Additional Inbound Processing Steps for MLS Networking.............37
8.5 Additional Outbound Processing Steps for MLS Networking............37
8.6 Additional MLS Processing for Security Gateways....................38
9. Performance Issues.....................................................38
10. Conformance Requirements..............................................39
11. Security Considerations...............................................39
12. Differences from RFC 1825.............................................39
Acknowledgements..........................................................39
Appendix A security property that ensures that the origin -- Glossary....................................................40
Appendix B -- Analysis/Discussion of received data
is, in fact, PMTU/DF/Fragmentation Issues.........44
B.1 DF bit.............................................................44
B.2 Fragmentation......................................................44
B.3 Path MTU Discovery.................................................48
B.3.1 Identifying the Originating Host(s)...........................49
B.3.2 Calculation of PMTU...........................................51
B.3.3 Granularity of Maintaining PMTU Data..........................51
B.3.4 Per Socket Maintenance of PMTU Data...........................53
B.3.5 Delivery of PMTU Data to the claimed sender. Usually bundled with integrity services,
especially connectionless integrity.

Integrity (Connectionless)
A security property that ensures data is transmitted from source to
destination without undetected alteration. If the order Transport Layer..................53
B.3.6 Aging of PMTU Data............................................53
Appendix C -- Sequence Space Window Code Example..........................54
Appendix D -- Categorization of
transmitted data also is ensured, ICMP messages.............................56
References................................................................59
Disclaimer................................................................62
Author Information........................................................62

Kent, Atkinson [Page 3]

Internet Draft Security Architecture for IP November 1997

1. Introduction

1.1 Summary of Contents of Document

This memo specifies the service is termed
connection-oriented integrity. base architecture for IPsec compliant
systems. The term anti-replay refers to a
minimal `qform goal of connection-oriented integrity designed to detect and
reject duplicated or very old data units.

Confidentiality
A security property that ensures that communicated data is
disclosed to intended recipients, but the architecture is not disclosed to other,
unauthorized parties. Traffic flow confidentiality extends this service to
externally visible characteristics of communication, e.g., source and
destination identifiers, message length, or frequency of communication.
(See also traffic analysis, below.)

Encryption
A mechanism commonly used to provide confidentiality.

Non-repudiation
A various security property that ensures that a participant in a
communication cannot later deny having participated
services for traffic at the IP layer, in both the communication. IPv4 and IPv6
environments. This property may apply to either document describes the sender or goals of such systems,
their components and how they fit together with each other and into
the recipient IP environment. It also describes the security services offered
by the IPsec protocols, and how these services can be employed in the
IP environment. This document does not address all aspects of
communccated data, or both.

SPI
Acronym IPsec
architecture. Subsequent documents will address additional
architectural details of a more advanced nature, e.g., use of IPsec
in NAT environments and more complete support for "Security Parameters Index." IP multicast. The combination
following fundamental components of an SPI
and a destination address uniquely identifies a simplex the IPsec security
association (SA, see below). The SPI is carried architecture
are discussed in IPsec protocols to
select the set terms of parameters bound their underlying, required functionality.
Additional RFCs (see Section 1.3 for pointers to an SA. An SPI has only local
significance, defined by the creator of the SA; thus an SPI is generally
viewed as an opaque bit string. However, the creator of an SA may choose
to interpret other documents)
define the bits protocols in an SPI to facilitate local processing. (a), (c), and (d).

a. Security Association (SA)
A simplex (uni-directional) logical connection, created Protocols -- Authentication Header (AH) and
Encapsulating Security Payload (ESP)
b. Security Associations -- what they are and how they work,
how they are managed, associated processing
c. Key Management -- manual and automatic (ISAKMP/Oakley)
d. Algorithms for
security purposes. All traffic traversing an SA authentication and encryption

This document is subjected to not an overall Security Architecture for the same
Internet; it addresses security processing only at the transmitter and receiver. In IPsec, an SA is a
network layer abstraction enforced IP layer, provided
through the use of AH a combination of cryptographic and protocol
security mechanisms.

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].

1.2 Audience

The target audience for this document includes implementers of this
IP security technology and others interested in gaining a general
background understanding of this system. In particular, prospective
users of this technology (end users or ESP.

Security Gateway
A system that acts administrators) are
part of the target audience. A glossary is provided as an appendix
to help fill in gaps in background/vocabulary. This document assumes
that the communications interface between
untrusted external, networks reader is familiar with the Internet Protocol, related
networking technology, and internal (trusted) hosts general security terms and subnetworks. concepts.

Kent, Atkinson [Page 2] 4]

Internet Draft Security Architecture for IP 10 November 1996

The internal subnets and hosts served by a security gateway are presumed to
be trusted by virtue 1997

1.3 Related Documents

As mentioned above, other documents provide detailed definitions of
some of sharing a common, local, security administration.
(See "Trusted Subnetwork" below.) In the components of IPsec context, a security gateway
is a point at which AH and/or ESP is implemented in order to serve a set and of
internal hosts, their inter-relationship.
They include RFCs on the following topics:

a. "IP Security Document Roadmap" [TDG97] -- a document
providing guidelines for specifications describing encryption
and authentication algorithms used in this system.
b. security services protocols -- RFCs describing the Authentication
Header (AH) [KA97a] and Encapsulating Security Payload (ESP)
[KA97b] protocols.
c. algorithms for these hosts when they
communicate with external hosts also employing authentication and encryption -- a separate
RFC for each algorithm.
d. automatic key management, e.g., an RFC on ISAKMP/Oakley and
"The Internet IP Security Domain of Interpretation for
ISAKMP" [Pip97].

2. Design Objectives

2.1 Goals/Objectives/Requirements/Problem Description

IPsec (either directly or
via another is designed to provide interoperable, high quality,
cryptographically-based security gateway).

Traffic Analysis for IPv4 and IPv6. The analysis set of network
security services offered includes access control, connectionless
integrity, data origin authentication, protection against replays (a
form of partial sequence integrity), confidentiality (encryption),
and limited traffic flow for confidentiality. These services are
provided at the purpose of deducing
information that is useful to an adversary. Examples of such information IP layer, offering protection for IP and/or upper
layer protocols.

These objectives are frequency of transmission, met through the identities use of two traffic security
protocols, the conversing parties,
sizes Authentication Header (AH) and the Encapsulating
Security Payload (ESP), and through the use of packets, flow Identifiers, etc. [Kent78]

Trusted Subnetwork
A subnetwork containing hosts cryptographic key
management procedures and routers that trust each other not
to engage protocols. The set of IPsec protocols
employed in active or passive attacks any context, and trust that the underlying
communications channel (e.g., an Ethernet) isn't being attacked.

1.2 Requirements Terminology

In this document, the words that ways in which they are used to define employed,
will be determined by the
significance security and system requirements of each particular requirement users,
applications, and/or sites/organizations.

When these mechanisms are usually capitalised. These
words are:

- MUST
This word or the adjective "REQUIRED" means that implementation of
the item is an absolute requirement of the specification.

- SHOULD
This word or the adjective "RECOMMENDED" means that there might
exist valid reasons in particular circumstances to not implement this item,
but the full implications should be understood correctly implemented and the case carefully
weighed before taking a different course.

- MAY
This word or the adjective "OPTIONAL" means that this item is truly
optional to implement. One vendor might choose to include the item because
a particular marketplace requires it or because it enhances the product,
for example; another vendor may omit the same item.

1.3 Basic IPsec features

Two specific headers used deployed, they
ought not to provide security services in IPv4 and
IPv6: the "IP Authentication Header (AH)" [Atk95a] adversely affect users, hosts, and the "IP
Encapsulating Security Payload (ESP)" [Atk95b] header. There are a number
of ways in which other Internet
components that do not employ these IP security mechanisms may for
protection of their traffic. These mechanisms also are designed to
be employed, in large
part because AH and ESP algorithm-independent. This modularity permits selection of
different sets of algorithms without affecting the other parts of the
implementation. For example, different user communities may be used independently select
different sets of one another, in algorithms (creating cliques) if required.

Kent, Atkinson [Page 3] 5]

Internet Draft Security Architecture for IP 10 November 1996

combination with one another, or 1997

A standard set of default algorithms is specified to facilitate
interoperability in an interated (nested) fashion. This
section describes the basic features global Internet. The use of both these
algorithms, in conjunction with IPsec traffic protection and key
management protocols, is intended to permit system and application
developers to deploy high quality, Internet layer, cryptographic
security technology.

2.2 Caveats and Assumptions

The suite of IPsec protocols and typical uses associated default algorithms are
designed to provide high quality security for Internet traffic.
However, the security offered by use of these protocols. The next section defines protocols ultimately
depends on the minimum header processing
configurations that all compliant IPsec implementations must support.
(Additional configurations may be supported at the discretion quality of the
implementor.) Thus their implementation, which is outside
the configuration examples in scope of this and set of standards. Moreover, the next section
are not exhaustive.

The IP Authentication Header (AH) can be used to provide
connectionless integrity and data origin authentication for IP datagrams,
and optionally to provide anti-replay integrity. This last, optional
service may be selected when security of a
computer system or network is a function of many factors, including
personnel, physical, procedural, compromising emanations, and
computer security association practices. Thus IPsec is established. This
header protects only one part of an entire IP datagram, including all immutable fields in
overall system security architecture.

Finally, the IP header. AH does not provide confidentiality; thus implementations security afforded by the use of AH may be widely deployed, even in countries where controls IPsec is critically
dependent on
encryption would preclude deployment of technology that also offered
confidentiality. This header should be used whenever the integrity and
authenticity many aspects of the IP header, as well as operating environment in which the associted upper layer
protocols, must be ensured.
IPsec implementation executes. For example, AH can be used to bind a
sensitivity label (e.g., IPSO [Kent91]) to an IP datagram.

The Encapsulating Security Payload (ESP) can be used to provide
confidentiality, data origin authentication, connectionless integrity,
anti-replay integrity, and limited traffic flow confidentiality. The set defects in OS security,
poor quality of services provided depends on options selected at random number sources, sloppy system management
protocols and practices, etc. can all degrade the time of security
association establishment and provided
by IPsec. As above, none of these environmental attributes are
within the implementation placement.
Confidentiality may be selected independent scope of all this or other services. Data
origin authentication and connectionless integrity are joint services,
independent IPsec standards.

3. System Overview

This section provides a high level description of confidentiality. Anti-replay may be selected only if data
origin authentication and connectionless integrity are selected, but is
independent of confidentiality. Traffic flow confidentiality depends on
confidentiality, and requires selection of tunnel mode (see below).

Unlike AH, ESP provides security only for the protocols encapsulated by
it, not the protocol that carries it. Perhaps how IPsec works,
the most obvious use components of ESP
is the system, and how they fit together to provide
the security services for upper layer protocols such as TCP,
without affording protection noted above. The goal of this description is
to enable the IP header that carries reader to "picture" the these
protocols. Because ESP is an encapsulation protocol, overall process/system, see how
it may be employed
recursively, fits into the IP environment, and to create nested security associations. For example, one
ESP-protected SA might extend between provide context for later
sections of this document, which describe each of the components in
more detail.

An IPsec implementation operates in a host and a security gateway, and or a
second, nested ESP-protected SA might extend from the same host through the security gateway
environment, affording protection to IP traffic. The protection
offered is based on requirements defined by a host behind the gateway.

Two modes Security Policy
Database (SPD) established and maintained by a user or system
administrator, or by an application operating within constraints
established by either of ESP the above. In general, packets are defined: transport mode selected
for one of three processing modes based on IP and tunnel mode. In
transport mode, ESP encapsulates any transport layer protocol defined for
carriage
header information (Selectors, Section 4.4.2) matched against entries
in the TCP/IP suite, e.g., TCP, UDP. This is the simplest mode
for use between a pair of hosts implementing ESP. In tunnel model, the
protocol encapsulated by ESP database (SPD). Each packet is usually IP but could also be another either afforded IPsec security

Kent, Atkinson [Page 4] 6]

Internet Draft Security Architecture for IP 10 November 1996

network-layer protocol (e.g. IPX). Tunnel mode is always used 1997

services, discarded, or allowed to bypass IPsec, based on the
applicable database policies identified by the Selectors.

3.1 What IPsec Does

IPsec provides security
gateways for all packets not originating on services at the gateway, IP layer by enabling a system
to facilitate
operation in multi-homed environments, especially select required security protocols, determine the algorithm(s) to
use for the service(s), and put in place any cryptographic keys
required to provide the face of possible
fragmentation of ESP-protected packets. Tunnel mode requested services. IPsec can be used to create
virtual private networks between sites protected by security gateways
implementing ESP.

Both AH and ESP can provide security services
protect one or more "paths" between a pair of
communicating hosts, or between a pair
of communicating security gateways gateways, or between a security gateway and a host. Depending on (The
term "security gateway" is used throughout the choice of
algorithms, AH and ESP also may support multicast communication, e.g.,
among IPsec documents to
refer to an intermediate system that implements IPsec protocols. For
example, a set of hosts or security gateways router or combinations thereof. When a
security gateway provides services for hosts on a trusted subnet, the
security gateway firewall implementing IPsec is responsible for establishing and managing a security
associations on behalf of the trusted hosts it serves.
gateway.)

The security
gateway also is responsible for providing set of security services between the
gateway itself and correspondant external systems (hosts or security
gateways) through the implementation that IPsec can provide includes access
control, connectionless integrity, data origin authentication,
rejection of AH and ESP.

1.4 Minimal Essential Support

All IPsec-compliant implementations MUST support AH and MUST
support ESP in both transport and tunnel modes. The requirement to support
tunnel-mode is imposed to ensure interoperability between host and security
gateway implementations replayed packets (a form of ESP. The requirement to support transport-mode
ensures interoperability with other hosts using transport-mode partial sequence integrity),
confidentiality (encryption), and limited traffic flow
confidentiality. Because these services are provided at the IP
layer, they can
permit some reduction in security overhead.

A compliant host or security gateway implementation MUST be capable
of creating and accepting security associations that employ either AH or
ESP. A compliant host or security gateway SHOULD also used by any higher layer protocol, e.g., TCP, UDP,
ICMP, BGP, etc.

NOTE: When encryption is employed within IPsec, it prevents effective
compression by lower protocol layers. However, IPsec does not
provide its own compression services. Such services may be capable of
creating pairs of AH and ESP security associations. A compliant host
implementation also MUST also support a second (nested) ESP security
association, provided
by existing higher layer protocols, or, in transport mode, above a tunnel mode ESP security
association. the future, in IP itself.
The following sequences of combinations of AH and ESP, each
represented IETF working group, "IP Payload Compression Protocol (ippcp)" has
the charter to "develop protocol specifications that make it possible
to perform lossless compression on individual payloads before the
payload is processed by a separate security association, must protocol that encrypts it. These
specifications will allow for compression operations to be supported by an
IPsec-compliant host: AH, ESP (tunnel), ESP(transport), AH-ESP(transport),
AH-ESP(tunnel), ESP(tunnel)-AH, AH-ESP(tunnel)-ESP(transport), and
ESP(tunnel)-ESP(transport).

The following sequences of combinations performed
prior to the encryption of AH and ESP must be
supported by a compliant payload by such protocols as IPsec."

3.2 How IPsec Works

IPsec uses two protocols to provide traffic security gateway: AH, ESP (tunnel), --
Authentication Header (AH) and
AH-ESP(tunnel). Note that transport-mode ESP security associations may be
employed across a security gateway, terminating at hosts behind the
gateway. The gateway does not process these SAs; they Encapsulating Security Payload (ESP).
Both protocols are passed through
transparently, and hence there is no required "support" described in the gateway for more detail in their respective RFCs
[KA97a, KA97b].

o The IP Authentication Header (AH) [KA97a] provides
connectionless integrity, data origin authentication, and an
optional anti-replay service.
o The Encapsulating Security Payload (ESP) protocol [KA97b]
provides confidentiality (encryption), and limited traffic
flow confidentiality. It also may provide connectionless

Kent, Atkinson [Page 5] 7]

Internet Draft Security Architecture for IP 10 November 1996

these header combinations.

A security gateway which receives a datagram containing a
recognised sensitivity label, for example IPSO [Ken91], from a trusted host
MUST take that label's value into consideration when creating/selecting 1997

integrity, data origin authentication, and an
Security Association for use with anti-replay
service.
o Both AH between and ESP are vehicles for access control, based on
the gateway distribution of cryptographic keys and the external
destination. In such an environment, a gateway which receives management of
traffic flows relative to these security protocols.

These protocols may be applied alone or in combination with each
other to provide a IP packet
containing the IP Encapsulating Security Payload (ESP) should add
appropriate authentication, including implicit (i.e. contained desired set of security services in IPv4 and IPv6.
Each protocol supports two modes of use: transport mode and tunnel
mode. In transport mode the
Security Association used) or explicit label information (e.g. IPSO), protocols provide protection primarily
for upper layer protocols; in tunnel mode, the decrypted packet that it forwards protocols are applied
to tunneled IP packets. The differences between the trusted host that is two modes are
discussed in Section 4.

IPsec allows the
ultimate destination. The IP Authentication Header should always be used
on packets containing explicit sensitivity labels to ensure end-to-end
label integrity. In environments using security gateways, those gateways
MUST perform address-based IP packet filtering on unauthenticated packets
purporting to be from a user (or system known administrator) to be using IP security.

A gateway control the
granularity at which receives a datagram containing a recognised sensitivity
label from security service is offered. For example, one
can create a trusted host should take that label's value into consideration
when creating/selecting single encrypted tunnel to carry all the traffic between
two security gateways or a Security Association separate encrypted tunnel can be created
for use with ESP each TCP connection between the
gateway each pair of hosts communicating
across these gateways. IPsec management must incorporate facilities
for specifying:

o which security services to use and in what combinations
o the external destination. In such an environment, a gateway granularity at which receives a IP packet containing the ESP should appropriately label
the decrypted packet that it forwards to the trusted host that is the
ultimate destination. IP given security protection should always be
applied
o the algorithms used to effect cryptographic-based security

Because these security services use shared secret values
(cryptographic keys), IPsec relies on packets
containing explicit sensitivity labels a separate set of mechanisms
for putting these keys in place. (The keys are used for
authentication/integrity and encryption services.) This document
requires support for both manual and automatic distribution of keys.
It specifies a manner to ensure end-to-end
label integrity.

Routing headers specific public-key based approach (ISAKMP/Oakley --
[MSST97, Orm97, HC97]) for automatic key management, but other
automated key distribution techniques MAY be used. For example,
KDC-based systems such as Kerberos and other public-key systems such
as SKIP could be employed.

3.3 Where IPsec May Be Implemented

There are several ways in which integrity has not been cryptographically
protected SHOULD IPsec may be ignored by the receiver. If this rule is not strictly
adhered to, then implemented in a host or
in conjunction with a router or firewall (to create a security
gateway). Several common examples are provided below:

a. Integration of IPsec into the system will be vulnerable native IP implementation. This
requires access to various kinds of attacks,
including the IP source routing attacks. [Bel89][CB94][CERT95]

1.5 Security Association Management

The concept of a "Security Association" code and is fundamental applicable to
both hosts and security gateways.

Kent, Atkinson [Page 8]

Internet Draft Security Architecture for IP November 1997

b. "Bump-in-the-stack" (BITS) implementations, where IPsec is
implemented "underneath" an existing implementation of an IP
protocol stack, between the native IP Encapsulating Security Payload and the local network
drivers. Source code access for the IP Authentication Header. The
combination of a given Security Parameter Index (SPI) and Destination
Address uniquely identifies a particular "Security Association". An stack is not required
in this context, making this implementation approach
appropriate for use with legacy systems. This approach, when
it is adopted, is usually employed in hosts.

c. The use of an outboard crypto processor is a common design
feature of network security systems used by the Authentication Header military, and
of some commercial systems as well. It is sometimes referred
to as a "Bump-in-the-wire" (BITW) implementation. Such
implementations may be designed to serve either a host or a
gateway (or both). Usually the Encapsulating BITW device is IP
addressable. When supporting a single host, it may be quite
analogous to a BITS implementation, but in supporting a
router or firewall, it must operate like a security gateway.

4. Security
Payload Associations

This section defines Security Association management requirements for
all IPv6 implementations and for those IPv4 implementations that
implement AH, ESP, or both. The concept of a "Security Association"
(SA) is fundamental to IPsec. Both AH and ESP make use of SAs and a
major function of ISAKMP/Oakley is the establishment and maintenance
of Security Associations. All implementations of AH or ESP MUST
support this the concept of a Security Association. Association as described below.
The remainder of this section describes various aspects of Security
Association management, defining required characteristics for SA
policy management, traffic processing, and SA management techniques.

4.1 Definition and Scope

A single IPsec Security Association (SA) is a simplex (unidirectional)
connection with which either AH "connection" that affords
security services to the traffic carried by it. Security services
are afforded to an SA by the use of AH, or ESP (but ESP, but not both) is employed. both. If
both AH and ESP protection is to be applied to a traffic stream, then two
(or more) security associations SAs are created to control processing of afford protection to the traffic stream.

A compliant implementation of IPsec
To secure typical, bi-directional communication between two hosts, or
between two security gateways, two Security Association MUST Associations (one in each
direction) are required.

A security association is uniquely identified by a triple consisting
of a Security Parameter Index (SPI), an IP Destination Address, and a
security protocol (AH or ESP) identifier. In principle, the
Destination Address may be a unicast address, an IP broadcast
address, or a multicast group address. However, IPsec SA management

Kent, Atkinson [Page 6] 9]

Internet Draft Security Architecture for IP 10 November 1996

support the following management parameters 1997

mechanisms currently are defined only for each SA; other parameters
MAY also unicast SAs. Hence, in the
discussions that follow, SAs will be included at described in the discretion context of
point-to-point communication, even though the implementor:

- Authentication algorithm concept is applicable
in the point-to-multipoint case as well.

As noted above, two types of SAs are defined: transport mode and
tunnel mode. A transport mode being used for AH or ESP.
[REQUIRED for all implementations].
- Key(s) used with SA is a security association between
two hosts. In IPv4, a transport mode security protocol header
appears immediately after the above authentication algorithm
[REQUIRED for all implementations].
- Encryption algorithm IP header and mode used with ESP.
[REQUIRED for ESP implementations]
- Key(s) used with any options, and before
any higher layer protocols (e.g., TCP or UDP). In IPv6, the above encryption algorithm.
[REQUIRED for ESP implementations]
- Presence/absence security
protocol header appears after the base IP header and size of a cryptographic synchronisation extensions, but
may appear before or
initialisation vector field for after destination options, and before higher
layer protocols. In the encryption algorithm.
[REQUIRED case of ESP, a transport mode SA provides
security services only for ESP implementations]
- Authentication key crypto period (fixed future time or duration).
[REQUIRED these higher layer protocols, not for all implementations].
- Encryption key crypto period (fixed future tie the
IP header or duration)
[REQUIRED for any extension headers preceding the ESP implementations]
- Lifetime of this Security Association
[REQUIRED for all implementations]
- Destination IP Address of the Security Association; this may be
a wildcard address if more than one desitnation system shares header. In the
same Security Association (behind a security gateway)
[REQUIRED for all implementations]
- Source IP Address(es)
case of AH, the Security Association; this might be
a wildcard address if more than one sending system shares the
same Security Association with the destination
[REQUIRED for all implementations]
- Proxy IP Address protection is also extended to selected portions of
the Security Association; this contains
the IP address of the security gateway that provides security
services header (and options). For more details on behalf of the source IP address when IPsec coverage
afforded by AH, see the AH specification [KA97b].

A tunnel mode SA is
not in use end-to-end from source essentially an SA applied to destination.
[REQUIRED for Security Gateways;
RECOMMENDED for all other implementations]
- Replay Protection information, including whether it is in use,
information on the window size for the sequence numbers, etc.
[REQUIRED for all implementations]
- Sensitivity level an IP tunnel.
Whenever either end of a security association is a security gateway,
the protected data (e.g., in IPSO terms)
[REQUIRED for all systems claiming to provide multi-level
security, RECOMMENDED for all other systems]
- Next Protocol (from IP header) as SA MUST be tunnel mode. Thus an optional SA selector
input for outbound traffic
[RECOMMENDED for all implementations]
- Source and/or Destination TCP/UDP Ports between two security gateways
is always a tunnel mode SA, as is an optional SA
selector between a host and a security
gateway. Note that for outbound the case where traffic
[RECOMMENDED is destined for all implementations]
- Identity of a
security gateway, e.g., SNMP commands, the source of security gateway is acting
as a host and transport mode is allowed. But in that case, the Security Association
[RECOMMENDED for all implementations]

Atkinson [Page 7]

Internet Draft Security Architecture for IP 10 November 1996

- Identity of the destination of the Security Association]
[RECOMMENDED for all implementations]

The way in which
security associations are matched to offered
(outbound) traffic varies based on whether IPsec gateway is implemented in a
host or not acting as a security gateway, and on the granularity of i.e., not transiting
traffic. Two hosts MAY establish a tunnel mode SA management
selected. At between
themselves. The requirement for any (transit traffic) SA involving a host, the inputs
security gateway to be a tunnel SA selection are the userid of
the sender, the Destination Address (perhaps including arises due to the next
protocol field need to avoid
potential problems with regard to fragmentation and source and/or destination port fields reassembly of
IPsec packets, and
source/destination identities) is used in circumstances where multiple paths (e.g., via
different security gateways) exist to select the appropriate
Security Association for outbound traffic. For a multi-level secure
host, the senstivity of same destination behind the traffic, e.g., as expressed in a
security
label, also gateways.

For a tunnel mode SA, there is an input to "outer" IP header that specifies
the SA selection. A security gateway
generally does not have access to userid information and thus IPsec
implementations in such devices are not required to select SAs for
outbound traffic on processing destination, plus an "inner" IP header that basis. Since a security gateway typically
serves a number of hosts,
specifies the Source Address (perhaps including (apparently) ultimate destination for the
next packet. The
security protocol field header appears after the outer IP header, and source and/or destination port fields) is an
input to
before the SA selection. The Destination Address address also inner IP header. If AH is
an input, and when employed in a multi-level secure network context a traffic
sensitivity label is a REQUIRED additional input.

Processing for received (inbound) IPsec traffic is much simpler.
The receiving host uses the combination tunnel mode,
portions of the SPI and the
Destination Address to distinguish the correct association. Hence,
an IPsec implementation will always be able to use the SPI in
combination with the Destination Address to determine outer IP header are afforded protection (as above),
as well as all of the security
association with which tunneled IP packet (i.e., all of the traffic inner IP
header is associated. When a formerly
valid Security Association protected, as well as higher layer protocols). If ESP is terminated,
employed, the destination system(s)
SHOULD NOT immediately reuse that SPI and instead SHOULD let that SPI
value become stale before reusing it for some other Security
Association.

As noted above, an IPsec Security Association protection is unidirectional.
Hence, afforded only to secure typical, bi-directional communications between two
hosts (or security gateways), two Security Associations (one in each
direction) will be required. The Destination Address may be a
unicast address, an IPv4 broadcast address, or a multicast group
address.

Kent, Atkinson [Page 8] 10]

Internet Draft Security Architecture for IP 10 November 1996

select SPIs 1997

4.2 Security Association Functionality

The set of security services offered by an SA depends on behalf the security
protocol selected, the SA mode, the endpoints of that multicast group the SA, and then communicate on the information to all
election of optional services within the legitimate members of that multicast
group via mechanisms not defined here.

Multiple senders to a multicast group SHOULD use a single
Security Association (and hence Security Parameter Index) protocol. For example, AH
provides data origin authentication and connectionless integrity for all
traffic
IP datagrams (hereafter referred to that group when a symmetric cryptographic algorithm is in
use. In that case, the receiver only knows that as just "authentication"). The
"precision" of the message came
from authentication service is a system knowing function of the
granularity of the security association data for that
multicast group. A receiver cannot generally authenticate with which
system sent the multicast traffic when symmetric algorithms (e.g.
DES, IDEA) are in use. Multicast traffic SHOULD use a separate
Security Association for each sender to the multicast group when an
asymmetric cryptographic algorithm AH is employed, as
discussed in use. In this last case, the
receiver can know the specific system that originated Section 4.4.2, "Selectors".

AH also offers an anti-replay (partial sequence integrity) service at
the message.

2. DESIGN OBJECTIVES

This section describes some discretion of the design objectives of this
security architecture and its component mechanisms. The primary
objective receiver, to help counter denial of this work service
attacks. AH is an appropriate protocol to ensure that IPv4 and IPv6 will have
solid cryptographic security mechanisms available to users who desire
security.

These mechanisms are designed employ when
confidentiality is not required (or is not permitted, e.g , due to avoid adverse impacts
government restrictions on
Internet users who do not employ these security mechanisms use of encryption). AH also provides
authentication for their
traffic. These mechanisms are intended to selected portions of the IP header, which may be algorithm-independent
so that
necessary in some contexts. For example, if the cryptographic algorithms can integrity of an IPv4
option or IPv6 extension header must be altered without affecting protected en route between
sender and receiver, AH can provide this service (except for the other
non-predictable but mutable parts of the implementation. These security mechanisms
should be useful in enforcing a variety IP header.)

ESP always provides confidentiality for traffic. (However, the
strength of security policies.

Standard default algorithms (Keyed HMAC MD5, Keyed HMAC SHA,
DES- CBC) are specified to ensure interoperability in the global
Internet. The selected default algorithms are widely used confidentiality service will depend, in other
contexts.

3. IP-LAYER SECURITY MECHANISMS

There are two cryptographic security mechanisms for IP. The
first is part, on the Authentication Header which provides integrity and
encryption algorithm employed.) ESP also may optionally provide
authentication (as defined above). If authentication without confidentiality. [Atk95a] The second is negotiated
for an ESP SA, the
Encapsulating Security Payload which always provides confidentiality,
and usually provides integrity and authentication. [Atk95b] receiver also may elect to enforce an anti-replay
service with the same features as the AH anti-replay service. The two
IP security mechanisms are normally used separately. When both
confidentiality and
scope of the authentication are needed, a combined offered by ESP
transform should be used instead of using AH with ESP.

Atkinson [Page 9]

Internet Draft Security Architecture is narrower than for AH,
i.e., the IP 10 November 1996

These IP-layer mechanisms do header(s) "below" the ESP header is not provide complete security
against all traffic analysis attacks, though protected. If
only the upper layer protocols need to be authenticated, then ESP
authentication is an appropriate choice and is more space efficient
than use of AH encapsulating ESP.

An ESP (tunnel mode) SA between two security gateways can provide offer
partial traffic flow protection.
However, there are several techniques outside the scope of this
specification (e.g. bulk link encryption) that might be used to
provide more comprehensive protection against traffic analysis.
[VK83]

3.1 AUTHENTICATION HEADER confidentiality. The use of tunnel mode allows
the inner IP Authentication Header is designed headers to provide
authentication, integrity, be encrypted, concealing the identities of
the (ultimate) traffic source and replay protection destination. Moreover, ESP payload
padding also can be invoked to IP datagrams.
[Atk95a] It does this by computing a cryptographic authentication
function over hide the IP datagram and using one or more authentication
keys in size of the computation. The authentication algorithm may be either
symmetric or asymmetric. The sender computes packets, further
concealing the authentication data
prior to sending external characteristics of the authenticated traffic. Similar
traffic flow confidentiality services may be offered when a mobile
user is assigned a dynamic IP packet and places the
authentication data inside the Authentication Data. Fragmentation
occurs after the Authentication Header processing for outbound
packets address in a dialup context, and reassembly occurs prior
establishes a (tunnel mode) ESP SA to Authentication Header
processing a corporate firewall (acting as
a security gateway).

Kent, Atkinson [Page 11]

Internet Draft Security Architecture for inbound packets. IP November 1997

4.3 Combining Security Associations

The receiver verifies the
correctness of the authentication data upon reception.

Certain fields of the outer IP header that may change in transit datagrams transmitted over an individual SA are zeroed afforded
protection by exactly one security protocol, either AH or ESP, but
not both. Sometimes a security policy may call for the authentication calculation. For IPv4, these
fields are:

Type a combination of Service (TOS)
Time To Live (TTL)
Checksum
Offset
Flags

Also, IPv4 options are zeroed for the authentication
calculation, except
services for the IP Security Option BSO and ESO (RFC-1038,
RFC-1108) and the undocumented non-standard CIPSO (IPv4 Option number
134) option, which are included and are a particular traffic flow that is not zeroed.

For IPv6, achievable with a
single SA. In such instances it will be necessary to employ multiple
SAs to implement the "IP Version", "Type required security policy. The term "security
association bundle" or "SA bundle" is applied to a sequence of Service", "Flow Label", and
"Hop Limit" fields SAs
through which traffic must be processed to satisfy a security policy.
The order of the outermost IPv6 header are zeroed for sequence is defined by the
authentication calculation. IPv6 options contain a bit policy. (Note that
indicates whether the option might change during transit. Options
SAs that might change during transit are zeroed for the authentication
calculation and all others are included in the authentication
calculation. See the IPv6 specifications for more information.

Non-repudiation is not normally provided with the Authentication
Header. Confidentiality comprise a bundle may terminate at different endpoints. For
example, one SA may extend between a mobile host and traffic analysis protection are not

Atkinson [Page 10]

Internet Draft Security Architecture for IP 10 November 1996

provided by the Authentication Header. Replay Protection is normally
provided by the Authentication Header, though a user might choose not security
gateway and a second, nested SA may extend to use it.

Use of the Authentication Header will increase a host behind the IP protocol
processing costs
gateway.)

Security associations may be combined into bundles in participating systems two ways:
transport adjacency and will also increase the
communications latency. The increased latency is primarily due iterated tunneling.

o Transport adjacency refers to applying more than one security
protocol to the calculation same IP datagram, without invoking tunneling.
This approach to combining AH and ESP allows for only one
level of combination; further nesting yields no added benefit
since the authentication data by processing is performed at one IPsec instance the sender and
(ultimate) destination.

o Iterated tunneling refers to the
calculation and comparison application of the authentication data by each
receiver multiple
layers of security protocols effected through IP tunneling.
This approach allows for multiple levels of nesting, since
each IP datagram containing tunnel can originate or terminate at a different IPsec
site along the path.

These two approaches also can be combined, i.e., an Authentication Header
(AH).

The Authentication Header provides much stronger security than
exists SA bundle could
be constructed from one tunnel mode SA and one or two transport mode
SAs, applied in most sequence. Note that nested tunnels can also occur
where neither the source nor the destination endpoints of any of the current Internet and should not affect
exportability or significantly increase implementation cost. While
tunnels are the Authentication Header might same. In that case, there would be implemented by a no host or
security gateway
on behalf of hosts on with a trusted network behind that security gateway,
this bundle corresponding to the nested tunnels.

For transport mode SAs, only one ordering of operation security protocols seems
appropriate. AH is not encouraged. Instead, whenever possible
the Authentication Header should be used from origin to final
destination so that end-to-end protections are provided.

All IPv6-capable nodes and all IPv4 systems claiming applied to
implement the Authentication Header MUST implement both the standards-
track mandatory-to- implement AH transforms. As of this writing
these are HMAC MD5 [OG96] upper layer protocols and HMAC SHA [CG96], but implementers
should consult the most recent edition of the "Internet Official
Protocol Standards" [STD-1] for current guidance. An implementation
MAY support other authentication algorithms in addition to
(parts of) the
mandatory transforms.

3.2 ENCAPSULATING SECURITY PAYLOAD

The IP Encapsulating Security Payload (ESP) header. Thus if AH is designed to
provide integrity, authentication, and confidentiality to IP
datagrams. [Atk96b] ESP can also provide replay protection when used in a transport mode, in
conjunction with certain transforms. ESP encapsulates either an entire IP
datagram or only the upper-layer protocol (e.g. TCP, UDP, ICMP) data
inside the ESP, applies integrity and authentication protections, and
encrypts AH SHOULD appear as the data. If tunnel-mode is in use, a new cleartext IP first header is prepended after IP,
prior to the now encrypted Encapsulating Security
Payload. appearance of ESP. In tunnel-mode, the cleartext IP header that context, AH is used applied to carry
the protected data through
the internetwork.

3.2.1 Description ciphertext output of the ESP Modes

There are two modes within ESP. In contrast, for tunnel mode SAs, one
can imagine uses for various orderings of AH and ESP. The first mode, which is known
as Tunnel-mode, encapsulates an entire IP datagram within the
ESP header. The second mode, which required
set of SA bundle types that MUST be supported by a compliant IPsec
implementation is known as Transport- described in Section 4.5.

Kent, Atkinson [Page 11] 12]

Internet Draft Security Architecture for IP 10 November 1996

mode, encapsulates 1997

4.4 Security Association Databases

Many of the details associated with processing IP traffic in an upper-layer protocol (for example UDP or TCP)
inside ESP and then prepends IPsec
implementation are largely a cleartext IP header.

3.2.2 Usage local matter, not subject to
standardization. However, some external aspects of ESP

ESP works between hosts, between a host the processing
must be standardized, to ensure interoperability and to provide a security gateway,
or between security gateways. This support
minimum management capability that is essential for security gateways
permits trustworthy networks behind productive use of
IPsec. This section describes a security gateway general model for processing IP
traffic relative to omit
encryption security associations, in support of these
interoperability and thereby avoid functionality goals. The model described below
is nominal; compliant implementations need not match details of this
model as presented, but the performance external behavior of such implementations
must be mappable to the externally observable characteristics of this
model.

There are two nominal databases in this model: the Security Policy
Database and monetary costs the Security Association Database. The former specifies
the policies that determine the disposition of
encryption, while still providing confidentiality for all IP traffic
transiting untrustworthy network segments. When both hosts
directly implement ESP and there is no intervening inbound
or outbound from a host, security gateway,
then they may use the Transport- mode (where only the upper layer
protocol data (e.g. TCP or UDP) is encrypted and there is no
encrypted IP header). BITS or BITW IPsec
implementation. The latter database contains parameters that are
associated with each (active) security association. This mode reduces both section
also defines the bandwidth
consumed concept of a Selector, a set of IP and the upper layer
protocol processing costs for users field values that don't need
to keep is used by the entire IP datagram confidential. ESP works with both
unicast and multicast traffic.

3.2.3 Performance Impacts of ESP Security Policy Database to
map traffic to a policy, i.e., an SA (or SA bundle).

4.4.1 The encapsulating Security Policy Database (SPD)

Ultimately, a security approach association is a management construct used by ESP can noticeably
impact network performance to
enforce a security policy in participating systems, but use the IPsec environment. Thus an
essential element of ESP
should not adversely impact gateways or other intermediate systems SA processing is an underlying Security Policy
Database (SPD) that specifies what services are not participating in the particular ESP association.
Protocol processing in participating systems will to be more complex
when encapsulating security is used, requiring both more time and
more processing power. Use of encryption will also increase the
communications latency. The increased latency is primarily due offered to
the encryption and decryption required for each IP datagram
containing an Encapsulating Security Payload.
datagrams and in what fashion. The precise cost of
ESP will vary with the specifics form of the implementation, including the
encryption algorithm, key size, database and other factors. Hardware
implementations of the encryption algorithm its
interface are recommended when high
throughput is desired.

For interoperability throughout the worldwide Internet, all
conforming implementations of the IP Encapsulating Security Payload
MUST also implement outside the standard mandatory ESP transform. As scope of this
writing, specification. However, this
section does specify certain minimum management functionality that
must be provided, to allow a user or system administrator to control
how IPsec is applied to traffic transmitted or received by a host or
transiting a security gateway.

An SPD must discriminate among traffic that is afforded IPsec
protection and traffic that is allowed to bypass IPsec. This applies
to the Combined ESP transform with DES-CBC, HMAC MD5, IPsec protection to be applied by a sender and Replay Protection. [Hugh96] Implementers should consult to the most
recent "IAB Official Protocols" RFC for current information on IPsec
protection that must be present at the
mandatory receiver. For any outbound or
inbound datagram, three processing choices are possible: discard,
bypass IPsec, or apply IPsec. The first choice refers to implement ESP transform(s). Other confidentiality
algorithms and modes may also traffic
that is not allowed to exit the host, traverse the security gateway,
or be implemented in addition delivered to this
mandatory algorithm and mode. Export and use of encryption are
regulated in some countries. [OTA94] an application at all. The second choice refers
to traffic that is allowed to pass without additional IPsec
protection. The third choice refers to traffic that is afforded

Kent, Atkinson [Page 12] 13]

Internet Draft Security Architecture for IP 10 November 1996

3.3 COMBINING SECURITY MECHANISMS

A node normally does not apply both ESP 1997

IPsec protection, and AH to for such traffic the same IP
datagram. If confidentiality is not required, then AH should SPD must specify the
security services to be
used. If confidentiality is required, then ESP should provided, protocols to be used. In
some circumstances employed,
algorithms to be used, etc.

For every IPsec implementation, there MUST be an administrative
interface that allows a security gateway might apply ESP user or system administrator to manage the
SPD. This interface must allow the user (or AH) system administrator) to
specify the security processing to be applied to each packet entering
or exiting the system, on a packet before forwarding that by packet because basis. (In a secure tunnel has been
configured in that security gateway. Hence, IP packets containing
both ESP and AH are not strictly prohibited.

3.4 OTHER SECURITY MECHANISMS

Protection from traffic analysis is not provided by any host IPsec
implementation making use of a socket interface, the
security mechanisms described above. It is unclear whether
meaningful protection from traffic analysis can SPD may not need
to be provided
economically at consulted on a per packet basis, but the Internet Layer and it appears that few Internet
users are concerned about traffic analysis. One traditional method
for protection against traffic analysis effect is still the use
same.) The management interface for the SPD MUST allow creation of bulk link
encryption. Another technique
entries consistent with the selectors defined in Section 4.4.2, and
MUST support ordering of these entries.

In host systems, applications MAY be allowed to select what security
processing is to send false be applied to the traffic in order they generate and consume.
(Means of signalling such requests to
increase the noise in IPsec implementation are
outside the data provided by traffic analysis.
Reference [VK83] discusses traffic analysis issues in more detail.

4. SECURITY ASSOCIATION MANAGEMENT

The Security Management protocol that will be used with IP layer
security is not specified in scope of this document. standard.) However, because the
security management protocol is coupled system
administrator MUST be able to AH and ESP only via the
Security Parameters Index (SPI), we specify whether or not a user or
application can meaningfully define AH and
ESP without having override (default) system policies. Note that
application specified policies may satisfy system requirements, so
that the system may not need to fully specify how security management is
performed. We envision do additional IPsec processing beyond
that several security management systems will
be usable with these specifications, including manual key
configuration.

Support for key management methods where needed to meet an application's requirements. The form of the key
management data
is carried in-line within the IP layer interface is not a design objective specified by this document and may differ
for
these IP-layer security mechanisms. Instead these IP-layer hosts vs. security
mechanisms will primarily use key management methods where gateways, and within hosts the key
management data will be carried by interface may
differ for socket-based vs. BITS implementations. However, this
document does specify a standard set of SPD elements that all IPsec
implementations MUST support.

The SPD contains an upper layer protocol, such as
UDP or TCP, on some specific port number ordered list of policy entries. Each policy
entry is keyed by one or where more selectors that define the key management
data set of IP
traffic encompassed by this policy entry. (The required selector
types are defined in Section 4.4.2.) These define the granularity of
policies or SAs. Each entry includes an indication of whether
traffic matching this policy will be distributed manually.

This design permits clear decoupling of bypassed, discarded, or subject
to IPsec processing. If IPsec processing is to be applied, the key management
mechanism from entry
includes an SA (or SA bundle) specification, listing the other security mechanisms, IPsec
protocols, modes, and thereby permits one algorithms to substitute new and improved key management methods without having be employed, including any
nesting requirements. For example, an entry may call for all
matching traffic to modify be protected by ESP in transport mode using
3DES-CBC with an explicit IV, nested inside of AH in tunnel mode
using HMAC/SHA-1. For each selector, the implementations policy entry specifies
which of the other security mechanisms. This
separation of mechanism is clearly wise given the long history of
subtle flaws following values should used in published key management protocols. [NS78, NS81] What
follows the SA: (a) the value in this section is
the packet, (b) the value associated with the policy, or (c) a brief discussion
wildcard.

Case (c) permits the sharing of a few alternative an SA (or SA bundle) by multiple SPD

Kent, Atkinson [Page 13] 14]

Internet Draft Security Architecture for IP 10 November 1996

approaches 1997

entries. Case (a) can be used to key management. Mutually consenting systems prohibit sharing, even among
packets that match the same SPD entry.

As described below in Section 4.4.3, selectors may
additionally use other key management approaches by private prior
agreement.

4.1 Manual Key Distribution

The simplest form of key management is manual key management,
where a person manually configures each system with its own key include "wildcard"
entries and
also with hence the keys of other communicating systems. This selectors for two entries may overlap. (This
is quite
practical analogous to the overlap that arises with ACLs or filter entries
in small, static environments but does not scale. It is
not a viable medium-term routers or long-term approach, but might packet filtering firewalls.) Thus, to ensure
consistent, predictable processing, SPD entries MUST be
appropriate ordered and useful in many environments
the SPD MUST always be searched in the near-term. For
example, within a small LAN it is entirely practical to manually
configure keys for each system. Within a single administrative
domain it is practical to configure keys for each router same order, so that the
routing data can first
matching entry is consistently selected. (This requirement is
necessary as the effect of processing traffic against SPD entries
must be protected and deterministic, but there is no way to reduce canonicalize SPD
entries given the risk use of an intruder
breaking into a router. Another case wildcards and enumerated lists for some
selectors.) More detail on matching of packets against SPD entries
is where an organisation has an
encrypting firewall between provided in Section 5.

The SPD can be used to map traffic to specific SAs or SA bundles.
Thus it can function both as the internal network reference database for security
policy and as the Internet at
each of its sites and it connects two or more sites via the Internet.
In this case, map to existing SAs (or SA bundles). (To
accommodate the security gateway might selectively encrypt traffic
for other sites within bypass and discard policies cited above, the organisation using SPD also
MUST provide a manually configured
key, while not encrypting means of mapping traffic to these functions, even
though they are not, per se, IPsec processing.) The way in which the
SPD operates is different for other destinations. It inbound vs. outbound traffic and it
also
might be appropriate when only selected communications need to be
secured.

4.2 Requirements may differ for Key Management Protocols

Widespread deployment host vs. security gateway, BITS, and BITW
implementations. Sections 5.1 and 5.2 describe the use of IP security requires an
Internet-standard scalable key management protocol. This protocol
should not be limited to supporting IP security. This protocol
should be compatible with the IETF's DNS Security work SPD
for outbound and should
include the ability to obtain bootstrapping information (e.g. keys,
addresses) from the Secure DNS as inbound processing, respectively.

Because a mandatory-to-implement feature.
signed host keys security policy may require that more than one SA be
applied to a specified set of traffic, in a specific order, the Domain Name System [EK96] The DNS keys enable
policy entry in the originating party SPD must preserve these ordering requirements,
when present. Thus, it must be possible for an IPsec implementation
to authenticate key management messages with
the other key management party using determine that an asymmetric algorithm. A
standards-track key management protocol outbound or inbound packet must be processed
thorough a sequence of SAs. Conceptually, for use with IP Security MUST
provide outbound processing,
one might imagine links (to the property SAD) from an SPD entry for which
there are active SAs, and each entry would consist of "Perfect Forward Secrecy" as either a mandatory-to-
implement feature. Further, any standards-track key management
protocol MUST permit the secure negotiation single
SA or secure identification
of all of the Security Association attributes [as defined above] to
all parties an ordered list of SAs that Security Association.

4.4 Keying Approaches for IP

There are several keying approaches for IP. The first approach,
called host-oriented keying, has all users on host 1 share comprise an SA bundle. When a
packet is matched against an SPD entry and there is an existing SA or
SA bundle that can be used to carry the same
key for use traffic, the processing of
the packet is controlled by the SA or SA bundle entry on traffic destined the list.
For an inbound IPsec packet for all users which multiple IPsec SAs are to be
applied, the lookup based on host 2. destination address, IPsec protocol, and
SPI should identify a single SA. To allow minimization of the number
of SAs, the linkage between the SPD and the SAD (at both the sender
and the receiver) MUST allow an SA to be used in more than one
bundle.

The second SPD also will be consulted when any IPsec implementation is the
target of an SA establishment request from another IPsec

Kent, Atkinson [Page 14] 15]

Internet Draft Security Architecture for IP 10 November 1996

approach, called user-oriented keying, lets user A on host 1 have one 1997

implementation, e.g., using ISAKMP/Oakley.

4.4.2 Selectors

An SA (or SA bundle) may be fine-grained or more unique session keys for its coarse-grained, depending
on the selectors used to define the set of traffic destined for host 2; such
session keys are not shared with other users on host1. the SA. For
example,
user A's ftp session might use a different key than user A's telnet
session. In systems claiming to provide multi-level security, user A
will typically have at least one key per sensitivity level in use
(e.g. one key for UNCLASSIFIED traffic, all traffic between two hosts may be carried via a second key for SECRET
traffic, single
SA, and afforded a third key for TOP SECRET traffic). Similarly, with
user-oriented keying one might use separate keys for information sent
to uniform set of security services. Alternatively,
traffic between a multicast group and control messages sent to the same multicast
group. A third approach, called session-unique keying, has pair of hosts might be spread over multiple SAs,
depending on the applications being used (as defined by the Next
Protocol and Port fields), with different security services offered
by different SAs. Similarly, all traffic between a pair of security
gateways could be carried on a single
key being SA, or one SA could be assigned
for each communicating host pair. The following selector parameters
MUST be supported for SA management to facilitate control of SA
granularity. Note that in the case of receipt of a given IP address, upper-layer packet with an
ESP header, e.g., at an encapsulating security gateway or BITW
implementation, the transport layer protocol, source/destination
ports, and
port number triple.

In many cases, UserID (if present) may be opaque.

- Destination IP Address (IPv4 or IPv6): this may be a single computer system will have at least IP
address (unicast, broadcast, or multicast group), an enumerated
list or range of addresses, or a wildcard (mask) address. The
latter two
mutually suspicious users A and B are required to support more than one destination
system sharing the same SA (e.g., behind a security gateway).
Note that do not trust each other. When
host-oriented keying this selector is conceptually different from the
"Destination IP Address" field in the <Destination IP Address,
IPsec Protocol, SPI> used and mutually suspicious users exist, it
is sometimes possible for user A to determine uniquely identify an SA. It could
have the host-oriented key
via well known methods, such as same value.
[REQUIRED for all implementations]

- Source IP Address(es) (IPv4 or IPv6): this may be a Chosen Plaintext attack. Once user
A has improperly obtained the key in use, user A can then either read
user B's encrypted traffic single IP
address, an enumerated list or forge traffic from user B. When user-
oriented keying is used, certain kinds range of attack from one user onto
another user's traffic addresses, or a wildcard
(mask) address. The latter two are not possible.

IP Security is intended required to support more
than one source system sharing the same SA (e.g., behind a
security gateway or in a multihomed host).
[REQUIRED for all implementations]

- UserID: a user identifier from the operating system. Note that
one of the possible values of this selector is "OPAQUE". (The
use of a User ID as an SA selector is sometimes referred to as
"user-oriented keying.")
[REQUIRED for host implementations, unless the layering of the
implementation precludes access to this information, e.g., a
BITS implementation need not support this selector.]

- Data sensitivity level: (IPSO/CIPSO labels)
[REQUIRED for all systems providing information flow security as

Kent, Atkinson [Page 16]

Internet Draft Security Architecture for IP November 1997

per Section 8, OPTIONAL for all other systems.]

- Transport Layer Protocol: Obtained from the IPv4 "Protocol" or
the IPv6 "Next Header" fields. This may be an individual
protocol number, a list of protocol numbers, or a range of
protocol numbers. These packet fields may not contain the
Transport Protocol due to the presence of IP extension headers,
e.g., a Routing Header, AH, ESP, Fragmentation Header,
Destination Options, Hop-by-hop options, etc. Note that the
Transport Protocol may not be available in the case of receipt
of a packet with an ESP header, thus a value of "OPAQUE" SHOULD
be supported.
[REQUIRED for IPv6 implementations, MAY be supported in IPv4
implementations]

NOTE: To locate the transport protocol, a system has to chain
through the packet headers checking the "Protocol" or "Next
Header" field until it encounters either one it recognizes as a
transport protocol, or until it reaches one that isn't on its
list of extension headers, or until it encounters an ESP header
that renders the transport protocol opaque.

- IPsec protocol (AH or ESP or AH/ESP): If present, this is
obtained from the IPv4 "Protocol" field or the IPv6 "Next
Header" field.
[REQUIRED for all implementations]

NOTE: The "Protocol" or "Next Header" field could contain a
Transport Protocol, Routing Header, AH, ESP, Fragmentation
Header, Destination Options, Hop-by-hop options, etc. Although
IPv6 recommends a particular order for extension headers, it
also specifies that the implementation must be prepared to
accept them in any order. So to check for the existence of an
IPsec header, a system has to chain through the packet headers
checking the Protocol/Next Header field until it has checked all
that are not opaque.

- Source and Destination (e.g., TCP/UDP) Ports: These may be
individual UDP or TCP port values, an enumerated list of ports,
or a wildcard port. (The use of the Next Protocol field and the
Source and/or Destination Port fields (in conjunction with the
Source and/or Destination Address fields), as an SA selector is
sometimes referred to as "session-oriented keying."). Note that
the source and destination ports may not be available in the
case of receipt of a packet with an ESP header, thus a value of
"OPAQUE" SHOULD be supported.
[REQUIRED for all implementations]

Kent, Atkinson [Page 17]

Internet Draft Security Architecture for IP November 1997

- IPv6 Class (from IP header): This may be expressed as a wildcard
value or a specific IPv6 Class value.
[REQUIRED for all systems that implement IPv6]

- IPv6 Flow Label (from IP header): This may be expressed as a
wildcard value or a specific Flow Label. The IPv6 spec (RFC
1883) calls for all datagrams for a given IPv6 Flow Label to
have the same Source Address, Destination Address, Hop-by-hop
Options header, and Routing Header. The Flow Label may be
assigned on a per socket basis. It would then be correlated
with the Source/Destination and could be used to provide finer
granularity selection of security association(s).
[REQUIRED for all systems that implement IPv6]

- IPv4 Type of Service (TOS): Obtained from the IPv4 header. This
may be expressed as a wildcard or an explicit value.
[REQUIRED for all IPv4 systems that implement IPsec]

The IPsec implementation context determines how selectors are used.
For example, a host implementation integrated into the stack may make
use of a socket interface. When a new connection is established the
SPD can be consulted and an SA (or SA bundle) bound to the socket.
Thus traffic sent via that socket need not result in additional
lookups to the SPD/SAD. In contrast, a BITS, BITW, or security
gateway implementation needs to look at each packet and perform an
SPD/SAD lookup based on the selectors. The allowable values for the
selector fields differ between the traffic flow, the security
association, and the security policy.

The following table summarizes the kinds of entries that one needs to
be able to express in the SPD and SAD. It shows how they relate to
the fields in data traffic being subjected to IPsec screening.
(Note: the "wild" or "wildcard" entry for src and dst addresses
includes a mask, list, etc.)

Kent, Atkinson [Page 18]

Internet Draft Security Architecture for IP November 1997

Field Traffic Value SAD Entry SPD Entry
-------- ------------- ---------------- --------------------
src addr single IP addr single,list,wild single,list,wildcard
dst addr single IP addr single IP addr single,list,wildcard
xpt protocol* xpt protocol single,list,wild single,list,wildcard
src port* single src port single,list,wild single,list,wildcard
dst port* single dst port single,list,wild single,list,wildcard
user id* single user id single,list,wild single,list,wildcard
IPsec prot AH,ESP,AH/ESP single or wild single or wildcard
IPv6 class IPv6 class single,list,wild single,list,wildcard
IPv6 flow IPv6 flow single,list,wild single,list,wildcard
IPv4 TOS IPv4 TOS single,list,wild single,list,wildcard
sec. labels single value single,list,wild single,list,wildcard

* The SAD and SPD entries for these fields could be "OPAQUE"
because the traffic value is encrypted.

4.4.3 Security Association Database (SAD)

In each IPsec implementation there is a nominal Security Association
Database, in which each entry defines the parameters associated with
one SA. Each SA has an entry in the SAD. For outbound processing,
entries are pointed to by entries in the SPD. Note that if an SPD
entry does not currently point to an SA that is appropriate for the
packet, before it creates an SA, the implementation should check to
see if the SAD already has an appropriate SA (created by some other
SPD entry). For inbound processing, each entry in the SAD is indexed
by a destination IP address, IPsec protocol type, and SPI. The
following parameters are associated with each entry in the SAD. This
description does not purport to be a MIB, but only a specification of
the minimal data items required to support an SA in an IPsec
implementation.

For inbound processing: The following packet fields are used to look
up the SA in the SAD:

o Outer Header's Destination IP address: the IPv4 or IPv6
Destination address.
[REQUIRED for all implementations]
o IPsec Protocol: AH or ESP, used as an index for SA lookup in
this database. Specifies the IPsec protocol to be applied to
the traffic on this SA.
[REQUIRED for all implementations]
o SPI: the 32-bit value used to distinguish among different SAs
terminating at the same destination and using the same IPsec
protocol.
[REQUIRED for all implementations]

Kent, Atkinson [Page 19]

Internet Draft Security Architecture for IP November 1997

For each of the selectors defined in Section 4.4.2, the SA entry
in the SAD MUST contain the value or values which were negotiated
at the time the SA was created. For the sender, these values are
used to decide whether a given SA is appropriate for use with an
outbound packet. This is part of checking to see if there is an
existing SA that can be used. For the receiver, these values are
used to check that the selector values in an inbound packet match
those for the SA (and thus indirectly those for the matching
policy). For the receiver, this is part of verifying that the SA
was appropriate for this packet. (See Section 6 for rules for
ICMP messages.) These fields can have the form of specific
values, lists, ranges, wildcards, or "OPAQUE" as described in
section 4.4.2, "Selectors".

The following SAD fields are used in doing IPsec processing:

o Sequence Number Counter: a 32-bit value used to generate the
Sequence Number field in AH or ESP headers.
[REQUIRED for all implementations, but used only for outbound
traffic.]
o Sequence Counter Overflow: a flag indicating whether overflow of
the Sequence Number Counter should generate an auditable event
and prevent transmission of additional packets on the SA.
[REQUIRED for all implementations, but used only for outbound
traffic.]
o Anti-Replay Window: a 32-bit counter and a bit-map (or
equivalent) used to determine whether an inbound AH or ESP
packet is a replay.
[REQUIRED for all implementations but used only for inbound
traffic.]
o AH Authentication algorithm, keys, etc.
[REQUIRED for AH implementations]
o ESP Encryption algorithm, keys, IV mode, IV, etc.
[REQUIRED for ESP implementations]
o ESP authentication algorithm, keys, etc. If the authentication
service is not selected, this field will be null.
[REQUIRED for ESP implementations]
o Lifetime of this Security Association: a time interval after
which an SA must be replaced with a new SA (and new SPI) or
terminated, plus an indication of which of these actions should
occur. This may be expressed as a time or byte count.
[REQUIRED for all implementations]
o IPsec protocol mode: tunnel, transport or wildcard. Indicates
which mode of AH or ESP is applied to traffic on this SA.
[REQUIRED for all implementations, unless implicitly defined by
context]
o Path MTU: any observed path MTU and aging variables. See

Kent, Atkinson [Page 20]

Internet Draft Security Architecture for IP November 1997

Section 6.1.2.4
[REQUIRED for all implementations but used only for outbound
traffic]

4.5 Basic Combinations of Security Associations

This section describes four examples of combinations of security
associations that MUST be supported by compliant IPsec hosts or
security gateways. Additional combinations of AH and/or ESP in
tunnel and/or transport modes MAY be supported at the discretion of
the implementor. Compliant implementations MUST be capable of
generating these four combinations and on receipt, of processing
them, but SHOULD be able to receive and process any combination. The
diagrams and text below describe the basic cases. The legend for the
diagrams is:

==== = one or more security associations (AH or ESP, transport
or tunnel)
---- = connectivity (or if so labelled, administrative boundary)
Hx = host x
SGx = security gateway x
X* = X supports IPsec

NOTE: The security associations below can be either AH or ESP. The
mode (tunnel vs transport) is determined by the nature of the
endpoints. For host-to-host SAs, the mode can be either transport or
tunnel.

Case 1. The case of providing end-to-end security between 2 hosts
across the Internet (or an Intranet).

====================================
| |
H1* ------ (Inter/Intranet) ------ H2*

Note that either transport or tunnel mode can be selected by the
hosts. Also, in transport mode at the sender, first ESP, then
AH can be applied to the packet. So the headers in a packet
between H1 and H2 could look like any of the following:

Transport Tunnel
----------------- ---------------------
1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper]
2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper]
3. [IP1][AH][ESP][upper]

Kent, Atkinson [Page 21]

Internet Draft Security Architecture for IP November 1997

Case 2. This case illustrates simple virtual private networks
support.

===========================
| |
---------------------|---- ---|-----------------------
| | | | | |
| H1 -- (Local --- SG1* |--- (Internet) ---| SG2* --- (Local --- H2 |
| Intranet) | | Intranet) |
-------------------------- ---------------------------
admin. boundary admin. boundary

Only tunnel mode is required here. So the headers in a packet
between SG1 and SG2 could look like either of the following:

Tunnel
---------------------
4. [IP2][AH][IP1][upper]
5. [IP2][ESP][IP1][upper]

Case 3. This case builds on case 2, adding end-to-end security
between the sending and receiving hosts. It imposes no new
requirements on the hosts or security gateways, other than a
requirement for a security gateway to be configurable to pass
IPsec traffic (including ISAKMP traffic) for hosts behind it.

===============================================================
| |
| ========================= |
| | | |
---|-----------------|---- ---|-------------------|---
| | | | | | | |
| H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* |
| Intranet) | | Intranet) |
-------------------------- ---------------------------
admin. boundary admin. boundary

Kent, Atkinson [Page 22]

Internet Draft Security Architecture for IP November 1997

Case 4. This covers the situation where a remote host (H1) uses the
Internet to reach an organization's firewall (SG2) and to then
gain access to some server or other machine (H2). The remote
host could be a mobile host (H1) dialing up to a local PPP/ARA
server (not shown) on the Internet and then crossing the
Internet to the home organization's firewall (SG2), etc. The
details of support for this case, (how H1 locates SG2,
authenticates it, and verifies its authorization to represent
H2) are discussed in Section 4.4.3, "Locating a Security
Gateway".

======================================================
| |
|============================== |
|| | |
|| ---|----------------------|---
|| | | | |
H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* |
^ | Intranet) |
| ------------------------------
could be dialup admin. boundary (optional)
to PPP/ARA server

Only tunnel mode is required between H1 and SG2. So the headers
in a packet between H1 and SG2 would look like one of the ones
in case 2.

The following combinations of AH and ESP MUST be supported in the
indicated contexts:

- Cases 1, 3, 4 (between H1 and H2):
a. AH in transport mode
b. ESP in transport mode
b. AH followed by ESP in transport mode
d. any one of a, b, or c above AH or ESP in tunnel mode
- Cases 1, 2, 3, and 4 (all SAs shown):
e. AH in tunnel mode
f. ESP in tunnel mode

As noted above, support for additional combinations of AH and ESP is
optional. Use of other, optional combinations may adversely affect
interoperability.

4.6 SA and Key Management

IPsec mandates support for both manual and automated SA and
cryptographic key management. The IPsec protocols, AH and ESP, are
largely independent of the associated SA management techniques,

Kent, Atkinson [Page 23]

Internet Draft Security Architecture for IP November 1997

although the techniques involved do affect some of the security
services offered by the protocols. For example, the optional anti-
replay services available for AH and ESP require automated SA
management. Moreover, the granularity of key distribution employed
with IPsec determines the granularity of authentication provided.
(See also a discussion of this issue in Section 4.7.) In general,
data origin authentication in AH and ESP is limited by the extent to
which secrets used with the authentication algorithm (or with a key
management protocol that creates such secrets) are shared among
multiple possible sources.

The following text describes the minimum requirements for both types
of SA management.

4.6.1 Manual Techniques

The simplest form of management is manual management, in which a
person manually configures each system with keying material and
security association management data relevant to secure communication
with other systems. Manual techniques are practical in small, static
environments but they do not scale well. For example, a company
could create a Virtual Private Network (VPN) using IPsec in security
gateways at several sites. If the number of sites is small, and
since all the sites come under the purview of a single administrative
domain, this is likely to be a feasible context for manual management
techniques. In this case, the security gateway might selectively
protect traffic to and from other sites within the organization using
a manually configured key, while not protecting traffic for other
destinations. It also might be appropriate when only selected
communications need to be secured. A similar argument might apply to
use of IPsec entirely within an organization for a small number of
hosts and/or gateways. Manual management techniques often employ
statically configured, symmetric keys, though other options also
exist.

4.6.2 Automated SA and Key Management

Widespread deployment and use of IPsec requires an Internet-standard,
scalable, automated, SA management protocol. Such support is
required to facilitate use of the anti-replay features of AH and ESP,
and to accommodate on-demand creation of SAs, e.g., for user- and
session-oriented keying. (Note that the notion of "rekeying" an SA
actually implies creation of a new SA with a new SPI, a process that
generally implies use of an automated SA/key management protocol.)

The default automated key management protocol selected for use with
IPsec is ISAKMP/Oakley [MSST97, Orm97, HC97] under the IPsec domain
of interpretation [Pip97]. Other automated SA management protocols

Kent, Atkinson [Page 24]

Internet Draft Security Architecture for IP November 1997

MAY be employed.

When an automated SA/key management protocol is employed, the output
from this protocol may be used to generate multiple keys, e.g., for a
single ESP SA. This may arise because:

o the encryption algorithm uses multiple keys (e.g., triple DES)
o the authentication algorithm uses multiple keys
o both encryption and authentication algorithms are employed

The Key Management System may provide a separate string of bits for
each key or it may generate one string of bits from which all of them
are extracted. If a single string of bits is provided, care needs to
be taken to ensure that the parts of the system that map the string
of bits to the required keys do so in the same fashion at both ends
of the SA. To ensure that the IPsec implementations at each end of
the SA use the same bits for the same keys, and irrespective of which
part of the system divides the string of bits into individual keys,
the encryption key(s) MUST be taken from the first (left-most, high-
order) bits and the authentication key(s) MUST be taken from the
remaining bits. The number of bits for each key is defined in the
relevant algorithm specification RFC. In the case of multiple
encryption keys or multiple authentication keys, the specification
for the algorithm must specify the order in which they are to be
selected from a single string of bits provided to the algorithm.

4.6.3 Locating a Security Gateway

This section discusses issues relating to how a host learns about the
existence of relevant security gateways and once a host has contacted
these security gateways, how it knows that these are the correct
security gateways. The details of where the required information is
stored is a local matter.

Consider a situation in which a remote host (H1) is using the
Internet to gain access to a server or other machine (H2) and there
is a security gateway (SG2), e.g., a firewall, through which H1's
traffic must pass. An example of this situation would be a mobile
host (Road Warrior) crossing the Internet to the home organization's
firewall (SG2). (See Case 4 in the section 4.5 Basic Combinations of
Security Associations.) This situation raises several issues:

Kent, Atkinson [Page 25]

Internet Draft Security Architecture for IP November 1997

1. How does H1 know/learn about the existence of the security
gateway SG2?
2. How does it authenticate SG2, and once it has authenticated
SG2, how does it confirm that SG2 has been authorized to
represent H2?
3. How does SG2 authenticate H1 and verify that H1 is authorized
to contact H2?
4. How does H1 know/learn about backup gateways which provide
alternate paths to H2?

To address these problems, a host or security gateway MUST have an
administrative interface that allows the user/administrator to
configure the address of a security gateway for any sets of
destination addresses that require its use. This includes the ability
to configure:

o the requisite information for locating and authenticating the
security gateway and verifying its authorization to represent
the destination host.
o the requisite information for locating and authenticating any
backup gateways and verifying their authorization to represent
the destination host.

It is assumed that the SPD is also configured with policy information
that covers any other IPsec requirements for the path to the security
gateway and the destination hos.

This document does not address the issue of how to automate the
discovery/verification of security gateways.

4.7 Security Associations and Multicast

The receiver-orientation of the Security Association implies that, in
the case of unicast traffic, the destination system will normally
select the SPI value. By having the destination select the SPI
value, there is no potential for manually configured Security
Associations to conflict with automatically configured (e.g., via a
key management protocol) Security Associations or for Security
Associations from multiple sources to conflict with each other. For
multicast traffic, there are multiple destination systems per
multicast group. So some system or person will need to coordinate
among all multicast groups to select an SPI or SPIs on behalf of each
multicast group and then communicate the group's IPsec information to
all of the legitimate members of that multicast group via mechanisms
not defined here.

Multiple senders to a multicast group SHOULD use a single Security
Association (and hence Security Parameter Index) for all traffic to

Kent, Atkinson [Page 26]

Internet Draft Security Architecture for IP November 1997

that group when a symmetric key encryption or authentication
algorithm is employed. In such circumstances, the receiver knows only
that the message came from a system possessing the key for that
multicast group. In such circumstances, a receiver generally will
not be able to authenticate which system sent the multicast traffic.
Specifications for other, more general multicast cases are deferred
to later IPsec documents.

At the time this specification was published, automated protocols for
multicast key distribution were not considered adequately mature for
standardization. For multicast groups having relatively few members,
manual key distribution or multiple use of existing unicast key
distribution algorithms such as modified Diffie-Hellman appears
feasible. For very large groups, new scalable techniques will be
needed. An example of current work in this area is the Group Key
Management Protocol (GKMP) [HM97].

5. IPsec Traffic Processing

5.1 Outbound IPsec Traffic Processing

5.1.1 Selecting and Using an SA or SA Bundle

In a security gateway or BITW implementation (and in many BITS
implementations), each outbound packet is compared against the SPD to
determine what processing is required for the packet. If the packet
is to be discarded, this is an auditable event. If the traffic is
allowed to bypass IPsec processing, the packet continues through
"normal" processing for the environment in which the IPsec processing
is taking place. If IPsec processing is required, the packet is
either mapped to an existing SA (or SA bundle), or a new SA (or SA
bundle) is created for the packet. Since a packet's selectors might
match multiple policies or multiple extant SAs and since the SPD is
ordered, but the SAD is not, IPsec MUST:

1. Match the packet's selector fields against the outbound
policies in the SPD to locate the first appropriate policy,
which will point to zero or more SA bundles in the SAD.

2. Match the packet's selector fields against those in the SA
bundles found in (1) to locate the first SA bundle that
matches. If no SAs were found or none match, search the SAD
for an SA (created by other SPD entries) that matches. If
none exist, create an appropriate SA bundle.

3. Use the SA bundle found/created in (2) to do the required
IPsec processing, e.g., authenticate and encrypt.

Kent, Atkinson [Page 27]

Internet Draft Security Architecture for IP November 1997

In a host IPsec implementation based on sockets, the SPD will be
consulted whenever a new socket is created, to determine what, if
any, IPsec processing will be applied to the traffic that will flow
on that socket.

5.1.2 Header Construction for Tunnel Mode

This section describes the handling of the inner and outer IP
headers, extension headers, and options for AH and ESP tunnels. This
includes how to construct the encapsulating (outer) IP header, how to
handle fields in the inner IP header, and what other actions should
be taken. The general idea is modeled after the one used in RFC
2003, "IP Encapsulation with IP":

o The outer IP header Source Address and Destination Address
identify the "endpoints" of the tunnel (the encapsulator and
decapsulator). The inner IP header Source Address and
Destination Addresses identify the original sender and recipient
of the datagram, respectively.
o The inner IP header is not changed except to decrement the TTL
as noted below, and remains unchanged during its delivery to the
tunnel exit point.
o No change to IP options or extension headers in the inner header
occurs during delivery of the encapsulated datagram through the
tunnel.
o If need be, other protocol headers such as the IP Authentication
header may be inserted between the outer IP header and the inner
IP header.

The tables in the following sub-sections show the handling for the
different header/option fields (constructed = the value in the outer
field is constructed independently of the value in the inner).

Kent, Atkinson [Page 28]

Internet Draft Security Architecture for IP November 1997

5.1.2.1 IPv4 -- Header Construction for Tunnel Mode

<-- How Outer Hdr Relates Inner Hdr -->
Outer Hdr at Inner Hdr at
IPv4 Encapsulator Decapsulator
Header fields: -------------------- ------------
version 4 (1) no change
header length constructed no change
TOS copied from inner hdr (5) no change
total length constructed no change
ID constructed no change
flags (DF,MF) constructed, DF (4) no change
fragmt offset constructed no change
TTL constructed (2) decrement (2)
protocol AH, ESP, routing hdr no change
checksum constructed no change
src address constructed (3) no change
dest address constructed (3) no change
Options never copied no change

1. The IP version in the encapsulating header can be different
from the value in the inner header.
2. The TTL in the inner header is decremented by the
encapsulator prior to forwarding and by the decapsulator if
it forwards the packet.
3. src and dest addresses depend on the SA, which is used to
determine the dest address which in turn determines which src
address (net interface) is used to forward the packet.
4. configuration determines whether to copy from the inner
header (IPv4 only), clear or set the DF.
5. If Inner Hdr is IPv4, copy the TOS. If Inner Hdr is IPv6,
map the Class to TOS.

Kent, Atkinson [Page 29]

Internet Draft Security Architecture for IP November 1997

5.1.2.2 IPv6 -- Header Construction for Tunnel Mode

See previous section 5.1.2 for notes 1-5 indicated by (footnote number).

<-- How Outer Hdr Relates Inner Hdr --->
Outer Hdr at Inner Hdr at
IPv6 Encapsulator Decapsulator
Header fields: -------------------- ------------
version 6 (1) no change
class copied or configured (6) no change
flow id copied or configured no change
len constructed no change
next header AH,ESP,routing hdr no change
hop count constructed (2) decrement (2)
src address constructed (3) no change
dest address constructed (3) no change
Extension headers never copied no change

6. If Inner Hdr is IPv6, copy the Class. If Inner Hdr IPv4,
map the TOS to Class.

5.2 Processing Inbound IPsec Traffic

Prior to performing AH or ESP processing, any IP fragments are
reassembled. Each inbound IP datagram to which IPsec processing will
be applied is identified by the appearance of the AH or ESP values in
the IP Next Protocol field (or of AH or ESP as an extension header in
the IPv6 context).

Note: Appendix C contains sample code for a bitmask check for a 32
packet window that can be used for implementing anti-replay service.

5.2.1 Selecting and Using an SA or SA Bundle

Mapping the IP datagram to the appropriate SA is simplified because
of the presence of the SPI in the AH or ESP header. Note that the
selector checks are made on the inner headers not the outer (tunnel)
headers. The steps followed are:

1. Use the packet's destination address (outer IP header), IPsec
protocol, and SPI to look up the SA in the SAD.

2. Use the SA found in (1) to do the IPsec processing, e.g.,
authenticate and decrypt. This step includes matching the
packet's (Inner Header if tunneled) selectors to the
selectors in the SA. Local policy determines the specificity
of the SA selectors (single value, list, range, wildcard).
In general, a packet's source address SHOULD match the SA

Kent, Atkinson [Page 30]

Internet Draft Security Architecture for IP November 1997

selector value. (However, an AH or ESP-protected ICMP packet
from a gateway may legitimately appear in a tunnel mode SA
with a source IP address other than that bound to the SA, and
thus such packets should be permitted as exceptions to this
check. See Section 6.) Other packet fields MAY match the SA
selector values as required by local policy.

Do (1) and (2) for every IPsec header until a Transport
Protocol Header or an IP header that is NOT for this system
is encountered. Keep track of what SAs have been used and
their order of application.

3. Find an incoming policy in the SPD that matches the packet.
This could be done, for example, by use of backpointers from
the SAs to the SPD or by matching the packet's selectors
(Inner Header if tunneled) against those of the policy
entries in the SPD.

4. Check whether the required IPsec processing has been applied,
i.e., verify that the SA's found in (1) and (2) match the
kind and order of SAs required by the policy found in (3).

NOTE: The correct "matching" policy will not necessarily be
the first inbound policy found. If the check in (4) fails,
steps (3) and (4) are repeated until all policy entries have
been checked or until the check succeeds.

At the end of these steps, pass the resulting packet to the Transport
Layer or forward the packet. Note that any IPsec headers processed
in these steps may have been removed, but that this information,
i.e., what SAs were used and the order of their application, may be
needed for subsequent IPsec or firewall processing.

5.2.2 Handling of AH and ESP tunnels

The handling of the inner and outer IP headers, extension headers,
and options for AH and ESP tunnels should be performed as described
in the tables in Section 5.1.

6. ICMP Processing (relevant to IPsec)

An ICMP message protected by AH or ESP and generated by a router
SHOULD be processed and forwarded in a tunnel mode SA, and MUST NOT
be subjected to source address checks. An ICMP message protected by
AH or ESP and generated by a router MUST NOT be forwarded on a
transport mode SA (unless the SA has been established to the router
acting as a host, e.g., a Telnet connection used to manage a router).
An ICMP message generated by a host SHOULD be checked against the

Kent, Atkinson [Page 31]

Internet Draft Security Architecture for IP November 1997

source IP address selectors bound to the SA in which the message
arrives.

The table in Appendix D characterize ICMP messages as being either
host generated, router generated, both, unknown/unassigned. ICMP
messages falling into the last two categories should be handled as
determined by the receiver's policy.

An ICMP message not protected by AH or ESP is unauthenticated and its
processing and/or forwarding may result in denial of service. This
suggests that, in general, it would be desirable to ignore such
messages. However, it is expected that many routers (vs. security
gateways) will not implement IPsec for transit traffic and thus
strict adherence to this rule would cause many ICMP messages to be
discarded. The result is that some critical IP functions would be
lost, e.g., redirection and PMTU processing. Thus it MUST be
possible to configure an IPsec implementation to accept or reject
(router) ICMP traffic as per local security policy.

The remainder of this section addresses how PMTU processing MUST be
performed at hosts and security gateways. It addresses processing of
both authenticated and unauthenticated ICMP PMTU messages. However,
as noted above, unauthenticated ICMP messages MAY be discarded based
on local policy.

6.1 PMTU/DF Processing

6.1.1 DF Bit

In cases where a system (host or gateway) adds an encapsulating
header (ESP tunnel or AH tunnel), it MUST support the option of
copying the DF bit from the original packet to the encapsulating
header (and processing ICMP PMTU messages). This means that it MUST
be possible to configure the system's treatment of the DF bit (set,
clear, copy from encapsulated header) for each interface. (See
Appendix B for rationale.)

6.1.2 Path MTU Discovery (PMTU)

This section discusses IPsec handling for Path MTU Discovery
messages. ICMP PMTU is used here to refer to an ICMP message for:

IPv4 (RFC 792):
- Type = 3 (Destination Unreachable)
- Code = 4 (Fragmentation needed and DF set)
- Next-Hop MTU in the low-order 16 bits of the second
word of the ICMP header (labelled "unused" in RFC
792), with high-order 16 bits set to zero

Kent, Atkinson [Page 32]

Internet Draft Security Architecture for IP November 1997

IPv6 (RFC 1885):
- Type = 2 (Packet Too Big)
- Code = 0 (Fragmentation needed and DF set)
- Next-Hop MTU in the 32 bit MTU field of the ICMP6
message

6.1.2.1 Propagation of PMTU

The amount of information returned with the ICMP PMTU message (IPv4
or IPv6) is limited and this affects what selectors are available for
use in further propagating the PMTU information. (See Appendix B for
more detailed discussion of this topic.)

o PMTU message with 64 bits of IPsec header -- If the ICMP PMTU
message contains only 64 bits of the IPsec header (minimum for
IPv4), then a security gateway MUST support the following options
on a per SPI/SA basis:

a. if the originating host can be determined (or the possible
sources narrowed down to a manageable number), send the PMTU
information to all the possible originating hosts.
b. if the originating host cannot be determined, store the PMTU
with the SA and wait until the next packet(s) arrive from the
originating host for the relevant security association. If
the packet(s) are bigger than the PMTU, drop the packet(s),
and compose ICMP PMTU message(s) with the new packet(s) and
the updated PMTU, and send the ICMP message(s) about the
problem to the originating host. Retain the PMTU information
for any message that might arrive subsequently (see Section
6.1.2.4, "PMTU Aging").

o PMTU message with >64 bits of IPsec header -- If the ICMP message
contains more information from the original packet, e.g., the 576
byte minimum for IPv6, then there MAY be enough non-opaque
information to immediately determine to which host to propagate the
ICMP/PMTU message and to provide that system with the 5 fields
(source address, destination address, source port, destination
port, transport protocol) needed to determine where to store/update
the PMTU. Under such circumstances, a security gateway MUST
generate an ICMP PMTU message immediately upon receipt of an ICMP
PMTU from further down the path.

o Distributing the PMTU to the Transport Layer -- The host mechanism
for getting the updated PMTU to the transport layer is unchanged,
as specified in RFC 1191 (Path MTU Discovery).

Kent, Atkinson [Page 33]

Internet Draft Security Architecture for IP November 1997

6.1.2.2 Calculation of PMTU

The calculation of PMTU from an ICMP PMTU MUST take into account the
addition of any IPsec header -- AH transport, ESP transport, AH/ESP
transport, ESP tunnel, AH tunnel. (See Appendix B for discussion of
implementation issues.)

6.1.2.3 Granularity of PMTU Processing

In hosts, the granularity with which ICMP PMTU processing can be done
differs depending on the implementation situation. Looking at a
host, there are 3 situations that are of interest with respect to
PMTU issues (See Appendix B for additional details on this topic.):

a. Integration of IPsec into the native IP implementation
b. Bump-in-the-stack implementations, where IPsec is implemented
"underneath" an existing implementation of a TCP/IP protocol
stack, between the native IP and the local network drivers
c. No IPsec implementation -- This case is included because it
is relevant in cases where a security gateway is sending PMTU
information back to a host.

Only in case (a) can the PMTU data be maintained at the same
granularity as communication associations. In (b) and (c), the IP
layer will only be able to maintain PMTU data at the granularity of
source and destination IP addresses (and optionally ToS), as
described in RFC 1191. This is an important difference, because more
than one communication association may map to the same source and
destination IP addresses, and each communication association may have
a different amount of IPsec header overhead (e.g., due to use of
different transforms or different algorithms).

Implementation of the calculation of PMTU and support for PMTUs at
the granularity of individual communication associations is a local
matter. However, a socket-based implementation of IPsec in a host
SHOULD maintain the information on a per socket basis. Bump in the
stack systems MUST pass an ICMP PMTU to the host IP implementation,
after adjusting it for any IPsec header overhead added by these
systems. The calculation of the overhead SHOULD be determined by
analysis of the SPI and any other selector information present in a
returned ICMP PMTU message.

6.1.2.4 PMTU Aging

In all systems (host or gateway) implementing IPsec and maintaining
PMTU information, the PMTU associated with a security association
(transport or tunnel) MUST be "aged" and some mechanism put in place
for updating the PMTU in a timely manner, especially for discovering

Kent, Atkinson [Page 34]

Internet Draft Security Architecture for IP November 1997

if the PMTU is smaller than it needs to be. A given PMTU has to
remain in place long enough for a packet to get from the source end
of the security association to the system at the other end of the
security association and propagate back an ICMP error message if the
current PMTU is too big. Note that if there are nested tunnels,
multiple packets and round trip times might be required to get an
ICMP message back to an encapsulator or originating host.

Systems SHOULD use the approach described in the Path MTU Discovery
document (RFC 1191, Section 6.3), which suggests periodically
resetting the PMTU to the first-hop data-link MTU and then letting
the normal PMTU Discovery processes update the PMTU as necessary.
The period SHOULD be configurable.

7. Auditing

Not all systems that implement IPsec will implement auditing. For
the most part, the granularity of auditing is a local matter.
However, several auditable events are identified in the AH and ESP
specifications 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 transmitter in response to the detection of an auditable
event, because of the potential to induce denial of service via such
action.

8. Use in Systems Supporting Information Flow Security

A multi-level secure (MLS) network is one where a single network is
used to communicate data with different sensitivity information
labels (e.g., Unclassified, Company Proprietary, Secret) [DoD85,
DoD87]. The IP security mechanisms can easily support MLS
networking. MLS networking requires the use of strong Mandatory
Access Controls (MAC), which unprivileged users or unprivileged
processes are incapable of controlling or violating [BL73]. This
section pertains only to the use of these IP security mechanisms in
MLS environments. Nothing in this section applies to systems not
claiming to provide MLS.

As used in this section, "sensitivity information" might include
implementation-defined hierarchic levels, categories, and/or
releasability information.

The Authentication Header can be used to provide strong assurance for
both mandatory access control decisions in multi-level networks and

Kent, Atkinson [Page 35]

Internet Draft Security Architecture for IP November 1997

discretionary access control decisions in all kinds of networks. If
explicit IP sensitivity information (e.g., IPSO [Ken91]) is used and
confidentiality is not considered necessary within the particular
operational environment, the Authentication Header can be used to
provide authentication for the entire packet, including cryptographic
binding of the sensitivity information to the IP header and user
data. This is a significant improvement over labeled IPv4 networks
where the sensitivity information is trusted even though there is no
authentication or cryptographic binding of the information to the IP
header and user data. IPv4 networks might or might not use explicit
labelling. IPv6 will normally use implicit sensitivity information
that is part of the IPsec Security Association but not transmitted
with each packet instead of using explicit sensitivity information.
All explicit IP sensitivity information MUST be authenticated using
either ESP, AH, or both.

Encryption is useful and can be desirable even when all of the hosts
are within a protected environment, for example, behind a firewall or
disjoint from any external connectivity. The Internet-standard
encryption algorithm could be used, in conjunction with appropriate
key management, to provide strong Discretionary Access Controls
(DAC). Key management could use sensitivity information to provide
Mandatory Access Controls (MAC). Some environments, depending on
their local policy, might consider the Internet-standard encryption
algorithm sufficiently strong to provide MAC. IPsec implementations
on systems claiming to provide MLS SHOULD be capable of using IPsec
to provide MAC for IP-based communications.

8.1 Relationship Between Security Associations and Data Sensitivity

Both the Encapsulating Security Payload and the Authentication Header
could be combined with appropriate Security Association policies to
provide multi-level secure networking. In this case each SA (or SA
bundle) is normally used for only a single instance of sensitivity
information. For example, "PROPRIETARY - Internet Engineering" must
be associated with a different SA (or SA bundle) from "PROPRIETARY -
Finance".

8.2 Sensitivity Consistency Checking

An MLS implementation (both host and router) MAY associate
sensitivity information, or a range of sensitivity information with
an interface, or a configured IP address with its associated prefix
(the latter is sometimes referred to as a logical interface, or an
interface alias). If such properties exist, an implementation SHOULD
compare the sensitivity information associated with the packet
against the sensitivity information associated with the interface or
address/prefix from which the packet arrived, or through which the

Kent, Atkinson [Page 36]

Internet Draft Security Architecture for IP November 1997

packet will depart. This check will either verify that the
sensitivities match, or that the packet's sensitivity falls within
the range of the interface or address/prefix.

The checking SHOULD be done on both inbound and outbound processing.

8.3 Additional MLS Attributes for Security Association Databases

Section 4.4 discussed two Security Association databases (the
Security Policy Database (SPD) and the Security Association Database
(SAD)) and the associated policy selectors and SA attributes. MLS
networking introduces an additional selector/attribute:

- Sensitivity information.

The Sensitivity information aids in selecting the appropriate
algorithms and key strength, so that the traffic gets a level of
protection appropriate to its importance or sensitivity as described
in section 8.1. The exact syntax of the sensitivity information is
implementation defined.

Sensitivity information is needed in the model shown in [BL73].

8.4 Additional Inbound Processing Steps for MLS Networking

After an inbound packet has passed through IPsec processing, an MLS
implementation SHOULD first check the packet's sensitivity (as
defined by the SA (or SA bundle) used for the packet) with the
interface or address/prefix as described in section 8.2 before
delivering the datagram to an upper-layer protocol or forwarding it.

The MLS system MUST retain the binding between the data received in
an IPsec protected packet and the sensitivity information in the SA
or SAs used for processing, so appropriate policy decisions can be
made when delivering the datagram to an application or forwarding
engine. The means for maintaining this binding are implementation
specific.

8.5 Additional Outbound Processing Steps for MLS Networking

An MLS implementation of IPsec MUST perform two additional checks
besides the normal steps detailed in section 5.1.1. When consulting
the SPD or the SAD to find an outbound security association, the MLS
implementation MUST use the sensitivity of the data to select an
appropriate outbound SA or SA bundle. The second check comes before
forwarding the packet out to its destination, and is the sensitivity
consistency checking described in section 8.2.

Kent, Atkinson [Page 37]

Internet Draft Security Architecture for IP November 1997

8.6 Additional MLS Processing for Security Gateways

An MLS security gateway MUST follow the previously mentioned inbound
and outbound processing rules as well as perform some additional
processing specific to the intermediate protection of packets in an
MLS environment.

A security gateway MAY act as an outbound proxy for creating SAs for
MLS systems that originate packets forwarded by the gateway. These
MLS systems may explicitly label the packets to be forwarded, or the
whole originating network may have sensitivity characteristics
associated with it. The security gateway MUST create and use
appropriate SAs for AH, ESP, or both, to protect such traffic it
forwards.

Similarly such a gateway SHOULD accept and process inbound AH and/or
ESP packets and forward appropriately, using explicit packet
labeling, or relying on the sensitivity characteristics of the
destination network.

9. Performance Issues

The use of IPsec imposes computational performance costs on the hosts
or security gateways that implement these protocols. These costs are
associated with the memory needed for IPsec code and data structures,
and the computation of integrity check values, encryption and
decryption, and added per-packet handling. The per-packet
computational costs will be manifested by increased latency and,
possibly, reduced throughout. Use of SA/key management protocols,
especially ones that employ public key cryptography, also adds
computational performance costs to use of IPsec. These per-
association computational costs will be manifested in terms of
increased latency in association establishment. For many hosts, it
is anticipated that software-based cryptography will not appreciably
reduce throughput, but hardware may be required for security gateways
(since they represent aggregation points), and for some hosts.

The use of IPsec also imposes bandwidth utilization costs on
transmission, switching, and routing components of the Internet
infrastructure, components not implementing IPsec. This is due to
the increase in the packet size resulting from the addition of AH
and/or ESP headers, AH and ESP tunneling (which adds a second IP
header), and the increased packet traffic associated with key
management protocols. It is anticipated that, in most instances,
this increased bandwidth demand will not noticeably affect the
Internet infrastructure. However, in some instances, the effects may
be significant, e.g., transmission of ESP encrypted traffic over a
dialup link that otherwise would have compressed the traffic.

Kent, Atkinson [Page 38]

Internet Draft Security Architecture for IP November 1997

Note: The initial SA establishment overhead will be felt in the first
packet. This delay could impact the transport layer and application.
For example, it could cause TCP to retransmit the SYN before the
ISAKMP exchange is done. The effect of the delay would be different
on UDP than TCP because TCP shouldn't transmit anything other than
the SYN until the connection is set up whereas UDP will go ahead and
transmit data beyond the first packet.

Note: As discussed earlier, compression can still be employed at
layers above IP. There is an IETF working group (IP Payload
Compression Protocol (ippcp)) working on "protocol specifications
that make it possible to perform lossless compression on individual
payloads before the payload is processed by a protocol that encrypts
it. These specifications will allow for compression operations to be
performed prior to the encryption of a payload by IPsec protocols."

10. Conformance Requirements

All IPv4 systems that claim to implement IPsec MUST comply with all
requirements of the Security Architecture document. All IPv6 systems
MUST comply with all requirements of the Security Architecture
document.

11. Security Considerations

The focus of this document is security; hence security considerations
permeate this specification.

12. Differences from RFC 1825

This architecture document differs substantially from RFC 1825 in
detail and in organization, but the fundamental notions are
unchanged. This document provides considerable additional detail in
terms of compliance specifications. It introduces the SPD and SAD,
and the notion of SA selectors. It is aligned with the new versions
of AH and ESP, which also differ from their predecessors. Specific
requirements for supported combinations of AH and ESP are newly
added, as are details of PMTU management.

Acknowledgements

Many of the concepts embodied in this specification were derived from
or influenced by the US Government's SP3 security protocol, ISO/IEC's
NLSP, the proposed swIPe security protocol [SDNS, ISO, IB93, IBK93],
and the work done for SNMP Security and SNMPv2 Security.

Kent, Atkinson [Page 39]

Internet Draft Security Architecture for IP November 1997

For over 2 years (although it sometimes seems *much* longer) , this
document has evolved through multiple versions and iterations.
During this time, many people have contributed significant ideas and
energy to the process and the documents themselves. The authors
would like to thank Karen Seo for providing extensive help in the
review, editing, background research, and coordination for this
version of the specification. The authors would also like to thank
the members of the IPsec and IPng working groups, with special
mention of the efforts of (in alphabetic order): Steve Bellovin,
Steve Deering, James Hughes, Phil Karn, Frank Kastenholz, Perry
Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William
Simpson, Harry Varnis, and Nina Yuan.

Kent, Atkinson [Page 40]

Internet Draft Security Architecture for IP November 1997

Appendix A -- Glossary

This section provides definitions for several key terms that are
employed in this document. Other documents provide additional
definitions and background information relevant to this technology,
e.g., [VK83, HA94]. Included in this glossary are generic security
service and security mechanism terms, plus IPsec-specific terms.

Access Control
Access control is a security service that prevents unauthorized
use of a resource, including the prevention of use of a resource
in an unauthorized manner. In the IPsec context, the resource to
which access is being controlled is often:
o for a host, computing cycles or data
o for a security gateway, a network behind the gateway or
bandwidth on that network.

Anti-replay
[See "Integrity" below]

Authentication
This term is used informally to refer to the combination of two
nominally distinct security services, data origin authentication
and connectionless integrity. See the definitions below for each
of these services.

Availability
Availability, when viewed as a security service, addresses the
security concerns engendered by attacks against networks that deny
or degrade service. For example, in the IPsec context, the use of
anti-replay mechanisms in AH and ESP support availability.

Confidentiality
Confidentiality is the security service that protects data from
unauthorized disclosure. The primary confidentiality concern in
most instances is unauthorized disclosure of application level
data, but disclosure of the external characteristics of
communication also can be a concern in some circumstances.
Traffic flow confidentiality is the service that addresses this
latter concern by concealing source and destination addresses,
message length, or frequency of communication. In the IPsec
context, using ESP in tunnel mode, especially at a security
gateway, can provide some level of traffic flow confidentiality.
(See also traffic analysis, below.)

Kent, Atkinson [Page 41]

Internet Draft Security Architecture for IP November 1997

Encryption
Encryption is a security mechanism used to transform data from an
intelligible form (plaintext) into an unintelligible form
(ciphertext), to provide confidentiality. The inverse
transformation process is designated "decryption". Oftimes the
term "encryption" is used to generically refer to both processes.

Data Origin Authentication
Data origin authentication is a security service that verifies the
identity of the claimed source of data. This service is usually
bundled with connectionless integrity service.

Integrity
Integrity is a security service that ensures that modifications to
data are detectable. Integrity comes in various flavors to match
application requirements. IPsec supports two forms of integrity:
connectionless and a form of partial sequence integrity.
Connectionless integrity is a service that detects modification of
an individual IP datagram, without regard to the ordering of the
datagram in a stream of traffic. The form of partial sequence
integrity offered in IPsec is referred to as anti-replay
integrity, and it detects arrival of duplicate IP datagrams
(within a constrained window). This is in contrast to
connection-oriented integrity, which imposes more stringent
sequencing requirements on traffic, e.g., to be able to detect
lost or re-ordered messages. Although authentication and
integrity services often are cited separately, in practice they
are intimately connected and almost always offered in tandem.

Security Association (SA)
A simplex (uni-directional) logical connection, created for
security purposes. All traffic traversing an SA is provided the
same security processing. In IPsec, an SA is an internet layer
abstraction implemented through the use of AH or ESP.

Security Gateway
A security gateway is an intermediate system that acts as the
communications interface between two networks. The set of hosts
(and networks) on the external side of the security gateway is
viewed as untrusted (or less trusted), while the networks and
hosts and on the internal side are viewed as trusted (or more
trusted). The internal subnets and hosts served by a security
gateway are presumed to be trusted by virtue of sharing a common,
local, security administration. (See "Trusted Subnetwork" below.)
In the IPsec context, a security gateway is a point at which AH
and/or ESP is implemented in order to serve a set of internal
hosts, providing security services for these hosts when they
communicate with external hosts also employing IPsec (either

Kent, Atkinson [Page 42]

Internet Draft Security Architecture for IP November 1997

directly or via another security gateway).

SPI
Acronym for "Security Parameters Index". The combination of a
destination address, a security protocol, and an SPI uniquely
identifies a security association (SA, see above). The SPI is
carried in AH and ESP protocols to enable the receiving system to
select the SA under which a received packet will be processed. An
SPI has only local significance, as defined by the creator of the
SA (usually the receiver of the packet carrying the SPI); thus an
SPI is generally viewed as an opaque bit string. However, the
creator of an SA may choose to interpret the bits in an SPI to
facilitate local processing.

Traffic Analysis
The analysis of network traffic flow for the purpose of deducing
information that is useful to an adversary. Examples of such
information are frequency of transmission, the identities of the
conversing parties, sizes of packets, flow identifiers, etc.
[Sch94]

Trusted Subnetwork
A subnetwork containing hosts and routers that trust each other
not to engage in active or passive attacks. There also is an
assumption that the underlying communications channel (e.g., a LAN
or CAN) isn't being attacked by other means.

Kent, Atkinson [Page 43]

Internet Draft Security Architecture for IP November 1997

Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues

B.1 DF bit

In cases where a system (host or gateway) adds an encapsulating
header (e.g., ESP tunnel), should/must the DF bit in the original
packet be copied to the encapsulating header?

Fragmenting seems correct for some situations, e.g., it might be
appropriate to fragment packets over a network with a very small MTU,
e.g., a packet radio network, or a cellular phone hop to mobile node,
rather than propagate back a very small PMTU for use over the rest of
the path. In other situations, it might be appropriate to set the DF
bit in order to get feedback from later routers about PMTU
constraints which require fragmentation. The existence of both of
these situations argues for enabling a system to decide whether or
not to fragment over a particular network "link", i.e., for requiring
an implementation to be able to copy the DF bit (and to process ICMP
PMTU messages), but making it an option to be selected on a per
interface basis. In other words, an administrator should be able to
configure the router's treatment of the DF bit (set, clear, copy from
encapsulated header) for each interface.

Note: If a bump-in-the-stack implementation of IPsec attempts to
apply different IPsec algorithms based on source/destination ports,
it will be difficult to apply Path MTU adjustments.

B.2 Fragmentation

Fragmentation MUST be done after outbound IPsec processing.
Reassembly MUST be done before inbound IPsec processing. The general
reasoning is shown below (delimited by the ****'s).

NOTE: IPsec always has to figure out what the encapsulating IP header
fields are. This is independent of where you insert IPsec and is
intrinsic to the definition of IPsec. Therefore any IPsec
implementation that is not integrated into an IP implementation must
include code to construct the necessary IP headers (e.g., IP2):

o AH-tunnel --> IP2-AH-IP1-Transport-Data
o ESP-tunnel --> IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer

**********************************************************************

Overall, the fragmentation/reassembly approach described above works
for all cases examined.

Kent, Atkinson [Page 44]

Internet Draft Security Architecture for IP November 1997

AH Xport AH Tunnel ESP Xport ESP Tunnel
Implementation approach IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 IPv6
----------------------- ---- ---- ---- ---- ---- ---- ---- ----
Hosts (integr w/ IP stack) Y Y Y Y Y Y Y Y
Hosts (betw/ IP and drivers) Y Y Y Y Y Y Y Y
S. Gwy (integr w/ IP stack) Y Y Y Y
Outboard crypto processor *

* If the crypto processor system has its own IP address, then it
is covered by the security gateway case. This box receives
the packet from the host and performs IPsec processing. It
has to be able to provide Authentication,
Integrity, handle the same AH, ESP, and related
IPv4/IPv6 tunnel processing that a security gateway would have
to handle. If it doesn't have it's own address, then it is
similar to the bump-in-the stack implementation between IP and
the network drivers.

The following analysis assumes that:

1. There is only one IPsec module in a given system's stack.
There isn't an IPsec module A (adding ESP/encryption and
thus) hiding the transport protocol, SRC port, and DEST port
from IPsec module B.
2. There are several places where IPsec could be implemented
(as shown in the table above).
a. Hosts with integration of IPsec into the native IP
implementation. Implementer has access to the source
for the stack.
b. Hosts with bump-in-the-stack implementations, where
IPsec is implemented between IP and the local network
drivers. Source access for stack is not available;
but there are well-defined interfaces that allows the
IPsec code to be incorporated into the system.
c. Security gateways and Confidentiality for applications operating on
connected end systems when appropriate algorithms outboard crypto processors with
integration of IPsec into the stack.
3. Not all of the above approaches are feasible in use.
Integrity all hosts.
But it was assumed that for each approach, there are some
hosts for whom the approach is feasible.

For each of the above 3 categories, there are IPv4 and Confidentiality can be provided by host-oriented keying
when appropriate dynamic key management techniques IPv6, AH
transport and appropriate
algorithms tunnel modes, and ESP transport and tunnel modes -- for
a total of 24 cases (3 x 2 x 4).

Some header fields and interface fields are listed here for ease of
reference -- they're not in use. However, the header order, but instead listed to
allow comparison between the columns. (* = not covered by AH
authentication. ESP authentication of principals using
applications on end-systems requires doesn't cover any headers that processes running
applications be able to request and use their own
precede it.)

Kent, Atkinson [Page 45]

Internet Draft Security
Associations. Architecture for IP November 1997

IP/Transport Interface
IPv4 IPv6 (RFC 1122 -- Sec 3.4)
---- ---- ----------------------
Version = 4 Version = 6
Header Len
*TOS Class,Flow Lbl TOS
Packet Len Payload Len Len
ID ID (optional)
*Flags DF
*Offset
*TTL *Hop Limit TTL
Protocol Next Header
*Checksum
Src Address Src Address Src Address
Dst Address Dst Address Dst Address
Options? Options? Opt

? = AH covers Option-Type and Option-Length, but
might not cover Option-Data.

The results for each of the 24 cases is shown below ("works" = will
work if system fragments after outbound IPsec processing, reassembles
before inbound IPsec processing). Notes indicate implementation
issues.

a. Hosts (integrated into IP stack)
o AH-transport --> (IP1-AH-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works
o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works

b. Hosts (Bump-in-the-stack) -- put IPsec between IP layer and
network drivers. In this manner, applications can make use case, the IPsec module would have to
do something like one of key
distribution facilities that provide authentication.

Hence, support the following for session-unique keying MUST be present in all
IP Security implementations, as fragmentation and
reassembly.
- do the fragmentation/reassembly work itself and
send/receive the packet directly to/from the network
layer. In AH or ESP transport mode, this is described in fine. In AH
or ESP tunnel mode where the "IPsec Key
Management Requirements" section below. Support for other styles MAY
also be implemented.

4.5 Multicast Key Distribution

Multicast key distribution tunnel is an active research area in to the
published literature as of ultimate
destination, this writing. For multicast groups having
relatively few members, manual key distribution is fine. But in AH or multiple use of
existing unicast key distribution algorithms such as modified Diffie-
Hellman appears feasible. For very large groups, new scalable
techniques will be needed. In-line key management systems that rely ESP tunnel modes

Kent, Atkinson [Page 15] 46]

Internet Draft Security Architecture for IP 10 November 1996

on pre-distributed master keys 1997

where the tunnel end is different from the ultimate
destination and then have serious scaling issues
that make them questionable for multicast traffic.

4.6 where the source host is multi-homed, this
approach could result in sub-optimal routing because the
IPsec Key Management Requirements

This section defines key management requirements for all IPv6
implementations and for those IPv4 implementations that implement module may be unable to obtain the
IP Authentication Header, information
needed (LAN interface and next-hop gateway) to direct the IP Encapsulating Security Payload, or
both. It applies equally
packet to the IP Authentication Header appropriate network interface. This is not
a problem if the interface and next-hop gateway are the IP
Encapsulating Security Payload.

All such implementations MUST support manual configuration of
Security Associations, including all of
same for the attributes described in ultimate destination and for the Security Association definition section of this document, having
variable SPI values within tunnel end.
But if they are different, then IPsec would need to know
the non-reserved range. An implementation
that only supports a fixed SPI value is NOT conforming or compliant.

All IPv6 IP Security implementations MUST implement
ISAKMP/Oakley. All IPv4 IP Security implementations SHOULD implement
ISAKMP/Oakley. Other key management protocols MAY also LAN interface and the next-hop gateway for the tunnel
end. (Note: The tunnel end (security gateway) is highly
likely to be
implemented. [Sch96]

Implementations MAY on the regular path to the ultimate
destination. But there could also support other methods of configuring
Security Associations.

Given two endpoints, it MUST be possible to have more than one
concurrent Security Association for communications between them.
Implementations on multi-user hosts having path
to the destination, e.g., the host could be at least discretionary
access controls MUST support either user granularity (i.e. "user-
oriented") Security Associations or session-unique Security
Associations.

All such implementations MUST permit an
organization with 2 firewalls. And the path being used
could involve the less commonly chosen firewall.)
OR
- pass the IPsec'd packet back to the configuration of host-
oriented keying.

A device that encrypts or authenticates IP packets originated by
other systems, for example layer where an
extra IP header would end up being pre-pended and the
IPsec module would have to check and let IPsec'd fragments
go by.
OR
- pass the packet contents to the IP layer in a dedicated form such
that the IP encryptor or layer recreates an security
gateway, cannot generally provide user-oriented keying for traffic
originating on other systems. Such systems MUST support session-
unique key selection based on source appropriate IP header

At the network layer, the IPsec module will have access to the
following selectors from the packet -- SRC address, destination DST address,
upper-layer protocol, source port (if any),
TOS, Next Protocol, and destination port (if
any). Such systems MAY additionally implement support for user-
oriented keying for traffic originating on other systems.

The method by which keys are configured on if there's a particular system
is implementation-defined. A flat file containing security
association identifiers transport layer header -->
SRC port and DST port. One cannot assume IPsec has access to the
User ID. It is assumed that the available selector information
is sufficient to figure out the relevant Security Association(s).

o AH-transport --> (IP1-AH-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works
o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works

c. Security gateways -- integrate IPsec into the security parameters, including IP stack

NOTE: The IPsec module will have access to the
key(s), is an example of one possible method for manual key following

Kent, Atkinson [Page 16] 47]

Internet Draft Security Architecture for IP 10 November 1996

distribution. An IP 1997

selectors from the packet -- SRC address, DST address, TOS/Class,
Next Protocol, and if there's a transport layer header --> SRC
port and DST port. It won't have access to the User ID (only
Hosts have access to User ID information.) It also won't have
access to the transport layer information if there is an ESP
header, or if it's not the first fragment of a fragmented
message. It is assumed that the available selector information
is sufficient to figure out the relevant Security implementation MUST take reasonable
steps Association(s).

o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works

**********************************************************************

B.3 Path MTU Discovery

As mentioned earlier, "ICMP PMTU" refers to protect an ICMP message used for
Path MTU Discovery.

The legend for the keys diagrams below in B.3.1 and other B.3.3 (but not B.3.2)
is:

==== = security association information
from unauthorised examination (AH or modification because all ESP, transport or tunnel)
---- = connectivity (or if so labelled, administrative boundary)
.... = ICMP message (hereafter referred to as ICMP PMTU) for

IPv4:
- Type = 3 (Destination Unreachable)
- Code = 4 (Fragmentation needed and DF set)
- Next-Hop MTU in the low-order 16 bits of the
security lies in second
word of the keys.

5. USAGE

This section describes ICMP header (labelled unused in RFC 792),
with high-order 16 bits set to zero

IPv6 (RFC 1885):
- Type = 2 (Packet Too Big)
- Code = 0 (Fragmentation needed and DF set)
- Next-Hop MTU in the possible use 32 bit MTU field of the ICMP6

Hx = host x
Rx = router x
SGx = security
mechanisms provided by gateway x
X* = X supports IPsec

Kent, Atkinson [Page 48]

Internet Draft Security Architecture for IP in several different environments November 1997

B.3.1 Identifying the Originating Host(s)

The amount of information returned with the ICMP message is limited
and
applications in order this affects what selectors are available to give identify security
associations, originating hosts, etc. for use in further propagating
the implementer and user PMTU information.

In brief... An ICMP message must contain the following information
from the "offending" packet:
- IPv4 (RFC 792) -- IP header plus a better idea minimum of how these mechanisms can be used to reduce security risks.

5.1 USE WITH FIREWALLS

Firewalls are not uncommon 64 bits
- IPv6 (RFC 1885) -- IP header plus a minimum of 576 bytes

Accordingly, in the current Internet. [CB94]
While many dislike their presence IPv4 context, an ICMP PMTU may identify only the
first (outermost) security association. This is because they restrict connectivity,
they are unlikely to disappear in the near future. Both ICMP
PMTU may contain only 64 bits of these IP
mechanisms can be used to increase the security provided by
firewalls.

Firewalls used with IP often need to be able to parse "offending" packet beyond the
headers and options to determine IP
header, which would capture only the transport protocol (e.g. UDP first SPI from AH or
TCP) in use and ESP. In
the port number for that protocol. Firewalls can be
used with IPv6 context, an ICMP PMTU will probably provide all the Authentication Header regardless of whether that
firewall is party to SPIs and
the appropriate Security Assocation. However, a
firewall that is not party to selectors in the applicable Security Association
will IP header, but maybe not normally be able to decrypt an encrypted upper-layer
protocol to view the protocol or port number needed to perform per-
packet filtering.

Further, firewalls need to verify that SRC/DST ports (in
the data (e.g. source,
destination, transport protocol, port number) being used for access
control decisions header) or the encapsulated (TCP, UDP, etc.) protocol.
Moreover, if ESP is correct used, the transport ports and authentic. Hence, authentication
might protocol selectors
may be performed not only within an organisation or campus but also
end to end with remote systems across encrypted.

Looking at the Internet. This use diagram below of the
Authentication Header with IP provides much more assurance a security gateway tunnel (as
mentioned elsewhere, security gateways do not use transport mode)...

H1 =================== H3
\ | | /
H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5
/ ^ | \
H2 |........| H4

Suppose that the
data being used security policy for access control decisions SG1 is authentic.

Organisations with two or more sites that are interconnected
using commercial IP service might wish to use a selectively
encrypting firewall. If an encrypting firewall were placed between
each site of a company and the commercial IP service provider, the
firewall could provide an encrypted IP tunnel among single SA to SG2
for all the company's
sites. It could also encrypt the traffic between the company hosts H0, H1, and its
suppliers, customers, H2 and other affiliates. Traffic with hosts H3, H4,
and H5. And suppose H0 sends a data packet to H5 which causes R1 to
send an ICMP PMTU message to SG1. If the Network
Information Center, with public Internet archives, or some other
organisations might not PMTU message has only the
SPI, SG1 will be encrypted because of able to look up the SA and find the unavailability list of
a standard key management protocol or as a deliberate choice possible
hosts (H0, H1, H2, wildcard); but SG1 will have no way to figure out
that H0 sent the traffic that triggered the ICMP PMTU message.

Kent, Atkinson [Page 17] 49]

Internet Draft Security Architecture for IP 10 November 1996

facilitate better communications, improved network performance, and
increased connectivity. Such a practice could easily protect 1997

original after IPsec ICMP
packet processing packet
-------- ----------- ------
IP-3 header (S = R1, D = SG1)
ICMP header (includes PMTU)
IP-2 header IP-2 header (S = SG1, D = SG2)
ESP header minimum of 64 bits of ESP hdr (*)
IP-1 header IP-1 header
TCP header TCP header
TCP data TCP data
ESP trailer

(*) The 64 bits will include enough of the
company's sensitive traffic from eavesdropping and modification.

Some organisations (e.g. governments) might wish ESP (or AH) header to use
include the SPI.
- ESP -- SPI (32 bits), Seq number (32 bits)
- AH -- Next header (8 bits), Payload Len (8 bits),
Reserved (16 bits), SPI (32 bits)

This limitation on the amount of information returned with an ICMP
message creates a fully
encrypting firewall problem in identifying the originating hosts for
the packet (so as to know where to further propagate the ICMP PMTU
information). If the ICMP message contains only 64 bits of the IPsec
header (minimum for IPv4), then the IPsec selectors (e.g., Source and
Destination addresses, Next Protocol, Source and Destination ports,
etc.) will have been lost. But the ICMP error message will still
provide a Virtual Private Network (VPN) over
commercial IP service. SG1 with the SPI, the PMTU information and the source and
destination gateways for the relevant security association.

The difference between that destination security gateway and SPI uniquely define a bulk IP
encryption device security
association which in turn defines a set of possible originating
hosts. At this point, SG1 could:

a. send the PMTU information to all the possible originating hosts.
This would not work well if the host list is that a fully encrypting firewall would provide
filtering wild card or if
many/most of the decrypted traffic as well as providing encryption of
IP packets. A related scenario is hosts weren't sending to use encryption between a mobile
computer and SG1; but it might work
if the security gateway SPI/destination/etc mapped to just one or encrypting firewall a small number of its home
campus.

5.2 USE WITH IP MULTICAST

In the past several years,
hosts.
b. store the Multicast Backbone (MBONE) has
grown rapidly. IETF meetings and other conferences are now regularly
multicast PMTU with real-time audio, video, the SPI/etc and whiteboards. Many people
are now using teleconferencing applications based on IP Multicast in wait until the Internet or in private internal networks. Others are using IP
multicasting to support distributed simulation or other applications.
Hence it is important that next packet(s)
arrive from the security mechanisms in IP be suitable originating host(s) for use in an environment where multicast is the general case.

The Security Parameters Indexes (SPIs) used in the IP relevant security
mechanisms
association. If it/they are receiver-oriented, making them well suited for use in
IP multicast. [Atk95a, Atk95b] Unfortunately, most currently
published multicast key distribution protocols do not scale well.
However, there is active research in this area. As an interim step,
a multicast group could repeatedly use a secure unicast key
distribution protocol to distribute bigger than the key to all members or PMTU, drop the
group could pre-arrange keys using manual key distribution.

5.3 USE TO PROVIDE QOS PROTECTION

The recent IAB Security Workshop identified Quality of Service
protection as an area of significant interest. [BCCH] The two IP
security mechanisms are intended to provide good support for real-
time services as well as multicasting. This section describes one
possible approach to providing such protection.

The Authentication Header might be used,
packet(s), and compose ICMP PMTU message(s) with appropriate key
management, to provide authentication of packets. the new
packet(s) and the updated PMTU, and send the originating host(s)
the ICMP message(s) about the problem. This
authentication is potentially important in packet classification
within routers. The IPv6 Flow Identifier might act as involves a Low-Level
Identifier (LLID). Used together, packet classification within
routers becomes straightforward if the router is provided with delay in
notifying the
appropriate keying material. For performance reasons originating host(s), but avoids the routers problems of (a).

Since only the latter approach is feasible in all instances, a
security gateway MUST provide such support, as an option. However,

Kent, Atkinson [Page 18] 50]

Internet Draft Security Architecture for IP 10 November 1996

might authenticate only every Nth packet rather than every packet,
but this is still a significant improvement over capabilities in 1997

if the
current Internet. Quality of service provisioning is likely to also
use ICMP message contains more information from the Flow ID in conjunction with a resource reservation protocol,
such as RSVP. [ZDESZ93] Thus, original
packet, e.g., the authenticated packet classification
can 576 byte minimum for IPv6, then there MAY be used to help ensure that each packet receives appropriate
handling inside routers.

5.4 USE IN COMPARTMENTED OR MULTI-LEVEL NETWORKS

A multi-level secure (MLS) network is one where a single network
is used enough
information to communicate data at different sensitivity levels (e.g.
Unclassified and Secret). [DoD85] [DoD87] Many governments have
significant interest in MLS networking. [DIA] The IP security
mechanisms have been designed immediately determine to support MLS networking. MLS
networking requires the use of strong Mandatory Access Controls
(MAC), which ordinary users are incapable of controlling or
violating. [BL73] This section pertains only host to propagate the use of these IP
security mechanisms in MLS environments.

The Authentication Header can be used to provide strong
authentication among hosts in a single-level network. The
Authentication Header can also be used
ICMP/PMTU message and to provide strong assurance
for both mandatory access control decisions in multi-level networks that system with the 5 fields
(source address, destination address, source port, destination port,
and discretionary access control decisions in all kinds transport protocol) needed to determine where to store/update the
PMTU. Under such circumstances, a security gateway MUST generate an
ICMP PMTU message immediately upon receipt of networks.
If explicit IP sensitivity labels (e.g. IPSO) [Ken91] are used and
confidentiality is not considered necessary within an ICMP PMTU from
further down the particular
operational environment, path. NOTE: The Next Protocol field MAY not be
contained in the Authentication Header is used to provide
authentication for 576 bytes and the entire packet, including cryptographic binding use of ESP encryption MAY hide the sensitivity level
selector fields that have been encrypted.

B.3.2 Calculation of PMTU

The calculation of PMTU from an ICMP PMTU has to take into account
the IP addition of any IPsec header by H1 -- AH and/or ESP transport, or
ESP or AH tunnel. Within a single host, multiple applications may
share an SPI and user data. This is nesting of security associations may occur. The
diagram below illustrates several possible combinations of security
associations between a
significant improvement over labeled IPv4 networks where pair of hosts (as viewed from the label is
trusted even though it is not trustworthy because there is no
authentication or cryptographic binding perspective
of one of the label hosts.) (ESPt or AHt = tunnel mode; ESPx or AHx =
transport mode)

Socket 1 ----------------------------------------------- I
| n
Socket 2 (ESPt/SPI-A) ------------------------------- | t
| | e
Socket 3 (AHx/SPI-B, ESPt/SPI-C) --- AHx (SPI-D) --- ESPt (SPI-E)--r
| n
Socket 4 (ESPx/SPI-F, ESPt/SPI-G) -- ESPx (SPI-H) --- e
t

In order to figure out the IP header
and user data. IPv6 will normally use implicit sensitivity labels
that are part of the Security Association but not transmitted with PMTU for each packet instead of using explicit sensitivity labels. All
explicit IP sensitivity labels MUST be authenticated using either
ESP, AH, or both.

The Encapsulating Security Payload can socket that maps to SPI-E,
it will be combined with
appropriate key policies necessary to have backpointers from SPI-E to provide full multi-level secure
networking. In this case each key must be used only at a single
sensitivity level and compartment. For example, Key "A" might be
used only for sensitive Unclassified packets, while Key "B" is used
only for Secret/No-compartments traffic, and Key "C" is used only for
Secret/Compartment-X traffic. The sensitivity level of the protected
traffic MUST NOT dominate the sensitivity level
four paths that lead to it -- Socket 1, SPI-A, SPI-D, and SPI-H.

B.3.3 Granularity of Maintaining PMTU Data

In hosts, the granularity with which PMTU ICMP processing can be done
differs depending on the Security
Association used with implementation situation. Looking at a
host, there are three situations that traffic. The sensitivity level are of the interest with respect to
PMTU issues:

Kent, Atkinson [Page 19] 51]

Internet Draft Security Architecture for IP 10 November 1996

Security Association MUST NOT dominate 1997

a. Integration of IPsec into the sensitivity level native IP implementation
b. Bump-in-the-stack implementations, where IPsec is implemented
"underneath" an existing implementation of a TCP/IP protocol
stack, between the
key that belongs native IP and the local network drivers
c. No IPsec implementation -- This case is included because it is
relevant in cases where a security gateway is sending PMTU
information back to that Security Association. The sensitivity level
of a host.

Only in case (a) can the key SHOULD PMTU data be maintained at the same
granularity as communication associations. In the sensitivity level of the
Security Association. The Authentication Header can also have
different keys for the same reasons, with other cases, the choice of key depending
in part on
IP layer will maintain PMTU data at the sensitivity level granularity of the packet.

Encryption is very useful Source and desirable even when all of the
hosts are within a protected environment. The Internet-standard
encryption algorithm could be used, in conjunction with appropriate
key management, to provide strong Discretionary Access Controls (DAC)
in conjunction with either implicit sensitivity labels or explicit
sensitivity labels (such
Destination IP addresses (and optionally TOS/Class), as IPSO provides for IPv4 [Ken91]). Some
environments might consider the Internet-standard encryption
algorithm sufficiently strong to provide Mandatory Access Controls
(MAC). Full encryption should be used for all communications between
multi-level computers or compartmented mode workstations even when
the computing environment is considered to be protected.

6. SECURITY CONSIDERATIONS described in
RFC 1191. This entire draft discusses the Security Architecture for the
Internet Protocol. It is not a general security architecture for the
Internet, but is instead focused on an important difference, because more than one
communication association may map to the same source and destination
IP layer.

Cryptographic transforms for ESP which use a block-chaining
algorithm addresses, and lack each communication association may have a strong integrity mechanism are vulnerable different
amount of IPsec header overhead (e.g., due to a
cut-and-paste attack described by Bellovin use of different
transforms or different algorithms). The examples below illustrate
this.

In cases (a) and should not be used
unless (b)... Suppose you have the Authentication Header following situation.
H1 is always present with packets using
that ESP transform. [Bel95]

If more than one sender shares a Security Association with a
destination, then the receiving system can only authenticate that sending to H2 and the packet was to be sent from one of those systems and cannot authenticate
which R1 to R2 exceeds
the PMTU of those systems sent it. Similarly, if the receiving system
does network hop between them.

==================================
| |
H1* --- R1 ----- R2 ---- R3 ---- H2*
^ |
|.......|

If R1 is configured to not check that fragment subscriber traffic, then R1 sends
an ICMP PMTU message with the Security Association used for a packet is
valid for appropriate PMTU to H1. H1's
processing would vary with the claimed Source Address nature of the packet, then implementation. In case
(a) (native IP), the
receiving system cannot authenticate whether security services are bound to sockets or the packet's claimed
equivalent. Here the IP/IPsec implementation in H1 can store/update
the PMTU for the associated socket. In case (b), the IP layer in H1
can store/update the PMTU but only at the granularity of Source Address is valid. For example, if senders "A" and "B" each
have their own unique Security Association with destination "D"
Destination addresses and
"B" uses its valid Security Association with D but forges possibly TOS/Class, as noted above. So the
result may be sub-optimal, since the PMTU for a Source
Address of "A", then "D" given
SRC/DST/TOS/Class will be fooled into believing the packet
came from "A" unless "D" verifies that subtraction of the claimed Source Address is
party largest amount of
IPsec header used for any communication association between a given
source and destination.

In case (c), there has to the Security Association that was used.

Users need be a security gateway to understand that the quality of have any IPsec
processing. So suppose you have the security
provided by following situation. H1 is
sending to H2 and the mechanisms provided by these two IP security
mechanisms depends completely on packet to be sent from SG1 to R exceeds the strength
PMTU of the implemented network hop between them.

Kent, Atkinson [Page 20] 52]

Internet Draft Security Architecture for IP 10 November 1996

cryptographic algorithms, 1997

================
| |
H1 ---- SG1* --- R --- SG2* ---- H2
^ |
|.......|

As described above for case (b), the strength of IP layer in H1 can store/update
the key being used, PMTU but only at the
correct implementation granularity of Source and Destination
addresses, and possibly TOS/Class. So the cryptographic algorithms, result may be sub-optimal,
since the security PMTU for a given SRC/DST/TOS/Class will be the subtraction
of the key management protocol, largest amount of IPsec header used for any communication
association between a given source and destination.

B.3.4 Per Socket Maintenance of PMTU Data

Implementation of the correct implementation calculation of IP PMTU (Section B.2.2) and support
for PMTUs at the several security mechanisms in all granularity of the participating
systems. The security individual "communication
associations" (Section B.2.3) is a local matter. However, a socket-
based implementation of IPsec in a host SHOULD maintain the implementation is
information on a per socket basis. Bump in part related the stack systems MUST
pass an ICMP PMTU to the security host IP implementation, after adjusting it
for any IPsec header overhead added by these systems. The
determination of the operating system which embodies overhead SHOULD be determined by analysis of the security
implementations. For example, if
SPI and any other selector information present in a returned ICMP
PMTU message.

B.3.5 Delivery of PMTU Data to the operating system does not keep Transport Layer

The host mechanism for getting the private cryptologic keys (that is, all symmetric keys and updated PMTU to the
private asymmetric keys) confidential, then traffic using those keys
will not be secure. If any transport
layer is unchanged, as specified in RFC 1191 (Path MTU Discovery).

B.3.6 Aging of these PMTU Data

This topic is incorrect or insufficiently
secure, little or no real security will be covered in Section 6.1.2.4.

Kent, Atkinson [Page 53]

Internet Draft Security Architecture for IP November 1997

Appendix C -- Sequence Space Window Code Example

This appendix contains a routine that implements a bitmask check for
a 32 packet window. It was provided to by James Hughes
(jim_hughes@stortek.com) and Harry Varnis (hgv@anubis.network.com)
and is intended as an implementation example. Note that this code
both checks for a replay and updates the user.
Because different users on window. Thus the same system might not trust each
other, each user or each session algorithm,
as shown, should usually only be keyed separately.
This will also tend called AFTER the packet has been
authenticated. Implementers might wish to increase consider splitting the work required
code to cryptanalyse do the
traffic since not all traffic will use check for replays before computing the same key.

Certain security properties (e.g. traffic analysis protection)
are ICV. If the
packet is not provided by a replay, the code would then compute the ICV, (discard
any of these mechanisms. One possible approach
to traffic analysis protection bad packets), and if the packet is appropriate use of link encryption.
[VK83] Users OK, update the window.

#include <stdio.h>
#include <stdlib.h>
typedef unsigned long u_long;

enum {
ReplayWindowSize = 32
};

u_long bitmap = 0; /* session state - must carefully consider which security properties they
require and take active steps to ensure that their needs are met by
these be 32 bits */
u_long lastSeq = 0; /* session state */

/* Returns 0 if packet disallowed, 1 if packet permitted */
int ChkReplayWindow(u_long seq);

int ChkReplayWindow(u_long seq) {
u_long diff;

if (seq == 0) return 0; /* first == 0 or other mechanisms.

Certain applications (e.g. electronic mail) probably need to
have application-specific security mechanisms. Application-specific
security mechanisms are wrapped */
if (seq > lastSeq) { /* new larger sequence number */
diff = seq - lastSeq;
if (diff < ReplayWindowSize) { /* In window */
bitmap <<= diff;
bitmap |= 1; /* set bit for this packet */
} else bitmap = 1; /* This packet has a "way larger" */
lastSeq = seq;
return 1; /* larger is good */
}
diff = lastSeq - seq;
if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */
if (bitmap & (1 << diff)) return 0; /* this packet already seen */
bitmap |= (1 << diff); /* mark as seen */
return 1; /* out of the scope of this document. Users
interested order but good */
}

char string_buffer[512];

Kent, Atkinson [Page 54]

Internet Draft Security Architecture for IP November 1997

#define STRING_BUFFER_SIZE sizeof(string_buffer)

int main() {
int result;
u_long last, current, bits;

printf("Input initial state (bits in electronic mail security should consult the RFCs
describing the Internet's Privacy-Enhanced Mail system. Users
concerned about other application-specific mechanisms should consult
the online RFCs hex, last msgnum):\n");
if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0);
sscanf(string_buffer, "%lx %lu", &bits, &last);
if (last != 0)
bits |= 1;
bitmap = bits;
lastSeq = last;
printf("bits:%08lx last:%lu\n", bitmap, lastSeq);
printf("Input value to see test (current):\n");

while (1) {
if suitable (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break;
sscanf(string_buffer, "%lu", &current);
result = ChkReplayWindow(current);
printf("%-3s", result ? "OK" : "BAD");
printf(" bits:%08lx last:%lu\n", bitmap, lastSeq);
}
return 0;
}

Kent, Atkinson [Page 55]

Internet Standard mechanisms
exist.

ACKNOWLEDGEMENTS

Steve Kent provided detailed and helpful editorial input into
this draft. His contributions improved the draft significantly.

Many Draft Security Architecture for IP November 1997

Appendix D -- Categorization of ICMP messages

The tables below characterize ICMP messages as being either host
generated, router generated, both, unassigned/unknown. The first set
are IPv4. The second set are IPv6.

[Please let us know if any of these should re-categorized.]

IPv4

Type Name/Codes Reference
=========================================================================
HOST GENERATED:
3 Destination Unreachable
2 Protocol Unreachable [RFC792]
3 Port Unreachable [RFC792]
8 Source Host Isolated [RFC792]
14 Host Precedence Violation [RFC1812]
10 Router Selection [RFC1256]

Type Name/Codes Reference
=========================================================================
ROUTER GENERATED:
3 Destination Unreachable
0 Net Unreachable [RFC792]
4 Fragmentation Needed, Don't Fragment was Set [RFC792]
5 Source Route Failed [RFC792]
6 Destination Network Unknown [RFC792]
7 Destination Host Unknown [RFC792]
9 Comm. w/Dest. Net. is Administratively Prohibited [RFC792]
11 Destination Network Unreachable for Type of Service [RFC792]
5 Redirect
0 Redirect Datagram for the concepts here are derived from or were influenced by
the US Government's SDNS security protocol specifications, Network (or subnet) [RFC792]
2 Redirect Datagram for the
ISO/IEC's NLSP specification, or from Type of Service & Network [RFC792]
9 Router Advertisement [RFC1256]
18 Address Mask Reply [RFC950]

Kent, Atkinson [Page 56]

Internet Draft Security Architecture for IP November 1997

IPv4
Type Name/Codes Reference
=========================================================================
BOTH ROUTER AND HOST GENERATED:
0 Echo Reply [RFC792]
3 Destination Unreachable
1 Host Unreachable [RFC792]
10 Comm. w/Dest. Host is Administratively Prohibited [RFC792]
12 Destination Host Unreachable for Type of Service [RFC792]
13 Communication Administratively Prohibited [RFC1812]
15 Precedence cutoff in effect [RFC1812]
4 Source Quench [RFC792]
5 Redirect
1 Redirect Datagram for the proposed swIPe security
protocol. [SDNS, ISO, IB93, IBK93] The work done Host [RFC792]
3 Redirect Datagram for SNMP Security
and SNMPv2 Security influenced the choice Type of default cryptological
algorithms Service and modes. [GM93] Steve Bellovin, Steve Deering, Phil
Karn, Frank Kastenholz, Steve Host [RFC792]
6 Alternate Host Address [JBP]
8 Echo [RFC792]
11 Time Exceeded [RFC792]
12 Parameter Problem [RFC792,RFC1108]
13 Timestamp [RFC792]
14 Timestamp Reply [RFC792]
15 Information Request [RFC792]
16 Information Reply [RFC792]
17 Address Mask Request [RFC950]
30 Traceroute [RFC1393]
31 Datagram Conversion Error [RFC1475]
32 Mobile Host Redirect [Johnson]
39 SKIP [Markson]
40 Photuris [Simpson]

Type Name/Codes Reference
=========================================================================
UNASSIGNED TYPE OR UNKNOWN GENERATOR:
1 Unassigned [JBP]
2 Unassigned [JBP]
7 Unassigned [JBP]
19 Reserved (for Security) [Solo]
20-29 Reserved (for Robustness Experiment) [ZSu]
33 IPv6 Where-Are-You [Simpson]
34 IPv6 I-Am-Here [Simpson]
35 Mobile Registration Request [Simpson]
36 Mobile Registration Reply [Simpson]
37 Domain Name Request [Simpson]
38 Domain Name Reply [Simpson]
41-255 Reserved [JBP]

Kent, Perry Metzger, Dave Mihelcic,
Hilarie Orman and Bill Simpson provided careful critiques of earlier
versions of this draft. Atkinson [Page 21] 57]

Internet Draft Security Architecture for IP 10 November 1996

REFERENCES

[Atk96a] Randall Atkinson, IP Authentication Header, RFC-xxxx, 1997

IPv6

Type Name/Codes Reference
=========================================================================
HOST GENERATED:
1 Destination Unreachable [RFC 1885]
4 June 1996.

[Atk96b] Randall Atkinson, IP Encapsulating Security Payload, RFC-xxxx, Port Unreachable

Type Name/Codes Reference
=========================================================================
ROUTER GENERATED:
1 Destination Unreachable [RFC1885]
0 No Route to Destination
1 Comm. w/Destination is Administratively Prohibited
2 Not a Neighbor
3 Address Unreachable
2 Packet Too Big [RFC1885]
0
3 Time Exceeded [RFC1885]
0 Hop Limit Exceeded in Transit
1 Fragment reassembly time exceeded

Type Name/Codes Reference
=========================================================================
BOTH ROUTER AND HOST GENERATED:
4 June 1996. Parameter Problem [RFC1885]
0 Erroneous Header Field Encountered
1 Unrecognized Next Header Type Encountered
2 Unrecognized IPv6 Option Encountered

Kent, Atkinson [Page 58]

Internet Draft Security Architecture for IP November 1997

References

[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, June 1994.

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

[Bel95] Steven M. Bellovin, Presentation at IP Security Working
Group Meeting, Proceedings of the 32nd Internet Engineering
Task Force, March 1995, Internet Engineering Task Force,
Danvers, MA.

[Bel96] Steven M. Bellovin, "Problem Areas for the IP Security
Protocols", Proceedings of the Sixth Usenix Unix Security
Symposium, July, 1996.

[BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems:
Mathematical Foundations and Model", Technical Report M74-244, M74-
244, The MITRE Corporation, Bedford, MA, May 1973.

[CERT95] CA-95:01

[CB94] William R. Cheswick & Steven M. Bellovin, Firewalls &
Internet Security, Addison-Wesley, Reading, MA, 1994.

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

[DIA] US Defense Intelligence Agency, "Compartmented Mode
Workstation Specification", Technical Report DDS-2600-6243-87. DDS-2600-
6243-87.

[DoD85] US National Computer Security Center, "Department of
Defense Trusted Computer System Evaluation Criteria", DoD
5200.28-STD, US Department of Defense, Ft. Meade, MD.,
December 1985.

[DoD87] US National Computer Security Center, "Trusted Network
Interpretation of the Trusted Computer System Evaluation
Criteria", NCSC-TG-005, Version 1, US Department of
Defense, Ft. Meade, MD., 31 July 1987.

[DH76] W. Diffie & M. Hellman, "New Directions in Cryptography",
IEEE Transactions on Information Theory, Vol. IT-22, No. 6,
November 1976, pp. 644-654.

Kent, Atkinson [Page 59]

Internet Draft Security Architecture for IP November 1997

[DH95] Steve Deering & Bob Hinden, Internet Protocol version 6
(IPv6)

Atkinson [Page 22]

Internet Draft Security Architecture for IP 10 November 1996 Specification, RFC-1883, December 1995.

[EK96] D. Eastlake III & C. Kaufman, "Domain Name System Protocol
Security Extensions", Internet Draft, 30 January 1996.

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

[HA94] N. Haller & R. Atkinson, "On Internet Authentication",
RFC-1704, DDN Network Information Center, October 1994.

[HC97] D. Harkins & D. Carrel, "The resolution of ISAKMP with
Oakley", Internet Draft, February 1997.

[HM97] H. Harney, C. Muckenhirn, "Group Key Management Protocol
(GKMP) Architecture", RFC 2094, July 1997.

[Hugh96] J. Hughes (Editor), "Combined DES-CBC, HMAC, and Replay
Prevention Security Transform", Internet Draft, June 1996.

[ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
DIS 11577, International Standards Organisation, Geneva,
Switzerland, 29 November 1992.

[IB93] John Ioannidis and Matt Blaze, "Architecture and
Implementation of Network-layer Security Under Unix",
Proceedings of USENIX Security Symposium, Santa Clara, CA,
October 1993.

[IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer Network-
Layer Security for IP", presentation at the Spring 1993
IETF Meeting, Columbus, Ohio.

[Ken78] Ohio

[KA97a] Steve Kent, Randall Atkinson, "IP Authentication Header",
Internet Draft, October 1997.

[KA97b] Steve Kent, ..., Proceedings of SIGCOMM '78, ACM SIGCOMM, 1978. Randall Atkinson, "IP Encapsulating Security
Payload (ESP)", Internet Draft, October 1997.

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

[Ken93] Steve Kent, Privacy Enhancement for Internet Electronic
Mail: Part II: Certificate-Based Key Management, RFC-1422,
DDN Network Information Center, 10 February 1993.

Kent, Atkinson [Page 60]

Internet Draft Security Architecture for IP November 1997

[KB93] J. Kohl & B. Neuman, The Kerberos Network Authentication
Service (V5), RFC-1510, DDN Network Information Center, 10
September 1993.

[MSST97] D Maughan, M. Schertler, M. Schneider, & J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP", Internet Draft, July 26, 1997.

[NS78] R.M. Needham & M.D. Schroeder, "Using Encryption for
Authentication in Large Networks of Computers",
Communications of the ACM, Vol. 21, No. 12, December 1978,
pp. 993-999.

[NS81] R.M. Needham & M.D. Schroeder, "Authentication Revisited",
ACM Operating Systems Review, Vol. 21, No. 1., 1981.

[OG96] Mike Oehler & Rob Glenn, "HMAC-MD5 IP Authentication with
Replay

Atkinson [Page 23]

Internet Draft Security Architecture for IP 10 November 1996 Prevention", Internet Draft, 1 May 1996.

[Orm97] H. K. Orman, "The OAKLEY Key Determination Protocol",
Internet Draft, July 25, 1997.

[OTA94] US Congress, Office of Technology Assessment, "Information
Security & Privacy in Network Environments", OTA-TCT-606,
Government Printing Office, Washington, DC, September 1994.

[Sch96] Jeff Schiller, "Security AD Statement on IPSEC Key Management",
Email to IPsec mailing list, September 19, 1996.

[Pip97] D. Piper, "The Internet IP Security Domain of
Interpretation for ISAKMP", Internet Draft, October 1997.

[Sch94] Bruce Schneier, Applied Cryptography, Section 8.6, John
Wiley & Sons, New York, NY, 1994.

[SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3,
Document SDN.301, Revision 1.5, 15 May 1989, published in
NIST Publication NIST-IR-90-4250, February 1990.

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

[TDG97] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document
Roadmap", Internet Draft, July 1997.

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

[ZDESZ93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and
Zappala, D., "RSVP: A New Resource ReSerVation Protocol",

Kent, Atkinson [Page 61]

Internet Draft Security Architecture for IP November 1997

IEEE Network magazine, September 1993.

DISCLAIMER

Disclaimer

The views and specification expressed in this note document are those of
the editor authors and are not necessarily those of his employer. their employers. The editor
authors and his employer their employers specifically disclaim responsibility for
any problems arising from correct or incorrect implementation or use
of this design.

EDITOR INFORMATION:

Randall Atkinson <rja@cisco.com>
cisco Systems
170 West Tasman Drive
San Jose, CA, 95134-1706

Author Information

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

Randall Atkinson
@Home Network
425 Broadway
Redwood City, CA 94063
USA
E-mail: rja@inet.org

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.

Kent, Atkinson [Page 24] 62]

Internet Draft Security Architecture for IP November 1997

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.

Kent, Atkinson [Page 63]

----