WDIFF

draft-ietf-ipsec-rfc2401bis-02.txt-134238.txt --> draft-ietf-ipsec-rfc2401bis-02.txt

Network Working Group S. Kent
Internet Draft K. Seo
draft-ietf-ipsec-rfc2401bis-02.txt BBN Technologies
Obsoletes: RFC 2401 January April 2004
Expires July October 2004

Security Architecture for the Internet Protocol

Status of this Memo

This document is an Internet Draft and is subject to all provisions
of Section 10 of RFC2026. Internet Drafts are working documents of
the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working
documents as Internet Drafts

Internet Drafts are draft documents valid for a maximum of 6 months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as a "work in progress".

The list of current Internet Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html

The list of Internet Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

Kent & Seo [Page 1]

Internet Draft Security Architecture for IP January April 2004

Table of Contents

1. Introduction.........................................................3 Introduction.........................................................4
1.1 Summary of Contents of Document.................................3 Document.................................4
1.2 Audience........................................................3 Audience........................................................4
1.3 Related Documents...............................................4 Documents...............................................5
2. Design Objectives....................................................4 Objectives....................................................5
2.1 Goals/Objectives/Requirements/Problem Description...............4 Description...............5
2.2 Caveats and Assumptions.........................................5 Assumptions.........................................6
3. System Overview .....................................................6 .....................................................7
3.1 What IPsec Does.................................................6 Does.................................................7
3.2 How IPsec Works.................................................8 Works.................................................9
3.3 Where IPsec May Be Implemented..................................9 Implemented.................................10
4. Security Associations...............................................10 Associations...............................................11
4.1 Definition and Scope...........................................10 Scope...........................................11
4.2 Security Association Functionality.............................13 Functionality.............................15
4.3 Combining Security Associations................................14 Associations................................16
4.4 Major IPsec Databases..........................................14 Databases..........................................16
4.4.1 The Security Policy Database (SPD)........................15 (SPD)........................19
4.4.1.1 Selectors............................................24
4.4.1.2 Structure of an SPD entry............................27
4.4.2 Selectors.................................................19
4.4.3 Security Association Database (SAD).......................22 (SAD).......................29
4.5 SA and Key Management..........................................24 Management..........................................35
4.5.1 Manual Techniques.........................................25 Techniques.........................................35
4.5.2 Automated SA and Key Management...........................25 Management...........................36
4.5.3 Locating a Security Gateway...............................26 Gateway...............................37
4.6 Security Associations and Multicast............................27 Multicast............................38
5. IP Traffic Processing...............................................27 Processing...............................................38
5.1 Outbound IP Traffic Processing (protected-to-unprotected)......28 (protected-to-unprotected)......39
5.1.1 Handling an Outbound Packet That Must Be Dropped..........30 Discarded........41
5.1.2 Header Construction for Tunnel Mode.......................31 Mode.......................42
5.1.2.1 IPv4 -- Header Construction for Tunnel Mode..........33 Mode..........43
5.1.2.2 IPv6 -- Header Construction for Tunnel Mode..........34 Mode..........45
5.2 Processing Inbound IP Traffic (unprotected-to-protected).......35 (unprotected-to-protected).......45
6. ICMP Processing (to be filled in when IPsec issue #91 is resolved)..38 ....................................................49
7. Auditing............................................................38 Handling Fragments (on the protected side of the IPsec boundary)....49
8. Conformance Requirements............................................38 Auditing............................................................51
9. Security Considerations.............................................38 Conformance Requirements............................................52
10. Security Considerations............................................52
11. Differences from RFC 2401..........................................38
Acknowledgements.......................................................38 2401..........................................52
Acknowledgements.......................................................57
Appendix A -- Glossary.................................................40 Glossary.................................................58
Appendix B -- Decorrelation............................................43 Decorrelation............................................61
Appendix C -- Categorization of ICMP messages [May be deleted].........46
References.............................................................49 deleted].........64
Appendix D -- ASN.1 for an SPD entry...................................67
Appendix E -- Fragment Handling Rationale..............................72
References.............................................................73
Author Information.....................................................51
Notices................................................................52 Information.....................................................74

Kent & Seo [Page 2]

Internet Draft Security Architecture for IP January April 2004

Notices................................................................77

Kent & Seo [Page 3]

Internet Draft Security Architecture for IP April 2004

1. Introduction

1.1 Summary of Contents of Document

This document specifies the base architecture for IPsec compliant
systems. It describes how to provide a set of security services for
traffic at the IP layer, in both the IPv4 and IPv6 environments.
This document describes the requirements for systems that implement
IPsec, the fundamental elements of such systems, and how the elements
fit together and fit into the 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 the IPsec architecture. Other documents
address additional architectural details in specialized environments,
e.g., use of IPsec in NAT environments and more comprehensive support
for IP multicast. The fundamental components of the IPsec security
architecture are discussed in terms of their underlying, required
functionality. Additional RFCs (see Section 1.3 for pointers to
other documents) define the protocols in (a), (c), and (d).

a. Security 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 automated (The Internet Key
Exchange (IKE))
d. Cryptographic algorithms for authentication and encryption

This document is not a Security Architecture for the Internet; it
addresses security only at the IP layer, provided through the use of
a combination of cryptographic and protocol security mechanisms.

The spelling "IPsec" is preferred and used throughout this and all
related IPsec standards. All other capitalizations of IPsec (e.g.,
IPSEC, IPSec, ipsec) are deprecated. However, any capitalization of
the sequence of letters "IPsec" should be understood to refer to the
IPsec protocols.

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 is primarily individuals who
implement this IP security technology or who architect systems that
will use this technology. Technically adept users of this technology
(end users or system administrators) also are part of the target

Kent & Seo [Page 3] 4]

Internet Draft Security Architecture for IP January April 2004

audience. A glossary is provided as an appendix in Appendix A to help fill in gaps
in background/vocabulary. This document assumes that the reader is
familiar with the Internet Protocol (IP), related networking
technology, and general information system security terms and
concepts.

1.3 Related Documents

As mentioned above, other documents provide detailed definitions of
some of the components of IPsec and of their inter-relationship.
They include RFCs on the following topics:

a. security protocols -- RFCs describing the Authentication Header
(AH) [Ken04b] and Encapsulating Security Payload (ESP) [Ken04a]
protocols.
b. cryptographic algorithms for integrity and encryption -- one RFC
that defines the mandatory, default algorithms for use with AH
and ESP [Eas03], a similar RFC that defines the mandatory
algorithms for use with IKEv2 [Sch03] plus a separate RFC for
each cryptographic algorithm.
c. automatic key management -- RFCs on "The Internet Key Exchange
(IKEv2) Protocol" [Kau03] and "Cryptographic Algorithms for use
in the Internet Key Exchange Version 2" [Sch03]

2. Design Objectives

2.1 Goals/Objectives/Requirements/Problem Description

IPsec is designed to provide interoperable, high quality,
cryptographically-based security for IPv4 and IPv6. The set of
security services offered includes access control, connectionless
integrity, data origin authentication, detection and rejection of
replays (a form of partial sequence integrity), confidentiality (via
encryption), and limited traffic flow confidentiality. These
services are provided at the IP layer, offering protection for all
protocols that may be carried over IP in a standard fashion
(including IP itself).

IPsec includes a specification for minimal firewall functionality,
since that is an essential aspect of access control at the IP layer.
Implementations are free to provide more sophisticated firewall
mechanisms, and to implement the IPsec- mandated IPsec-mandated functionality using
those more sophisticated mechanisms. (Note that interoperability may
suffer if additional firewall constraints on traffic flows are
imposed by an IPsec implementation but cannot be negotiated based on
the traffic selector features defined in this document and negotiated
via IKEv2.) The IPsec firewall function makes use of the

Kent & Seo [Page 4] 5]

Internet Draft Security Architecture for IP January April 2004

cryptographically-enforced authentication and integrity provided for
all IPsec traffic to offer better access control than could be
obtained through use of an independent a firewall (one not privy to IPsec internal parameters).
parameters) plus separate cryptographic protection.

Most of the security services are provided through use of two traffic
security protocols, the Authentication Header (AH) and the
Encapsulating Security Payload (ESP), and through the use of
cryptographic key management procedures and protocols. The set of
IPsec protocols employed in a context, and the ways in which they are
employed, will be determined by the users/administrators in that
context. It is the goal of the IPsec architecture to ensure that
compliant implementations include the services and management
interfaces needed to meet the security requirements of a broad user
population.

When IPsec is correctly implemented and deployed, it ought not
adversely affect users, hosts, and other Internet components that do
not employ IPsec for traffic protection. IPsec security protocols
(AH & ESP, and to a lesser extent, IKE) are designed to be
cryptographic algorithm-independent. This modularity permits
selection of different sets of cryptographic algorithms as
appropriate, without affecting the other parts of the implementation.
For example, different user communities may select different sets of
cryptographic algorithms (creating cryptographically-enforced
cliques) if required.

A set of default cryptographic algorithms for use with AH and ESP is
specified [Eas03] to facilitate interoperability in the global
Internet. The use of these cryptographic 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 associated default cryptographic
algorithms are designed to provide high quality security for Internet
traffic. However, the security offered by use of these protocols
ultimately depends on the quality of the their implementation, which
is outside the scope of this set of standards. Moreover, the
security of a computer system or network is a function of many
factors, including personnel, physical, procedural, compromising
emanations, and computer security practices. Thus IPsec is only one
part of an overall system security architecture.

Finally, the security afforded by the use of IPsec is critically
dependent on many aspects of the operating environment in which the

Kent & Seo [Page 5] 6]

Internet Draft Security Architecture for IP January April 2004

IPsec implementation executes. For example, defects in OS security,
poor quality of random number sources, sloppy system management
protocols and practices, etc. can all degrade the security provided
by IPsec. As above, none of these environmental attributes are
within the scope of this or other IPsec standards.

3. System Overview

This section provides a high level description of how IPsec works,
the components of the system, and how they fit together to provide
the security services noted above. The goal of this description is
to enable the reader to "picture" the overall process/system, see how
it fits into the IP environment, and to provide context for later
sections of this document, which describe each of the components in
more detail.

An IPsec implementation operates in a host, as a security gateway, or
as an independent device, affording protection to IP traffic. (A
security gateway is an intermediate system implementing IPsec, e.g.,
a firewall or router that has been IPsec-enabled.) More detail on
these classes of implementations is provided later, in Section 3.3.
The protection offered by IPsec is based on requirements defined by a
Security Policy Database (SPD) established and maintained by a user
or system administrator, or by an application operating within
constraints established by either of the above. In general, packets
are selected for one of three processing actions based on IP and next
layer header information (Selectors, Section 4.4.2) 4.4.1.1) matched against
entries in the database (SPD). Each packet is either afforded PROTECTed using
IPsec security services, discarded, DISCARDed, or allowed to bypass BYPASS IPsec
protection, based on the applicable SPD policies identified by the
Selectors.

3.1 What IPsec Does

IPsec creates a boundary between unprotected and protected
interfaces, for a host or a network (See (see Figure 1 below). Traffic
traversing the boundary is subject to the access controls specified
by the user or administrator responsible for the IPsec configuration.
These controls indicate whether packets cross the boundary unimpeded,
are afforded security services via AH or ESP, or are discarded. IPsec
security services are offered at the IP layer through selection of
appropriate security protocols, cryptographic algorithms, and
cryptographic keys. IPsec can be used to protect one or more "paths"
(a) between a pair of hosts, (b) between a pair of security gateways,
or (c) between a security gateway and a host. Compliant implementations A compliant host
implementation MUST support (a) and (c) and a compliant security
gateway must support all three of these forms of connectivity noted here. connectivity, since

Kent & Seo [Page 6] 7]

Internet Draft Security Architecture for IP January April 2004

under certain circumstances a security gateway acts as a host.

Unprotected
^ ^
| |
+-------------|-------|-------+
| +-------+ | | |
| |Discard|<--| V |
| +-------+ |B +--------+ |
................|y..| AH/ESP |..... IPsec Boundary
| +---+ |p +--------+ |
| |IKE|<----|a ^ |
| +---+ |s | |
| +-------+ |s | |
| |Discard|<--| | |
| +-------+ | | |
+-------------|-------|-------+
| |
V V
Protected

Figure 1. Top Level IPsec Processing Model

In this diagram, "unprotected" refers to an interface that might also
be described as "black" or "ciphertext." Here, "protected" refers to
an interface that might also be described as "red" or "plaintext."
The protected interface noted above may be internal, e.g., in a host
implementation of IPsec; IPsec, the protected interface may link to a socket
layer interface presented by the OS. In this document, the term
"inbound" refers to traffic entering an IPsec implementation via the
unprotected interface. The term "outbound" refers to traffic entering
the implementation via the protected interface, or emitted by the
implementation on the protected side of the boundary and directed
toward the unprotected interface. An IPsec implementation may
support more than one interface on either or both sides of the
boundary.

Note the facilities for discarding traffic on either side of the
IPsec boundary, the bypass BYPASS facility that allows traffic to transit
the boundary without cryptographic protection, and the reference to
IKE as a protected-side key and security management function.

IPsec optionally supports negotiation of IP compression [SMPT98],
motivated in part by the observation that when encryption is employed
within IPsec, it prevents effective compression by lower protocol
layers.

Kent & Seo [Page 7] 8]

Internet Draft Security Architecture for IP January April 2004

3.2 How IPsec Works

IPsec uses two protocols to provide traffic security services --
Authentication Header (AH) and Encapsulating Security Payload (ESP).
Both protocols are described in detail in their respective RFCs
[KA98a, KA98b].
[Ken04b, Ken04a]. IPsec implementations MUST support ESP and MAY
support AH. (Support for AH has been downgraded to MAY because
experience has shown that there are very few contexts in which ESP
cannot provide the requisite security services. Note that ESP can be
used to provide only integrity, without confidentiality, making it
comparable to AH in most contexts.)

o The IP Authentication Header (AH) [Ken04b] offers integrity and
data origin authentication, with optional (at the discretion of
the receiver) anti-replay features.

o The Encapsulating Security Payload (ESP) protocol [Ken04a] offers
the same set of services, and also offers confidentially. Use of
ESP in a confidentiality-only mode is discouraged. When ESP is
used with confidentiality enabled, there are provisions for
limited traffic flow confidentiality, i.e., provisions for
concealing packet length, and to facilitate efficient generation
and discard of dummy packets. This capability is likely to be
effective primarily in VPN and overlay network contexts.

o Both AH and ESP offer access control, enforced through the
distribution of cryptographic keys and the management of traffic
flows as dictated by the Security Policy Database (SPD, Section
4.4).
4.4.1).

These protocols may be applied individually or in combination with
each other to provide security services in IPv4 and IPv6. However,
most security requirements can be met through the use of ESP by
itself. Each protocol supports two modes of use: transport mode and
tunnel mode. In transport mode, AH and ESP provide protection
primarily for next layer protocols; in tunnel mode, AH and ESP are
applied to tunneled IP packets. The differences between the two
modes are discussed in Section 4. 4.1.

IPsec allows the user (or system administrator) to control the
granularity at which a security service is offered. For example, one
can create a single encrypted tunnel to carry all the traffic between
two security gateways or a separate encrypted tunnel can be created
for each TCP connection between each pair of hosts communicating
across these gateways. IPsec, through the SPD management paradigm,
incorporates facilities for specifying:

o which security services protocols (AH, ESP) to use and in what combinations employ, their mode

Kent & Seo [Page 8] 9]

Internet Draft Security Architecture for IP January April 2004

(transport or tunnel), security service options, what
cryptographic algorithms to use, and in what combinations to use
the specified protocols and services,
o the granularity at which protection should be applied
o the cryptographic algorithms used to effect cryptographic-based
security applied.

Because most of the security services provided by IPsec require the
use of cryptographic keys, IPsec relies on a separate set of
mechanisms for putting these keys in place. This document requires
support for both manual and automated distribution of keys. It
specifies a specific public-key based approach (IKEv2 [KAU04]) for
automated key management, but other automated key distribution
techniques MAY be used.

Note: This document mandates support for several features for which
support is available in IKEv2 but not in IKEv1, e.g., negotiation of
an SA representing ranges of source local and destination remote ports or negotiation of
multiple SAs with the same selectors. Therefore this document assumes
use of IKEv2 or a key and security association management system with
comparable features.

3.3 Where IPsec Can Be Implemented

There are many ways in which IPsec may be implemented in a host, or
in conjunction with a router or firewall to create a security
gateway, or as an independent security device.

a. IPsec may be integrated into the native IP stack. This requires
access to the IP source code and is applicable to both hosts and
security gateways, although native host implementations benefit
the most from this strategy, as explained later (Section 4.4.1,
paragraph 4; 6; Section 4.4.2, 4.4.1.1, last paragraph) paragraph).

b. In a "bump-in-the-stack" (BITS) implementation, IPsec is
implemented "underneath" an existing implementation of an IP
protocol stack, between the native IP and the local network
drivers. Source code access for the IP 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 a dedicated, inline security protocol processor is a
common design feature of systems used by the 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. Usually the
BITW device is itself 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.

Kent & Seo [Page 9] 10]

Internet Draft Security Architecture for IP January April 2004

gateway.

This document often talks in terms of host or security gateway use of
IPsec, without regard to whether the implementation is native, BITS
or BITW. When the distinctions among these implementation options are
significant, the document makes reference to specific implementation
approaches.

4. Security Associations

This section defines Security Association management requirements for
all IPv6 implementations and for those IPv4 implementations that
implement AH, ESP, or both. both AH and ESP. The concept of a "Security
Association" (SA) is fundamental to IPsec. Both AH and ESP make use
of SAs and a major function of IKE is the establishment and
maintenance of Security Associations. All implementations of AH or
ESP MUST support the concept of a Security 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, management and SA management techniques.

4.1 Definition and Scope

A Security Association (SA) is a simplex "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 not
both. If both AH and ESP protection are applied to a traffic stream,
then two SAs must be created and coordinated to effect protection
through iterated application of the security protocols. To secure
typical, bi-directional communication between two IPsec-enabled
systems, a pair of Security Associations (one in each direction) are
required. IKE explicitly creates SA pairs in recognition of this
common usage requirement.

For an SA used to carry unicast (or anycast) traffic, the SPI
(Security Parameters Index - see Appendix A and AH [Ken04b] and ESP
[Ken04a] specifications) by itself suffices to specify an SA.
However, as a local matter, an implementation may choose to use the
SPI in conjunction with the IPsec protocol type (AH or ESP) for SA
identification. If an IPsec implementation supports multicast, then
it MUST support multicast SAs using the algorithm described in AH and
ESP below for mapping
inbound IPsec protected datagrams to SAs.
(Implementations Implementations that support only
unicast traffic need not implement
that this demultiplexing algorithm.)

Note: If different classes of traffic (distinguished by DSCP bits
[NiBlBaBL98], [Gro02]) are sent on algorithm.

In many secure multicast architectures, e.g., [RFC3740], a central
Group Controller/Key Server unilaterally assigns the same SA, this could result group security
association's SPI. This SPI assignment is not negotiated or
coordinated with the key management (e.g., IKE) subsystems that
reside in
inappropriate discarding of lower priority packets due to the
windowing mechanism used by receivers to reject replays. Therefore a
sender SHOULD put traffic of different classes, but with individual end systems that comprise the same group.

Kent & Seo [Page 10] 11]

Internet Draft Security Architecture for IP January April 2004

selector values, on different SAs to appropriately support QoS. To
permit this,

Consequently, it is possible that a group security association and a
unicast security association can simultaneously use the same SPI. A
multicast-capable IPsec implementation MUST permit establishment and
maintenance correctly de-multiplex
inbound traffic even in the context of multiple SAs between a given sender and receiver, with SPI collisions.

Each entry in the same selectors. Distribution Security Association Database (SAD) [Section 4.4.2]
must indicate whether the SA lookup makes use of traffic among these parallel SAs
to support QoS is locally determined by the sender destination, or
destination and source, IP addresses, in addition to the SPI. For
multicast SAs, the protocol field is not
negotiated by IKE. The receiver MUST process employed for SA lookups. For
each inbound, IPsec-protected packet, an implementation must conduct
its search of the packets from SAD such that it finds the
different SAs without prejudice.

DISCUSSION: While entry that matches the DSCP [NiBlBaBL98, Gro02] and ECN [RaFlBL01]
fields are not "selectors", as
"longest" SA identifier. In this context, if two or more SAD entries
match based on the SPI value, then the entry that term in used also matches based
on destination, or destination and source, address comparison (as
indicated in this
architecture, the sender will need a mechanism to direct packets with
a given (set of) DSCP values to SAD entry) is the appropriate SA. "longest" match. This mechanism
might be termed implies a "classifier".

As noted above, two types of SAs are defined: transport mode and
tunnel mode. IKE creates pairs of SAs, so for simplicity, we choose
to require that both SAs in a pair be
logical ordering of the same mode, transport or
tunnel.

A transport mode SA is SAD search as follows:

1. Search the SAD for a security association typically employed
between match on {SPI, destination address, source
address}. If a pair of hosts SAD entry matches then process the inbound ESP
packet with that matching SAD entry. Otherwise, proceed to provide end-to-end security services. When
link (vs. end-to-end) security is desired between two intermediate
systems along a path, transport mode MAY be used between security
gateways or between step
2.

2. Search the SAD for a security gateway and match on {SPI, destination address}. If the
SAD entry matches then process the inbound ESP packet with that
matching SAD entry. Otherwise, proceed to step 3.

3. Search the SAD for a host. In match on only {SPI} if the latter
case, transport mode may be used receiver has
chosen to support IP-in-IP [Per96] or GRE
tunneling [FaLiHaMeTr00] over transport mode SAs. The access control
functions maintain a single SPI space for AH and ESP, and on
{SPI, protocol} otherwise. If an SAD entry matches then process
the inbound ESP packet with that are matching SAD entry. Otherwise,
discard the packet and log an important part of IPsec are significantly
limited in auditable event.

In practice, an implementation MAY choose any method to accelerate
this context, as they cannot search, although its externally visible behavior MUST be applied
functionally equivalent to having searched the end-to-end
headers of SAD in the packets that traverse above
order. For example, a transport mode software-based implementation could index into
a hash table by the SPI. The SAD entries in each hash table bucket's
linked list are kept sorted to have those SAD entries with the
longest SA used identifiers first in this
fashion. Thus this way of using transport mode should be evaluated
carefully before being employed in a specific context.

In IPv4, a transport mode security protocol header appears
immediately after the IP header and any options, and before any next
layer protocols (e.g., TCP or UDP). In IPv6, the security protocol
header appears after the base IP header and selected extension
headers, but may appear before or after destination options; it MUST
appear before next layer protocols. In that linked list. Those SAD entries
having the case of ESP, a transport
mode shortest SA provides security services only for these next layer
protocols, not for the IP header or any extension headers preceding
the ESP header. In identifiers are sorted so that they are the case of AH,
last entries in the protection is also extended linked list. A hardware-based implementation may
be able to selected portions of effect the IP header preceding it, selected portions longest match search intrinsically, using
commonly available TCAM features.

The indication of extension headers, whether source and selected options (contained in the IPv4
header, IPv6 Hop-by-Hop extension header, or IPv6 Destination
extension headers). For more details on the coverage afforded by AH,
see the AH specification [Ken04b].

A tunnel mode SA destination address matching is essentially an SA applied
required to an IP tunnel, with map inbound IPsec traffic to SAs MUST be set either as a

Kent & Seo [Page 11] 12]

Internet Draft Security Architecture for IP January April 2004

the access controls applied to the headers of the traffic inside the
tunnel. In general, whenever either end

side effect of a security association is
a security gateway, the manual SA MUST be tunnel mode. Thus configuration or via negotiation using an SA between
two security gateways is typically
management protocol, e.g., IKE or GDOI [RFC3547]. Typically, Source-
Specific Multicast (SSM) [HC03] groups use a tunnel mode SA, as is an 3-tuple SA
between identifier
composed of an SPI, a host destination multicast address, and source
address. An Any-Source Multicast group SA requires only an SPI and a security gateway. Note that for the case where
destination multicast address as an identifier.

If different classes of traffic is destined for a security gateway, e.g., SNMP commands, (distinguished by DSCP bits
[NiBlBaBL98], [Gro02]) are sent on the
security gateway is acting as a host same SA, and transport mode if the receiver
is allowed.
In this case, employing the SA terminates at a host (management) function
within a security gateway optional anti-replay feature available in both AH
and thus merits different treatment. Also,
as noted above, security gateways MAY support a transport mode SA ESP, this could result in inappropriate discarding of lower
priority packets due to
provide link security for IP traffic. Two hosts MAY establish a
tunnel mode SA between themselves. Several concerns motivate the use
of tunnel mode for an SA involving windowing mechanism used by this feature.
Therefore a security gateway. For example,
if there are multiple paths (e.g., via sender SHOULD put traffic of different security gateways)
to classes, but with
the same destination behind security gateways, it is important
that an IPsec packet be sent selector values, on different SAs to appropriately support
QoS. To permit this, the security gateway with which the
SA was negotiated. Similarly, IPsec implementation MUST permit
establishment and maintenance of multiple SAs between a packet that might be fragmented en
route must have all the fragments delivered to given sender
and receiver, with the same IPsec
instance for reassembly. Also, when a fragment selectors. Distribution of traffic among
these parallel SAs to support QoS is processed locally determined by IPsec the sender
and transmitted, then fragmented en route, it is critical that there
be inner and outer headers to retain not negotiated by IKE. The receiver MUST process the fragmentation state data for packets
from the pre- different SAs without prejudice.

DISCUSSION: While the DSCP [NiBlBaBL98, Gro02] and post-IPsec packet formats. Hence there ECN [RaFlBL01]
fields are several
reasons for employing tunnel mode when either end of an SA is not "selectors", as that term in used in this
architecture, the sender will need a
security gateway.

Note: AH and ESP cannot mechanism to direct packets with
a given (set of) DSCP values to the appropriate SA. This mechanism
might be applied using termed a "classifier".

As noted above, two types of SAs are defined: transport mode and
tunnel mode. IKE creates pairs of SAs, so for simplicity, we choose
to IPv4
packets require that are fragments. Only tunnel mode can be employed both SAs in such
cases.

For a tunnel pair be of the same mode, transport or
tunnel.

A transport mode SA, there SA is an "outer" IP header that specifies
the IPsec processing source and destination, plus an "inner" IP
header that specifies the (apparently) ultimate source and
destination for the packet. The a security protocol header appears
after the outer IP header, and before the inner IP header. If AH is association typically employed in tunnel mode, portions of the outer IP header are afforded
protection (as above), as well as all of the tunneled IP packet
(i.e., all
between a pair of the inner IP header is protected, as well as next layer
protocols). If ESP is employed, the protection is afforded only to
the tunneled packet, not hosts to the outer header.

In summary,
a) A host implementation provide end-to-end security services. When
security is desired between two intermediate systems along a path
(vs. end-to-end use of IPsec MUST support both IPsec), transport and
tunnel mode. This is true for native, BITS, and BITW
implementations for hosts.

b) A mode MAY be used between
security gateways or between a security gateway MUST support tunnel mode and MAY support
transport mode. If it supports a host. In the
latter case, transport mode, that should mode may be used only when to support in-IP tunneling
(e.g., IP-in-IP [Per96] or GRE tunneling [FaLiHaMeTr00]) over
transport mode SAs. To further clarify, the use of transport mode by
an intermediate system (e.g., a security gateway gateway) is acting permitted only
when applied to packets whose source address (for outbound packets)
or destination address (for inbound packets) is an address belonging
to the intermediate system itself. The access control functions that
are an important part of IPsec are significantly limited in this
context, as they cannot be applied to the end-to-end headers of the
packets that traverse a host, e.g., for transport mode SA used in this fashion. Thus
this way of using transport mode should be evaluated carefully before

Kent & Seo [Page 12] 13]

Internet Draft Security Architecture for IP January April 2004

network management, or to provide link security.

4.2 Security Association Functionality

The set of security services offered by an SA depends on the

being employed in a specific context.

In IPv4, a transport mode security protocol selected, the SA mode, header appears
immediately after the endpoints of the SA, and on the
election of optional services within the protocol.

For example, both AH IP header and ESP offer integrity any options, and authentication
services, but before any next
layer protocols (e.g., TCP or UDP). In IPv6, the coverage differs for each security protocol and differs for
transport vs. tunnel mode. If
header appears after the integrity of an IPv4 option or IPv6
extension base IP header must be protected en route between sender and
receiver, AH can provide this service, except for selected extension
headers, but may appear before or after destination options; it MUST
appear before next layer protocols (e.g., TCP, UDP, SCTP). In the mutable (non-
predictable) parts
case of ESP, a transport mode SA provides security services only for
these next layer protocols, not for the IP header or any extension headers. However,
headers preceding the same
security may be achieved in some contexts by applying ESP to a tunnel
carrying a packet.

The granularity header. In the case of access control provided AH, the protection
is determined by also extended to selected portions of the
choice IP header preceding it,
selected portions of extension headers, and selected options
(contained in the selectors that define each security association.
Moreover, IPv4 header, IPv6 Hop-by-Hop extension header, or
IPv6 Destination extension headers). For more details on the authentication means employed
coverage afforded by IPsec peers, e.g.,
during creation of AH, see the AH specification [Ken04b].

A tunnel mode SA is essentially an IKE (vs. child) SA also effects applied to an IP tunnel, with
the granularity access controls applied to the headers of the access control afforded.

If confidentiality is selected, then an ESP (tunnel mode) SA between
two security gateways can offer partial traffic flow confidentiality.
The use of inside the
tunnel. Two hosts MAY establish a tunnel mode allows the inner IP headers to be encrypted,
concealing SA between themselves.
Aside from the identities two exceptions below, whenever either end of a
security association is a security gateway, the (ultimate) traffic source and
destination. Moreover, ESP payload padding also can SA MUST be invoked to
hide the size of the packets, further concealing the external
characteristics of the traffic. Similar tunnel
mode. Thus an SA between two security gateways is typically a tunnel
mode SA, as is an SA between a host and a security gateway. The two
exceptions are as follows.

o Where traffic flow confidentiality
services may be offered when is destined for a mobile user security gateway, e.g., SNMP
commands, the security gateway is assigned acting as a dynamic IP
address in host and transport
mode is allowed. In this case, the SA terminates at a dialup context, host
(management) function within a security gateway and establishes thus merits
different treatment.

o As noted above, security gateways MAY support a (tunnel mode) ESP transport mode SA
to provide security for IP traffic between two systems along a corporate firewall (acting as
path, e.g., between a host and a security gateway). Note that
fine granularity SAs generally are more vulnerable to traffic
analysis than coarse granularity ones that are carrying traffic from
many subscribers.

NOTE: A compliant implementation MUST NOT allow instantiation gateway or between two
security gateways.

Several concerns motivate the use of an
ESP SA that employs both NULL encryption and no integrity algorithm.
An attempt to negotiate such tunnel mode for an SA is an auditable event involving
a security gateway. For example, if there are multiple paths (e.g.,
via different security gateways) to the same destination behind
multiple security gateways, it is important that an IPsec packet be
sent to the security gateway with which the SA was negotiated.
Similarly, a packet that might be fragmented en-route must have all
the fragments delivered to the same IPsec instance for reassembly
prior to cryptographic processing. Also, when a fragment is processed
by both
initiator IPsec and responder. The audit log entry transmitted, then fragmented en-route, it is critical
that there be inner and outer headers to retain the fragmentation
state data for this event SHOULD
include the current date/time, local IKE IP address, pre- and remote IKE
IP address. The initiator SHOULD record the relevant SPD entry. post-IPsec packet formats. Hence there

Kent & Seo [Page 13] 14]

Internet Draft Security Architecture for IP January April 2004

4.3 Combining Security Associations

This document does not require support

are several reasons for nested employing tunnel mode when either end of an
SA is a security
associations or for what RFC 2401 called "SA bundles." These features
still gateway.

Note: AH and ESP cannot be applied using transport mode to IPv4
packets that are fragments. Only tunnel mode can be effected by appropriate configuration of both the SPD
and the local forwarding functions (for inbound and outbound
traffic), but employed in such
cases. For IPv6, it would be feasible to carry a plaintext fragment
on a transport mode SA; however, for simplicity, this function is outside restriction
also applies to IPv6 packets. See Section 7 for more details on
handling plaintext fragments on the protected side of the IPsec module and thus
the scope of this specification. As
barrier.

For a result, management of
nested/bundled SAs tunnel mode SA, there is potentially more complex and less assured than
under the model implied by RFC 2401. An implementation an "outer" IP header that provides
support for nested SAs SHOULD provide a management interface specifies
the IPsec processing source and destination, plus an "inner" IP
header that
enables a user or administrator to express specifies the nesting requirement, (apparently) ultimate source and then create
destination for the appropriate SPD entries packet. The security protocol header appears
after the outer IP header, and forwarding table
entries to effect before the requisite processing.

4.4 Major IPsec Databases

Many inner IP header. If AH is
employed in tunnel mode, portions of the details associated with processing outer IP traffic in an IPsec
implementation header are largely a local matter, not subject to
standardization. However, some external aspects afforded
protection (as above), as well as all of the processing
must be standardized, to ensure interoperability and to provide a
minimum management capability that is essential for productive use of
IPsec. This section describes a general model for processing tunneled IP
traffic relative to IPsec functionality, in support packet
(i.e., all of these
interoperability and functionality goals. The model described below the inner IP header is nominal; implementations need not match details of this model protected, as
presented, but well as next layer
protocols). If ESP is employed, the external behavior of implementations MUST
correspond protection is afforded only to
the externally observable characteristics of this model
in order tunneled packet, not to be deemed compliant.

There are two nominal databases in this model: the Security Policy
Database and the Security Association Database. The first specifies
the policies that determine the disposition of all IP traffic inbound
or outbound from a outer header.

In summary,
a) A host or implementation of IPsec MUST support both transport and
tunnel mode. This is true for native, BITS, and BITW
implementations for hosts.

b) A security gateway. The second database
contains parameters gateway MUST support tunnel mode and MAY support
transport mode. If it supports transport mode, that are associated with each established (keyed)
security association.

A third database, should be
used only when the Peer Authorization Database (PAD) security gateway is also
required. The PAD provides acting as a link host, e.g., for
network management, or to provide security between two
intermediate systems along a path.

4.2 Security Association Functionality

The set of security services offered by an SA management depends on the security
protocol
like IKE and selected, the SPD. The PAD indicates SA mode, the range endpoints of identities that
a peer is authorized to represent when (child) SAs are negotiated
with the peer. The identities may be a list of IP address ranges or
symbolic names. The fundamental requirement associated with SA, and on the PAD
is that
election of optional services within the traffic selectors passed by protocol.

For example, both AH and ESP offer integrity and authentication
services, but the SA management coverage differs for each protocol and differs for comparison against
transport vs. tunnel mode. If the SPD MUST integrity of an IPv4 option or IPv6
extension header must be verified as authorized
relative to protected en-route between sender and
receiver, AH can provide this service, except for the authenticated peer mutable (non-
predictable) parts of the SA management protocol.
(See also Section 4.5.3, which levies requirements on IP or extension headers. However, the PAD same
security may be achieved in some contexts by applying ESP to a tunnel
carrying a packet.

Kent & Seo [Page 14] 15]

Internet Draft Security Architecture for IP January April 2004

support of locating security gateways.)

The PAD also specifies how to authenticate each peer, e.g., via
shared secret or use granularity of a certificate. If a shared secret access control provided is used, determined by the secret is stored here. If a certificate is used,
choice of the trust anchor
for selectors that define each security association.
Moreover, the certificate is part authentication means employed by IPsec peers, e.g.,
during creation of an IKE (vs. child) SA also effects the PAD. Because the PAD might be
incorporated into granularity
of the SA management protocol implementation, it is
not discussed extensively in this document. access control afforded.

If confidentiality is selected, then an IPsec implementation acts as a ESP (tunnel mode) SA between
two security gateway for multiple
subscribers, it MAY implement multiple separate IPsec contexts. Each
context MAY have and gateways can offer partial traffic flow confidentiality.
The use completely independent identities, policies,
key management SAs, and/or IPsec SAs. This is for of tunnel mode allows the most part a
local implementation matter. However, a means for associating inbound
(SA) proposals with local contexts is required. To this end, if
supported by inner IP headers to be encrypted,
concealing the key management protocol in use, context identifiers
MAY identities of the (ultimate) traffic source and
destination. Moreover, ESP payload padding also can be conveyed from initiator invoked to responder in
hide the signaling
messages, with size of the result that IPsec SAs are created with a binding
to a particular context.

The IPsec model described here embodies a clear separation between
forwarding (routing) and security decisions, to accommodate a wide
range packets, further concealing the external
characteristics of contexts where IPsec may be employed. Forwarding may be
trivial, in the case where there are only two interfaces, or it traffic. Similar traffic flow confidentiality
services may be complex, e.g., if there are multiple protected or unprotected
interfaces or if the context in which IPsec is implemented employs offered when a
sophisticated forwarding function. IPsec assumes only that outbound
and inbound traffic that has passed through IPsec processing mobile user is
forwarded in assigned a fashion consistent with the context dynamic IP
address in which IPsec is
implemented. Support for nested SAs is optional; if required, it
requires coordination between forwarding tables a dialup context, and SPD entries to
cause establishes a packet (tunnel mode) ESP SA
to traverse the IPsec boundary a corporate firewall (acting as a security gateway). Note that
fine granularity SAs generally are more vulnerable to traffic
analysis than once.

4.4.1 The Security Policy Database (SPD) coarse granularity ones that are carrying traffic from
many subscribers.

NOTE: A security association is a management construct used compliant implementation MUST NOT allow instantiation of an
ESP SA that employs both NULL encryption and no integrity algorithm.
An attempt to enforce
security policy for traffic crossing the IPsec boundary. Thus negotiate such an
essential element of SA processing is an underlying Security Policy
Database (SPD) that specifies what services are to be offered to IP
datagrams auditable event by both
initiator and in what fashion. responder. The form of the database audit log entry for this event SHOULD
include the current date/time, local IKE IP address, and its
interface are remote IKE
IP address. The initiator SHOULD record the relevant SPD entry.

4.3 Combining Security Associations

This document does not require support for nested security
associations or for what RFC 2401 called "SA bundles." These features
still can be effected by appropriate configuration of both the SPD
and the local forwarding functions (for inbound and outbound
traffic), but this capability is outside of the IPsec module and thus
the scope of this specification. However, this
section specifies minimum As a result, management functionality of
nested/bundled SAs is potentially more complex and less assured than
under the model implied by RFC 2401. An implementation that must be
provided, to allow provides
support for nested SAs SHOULD provide a management interface that
enables a user or system administrator to control whether express the nesting requirement,
and how IPsec is applied then create the appropriate SPD entries and forwarding table
entries to traffic transmitted or received by a host
or transiting a security gateway. The SPD, or relevant caches, must
be consulted during effect the processing requisite processing.

4.4 Major IPsec Databases

Many of ALL traffic (inbound and
outbound), including non-IPsec traffic, that traverses the details associated with processing IP traffic in an IPsec
implementation are largely a local matter, not subject to

Kent & Seo [Page 15] 16]

Internet Draft Security Architecture for IP January April 2004

boundary. This includes IPsec

standardization. However, some external aspects of the processing
must be standardized, to ensure interoperability and to provide a
minimum management capability that is essential for productive use of
IPsec. This section describes a general model for processing IP
traffic such as IKE. An relative to IPsec implementation MUST have at least one SPD, and it MAY support
multiple SPDs, if appropriate for the context functionality, in which the IPsec
implementation operates. There support of these
interoperability and functionality goals. The model described below
is no requirement to maintain SPDs on
a per interface basis, nominal; implementations need not match details of this model as was specified in RFC 2401. However, if an
implementation supports multiple SPDs, then it
presented, but the external behavior of implementations MUST include an
explicit SPD selection function, that is invoked
correspond to select the
appropriate SPD for outbound traffic processing. The inputs to externally observable characteristics of this
function model
in order to be deemed compliant.

There are three nominal databases in this model: the outbound packet Security Policy
Database (SPD), the Security Association Database (SAD), and any local metadata (e.g., the
interface via which Peer
Authorization Database (PAD). The first specifies the packet arrived) required to effect policies that
determine the SPD
selection function. The output disposition of the function is an SPD ID.

Each SPD entry is either implicitly or explicitly directional. For all IP traffic protected by IPsec, the source and destination address and
ports are swapped to represent directionality, consistent with IKE
conventions. For bypassed or discarded traffic, separate inbound and or outbound entries from
a host or security gateway (Section 4.4.1). The second database
contains parameters that are supported, e.g., to permit unidirectional flows
if required. associated with each established (keyed)
security association (Section 4.4.2).

Peer Authorization Database (PAD)

The SPD is an ordered third database, consistent with the use of ACLs or
packet filters in firewalls, routers, etc. The ordering requirement
arises because entries often will overlap due to Peer Authorization Database (PAD) provides
a link between an SA management protocol like IKE and the presence SPD. The
PAD indicates the range of
(non-trivial) ranges as values for selectors. Thus a user identities that an IPv4 or
administrator MUST be able to order the entries to express a desired
access control policy. There IPv6 peer is no way
authorized to impose represent when (child) SAs are negotiated with the
peer. The identities may be a general, canonical
order on SPD entries, because list of IPv4 or IPv6 address ranges
or symbolic names. The IP version of the allowed use identities does not have
to be the same as that of wildcards for
selector values and because the different types IP version of selectors are not
hierarchically related. the peer representing
them. The processing model described in this document assumes fundamental requirement associated with the PAD is that
the traffic selectors passed by the SA management protocol for
comparison against the ability
to decorrelate overlapping SPD entries MUST be verified as authorized relative
to permit caching, which
enables more efficient processing the authenticated peer of outbound traffic the SA management protocol. (See also
Section 4.5.3, which levies requirements on the PAD in security
gateways and BITS/BITW implementations. (Native host implementations
have an implicit form support of caching available, due
locating security gateways.)

The PAD also specifies how to the authenticate each peer, e.g., via
shared secret or use of, for
example, socket interfaces for applications, and thus there of a certificate. If a shared secret is no
requirement to be able to decorrelate SPD entries in these
implementations.) Decorrelation used,
the secret is stored here. If a means of improving performance
and simplifying the processing description; it certificate is not a requirement used, the trust
anchor for a compliant implementation.

Appendix B provides an algorithm that can be used to decorrelate SPD
entries, but any algorithm that produces equivalent output may be
used. Note that when an SPD entry is decorrelated all the resulting
entries MUST be grouped together, so that all members certificate is part of the group
derived from an individual, SPD entry (prior to decorrelation) can
all PAD. Because the PAD
might be placed into caches and incorporated into the SAD at the same time. The
intent SA management protocol
implementation, it is that use of a decorrelated SPD ought not create more SAs
than would discussed extensively in this document.

Multiple Separate IPsec Contexts

If an IPsec implementation acts as a security gateway for multiple
subscribers, it MAY implement multiple separate IPsec contexts.
Each context MAY have resulted from and use of a not-decorrelated SPD. completely independent identities,
policies, key management SAs, and/or IPsec SAs. This is for the

Kent & Seo [Page 16] 17]

Internet Draft Security Architecture for IP January April 2004

An SPD must discriminate among traffic that is afforded IPsec
protection and traffic that

most part a local implementation matter. However, a means for
associating inbound (SA) proposals with local contexts is allowed to bypass IPsec. This applies
to
required. To this end, if supported by the IPsec protection to key management
protocol in use, context identifiers MAY be applied by a sender and conveyed from
initiator to responder in the IPsec
protection that must be present at signaling messages, with the receiver. For any outbound or
inbound datagram, three processing choices result
that IPsec SAs are possible: discard,
bypass IPsec, or apply IPsec. The first choice refers created with a binding to traffic a particular context.
For example, a security gateway that is not allowed provides VPN service to traverse the IPsec boundary (in the specified
direction). The second choice refers
multiple customers will be able to associate each customer~Os
traffic that is allowed to
pass without additional IPsec protection. with the correct VPN.

Forwarding vs Security Decisions

The third choice refers to
traffic that is afforded IPsec protection, model described here embodies a clear separation between
forwarding (routing) and for such traffic the
SPD must specify the security protocols to be employed, their mode, security service options, and the cryptographic algorithms decisions, to be
used. An SPD is logically divided into three pieces, all accommodate a wide
range of which
should be decorrelated (with the exception noted above for native
host implementations) to facilitate caching. The SPD-S (secure
traffic) contains entries for all traffic subject to contexts where IPsec
protection. SPD-O (outbound) contains entries for all outbound
traffic that is to may be bypassed or discarded. SPD-I (inbound) is
applied to inbound traffic that will employed. Forwarding may be bypassed or discarded. If an
IPsec implementation supports only one SPD, then
trivial, in the SPD consists of
all three parts. If multiple SPDs case where there are supported, some of them only two interfaces, or it
may be
partial, complex, e.g., some SPDs might contain if there are multiple protected or
unprotected interfaces or if the context in which IPsec is
implemented employs a sophisticated forwarding function. IPsec
assumes only SPD-I entries, to control that outbound and inbound bypassed traffic on that has passed
through IPsec processing is forwarded in a per-interface basis. The split allows
SPD-I to be consulted without having to consult SPD-S, for such
traffic. Since fashion consistent with
the SPD-I context in which IPsec is just a part of the SPD, the same rule
applies here, i.e., implemented. Support for nested SAs
is optional; if required, it requires coordination between
forwarding tables and SPD entries to cause a packet that is looked up in to traverse
the SPD-I cannot
be matched IPsec boundary more than once.

Local" vs "Remote"

In this document, with respect to an entry there, then IP addresses and ports, the packet MUST be discarded.
Note that
terms "Local" and "Remote" are used for outbound traffic, if a match is not found in SPD-S,
then SPD-O must be checked policy rules. "Local"
refers to see if the traffic should be bypassed.
Similarly, if SPD-O is checked first and no match is found, then SPD-
S must be checked.

For every entity being protected by an IPsec implementation, there MUST be a management interface
that allows a user or system administrator to manage
i.e., the SPD. The
interface must allow "source" address/port of outbound packets or the user (or administrator)
"destination" address/port of inbound packets. "Remote" refers to specify
a peer entity or peer entities. The terms "source" and
"destination" are used for packet header fields.

"Non-initial" vs "Initial" Fragments

Throughout this document, the
security processing to be applied phrase "non-initial" fragments is
used to every packet mean fragments that traverses the
IPsec boundary. (In a native host IPsec implementation making use do not contain all of
a socket interface, the SPD selector
values that may not need to be consulted on a per
packet basis, as noted above.) The management interface needed for the SPD
MUST allow creation of entries consistent with the selectors defined
in Section 4.4.2, access control (e.g., they might not
contain Next Layer Protocol, source and MUST support (total) ordering of these entries,
as seen via this interface. The SPD entries' selectors are analogous
to destination ports, ICMP
message type/code, Mobility Header type). And the ACL or packet filters commonly found in phrase "initial"
fragment is used to mean a stateless firewall
or packet filtering router and which are currently managed this way.

In host systems, applications MAY fragment that contains all the selector
values needed for access control. However, it should be allowed to create SPD entries.
(The means of signaling such requests to noted that
for IPv6, which fragment contains the IPsec implementation are
outside Next Layer Protocol and
ports (or ICMP message type/code or Mobility Header type) will
depend on the scope kind and number of this standard.) However, the system extension headers present. The

Kent & Seo [Page 17] 18]

Internet Draft Security Architecture for IP January April 2004

administrator MUST be able to specify whether or

"initial" fragment might not be the first fragment.

4.4.1 The Security Policy Database (SPD)

A security association is a user or
application can override (default) system policies. management construct used to enforce
security policy for traffic crossing the IPsec boundary. Thus an
essential element of SA processing is an underlying Security Policy
Database (SPD) that specifies what services are to be offered to IP
datagrams and in what fashion. The form of the
management interface is not specified by this document and may differ
for hosts vs. security gateways, database and within hosts the its
interface may
differ for socket-based vs. BITS implementations. are outside the scope of this specification. However, this
document does specify a standard set of SPD elements that all IPsec
implementations MUST support.

Each SPD entry
section specifies packet disposition as BYPASS, DISCARD, or
IPsec. The entry is keyed by a list of one or more selectors. The SPD
contains an ordered list of these entries. The required selector
types are defined in Section 4.4.2. These selectors are used to
define the granularity of the SAs minimum management functionality that are created in response to an
outbound packet or in response must be
provided, to a proposal from a peer.

The SPD MUST permit allow a user or system administrator to specify policy entries
as follows:
- SPD-I: For inbound traffic that control whether
and how IPsec is applied to be bypassed or discarded,
the entry consists of the values of the selectors that apply to
the traffic to be bypassed transmitted or discarded.
- SPD-O: For outbound traffic that is to be bypassed received by a host
or discarded,
the entry consists of transiting a security gateway. The SPD, or relevant caches, must
be consulted during the values processing of the selectors that apply to
the ALL traffic to be bypassed or discarded.
- SPD-S: For (inbound and
outbound), including traffic that is to be not protected using by IPsec, the entry
consists of the values of the selectors that apply to traverses
the IPsec boundary. This includes IPsec management traffic
that the initiator will send or receive such as
IKE. An IPsec implementation MUST have at least one SPD, and it MAY
support multiple SPDs, if appropriate for the values that apply
to the traffic that the responder will receive or send.
- The selector types are defined in Section 4.2.2 below.

For each selector in an SPD entry, context in addition to which the literal values
that define a match, there are two special values: ANY and OPAQUE.
The former value is a wildcard that matches any value in the
corresponding field of the packet, whereas the latter value indicates
that the corresponding selector field
IPsec implementation operates. There is not examined, e.g., because
it may be obscured by encryption already applied no requirement to the packet or may
not be present in maintain
SPDs on a fragment.

For each selector per interface basis, as was specified in RFC 2401. However,
if an implementation supports multiple SPDs, then it MUST include an
explicit SPD entry, the policy entry specifies how selection function, that is invoked to
derive select the corresponding values
appropriate SPD for a new Security Association
Database (SAD, see Section 4.4.3) entry from those in outbound traffic processing. The inputs to this
function are the SPD outbound packet and any local metadata (e.g., the
packet.
interface via which the packet arrived) required to effect the SPD
selection function. The goal output of the function is to allow an SAD entry and an SPD cache entry to
be created based on specific selector values from the packet, or from
the matching ID.

The SPD entry. If IPsec processing is specified for an
entry, a "populate from packet" (PFP) flag may be asserted for one or
more of the selector types in the SPD entry. If present, ordered database, consistent with the flag
applies to all selectors use of the indicated type ACLs or
packet filters in firewalls, routers, etc. The ordering requirement
arises because entries often will overlap due to the outbound
element presence of the pair. (PFP does not apply to inbound traffic.)

Kent & Seo [Page 18]

Internet Draft Security Architecture
(non-trivial) ranges as values for IP January 2004

Note that this text describes the representation in the SPD that maps
into IKE payloads, i.e., one should not create SPD entries that
cannot selectors. Thus a user or
administrator MUST be mapped into what IKE can negotiate. The management GUI can
offer able to order the user other forms entries to express a desired
access control policy. There is no way to impose a general, canonical
order on SPD entries, because of data entry and display, e.g., the
option allowed use of using address prefixes as well as ranges, and symbolic
names wildcards for protocols, ports, etc. (Do not confuse
selector values and because the use different types of symbolic
names in a management interface with the selectors are not
hierarchically related.

Processing Choices --> DISCARD, BYPASS, PROTECT

An SPD selector "name".) If
the reserved, symbolic selector value OPAQUE or ANY must discriminate among traffic that is employed for afforded IPsec
protection and traffic that is allowed to bypass IPsec. This
applies to the IPsec protection to be applied by a
given selector type, only it may appear in sender and to
the list for IPsec protection that type,
and it must appear only once in be present at the list receiver. For
any outbound or inbound datagram, three processing choices are
possible: DISCARD, BYPASS IPsec, or PROTECT using IPsec. The

Kent & Seo [Page 19]

Internet Draft Security Architecture for IP April 2004

first choice refers to traffic that type. Note that
"ANY" is a local syntax convention - IKE handles this concept via
ranges.

The following example illustrates the use of not allowed to traverse the PFP flag in
IPsec boundary (in the
context of a security gateway or a BITS/BITW implementation. Consider
an SPD entry where the allowed value for destination address is a
range of IPv4 addresses: 192.168.2.1 specified direction). The second choice
refers to 192.168.2.10. Suppose an
outbound packet arrives with a destination address of 192.168.2.3,
and there traffic that is no extant SA allowed to carry this packet. The value used for cross the SA created IPsec boundary
without IPsec protection. The third choice refers to transmit this packet could be either of the two
values shown below, depending on what the SPD entry for this selector
says traffic that
is the source of the selector value:

source afforded IPsec protection, and for such traffic the example of new
value SPD must
specify the security protocols to be SAD destination address
used in employed, their mode,
security service options, and the SA selector value
--------------- ------------
a. PFP TRUE 192.168.2.3 (one host)
b. PFP FALSE 192.168.2.1 cryptographic algorithms to 192.168.2.10 (range of hosts)

Note that if the be
used.

SPD-S, SPD-I, SPD-O

An SPD entry had a value of ANY is logically divided into three pieces. The SPD-S (secure
traffic) contains entries for the destination
address, then the SAD selector value would have all traffic subject to be ANY for case
(b), but would still be as illustrated IPsec
protection. SPD-O (outbound) contains entries for case (a). Thus the PFP
flag can all outbound
traffic that is to be used bypassed or discarded. SPD-I (inbound) is
applied to prohibit sharing of an SA, even among packets inbound traffic that match the same SPD entry.

4.4.2 Selectors

An SA may will be fine-grained bypassed or coarse-grained, depending on the
selectors used to define the set discarded. All
three of traffic these can be decorrelated (with the exception noted above
for native host implementations) to facilitate caching. If an
IPsec implementation supports only one SPD, then the SA. For example, SPD consists
of all traffic between two hosts three parts. If multiple SPDs are supported, some of them
may be carried via a single SA, and
afforded a uniform set of security services. Alternatively, partial, e.g., some SPDs might contain only SPD-I entries,
to control inbound bypassed traffic
between on a pair of hosts might per-interface basis. The
split allows SPD-I to be spread over multiple SAs, depending
on the applications being used (as defined by consulted without having to consult SPD-
S, for such traffic. Since the Next Protocol and
Port fields), with different security services offered by different
SAs. Similarly, all traffic between SPD-I is just a pair part of security gateways could
be carried on the SPD,
the same rule applies here, i.e., if a single SA, or one SA could packet that is looked up in
the SPD-I cannot be assigned for each

Kent & Seo [Page 19]

Internet Draft Security Architecture for IP January 2004

communicating host pair. The following selector parameters matched to an entry there, then the packet
MUST be
supported by all IPsec implementations to facilitate control of SA
granularity. discarded. Note that both Source and Destination addresses should
either be IPv4 or IPv6, but not for outbound traffic, if a mix of address types. Also, note
that the source/destination port selectors may match is
not found in SPD-S, then SPD-O must be labeled as "OPAQUE"
to accommodate situations where these fields are inaccessible because
of prior encryption or due checked to see if the
traffic should be bypassed. Similarly, if SPD-O is checked first
and no match is found, then SPD-S must be checked.

SPD entries

Each SPD entry specifies packet fragmentation.

- Destination IP Address (IPv4 disposition as BYPASS, DISCARD, or IPv6): this
PROTECT. The entry is keyed by a list of ranges
of IP addresses (unicast, anycast, broadcast (IPv4 only), or
multicast group). This structure allows expression of a single
IP address (via a trivial range), or a list of addresses (each a
trivial ranges), one or a range of addresses (high and low values,
inclusive), as well as the most generic form of a more selectors.
The SPD contains an ordered list of
ranges. Address ranges these entries. The required
selector types are defined in Section 4.4.1.1. These selectors are
used to support more than one
destination system sharing define the same SA, e.g., behind a security
gateway.

- Source IP Address(es) (IPv4 or IPv6): this is a list of ranges granularity of IP addresses (unicast, anycast, broadcast (IPv4 only), the SAs that are created in
response to an outbound packet or
multicast group). This structure allows expression of a single
IP address (via in response to a trivial range), or proposal from a list
peer. The detailed structure of addresses (each a
trivial ranges), or an SPD entry is described in
Section 4.4.1.2. Every SPD SHOULD have a range of addresses (high nominal, final entry that
matches anything that is otherwise unmatched, and low values,
inclusive), as well as the most generic form of discards it.

The SPD MUST permit a list of
ranges. Address ranges are used user or administrator to support more than one source
system sharing the same SA, e.g., behind a security gateway. specify policy
entries as follows:

- Next Layer Protocol: Obtained from the IPv4 "Protocol" or the
IPv6 "Next Header" fields. This is an individual protocol
number, or ANY. The Next Layer Protocol is whatever comes after
any IP extension headers SPD-I: For inbound traffic that are present. To simplify locating
the Next Layer Protocol in the IPv6 context, there SHOULD be a
mechanism for configuring which IP extension headers to skip,
e.g., Destination Options, Routing Header, Fragmentation Header,
Mobility Header, Hop-by-hop options, etc.

Several additional selectors depend on the Next Layer Protocol
value:

* If the Next Layer Protocol uses ports (e.g., TCP, UDP, SCTP,
...), then there are selectors for Source and Destination
Ports: Each of these selectors is a list of ranges of
values. Note that the source and destination ports may not to be available in bypassed or discarded,
the case of receipt of a fragmented packet,
thus a value entry consists of "OPAQUE" also MUST be supported. Note: In a
non-initial fragment, port the values will not be available. If of the SA requires a non-OPAQUE port value, an arriving
fragment MUST be discarded. selectors that apply to

Kent & Seo [Page 20]

Internet Draft Security Architecture for IP January April 2004

* If

the Next Layer Protocol is a Mobility Header, then there
is a selector for IPv6 Mobility Header Message Type (MH
type) [Mobip]. This is an 8-bit value traffic to be bypassed or discarded.

- SPD-O: For outbound traffic that identifies a
particular mobility message.

* If the Next Layer Protocol value is ICMP then there are
selectors for to be bypassed or discarded,
the ICMP message type and code. The message
type is a single 8-bit value, which defines entry consists of the type values of an
ICMP message, or ANY. The ICMP code is single 8-bit value the selectors that defines a specific subtype for an ICMP message. This
selector can apply to
the traffic to be a single value, bypassed or ANY. discarded.

- Name: A name SPD-S: For traffic that is used as a symbolic identifier for an IPsec
source or destination address. Thus an SPD to be protected using IPsec, the entry
consists of the values of the selectors that has a non-
null Name selector MUST set either apply to the source traffic
to be protected via AH or destination IP
address selector ESP, controls on how to NULL in the corresponding, directional SPD
entry.

a. an RFC 822 address, e.g., mozart@foo.example.com
b. X.500 distinguished name
c. a fully qualified DNS name, e.g., foo.example.com

Use of this selector is different from all create SAs based
on these selectors, and the other selectors
described above. Names do not appear in packets, so it is not
possible parameters needed to match a packet against effect this
protection (e.g., algorithms, modes, etc.). Note that an SPD SPD-S
entry based also contains information such as "populate from packet"
(PFP) flag (see paragraphs below on a Name
selector. Name selectors are used to trigger creation "How To Derive the Values for
an SAD entry") and bits indicating whether the SA lookup makes use
of SPD cache
(SPD-S the local and SPD-O) (and SAD) entries, which are then populated with
specific remote IP source or destination addresses provided by the SA
management protocol. For a native host implementation, a Name may be
used in an SPD entry addition to provide finer granularity access control that
would be otherwise be available on multi-user systems. In this case, the SPI (see
AH [Ken04b] or ESP [Ken04a] specifications).

Representing directionality in an SPD entry may be consulted when SA creation is initiated

For traffic protected by IPsec, the host,
or when the host is a responder. The Name refers to Local and Remote address and
ports in an entity at SPD entry are swapped to represent directionality,
consistent with IKE conventions. In general, the
host in question, and protocols that
IPsec deals with have the implementation relies on its integration
into property of requiring symmetric SAs with
flipped Local/Remote IP addresses. However, for ICMP, there is
often no such bi-directional authorization requirement.
Nonetheless, for the host OS to ensure appropriate linking to sake of uniformity and simplicity, SPD
entries for ICMP are specified in the named entity's
process. The same way as for other use
protocols. Note also that for ICMP, Mobility Header, and non-
initial fragments, there are no port fields in these packets. ICMP
has message type and code and Mobility Header has mobility header
type. Thus SPD entries have provisions for expressing access
controls appropriate for these protocols, in lieu of the Name selector occurs when any IPsec
implementation (native host, BITW, BITS, normal
port field controls. For bypassed or security gateway) is
contacted by a peer whose address cannot be known a priori, discarded traffic, separate
inbound and outbound entries are supported, e.g., a
road warrior. In this context, to permit
unidirectional flows if required.

OPAQUE and ANY

For each selector in an SPD entry, in addition to the Name literal
values that define a match, there are two special values: ANY and
OPAQUE. ANY is used a wildcard that matches any value in lieu of the IP
address
corresponding field of the peer, who must be an initiator of packet, or that matches packets where
that field is not present or is obscured. OPAQUE indicates that
the SA creation.

[This corresponding selector description field is not available for examination
because it may change based on discussion of some
name/identity issues that haven't yet been posted to the list.]

The IPsec implementation context determines how selectors are used.
For example, a native host implementation typically makes use of a
socket interface. When not be present in a new connection is established fragment or does not exist for
the SPD can
be consulted and an SA bound to given Next Layer Protocol. ANY includes OPAQUE.

How To Derive the socket. Thus traffic sent via Values for an SAD entry

Kent & Seo [Page 21]

Internet Draft Security Architecture for IP January April 2004

that socket need not result

For each selector in additional lookups an SPD entry, the entry specifies how to
derive the corresponding values for a new Security Association
Database (SAD, see Section 4.4.2) entry from those in the SPD (SPD-O and SPD-S) cache. In contrast, a BITS, BITW, or security gateway
implementation needs
the packet. The goal is to look at each packet allow an SAD entry and perform an SPD/SPD-S SPD cache lookup
entry to be created based on specific selector values from the selectors.

4.4.3 Security Association Database (SAD)

In each
packet, or from the matching SPD entry. If IPsec implementation there processing is
specified for an entry, a nominal Security Association
Database, in which each entry defines the parameters associated with "populate from packet" (PFP) flag may be
asserted for one SA. Each SA has an entry in or more of the SAD. For outbound processing,
entries are pointed to by entries selectors in the SPD-S part of the SPD cache.
For inbound processing, each entry in the SAD is indexed by an SPI
(from the AH (Local
IP address, Remote IP address, Next Layer Protocol, and depending
on Next Layer Protocol -- Local port, ICMP type/code or ESP protocol header), plus source and/or destination
address Mobility
Header type; Remote port). If asserted for multicast SAs, as noted earlier. The following parameters
are associated with each entry in a given selector, the SAD. They should all be
present except where otherwise noted, e.g., AH Authentication
algorithm. This description does not purport
flag indicates that the SA to be a MIB, only a
specification of created should take its value for
that selector from the minimal data items required to support an SA value in
an IPsec implementation.

For each of the selectors defined in Section 4.4.2, packet. Otherwise, the entry for an
inbound SA
should take its value(s) for that selector from the value(s) in
the SAD MUST contain SPD entry. Note: In the value or non-PFP case, the selector values
negotiated at
the time by the SA was created. For management protocol (e.g., IKEv2) may be a receiver, these values are used to
check that the header fields
subset of an inbound packet match the selector
values negotiated for the SA. For those in the receiver, this is part of
verifying that a packet arriving SPD entry, depending on an SA is consistent with the SPD policy for of
the SA. (See Section 6 for rules for peer. Also, whether a single flag is used for, e.g., source
port, ICMP messages.)
These fields can have the form of specific values, ranges, ANY, type/code, and MH type, or
"OPAQUE" as described in section 4.4.2, "Selectors." a separate flag is used for
each, is a local matter.

The following data items MUST be example illustrates the use of the PFP flag in the SAD:

o Security Parameter Index (SPI): a 32-bit value selected by the
receiving end
context of a security gateway or a BITS/BITW implementation.
Consider an SA to uniquely identify the SA. In an SAD SPD entry where the allowed value for Remote address
is a range of IPv4 addresses: 192.168.2.1 to 192.168.2.10. Suppose
an outbound SA, the SPI packet arrives with a destination address of
192.168.2.3, and there is used no extant SA to construct the
packet's AH or ESP header. In an SAD entry carry this packet. The
value used for an inbound SA, the
SPI is used to map traffic SA created to transmit this packet could be
either of the appropriate SA (see text two values shown below, depending on
unicast/multicast in Section 4.1).

o Sequence Number Counter: a 64-bit or 32-bit value used to generate what the Sequence Number field in AH or ESP headers. 64-bit sequence
numbers are SPD
entry for this selector says is the default, but 32-bit sequence numbers are also
supported if negotiated.

o Sequence Counter Overflow: a source of the selector value:

PFP flag indicating whether overflow value example of new
for the Sequence Number Counter should generate an auditable event and
prevent transmission Remote SAD dest. address
addr. selector selector value
--------------- ------------
a. PFP TRUE 192.168.2.3 (one host)
b. PFP FALSE 192.168.2.1 to 192.168.2.10 (range of additional packets on hosts)

Note that if the SA, or whether

Kent & Seo [Page 22]

Internet Draft Security Architecture for IP January 2004

rollover is permitted. The audit log SPD entry above had a value of ANY for this event SHOULD
include the SPI value, current date/time, Source Address,
Destination Address, and the selectors from Remote
address, then the relevant SAD
entry.

o Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent)
used selector value would have to determine whether an inbound AH or ESP packet is a replay.

NOTE: If anti-replay has been disabled by the receiver be ANY for case
(b), but would still be as illustrated for case (a). Thus the PFP
flag can be used to prohibit sharing of an SA,
e.g., in even among packets
that match the case of same SPD entry.

Management Interface

For every IPsec implementation, there MUST be a manually keyed SA, then management
interface that allows a user or system administrator to manage the Anti-Replay
Window is ignored

Kent & Seo [Page 22]

Internet Draft Security Architecture for IP April 2004

SPD. The interface must allow the SA in question. 64-bit sequence numbers
are the default, but this counter size accommodates 32-bit
sequence numbers.

o AH Authentication algorithm, key, etc. This is required only if AH
is supported.

o ESP Encryption algorithm, key, mode, IV, etc.

o ESP integrity algorithm, keys, etc. If user (or administrator) to
specify the integrity service is
not selected, these fields will security processing to be null.

o ESP combined mode algorithms, key(s), etc. This data is used when applied to every packet that
traverses the IPsec boundary. (In a combined mode (encryption and integrity) algorithm is used with
ESP.

o Lifetime native host IPsec
implementation making use 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 socket interface, the SPD may not
need to be expressed as a time or byte count, or a simultaneous use of
both with the first lifetime to expire taking precedence. A
compliant implementation MUST support both types of lifetimes, and
must support consulted on a simultaneous use of both. If time is employed, and
if IKE employs X.509 certificates per packet basis, as noted above.) The
management interface for SA establishment, the SA
lifetime must be constrained by the validity intervals SPD MUST allow creation of entries
consistent with the
certificates, selectors defined in Section 4.4.1.1, and the NextIssueDate MUST
support (total) ordering of these entries, as seen via this
interface. The SPD entries' selectors are analogous to the CRLs used ACL or
packet filters commonly found in the IKE
exchange for the SA. Both initiator a stateless firewall or packet
filtering router and responder which are responsible
for constraining SA lifetime in currently managed this fashion. NOTE: The details
of how way.

In host systems, applications MAY be allowed to handle the refreshing create SPD
entries. (The means of keys when SAs expire is a local
matter. However, one reasonable approach is:

(a) If byte count is used, then signaling such requests to the IPsec
implementation SHOULD count are outside the
number scope of bytes this standard.) However,
the system administrator MUST be able to which specify whether or not a
user or application can override (default) system policies. The
form of the IPsec cryptographic algorithm management interface is
applied. For ESP, not specified by this is the encryption algorithm (including
Null encryption) document
and may differ for AH, this is hosts vs. security gateways, and within hosts
the authentication
algorithm. This includes pad bytes, etc. Note that
implementations SHOULD 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.

Decorrelation

The processing model described in this document assumes the
ability to decorrelate overlapping SPD entries to permit caching,
which enables more efficient processing of outbound traffic in
security gateways and BITS/BITW implementations. (Native host
implementations have an implicit form of caching available, due to
the use of, for example, socket interfaces for applications, and
thus there is no requirement to be able to handle having decorrelate SPD entries
in these implementations.)

Note: Decorrelation is a means of improving performance and
simplifying the counters at processing description; it is not a requirement
for a compliant implementation. In this section, unless otherwise
noted, the ends use of an SA get out "SPD" refers to the body of synch, e.g., because policy information
in both ordered or decorrelated (unordered) state.

Appendix B provides an algorithm that can be used to decorrelate
SPD entries, but any algorithm that produces equivalent output may
be used. Note that when an SPD entry is decorrelated all the
resulting entries MUST be linked together, so that all members of packet
the group derived from an individual, SPD entry (prior to
decorrelation) can all be placed into caches and into the SAD at
the same time. For example, suppose one starts with an entry A
(from an ordered SPD) that when decorrelated, yields entries A1,

Kent & Seo [Page 23]

Internet Draft Security Architecture for IP January April 2004

loss or because

A2 and A3. When a packet comes along that matches, say A2, and
triggers the implementations at each end creation of an SA, the SA
aren't doing things the same way.

(b) There SHOULD be two kinds of lifetime -- a soft lifetime that
warns the implementation to initiate action such as setting up
a replacement SA; management protocol, e.g.,
IKEv2, negotiates A. And all 3 decorrelated entries, A1, A2, and a hard lifetime when
A3 are placed in the current SA ends appropriate SPD-S cache and is destroyed.

(c) If linked to the entire packet does SA.
The intent is that use of a decorrelated SPD ought not get delivered during the create more
SAs
lifetime, the packet SHOULD be discarded.

o IPsec protocol mode: tunnel or transport. Indicates which mode than would have resulted from use of
AH or ESP a not-decorrelated SPD.
Note also that if a decorrelated SPD is applied to traffic on this SA.

o Path MTU: any observed path MTU and aging variables. See Section
6.1.2.4

o Tunnel header IP source and destination address - both addresses
must employed, the original
entry from the (correlated) SPD should be either IPv4 or IPv6 addresses. The version implies retained and passed to
the
type of IP header SA management protocol, e.g., IKE. Passing the correlated SPD
entry to be used. Only used when the IPsec SA management protocol
mode is tunnel.

The following table summarizes keeps the kinds use of entries that one needs to
be able a
decorrelated SPD a local matter, not visible to express in peers. When acting
as a responder, the peer uses a correlated SPD entry for matching,
and SAD. It also shows how they relate for issuing a "narrowed" response. Then the decorrelated
entries are used to populate the fields in data traffic being subjected SPD-S cache.

Handling Changes to IPsec screening.

[Table the SPD while the System is Running

If a change is made to be added in the SPD while the system is running, a future draft.]

4.5 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
check SHOULD be made of the associated SA management techniques,
although the techniques involved do affect some of this change on extant SAs.
This document does not impose a requirement to do this, but an
implementation MAY choose to check the security
services offered by the protocols. For example, the optional anti-
replay service available for AH impact of an SPD change on
extant SAs and ESP requires automated to provide a user/administrator with a mechanism
for configuring what actions to take, e.g., delete an affected SA,
allow an affected SA
management. Moreover, to continue unchanged, etc.

4.4.1.1 Selectors

An SA may be fine-grained or coarse-grained, depending on the granularity of key distribution employed
with IPsec determines
selectors used to define the granularity set of authentication provided. In
general, data origin authentication in AH traffic for the SA. For example,
all traffic between two hosts may be carried via a single SA, and ESP is limited by
afforded a uniform set of security services. Alternatively, traffic
between a pair of hosts might be spread over multiple SAs, depending
on the
extent to which secrets applications being used with (as defined by the integrity algorithm (or Next Layer Protocol
and related fields, e.g., ports), with different security services
offered by different SAs. Similarly, all traffic between a
key management protocol that creates such secrets) are shared among
multiple possible sources.

The following text describes the minimum requirements for both types pair of
security gateways could be carried on a single SA, or one SA management.

Kent & Seo [Page 24]

Internet Draft Security Architecture could be
assigned for IP January 2004

4.5.1 Manual Techniques each communicating host pair. The simplest form following selector
parameters MUST be supported by all IPsec implementations to
facilitate control of management is manual management, in which a
person manually configures each system with keying material SA granularity. Note that both Local and
security association management data relevant to secure communication
with other systems. Manual techniques are practical in small, static
environments Remote
addresses should either be IPv4 or IPv6, 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 mix of a single administrative
domain, this might be a feasible context for manual management
techniques. In this case, address
types. Also, note that the security gateway might selectively
protect traffic to Local/Remote port selectors (and ICMP
message type and from other sites within the organization using
a manually configured key, while not protecting traffic for other
destinations. It also might code, and Mobility Header type) may be appropriate when only selected
communications need labeled as
OPAQUE to be secured. A similar argument might apply accommodate situations where these fields are inaccessible
due to
use packet fragmentation.

- Remote IP Address(es) (IPv4 or IPv6): this is a list of IPsec entirely within an organization ranges
of IP addresses (unicast, anycast, broadcast (IPv4 only), or

Kent & Seo [Page 24]

Internet Draft Security Architecture for IP April 2004

multicast group). This structure allows expression of a small number single
IP address (via a trivial range), or a list of
hosts and/or gateways. Manual management techniques often employ
statically configured, symmetric keys, though other options also
exist.

4.5.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 addresses (each a
trivial ranges), or a range of addresses (low and high values,
inclusive), as well as the anti-replay features most generic form of AH and ESP, and to
accommodate on-demand creation a list of SAs, e.g., for user- and session-
oriented keying. (Note that
ranges. Address ranges are used to support more than one
destination system sharing the notion same SA, e.g., behind a security
gateway.

- Local IP Address(es) (IPv4 or IPv6): this is a list of "rekeying" an SA actually
implies creation ranges of
IP addresses (unicast, anycast, broadcast (IPv4 only), or
multicast group). This structure allows expression of a new SA with single
IP address (via a new SPI, trivial range), or a process that generally
implies use list of an automated SA/key management protocol.)

The default automated key management protocol selected for use with
IPsec is IKEv2 [Kau04]. Other automated SA management protocols MAY
be employed.

When an automated SA/key management protocol is employed, the output
from this protocol is used to generate multiple keys for addresses (each a single SA.
This also occurs because distinct keys are used for each
trivial ranges), or a range of the two
SAs created by IKE. If both integrity addresses (low and confidentiality are
employed, then high values,
inclusive), as well as the most generic form of a minimum list of four keys
ranges. Address ranges are required. Additionally,
some cryptographic algorithms may require multiple keys, e.g., 3DES.

The Key Management System may provide a separate string of bits for
each key or it may generate used to support more than one string of bits from which all keys
are extracted. If source
system sharing the same SA, e.g., behind a single string of bits is provided, care needs to
be taken security gateway.
Local refers to ensure that the parts of the system that map address(es) being protected by this
implementation (or policy entry).

- Next Layer Protocol: Obtained from the string
of bits to IPv4 "Protocol" or the required keys do so in
IPv6 "Next Header" fields. This is an individual protocol
number, or ANY. The Next Layer Protocol is whatever comes after
any IP extension headers that are present. To simplify locating
the same fashion at both ends

Kent & Seo [Page 25]

Internet Draft Security Architecture Next Layer Protocol, there SHOULD be a mechanism for
configuring which IP January 2004

of the SA. To ensure that extension headers to skip. The default
configuration for which protocols to skip SHOULD include the IPsec implementations at each end
following protocols: 0 (Hop-by-hop options), 43 (Routing
Header), 44 (Fragmentation Header), and 60 (Destination
Options). Note: The default list does NOT include 51 (AH), or
50 (ESP). From a selector lookup point of view, IPsec treats AH
and ESP as Next Layer Protocols.

Several additional selectors depend on the SA use the same bits for Next Layer Protocol
value:

* If the same keys, and irrespective Next Layer Protocol uses two ports (e.g., TCP, UDP, SCTP,
these selectors is a list of which
part ranges of values. Note that the system divides
Local and Remote ports may not be available in the string case of bits into individual keys,
the encryption keys
receipt of a fragmented packet, thus a value of OPAQUE also MUST
be taken from the first (left-most, high-
order) bits and supported. Note: In a non-initial fragment, port values will
not be available. If a port selector specifies a value other than
ANY or OPAQUE, it cannot match packets that are non-initial
fragments. If the integrity keys SA requires a port value other than ANY or
OPAQUE, an arriving fragment without ports MUST be taken from discarded.

* If the remaining
bits. The number of bits Next Layer Protocol is a Mobility Header, then there is a
selector for each key IPv6 Mobility Header Message Type (MH type) [Mobip].
This is defined in an 8-bit value that identifies a particular mobility

Kent & Seo [Page 25]

Internet Draft Security Architecture for IP April 2004

message. Note that the relevant
cryptographic algorithm specification RFC. In MH type may not be available in the case
of multiple
encryption keys or multiple integrity keys, receipt of a fragmented packet, thus a value of OPAQUE MUST be
supported.

* If the specification Next Layer Protocol value is ICMP then there is a 16-bit
selector for the
cryptographic algorithm must specify the order in which they are to
be selected from ICMP message type and code. The message type is
a single string of bits provided to 8-bit value, which defines the
cryptographic algorithm.

4.5.3 Locating type of an ICMP message,
or ANY. The ICMP code is a Security Gateway

This section discusses issues relating to how single 8-bit value that defines a host learns about
specific subtype for an ICMP message. The message type is placed
in the
existence most significant 8 bits 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 16-bit selector and the required information is
stored
code is a local matter, but the Peer Authorization database
described placed in Section 4.4 is the most likely candidate.

Consider least significant 8 bits. This 16-bit
selector can contain a situation in which single type and a remote host (H1) is using the
Internet to gain access to range of codes, a server or other machine (H2) single
type and there
is ANY code, ANY type and ANY code. Given a security gateway (SG2), e.g., policy entry
with a firewall, through which H1's
traffic must pass. An example range of this situation would be a mobile
host (road warrior) crossing the Internet Types (T-start to his home organization's
firewall (SG2). This situation raises several issues:

1. How does H1 know/learn about the existence of the security gateway
SG2?

2. How does it authenticate SG2, T-end) and once it has authenticated SG2,
how does it confirm that SG2 has been authorized a range of Codes (C-
start to represent H2?

3. How does SG2 authenticate H1 C-end), and verify that H1 is authorized to
contact H2?

4. How does H1 know/learn about any additional gateways that provide
alternate paths to H2?

To address these problems, a host or security gateway MUST have an
administrative interface ICMP packet with Type t and Code c, an
implementation MUST test for a match using

(T-start*256) + C-start <= (t*256) + c <= (T-end*256) + C-end

Note that allows the user/administrator to
configure ICMP message type and code may not be available in
the address case of one or more security gateways for ranges receipt of
destination addresses that require its use. This includes a fragmented packet, thus a value of
OPAQUE MUST be supported.

- Name: A name may be used as a symbolic identifier for an IPsec
Local or Remote address. Named SPD entries are used in two ways:

1. A named SPD entry is used by a responder (not an initiator) in
support of access control when an IP address would not be
appropriate for the
ability Remote IP address selector, e.g., for "road
warriors." The name used to configure information match this field is communicated
during the IKE negotiation in the ID payload. In this context,
the initiator's Source IP address (inner IP header in tunnel
mode) is bound to the Remote IP address in the SAD entry created
by the IKE negotiation. This address overrides the Remote IP
address value in the SPD, when the SPD entry is selected in this
fashion. All IPsec implementations MUST support this use of
names.

2. A named SPD entry may be used by an initiator to identify a user
for locating and authenticating one
or more security gateways whom an IPsec SA will be created (or for whom traffic may be
bypassed). Support for this use is optional for multi-user,
native host implementations and verifying not applicable to other
implementations. Note that this name is used only locally; it is
not communicated by the authorization key management protocol.

An SPD entry can contain both a name (or a list of these
gateways to represent names) and
also values for the destination host. (The authorization Local or Remote IP address. If a name is
used in the IKE exchange, that name is matched against the SPD,

Kent & Seo [Page 26]

Internet Draft Security Architecture for IP January April 2004

function is implied in

rather than matching the PAD.) This document does not corresponding address in the
issue of how to automate the discovery/verification of security
gateways.

4.6 Security Associations SPD, and Multicast

The receiver-orientation of
the Security Association implies that, IP address in the case corresponding SAD entry is derived from
that of unicast traffic, the destination system will select named entity (Use initiator's source address as the
SPI value. By having
"Remote" address for case 1, and use the destination select user's source address
as the SPI value, there is
no potential "Local" address for manually configured Security Associations to
conflict with automatically configured (e.g., via case 2).

The identifiers employed in named SPD entries are one of the
following four types:

a. a key management
protocol) Security Associations or for Security Associations from
multiple sources fully qualified user name string (email), e.g.,
mozart@foo.example.com
(this corresponds to conflict with each other. For multicast traffic,
there are multiple destination systems associated with ID_RFC822_ADDR in IKEv2)

b. a single SA.
So some system or person will need fully qualified DNS name, e.g.,
foo.example.com
(this corresponds to coordinate among all multicast
groups ID_FQDN in IKEv2)

c. X.500 distinguished name, e.g.,
C = US, SP = MA,
O = BBN Technologies, CN = Stephen T. Kent
(this corresponds to select an SPI or SPIs on behalf ID_DER_ASN1_DN in IKEv2, after
decoding)

d. a byte string
(this corresponds to Key_ID in IKEv2)

The IPsec implementation context determines how selectors are used.
For example, a native host implementation typically makes use of each multicast group and
then communicate a
socket interface. When a new connection is established the group's IPsec information SPD can
be consulted and an SA bound to all of the
legitimate members of that multicast group socket. Thus traffic sent via mechanisms
that socket need not defined
here.

Multiple senders result in additional lookups to the SPD (SPD-O
and SPD-S) cache. In contrast, a multicast group SHOULD use a single Security
Association (and hence Security Parameter Index) for all traffic BITS, BITW, or security gateway
implementation needs to
that group when look at each packet and perform an SPD-O/SPD-
S cache lookup based on the selectors.

4.4.1.2 Structure of an SPD entry

This section contains a symmetric key encryption or integrity algorithm prose description of an SPD entry. Also, an
ASN.1 definition of an SPD entry is
employed. In such circumstances, the receiver knows only that provided in Appendix D.

This text describes the
message came from SPD in a system possessing the key for fashion that multicast
group. In such circumstances, a receiver generally will maps directly into IKE
payloads. One should not create SPD entries that cannot be able
to authenticate which system sent mapped
into something that IKE can negotiate. The management GUI can offer
the multicast traffic.
Specifications user other forms of data entry and display, e.g., the option of
using address prefixes as well as ranges, and symbolic names for other, more general multicast approaches are
deferred to
protocols, ports, etc. (Do not confuse the IETF's Multicast Security Working Group.

5. IP Traffic Processing

As mentioned use of symbolic names in Section 4.4.1 "The a

Kent & Seo [Page 27]

Internet Draft Security Policy Database (SPD)", Architecture for IP April 2004

management interface with the SPD (or associated caches) must be be consulted during the
processing of all traffic that crosses the IPsec boundary, including
IPsec management traffic. selector "Name".) If no policy the reserved,
symbolic selector value OPAQUE or ANY is found employed for a given
selector type, only it may appear in the SPD list for that
matches a packet (for either inbound or outbound traffic), the packet
MUST be discarded.

To simplify processing, selector, and to allow for very fast SA lookups (for
SG/BITS/BITW), this document introduces
it must appear only once in the notion of an SPD cache list for all outbound traffic (SPD-O plus SPD-S), that selector. Note that
ANY and a cache for inbound,
non-IPsec traffic (SPD-I). There is nominally one cache per SPD.
Since SPD entries may overlap, one cannot safely cache OPAQUE are local syntax conventions -D IKEv2 negotiates these entries
in general. Simple caching might result in a match against a cache
entry whereas
values via ranges. Also, Remote/Local only applies to ports, not to
ICMP message type/code or Mobility Header type.

ANY: start = 0 end = <max>
OPAQUE: start = <max> end = 0

An SPD is an ordered search list of entries each of which contains the SPD would have resulted in
following fields.
o Name -- a

Kent & Seo [Page 27]

Internet Draft Security Architecture list of IDs. This selector is optional.

o PFP flags -- one per traffic selector. A given flag, e.g.,
for IP January 2004

match against a different entry. But, if Next Layer Protocol, applies to the relevant selector
across all "selector sets" (see below) contained in an SPD entries are first
decorrelated, then the resulting entries can safely be cached, and
entry. When creating an SA, each cached entry will map flag specifies for the
corresponding traffic selector whether to an SA (or multiple SAs if "populate instantiate the
selector from packet" (PFP) is specified), or indicate the corresponding field in the packet that matching traffic
should be bypassed
triggered the creation of the SA or discarded, appropriately.

Note: In a host IPsec implementation based on sockets, from the value(s) in the
corresponding SPD will
be consulted whenever a new socket is created, to determine what, if
any, IPsec processing will be applied to entry (see Section 4.4.1, "How To Derive
the traffic that will flow
on that socket. This provides Values for an implicit caching mechanism and the
portions of the preceding discussion that address caching can be
ignored in such implementations.

Note: It is assumed that one starts with SAD entry"). Whether a correlated SPD, because
that single flag is how users used
for, e.g., source port, ICMP type/code, and administrators are accustomed to managing these
sorts of access control lists MH type, or firewall filter rules. Then the
decorrelation algorithm a
separate flag is applied, to allow caching of SPD entries.
The decorrelation used for each, is invisible at the management interface.

For inbound IPsec traffic, a local matter.
- Local Address
- Remote Address
- Next Layer Protocol
- Local Port, or ICMP message type/code or Mobility
Header type (depending on the SAD entry selected by next layer protocol)
- Remote Port, or ICMP message type/code or Mobility
Header type (depending on the SPI serves
as next layer protocol)

o One to N selector sets that correspond to the cache "condition"
for the selectors to be matched against arriving applying a particular IPsec
packets, after AH action. Each selector set
contains:
- Local Address
- Remote Address
- Next Layer Protocol
- Local Port, or ESP processing has been performed.

5.1 Outbound IP Traffic Processing (protected-to-unprotected)

First consider ICMP message type/code or Mobility
Header type (depending on the path for traffic entering next layer protocol)
- Remote Port, or ICMP message type/code or Mobility
Header type (depending on the implementation via next layer protocol)

o processing info -- which action is required -- PROTECT,
BYPASS, or DISCARD. There is just one action that goes with
all the selector sets, not a
protected interface and exiting via an unprotected interface. separate action for each set.

Kent & Seo [Page 28]

Internet Draft Security Architecture for IP January April 2004

Unprotected Interface
^
|
+----------+
...................|Forwarding|<-----+
: +----------+ |
: ^ |
: | Bypass |
: +-----+ |
+-------+ +-------+ | SPD | +--------+
| SPD-I | |Discard|<---|Cache|---->| AH/ESP |
+-------+ +-------+ +-----+ +--------+
: ^
: |
: +-------------+
:................>|SPD Selection|
+-------------+
^
|
Protected Interface

Figure 2. Processing Model for Outbound Traffic

IPsec MUST perform

If the following steps when required processing outbound
packets:

1. when a packet arrives from the subscriber (protected) interface,
invoke the SPD lookup function to select the appropriate SPD. (If
the implementation uses only one SPD, this step is a no-op.)

2. Match the packet headers against the cache for the SPD specified
by PROTECT, the SPD-ID from step 1. Note that this cache entry contains entries
from SPD-O and SPD-S.

3a. If there is a match, then process the packet as specified by
the
matching cache entry, i.e., bypass, discard, or apply AH following information.

- IPsec mode -- tunnel or transport
- extended sequence number -- Is this SA using extended
sequence numbers?
- stateful fragment checking -- Is this SA using stateful
fragment checking (see Section 7 for more details)
- IPsec protocol(s) -- AH, ESP in
the specified mode. If
- algorithms -- which ones to use for AH, which ones to
use for ESP, ordered by decreasing priority

4.4.2 Security Association Database (SAD)

In each IPsec processing is applied, implementation there is a
link from nominal Security Association
Database, in which each entry defines the SPD cache parameters associated with
one SA. Each SA has an entry to in the relevant SAD. For outbound processing,
each SAD entry
(specifying the cryptographic algorithms, keys, SPI, etc.). IPsec
processing is as previously defined, for tunnel or transport modes
and for AH or ESP, as specified in their respective RFCs [Ken04b
and Ken04a].

3b. If no match is found pointed to by entries in the cache, search the SPD (SPD-S and SPD-
O parts) specified by SPD-ID. If SPD-S part of the SPD entry calls for bypass or
discard, create new outbound and
cache. For inbound SPD cache entries. If the

Kent & Seo [Page 29]

Internet Draft Security Architecture for IP January 2004

SPD entry calls processing, for creation of an SA, unicast SAs, the key management
mechanism (e.g., IKEv2) SPI is invoked used
either alone to create the SA. If SA
creation succeeds, a new outbound (SPD-S) cache entry is created,
along with an SAD entry, otherwise the packet is discarded. (A
packet that triggers look up an SPD lookup MAY be discarded by the
implementation, SA, or it the SPI may be processed against the newly created
cache entry, if one is created.) Since SAs are created used in pairs, conjunction
with the IPsec protocol type. If an SAD entry for IPsec implementation supports
multicast, the corresponding inbound SA also is created, SPI plus destination address, or SPI plus destination
and
it contains the selector values derived from the SPD entry source addresses are used to
create look up the inbound SA, for use SA. (See Section 4.1.)
The following parameters are associated with each entry in checking inbound traffic
delivered via the SA .

4. The packet is passed SAD.
They should all be present except where otherwise noted, e.g., AH
Authentication algorithm. This description does not purport to the outbound forwarding function
(operating outside of the IPsec implementation), to select the
interface to which the packet will be directed. This function may
cause a
MIB, only a specification of the packet minimal data items required to be passed back across the IPsec boundary, for
additional IPsec processing, e.g., in
support of nested SAs. If
so, there MUST be an entry SA in SPD-I database that permits bypass
of the packet.

5.1.1 Handling an Outbound Packet That Must Be Dropped

If an IPsec system receives an outbound packet which it finds it must
drop, it SHOULD be capable implementation.

For each of generating and sending the selectors defined in Section 4.4.1.1, the entry for
an ICMP message
to indicate to inbound SA in the sender of SAD MUST contain the outbound packet that value or values negotiated
at the packet time the SA was
dropped. The type and code created. For a receiver, these values are used
to check that the header fields of an inbound packet match the ICMP message will depend
selector values negotiated for the SA. For the receiver, this is part
of verifying that a packet arriving on an SA is consistent with the
reason
policy for dropping the packet, SA. (See Section 6 for rules for ICMP messages.)
These fields can have the form of specific values, ranges, ANY, or
OPAQUE, as specified below. described in section 4.4.1.1, "Selectors."

The reason
SHOULD following data items MUST be recorded in the audit log. The audit log entry for this
event SHOULD include the reason, current date/time, and the selector
values of the packet.

a. SAD:

o Security Parameter Index (SPI): a 32-bit value selected by the selectors
receiving end of the packet matched an SPD entry requiring the
packet to be dropped -->

IPv4 Type = 3 (destination unreachable) Code = 13
(Communication Administratively Prohibited)

IPv6 Type = 1 (destination unreachable) Code = 1
(Communication with destination administratively
prohibited)

b1. the IPsec system was unable to set up the SA required by to uniquely identify the SPD SA. In an SAD
entry matching the packet because for an outbound SA, the IPsec peer at SPI is used to construct the other end
of
packet's AH or ESP header. In an SAD entry for an inbound SA, the exchange
SPI is administratively prohibited from communicating
with the initiator and rejects used to map traffic to the negotiation.

IPv4 Type = 3 (destination unreachable) Code = 13
(Communication Administratively Prohibited) appropriate SA (see text on
unicast/multicast in Section 4.1).

Kent & Seo [Page 30] 29]

Internet Draft Security Architecture for IP January April 2004

IPv6 Type = 1 (destination unreachable) Code = 1
(Communication with destination administratively
prohibited)

b2. the IPsec system was unable

o Sequence Number Counter: a 64-bit used to set up the SA required by the SPD
entry matching the packet because generate the IPsec peer at Sequence
Number field in AH or ESP headers. 64-bit sequence numbers are the other end
default, but 32-bit sequence numbers are also supported if
negotiated.

o Sequence Counter Overflow: a flag indicating whether overflow of
the exchange could not be contacted.

IPv4 Type = 3 (destination unreachable) Code = 1 (host
unreachable)

IPv6 Type = 1 (destination unreachable) Code = 3 (address
unreachable)

Note that Sequence Number Counter should generate an attacker behind a security gateway could send auditable event and
prevent transmission of additional packets
with a spoofed source address, W.X.Y.Z, to an IPsec entity causing it
to send ICMP messages to W.X.Y.Z. This creates an opportunity on the SA, or whether
rollover is permitted. The audit log entry for a
DoS attack among hosts behind a security gateway. To address this, a
security gateway this event SHOULD
include the SPI value, current date/time, Local Address, Remote
Address, and the selectors from the relevant SAD entry.

o Anti-Replay Window: a management control to allow an
administrator 64-bit counter and a bit-map (or equivalent)
used to configure determine whether an IPsec implementation to send inbound AH or not
send the ICMP messages under these circumstances, and if this
facility ESP packet is selected, to rate limit a replay.

NOTE: If anti-replay has been disabled by the transmission of such ICMP
responses.

5.1.2 Header Construction receiver for Tunnel Mode

This section describes an SA,
e.g., in the handling case of a manually keyed SA, then the inner and outer IP
headers, extension headers, and options Anti-Replay
Window is ignored for the SA in question. 64-bit sequence numbers
are the default, but this counter size accommodates 32-bit
sequence numbers.

o AH and ESP tunnels, with
regard to outbound traffic processing. Authentication algorithm, key, etc. This includes how to
construct the encapsulating (outer) IP header, how to process is required only if AH
is supported.

o ESP Encryption algorithm, key, mode, IV, etc. If a combined mode
algorithm is used, these fields
in will not be applicable.

o ESP integrity algorithm, keys, etc. If the inner IP header, and what other actions should integrity service is
not selected, these fields will not be taken for
outbound, tunnel applicable. If a combined
mode traffic. The general processing described here algorithm is modeled after RFC 2003, "IP Encapsulation with IP" [Per96]: used, these fields will not be applicable.

o The outer IP header Source Address ESP combined mode algorithms, key(s), etc. This data is used when
a combined mode (encryption and Destination Address
identify the "endpoints" integrity) algorithm is used with
ESP. If a combined mode algorithm is not used, these fields are
not applicable.

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, or a simultaneous use of
both with the tunnel (the encapsulator and
decapsulator). The inner IP header Source Address and Destination
Addresses identify the original sender first lifetime to expire taking precedence. A
compliant implementation MUST support both types of lifetimes, and recipient
must support a simultaneous use of both. If time is employed, and
if IKE employs X.509 certificates for SA establishment, the
datagram, (from SA
lifetime must be constrained by the perspective validity intervals of this tunnel), respectively.
(see footnote 3 after the table in 5.1.2.1 for more details on the
encapsulating source IP address.)

o The inner IP header is not changed except as noted below for TTL
(or Hop Limit)
certificates, and the ECN Field. The inner IP header otherwise
remains unchanged during its delivery to NextIssueDate of the tunnel exit point.

o No change to IP options or extension headers CRLs used in the inner header IKE

Kent & Seo [Page 31] 30]

Internet Draft Security Architecture for IP January April 2004

occurs during delivery of the encapsulated datagram through

exchange for the
tunnel.

Note: IPsec tunnel mode is different from IP-in-IP tunneling (RFC
2003) in several ways:

o IPsec offers certain controls to a security administrator to
manage covert channels (which would not normally be a concern for
tunneling) SA. Both initiator and to ensure that the receiver examines responder are responsible
for constraining the right
portions SA lifetime in this fashion. NOTE: The
details of how to handle the received packet re: application refreshing of access
controls. An IPsec keys when SAs expire is
a local matter. However, one reasonable approach is:

(a) If byte count is used, then the implementation MAY be configurable with regard SHOULD count the
number of bytes to how it processes which the DSCP field for tunnel mode for transmitted
packets. IPsec cryptographic algorithm is
applied. For outbound traffic, one configuration setting for DSCP
will operate as described in ESP, this is the following sections on IPv4 encryption algorithm (including
Null encryption) and
IPv6 header processing for IPsec tunnels. Another will allow AH, this is the
DSCPfield to be mapped to a fixed value, which MAY be configured
on a per SA basis. (The value might really be fixed for all
traffic outbound from a device, but per SA granularity allows that
as well.) authentication
algorithm. This configuration option allows a local administrator includes pad bytes, etc. Note that
implementations MUST be able to decide whether handle having the covert channel provided by copying these
bits outweighs counters at
the benefits ends of copying.

o IPsec describes how to handle ECN an SA get out of synch, e.g., because of packet
loss or DSCP.

o IPsec allows because the IP version implementations at each end of the encapsulating header to SA
aren't doing things the same way.

(b) There SHOULD be
different from that two kinds of lifetime -- a soft lifetime that
warns the inner header. implementation to initiate action such as setting up
a replacement SA; and a hard lifetime when the current SA ends
and is destroyed.

o IPsec protocol mode: tunnel or transport. Indicates which mode of
AH or ESP is applied to traffic on this SA.

o Stateful fragment checking flag. Indicates whether or not stateful
fragment checking applies to this SA.

o Path MTU: any observed path MTU and aging variables.

o Tunnel header IP source and destination address - both addresses
must be either IPv4 or IPv6 addresses. The tables in version implies the
type of IP header to be used. Only used when the IPsec protocol
mode is tunnel.

For each selector, the following sub-sections tables show the handling for relationship between
the
different header/option fields ("constructed" means that value in the SPD, the PFP flag, the value in the outer field is constructed independently of triggering
packet and the resulting value in the
inner). SAD. Note that the
administrative interface for IPsec can use various syntactic options
to make it easier for the administrator to enter rules. For example,
although a list of ranges is what IKEv2 sends, it might be clearer
and less error prone for the user to enter a single IP address or IP
address prefix.

Kent & Seo [Page 32] 31]

Internet Draft Security Architecture for IP January April 2004

5.1.2.1 IPv4 -- Header Construction for Tunnel Mode

<-- How Outer Hdr Relates to Inner Hdr -->
Outer Hdr at Inner Hdr at
IPv4 Encapsulator Decapsulator
Header fields: --------------------

Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
-------- ---------------- --- ------------
version 4 (1) no change
header length constructed no change
DS Field copied from inner hdr (5) no change
ECN Field copied from inner hdr constructed (6)
total length constructed no change
ID constructed no change
flags (DF,MF) constructed, DF (4) no change
fragment offset constructed no change
TTL constructed (2) decrement (2) --------------
loc addr list of ranges 0 IP addr "S" list of ranges
or ANY or ANY
list of ranges 1 IP addr "S" "S"
or ANY

rem addr list of ranges 0 IP addr "D" list of ranges
or ANY or ANY
list of ranges 1 IP addr "D" "D"
or ANY

protocol AH, ESP no change
checksum constructed constructed (2)(6) list of prot's* 0 prot. "P" list of prot's*
or ANY** or ANY
list of prot's* 1 prot. "P" "P"
or ANY**
OPAQUE 0 not avail. "undefined"
OPAQUE 1 not avail. ***

Kent & Seo [Page 32]

Internet Draft Security Architecture for IP April 2004

If the protocol is one that has two ports then there will be
selectors for both Local and Remote ports.

Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
-------- ---------------- --- ------------ --------------
loc port list of ranges 0 src address constructed (3) port "s" list of ranges
or ANY or ANY
list of ranges 0 no change
dest address constructed (3) src port discard packet
or ANY
OPAQUE 0 not avail. OPAQUE
OPAQUE 1 not avail. ***
list of ranges 1 src port "s" "s"
or ANY
list of ranges 1 no change
Options never copied src port discard packet
or ANY

rem port list of ranges 0 dst port "d" list of ranges
or ANY or ANY
list of ranges 0 no change

1. The IP version in the encapsulating header can dst port discard packet
or ANY
OPAQUE 0 not avail. OPAQUE
OPAQUE 1 not avail. ***
list of ranges 1 dst port "d" "d"
or ANY
list of ranges 1 no dst port discard packet
or ANY

If the protocol is mobility header then there will be a selector for
mh type.

Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
-------- ---------------- --- ------------ --------------
mh type list of ranges 0 mh type "T" list of ranges
or ANY or ANY
list of ranges 0 no mh type discard packet
or ANY
OPAQUE 0 not avail. OPAQUE
OPAQUE 1 not avail. ***
list of ranges 1 mh type "T" "T"
or ANY
list of ranges 1 no mh type discard packet
or ANY

Kent & Seo [Page 33]

Internet Draft Security Architecture for IP April 2004

If the protocol is ICMP, then there will be a 16-bit selector for
ICMP type and ICMP code. Note that the type and code are bound to
each other, i.e., the codes apply to the particular type. This 16-bit
selector can contain a single type and a range of codes, a single
type and ANY code, ANY type and ANY code.

Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
--------- ---------------- --- ------------ --------------
ICMP type a single type 0 type "t" list of ranges
or ANY or ANY
a single type 0 no type discard packet
or ANY
OPAQUE 0 not avail. OPAQUE
OPAQUE 1 not avail. ***
a single type 1 type "t" "t"
or ANY
a single type 1 no type discard packet
or ANY

ICMP code list of ranges 0 type "c" list of ranges
or ANY or ANY
list of ranges 0 no code discard packet
or ANY
OPAQUE 0 not avail. OPAQUE
OPAQUE 1 not avail. ***
list of ranges 1 type "c" "c"
or ANY
list of ranges 1 no code discard packet
or ANY

Kent & Seo [Page 34]

Internet Draft Security Architecture for IP April 2004

If the name selector is used...

Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
--------- ---------------- --- ------------ --------------
name list of system- N/A packet from N/A
dependent user or
user or sys. system
names

* "List of protocols" is the information, not the way
that the SPD or SAD or IKv2 have to represent this
information.
** 0 (zero) is used by IKE to indicate ANY for
protocol.
*** Use of PFP=1 with an OPAQUE value is an error and
SHOULD be prohibited by an IPsec implementation.

4.5 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,
although the techniques involved do affect some of the security
services offered by the protocols. For example, the optional anti-
replay service available for AH and ESP requires automated SA
management. Moreover, the granularity of key distribution employed
with IPsec determines the granularity of authentication provided. In
general, data origin authentication in AH and ESP is limited by the
extent to which secrets used with the integrity 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.5.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

Kent & Seo [Page 35]

Internet Draft Security Architecture for IP April 2004

domain, this might 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.5.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 IKEv2 [Kau04]. Other automated SA management protocols MAY
be employed.

When an automated SA/key management protocol is employed, the output
from this protocol is used to generate multiple keys for a single SA.
This also occurs because distinct keys are used for each of the two
SAs created by IKE. If both integrity and confidentiality are
employed, then a minimum of four keys are required. Additionally,
some cryptographic algorithms may require multiple keys, e.g., 3DES.

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 keys
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 keys MUST be taken from the first (left-most, high-
order) bits and the integrity keys MUST be taken from the remaining
bits. The number of bits for each key is defined in the relevant
cryptographic algorithm specification RFC. In the case of multiple
encryption keys or multiple integrity keys, the specification for the
cryptographic algorithm must specify the order in which they are to
be selected from a single string of bits provided to the

Kent & Seo [Page 36]

Internet Draft Security Architecture for IP April 2004

cryptographic algorithm.

4.5.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, but the Peer Authorization Database
described in Section 4.4 is the most likely candidate.

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 his home organization's
firewall (SG2). This situation raises several issues:

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 any additional gateways that 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 one or more security gateways for ranges of
destination addresses that require its use. This includes the
ability to configure information for locating and authenticating one
or more security gateways and verifying the authorization of these
gateways to represent the destination host. (The authorization
function is implied in the PAD.) This document does not address the
issue of how to automate the discovery/verification of security
gateways. The IP Security Policy (IPSP) Working Group is a possible
future source of guidance. One of its goals is to produce an Internet
Draft on a "Security Gateway Discovery, Policy Exchange and
Negotiation Protocol".

Kent & Seo [Page 37]

Internet Draft Security Architecture for IP April 2004

4.6 Security Associations and Multicast

The receiver-orientation of the Security Association implies that, in
the case of unicast traffic, the destination system will 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 associated with a single SA.
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
that group when a symmetric key encryption or integrity 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 approaches are
deferred to the IETF's Multicast Security Working Group.

5. IP Traffic Processing

As mentioned in Section 4.4.1 "The Security Policy Database (SPD)",
the SPD (or associated caches) must be consulted during the
processing of all traffic that crosses the IPsec protection boundary,
including IPsec management traffic. If no policy is found in the SPD
that matches a packet (for either inbound or outbound traffic), the
packet MUST be discarded. To simplify processing, and to allow for
very fast SA lookups (for SG/BITS/BITW), this document introduces the
notion of an SPD cache for all outbound traffic (SPD-O plus SPD-S),
and a cache for inbound, non-IPsec-protected traffic (SPD-I). There
is nominally one cache per SPD. Since SPD entries may overlap, one
cannot safely cache these entries in general. Simple caching might
result in a match against a cache entry whereas an ordered search of
the SPD would have resulted in a match against a different entry.
But, if the SPD entries are first decorrelated, then the resulting
entries can safely be cached, and each cached entry will map to
exactly one SA, or indicate that matching traffic should be bypassed
or discarded, appropriately. (Note: The original SPD entry might
result in multiple SAs, e.g., because of PFP.) Unless otherwise
noted, all references below to the "SPD" or "SPD cache" or "cache"

Kent & Seo [Page 38]

Internet Draft Security Architecture for IP April 2004

are to a decorrelated SPD (SPD-I, SPD-O, SPD-S) or the SPD cache
containing entries from the decorrelated SPD.

Note: 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. This provides an implicit caching mechanism and the
portions of the preceding discussion that address caching can be
ignored in such implementations.

Note: It is assumed that one starts with a correlated SPD because
that is how users and administrators are accustomed to managing these
sorts of access control lists or firewall filter rules. Then the
decorrelation algorithm is applied, to build a list of cache-able SPD
entries. The decorrelation is invisible at the management interface.

For inbound IPsec traffic, the SAD entry selected by the SPI serves
as the cache for the selectors to be matched against arriving IPsec
packets, after AH or ESP processing has been performed.

5.1 Outbound IP Traffic Processing (protected-to-unprotected)

First consider the path for traffic entering the implementation via a
protected interface and exiting via an unprotected interface.

Unprotected Interface
^
|
(nested SAs) +----------+
...................|Forwarding|<-----+
: +----------+ |
: ^ |
: | BYPASS |
V +-----+ +--------+
+-------+ +-------+ | SPD | |PROTECT |
| SPD-I | |DISCARD|<---|Cache|---->|(AH/ESP)|
+-------+ +-------+ +-----+ +--------+
: ^
: |
: +-------------+
:................>|SPD Selection|
+-------------+
^
|
Protected Interface

Kent & Seo [Page 39]

Internet Draft Security Architecture for IP April 2004

Figure 2. Processing Model for Outbound Traffic

IPsec MUST perform the following steps when processing outbound
packets:

1. When a packet arrives from the subscriber (protected) interface,
invoke the SPD selection function to obtain the SPD-ID needed to
choose the appropriate SPD. (If the implementation uses only one
SPD, this step is a no-op.)

2. Match the packet headers against the cache for the SPD specified
by the SPD-ID from step 1. Note that this cache contains entries
from SPD-O and SPD-S.

3a. If there is a match, then process the packet as specified by the
matching cache entry, i.e., BYPASS, DISCARD, or PROTECT using AH
or ESP. If IPsec processing is applied, there is a link from the
SPD cache entry to the relevant SAD entry (specifying the mode,
cryptographic algorithms, keys, SPI, etc.). IPsec processing is
as previously defined, for tunnel or transport modes and for AH or
ESP, as specified in their respective RFCs [Ken04b and Ken04a].

3b. If no match is found in the cache, search the SPD (SPD-S and SPD-
O parts) specified by SPD-ID. If the SPD entry calls for BYPASS or
DISCARD, create new outbound SPD cache entries and if BYPASS,
create new inbound SPD cache entries. If the SPD entry calls for
PROTECT, i.e., creation of an SA, the key management mechanism
(e.g., IKEv2) is invoked to create the SA. If SA creation
succeeds, a new outbound (SPD-S) cache entry is created, along
with outbound and inbound SAD entries, otherwise the packet is
discarded. (A packet that triggers an SPD lookup MAY be discarded
by the implementation, or it may be processed against the newly
created cache entry, if one is created.) Since SAs are created in
pairs, an SAD entry for the corresponding inbound SA also is
created, and it contains the selector values derived from the SPD
entry (and packet, if any PFP flags were "true") used to create
the inbound SA, for use in checking inbound traffic delivered via
the SA.

4. The packet is passed to the outbound forwarding function
(operating outside of the IPsec implementation), to select the
interface to which the packet will be directed. This function may
cause the packet to be passed back across the IPsec boundary, for
additional IPsec processing, e.g., in support of nested SAs. If
so, there MUST be an entry in SPD-I database that permits inbound
bypassing of the packet.

Kent & Seo [Page 40]

Internet Draft Security Architecture for IP April 2004

NOTE: With the exception of IPv4 and IPv6 transport mode, an SG,
BITS, or BITW implementation MAY fragment packets before applying
IPsec. The device SHOULD have a configuration setting to disable
this. The resulting fragments are evaluated against the SPD in the
normal manner. Thus, fragments not containing port numbers (or ICMP
message type and code, or Mobility Header type) will only match rules
having port (or ICMP message type and code, or MH type) selectors of
OPAQUE or ANY. (See section 7 for more details.)

5.1.1 Handling an Outbound Packet That Must Be Discarded

If an IPsec system receives an outbound packet which it finds it must
discard, it SHOULD be capable of generating and sending an ICMP
message to indicate to the sender of the outbound packet that the
packet was discarded. The type and code of the ICMP message will
depend on the reason for discarding the packet, as specified below.
The reason SHOULD be recorded in the audit log. The audit log entry
for this event SHOULD include the reason, current date/time, and the
selector values from the packet.

a. The selectors of the packet matched an SPD entry requiring the
packet to be discarded.

IPv4 Type = 3 (destination unreachable) Code = 13
(Communication Administratively Prohibited)

IPv6 Type = 1 (destination unreachable) Code = 1
(Communication with destination administratively
prohibited)

b1. The IPsec system was unable to set up the SA required by the SPD
entry matching the packet because the IPsec peer at the other end
of the exchange is administratively prohibited from communicating
with the initiator.

IPv4 Type = 3 (destination unreachable) Code = 13
(Communication Administratively Prohibited)

IPv6 Type = 1 (destination unreachable) Code = 1
(Communication with destination administratively
prohibited)

b2. The IPsec system was unable to set up the SA required by the SPD
entry matching the packet because the IPsec peer at the other end
of the exchange could not be contacted.

IPv4 Type = 3 (destination unreachable) Code = 1 (host
unreachable)

Kent & Seo [Page 41]

Internet Draft Security Architecture for IP April 2004

IPv6 Type = 1 (destination unreachable) Code = 3 (address
unreachable)

Note that an attacker behind a security gateway could send packets
with a spoofed source address, W.X.Y.Z, to an IPsec entity causing it
to send ICMP messages to W.X.Y.Z. This creates an opportunity for a
DoS attack among hosts behind a security gateway. To address this, a
security gateway SHOULD include a management control to allow an
administrator to configure an IPsec implementation to send or not
send the ICMP messages under these circumstances, and if this
facility is selected, to rate limit the transmission of such ICMP
responses.

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, with
regard to outbound traffic processing. This includes how to
construct the encapsulating (outer) IP header, how to process fields
in the inner IP header, and what other actions should be taken for
outbound, tunnel mode traffic. The general processing described here
is modeled after RFC 2003, "IP Encapsulation with IP" [Per96]:

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, (from the perspective of this tunnel), respectively.
(See footnote 3 after the table in 5.1.2.1 for more details on the
encapsulating source IP address.)

o The inner IP header is not changed except as noted below for TTL
(or Hop Limit) and the DS/ECN Fields. The inner IP header
otherwise 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.

Note: IPsec tunnel mode is different from IP-in-IP tunneling (RFC
2003) in several ways:

o IPsec offers certain controls to a security administrator to
manage covert channels (which would not normally be a concern for
tunneling) and to ensure that the receiver examines the right

Kent & Seo [Page 42]

Internet Draft Security Architecture for IP April 2004

portions of the received packet re: application of access
controls. An IPsec implementation MAY be configurable with regard
to how it processes the DS field for tunnel mode for transmitted
packets. For outbound traffic, one configuration setting for DSCP
will operate as described in the following sections on IPv4 and
IPv6 header processing for IPsec tunnels. Another will allow the
DS field to be mapped to a fixed value, which MAY be configured on
a per SA basis. (The value might really be fixed for all traffic
outbound from a device, but per SA granularity allows that as
well.) This configuration option allows a local administrator to
decide whether the covert channel provided by copying these bits
outweighs the benefits of copying.

o IPsec describes how to handle ECN or DS.

o IPsec allows the IP version of the encapsulating header to be
different from that of the inner header.

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

5.1.2.1 IPv4 -- Header Construction for Tunnel Mode

<-- How Outer Hdr Relates to Inner Hdr -->
Outer Hdr at Inner Hdr at
IPv4 Encapsulator Decapsulator
Header fields: -------------------- ------------
version 4 (1) no change
header length constructed no change
DS Field copied from inner hdr (5) no change
ECN Field copied from inner hdr constructed (6)
total length constructed no change
ID constructed no change
flags (DF,MF) constructed, DF (4) no change
fragment offset constructed no change
TTL constructed (2) decrement (2)
protocol AH, ESP no change
checksum constructed constructed (2)(6)
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.

Kent & Seo [Page 43]

Internet Draft Security Architecture for IP April 2004

2. The TTL in the inner header is decremented by the
encapsulator prior to forwarding and by the decapsulator
if it forwards the packet. (The IPv4 checksum changes
when the TTL changes.)

Note: Decrementing the TTL value is a normal part of
forwarding a packet. Thus, a packet originating from
the same node as the encapsulator does not have its TTL
decremented, since the sending node is originating the
packet rather than forwarding it.

3. Local and Remote addresses depend on the SA, which is
used to determine the Remote address which in turn
determines which Local address (net interface) is used
to forward the packet.

Note: For multicast traffic, the destination address, or
source and destination addresses, may be required for
demuxing. In that case, it is important to ensure
consistency over the lifetime of the SA by ensuring that
the source address that appears in the encapsulating
tunnel header is the same as the one that was negotiated
during the SA establishment process. There is an
exception to this general rule, i.e., a mobile IPsec
implementation will update its source address as it
moves.

4. configuration determines whether to copy from the inner
header (IPv4 only), clear or set the DF.

5. If the packet will immediately enter a domain for which
the DSCP value in the outer header is not appropriate,
that value MUST be mapped to an appropriate value for
the domain [RFC 2474]. See [RFC 2475] for further
information.

6. If the ECN field in the inner header is set to ECT(0) or
ECT(1) and the ECN field in the outer header is set to
CE, then set the ECN field in the inner header to CE,
otherwise make no change to the ECN field in the inner
header. (The IPv4 checksum changes when the ECN
changes.)

Note: IPsec does not copy the options from the inner header into the
outer header, nor does IPsec construct the options in the outer
header. However, post-IPsec code MAY insert/construct options for the
outer header.

Kent & Seo [Page 44]

Internet Draft Security Architecture for IP April 2004

5.1.2.2 IPv6 -- Header Construction for Tunnel Mode

See previous section 5.1.2.1 for notes 1-6 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
DS Field copied from inner hdr (5) no change
ECN Field copied from inner hdr constructed (6)
flow label copied or configured no change
payload length constructed no change
next header AH,ESP,routing hdr no change
hop limit constructed (2) decrement (2)
src address constructed (3) no change
dest address constructed (3) no change
Extension headers never copied (7) no change

7. IPsec does not copy the extension headers from the inner
packet into the outer header, nor does IPsec construct
extension headers in the outer header. However, post-
IPsec code MAY insert/construct extension headers for
the outer header.

5.2 Processing Inbound IP Traffic (unprotected-to-protected)

Inbound processing is somewhat different from outbound processing,
because of the use of SPIs to map IPsec protected traffic to SAs. The
inbound SPD cache (SPD-I) is applied only to bypassed or discarded
traffic. If an arriving packet appears to be an IPsec fragment from
an unprotected interface, reassembly is performed prior to the IPsec
processing. The intent for any SPD cache is that a packet that fails
to match any entry is then referred to the corresponding SPD. Every
SPD SHOULD have a nominal, final entry that catches anything that is
otherwise unmatched, and discards it. This ensures that non-IPsec
protected traffic that arrives and does not match any SPD-I entry
will be discarded.

Kent & Seo [Page 45]

Internet Draft Security Architecture for IP April 2004

Unprotected Interface
|
V
+-----+ IPsec protected
------------------->|Demux|-------------------+
| +-----+ |
| | |
| Not IPsec | |
| | |
| V |
| +-------+ +-------+ +------+ |
| |DISCARD|<---| SPD-I |-->| ICMP | |
| +-------+ +-------+ +------+ |
| | V
+-----+ | +--------+
....|SPD-O|................|....................|PROTECT |...IPsec
+-----+ | |(AH/ESP)| Boundary
^ | +--------+
| | +---+ |
| BYPASS | +-->|IKE| |
| | | +---+ |
| V | V
| +----------+ +---------+
|--------<------|Forwarding|<------------|SAD Check|
+----------+ +---------+
|
V
Protected Interface

Figure 3. Inbound Traffic Processing Model

Prior to performing AH or ESP processing, any IP fragments that
arrive via the unprotected interface are reassembled (by IP). 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 a next layer protocol in the IPv6
context).

IPsec MUST perform the following steps:

1. When a packet arrives, it may be tagged with the ID of the
interface (physical or virtual) via which it arrived, if necessary
to support multiple SPDs with different SPD-I entries. (The
interface ID is mapped to a corresponding SPD-ID.)

Kent & Seo [Page 46]

Internet Draft Security Architecture for IP April 2004

2. The packet is examined and demuxed into one of three categories:
- If the packet appears to be IPsec protected and it is addressed
to this device, an attempt is made to map it to an active SA
via the SAD.
- Traffic not addressed to this device, or addressed to this
device and not AH, ESP, or ICMP, is directed to BYPASS/DISCARD
lookup. (IKE traffic MUST have an explicit BYPASS entry in the
SPD.) If multiple SPDs are employed, the tag assigned to the
packet in step 1 is used to select the appropriate SPD-I (and
cache) to search.
- ICMP traffic directed to this device is directed to
"unprotected" ICMP processing (see Section 6).

3a. If the packet is addressed to the IPsec device and AH or ESP is
specified as the protocol, the packet is looked up in the SAD
identified by the SPD-ID from step 1. For unicast traffic, use
only the SPI (or SPI plus protocol). For multicast traffic, use
the SPI plus the destination and/or source addresses, as specified
in the SAD. If there is no match, discard the traffic. This is an
auditable event. The audit log entry for this event SHOULD include
the current date/time, SPI, source and destination of the packet,
IPsec protocol, and any other selector values of the packet that
are available. If the packet is found in the SAD, process it
accordingly (see step 4).

3b. If the packet is not addressed to the device or is addressed to
this device and is not AH, ESP, or ICMP, look up the packet header
in the (appropriate) SPD-I cache. If there is a match and the
packet is to be discarded or bypassed, do so. If there is no cache
match, look up the packet in the corresponding SPD-I and create a
cache entry as appropriate. (No SAs are created in response to
receipt of a packet that requires IPsec protection; only BYPASS or
DISCARD entries can be created this way.) If there is no match,
discard the traffic. This is an auditable event. The audit log
entry for this event SHOULD include the current date/time, SPI if
available, IPsec protocol if available, source and destination of
the packet, and any other selector values of the packet that are
available.

3c. Unprotected ICMP processing is assumed to take place on the
unprotected side of the IPsec boundary. Unprotected ICMP messages
are examined and local policy is applied to determine whether to
accept or reject these messages and, if accepted, what action to
take as a result. For example, if an ICMP unreachable message is
received, the implementation must decide whether to act on it,
reject it, or act on it with constraints. [See Section 6.]

4. Apply AH or ESP processing as specified, using the SAD entry

Kent & Seo [Page 47]

Internet Draft Security Architecture for IP April 2004

selected in step 3a above. Then match the packet against the
inbound selectors identified by the SAD entry to verify that the
received packet is appropriate for the SA via which it was
received.

If an IPsec system receives an inbound packet on an SA and the
packet's header fields are not consistent with the selectors for
the SA, it MUST discard the packet. This is an auditable event.
The audit log entry for this event SHOULD include the current
date/time, SPI, IPsec protocol(s), source and destination of the
packet, and any other selector values of the packet that are
available, and the selector values from the relevant SAD entry.
The system SHOULD also be capable of generating and sending an IKE
notification to the sender (IPsec peer), indicating that the
received packet was discarded because of failure to pass selector
checks.

IKEv2 NOTIFY MESSAGES - ERROR TYPES Value
----------------------------------- -----
INVALID_SELECTORS iana-tbd

This error indication MAY be sent in an IKE INFORMATIONAL
exchange when a node receives an ESP or AH packet whose
selectors do not match those of the SA on which it was
delivered (and which caused the packet to be discarded).
The Notification Data contains the start of the offending
packet (as in ICMP messages) and the SPI field of the
notification is set to match the SPI of the IPsec SA.

To minimize the impact of a DoS attack or a mis-configured peer, the
IPsec system SHOULD include a management control to allow an
administrator to configure the IPsec implementation to send or not
send this IKE notification, and if this facility is selected, to rate
limit the transmission of such notifications.

After traffic is bypassed or processed through IPsec, it is handed to
the inbound forwarding function for disposition. This function may
cause the packet to be sent (outbound) across the IPsec boundary for
additional inbound IPsec processing, e.g., in support of nested SAs.
If so, then as with ALL outbound traffic that is to be bypassed, the
packet MUST be matched against an SPD-O entry. Ultimately, the packet
should be forwarded to the destination host or process for
disposition.

Kent & Seo [Page 48]

Internet Draft Security Architecture for IP April 2004

6. ICMP Processing

[This section will be filled in when IPsec issue # 91 is resolved.]

7. Handling Fragments (on the protected side of the IPsec boundary)

Earlier sections of this document describe mechanisms for (a)
fragmenting an outbound packet after IPsec processing has been
applied and reassembling it at the receiver before IPsec processing
and (b) handling inbound fragments received from the unprotected side
of the IPsec boundary. This section describes how an implementation
should handle the processing of outbound plaintext fragments on the
protected side of the IPsec boundary. (See Appendix E for discussion
of Fragment Handling Rationale.) In particular, it addresses:

o mapping an outbound non-initial fragment to the right SA
(or finding the right SPD entry)
o verifying that a received non-initial fragment is
authorized for the SA via which it was received
o mapping outbound and inbound non-initial fragments to the
right SPD-O/SPD-I entry or the relevant cache entry, for
BYPASS/DISCARD traffic

Note: In Section 4.1, transport mode SAs have been defined to not
carry fragments (IPv4 or IPv6). Note also that in Section 4.4.1, two
special values, ANY and OPAQUE, were defined for selectors and that
ANY includes OPAQUE.

Note: The term "non-initial fragment" is used here to indicate a
fragment that does not contain all the selector values that may be
needed for access control. As observed in Section 4.4.1, depending
on the Next Layer Protocol, in addition to Ports, the ICMP message
type/code or Mobility Header type could be missing from non-initial
fragments. Also, for IPv6, even an initial fragment might NOT
contain the Next Layer Protocol or Ports (or ICMP message type/code,
or Mobility Header type) depending on the kind and number of
extension headers present. If a non-initial fragment contains the
Port (or ICMP type and code or Mobility header type) but not the Next
Layer Protocol, then unless there is an SPD entry for the relevant
Local/Remote addresses with ANY for Next Layer Protocol and Port (or
ICMP type and code or Mobility header type), the fragment would not
contain all the selector information needed for access control.

To address the above requirements, three approaches have been
defined:

Kent & Seo [Page 49]

Internet Draft Security Architecture for IP April 2004

1. All implementations MUST support tunnel mode SAs that are
configured to pass traffic without regard to port field (or ICMP
type/code or Mobility Header type) values. If the SA will carry
traffic for specified protocols, the selector set for the SA MUST
specify the port fields (or ICMP type/code or Mobility Header type)
as ANY. An SA defined in this fashion will carry all traffic
including initial and non-initial fragments for the indicated
Local/Remote addresses and specified Next Layer protocol(s). If the
SA will carry traffic without regard to a specific protocol value
(i.e., ANY is specified as the (Next Layer) protocol selector value),
then the port field values are undefined and MUST be set to ANY as
well. (As noted in 4.4.1, ANY includes OPAQUE as well as all specific
values.)

2. All implementations MAY/SHOULD support tunnel mode SAs that will
carry only non-initial fragments, separate from non-fragmented
packets and initial fragments. The OPAQUE value will be used to
specify port (or ICMP type/code or Mobility Header type) field
selectors for an SA to carry such fragments. Receivers MUST perform a
minimum offset check on IPv4 (non-initial) fragments to protect
against overlapping fragment attacks when SAs of this type are
employed. Because such checks cannot be performed on IPv6 non-initial
fragments, users and administrators are advised that carriage of such
fragments may be dangerous, and implementers may choose to NOT
support such SAs for IPv6 traffic. Also, because an SA of this sort
will carry ALL non-initial fragments that match a specified
Local/Remote address pair and protocol value, users and
administrators are advised to protect such traffic using ESP (with
integrity) and the "strongest" integrity and encryption algorithms
available at both peers. (Determination of the "strongest"
algorithms requires imposing an ordering of the available algorithms,
a local determination at the discretion of the initiator of the SA.)

Specific port (or ICMP type/code or Mobility header type) selector
values will be used to define SAs to carry initial fragments and non-
fragmented packets. This approach can be used if a user or
administrator wants to create one or more tunnel mode SAs between the
same Local/Remote addresses that discriminate based on port (or ICMP
type/code or Mobility header type) fields. These SAs MUST have non-
trivial protocol selector values, otherwise approach #1 above MUST be
used.

Note: In general, for approach 2, one needs only a single SA between
two implementations to carry all non-initial fragments. However, if
one chooses to have multiple SAs between the two implementations for
QoS differentiation, then one might also want multiple SAs to carry
fragments-without-ports, one for each supported QoS class. Since
support for QoS via distinct SAs is a local matter, not mandated by

Kent & Seo [Page 50]

Internet Draft Security Architecture for IP April 2004

2401bis, the choice to have multiple SAs to carry non-initial
fragments should also be local.

3. An implementation MAY/SHOULD support some form of stateful
fragment checking for a tunnel mode SA with non-trivial port (or ICMP
type/code or MH type) field values (not ANY or OPAQUE).
Implementations that will transmit non-initial fragments on a tunnel
mode SA that makes use of non-trivial port (or ICMP type/code or MH
type) selectors MUST notify a peer via the IKE NOTIFY payload:

IKEv2 NOTIFY MESSAGES - ERROR TYPES Value
----------------------------------- -----
NON FIRST FRAGMENTS ALSO iana-tbd

The peer MUST reject this proposal if it will not accept non-initial
fragments in this context. If an implementation does not successfully
negotiate transmission of non-initial fragments for such an SA, it
MUST NOT send such fragments over the SA. This standard does not
specify how peers will deal with such fragments, e.g., via reassembly
or other means, at either sender or receiver. However, a receiver
MUST discard non-initial fragments that arrive on an SA with non-
trivial port (or ICMP type/code or MH type) selector values unless
this feature has been negotiated. Also, the receiver MUST discard
non-initial fragments that do not comply with the security policy
applied to the overall packet. Discarding such packets is an
auditable event. Note that in network configurations where fragments
of a packet might be sent or received via different security gateways
or BITW implementations, stateful strategies for tracking fragments
may fail. Also note that stateful fragment checking may create DoS
opportunities that may be exploitable by hosts on a protected network
behind a security gateway.

An implementation MAY/SHOULD choose to support stateful fragment
checking for BYPASS/DISCARD traffic for a tunnel mode SA with non-
trivial port field values (not ANY or OPAQUE) (Approach 3 above). An
implementation also MUST permit a user or administrator to accept or
reject BYPASS/DISCARD traffic using the SPD conventions described in
approaches 1 and 2 above.

8. 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 this document and
for each of these events a minimum set of information that SHOULD be

Kent & Seo [Page 51]

Internet Draft Security Architecture for IP April 2004

included in an audit log is defined. Additional information also MAY
be
different from the value included in the inner header.

2. The TTL audit log for each of these events, and additional
events, not explicitly called out in the inner header this specification, also MAY
result in audit log entries. There is decremented by no requirement for the
encapsulator prior
receiver to transmit any message to forwarding and by the decapsulator
if it forwards the packet. (The checksum changes when purported transmitter in
response to the TTL changes.)

Note: Decrementing detection of an auditable event, because of the TTL value is a normal part
potential to induce denial of
forwarding a packet. Thus, a packet originating service via such action.

9. Conformance Requirements

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

10. Security Considerations

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

11. Differences from
the same node as the encapsulator does not RFC 2401

[This section will be further updated when things have its TTL
decremented, since the sending node is originating the
packet rather than forwarding it.

3. src settled down.
Issue numbers, status, rejected items, and dest addresses depend on "proposed changes", etc.
will be removed in final version. Only the SA, which is used
to determine text describing the dest address which
differences from 2401 will remain.]

This architecture document differs substantially from RFC 2401 in turn determines
which src address (net interface) is used
detail and in organization, but the fundamental notions are
unchanged.

o [Issues 40,44,45]
- 40 [closed] "Interface SPD selector vs. per-interface SPD"
- 44 [pending] "Proposed change: forwarding table lookup to forward the
packet.

Note:
select virtual interface ID"
- 45 [pending] "Proposed change: use of cache with
decorrelated SPD"

The source processing model has been revised to address that appears in the
encapsulating tunnel header MUST be the one that was
negotiated during the SA establishment process. In
principle, new IPsec scenarios,
improve performance and simplify implementation. This includes a
separation between forwarding (routing) and SPD selection, several SPD
changes, and the encapsulating IP source address can be
any addition of the encapsulator's interface addresses or even an
address different from any of the encapsulator's IP
addresses, (e.g., if it's acting as a NAT box) so long
as the address outbound SPD cache and an inbound SPD
cache for bypassed or discarded traffic.

o [Issue #46] [closed] "Proposed change: no need for iterated
processing" -- There is reachable through the encapsulator no longer a requirement to support nested SAs

Kent & Seo [Page 33] 52]

Internet Draft Security Architecture for IP January April 2004

from the environment into which the packet is sent.

4. configuration determines whether to copy from the inner
header (IPv4 only), clear

or "SA bundles." Instead this functionality can be achieved through
SPD and forwarding table configuration.

o [Issue #47] [closed] "Proposed change: all selectors can be a list
of ranges, per IKEv2 spec"

SPD entries were redefined to provide more flexibility. Each SPD
entry now consists of a set the DF.

5. If the packet will immediately enter of selectors, where each selector set
contains one protocol and a domain for which
the DSCP value in the outer header is not appropriate,
that value MUST "list of ranges" can now be mapped to an appropriate value for
the domain [RFC 2474]. See [RFC 2475] specified for further
information.

6. If the ECN field in
the inner header Local IP address, Remote IP address, Local Port, Remote Port, and
ICMP message type and code. An individual value for a selector is set to ECT(0) or
ECT(1)
represented via a trivial range and the ECN field in the outer header ANY is set to
CE, then set the ECN field in the inner header to CE,
otherwise make no change to the ECN field in the inner
header. The checksum changes when the ECN changes.)

5.1.2.2 IPv6 selector. An ASN.1 description is
included in Appendix D.

o [Issue #48] [closed] "Proposed change: add ToS traffic selector
option" -- Header Construction for Tunnel Mode

See previous section 5.1.2.1 for notes 1-6 indicated TOS (IPv4) and Traffic Class (IPv6) have been replaced by (footnote
number).

Note: IPsec does not copy
DSCP and ECN.

o [Issues #49 and #88]
- 49 [closed] "Proposed change: red-side fragmentation option"
- 88 [accepted] "Lift the extension headers from prohibition on red-side
fragmentation by SG, BITS, BITW"
For tunnel mode SAs, an SG, BITS, or BITW implementation is now
allowed to fragment packets before applying IPsec. This applies only
to IPv4. For IPv6 packets, only the inner header
into originator is allowed to
fragment it.

o [Issue #50 and #87]
- 50 [closed] "Proposed change: tunnel vs. transport mode"
- 87 [closed] "Permit Security Gateways to use transport mode
when they are the outer header, nor does IPsec construct extension headers in endpoints of the outer header. However, post-IPsec code MAY insert/construct
extension headers communication"
When security is desired between two intermediate systems along a
path or between an intermediate system and an end system, transport
mode may now be used between security gateways and between a security
gateway and a host.

o [Issue #57] [closed] "ECN support"

The tunnel section has been updated to explain how to handle DSCP and
ECN bits.

o [Issue #67] [closed] "IPsec management traffic"

2401bis clarifies that for all traffic that crosses the outer header. IPsec
boundary, including IPsec management traffic, the SPD or associated
caches must be consulted.

Kent & Seo [Page 34] 53]

Internet Draft Security Architecture for IP January April 2004

5.2 Processing Inbound

o [Issue #68] [closed] "VPNs with overlapping IP Traffic (unprotected-to-protected)

2401bis now defines how to handle the corresponding SPD. Every
SPD SHOULD have situation of a nominal, final entry that catches anything that is
otherwise unmatched, and discards it. This ensures that non-IPsec
protected traffic that arrives security gateway
with multiple subscribers requiring separate IPsec contexts.

o [Issue #69] [closed] "Multiple protocols per SPD entry" -- Covered
by resolution of Issue #47

o [Issue #70] [closed] "Add diffserv (IPv4) and does not match any SPD-I entry
will class (IPv6) as
selectors -- Covered by Issues #48 and #57

o [Issue #71] [closed] "Add definition of reserved SPIs"

A definition of reserved SPIs has been added.

o [Issue #72] [closed] "Explain why ALL IP packets must be discarded.

Unprotected Interface
|
V
+-----+ IPsec protected
...................>|Demux|-------------------+
: +-----+ |
: | |
: | Not checked"

Text has been added explaining why ALL IP packets must be checked --
IPsec |
: |-----------+ |
: V | |
: +-------+ V V
+-----+ +-------+ |Bypass/| +------+ +------+
|SPD-O| |Discard|<---|Discard| | ICMP | |AH/ESP|
+-----+ +-------+ +-------+ +------+ +------+
^ | |
: | +---+ |
: Bypass | +-->|IKE| |
: | | +---+ |
: V | V
: +----------+ +---------+
:...............|Forwarding|<------------|SAD Check|
+----------+ +---------+
|
V
Protected Interface

Figure 3. Inbound Traffic Processing Model

Prior includes minimal firewall functionality to performing AH or ESP processing, any support access
control at the IP fragments that
arrive via layer.

o [Issue #73] [closed] "IP Option & Ext Hdr handling in Tunnel Mode"

The tunnel section has been updated to clarify how to handle the unprotected interface are reassembled (by IP). Each
inbound IP datagram
options field and IPv6 extension headers when constructing the outer
header.

o [Issue #74] [closed] "Inbound SA lookup -- multicast & unicast"

SA mapping for inbound traffic has been updated to which IPsec processing will be applied is
identified by the appearance of consistent with
the changes made in AH or and ESP values for support of unicast, anycast, and
multicast SAs.

o [Issue #75] [closed] "TOS (now ECN) copying in tunnel mode"

Guidance has been added re: how to handle the covert channel created
in tunnel mode by copying the IP Next
Protocol field (or DSCP value to outer header.

o [Issue #76] [accepted] "More explanation re: ESPv3 TFC padding &
dummy packets"

Modified ESP -- added more explanation re: ESPv3 TFC padding. IKEv2
to be modified to support negotiation of use of TFC padding.

o [Issue #77] [closed] "Should AH be mandatory?"

Support for AH or ESP as an extension header in the both IPv4 and IPv6 is now a MAY.

Kent & Seo [Page 35] 54]

Internet Draft Security Architecture for IP January April 2004

context).

IPsec MUST perform the following steps:

1. When a packet arrives, it may

o [Issue #78] [closed] "PMTU issues" -- Ongoing discussion: PMTU
discovery (Ravi Kumar (9/30/03), Michael Richardson (11/14/03 and
11/17/03) Will be tagged with the ID updated based on conclusion of the
interface (physical or virtual) via which it arrived, if necessary
to support multiple SPDs with different SPD-I entries.

2. The packet is examined and demuxed into one discussion on ICMP
handling.

o [Issue #79] [closed] "Detection of three categories:
- If the packet appears to be IPsec protected dead peers and it is addressed
to this device, an attempt is made to map it dead SAs -- No
change required; IKEv2 handles dead peer/SA detection

o [Issue #80] [closed] "Security gateway discovery" -- The IPSP
working group was supposed to produce an active SA
via the SAD.
- Traffic not addressed to this device is directed to
BYPASS/DISCARD lookup. If multiple SPDs are employed, the tag
assigned to the packet in step 1 is used to select the
appropriate SPD-I (and cache) to search.
- ICMP traffic directed to this device is directed to
"unprotected" ICMP processing (see Section 6).

3a. If the packet is addressed to the IPsec device ID on "SG discovery, Policy
Exchange and AH or ESP is
specified as the protocol, the packet is looked up in the SAD
identified by the SPD-ID from step 1. For unicast traffic, use
only the SPI. For multicast traffic, use the SPI plus the source
and/or destination addresses, as specified Negotiation Protocol" in the SAD. If there June 2003, but has not yet
posted this draft.

Added text saying "The IP Security Policy (IPSP) Working Group is
no match, discard the traffic. This a
possible future source of guidance. One of their goals is an auditable event. to produce
a Internet Draft on a "Security Gateway Discovery, Policy Exchange
and Negotiation Protocol."

o [Issue #81] [closed] "Handling outbound red fragments (e.g., on
separate SA)" The
audit log entry for Issues Tracking Database lists this event SHOULD include as Closed
(rejected). The working group rejected creation of a separate SA for
fragments. Based on a subsequent discussion on the current
date/time, SPI, source and destination mailing list,
2401bis was amended with 3 approaches.

Three approaches have been added for handling plaintext fragments on
the protected side of the packet, IPsec
protocol, and any other boundary. An appendix has been added
documenting the rationale behind them.

o [Issue #82] [closed] "Creation of SAs"

Current 2401bis draft has revised text re: how to derive selector
values of the packet that are
available. If the packet is found in the SAD, process it
accordingly (see step 4).

3b. If for SAs (from the packet is not addressed to SPD entry or from the device, look up packet, etc.). A new
table describing the packet
header relationship between selector values in an SPD
entry, the (appropriate) SPD-I cache. If there is a match PFP flag, and
the packet is to be discarded or bypassed, do so. If there is no
cache match, look up the packet resulting selector values in the
corresponding SPD-I and
create a cache entry as appropriate. (No SAs are created in
response to receipt of a packet that requires IPsec protection;
only bypass or discard entries can be created this way.) If there
is no match, discard the traffic. This is SAD entry. Also, an auditable event. The
audit log entry for this event SHOULD include the current
date/time, SPI if available, appendix on decorrelation has been
added.

o [Issue #83] [rejected] "DROP'd inbound packet -- missing required
IPsec protocol if available, source
and destination protection"

o [Issue #84] [closed] "DROP'd outbound packet"

If an IPsec system receives an outbound packet which it finds it must
discard, it SHOULD be capable of the packet, generating and any other selector values of
the packet that are available.

3c. Unprotected sending an ICMP processing is assumed
message to indicate to take place on the
unprotected side sender of the IPsec boundary. Unprotected ICMP messages
are examined and local policy is applied to determine whether to
accept or reject these messages and, if accepted, what action to outbound packet that the
packet was discarded.

o [Issue #85] [closed] "DROP'd inbound packet -- does not match SA"

Kent & Seo [Page 36] 55]

Internet Draft Security Architecture for IP January April 2004

take as a result. For example, if an ICMP unreachable message is
received, the implementation must decide whether to act on it,
reject it, or act on it with constraints. [See Section 6.]

4. Apply AH or ESP processing as specified, using the SAD entry
selected in step 2a above. Then match the packet against the
inbound selectors identified by the SAD entry to verify that the
received packet is appropriate for the SA via which it was
received.

If an IPsec system receives an inbound packet on an SA and the
packet's header fields are not consistent with the selectors for the
SA, it MUST drop SHOULD be able to send an IKE notification to the sender of
the packet.

o [Issue #86] [closed] "Add IPv6 mobility header message type as
selector"

IPv6 mobility header has been added as a possible Next Layer
Protocol. IPv6 mobility header message type has been added as a
selector.

o [Issue #87] [closed] "Permit Security Gateways to use transport
mode when they are the endpoints of the communication" -- See Issue
50.

o [Issue #88] [accepted] "Lift the prohibition on red-side
fragmentation by SG, BITS, BITW" -- See Issue 49.

o [Issue #89] [closed] " Remove the selector "name"" -- Rejected.
See issue 93.

o [Issue #90] [closed] "Remove the selector "data sensitivity level"
-- The selector "data sensitivity level" has been removed to simplify
things.

o [Issue #91] [pending] "Handling ICMP error messages" -- Ongoing
discussion

o [Issue #93] [pending] "Clarification re: the packet. This is an auditable event. selector "name""

The
audit log entry text for this event SHOULD include the current
date/time, SPI, IPsec protocol(s), source selector name has been updated and destination of the
packet, clarified.

o [ na ] "Next Layer Protocol" has been further explained and any other selector values a
default list of protocols to skip when looking for the packet Next Layer
Protocol has been added.

o [ na ] The text has been amended to say that are
available, and 2401bis assumes use of
IKEv2 or an SA management protocol with comparable features.

o [ na ] Text has been added clarifying the selector values from algorithm for mapping
inbound IPsec datagrams to SAs in the relevant SAD entry.
The system SHOULD also be capable presence of generating multicast SAs

o [ na ] Text and sending an IKE
notification ASN.1 description have been added to clarify the sender (IPsec peer), indicating that the
received packet was dropped because
structure of failure to pass selector
checks.

NOTIFY MESSAGES - ERROR TYPES Value
----------------------------- -----
INVALID_SELECTORS iana-tbd

MAY be sent in an IKE INFORMATIONAL Exchange when a node
receives an ESP or AH packet whose selectors do not match
those of the SA on which it was delivered (and which
caused the packet to SPD entry and its alignment with what can be dropped).
negotiated in IKE.

Kent & Seo [Page 56]

Internet Draft Security Architecture for IP April 2004

Acknowledgements

The Notification Data
contains authors would like to acknowledge the start contributions of Ran
Atkinson, who played a critical role in initial IPsec activities, and
who authored the offending packet (as first series of IPsec standards: RFCs 1825-1827.
Also a contributor who wishes to remain nameless, deserves special
thanks for providing extensive help in ICMP
messages) and the SPI field editing of the notification is set this
specification. The authors also would like to
match thank the SPI members of
the IPsec SA.

To minimize and MSEC working groups who have contributed to the impact
development of this protocol specification.

Kent & Seo [Page 57]

Internet Draft Security Architecture for IP April 2004

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., [Shi00, VK83, HA94]. Included in this glossary are generic
security service and security mechanism terms, plus IPsec-specific
terms.

Access Control

Access control is a DoS attack or security service that prevents unauthorized
use of a mis-configured peer, resource, including the
IPsec system SHOULD include prevention of use of a management control to allow resource
in an
administrator to configure unauthorized manner. In the IPsec implementation context, the resource to send or not
send this IKE notification, and if this facility
which access is selected, to rate
limit the transmission of such notifications.

After traffic being controlled is bypassed often:

o for a host, computing cycles or processed through IPsec, it 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 handed used informally to refer to the inbound forwarding function combination of two
nominally distinct security services, data origin authentication
and connectionless integrity. See the definitions below for disposition. This function may
cause each
of these services.

Availability
Availability, when viewed as a security service, addresses the packet to be sent across
security concerns engendered by attacks against networks that deny
or degrade service. For example, in the IPsec boundary for additional
inbound IPsec processing, e.g., context, the use of
anti-replay mechanisms in AH and ESP support of nested SAs. If so, then
as with ALL outbound traffic that availability.

Confidentiality
Confidentiality is to be bypassed, the packet MUST
be matched against an SPD-O entry. Ultimately, 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 packet should external characteristics of
communication also can be
forwarded to a concern in some circumstances.
Traffic flow confidentiality is the service that addresses this
latter concern by concealing source and destination host addresses,
message length, or process for disposition. 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 & Seo [Page 37] 58]

Internet Draft Security Architecture for IP January April 2004

6. ICMP Processing [This section will be filled in when IPsec issue # 91

Data Origin Authentication
Data origin authentication is resolved. The following text needs to be inserted somewhere,
possibly this section.]

NOTE: With a security service that verifies the exception
identity of IPv4 transport mode, the claimed source of data. This service is usually
bundled with connectionless integrity service.

Encryption
Encryption is a security mechanism used to transform data from an SG, BITS, or BITW
implementation MAY fragment packets before applying IPsec.
intelligible form (plaintext) into an unintelligible form
(ciphertext), to provide confidentiality. The
device SHOULD have inverse
transformation process is designated "decryption". Oftimes the
term "encryption" is used to generically refer to both processes.

Integrity
Integrity is a configuration setting security service that ensures that modifications to disable this. The
resulting fragments
data are evaluated against the SPD detectable. Integrity comes in the normal
manner. Thus, fragments not containing port numbers may only various flavors to match
rules having port selectors
application requirements. IPsec supports two forms of OPAQUE or "ANY".

7. Auditing

Not all systems integrity:
connectionless and a form of partial sequence integrity.
Connectionless integrity is a service that implement IPsec will implement auditing. For
the most part, detects modification of
an individual IP datagram, without regard to the granularity ordering of auditing is the
datagram in a local matter.
However, several auditable events are identified stream of traffic. The form of partial sequence
integrity offered in this document IPsec is referred to as anti-replay
integrity, and
for each it detects arrival of these events duplicate IP datagrams
(within a minimum set of information that SHOULD be
included in an audit log constrained window). This is defined. Additional information also MAY
be included in the audit log for each of these events, 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 additional
events, not explicitly called out integrity services
often are cited separately, in this specification, also MAY
result practice they are intimately
connected and almost always offered in audit log entries. tandem.

Protected vs Unprotected
"Protected" refers to the systems or interfaces that are inside
the IPsec protection boundary and "unprotected" refers to the
systems or interfaces that are outside the IPsec protection
boundary. IPsec provides a boundary through which traffic passes.
There is no requirement for the
receiver to transmit any message an asymmetry to the purported transmitter this barrier, which is reflected in
response to the detection of an auditable event, because
processing model. Outbound data, if not discarded or bypassed, is
protected via the application of AH or ESP and the
potential to induce denial addition of service the
corresponding headers. Inbound data, if not discarded or
bypassed, is processed via such action.

8. Conformance Requirements

All IPv4 systems that claim to implement IPsec MUST comply with all
requirements the removal of AH or ESP headers. In
this document. All IPv6 systems that claim to
implement document, inbound traffic enters an IPsec MUST comply with all requirements of this document.

9. Security Considerations

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

10. Differences from RFC 2401 [Will be updated when things have settled
down.]

This architecture document differs substantially implementation from RFC 2401 in
detail and in organization, but
the fundamental notions are
unchanged.

Kent & Seo [Page 38]

Internet Draft Security Architecture for IP January 2004

Acknowledgements

The authors would like to acknowledge "unprotected" interface. Outbound traffic enters the contributions
implementation via the "protected" interface, or is internally
generated by the implementation on the "protected" side of Ran
Atkinson, who played a critical role in initial IPsec activities, the
boundary and
who authored directed toward the first series of "unprotected" interface. An IPsec standards: RFCs 1825-1827.
Also a contributor who wishes to remain nameless, deserves special
thanks for providing extensive help
implementation may support more than one interface on either or
both sides of the boundary. The protected interface may be
internal, e.g., in the editing a host implementation of this
specification. IPsec. The authors also would like to thank the members of
the IPsec and MSEC working groups who have contributed protected
interface may link to a socket layer interface presented by the
development of this protocol specification.

Kent & Seo [Page 39] 59]

Internet Draft Security Architecture for IP January April 2004

Appendix

OS.

Security Association (SA)
A -- Glossary

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

Access Control
Access control purposes. All traffic traversing an SA is a provided the
same security service that prevents unauthorized
use of a resource, including processing. In IPsec, an SA is an internet layer
abstraction implemented through the prevention of use of a resource AH or ESP. State data
associated with an SA is represented in the Security Association
Database (SAD).

Security Gateway
A security gateway is an unauthorized manner. In intermediate system that acts as the IPsec context,
communications interface between two networks. The set of hosts
(and networks) on the resource to
which access is being controlled external side of the security gateway is often:
o for
termed unprotected (they are generally at least less protected
than those "behind" the SG), while the networks and hosts on the
internal side are viewed as protected. The internal subnets and
hosts served by a host, computing cycles or data
o for 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, a network behind the
gateway
or bandwidth on that network.

Anti-replay
[See "Integrity" below]

Authentication
This term is used informally to refer a point at which AH and/or ESP is implemented in order
to the combination serve a set of two
nominally distinct internal hosts, providing security services, data origin authentication
and connectionless integrity. See the definitions below services for each
of
these services.

Availability
Availability, hosts when viewed as a they communicate with external hosts also
employing IPsec (either directly or via another security service, addresses gateway).

SPI
Acronym for "Security Parameters Index" (SPI). The SPI is an
arbitrary 32-bit value that is used by a receiver to identify the
security concerns engendered
SA to which an incoming packet should be bound. For a unicast SA,
the SPI can be used by attacks against networks that deny itself to specify an SA, or degrade service. For example, it may be used
in conjunction with the IPsec context, the use of
anti-replay mechanisms protocol type. Additional IP
address information is used to identify multicast SAs. The SPI is
carried in AH and ESP support availability.

Confidentiality
Confidentiality is protocols to enable the security service that protects data from
unauthorized disclosure. The primary confidentiality concern in
most instances is unauthorized disclosure 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 application level
data, but disclosure 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 external characteristics of
communication also can be a concern bits in some circumstances. an SPI to
facilitate local processing.

Traffic Analysis
The analysis of network traffic flow confidentiality is for the service purpose of deducing
information that addresses this
latter concern by concealing source and destination addresses,
message length, or is useful to an adversary. Examples of such
information are frequency of communication. In transmission, the IPsec
context, using ESP in tunnel mode, especially at a security
gateway, can provide some level identities of traffic flow confidentiality.
(See also traffic analysis, below.)

Data Origin Authentication
Data origin authentication is a security service that verifies the
conversing parties, sizes of packets, flow identifiers, etc.
[Sch94]

Kent & Seo [Page 40] 60]

Internet Draft Security Architecture for IP January April 2004

identity of the claimed source of data.

Appendix B - Decorrelation

This service is usually
bundled with connectionless integrity service.

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.

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 section 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 based on work done for caching of partial sequence
integrity offered policies in IPsec is referred to as anti-replay
integrity, and it detects arrival of duplicate the IP datagrams
(within a constrained window). This
Security Policy Working Group by Luis Sanchez, Matt Condell, and John
Zao.

Two SPD entries are correlated if there is a non-null intersection
between the values of corresponding selectors in contrast to connection-
oriented integrity, which imposes more stringent sequencing
requirements on traffic, e.g., each entry. Caching
correlated SPD entries can lead to be able incorrect policy enforcement. A
solution 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.

Protected vs Unprotected
"Protected" refers this problem, that still allows for caching, is to remove
the systems or interfaces that are inside ambiguities by decorrelating the IPsec protection boundary and "unprotected" refers to entries. That is, the
systems or interfaces SPD
entries must be rewritten so that are outside the IPsec protection
boundary. IPsec provides for every pair of entries there
exists a barrier through which traffic passes.
There is an asymmetry to this barrier, selector for which there is reflected a null intersection between the
values in both of the
processing model. Outbound data, if not discarded or bypassed, is
protected via entries. Once the application of AH or ESP entries are decorrelated,
there is no longer any ordering requirement on them, since only one
entry will match any lookup. The next section describes
decorrelation in more detail and presents an algorithm that may be
used to implement decorrelation.

B.1 Decorrelation Algorithm

The basic decorrelation algorithm takes each entry in a correlated
SPD and divides it up into a set of entries using a tree structure.
The resulting entries that are decorrelated with the addition decorrelated set
of the
corresponding headers. Inbound data, if entries are then added to that decorrelated set.

The basic algorithm does not discarded or
bypassed, is processed via the removal of AH or ESP headers. In
this document, inbound traffic enters guarantee an IPsec implementation from
the "unprotected" interface. Outbound traffic enters the
implementation via optimal set of decorrelated
entries. That is, the "protected" interface, or entries may be broken up into smaller sets
than is emitted by the
implementation on necessary, though they will still provide all the "protected" side of necessary
policy information. Some extensions to the boundary basic algorithm are
described later to improve this and
directed toward improve the "unprotected" interface. An IPsec
implementation may support more than one interface on either or
both sides performance of the boundary.
algorithm.

C A set of ordered, correlated entries (a correlated SPD)
Ci The protected interface may be
internal, e.g., ith entry in a host implementation C.
U The set of IPsec. decorrelated entries being built from C
Ui The protected
interface may link to a socket layer interface presented by the
OS.

Kent & Seo [Page 41]

Internet Draft Security Architecture ith entry in U.
Sik The kth selection for IP January 2004

Security Association (SA)
A simplex (uni-directional) logical connection, created policy Ci
Ai The action 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. State data
associated with an SA is represented in the Security Association
Database (SAD).

Security Gateway policy Ci

A security gateway is an intermediate system that acts policy (SPD entry) P may be expressed as the
communications interface between two networks. The set of hosts
(and networks) on the external side a sequence of the security gateway is
termed unprotected (they are at generally at least less protected
than those "behind the SG), while the networks and hosts selector
values and on
the internal side are viewed an action (BYPASS, DISCARD, or PROTECT):

Ci = Si1 x Si2 x ... x Sik -> Ai

1) Put C1 in set U as protected. The internal subnets
and hosts served by a security gateway are presumed U1

For each policy Cj (j > 1) in C

Kent & Seo [Page 61]

Internet Draft Security Architecture for IP April 2004

2) If Cj is decorrelated with every entry in U, then add it to be trusted
by virtue of sharing a common, local, security administration.
(See "Trusted Subnetwork" below.) In the IPsec context, a
security gateway U.

3) If Cj is correlated with one or more entries in U, create a point tree
rooted at which AH and/or ESP is implemented
in order to serve the policy Cj that partitions Cj into a set of internal hosts, providing security
services for these hosts when they communicate with external hosts
also employing IPsec (either directly or via another security
gateway).

SPI
Acronym for "Security Parameters Index" (SPI). decorrelated
entries. The combination of
a destination address, algorithm starts with a security protocol, and an SPI uniquely
identifies root node where no selectors
have yet been chosen.

A) Choose a security association (SA, see above) selector in Cj, Sjn, that has not yet been chosen when
traversing the context
of unicast or anycast traffic. Additional IP address information tree from the root to this node. If there are no
selectors not yet used, continue to the next unfinished branch
until all branches have been completed. When the tree is used
completed, go to identify multicast SAs. The SPI step D.

T is carried the set of entries in AH and
ESP protocols to enable U that are correlated with the receiving system to select entry
at this node.

The entry at this node is the SA
under which a received packet will be processed. An SPI has only
local significance, as defined entry formed by the creator selector
values of the SA (usually
the receiver each of the packet carrying branches between the SPI); thus an SPI is
generally viewed as an opaque bit string. However, root and this node.
Any selector values that are not yet represented by branches
assume the creator of
an SA may choose to interpret corresponding selector value in Cj, since the bits values
in an SPI to facilitate
local processing.

Traffic Analysis
The analysis of network traffic flow for Cj represent the purpose of deducing
information that is useful maximum value for each selector.

B) Add a branch to an adversary. Examples of such
information are frequency of transmission, the identities of the
conversing parties, sizes of packets, flow identifiers, etc.
[Sch94]

Kent & Seo [Page 42]

Internet Draft Security Architecture tree for IP January 2004

Appendix B - Decorrelation

This section is based on work done in the IP Security Policy Working
Group by Luis Sanchez, Matt Condell, and John Zao.

Two SPD each value of the selector Sjn that
appears in any of the entries are correlated if there in T. (If the value is a non-null intersection
between superset
of the values value of corresponding selectors Sjn in each entry. Caching
correlated SPD entries can lead to incorrect policy enforcement. A
solution to this problem, Cj, then use the value in Cj, since that still allows
value represents the universal set.) Also add a branch for caching, is to remove the ambiguities by decorrelating
complement of the entries. That is, union of all the SPD
entries must be rewritten so that for every pair values of entries there
exists a the selector for which there Sjn
in T. When taking the complement, remember that the universal
set is a null intersection between the
values in both value of Sjn in Cj. A branch need not be created
for the entries. Once null set.

C) Repeat A and B until the entries are decorrelated,
there tree is no longer any ordering requirement on them, since only one
entry will match any lookup. completed.

D) The next section describes
decorrelation in more detail and presents an algorithm that may be
used entry to implement decorrelation.

B.1 Decorrelation Algorithm

The basic decorrelation algorithm takes each leaf now represents an entry in a correlated
SPD and divides it up into that is a set subset
of Cj. The entries using at the leaves completely partition Cj in
such a tree structure.
Those way that each entry is either completely overridden by
an entry in U, or is decorrelated with the entries in U.

Add all the decorrelated entries at the leaves of the resulting tree to U.

4) Get next Cj and go to 2.

5) When all entries that are decorrelated with the in C have been processed, then U will contain an
decorrelated set version of entries C.

There are then added several optimizations that can be made to this algorithm.
A few of them are presented here.

Kent & Seo [Page 62]

Internet Draft Security Architecture for IP April 2004

It is possible to optimize, or at least improve, the amount of
branching that decorrelated set.

The basic algorithm does not guarantee an optimal set occurs by carefully choosing the order of decorrelated
entries. That is, the entries may
selectors used for the next branch. For example, if a selector Sjn
can be broken up into smaller sets
than is necessary, though they will still provide chosen so that all the necessary
policy information. Some extensions to the basic algorithm values for that selector in T are
described later equal
to improve this and improve the performance or a superset of the
algorithm.

C A set of ordered, correlated entries (a correlated SPD)
Ci The ith entry in C.
U The set value of decorrelated entries being built from C
Ui The ith entry Sjn in U.

A policy (SPD entry) P may be expressed as Cj, then only a sequence single branch
needs to be created (since the complement will be null).

Branches of selector
values and an action (Bypass, Discard, or apply IPsec):

Pi = Si1 x Si2 x ... x Sik -> Ai

1) Put C1 in set U as U1 the tree do not have to proceed with the entire
decorrelation algorithm. For each policy Cj (j > 1) in C

2) If Cj example, if a node represents an entry
that is decorrelated with every entry all the entries in U, then add it there is no
reason to U.

Kent & Seo [Page 43]

Internet Draft Security Architecture for IP January 2004

3) If Cj continue decorrelating that branch. Also, if a branch is correlated with one or more entries
completely overridden by an entry in U, create a tree
rooted at then there is no reason to
continue decorrelating the policy Cj that partitions Cj into branch.

An additional optimization is to check to see if a set branch is
overridden by one of decorrelated
entries. The algorithm starts with a root node where no selectors
have yet been chosen.

A) Choose a selector the CORRELATED entries in Cj, Scjn, set C that has not yet already
been chosen when
traversing the tree from the root to this node. If there are no
selectors not yet used, continue to decorrelated. That is, if the next unfinished branch
until all branches have been completed. When the tree is
completed, go part of decorrelating
Cj, then check to step D.

T see if it was overridden by an entry Cm, m < j.
This is a valid check, since all the set of entries in U that Cm are correlated already expressed
in U.

Along with the entry
at this node.

The checking if an entry at this node is the entry formed already decorrelated in step 2,
check if Cj is overridden by the selector
values of each of the branches between the root and this node.
Any selector values that are any entry in U. If it is, skip it since
it is not yet represented by branches
assume the corresponding relevant. An entry x is overridden by another entry y if
every selector value in Cj, since the values in Cj represent the maximum value for each selector.

B) Add a branch x is equal to the tree for each value or a subset of the corresponding
selector Scjn that
appears in any entry y.

Kent & Seo [Page 63]

Internet Draft Security Architecture for IP April 2004

Appendix C -- Categorization of the entries in T. (If the value is a superset ICMP messages [May be deleted]

The tables below characterize ICMP messages as being either host
generated, router generated, both, unassigned/unknown. The first set
of the value messages are for IPv4. The second set of Scjn in Cj, then use messages are for IPv6.

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 value in Cj, since that
value represents Network (or subnet) [RFC792]
2 Redirect Datagram for the universal set.) Also add a branch Type of Service & Network[RFC792]
9 Router Advertisement [RFC1256]
18 Address Mask Reply [RFC950]

Kent & Seo [Page 64]

Internet Draft Security Architecture for IP April 2004

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 the
complement of the union of all the values Type of the selector Scjn Service [RFC792]
13 Communication Administratively Prohibited [RFC1812]
15 Precedence cutoff in T. When taking the complement, remember that the universal
set is effect [RFC1812]
4 Source Quench [RFC792]
5 Redirect
1 Redirect Datagram for the value of Scjn in Cj. A branch need not be created Host [RFC792]
3 Redirect Datagram for the null set.

C) Repeat A Type of Service and B until the tree is completed.

D) The entry 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 & Seo [Page 65]

Internet Draft Security Architecture for IP April 2004

IPv6

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

Type Name/Codes Reference
========================================================================
ROUTER GENERATED:
1 Destination Unreachable [RFC1885]
0 No Route to each leaf now represents an entry that Destination
1 Comm. w/Destination is Administratively Prohibited
2 Not a subset
of Cj. The entries at the leaves completely partition Cj in
such a way that each entry is either completely overridden by
an entry in U, or is decorrelated with the entries in U.

Add all the decorrelated entries at the leaves of the tree to U.

4) Get next Cj and go to 2.

5) When all entries Neighbor
3 Address Unreachable
2 Packet Too Big [RFC1885]
0
3 Time Exceeded [RFC1885]
0 Hop Limit Exceeded in C have been processed, then U will contain an
decorrelated version of C.

There are several optimizations that can be made to this algorithm.
A few of them are presented here.

It is possible to optimize, or at least improve, the amount of
branching that occurs by carefully choosing the order of the Transit
1 Fragment reassembly time exceeded

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

Kent & Seo [Page 44] 66]

Internet Draft Security Architecture for IP January April 2004

selectors used for the next branch. For example, if a selector Scjn
can be chosen so that all the values for that selector in T are equal
to or a superset of the value of Scjn in Cj, then only a single
branch needs to be created (since the complement will be null).

Branches of the tree do not have to proceed with the entire
decorrelation algorithm. For example, if a node represents

Appendix D -- ASN.1 for an SPD entry
that is decorrelated with all the entries (work in U, then there is no
reason progress)

This appendix uses ASN.1 syntax to continue decorrelating describe the information that branch. Also, if a branch is
completely overridden by an entry
contained in U, then there is no reason an SPD. Since it describes encodings that are to
continue decorrelating be
used with the branch. key management protocol, e.g., IKEv2, using ASN.1
constraints, it will not compile as shown due to "duplicate" tags.

-- An additional optimization SPD is to check to see if a branch is
overridden by one list of the CORRELATED entries policies in set C decreasing order of preference
SPD ::= SEQUENCE OF SPDEntry

-- An entry describes either traffic to be afforded IPsec protection
-- or traffic that has already
been decorrelated. That is, if the branch is part of decorrelating
Cj, then check to see if it was overridden by an be bypassed or discarded
SPDEntry ::= CHOICE {
iPsecEntry IPsecEntry, -- PROTECT traffic
bypassOrDiscard BypassOrDiscardEntry } -- DISCARD/BYPASS
-- traffic

-- A "selector set"
IPsecEntry ::= SEQUENCE { -- Each entry Cm, m < j.
This is a valid check, since all consist of:

name SEQUENCE {
passed SET OF Names, -- Matched to IKE ID
local SET OF Names }, -- Used internally

-- Populate from packet flags
pFPs BIT STRING { -- applies to ALL of the entries Cm are already expressed
in U.

Along with checking if an entry is already decorrelated in step 2,
check if Cj is overridden by any entry in U. If it is, skip it since
it is correspond-
pfpLocalAddr (0), -- ing traffic selectors;
pfpRemoteAddr (1), -- one does not relevant. An entry x is overridden by want to
pfpProtocol (2), -- allow some SelectorSet
pfpLocalNext (3), -- items to use one value
pfpRemoteNext (4)}, -- and some to use another entry y if
every selector in x is equal

-- Policy "condition"
condition SET OF SelectorList,

-- Policy "action"
processing SEQUENCE {
mode BOOLEAN, -- TRUE: transport, FALSE: tunnel
extSeqNum BOOLEAN, -- TRUE: 64 bit, FALSE: 32 bit
fragCheck BOOLEAN, -- TRUE: stateful fragment checking,
-- FALSE: no stateful fragment
-- checking

[need to or a subset of add fields/etc. for the corresponding
selector in entry y. following
SEQ counter overflow
SA lifetime
manual SPI

Kent & Seo [Page 45] 67]

Internet Draft Security Architecture for IP January April 2004

Appendix C

DS
ECN
DF
Flow Label]

CHOICE {
aH IntegrityAlgs,
eSP SEQUENCE {
IntegrityAlgs,
ConfidentialityAlgs } } } }

Names ::= CHOICE { -- IKEv2 IDs:
DistinguishedName, -- ID_DER_ASN1_DN
FQDN, -- ID_FQDN
RFC822Name } OPTIONAL, -- ID_RFC822_ADDR

BypassOrDiscardEntry ::= SEQUENCE {
action BOOLEAN, -- TRUE: BYPASS, FALSE: DISCARD
outbound SET OF SelectorList OPTIONAL, -- one or both may
inbound SET OF SelectorList OPTIONAL } -- Categorization of ICMP messages [May be deleted]

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

-- A "selector set"
SelectorList ::= SEQUENCE {
localAddr AddrList,
remoteAddr AddrList,

protocol CHOICE {
-- Representation for IPv6.

IPv4

Type Name/Codes Reference
========================================================================
ROUTER GENERATED:
3 Destination Unreachable
0 Net Unreachable [RFC792]
4 Fragmentation Needed, Don't ANY protocol
anyProt SEQUENCE {
INTEGER (0), -- ANY protocol
SEQUENCE { -- with either
ANY, -- ANY next layer selector
ANY }, -- ANY next layer selector

-- Protocols that have no next layer items
noNext SEQUENCE {
INTEGER (2..254),
SEQUENCE { -- if protocol has no next
OPAQUE,
OPAQUE } },

-- Fragments that have no next layer information
frag SEQUENCE {
INTEGER (44), -- 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 identifier
SEQUENCE {
OPAQUE,
OPAQUE } },

Kent & Seo [Page 68]

Internet Draft Security Architecture for Type IP April 2004

-- Protocols that have one next layer item
oneNext SEQUENCE {
INTEGER (1..254), -- ICMP, MH, ICMPv6
SEQUENCE { -- ICMP Type*256+Code
type NextChoice, -- MH Type*256
OPAQUE } },

-- Protocols that have two next layer items
twoNext SEQUENCE {
INTEGER (2..254), -- Protocol
SEQUENCE {
local NextChoice, -- Local and
remote NextChoice }}} -- Remote ports
}

NextChoice ::= CHOICE {
aNY ANY,
oPAQUE OPAQUE,
range Next }

-- Representation of Service[RFC792]
5 Redirect
0 Redirect Datagram for the Network (or subnet) [RFC792]
2 Redirect Datagram ANY in next layer field
ANY ::= SEQUENCE {
start INTEGER (0),
end INTEGER (65535) }

-- Representation of OPAQUE in next layer field
OPAQUE ::= SEQUENCE {
start INTEGER (65535),
end INTEGER (0) }

-- Range for the Type a next layer field
Next ::= SEQUENCE {
start INTEGER (0..65535),
end INTEGER (0..65535) }

-- List of Service & Network[RFC792]
9 Router Advertisement [RFC1256]
18 Address Mask Reply [RFC950] IP addresses
AddrList ::= SEQUENCE {
IPv4List OPTIONAL,
IPv6List OPTIONAL }

Kent & Seo [Page 46] 69]

Internet Draft Security Architecture for IP January 2004

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 Host [RFC792]
3 Redirect Datagram for the Type of Service and 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]

-- IPv4 address representations
IPv4List ::= CHOICE {
anyIPv4 SEQUENCE {
OCTET STRING ('00000000'H) (SIZE (4)),
OCTET STRING ('FFFFFFFF'H) (SIZE (4)) },
ipv4List SET OF CHOICE {
ipv4Addr OCTET STRING (SIZE (4)),
ipv4Range SEQUENCE { -- close, but not quite right ...
ipv4Start OCTET STRING ('00000001'H..'FFFFFFFE'H)
(SIZE (4)),
ipv4End OCTET STRING ('00000001'H..'FFFFFFFE'H)
(SIZE (4)) } } }

-- IPv6 address representations
IPv6List ::= CHOICE {
anyIPv6 SEQUENCE {
OCTET STRING
('00000000000000000000000000000000'H)
(SIZE (16)),
OCTET STRING
('FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF'H)
(SIZE (16)) },
ipv6List SET OF CHOICE {
ipv6Addr OCTET STRING (SIZE (16)),
ipv6Range SEQUENCE { -- close, but not quite right ...
ipv6Start OCTET STRING
('00000000000000000000000000000001'H
..'FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE'H)
(SIZE (16)),
ipv6End OCTET STRING
('00000000000000000000000000000001'H
..'FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE'H)
(SIZE (16))
} } }

-- Integrity Algorithms, ordered by decreasing preference
IntegrityAlgs ::= SEQUENCE OF IntegAlg

-- Confidentiality Algorithms, ordered by decreasing preference
ConfidentialityAlgs ::= SEQUENCE OF ConfAlg

Kent & Seo [Page 47] 70]

Internet Draft Security Architecture for IP January April 2004

IPv6

Type Name/Codes Reference
========================================================================
HOST GENERATED:
1 Destination Unreachable [RFC 1885]
4 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

-- Integrity Algorithms
IntegAlg ::= SEQUENCE {
algorithm ENUMERATED {
NONE (0),
AUTH_HMAC_MD5_96 (1),
AUTH_HMAC_SHA1_96 (2),
AUTH_DES_MAC (3),
AUTH_KPDK_MD5(4),
AUTH_AES_XCBC_96 (5),
TBD (6..65535) },
parameters ANY DEFINED BY algorithm OPTIONAL }

-- Confidentiality Algorithms
ConfAlg ::= SEQUENCE {
algorithm ENUMERATED {
ENCR_DES_IV64 (1),
ENCR_DES (2),
ENCR_3DES (3),
ENCR_RC5 (4),
ENCR_IDEA (5),
ENCR_CAST (6),
ENCR_BLOWFISH (7),
ENCR_3IDEA (8),
ENCR_DES_IV32 (9),
ENCR_RC4 (10),
ENCR_NULL (11),
ENCR_AES_CBC (12),
ENCR_AES_CTR (13),
TBD (14..65535) },
parameters ANY DEFINED BY algorithm OPTIONAL }

Kent & Seo [Page 71]

Internet Draft Security Architecture for IP April 2004

Appendix E -- Fragment reassembly time exceeded

[Will be added in next draft -- based on write up Steve distributed
on the list plus subsequent discussion.]

Kent & Seo [Page 48] 72]

Internet Draft Security Architecture for IP January April 2004

References

[Will be updated after the text settles down]

Normative

[Bra97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.

[DH98] Deering, S., and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.

[Eas03] Eastlake, D., "Cryptographic Algorithm Implementation
Requirements For ESP And AH", draft-ietf-ipsec-esp-ah-
algorithms-00.txt, December 2003.

[HC03] Holbrook, H., and Cain, B., "Source Specific Multicast for
IP", Internet Draft, draft-ietf-ssm-arch-01.txt, November
3, 2002.

[Kau03] Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol",
draft-ietf- ipsec-ikev2-11.txt, October 2003

[Ken04a] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
???, ???? 2004.

[Ken04b] Kent, S., "IP Authentication Header", RFC ???, ??? 2004.

[Mobip] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in
IPv6", Internet Draft, draft-ietf-mobileip-ipv6-24.txt,
June 2003

[Pos81] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981

[Sch03] Schiller, J., "Cryptographic Algorithms for use in the
Internet Key Exchange Version 2", draft-ietf-ipsec-
ikev2-algorithms-04.txt, September 2003

Informative

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

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

Kent & Seo [Page 49] 73]

Internet Draft Security Architecture for IP January April 2004

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.

[FaLiHaMeTr00]Farinacci, D., Li, T., Hanks, S., Meyer, D., Traina,
P., "Generic Routing Encapsulation (GRE), RFC 2784, March
2000.

[Gro02] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.

[HA94] Haller, N., and Atkinson, R., "On Internet Authentication",
RFC 1704, October 1994

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

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

[IBK93] Ioannidis, J., Blaze, M., and Karn, P., "swIPe: Network-
Layer Security for IP", presentation at the Spring 1993
IETF Meeting, Columbus, Ohio

[Ken91] Kent, S., "US DoD Security Options for the Internet
Protocol", RFC 1108, November 1991.

[MSST97] Maughan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.

[NiBlBaBL98]Nichols, K., Blake, S., Baker, F., Black, D., "Definition
of the Differentiated Services Field (DS Field) in the IPv4
and IPv6 Headers", RFC2474, December 1998.

[Orm97] Orman, H., "The OAKLEY Key Determination Protocol", RFC
2412, November 1998.

[Per96] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.

Kent & Seo [Page 74]

Internet Draft Security Architecture for IP April 2004

[Pip98] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.

Kent & Seo [Page 50]

Internet Draft Security Architecture for IP January 2004

[RaFlBL01]Ramakrishnan, K., Floyd, S., Black, D., "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.

[RFC3547] Baugher, M., Weis, B., Hardjono, T., Harney, H., "The Group
Domain of Interpretation", RFC 3547, July 2003.

[RFC3740] Hardjono, T., Weis, B., "The Multicast Group Security
Architecture", RFC 3740, March 2004.

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

[Shi00] Shirey, R., "Internet Security Glossary", RFC 2828, May
2000.
[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.

[SMPT98] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 2393, August
1998.

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

Author Information

Stephen Kent
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
USA

Phone: +1 (617) 873-3988
EMail: kent@bbn.com

Kent & Seo [Page 75]

Internet Draft Security Architecture for IP April 2004

Karen Seo
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
USA

Phone: +1 (617) 873-3152
EMail: kseo@bbn.com

Kent & Seo [Page 51] 76]

Internet Draft Security Architecture for IP January April 2004

Notices

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards- related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

Kent & Seo [Page 52] 77]

Internet Draft Security Architecture for IP January April 2004

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Expires July October 2004

Kent & Seo [Page 53] 78]
----