WDIFF

draft-ietf-ipsec-rfc2401bis-00.txt --> draft-ietf-ipsec-rfc2401bis-01.txt-134146.txt

Network Working Group S. Kent
Internet Draft K. Seo
draft-ietf-ipsec-rfc2401bis-01.txt BBN Technologies
draft-ietf-ipsec-rfc2401bis-00.txt October 2003
Obsoletes: RFC 2401 January 2004
Expires April July 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/lid-abstracts.html
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 [Page 1]

Internet Draft Security Architecture for IP October 2003 January 2004

Table of Contents

1. Introduction.........................................................4 Introduction.........................................................3
1.1 Summary of Contents of Document.................................4 Document.................................3
1.2 Audience........................................................4 Audience........................................................3
1.3 Related Documents...............................................5 Documents...............................................4
2. Design Objectives....................................................5 Objectives....................................................4
2.1 Goals/Objectives/Requirements/Problem Description...............5 Description...............4
2.2 Caveats and Assumptions.........................................6 Assumptions.........................................5
3. System Overview .....................................................7 .....................................................6
3.1 What IPsec Does.................................................7 Does.................................................6
3.2 How IPsec Works.................................................8
3.3 Where IPsec May Be Implemented..................................9
4. Security Associations................................................9 Associations...............................................10
4.1 Definition and Scope...........................................10
4.2 Security Association Functionality.............................12 Functionality.............................13
4.3 Combining Security Associations................................13
4.4 Security Association Databases.................................15 Major IPsec Databases..........................................14
4.4.1 The Security Policy Database (SPD)........................16 (SPD)........................15
4.4.2 Selectors.................................................20 Selectors.................................................19
4.4.3 Security Association Database (SAD).......................25 (SAD).......................22
4.5 Basic Combinations of Security Associations....................28
4.6 SA and Key Management..........................................31
4.6.1 Management..........................................24
4.5.1 Manual Techniques.........................................31
4.6.2 Techniques.........................................24
4.5.2 Automated SA and Key Management...........................31
4.6.3 Management...........................25
4.5.3 Locating a Security Gateway...............................32
4.7 Gateway...............................26
4.6 Security Associations and Multicast............................33 Multicast............................26
5. IP Traffic Processing...............................................34 Processing...............................................27
5.1 Outbound IP Traffic Processing.................................34 Processing (protected-to-unprotected)......28
5.1.1 Selecting and Using Handling an SA or SA Bundle....................34 Outbound Packet That Must Be Dropped..........??
5.1.2 Header Construction for Tunnel Mode.......................35 Mode.......................30
5.1.2.1 IPv4 -- Header Construction for Tunnel Mode..........36 Mode..........32
5.1.2.2 IPv6 -- Header Construction for Tunnel Mode..........37 Mode..........33
5.2 Processing Inbound IP Traffic..................................38
5.2.1 Selecting and Using an SA or SA Bundle....................38
5.2.2 Handling of AH and ESP tunnels............................41 Traffic (unprotected-to-protected).......34
6. ICMP Processing (relevant to IPsec).................................41
6.1 PMTU/DF Processing.............................................42
6.1.1 DF Bit....................................................42
6.1.2 Path MTU Discovery (PMTU).................................42
6.1.2.1 Propagation of PMTU..................................42
6.1.2.2 Calculation of PMTU..................................43
6.1.2.3 Granularity of PMTU Processing.......................43
6.1.2.4 PMTU Aging...........................................44 IPsec).................................36
7. Auditing............................................................45 Auditing............................................................37
8. Use in Systems Supporting Information Flow Security.................45
8.1 Relationship Between Security Associations and Data Sensitivity.46
8.2 Sensitivity Consistency Checking...............................47

Kent [Page 2]

Internet Draft Security Architecture for IP October 2003

8.3 Additional MLS Attributes for Security Association Databases...47
8.4 Additional Inbound Processing Steps for MLS Networking.........47
8.5 Additional Outbound Processing Steps for MLS Networking........48
8.6 Additional MLS Processing for Security Gateways................48
9. Performance Issues..................................................48
10. Conformance Requirements...........................................49
11. Requirements............................................37
9. Security Considerations............................................49
12. Considerations.............................................37
10. Differences from RFC 2401..........................................49
Acknowledgements.......................................................50 2401..........................................37
Acknowledgements.......................................................37
Appendix A -- Glossary.................................................51 Glossary.................................................38
Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues......54
B.1 DF bit.........................................................54
B.2 Fragmentation..................................................54
B.3 Path MTU Discovery.............................................58
B.3.1 Identifying the Originating Host(s).......................59
B.3.2 Calculation of PMTU.......................................61
B.3.3 Granularity of Maintaining PMTU Data......................62
B.3.4 Per Socket Maintenance of PMTU Data.......................63
B.3.5 Delivery of PMTU Data to the Transport Layer..............63
B.3.6 Aging of PMTU Data........................................63 Decorrelation............................................41
Appendix C -- Sequence Space Window Code Example.......................64
Appendix D -- Categorization of ICMP messages..........................66
References.............................................................69 messages [May be deleted].........44
References.............................................................47
Author Information.....................................................71
Notices................................................................71 Information.....................................................49
Notices................................................................50

Kent [Page 3] 2]

Internet Draft Security Architecture for IP October 2003 January 2004

1. Introduction

1.1 Summary of Contents of Document

This memo document specifies the base architecture for IPsec compliant
systems. The goal of the architecture is It describes how to provide various a set of security services for
traffic at the IP layer, in both the IPv4 and IPv6 environments.
This document describes the goals requirements for systems that implement
IPsec, the fundamental elements of such systems,
their components and how they the elements
fit together with each other 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. Subsequent Other documents will
address additional architectural details of a more advanced nature, in specialized environments,
e.g., use of IPsec in NAT environments and more complete comprehensive support
for IP multicast. The
following 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 automatic automated (The Internet Key
Exchange (IKE))
d. Algorithms Cryptographic algorithms for authentication and encryption

This document is not an overall 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 standard. used throughout this and all
related IPsec standards. All other capitalizations of IPsec (e.g.,
IPSEC, IPSec, ipsec) are deprecated. However, any capitalization of IPsec
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 includes implementers of is primarily individuals who
implement this IP security technology and others interested in gaining a general
background understanding of or who architect systems that
will use this system. In particular, prospective

Kent [Page 4]

Internet Draft Security Architecture for IP October 2003 technology. Technically adept users of this technology
(end users or system administrators) also are part of the target

Kent [Page 3]

Internet Draft Security Architecture for IP January 2004

audience. A glossary is provided as an appendix to help fill in gaps
in background/vocabulary. This document assumes that the reader is
familiar with the Internet Protocol, 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. "IP Security Document Roadmap" [TDG97] -- a document providing
guidelines for specifications describing encryption and
authentication algorithms used in this system.

b. security protocols -- RFCs describing the Authentication Header
(AH) [KA98a] [Ken04b] and Encapsulating Security Payload (ESP) [KA98b] [Ken04a]
protocols.

c.
b. cryptographic algorithms for authentication integrity and encryption -- one RFC
that defines the mandatory, default algorithms for use with AH
and ESP [Eas03], a separate similar RFC that defines the mandatory
algorithms for each use with IKEv2 [Sch03] plus a separate RFC for
each cryptographic algorithm.

d.
c. automatic key management -- RFCs on "The Internet Key Exchange
(IKE)" [HC98], "Internet Security Association and Key Management
Protocol (ISAKMP)" [MSST97],"The OAKLEY Key Determination
(IKEv2) Protocol"
[Orm97], [Kau03] and "The Internet IP Security Domain of Interpretation "Cryptographic Algorithms for ISAKMP" [Pip98]. 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, protection against detection and rejection of
replays (a form of partial sequence integrity), confidentiality (encryption), (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 and/or next
layer protocols.

IPsec provides in a range of security services to help secure
communication for the computers and networks it protects. In addition
to standard fashion
(including IP layer confidentiality and integrity, receiver-optional anti-
replay and data origin authentication (via SA key management), IPsec
also provides access control for all traffic traversing it. Thus itself).

IPsec includes a specification for minimal firewall functionality,

Kent [Page 5]

Internet Draft Security Architecture for IP October 2003
since that is a necessary part an essential aspect of secure IP. 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.

These objectives (Note that interoperability may
suffer if additional firewall constraints on traffic flows are met
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 [Page 4]

Internet Draft Security Architecture for IP January 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 firewall (one not privy to
IPsec internal parameters).

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 any a context, and the ways in which they are
employed, will be determined by the security users/administrators in that
context. It is the goal of the IPsec architecture to ensure that
compliant implementations include the services and system management
interfaces needed to meet the security requirements of users,
applications, and/or sites/organizations. a broad user
population.

When these mechanisms are IPsec is correctly implemented and deployed, they it ought not to
adversely affect users, hosts, and other Internet components that do
not employ these security mechanisms IPsec for
protection of their traffic. These mechanisms also 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 standard 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 [Page 5]

Internet Draft Security Architecture for IP January 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.

Kent [Page 6]

Internet Draft Security Architecture for IP October 2003

3. System Overview [Will change to reflect decisions re: [40],[44],[45]
processing model; and [46] nesting and bundling of SAs]

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 or host, as a security gateway
environment, 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 transport next
layer header information (Selectors, Section 4.4.2) matched against
entries in the database (SPD). Each packet is either afforded IPsec
security services, discarded, or allowed to bypass IPsec, IPsec protection,
based on the applicable database SPD policies identified by the Selectors.

3.1 What IPsec Does

IPsec provides creates a boundary between unprotected and protected
interfaces, for a host or a network (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 by enabling a system
to select required through selection of
appropriate security protocols, determine the algorithm(s) to
use for the service(s), cryptographic algorithms, and put in place any
cryptographic keys
required to provide the requested services. keys. IPsec can be used to protect one or more "paths"
between a pair of hosts, between a pair of security gateways, or
between a security gateway and a host. (The
term "security gateway" is used throughout the IPsec documents to
refer to an intermediate system that implements IPsec protocols. For
example, a router or a firewall implementing IPsec is a security
gateway.)

The set of security services that IPsec can provide includes access
control, connectionless integrity, data origin authentication,
rejection of replayed packets (a form Compliant implementations MUST
support all three forms of partial sequence integrity),
confidentiality (encryption), and limited traffic flow
confidentiality. Because these services are provided at the connectivity noted here.

Kent [Page 6]

Internet Draft Security Architecture for IP
layer, they can January 2004

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 used by any higher layer protocol, 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., TCP, UDP,
ICMP, BGP, etc. in a host
implementation of 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 DOI also 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 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 [Page 7]

Internet Draft Security Architecture for IP October 2003

layers. January 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 more detail in their respective RFCs
[KA98a, KA98b]. IPsec implementations MUST support ESP and MAY
support AH.

o The IP Authentication Header (AH) [KA98a] provides connectionless
integrity, data origin authentication, and an optional anti-replay
service.

o The Encapsulating Security Payload (ESP) protocol [KA98b] may
provide confidentiality (encryption), and limited traffic flow
confidentiality. It also may provide connectionless (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, and an with optional (at the discretion of
the receiver) anti-replay service. (One or features.

o The Encapsulating Security Payload (ESP) protocol [Ken04a] offers
the
other same set of these security services must be applied whenever services, and also offers confidentially. Use of
ESP in a confidentiality-only mode is discouraged. When ESP is invoked.)
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 are vehicles for offer access control, based on enforced through the
distribution of cryptographic keys and the management of traffic
flows relative to these security protocols. as dictated by the Security Policy Database (SPD, Section 4.4).

These protocols may be applied alone individually or in combination with
each other to provide a desired set of 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 the protocols mode, AH and ESP provide protection
primarily for next layer protocols; in tunnel mode, the protocols AH and ESP are
applied to tunneled IP packets. The differences between the two
modes are discussed in Section 4.

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 IPsec, through the SPD management must incorporate paradigm,
incorporates facilities for specifying:

o which security services to use and in what combinations

Kent [Page 8]

Internet Draft Security Architecture for IP January 2004

o the granularity at which a given security protection should be applied
o the cryptographic algorithms used to effect cryptographic-based
security

Because these most of the security services provided by IPsec require the
use shared secret values
(cryptographic keys), of cryptographic keys, IPsec relies on a separate set of
mechanisms

Kent [Page 8]

Internet Draft Security Architecture for IP October 2003 for putting these keys in place. (The keys are used for
authentication/integrity and encryption services.) This document requires
support for both manual and automatic automated distribution of keys. It
specifies a specific public-key based approach (IKE -- [MSST97,
Orm97, HC98]) (IKEv2 [KAU04]) for automatic
automated key management, but other automated key distribution
techniques MAY be used. For example, KDC-based systems
such as Kerberos and other public-key systems such as SKIP could be
employed.

3.3 Where IPsec May Be Implemented

There are several

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 and destination 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 host, or
in conjunction with a router or firewall (to to create a security
gateway). Several common examples are provided below:
gateway, or as an independent security device.

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

b. "Bump-in-the-stack" In a "bump-in-the-stack" (BITS) implementations, where 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 outboard crypto dedicated, inline security protocol processor
is a common design feature of network security systems used by the military,
and of some commercial systems as well. It is sometimes
referred to as a
"Bump-in-the-wire" "bump-in-the-wire" (BITW) implementation.
Such implementations may be designed to serve either a host
or a gateway (or both). gateway. Usually the BITW device is itself IP addressable.
When supporting a single host, it may be quite analogous to a

Kent [Page 9]

Internet Draft Security Architecture for IP January 2004

BITS implementation, but in supporting a router or firewall,
it must operate like a security gateway.

4. Security Associations [Will change to reflect decisions re: -
[40,44,45] changes

This document often talks in processing model (caching, etc.); - [46]
nesting/bundling terms of SAs; - [67] IPsec management traffic; - [82]
clarification re: creation host or security gateway use of SAs]
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. 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

Kent [Page 9]

Internet Draft Security Architecture for IP October 2003
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, and SA management techniques.

4.1 Definition and Scope [May change to reflect decisions re: [50]
should transport support by SG be MAY or MUST and [87] follow-on
proposed approach]

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 is are applied to a traffic stream, then two
(or more)
SAs are must be created and coordinated to afford effect protection to through
iterated application of the traffic stream. security protocols. To secure typical,
bi-directional communication between two hosts, or
between two security gateways, two IPsec-enabled systems, a
pair of Security Associations (one in each direction) are required.

A security association is uniquely identified by a triple consisting
IKE explicitly creates SA pairs in recognition of a Security Parameter Index (SPI), this common usage
requirement.

For an IP Destination Address, and a
security protocol (AH or ESP) identifier. The set of SPI values in
the range 1 through 255 are reserved by SA used to carry unicast (or anycast) traffic, the Internet Assigned Numbers
Authority (IANA) for future use. A reserved SPI value will not
normally be assigned
(Security Parameters Index - see Appendix A and AH [Ken04b] and ESP
[Ken04a] specifications) by IANA unless the use of the assigned SPI value
is specified in itself suffices to specify an RFC. The SPI value of zero (0) is reserved for
local implementation-specific use and MUST NOT be sent on the wire.
For example, SA.
However, as a key management local matter, an implementation MAY may choose to use the zero
SPI
value to mean "No Security Association Exists" during the period when in conjunction with the IPsec implementation has requested that its key management entity
establish a new SA, but the protocol type (AH or ESP) for SA has not yet been established. In
principle, the Destination Address may be a unicast address,
identification. If an IP
broadcast address, or a IPsec implementation supports multicast, then
it MUST support multicast group address. However, SAs using the algorithm described in AH and
ESP for mapping inbound IPsec SA
management mechanisms currently are defined protected datagrams to SAs.
(Implementations that support only for unicast SAs.
Hence, in the discussions traffic need not implement
that follow, SAs will be described
primarily in the context of point-to-point communication, even though
the concept is applicable in the point-to-multipoint case as well. demultiplexing algorithm.)

Note: If different classes of traffic (distinguished by DSCP bits) bits

Kent [Page 10]

Internet Draft Security Architecture for IP January 2004

[NiBlBaBL98], [Gro02]) are sent on the same SA, this could result 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 the same
selector values, on different SAs to appropriately support QoS. To
permit this, the IPsec implementation MUST permit establishment and
maintenance of multiple SAs between a given sender and receiver, with
the same selectors. Distribution of traffic among these parallel SAs
to support QoS is locally determined by the sender and is not
negotiated

Kent [Page 10]

Internet Draft Security Architecture for IP October 2003 by IKE. The receiver MUST process the packets from the
different SAs without prejudice.

DISCUSSION: While the DSCP [NiBlBaBL98, Gro02] and ECN [RaFlBL01]
fields are not "selectors", as that term in used in this
architecture, the sender will need a mechanism to direct packets with
a given (set of) DSCP values to the appropriate SA. This mechanism
might be termed a "filter". "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 of the same mode, transport or
tunnel.

A transport mode SA is a security association typically employed
between
two hosts. Also, in the case where a pair of hosts 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 two security gateways.
gateways or between a security gateway and a host. In the latter
case, transport mode
would may be used to support IP-in-IP [Per96] or GRE
tunneling [FaLiHaMeTr00] over transport mode SAs. Note that the The access control
functions that are an important part of IPsec are significantly constrained
limited in this
context. So context, as they cannot be applied to the end-to-end
headers of the packets that traverse a transport mode SA used in this
fashion. Thus this way of using transport mode should be evaluated
carefully before being employed. 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 higher next
layer protocols (e.g., TCP or UDP). In IPv6, the security protocol
header appears after the base IP header and extensions, selected extension
headers, but may appear before or after destination
options, and options; it MUST
appear before higher next layer protocols. In the case of ESP, a transport
mode SA provides security services only for these higher next layer
protocols, not for the IP header or any extension headers preceding
the ESP header. In the case of AH, the protection is also extended
to selected portions of the IP header, header preceding it, selected portions
of extension headers, and selected options (contained in the IPv4
header, IPv6 Hop- by-Hop Hop-by-Hop extension header, or IPv6 Destination

Kent [Page 11]

Internet Draft Security Architecture for IP January 2004

extension headers). For more details on the coverage afforded by AH,
see the AH specification [KA98a]. [Ken04b].

A tunnel mode SA is essentially an SA applied to an IP tunnel. With
only a couple tunnel, with
the access controls applied to the headers of exceptions, the traffic inside the
tunnel. In general, whenever either end of a security association is
a security gateway, the SA MUST be 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. Note that for the case where
traffic is destined for a security gateway, e.g., SNMP commands, the
security gateway is acting as a host and transport mode is allowed. But in that
In this case, the SA terminates at a host (management) function
within a security gateway is not acting as
a gateway, i.e., not transiting traffic. and thus merits different treatment. Also,
as noted above, security gateways MAY support a transport mode SA to
provide link
security. security for IP traffic. Two hosts MAY establish a
tunnel mode SA between themselves. The requirement Several concerns motivate the use
of tunnel mode for any (transit traffic) an SA involving a security gateway to be a tunnel SA arises due to the need to avoid
potential problems with regard to fragmentation and reassembly of
IPsec packets, and in circumstances where gateway. For example,
if there are multiple paths (e.g., via different security gateways) exist
to the same destination behind the

Kent [Page 11]

Internet Draft Security Architecture for IP October 2003 security gateways.

For a tunnel mode SA, there gateways, it is an "outer" IP header important
that specifies
the IPsec processing destination, plus an "inner" IP header that
specifies the (apparently) ultimate destination for IPsec packet be sent to the packet. The security protocol header appears after gateway with which the outer IP header, and
before
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. Also, when a fragment is processed by IPsec
and transmitted, then fragmented en route, it is critical that there
be inner and outer headers to retain the fragmentation state data for
the pre- and post-IPsec packet formats. Hence there are several
reasons for employing tunnel mode when either end of an SA is a
security gateway.

Note: AH and ESP cannot be applied using transport mode to IPv4
packets that are fragments. Only tunnel mode can be employed in such
cases.

For a tunnel mode SA, there 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 security protocol header appears
after the outer IP header, and before the inner IP header. If AH is
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 of the inner IP header is protected, as well as higher next layer
protocols). If ESP is employed, the protection is afforded only to
the tunneled packet, not to the outer header.

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

Kent [Page 12]

Internet Draft Security Architecture for IP January 2004

b) A security gateway is required to MUST support only tunnel mode but and MAY
support transport mode. If it supports transport mode, that
should be used only when the security gateway is acting as a
host, e.g., for network management, or to provide link security.

4.2 Security Association Functionality

The set of security services offered by an SA depends on the security
protocol selected, the SA mode, the endpoints of the SA, and on the
election of optional services within the protocol.

For example, both AH
provides data origin and ESP offer integrity and authentication
services, but the coverage differs for each protocol and connectionless differs for
transport vs. tunnel mode. If the integrity of an IPv4 option or IPv6
extension header must be protected en route between sender and
receiver, AH can provide this service, except for the mutable (non-
predictable) parts of the IP datagrams (hereafter referred or extension headers. However, the same
security may be achieved in some contexts by applying ESP to as just "authentication"). a tunnel
carrying a packet.

The
"precision" granularity of the authentication service access control provided is a function of determined by the
granularity
choice of the security association with which AH is employed, as
discussed in Section 4.4.2, "Selectors".

AH also offers an anti-replay (partial sequence integrity) service at
the discretion of selectors that define each security association.
Moreover, the receiver, to help counter denial of service
attacks. AH is an appropriate protocol to employ when
confidentiality is not required (or is not permitted, e.g , due to
government restrictions on use of encryption). AH also provides authentication for selected portions of the IP header, which may be
necessary in some contexts. For example, if the integrity of an IPv4
option or IPv6 extension header must be protected en route between
sender and receiver, AH can provide this service (except for the non-
predictable but mutable parts of the IP header.)

ESP optionally provides confidentiality for traffic. (The strength means employed by IPsec peers, e.g.,
during creation of the confidentiality service depends in part, on the encryption
algorithm employed.) ESP also may optionally provide authentication
(as defined above). If authentication is negotiated for an ESP SA,

Kent [Page 12]

Internet Draft Security Architecture for IP October 2003

the receiver IKE (vs. child) SA also may elect to enforce an anti-replay service with
the same features as effects the AH anti-replay service. The scope granularity
of the
authentication offered by ESP is narrower than for AH, i.e., the IP
header(s) "outside" the ESP header is(are) not protected. If only
the next layer protocols need to be authenticated, then ESP
authentication is an appropriate choice and is more space efficient
than use of AH encapsulating ESP. Note that although both
confidentiality and authentication are optional, they cannot both be
omitted. At least one of them MUST be selected. access control afforded.

If confidentiality service is selected, then an ESP (tunnel mode) SA between
two security gateways can offer partial traffic flow confidentiality.
The use of tunnel mode allows the inner IP headers to be encrypted,
concealing the identities of the (ultimate) traffic source and
destination. Moreover, ESP payload padding also can be invoked to
hide the size of the packets, further concealing the external
characteristics of the traffic. Similar traffic flow confidentiality
services may be offered when a mobile user is assigned a dynamic IP
address in a dialup context, and establishes a (tunnel mode) ESP SA
to a corporate firewall (acting as a security gateway). Note that
fine granularity SAs generally are more vulnerable to traffic
analysis than coarse granularity ones which that are carrying traffic from
many subscribers.

4.3 Combining Security Associations [May change depending on decisions
re: [46] nested SAs

NOTE: A compliant implementation MUST NOT allow instantiation of an
ESP SA that employs both NULL encryption and bundles]

The IP datagrams transmitted over no integrity algorithm.
An attempt to negotiate such an individual SA are afforded
protection is an auditable event by exactly one security protocol, either AH or ESP, but
not both. Sometimes a security policy may call both
initiator and responder. The audit log entry for a combination of
services this event SHOULD
include the current date/time, local IKE IP address, and remote IKE
IP address. The initiator SHOULD record the relevant SPD entry.

Kent [Page 13]

Internet Draft Security Architecture for a particular traffic flow that is IP January 2004

4.3 Combining Security Associations

This document does not achievable with a
single SA. In such instances it will be necessary to employ multiple
SAs to implement the required require support for nested security policy. The term "security
association bundle"
associations or for what RFC 2401 called "SA bundle" is applied to a sequence of SAs
through which traffic must bundles." These features
still can be processed to satisfy a security policy.
The order effected by appropriate configuration of both the sequence SPD
and the local forwarding functions (for inbound and outbound
traffic), but this function is defined by outside of the policy. (Note that IPsec module and thus
the
SAs that comprise a bundle may terminate at different endpoints. For
example, one SA may extend between scope of this specification. As a mobile host result, management of
nested/bundled SAs is potentially more complex and less assured than
under the model implied by RFC 2401. An implementation that provides
support for nested SAs SHOULD provide a security
gateway and management interface that
enables a second, nested SA may extend user or administrator to a host behind express the
gateway.)

Security associations may be combined into bundles in two ways:
transport adjacency nesting requirement,
and iterated tunneling.

o Transport adjacency refers then create the appropriate SPD entries and forwarding table
entries to applying more than one security
protocol effect the requisite processing.

4.4 Major IPsec Databases

IPsec implementation are largely a local matter, not subject to
standardization. However, some external aspects of the same IP datagram, without invoking tunneling. This
approach processing
must be standardized, to combining AH ensure interoperability and ESP allows to provide a
minimum management capability that is essential for only one level productive use of

Kent [Page 13]

Internet Draft Security Architecture
IPsec. This section describes a general model for processing IP October 2003

combination; further nesting yields no added benefit (assuming use of
adequately strong algorithms
traffic relative to IPsec functionality, in each protocol) since the processing support of these
interoperability and functionality goals. The model described below
is performed at one IPsec instance at nominal; implementations need not match details of this model as
presented, but the external behavior of implementations MUST
correspond to the externally observable characteristics of this model
in order to be deemed compliant.

There are two nominal databases in this model: the (ultimate) destination.

Host 1 --- Security ---- Internet -- Policy
Database and the Security --- Host 2
| | Gwy 1 Gwy 2 | |
| | | |
| -----Security Association 1 (ESP transport)------- |
| |
-------Security Association 2 (AH transport)----------

o Iterated tunneling refers to Database. The first specifies
the application of multiple layers policies that determine the disposition of
security protocols effected through all IP tunneling. This approach
allows for multiple levels of nesting, since each tunnel can
originate traffic inbound
or terminate at outbound from a different IPsec site along the path. No
special treatment is expected for ISAKMP traffic at intermediate host or security gateways other than what can be specified through
appropriate SPD entries (See Case 3 in Section 4.5)

There gateway. The second database
contains parameters that are 3 basic cases of iterated tunneling -- support associated with each established (keyed)
security association.

A third database, the Peer Authorization Database (PAD) is
required only for cases 2 also
required. The PAD provides a link between an SA management protocol
like IKE and 3.:

1. both endpoints for the SPD. The PAD indicates the range of identities that
a peer is authorized to represent when (child) SAs are negotiated
with the same -- peer. The inner and outer
tunnels could each identities may be either AH a list of IP address ranges or ESP, though it
symbolic names. The fundamental requirement associated with the PAD
is unlikely that
Host 1 would specify both to be the same, i.e., AH inside of AH or
ESP inside of ESP.

Host 1 --- Security ---- Internet -- Security --- Host 2
| | Gwy 1 Gwy 2 | |
| | | |
| -------Security Association 1 (tunnel)---------- | |
| |
---------Security Association 2 (tunnel)--------------

2. one endpoint of traffic selectors passed by the SAs is SA management protocol
for comparison against the same -- The inner and outer
tunnels could each SPD MUST be either AH or ESP.

Host 1 --- Security ---- Internet -- Security --- Host 2
| | Gwy 1 Gwy 2 |
| | | |
| ----Security Association 1 (tunnel)---- |
| |
---------Security Association 2 (tunnel)-------------

3. neither endpoint is verified as authorized
relative to the same -- The inner and outer tunnels
could each be either AH or ESP. authenticated peer of the SA management protocol.
(See also Section 4.5.3, which levies requirements on the PAD in
support of locating security gateways.)

Kent [Page 14]

Internet Draft Security Architecture for IP October 2003

These two approaches January 2004

The PAD also can be combined, specifies how to authenticate each peer, e.g., an SA bundle could
be constructed from one tunnel mode SA and one via
shared secret or two transport mode
SAs, applied in sequence. (See Section 4.5 "Basic Combinations use of
Security Associations.") Note that nested tunnels can also occur
where neither a certificate. If a shared secret is used,
the source nor secret is stored here. If a certificate is used, the destination endpoints of any trust anchor
for the certificate is part of the
tunnels are PAD. Because the same. In that case, there would PAD might be no host or
incorporated into the SA management protocol implementation, it is
not discussed extensively in this document.

If an IPsec implementation acts as a security gateway with a bundle corresponding to the nested tunnels.

For transport mode for multiple
subscribers, it MAY implement multiple separate IPsec contexts. Each
context MAY have and use completely independent identities, policies,
key management SAs, only one ordering of security protocols seems
appropriate. AH and/or IPsec SAs. This is applied to both the next layer protocols and
(parts of) for the IP header. Thus if AH is used in most part a transport mode, in
conjunction
local implementation matter. However, a means for associating inbound
(SA) proposals with ESP, AH SHOULD appear as local contexts is required. To this end, if
supported by the first header after IP,
prior key management protocol in use, context identifiers
MAY be conveyed from initiator to responder in the appearance of ESP. In signaling
messages, with the result that context, AH is applied IPsec SAs are created with a binding
to
the ciphertext output of ESP. In contrast, for tunnel mode SAs, one
can imagine uses for various orderings of AH and ESP. The required
set of SA bundle types that MUST be supported by a compliant particular context.

The IPsec
implementation is model described in Section 4.5.

4.4 Security Association Databases [Will change here embodies a clear separation between
forwarding (routing) and security decisions, to reflect decisions re:
- [40,44,45] changes in processing model (caching, etc.); - [46]
nesting/bundling accommodate a wide
range of SAs; - [67] contexts where IPsec management traffic; - [82]
clarification re: creation of SAs] -

Many of may be employed. Forwarding may be
trivial, in the details associated with processing IP traffic case where there are only two interfaces, or it may
be complex, e.g., if there are multiple protected or unprotected
interfaces or if the context in an which IPsec
implementation are largely is implemented employs a local matter, not subject to
standardization. However, some external aspects of the
sophisticated forwarding function. IPsec assumes only that outbound
and inbound traffic that has passed through IPsec processing
must be standardized, to ensure interoperability is
forwarded in a fashion consistent with the context in which IPsec is
implemented. Support for nested SAs is optional; if required, it
requires coordination between forwarding tables and SPD entries to provide
cause a
minimum management capability that packet to traverse the IPsec boundary more than once.

4.4.1 The Security Policy Database (SPD)

A security association is essential for productive use of
IPsec. This section describes a general model management construct used to enforce
security policy for processing IP traffic relative crossing the IPsec boundary. Thus an
essential element of SA processing is an underlying Security Policy
Database (SPD) that specifies what services are to security associations, be offered to IP
datagrams and in support what fashion. The form of these
interoperability the database and its
interface are outside the scope of this specification. However, this
section specifies minimum management functionality goals. The model described below
is nominal; compliant implementations need not match details of this
model as presented, but the external behavior of such implementations that must be mappable
provided, to the externally observable characteristics of this
model.

There are two nominal databases in this model: the Security Policy
Database allow a user or system administrator to control whether
and the Security Association Database. The former specifies
the policies that determine the disposition of all IP how IPsec is applied to traffic inbound transmitted or outbound from received by a host, security gateway, or BITS host
or BITW IPsec
implementation. transiting a security gateway. The latter database contains parameters SPD, or relevant caches, must
be consulted during the processing of ALL traffic (inbound and
outbound), including non-IPsec traffic, that are traverses the IPsec
boundary. This includes IPsec management traffic such as IKE. An
IPsec implementation MUST have at least one SPD, and it MAY support

Kent [Page 15]

Internet Draft Security Architecture for IP October 2003

associated with each (active) security association. This section
also defines January 2004

multiple SPDs, if appropriate for the concept of a Selector, context in which the IPsec
implementation operates. There is no requirement to maintain SPDs on
a set of IP and next layer
protocol field values per interface basis, as was specified in RFC 2401. However, if an
implementation supports multiple SPDs, then it MUST include an
explicit SPD selection function, that is used by the Security Policy Database invoked to
map select the
appropriate SPD for outbound traffic processing. The inputs to a policy, i.e., an SA (or SA bundle).

Each interface for which IPsec is enabled requires nominally separate
inbound vs. this
function are the outbound databases (SAD packet and SPD), because of any local metadata (e.g., the
directionality of many of
interface via which the fields that are used as selectors.
Typically there is just one such interface, for a host or security
gateway (SG). Note that an SG would always have at least 2
interfaces, but the "internal" one packet arrived) required to effect the corporate net, usually
would not have IPsec enabled and so only one pair of SADs and one
pair SPD
selection function. The output of SPDs would be needed. On the other hand, if a host had
multiple interfaces or function is an SG had multiple external interfaces, it
might be necessary SPD ID.

Each SPD entry is either implicitly or explicitly directional. For
traffic protected by IPsec, the source and destination address and
ports are swapped to have represent directionality, consistent with IKE
conventions. For bypassed or discarded traffic, separate SAD inbound and
outbound entries are supported, e.g., to permit unidirectional flows
if required.

The SPD pairs for each
interface.

IPsec devices supporting services such as: security gateway for
multiple subscribers, IPsec-protected tunnel links for overlay
networks, etc. MAY implement multiple separate IPsec contexts. These
contexts MAY have and use completely independent identities,
policies, key management SAs, and/or IPsec SAs. This is for the most
part a local implementation matter. However, a means for associating
inbound proposals an ordered database, consistent with local contexts is required. To this end, if
supported by the key management protocol use of ACLs or
packet filters in use, context identifiers
MAY be conveyed from initiator firewalls, routers, etc. The ordering requirement
arises because entries often will overlap due to responder in the signalling
messages, with presence of
(non-trivial) ranges as values for selectors. Thus a user or
administrator MUST be able to order the result that IPsec SAs are created with entries to express a binding desired
access control policy. There is no way to impose a particular context.

4.4.1 The Security Policy Database (SPD)

Ultimately, a security association is a management construct used to
enforce a security policy in general, canonical
order on SPD entries, because of the IPsec environment. Thus an
essential element allowed use of SA processing is an underlying Security Policy
Database (SPD) that specifies what services wildcards for
selector values and because the different types of selectors are not
hierarchically related.

The processing model described in this document assumes the ability
to be offered decorrelate overlapping SPD entries to IP
datagrams and permit caching, which
enables more efficient processing of outbound traffic in what fashion. The security
gateways and BITS/BITW implementations. (Native host implementations
have an implicit form of caching available, due to the database use of, for
example, socket interfaces for applications, and its
interface are outside the scope of this specification. However, this
section does specify certain minimum management functionality that
must thus there is no
requirement to be provided, able to allow decorrelate SPD entries in these
implementations.) Decorrelation is a user or system administrator to control
how IPsec means of improving performance
and simplifying the processing description; it is applied to traffic transmitted or received by not a host or
transiting requirement
for a security gateway.

The compliant implementation.

Appendix B provides an algorithm that can be used to decorrelate SPD must
entries, but any algorithm that produces equivalent output may be consulted during the processing of
used. Note that when an SPD entry is decorrelated all traffic
(INBOUND and OUTBOUND), including non-IPsec traffic. In order to
support this, the SPD requires distinct resulting
entries for inbound and
outbound traffic. One can think MUST be grouped together, so that all members of this as separate SPDs (inbound
vs. outbound). In addition, a nominally separate the group
derived from an individual, SPD must entry (prior to decorrelation) can
all be

Kent [Page 16]

Internet Draft Security Architecture for IP October 2003

provided for each IPsec-enabled interface. placed into caches and into the SAD at the same time. The
intent is that use of a decorrelated SPD ought not create more SAs
than would have resulted from use of a not-decorrelated SPD.

An SPD must discriminate among traffic that is afforded IPsec

Kent [Page 16]

Internet Draft Security Architecture for IP January 2004

protection and traffic that is allowed to bypass IPsec. This applies
to the IPsec protection to be applied by a sender and to the IPsec
protection that must be present at the receiver. For any outbound or
inbound datagram, three processing choices are possible: discard,
bypass IPsec, or apply IPsec. The first choice refers to traffic
that is not allowed to exit the host, traverse the security gateway,
or be delivered to an application at all. IPsec boundary (in the specified
direction). The second choice refers to traffic that is allowed to
pass without additional IPsec protection. The third choice refers to
traffic that is afforded IPsec protection, and for such traffic the
SPD must specify the security services to be provided, protocols to be employed, their mode,
security service options, and the cryptographic algorithms to be used, etc.

For every IPsec implementation, there MUST
used. An SPD is logically divided into three pieces, all of which
should be an administrative
interface that allows a user or system administrator to manage decorrelated (with the
SPD. Specifically, every inbound or outbound packet is exception noted above for native
host implementations) to facilitate caching. The SPD-S (secure
traffic) contains entries for all traffic subject to
processing by IPsec and the SPD must specify what action will be
taken in each case. Thus the administrative interface must allow the
user (or system administrator) to specify the security processing
protection. SPD-O (outbound) contains entries for all outbound
traffic that is to be bypassed or discarded. SPD-I (inbound) is
applied to any packet entering inbound traffic that will be bypassed or exiting the system, on a packet
by packet basis. (In a host discarded. If an
IPsec implementation making use of a
socket interface, supports only one SPD, then the SPD consists of
all three parts. If multiple SPDs are supported, some of them may not need to be consulted
partial, e.g., some SPDs might contain only SPD-I entries, to control
inbound bypassed traffic on a per
packet basis, but the effect is still the same.) per-interface basis. The management
interface split allows
SPD-I to be consulted without having to consult SPD-S, for such
traffic. Since the SPD-I is just a part of the SPD, the same rule
applies here, i.e., if a packet that is looked up in the SPD-I cannot
be matched to an entry there, then the packet MUST be discarded.
Note that for outbound traffic, if a match is not found in SPD-S,
then SPD-O must be 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.

For every IPsec implementation, there MUST be a management interface
that allows a user or system administrator to manage the SPD. The
interface must allow the user (or administrator) to specify the
security processing to be applied to every packet that traverses the
IPsec boundary. (In a native host IPsec implementation making use of
a socket interface, the SPD may not need to be consulted on a per
packet basis, as noted above.) The management interface for the SPD
MUST allow creation of entries consistent with the selectors defined
in Section 4.4.2, and MUST support (total) ordering of these entries. It is expected that through the use of
wildcards in various selector fields, and because all packets on a
single UDP or TCP connection will tend to match a single SPD entry, entries,
as seen via this requirement will not impose an unreasonably detailed level of
SPD specification. interface. The SPD entries' selectors are analogous
to what are the ACL or packet filters commonly found in a stateless firewall
or packet filtering router and which are currently
manageable managed this way.

In host systems, applications MAY be allowed to select what security
processing is to be applied to the traffic they generate and consume.
(Means create SPD entries.
(The means of signalling signaling such requests to the IPsec implementation are
outside the scope of this standard.) However, the system
administrator MUST be able to specify whether or not a user or

Kent [Page 17]

Internet Draft Security Architecture for IP January 2004

application can override (default) system policies. Note that
application specified policies may satisfy system requirements, so
that the system may not need to do additional IPsec processing beyond
that needed to meet an application's requirements. The form of the
management interface is not specified by this document and may differ
for hosts vs. security gateways, and within hosts the interface may
differ for socket-based vs. BITS implementations. However, this

Kent [Page 17]

Internet Draft Security Architecture for IP October 2003
document does specify a standard set of SPD elements that all IPsec
implementations MUST support.

The SPD contains an ordered list of policy entries.

Each policy SPD entry specifies packet disposition as BYPASS, DISCARD, or
IPsec. The entry is keyed by a list of one or more selectors that define the set selectors. The SPD
contains an ordered list of IP
traffic encompassed by this policy entry. (The these entries. The required selector
types are defined in Section 4.4.2.) 4.4.2. These selectors are used to
define the granularity of
policies the SAs that are created in response to an
outbound packet or SAs. in response to a proposal from a peer.

The SPD MUST permit a security user or administrator to specify policy entries
as follows:
- each SPD entry SPD-I: For inbound traffic that is a list of 1 to be bypassed or more selector set pairs - each
selector set pair
discarded, the
entry consists of one selector set for the SA from values of the
initiator selectors that apply to the receiver and one selector set for the SA from the
receiver
traffic to the initiator. be bypassed or discarded.
- each selector set SPD-O: For outbound traffic that is to be bypassed or
discarded, the
entry consists of the
following selector types: - source IP address range - destination IP
address range - protocol(or OPAQUE or ANY) - source port range (or
OPAQUE or ANY) - destination port range (or OPAQUE values of the selectors that apply to the
traffic to be bypassed or ANY) - IPv6
mobility header type (MH type) range - ICMP message type range - ICMP
codes range - name (list) discarded.
- data sensitivity level (list)

This will enable policies SPD-S: For traffic that is to be specified that, for example, support
use protected using IPsec, the entry
consists of a single SA the values of the selectors that apply to carry the
traffic for multiple protocols. Note that
this text describes the representation in initiator will send or receive and the SPD values
that maps into IKE
payloads. The management GUI can offer the user other forms of data
entry and display, e.g., apply to the option of using address masks as well as
ranges not representable by a mask, and symbolic names for protocols,
ports, etc. (Do not confuse traffic that the use of symbolic names responder will receive
or send.
- The selector types are defined in a management
interface with the reference to symbolic SPD Section 4.2.2 below.

For each selector types.) If in an SPD entry, in addition to the
reserved, symbolic selector literal values
that define a match, there are two special values: ANY and OPAQUE.
The former value OPAQUE is employed for a given
selector type, only it may appear in the list for wildcard that type, and it
must appear only once matches any value in the list for that type.

Each entry includes an indication
corresponding field of whether traffic matching this
policy will be bypassed, discarded, or subject to IPsec processing.
If IPsec processing is to be applied, the entry includes an SA (or SA
bundle) specification, listing packet, whereas the IPsec protocols, modes, and
algorithms to be employed, including any nesting requirements. For
example, an entry latter value indicates
that the corresponding selector field is not examined, e.g., because
it may call for all matching traffic to be protected obscured by ESP in transport mode using 3DES-CBC with an explicit IV, nested
inside of AH encryption already applied to the packet or may
not be present in tunnel mode using HMAC/SHA-1. a fragment.

For each selector, selector in an SPD entry, the policy entry specifies how to
derive the corresponding values for a new Security Association
Database (SAD, see Section 4.4.3) entry from those in the SPD and the packet (Note
that at present, ranges are only supported for IP addresses; but
wildcarding can
packet. The goal is to allow an SAD entry and an SPD cache entry to
be expressed for all selectors):

a. use the value in created based on specific selector values from the packet itself -- This will limit use packet, or from
the matching 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, the flag
applies to all selectors of the indicated type in the outbound
element of the pair. (PFP does not apply to inbound traffic.)

Kent [Page 18]

Internet Draft Security Architecture for IP October 2003

SA to those packets which have January 2004

Note that this packet's value for text describes the selector
even if representation in the selector for SPD that maps
into IKE payloads, i.e., one should not create SPD entries that
cannot be mapped into what IKE can negotiate. The management GUI can
offer the policy entry has a range user other forms of allowed
values or a wildcard for this selector.

b. use the value associated with the policy data entry -- If this were to
be just a single value, then there would be no difference between
(b) and (a). However, if display, e.g., the allowed values
option of using address prefixes as well as ranges, and symbolic
names for protocols, ports, etc. (Do not confuse the selector are
a range (for IP addresses) or wildcard, then in the case of a range,
(b) would enable use of the SA by any packet with symbolic
names in a selector value
within the range not just by packets management interface with the SPD selector "name".) If
the reserved, symbolic selector value of OPAQUE or ANY is employed for a
given selector type, only it may appear in the
packet list for that triggered the creation of the SA. In type,
and it must appear only once in the case of list for that type. Note that
"ANY" is a
wildcard, (b) would allow local syntax convention - IKE handles this concept via
ranges.

The following example illustrates the use of the SA by packets with any value
for this selector.

For example, suppose there is PFP flag in the
context of a security gateway or a BITS/BITW implementation. Consider
an SPD entry where the allowed value for source destination address is any of a
range of hosts (192.168.2.1 IPv4 addresses: 192.168.2.1 to
192.168.2.10). And suppose that a 192.168.2.10. Suppose an
outbound packet is to be sent that has arrives with a
source destination address of 192.168.2.3. 192.168.2.3,
and there is no extant SA to carry this packet. The value to be used for
the SA created to transmit this packet could be any either of the sample two
values below shown below, depending on what the policy SPD entry for this selector
says is the source of the selector value:

source for the example of new
value to be new SAD destination address
used in the SA selector value
--------------- ------------
a. packet PFP TRUE 192.168.2.3 (one host)
b. SPD entry PFP FALSE 192.168.2.1 to 192.168.2.10 (range of hosts)

Note that if the SPD entry had an allowed a value of wildcard ANY for the
source destination
address, then the SAD selector value could would have to be wildcard (any
host). Case (a) ANY for case
(b), but would still be as illustrated for case (a). Thus the PFP
flag can be used to prohibit sharing, sharing of an SA, even among packets
that match the same SPD entry.

As described below in Section 4.4.3, selectors

4.4.2 Selectors

An SA may include "wildcard"
entries and hence be fine-grained or coarse-grained, depending on the
selectors used to define the set of traffic for the SA. For example,
all traffic between two entries hosts may overlap. (This
is analogous to the overlap that arises with ACLs or filter entries
in routers or packet filtering firewalls.) Thus, to ensure
consistent, predictable processing, SPD entries MUST be ordered carried via a single SA, and
the SPD MUST always be searched in the same order, so that the first
matching entry is consistently selected. (This requirement is
necessary as the effect
afforded a uniform set of processing security services. Alternatively, traffic against SPD entries
must
between a pair of hosts might be deterministic, but there is no way to canonicalize SPD
entries given spread over multiple SAs, depending
on the use applications being used (as defined by the Next Protocol and
Port fields), with different security services offered by different
SAs. Similarly, all traffic between a pair of wildcards for some selectors.) More detail security gateways could
be carried on matching of packets against SPD entries is provided in Section 5.

Note that if ESP is specified, either (but not both) authentication a single SA, or encryption can be omitted. So it MUST one SA could be possible to configure
the SPD value assigned for the authentication or encryption algorithms to each
communicating host pair. The following selector parameters MUST be

Kent [Page 19]

Internet Draft Security Architecture for IP October 2003

"NULL". However, at least one of these services MUST be selected,
i.e., it MUST NOT be possible January 2004

supported by all IPsec implementations to configure both facilitate control of them as "NULL".

The SPD can be used to map traffic to specific SAs or SA bundles.
Thus it can function
granularity. Note that both as the reference database for security
policy and as the map to existing SAs (or SA bundles). (To
accommodate the bypass Source and discard policies cited above, the SPD also
MUST provide Destination addresses should
either be IPv4 or IPv6, but not a means mix of mapping traffic address types. Also, note
that the source/destination port selectors may be labeled as "OPAQUE"
to accommodate situations where these functions, even
though they fields are not, per se, IPsec processing.) The way in which the
SPD operates inaccessible because
of prior encryption or due to packet fragmentation.

- Destination IP Address (IPv4 or IPv6): this is different for inbound vs. outbound traffic and it
also may differ for host vs. security gateway, BITS, and BITW
implementations. Sections 5.1 and 5.2 describe the use a list of ranges
of IP addresses (unicast, anycast, broadcast (IPv4 only), or
multicast group). This structure allows expression of the SPD
for outbound and inbound processing, respectively.

Because a security policy may require that more than one SA be
applied to single
IP address (via a specified set trivial range), or a list of traffic, in addresses (each a specific order, the
policy entry in the SPD must preserve these ordering requirements,
when present. Thus, it must be possible for an IPsec implementation
to determine that an outbound
trivial ranges), or inbound packet must be processed
thorough a sequence range of SAs. Conceptually, for outbound processing,
one might imagine links (to addresses (high and low values,
inclusive), as well as the SAD) from an SPD entry for which
there most generic form of a list of
ranges. Address ranges are active SAs, and each entry would consist used to support more than one
destination system sharing the same SA, e.g., behind a security
gateway.

- Source IP Address(es) (IPv4 or IPv6): this is a list of ranges
of IP addresses (unicast, anycast, broadcast (IPv4 only), or
multicast group). This structure allows expression of either a single
SA
IP address (via a trivial range), or an ordered a list of SAs that comprise an SA bundle. When addresses (each a
packet is matched against an SPD entry and there is an existing SA
trivial ranges), or
SA bundle that can be a range of addresses (high and low values,
inclusive), as well as the most generic form of a list of
ranges. Address ranges are used to carry support more than one source
system sharing the traffic, same SA, e.g., behind a security gateway.

- Next Layer Protocol: Obtained from the processing of IPv4 "Protocol" or the packet
IPv6 "Next Header" fields. This is controlled by the SA an individual protocol
number, or SA bundle entry on the list.
For an inbound IPsec packet for which multiple IPsec SAs are to be
applied, the lookup based on destination address, IPsec protocol, and
SPI should identify a single SA. ANY. The SPD Next Layer Protocol is used to control the flow of ALL traffic through an IPsec
system, including security and key management traffic (e.g., ISAKMP)
from/to entities behind a security gateway. This means whatever comes after
any IP extension headers that ISAKMP
traffic must be explicitly accounted for are present. To simplify locating
the Next Layer Protocol in the SPD, else it will IPv6 context, there SHOULD be
discarded. Note that a security gateway could prohibit traversal of
encrypted packets in various ways, e.g., having a DISCARD entry in
the SPD
mechanism for ESP packets or providing proxy key exchange. In the
latter case, the traffic would be internally routed configuring which IP extension headers to the key
management module in the security gateway.

4.4.2 Selectors

An SA (or SA bundle) may be fine-grained or coarse-grained, depending skip,
e.g., Destination Options, Routing Header, Fragmentation Header,
Mobility Header, Hop-by-hop options, etc.

Several additional selectors depend on the selectors used to define Next Layer Protocol
value:

* If the set of traffic 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 SA. For
example, all traffic between two hosts source and destination ports may not
be carried via available in the case of receipt of a single
SA, and afforded fragmented packet,
thus a uniform set value of security services. Alternatively,
traffic between "OPAQUE" also MUST be supported. Note: In a pair of hosts might
non-initial fragment, port values will not be spread over multiple SAs,
depending on the applications being used (as defined by available. If
the Next SA requires a non-OPAQUE port value, an arriving
fragment MUST be discarded.

Kent [Page 20]

Internet Draft Security Architecture for IP October 2003 January 2004

* If the Next Layer Protocol and Port fields), with different security services offered
by different SAs. Similarly, all traffic between is a pair of security
gateways could be carried on Mobility Header, then there
is a single SA, or one SA could be assigned
for each communicating host pair. The following selector parameters
MUST be supported for SA management to facilitate control of SA
granularity. Note IPv6 Mobility Header Message Type (MH
type) [Mobip]. This is an 8-bit value that in the case of receipt of identifies a packet with an ESP
header, e.g., at an encapsulating security gateway or BITW
implementation,
particular mobility message.

* If the transport layer protocol, source/destination
ports, Next Layer Protocol value is ICMP then there are
selectors for the ICMP message type and Name (if present) may be "OPAQUE", i.e., inaccessible
because code. The message
type is a single 8-bit value, which defines the type of encryption an
ICMP message, or fragmentation. Note also ANY. The ICMP code is single 8-bit value
that both Source
and Destination addresses should either be IPv4 or IPv6.

- Destination IP Address (IPv4 or IPv6): this may defines a specific subtype for an ICMP message. This
selector can be a single IP
address (unicast, anycast, broadcast (IPv4 only), value, or multicast
group), ANY.

- Name: A name is used as a range of addresses (high and low values (inclusive),
address + mask, symbolic identifier for an IPsec
source or a wildcard address. The last three are used
to support more than one destination system sharing the same SA
(e.g., behind a security gateway). Note address. Thus an SPD entry that has a non-
null Name selector MUST set either the source or destination IP
address selector 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
conceptually different from all the "Destination IP Address" field other selectors
described above. Names do not appear in the <Destination IP Address, IPsec Protocol, SPI> tuple used packets, so it is not
possible to uniquely identify an SA. When match a tunneled packet arrives at
the tunnel endpoint, its SPI/Destination address/Protocol against an SPD entry based on a Name
selector. Name selectors are used to look up trigger creation of SPD
cache (SPD-S and SPD-O) (and SAD) entries, which are then
populated with specific IP source or destination addresses
provided by the SA for this packet management protocol. For a native host
implementation, a Name may be used in an SPD entry to provide
finer granularity access control that would be otherwise be
available on multi-user systems. In this case, the SAD. This
destination address comes from entry may be
consulted when SA creation is initiated by the encapsulating IP header.
Once host, or when the packet has been processed according
host is a responder. The Name refers to an entity at the tunnel SA host in
question, and has come out of the tunnel, implementation relies on its selectors are "looked up" in integration into
the Inbound SPD. host OS to ensure appropriate linking to the named entity's
process. The Inbound SPD has a other use for the Name selector called
destination address. This IP destination address occurs when any
IPsec implementation (native host, BITW, BITS, or security
gateway) is contacted by a peer whose address cannot be known a
priori, e.g., a road warrior. In this context, the one Name is used
in lieu of the inner (encapsulated) IP header. In the case address of a
transport'd packet, there will be only one IP header and this
ambiguity does not exist.
[REQUIRED for all implementations]

- Source IP Address(es) (IPv4 or IPv6): this may the peer, who must be a single IP
address (unicast, anycast, broadcast (IPv4 only), or multicast
group), range an initiator
of addresses (high and low values inclusive),
address + mask, or a wildcard address. The last three are used
to support more than one source system sharing the same SA
(e.g., behind a security gateway or in a multihomed host).
[REQUIRED for all implementations]

- Name: There are 2 cases (Note creation.

[This selector description may change based on discussion of
some name/identity issues that these name forms are
supported in haven't yet been posted to the
list.]

The IPsec DOI.)
1. User ID
a. a fully qualified user name string (DNS), e.g., implementation context determines how selectors are used.

Kent [Page 21]

Internet Draft Security Architecture for IP October 2003

mozart@foo.bar.com
b. X.500 distinguished name, e.g., C = US, SP = MA, O = GTE
Internetworking, CN = Stephen T. Kent.
2. System name (host, security gateway, etc.)
a. January 2004

For example, a fully qualified DNS name, e.g., foo.bar.com
b. X.500 distinguished name
c. X.500 general name

NOTE: One of the possible values native host implementation typically makes use of this selector a
socket interface. When a new connection is "OPAQUE".

[REQUIRED for established the following cases. Note SPD can
be consulted and an SA bound to the socket. Thus traffic sent via
that support for name
forms other than addresses is socket need not required for manually keyed
SAs.
o User ID
- native host implementations
- BITW result in additional lookups to the SPD (SPD-O
and BITS implementations acting as HOSTS
with only one user
- SPD-S) cache. In contrast, a BITS, BITW, or security gateway implementations for INBOUND
processing.
o System names -- all implementations]

- Data sensitivity level: (IPSO/CIPSO labels)
[REQUIRED for all systems providing information flow security as
per Section 8, OPTIONAL for all other systems.]

- Next Layer Protocol: Obtained from
implementation needs to look at each packet and perform an SPD/SPD-S
cache lookup based on the IPv4 "Protocol" or selectors.

4.4.3 Security Association Database (SAD)

In each IPsec implementation there is a nominal Security Association
Database, in which each entry defines the
IPv6 "Next Header" fields. This may be parameters associated with
one SA. Each SA has an individual protocol
number. These packet fields may not contain entry in the Next Layer
Protocol due SAD. For outbound processing,
entries are pointed to by entries in the presence SPD-S part of IP extension headers, e.g., a
Routing Header, AH, ESP, Fragmentation Header, Destination
Options, Hop-by-hop options, etc. Note that the Next Layer
Protocol may not be available SPD cache.
For inbound processing, each entry in the case of receipt of a packet
with SAD is indexed by an SPI
(from the AH or ESP header, thus a value of "OPAQUE" SHOULD be
supported..br [REQUIRED protocol header), plus source and/or destination
address for all implementations]

NOTE: To locate multicast SAs, as noted earlier. The following parameters
are associated with each entry in the Next Layer Protocol, SAD. They should all be
present except where otherwise noted, e.g., AH Authentication
algorithm. This description does not purport to be a system has MIB, only a
specification of the minimal data items required to chain
through support an SA in
an IPsec implementation.

For each of the packet headers checking selectors defined in Section 4.4.2, the "Protocol" entry for an
inbound SA in the SAD MUST contain the value or "Next
Header" field until it encounters either one it recognizes as a
Next Layer Protocol, or until it reaches one that isn't on its
list of extension headers, or until it encounters an ESP header
that renders values negotiated at
the Next Layer Protocol opaque. Note: The IPv6
mobility header is time the SA was created. For a possible next layer protocol.

- Source and Destination (e.g., TCP/UDP) Ports: These may be
individual UDP or TCP port receiver, these values or a wildcard port. (The use
of the Next Protocol field and are used to
check that the Source and/or Destination
Port header fields (in conjunction with the Source and/or Destination

Kent [Page 22]

Internet Draft Security Architecture for IP October 2003

Address fields), as of an SA inbound packet match the selector is sometimes referred to as
"session-oriented keying."). Note that
values negotiated for the source and
destination ports may not be available in SA. For the case of receipt receiver, this is part of
verifying that a packet with arriving on an ESP header, thus a value SA is consistent with the
policy for the SA. (See Section 6 for rules for ICMP messages.)
These fields can have the form of specific values, ranges, ANY, or
"OPAQUE" SHOULD be
supported. as described in section 4.4.2, "Selectors."

The following table summarizes the relationship between data items MUST be in the
"Next Header" SAD:

o Security Parameter Index (SPI): a 32-bit value in selected by the packet and SPD and
receiving end of an SA to uniquely identify the derived Port
Selector value SA. In an SAD entry
for an outbound SA, the SPD and SAD.

Next Hdr Transport Layer Derived Port Selector Field
in Packet Protocol in SPD Value in SPD and SAD
-------- --------------- ---------------------------
ESP ESP SPI is used to construct the packet's AH or ANY ANY (i.e., don't look at it)
-don't care- ANY ANY (i.e., don't look at it)
specific value specific value NOT ANY (i.e., drop packet)
fragment
specific value specific value actual port selector field
not fragment

If
ESP header. In an SAD entry for an inbound SA, the packet has been fragmented, then SPI is used to map
traffic to the port information may
not be available appropriate SA (see text on unicast/multicast in
Section 4.1).

o Sequence Number Counter: a 64-bit or 32-bit value used to generate
the current fragment. If so, discard Sequence Number field in AH or ESP headers. 64-bit sequence
numbers are the
fragment. An ICMP PMTU should be sent default, but 32-bit sequence numbers are also
supported if negotiated.

Kent [Page 22]

Internet Draft Security Architecture for IP January 2004

o Sequence Counter Overflow: a flag indicating whether overflow of
the first fragment,
which will have Sequence Number Counter should generate an auditable event and
prevent transmission of additional packets on the port information.
[MAY be supported]

- IPv6 Mobility Header Message Type (MH type) [Mobip]: This SA, or whether
rollover is an
8-bit selector that identifies permitted. The audit log entry for this event SHOULD
include the particular mobility message
in question. This MUST be used only if SPI value, current date/time, Source Address, Destination
Address, and the Next Layer Protocol
is defined selectors from the relevant SAD entry.

o Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent)
used to be determine whether an IPv6 Mobility Header. Note that inbound AH or ESP packet is a replay.

NOTE: If anti-replay has been disabled by the MH type
may not be available receiver for an SA,
e.g., in the case of receipt of a packet with an
ESP header, thus a value of "OPAQUE" SHOULD be supported.

- ICMP message type: This defines manually keyed SA, then the type of ICMP message. 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 Authentication algorithm, key, etc. This
selector can be a list. Note that is required only if AH
is supported.

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

o ESP integrity algorithm, keys, etc. If the ICMP message type may integrity service is not
selected, these fields will be available in the case of receipt of a packet with an null.

o ESP
header, thus combined mode algorithms, key(s), etc. This data is used when a value
combined mode (encryption and integrity) algorithm is used with ESP.

o Lifetime of "OPAQUE" SHOULD be supported.

- ICMP code: This defines this Security Association: a specific cause for the ICMP message.
This selector can time interval after which
an SA must be replaced with a list. Note that the ICMP code may not be
available in the case new SA (and new SPI) or terminated,
plus an indication of receipt which of these actions should occur. This may
be expressed as a packet with an ESP header,
thus time or byte count, or a value simultaneous use of "OPAQUE" SHOULD be supported.

The IPsec both
with the first lifetime to expire taking precedence. A compliant
implementation context determines how selectors are used.
For example, MUST support both types of lifetimes, and must support
a host implementation integrated into the stack may make simultaneous use of a socket interface. When a new connection both. If time is established the

Kent [Page 23]

Internet Draft Security Architecture for IP October 2003

SPD can be consulted employed, and an SA (or if IKE employs
X.509 certificates for SA bundle) bound to establishment, the socket.
Thus traffic sent via that socket need not result in additional
lookups to SA lifetime must be
constrained by the SPD/SAD. In contrast, a BITS, BITW, or security
gateway implementation needs to look at each packet validity intervals of the certificates, and perform an
SPD/SAD lookup based on the selectors. The allowable values for
NextIssueDate of the
selector fields differ between CRLs used in the traffic flow, IKE exchange for the security
association, SA. Both
initiator and the security policy. responder are responsible for constraining SA lifetime
in this fashion. NOTE: The following table summarizes details of how to handle the kinds refreshing
of entries that keys when SAs expire is a local matter. However, one needs to
be able to express in reasonable
approach is:

(a) If byte count is used, then the SPD and SAD. It shows how they relate to implementation SHOULD count the fields in data traffic being subjected
number of bytes to which the IPsec screening.
(Note: cryptographic algorithm is
applied. For ESP, this is the "wild" or "wildcard" entry for src and dst addresses
includes a mask, range, etc.)

Field Traffic Value SAD Entry SPD Entry
-------- ------------- ---------------- --------------------
src addr single IP addr single,range,wild single,range,wildcard
dst addr single IP addr single,range,wild single,range,wildcard
xpt protocol* xpt protocol single,wildcard single,wildcard
src port* single src port single,wildcard single,wildcard
dst port* single dst port single,wildcard single,wildcard
user id* single user id single,wildcard single,wildcard
sec. labels single value single,wildcard single,wildcard
mh type single value single,wildcard single,wildcard
ICMP type single value single,wildcard single,wildcard
ICMP code single value single,wildcard single,wildcard

* The SAD encryption algorithm (including Null
encryption) and SPD entries for these fields could be "OPAQUE"
because the traffic value AH, this is encrypted.

NOTE: In principle, one could have selectors and/or selector values
in the SPD which cannot authentication algorithm. This
includes pad bytes, etc. Note that implementations SHOULD be negotiated for an SA or SA bundle.
Examples might include selector values used to select traffic for
discarding or enumerated lists which cause a separate SA able to be
created for each item on the list. For now, this is left for future
versions of this document and the list of required selectors and
selector values is the same for
handle having the SPD and counters at the SAD. However, it is
acceptable to have an administrative interface that supports use ends of
selector values which cannot be negotiated provided that it does not
mislead the user into believing it is creating an SA with these
selector values. For example, the interface may allow the user to
specify an enumerated list get out of values but would result in the creation synch,
e.g., because of a separate policy and SA for each item on packet loss or because the list. A vendor
might support such an interface to make it easier for its customers
to specify clear and concise policy specifications. implementations at each

Kent [Page 24] 23]

Internet Draft Security Architecture for IP October 2003

4.4.3 Security Association Database (SAD)

In each IPsec implementation there is a nominal Security Association
Database, in which each entry defines January 2004

end of the parameters associated with
one SA. Each SA has an entry in the SAD. For outbound processing,
entries are pointed to by entries in aren't doing things the SPD. Note that if an SPD
entry does not currently point to an SA same way.

(b) There SHOULD be two kinds of lifetime -- a soft lifetime that is appropriate for the
packet,
warns the implementation creates an appropriate SA (or SA Bundle) to initiate action such as setting up a
replacement SA; and links a hard lifetime when the SPD entry to current SA ends and is
destroyed.

(c) If the SAD entry (see Section 5.1.1). For
inbound processing, each entry in entire packet does not get delivered during the SAD SAs
lifetime, the packet SHOULD be discarded.

o IPsec protocol mode: tunnel or transport. Indicates which mode of
AH or ESP is indexed by a 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 be either IPv4 or IPv6 addresses. The version implies the type
of IP address, header to be used. Only used when the IPsec protocol type, and SPI. mode is
tunnel.

The following parameters
are associated with each entry table summarizes the kinds of entries that one needs to
be able to express in the SPD and SAD. This description does not
purport It also shows how they relate
to be a MIB, but only a specification of the minimal fields in data
items required traffic being subjected to support an SA IPsec screening.

[Table to be added in an a future draft.]

4.5 SA and Key Management

IPsec implementation.

For inbound processing: mandates support for both manual and automated SA and
cryptographic key management. The following packet fields IPsec protocols, AH and ESP, are used to look
up
largely independent of the associated SA in management techniques,
although the SAD.

For a unicast SA, techniques involved do affect some of the SPI can be used security
services offered by itself to specify an SA, or
it may be used in conjunction with the IPsec protocol type (AH or
ESP). Since the SPI value is generated by protocols. For example, the receiver optional anti-
replay service available for a unicast
SA, whether the value is sufficient to identify an AH and ESP requires automated SA by itself, or
whether it must be used in conjunction with the IPsec protocol value
is a local matter. This mechanism for mapping inbound traffic to
unicast SAs MUST be supported by all IPsec implementations.

If an IPsec implementation supports multicast SAs as well as unicast
SAs, then it MUST use
management. Moreover, the following algorithm for mapping all inbound granularity of key distribution employed
with IPsec datagrams to SAs. (Implementations that support only unicast
traffic need not implement this algorithm.) Each entry in the
Security Association Database (SAD) must indicate whether determines the SA
lookup makes use granularity of (a) the SPI but neither the source or destination
address (unicast), (b) the destination IP address plus the SPI, or
(c) source plus destination IP addresses authentication provided. In
general, data origin authentication in addition to the SPI. (For
multicast SAs, the protocol field AH and ESP is not employed for SA lookups.)
Nominally, this indication can be represented limited by two bits, one
associated with the source IP address and
extent to which secrets used with the other for integrity algorithm (or with a
key management protocol that creates such secrets) are shared among
multiple possible sources.

The following text describes the
destination IP address. A "1" value minimum requirements for each bit indicates the need
to match against the corresponding address field as part both types
of the SA
lookup process. Thus, management.

Kent [Page 24]

Internet Draft Security Architecture for example, unicast SAs would have both bits
set to zero, since neither the source nor destination IP address January 2004

4.5.1 Manual Techniques

The simplest form of management is
required for SA matching.

For multicast methods that rely only on the destination address manual management, in which a
person manually configures each system with keying material and
security association management data relevant to
specify secure communication
with other systems. Manual techniques are practical in small, static
environments but they do not scale well. For example, a multicast group, only company
could create a Virtual Private Network (VPN) using IPsec in security
gateways at several sites. If the destination bit would be set to
"1," implying number of sites is small, and
since all the need to use sites come under the destination address plus purview of a single administrative
domain, this might be a feasible context for manual management
techniques. In this case, the SPI security gateway might selectively
protect traffic to
determine the appropriate SA. For multicast methods (e.g., SSM
[HC03]) that also require and from other sites within the source address to identify organization using
a multicast

Kent [Page 25]

Internet Draft Security Architecture manually configured key, while not protecting traffic for IP October 2003

group, both bits would other
destinations. It also might be set appropriate when only selected
communications need to "1." (There is no current
requirement be secured. A similar argument might apply to support multicast SA mapping based on the source
address but not the destination address, thus one
use of the possible
four values is not meaningful.) The indication as to whether source
and destination address matching is required to map inbound IPsec
traffic to SAs MUST be set either as entirely within an organization for a side effect small number of manual SA
configuration or via negotiation using an SA
hosts and/or gateways. Manual management protocol,
e.g., IKE.

For each of the selectors defined in Section 4.4.2, the techniques often employ
statically configured, symmetric keys, though other options also
exist.

4.5.2 Automated SA entry in
the SAD MUST contain the value or values which were negotiated at the
time the and Key Management

Widespread deployment and use of IPsec requires an Internet-standard,
scalable, automated, SA was created. For management protocol. Such support is required
to facilitate use of the sender, these values are used anti-replay features of AH and ESP, and to
decide whether
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 given new SA is appropriate 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 an outbound
packet. This is part of checking to see if there
IPsec is an existing IKEv2 [Kau04]. Other automated SA
that can management protocols MAY
be used. For the receiver, these values are used to check
that the selector values in employed.

When an inbound packet match those for the SA
(and thus indirectly those for the matching policy). For the
receiver, this automated SA/key management protocol is part of verifying that employed, the SA was appropriate for output
from this packet. (See Section 6 protocol is used to generate multiple keys for rules a single SA.
This also occurs because distinct keys are used for ICMP messages.) These
fields can have the form each of specific values, ranges, wildcards, or
"OPAQUE" as described in section 4.4.2, "Selectors". Note that for
an ESP SA, the encryption algorithm or the authentication algorithm
could be "NULL". However they MUST not both be "NULL".

The following SAD fields two
SAs created by IKE. If both integrity and confidentiality are used in doing IPsec processing:

o Sequence Number Counter:
employed, then a 32-bit value used to generate the
Sequence Number field in AH or ESP headers.

[REQUIRED 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 implementations, but used only for outbound traffic.]

o Sequence Counter Overflow: keys
are extracted. If a flag indicating whether overflow single string of bits is provided, care needs to
be taken to ensure that the
Sequence Number Counter should generate an auditable event and prevent
transmission parts of additional packets on the SA.

[REQUIRED for all implementations, but used only for outbound traffic.]

o Anti-Replay Window: a 32-bit counter and a bit-map (or equivalent) used system that map the string
of bits to determine whether an inbound AH or ESP packet is a replay.

[REQUIRED for all implementations but used only for inbound traffic.
NOTE: If anti-replay has been disabled by the receiver, e.g., required keys do so in the
case same fashion at both ends
of a manually keyed SA, then the Anti-Replay Window is not used.]

o AH Authentication algorithm, keys, etc.

[REQUIRED for AH implementations] SA. To ensure that the IPsec implementations at each end of

Kent [Page 26] 25]

Internet Draft Security Architecture for IP October 2003

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

[REQUIRED January 2004

the SA use the same bits for ESP implementations]

o ESP authentication algorithm, the same keys, etc. If and irrespective of which
part of the authentication service
is not selected, this field will be null.

[REQUIRED for ESP implementations]

o Lifetime of this Security Association: a time interval after which an
SA must be replaced with a new SA (and new SPI) or terminated, plus an
indication of which system divides the string of these actions should occur. This may bits into individual keys,
the encryption keys MUST be
expressed as a time or byte count, or a simultaneous use of both, taken from the first lifetime to expire taking precedence. A compliant implementation
MUST support both types of lifetimes, and must support a simultaneous
use of both. If time is employed, (left-most, high-
order) bits and if IKE employs X.509
certificates for SA establishment, the SA lifetime must integrity keys MUST be constrained
by taken from the validity intervals remaining
bits. The number of bits for each key is defined in the certificates, and relevant
cryptographic algorithm specification RFC. In the NextIssueDate case of multiple
encryption keys or multiple integrity keys, the CRLs used 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 IKE exchange for
cryptographic algorithm.

4.5.3 Locating a Security Gateway

This section discusses issues relating to how a host learns about the SA. Both initiator
existence of relevant security gateways and
responder once a host has contacted
these security gateways, how it knows that these are responsible for constraining SA lifetime in this fashion.

[REQUIRED for all implementations]

NOTE: the correct
security gateways. The details of how to handle where the refreshing of keys when SAs
expire required information is
stored is a local matter. However, one reasonable approach is:

(a) If byte count is used, then matter, but the implementation SHOULD count Peer Authorization database
described in Section 4.4 is the number
of bytes to most likely candidate.

Consider a situation in which the IPsec algorithm is applied. For ESP, this a remote host (H1) is using the encryption algorithm (including Null encryption)
Internet to gain access to a server or other machine (H2) and for AH, this there
is the authentication algorithm. This includes pad bytes, etc. Note
that implementations SHOULD be able to handle having the counters at
the ends of an SA get out of synch, a security gateway (SG2), e.g., because of packet loss or
because the implementations at each end a firewall, through which H1's
traffic must pass. An example of the SA aren't doing things
the same way.

(b) There SHOULD this situation would be two kinds of lifetime -- a soft lifetime which warns mobile
host (road warrior) crossing the implementation Internet to initiate action such as setting up a replacement
SA and a hard lifetime when the current SA ends.

1. How does not get delivered during the SAs lifetime, H1 know/learn about the packet SHOULD be discarded.

o IPsec protocol mode: tunnel, transport or wildcard. Indicates which
mode existence of AH or ESP is applied 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 traffic on this SA. Note
represent H2?

3. How does SG2 authenticate H1 and verify that if this
field H1 is "wildcard" at the sending end of the SA, then the application
has authorized
to specify the mode 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 IPsec implementation. This use address of
wildcard allows one or more security gateways for ranges of
destination addresses that require its use. This includes the same SA
ability to be used configure information for either tunnel locating and authenticating one
or transport
mode traffic on a per packet basis, e.g., by different sockets. The 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

Kent [Page 27] 26]

Internet Draft Security Architecture for IP October 2003

receiver does not need to know the mode in order January 2004

issue of how to properly process automate the packet's IPsec headers.

[REQUIRED as follows, unless implicitly defined by context:
- host implementations must support all modes
- gateway implementations must support tunnel mode]

NOTE: The use discovery/verification of wildcard for the protocol mode security
gateways.

4.6 Security Associations and Multicast

The receiver-orientation of an inbound SA may add
complexity to the situation Security Association implies that, in
the receiver (host only). Since case of unicast traffic, the
packets on such an SA could be delivered in either tunnel or transport
mode, destination system will select the security of an incoming packet could depend in part on which
mode had been used to deliver it. If, as a result, an application cared
about
SPI value. By having the SA mode of a given packet, then destination select the application would need a
mechanism SPI value, there is
no potential for manually configured Security Associations to obtain this mode information.

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

[REQUIRED for all implementations but used only
conflict with automatically configured (e.g., via a key management
protocol) Security Associations or for outbound traffic]

4.5 Basic Combinations of Security Associations [May change depending on
decisions re: [46] nesting/bundling SAs]

This section describes four examples of combinations of security
associations that MUST be supported by compliant IPsec hosts 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
security gateways. Additional combinations person will need to coordinate among all multicast
groups to select an SPI or SPIs on behalf of AH and/or ESP in
tunnel and/or transport modes MAY be supported at each multicast group and
then communicate the discretion group's IPsec information to all of the implementor. Compliant implementations MUST be capable of
generating these four combinations and on receipt,
legitimate members of processing
them, but 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 receive and process any combination. The
diagrams and text below describe authenticate which system sent the basic cases. The legend multicast traffic.
Specifications for the
diagrams is:

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

NOTE: The security associations below can 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 be consulted during the
processing of all traffic that crosses the IPsec boundary, including
IPsec management traffic. If no policy is found in the SPD that
matches a packet (for either AH inbound or ESP. The
mode (tunnel vs transport) is determined by 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 nature notion of an SPD cache
for all outbound traffic (SPD-O plus SPD-S), 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 these entries
in general. Simple caching might result in a match against a cache
entry whereas an ordered search of the
endpoints. For host-to-host SAs, SPD would have resulted in a
match against a different entry. But, if the mode SPD entries are first
decorrelated, then the resulting entries can safely be either transport or
tunnel. cached, and

Kent [Page 28] 27]

Internet Draft Security Architecture for IP October 2003

Case 1. The case of providing end-to-end security between 2 hosts across the
Internet (or January 2004

each cached entry will map to an Intranet).

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

Note that either transport SA (or multiple SAs if "populate
from packet" (PFP) is specified), or tunnel mode can indicate that matching traffic
should be selected by the hosts.
So the headers in bypassed or discarded, appropriately.

Note: In a packet between H1 and H2 could look like any of host IPsec implementation based on sockets, the following:

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

Note that there SPD will
be consulted whenever a new socket is no requirement created, to support general nesting, but in
transport mode, both AH and ESP can determine what, if
any, IPsec processing will be applied to the packet. In this event, traffic that will flow
on that socket. This provides an implicit caching mechanism and the
SA establishment procedure MUST ensure
portions of the preceding discussion that first ESP, then AH 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 applied accustomed to managing these
sorts of access control lists or firewall filter rules. Then the
packet.

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

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

Only tunnel mode
decorrelation algorithm is required here. So applied, to allow caching of SPD entries.
The decorrelation is invisible at the headers in 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 packet between
SG1
protected interface and SG2 could look like either of the following:

Tunnel
---------------------
4. [IP2][AH][IP1][next]
5. [IP2][ESP][IP1][next] exiting via an unprotected interface.

Kent [Page 29] 28]

Internet Draft Security Architecture for IP October 2003

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

===============================================================
| |
| ========================= January 2004

Unprotected Interface
^
|
+----------+
...................|Forwarding|<-----+
: +----------+ |
: ^ |
: | Bypass |
---|-----------------|---- ---|-------------------|---
: +-----+ |
+-------+ +-------+ | SPD | +--------+
| SPD-I | |Discard|<---|Cache|---->| AH/ESP |
+-------+ +-------+ +-----+ +--------+
: ^
: |
: +-------------+
:................>|SPD Selection|
+-------------+
^
|
| H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* |
| Intranet) | | Intranet) |
-------------------------- ---------------------------
admin. boundary admin. boundary

Case 4. This covers the situation where a remote host (H1) uses
Protected Interface

Figure 2. Processing Model for Outbound Traffic

IPsec MUST perform the Internet
to reach an organization's firewall (SG2) and to then gain access to some server
or other machine (H2). The remote host could be a mobile host (H1) dialing up to following steps when processing outbound
packets:

1. when a local PPP/ARA server (not shown) on packet arrives from the Internet and then crossing subscriber (protected) interface,
invoke the Internet SPD lookup function to select the home organization's firewall (SG2), etc. The details of support for appropriate SPD. (If the
implementation uses only one SPD, this
case, (how H1 locates SG2, authenticates it, and verifies its authorization to
represent H2) are discussed in Section 4.6.3, "Locating a Security Gateway".

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

Only tunnel mode step is required between H1 and SG2. So the choices for a no-op.)

2. Match the
SA between H1 and SG2 would be one of packet headers against the ones in case 2. The choices cache for the SA
between H1 and H2 would be one of SPD specified
by the ones in case SPD-ID from step 1. Note that in this case, the sender MUST apply the transport header before cache contains entries from
SPD-O and SPD-S.

3a. If there is a match, then process the tunnel header. Therefore packet as specified by the management interface to
matching cache entry, i.e., bypass, discard, or apply AH or ESP in
the specified mode. If IPsec implementation
MUST support configuration of processing is applied, there is a link
from the SPD and SAD cache entry to ensure this ordering of IPsec
header application.

As noted above, support for additional combinations of the relevant 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 ESP Ken04a].

3b. If no match is
optional. Use 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 and inbound SPD cache entries. If the
SPD entry calls for creation of other, optional combinations may adversely affect
interoperability. an SA, the key management mechanism

Kent [Page 30] 29]

Internet Draft Security Architecture for IP October 2003

4.6 SA and Key Management

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

(e.g., IKEv2) is invoked to create the associated SA. If SA management techniques,
although the techniques involved do affect some of creation succeeds, a
new outbound (SPD-S) cache entry is created, along with an SAD entry,
otherwise the security
services offered packet is discarded. (A packet that triggers an SPD
lookup MAY be discarded by the protocols. For example, implementation, or it may be processed
against the optional anti-
replay services available newly created cache entry, if one is created.) Since SAs
are created in pairs, an SAD entry for AH and ESP require automated SA
management. Moreover, the granularity of key distribution employed
with IPsec determines the granularity of authentication provided.
(See corresponding inbound SA
also a discussion of this issue in Section 4.7.) In general,
data origin authentication in AH and ESP is limited by created, and it contains the extent to
which secrets selector values derived from the
SPD entry used with to create the authentication algorithm (or with a key
management protocol that creates such secrets) are shared among
multiple possible sources.

The following text describes the minimum requirements inbound SA, for both types
of use in checking inbound
traffic delivered via the SA management.

4.6.1 Manual Techniques .

4. The simplest form of management packet is manual management, in which a
person manually configures each system with keying material and
security association management data relevant passed 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 outbound forwarding function
(operating outside of sites is small, and
since all the sites come under the purview of a single administrative
domain, this is likely IPsec implementation), to be a feasible context for manual management
techniques. In this case, select the security gateway might selectively
protect traffic
interface to and from other sites within which the organization using
a manually configured key, while not protecting traffic for other
destinations. It also might packet will be appropriate when only selected
communications need directed. This function may
cause the packet to be secured. A similar argument might apply to
use of passed back across the IPsec entirely within an organization boundary, for a small number
additional IPsec processing, e.g., in support of
hosts and/or gateways. Manual management techniques often employ
statically configured, symmetric keys, though other options also
exist.

4.6.2 Automated SA and Key Management

Widespread deployment and use nested SAs. If so,
there MUST be an entry in SPD-I database that permits bypass of the
packet.

5.1.1 Handling an Outbound Packet That Must Be Dropped

If an IPsec requires system receives an Internet-standard,
scalable, automated, SA management protocol. Such support is
required to facilitate use outbound packet which it finds it must
drop, it SHOULD be capable of generating and sending an ICMP message
to indicate to the anti-replay features sender of AH and ESP, the outbound packet that the packet was
dropped. The type and to accommodate on-demand creation code of SAs, e.g., the ICMP message will depend on the
reason for user- dropping 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
session-oriented keying. (Note that the notion selector
values of "rekeying" the packet.

a. the selectors 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
actually implies creation required by the SPD
entry matching the packet because the IPsec peer at the other end
of a new SA the exchange is administratively prohibited from
communicating with a new SPI, a process that
the initiator and rejects the negotiation.

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

Kent [Page 31] 30]

Internet Draft Security Architecture for IP October 2003

generally implies use of an automated SA/key management protocol.)

The default automated key management protocol selected for use January 2004

IPv6 Type = 1 (destination unreachable)
Code = 1 (Communication with
IPsec is IKE [MSST97, Orm97, HC98] under destination administratively
prohibited)

b2. the IPsec domain of
interpretation [Pip98]. Other automated system was unable to set up the SA management protocols MAY
be employed.

When an automated SA/key management protocol is employed, required by
the output
from this protocol may SPD entry
matching the packet because the IPsec peer at the other end of the
exchange could not be used contacted.

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

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 generate multiple keys, e.g., an IPsec entity causing it
to send ICMP messages to W.X.Y.Z. This creates an opportunity for a
single ESP SA. This may arise because:

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

The Key Management System may provide
DoS attack among hosts behind a separate string of bits for
each key or it may generate one string of bits from which all of them
are extracted. If security gateway. To address this, a single string of bits is provided, care needs
security gateway SHOULD include a management control to
be taken allow an
administrator to ensure that the parts of the system that map the string
of bits configure an IPsec implementation to send or not
send the required keys do so in ICMP messages under these circumstances, and if this
facility is selected, to rate limit the same fashion at both ends transmission of such ICMP
responses.

5.1.2 Header Construction for Tunnel Mode

This section describes the SA. To ensure that the IPsec implementations at each end handling of the SA use the same bits inner and outer IP
headers, extension headers, and options for the same keys, AH and irrespective of which
part of the system divides ESP tunnels, with
regard to outbound traffic processing. This includes how to
construct the string of bits into individual keys, encapsulating (outer) IP header, how to process fields
in the encryption key(s) MUST inner IP header, and what other actions should be taken from the first (left-most, high-
order) bits 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 authentication key(s) MUST be taken from "endpoints" of the
remaining bits. tunnel (the encapsulator and
decapsulator). The number inner IP header Source Address and Destination
Addresses identify the original sender and recipient of bits for each key is defined in the
relevant algorithm specification RFC. In
datagram, (from the case perspective of multiple
encryption keys or multiple authentication keys, this tunnel), respectively.
(see footnote 3 after the specification table in 5.1.2.1 for more details on the algorithm must specify
encapsulating source IP address.)

o The inner IP header is not changed except as noted below for TTL
(or Hop Limit) and the order in which they are to be
selected from a single string of bits provided ECN Field. The inner IP header otherwise
remains unchanged during its delivery to the algorithm.

4.6.3 Locating a Security Gateway

This section discusses issues relating tunnel exit point.

o No change to how a host learns about IP options or extension headers in the
existence inner header

Kent [Page 31]

Internet Draft Security Architecture for IP January 2004

occurs during delivery 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 encapsulated datagram through the required information is
stored
tunnel.

Note: IPsec tunnel mode is a local matter.

Consider a situation different from IP-in-IP tunneling (RFC
2003) in which a remote host (H1) is using the
Internet to gain access several ways:

o IPsec offers certain controls 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 administrator to
manage covert channels (which would not normally be a mobile
host (Road Warrior) crossing the Internet concern for
tunneling) and to ensure that the home organization's
firewall (SG2). (See Case 4 in receiver examines the section 4.5 Basic Combinations right
portions of
Security Associations.) This situation raises several issues:

Kent [Page 32]

Internet Draft Security Architecture for IP October 2003

1. How does H1 know/learn about the existence received packet re: application of the security gateway SG2?

2. How does it authenticate SG2, and once it has authenticated SG2, access
controls. An IPsec implementation MAY be configurable with regard
to how does it
confirm that SG2 has been authorized to represent H2?

3. How does SG2 authenticate H1 processes the DSCP 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 verify that H1 is authorized
IPv6 header processing for IPsec tunnels. Another will allow the
DSCPfield to contact H2?

4. How does H1 know/learn about backup gateways which provide alternate paths be mapped 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 fixed value, which MAY be configured
on a security gateway per SA basis. (The value might really be fixed for any sets of
destination addresses all
traffic outbound from a device, but per SA granularity allows that require its use.
as well.) This includes the ability configuration option allows a local administrator
to configure:

o decide whether the requisite information for locating and authenticating covert channel provided by copying these
bits outweighs the security gateway
and verifying its authorization benefits of copying.

o IPsec describes how to represent the destination host. handle ECN or DSCP.

o IPsec allows the requisite information for locating and authenticating any backup gateways
and verifying their authorization to represent IP version of the destination host.

It is assumed encapsulating header to be
different from that of the SPD is also configured with policy information
that covers any other IPsec requirements for inner header.

The tables in the path to following sub-sections show the security
gateway and handling for the destination host.

This document does not address
different header/option fields ("constructed" means that the issue of how to automate value in
the
discovery/verification of security gateways. Note: The IP Security
Policy (IPSP) working group outer field is working on an"SG discovery, Policy
Exchange and Negotiation Protocol".

4.7 Security Associations and Multicast

The receiver-orientation constructed independently of the Security Association implies that, value in the case of unicast traffic, the destination system will normally
select the SPI value. By having the destination select the SPI
value, there is no potential for manually configured Security
Associations to conflict with automatically configured (e.g., via a
key management protocol)
inner).

Kent [Page 32]

Internet Draft Security Associations or for Security
Associations from multiple sources to conflict with each other. For
multicast traffic, there are multiple destination systems per
multicast group. So some system or person will need to coordinate
among all multicast groups to select an SPI or SPIs on behalf of each
multicast group and then communicate the group's IPsec information to
all of the legitimate members of that multicast group via mechanisms
not defined here.

Multiple senders to a multicast group SHOULD use a single Security

Kent [Page 33]

Internet Draft Security Architecture for IP October 2003

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

5. IP Traffic Processing

As mentioned in Section 4.4.1 "The Security Policy Database (SPD)",
the SPD must be consulted during the processing of all traffic
(INBOUND and OUTBOUND), including non-IPsec traffic. If no policy is
found in the SPD that matches the packet (for either inbound or
outbound traffic), the packet MUST be discarded.

NOTE: All of the cryptographic algorithms used in IPsec expect their
input in canonical network byte order (see Appendix in RFC 791) and
generate their output in canonical network byte order. IP packets
are also transmitted in network byte order.

5.1 Outbound IP Traffic Processing [Will change to reflect decisions re:
[40],[44],[45] new processing model; [46] nested/bundled SAs; and [81]
handling outbound fragments]

5.1.1 Selecting and Using an SA or SA Bundle

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

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

2. Match the packet's selector fields against those in the SA bundles
found in (1) to locate the first SA bundle that matches. If no SAs

Kent [Page 34]

Internet Draft Security Architecture for IP October 2003

were found or none match, create an appropriate SA bundle and link
the SPD entry to the SAD entry. If no key management entity is
found, drop the packet.

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

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.

NOTE: A compliant implementation MUST not allow instantiation of an
ESP SA that employs both a NULL encryption and a NULL authentication
algorithm. An attempt to negotiate such an SA is an auditable event.

5.1.2 Header Construction for Tunnel Mode

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

o The outer IP header Source Address and Destination Address identify
the "endpoints" of the tunnel (the encapsulator and decapsulator).
The inner IP header Source Address and Destination Addresses identify
the original sender and recipient of the datagram, (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 to decrement the TTL as
noted below, and remains unchanged during its delivery to the tunnel
exit point.

o No change to IP options or extension headers in the inner header
occurs during delivery of the encapsulated datagram through the tunnel.

o If need be, other protocol headers such as the IP Authentication
header may be inserted between the outer IP header and the inner IP
header.

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

Kent [Page 35]

Internet Draft Security Architecture for IP October 2003

5.1.2.1 IPv4 -- Header Construction for Tunnel Mode [May be affected by
decisions on [75] "TOS (now DSCP and ECN) copying in tunnel mode"]

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
fragmt offset constructed no change
TTL constructed (2) decrement (2)
protocol AH, ESP, routing hdr no change
checksum constructed constructed (2)
src address constructed (3) no change
dest address constructed (3) no change
Options never copied no change

1. The IP version in the encapsulating header can be different from the
value in the inner header.

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

NOTE: The decrementing of the TTL is one of the usual actions that
takes place when forwarding a packet. Packets originating from the same node as
the encapsulator do not have their TTL's decremented, as the sending node is
originating the packet rather than forwarding it.

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

NOTE: In principle, the encapsulating IP source address can be any 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 is reachable through the encapsulator from the environment into which
the packet is sent. This does not cause a problem because IPsec does not
currently have any INBOUND processing requirement that involves the Source Address
of the encapsulating IP header. So while the receiving tunnel endpoint looks at

Kent [Page 36]

Internet Draft Security Architecture for IP October 2003

the Destination Address in the encapsulating IP header, it only looks at the
Source Address in the inner (encapsulated) IP header.

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.

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

5.1.2.2 IPv6 -- Header Construction for Tunnel Mode [May be affected by decisions
on [75] "TOS (now DSCP and ECN) copying in tunnel mode"]

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

<-- How Outer Hdr Relates Inner Hdr --->
Outer Hdr at Inner Hdr at
IPv6 Encapsulator Decapsulator
Header fields: -------------------- ------------
version 6 (1) no change

DS Field copied from inner hdr (6) no change
ECN Field copied from inner hdr constructed (7)
flow id copied or configured no change
len 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 no change

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

(7) If the ECN field in the inner header is set to ECT(0) or ECT(1) and

Kent [Page 37]

Internet Draft Security Architecture for IP October 2003

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.

Note: IPsec does not copy the extension headers from the inner header into the
outer header, and IPsec does not construct the 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 [Will change to reflect [40],[44],[45] new
processing model and [46] SA nesting/bundles.

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

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

5.2.1 Selecting and Using an SA or SA Bundle [May change to reflect
decisions re: [85] DROP�d inbound packet � does not match SA]

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

1. To look up an SA: For unicast, the SPI may be used alone to select an
SA, or may be combined with the protocol, at the option of the receiver. For
multicast SAs, the SPI is combined with the destination address, and optionally
the source address, to select an SA. (See Section 4.4.3 for more details.) If the
SA lookup fails, drop the packet and log/report the error.

2. Use the SA found in (1) to do the IPsec processing, e.g., authenticate
and decrypt. This step includes matching the packet's (Inner Header if tunneled)
selectors to the selectors in the SA. Local policy determines the specificity of
the SA selectors (single value, list, range, wildcard). In general, a packet's
source address MUST match the SA selector value. However, an ICMP packet received
on a tunnel mode SA may have a source address other than that bound to the SA and
thus such packets should be permitted as exceptions to this check. For an ICMP
packet, the selectors from the enclosed problem packet (the source and destination
addresses and ports should be swapped) should be checked against the selectors for
the SA. Note that some or all of these selectors may be inaccessible because of
limitations on how many bits of the problem packet the ICMP packet is allowed to

Kent [Page 38]

Internet Draft Security Architecture for IP October 2003

carry or due to encryption. See Section 6.

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

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

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

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

If an IPsec system receives an inbound (unprotected) packet for which the matching
SPD entry requires IPsec protection, it MUST drop the packet. It SHOULD also be
capable of generating and sending an ICMP message to indicate to the sender that
the receiver dropped the packet. The reason SHOULD be recorded in the audit log.

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

IPv6 Type = 1 (destination unreachable)
Code = 1 (Communication with Destination Administratively Prohibited

Note that an attacker 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 to use an IPsec receiver in a DoS attack. To address this, the
implementation SHOULD provide management controls to allow an administrator to
configure an IPsec implementation to silently discard the packet or to respond
with the above ICMP message, and if this facility is selected, to rate limit the
transmission of such ICMP responses. If responding with an ICMP message is
supported, then rate limiting MUST be supported.

If an IPsec system receives an outbound packet which it finds it must drop, it
SHOULD be capable of generating and sending an ICMP message to indicate to the
sender of the outbound packet that the packet was dropped. The type and code of
the ICMP message will depend on the reason for dropping the packet. The reason
SHOULD be recorded in the audit log.

a. the selectors of the packet matched an SPD entry requiring the packet to be
dropped -->

Kent [Page 39]

Internet Draft Security Architecture for IP October 2003

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 and rejects the
negotiation.

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)

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 above ICMP message, and if this facility is selected, to rate limit
the transmission of such ICMP responses.

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

Note that in the case of a security gateway, if forwarding causes a
packet to exit via an IPsec-enabled interface, then additional IPsec

Kent [Page 40]

Internet Draft Security Architecture for IP October 2003

processing may be applied.

5.2.2 Handling of AH and ESP tunnels

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

6. ICMP Processing (relevant to IPsec).fi

The focus of this section is on the handling of ICMP error messages.
Other ICMP traffic, e.g., Echo/Reply, should be treated like other
traffic and can be protected on an end-to-end basis using SAs in the
usual fashion.

An ICMP error message protected by AH or ESP and generated by a
router SHOULD be processed and forwarded in a tunnel mode SA. Local
policy determines whether or not it is subjected to source address
checks by the router at the destination end of the tunnel. Note that
if the router at the originating end of the tunnel is forwarding an
ICMP error message from another router, the source address check
would fail. An ICMP message protected by AH or ESP and generated by
a router MUST NOT be forwarded on a transport mode SA (unless the SA
has been established to the router acting as a host, e.g., a Telnet
connection used to manage a router). An ICMP message generated by a
host SHOULD be checked against the source IP address selectors bound
to the SA in which the message arrives. Note that even if the source
of an ICMP error message is authenticated, the returned IP header
could be invalid. Accordingly, the selector values in the IP header
SHOULD also be checked to be sure that they are consistent with the
selectors for the SA over which the ICMP message was received.

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

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

Kent [Page 41]

Internet Draft Security Architecture for IP October 2003

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

Note: An IPsec system SHOULD provide controls that allow an
administrator to configure the IPsec system to set a threshold for
the minimum size to which the PTMU can be set via processing an ICMP
PMTU from a public Internet source. The default might be that the
ciphertext size would be 576 bytes (IPv4) or 1280 (IPv6).

6.1 PMTU/DF Processing

6.1.1 DF Bit

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

6.1.2 Path MTU Discovery (PMTU) [May change to reflect decisions re:
[78] PMTU discovery]

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

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

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

6.1.2.1 Propagation of PMTU

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

Kent [Page 42]

Internet Draft Security Architecture for IP October 2003

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

a. if the originating host can be determined (or the possible sources
narrowed down to a manageable number), send the PMTU information to all the
possible originating hosts.

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

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

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

6.1.2.2 Calculation of PMTU

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

Note: In some situations the addition of IPsec headers could result
in an effective PMTU (as seen by the host or application) that is
unacceptably small. To avoid this problem, the implementation may
establish a threshold below which it will not report a reduced PMTU.
In such cases, the implementation would apply IPsec and then fragment
the resulting packet according to the PMTU. This would result in a
more efficient use of the available bandwidth.

6.1.2.3 Granularity of PMTU Processing

In hosts, the granularity with which ICMP PMTU processing can be done
differs depending on the implementation situation. Looking at a

Kent [Page 43]

Internet Draft Security Architecture for IP October 2003

host, there are 3 situations that are of interest with respect to
PMTU issues (See Appendix B for additional details on this topic.):

a. Integration of IPsec into the native IP implementation

b. Bump-in-the-stack implementations, where IPsec is implemented
"underneath" an existing implementation of a TCP/IP protocol stack, between the
native IP and the local network drivers

c. No IPsec implementation -- This case is included because it is
relevant in cases where a security gateway is sending PMTU information back to a
host.

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

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

6.1.2.4 PMTU Aging

In all systems (host or gateway) implementing IPsec and maintaining
PMTU information, the PMTU associated with a security association
(transport or tunnel) MUST be "aged" and some mechanism put in place
for updating the PMTU in a timely manner, especially for discovering
if the PMTU is smaller than it needs to be. A given PMTU has to
remain in place long enough for a packet to get from the source end
of the security association to the system at the other end of the
security association and propagate back an ICMP error message if the
current PMTU is too big. Note that if there are nested tunnels,
multiple packets and round trip times might be required to get an
ICMP message back to an encapsulator or originating host.

Systems SHOULD use the approach described in the Path MTU Discovery

Kent [Page 44]

Internet Draft Security Architecture for IP October 2003

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

7. Auditing

Not all systems that implement IPsec will implement auditing. For
the most part, the granularity of auditing is a local matter.
However, several auditable events are identified in the AH and ESP
specifications and for each of these events a minimum set of
information that SHOULD be included in an audit log is defined.
Additional information also MAY be included in the audit log for each
of these events, and additional events, not explicitly called out in
this specification, also MAY result in audit log entries. There is
no requirement for the receiver to transmit any message to the
purported transmitter in response to the detection of an auditable
event, because of the potential to induce denial of service via such
action.

8. Use in Systems Supporting Information Flow Security

Information of various sensitivity levels may be carried over a
single network. Information labels (e.g., Unclassified, Company
Proprietary, Secret) [DoD85, DoD87] are often employed to distinguish
such information. The use of labels facilitates segregation of
information, in support of information flow security models, e.g.,
the Bell-LaPadula model [BL73]. Such models, and corresponding
supporting technology, are designed to prevent the unauthorized flow
of sensitive information, even in the face of Trojan Horse attacks.
Conventional, discretionary access control (DAC) mechanisms, e.g.,
based on access control lists, generally are not sufficient to
support such policies, and thus facilities such as the SPD do not
suffice in such environments.

In the military context, technology that supports such models is
often referred to as multi-level security (MLS). Computers and
networks often are designated "multi-level secure" if they support
the separation of labelled data in conjunction with information flow
security policies. Although such technology is more broadly
applicable than just military applications, this document uses the
acronym "MLS" to designate the technology, consistent with much
extant literature.

IPsec mechanisms can easily support MLS networking. MLS networking
requires the use of strong Mandatory Access Controls (MAC), which
unprivileged users or unprivileged processes are incapable of
controlling or violating. This section pertains only to the use of

Kent [Page 45]

Internet Draft Security Architecture for IP October 2003

these IP security mechanisms in MLS (information flow security
policy) environments. Nothing in this section applies to systems not
claiming to provide MLS.

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

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

Encryption is useful and can be desirable even when all of the hosts
are within a protected environment, for example, behind a firewall or
disjoint from any external connectivity. ESP can be used, in
conjunction with appropriate key management and encryption
algorithms, in support of both DAC and MAC. (The choice of
encryption and authentication algorithms, and the assurance level of
an IPsec implementation will determine the environments in which an
implementation may be deemed sufficient to satisfy MLS requirements.)
Key management can make use of sensitivity information to provide
MAC. IPsec implementations on systems claiming to provide MLS SHOULD
be capable of using IPsec to provide MAC for IP-based communications.

8.1 Relationship Between Security Associations and Data Sensitivity

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

Kent [Page 46]

Internet Draft Security Architecture for IP October 2003

8.2 Sensitivity Consistency Checking

An MLS implementation (both host and router) MAY associate
sensitivity information, or a range of sensitivity information with
an interface, or a configured IP address with its associated prefix
(the latter is sometimes referred to as a logical interface, or an
interface alias). If such properties exist, an implementation SHOULD
compare the sensitivity information associated with the packet
against the sensitivity information associated with the interface or
address/prefix from which the packet arrived, or through which the
packet will depart. This check will either verify that the
sensitivities match, or that the packet's sensitivity falls within
the range of the interface or address/prefix.

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

8.3 Additional MLS Attributes for Security Association Databases

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

- Sensitivity information.

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

8.4 Additional Inbound Processing Steps for MLS Networking

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

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

Kent [Page 47]

Internet Draft Security Architecture for IP October 2003

8.5 Additional Outbound Processing Steps for MLS Networking

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

8.6 Additional MLS Processing for Security Gateways

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

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

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

9. Performance Issues [May change to reflect changes in [40],[44],[45]
processing model and [46] SA nesting/bundles.

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

Kent [Page 48]

Internet Draft Security Architecture for IP October 2003

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

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

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

10. Conformance Requirements

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

11. Security Considerations

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

12. Differences from RFC 2401 [Will change]

This architecture document differs substantially from RFC 2401 in
detail and in organization, but the fundamental notions are
unchanged. This document provides considerable additional detail in
terms of compliance specifications. It introduces the SPD and SAD,
and the notion of SA selectors. It is aligned with the new versions
of AH and ESP, which also differ from their predecessors. Specific

Kent [Page 49]

Internet Draft Security Architecture for IP October 2003

requirements for supported combinations of AH and ESP are newly
added, as are details of PMTU management.

Acknowledgements

The author would like to acknowledge the contributions of Ran
Atkinson, who played a critical role in initial IPsec activities, and
who authored the first series of IPsec standards: RFCs 1825-1827.
Karen Seo deserves special thanks for providing help in the editing
of this and the previous version of this specification. The author
also would like to thank the members of the IPsec and MSEC working
groups who have contributed to the development of this protocol
specification.

[For implementors using decorrelation, there may be an appendix with
implementor's notes describing how to avoid creating any unnecessary
SAs for a set of decorrelated SPD entries created from the same
original correlated SPD entry when one or more selector values are
populated from subscriber traffic.]

Kent [Page 50]

Internet Draft Security Architecture Architecture for IP October 2003

Appendix A January 2004

5.1.2.1 IPv4 -- Glossary

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

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

o for a security gateway, a network behind the gateway or bandwidth on
that network.

Anti-replay
[See "Integrity" below]

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

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

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

Kent [Page 51]

Internet Draft Security Architecture for IP October 2003

Encryption
Encryption is a security mechanism used to transform data encapsulating header can be
different from an
intelligible form (plaintext) into an unintelligible form
(ciphertext), to provide confidentiality. the value in the inner header.

2. The inverse
transformation process is designated "decryption". Oftimes TTL in the
term "encryption" inner header is used to generically refer decremented by the
encapsulator prior to both processes.

Data Origin Authentication
Data origin authentication is a security service that verifies forwarding and by the
identity of decapsulator
if it forwards the claimed source of data. This service is usually
bundled with connectionless integrity service.

Integrity
Integrity packet. (The checksum changes when
the TTL changes.)

Note: Decrementing the TTL value 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 normal part of integrity:
connectionless and
forwarding a form of partial sequence integrity.
Connectionless integrity is packet. Thus, a service that detects modification of
an individual IP datagram, without regard to the ordering of packet originating from the
datagram in a stream of traffic. The form of partial sequence
integrity offered in IPsec is referred to
same node as anti-replay
integrity, and it detects arrival of duplicate IP datagrams
(within a constrained window). This is in contrast to connection-
oriented integrity, which imposes more stringent sequencing
requirements on traffic, e.g., to be able to detect lost or re-
ordered messages. Although authentication and integrity services
often are cited separately, in practice they are intimately
connected and almost always offered in tandem.

Security Association (SA)
A simplex (uni-directional) logical connection, created for
security purposes. All traffic traversing an SA the encapsulator does not have its TTL decremented,
since the sending node is provided originating the
same security processing. In IPsec, an SA packet rather than
forwarding it.

3. src and dest addresses depend on the SA, which is an internet layer
abstraction implemented through used to
determine the use of AH or ESP.

Security Gateway
A security gateway dest address which in turn determines which
src address (net interface) is an intermediate system that acts as used to forward the
communications interface between two networks. packet.

Note: The set of hosts
(and networks) on source address that appears in the external side of encapsulating
tunnel header MUST be the security gateway is
viewed as untrusted (or less trusted), while one that was negotiated during the networks and
hosts and on
SA establishment process. In principle, the internal side are viewed as trusted (or more
trusted). The internal subnets and hosts served by a security
gateway are presumed to encapsulating IP
source address can be trusted by virtue any of sharing a common,
local, security administration. (See "Trusted Subnetwork" below.)
In the IPsec context, 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 security gateway NAT
box) so long as the address is a point at reachable through the
encapsulator from the environment into which AH
and/or ESP the packet is implemented
sent.

Kent [Page 33]

Internet Draft Security Architecture for IP January 2004

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 order the outer header is not appropriate, that
value MUST be mapped to serve a set of internal
hosts, providing security services an appropriate value for these hosts when they
communicate with external hosts also employing IPsec (either

Kent [Page 52]

Internet Draft Security Architecture the domain
[RFC 2474]. See [RFC 2475] for IP October 2003

directly further information.

6. If the ECN field in the inner header is set to ECT(0) or via another security gateway).

SPI
Acronym for "Security Parameters Index". The combination of a
destination address, a security protocol,
ECT(1) and an SPI uniquely
identifies a security association (SA, see above). The SPI is
carried the ECN field in AH and ESP protocols the outer header is set to enable CE,
then set the receiving system ECN field in the inner header to CE, otherwise
make no change to
select the SA under which a received packet will be processed. An
SPI has only local significance, as defined by ECN field in the creator of inner header. The
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.

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 no change

Note: IPsec does not copy the
SA (usually extension headers from the receiver of inner header
into the packet carrying outer header, nor does IPsec construct extension headers in
the SPI); thus an
SPI is generally viewed as an opaque bit string. outer header. However, the
creator of an SA may choose to interpret the bits in an SPI to
facilitate local processing.

Traffic Analysis
The analysis of network traffic flow post-IPsec code MAY insert/construct
extension headers for the purpose of deducing
information that is useful to an adversary. Examples of such
information are frequency of transmission, the identities of the
conversing parties, sizes of packets, flow identifiers, etc.
[Sch94]

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

Kent [Page 53] 34]

Internet Draft Security Architecture for IP October 2003

Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues [May
be changed depending on decisions re: [78] PMTU handling]

B.1 DF bit

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

Fragmenting seems correct for some situations, e.g., it might be
appropriate to fragment packets over a network with a very small MTU,
e.g., a packet radio network, or a cellular phone hop to mobile node,
rather than propagate back a very small PMTU for use over the rest Architecture for IP January 2004

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

Inbound processing is somewhat different from outbound processing,
because of the path. In other situations, it might be appropriate use of SPIs to set the DF
bit in order map IPsec protected traffic to get feedback from later routers about PMTU
constraints which require fragmentation. SAs. The existence of both of
these situations argues for enabling a system
inbound SPD cache (SPD-I) is applied only to decide whether bypassed or
not to fragment over a particular network "link", i.e., for requiring discarded
traffic. If an implementation arriving packet appears to be able to copy the DF bit (and to process ICMP
PMTU messages), but making it an option to be selected on a per
interface basis. In other words, IPsec fragment from
an administrator should be able unprotected interface, reassembly is performed prior to
configure the router's treatment of the DF bit (set, clear, copy from
encapsulated header) IPsec
processing. The intent for each interface.

Note: If any SPD cache is that a bump-in-the-stack implementation of IPsec attempts packet that fails
to
apply different IPsec algorithms based on source/destination ports,
it will be difficult match any entry is then referred to apply Path MTU adjustments.

B.2 Fragmentation [May change depending on decisions re: [78] PMTU
handling the corresponding SPD. Every
SPD SHOULD have a nominal, final entry that catches anything that is
otherwise unmatched, and community response to Mark Duffy�s proposed approach to
red-side fragmentation. discards it. This assumes ensures that ssues [49] & [81] red-side
fragmentation and handling outbound fragments] have been rejected by the
list.].fi

If required, IP fragmentation occurs after IPsec processing within an
IPsec implementation. Thus, transport mode AH or ESP is applied only
to whole IP datagrams (not to IP fragments). An IP packet to which
AH or ESP has been applied may itself be fragmented by routers en
route, non-IPsec
protected traffic that arrives and such fragments MUST does not match any SPD-I entry
will be reassembled prior to discarded.

Unprotected Interface
|
V
+-----+ IPsec
processing at a receiver. In tunnel mode, protected
...................>|Demux|-------------------+
: +-----+ |
: | |
: | Not 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 to performing AH or ESP is applied to an
IP packet, the payload of which may be a fragmented processing, any IP packet. For
example, a security gateway, "bump-in-the-stack" (BITS), or "bump-in-
the-wire" (BITW) IPsec implementation may apply tunnel mode AH to
such fragments. Note fragments that BITS or BITW implementations
arrive via the unprotected interface are examples
of where a host IPsec implementation might receive fragments reassembled (by IP). Each
inbound IP datagram to which
tunnel mode is to IPsec processing will be applied. However, if transport mode applied is to be
applied, then these implementations MUST reassemble the fragments
prior to applying IPsec.

Kent [Page 54] 35]

Internet Draft Security Architecture for IP October 2003

NOTE: IPsec always has to figure out what January 2004

identified by the encapsulating IP header
fields are. This is independent appearance of where you insert IPsec and is
intrinsic to the definition of IPsec. Therefore any IPsec
implementation that is not integrated into an IP implementation must
include code to construct AH or ESP values in the necessary IP headers (e.g., IP2):

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

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

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

AH Xport Next
Protocol field (or of AH Tunnel ESP Xport or ESP Tunnel
Implementation approach IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 as an extension header in the IPv6
----------------------- ---- ---- ---- ---- ---- ---- ---- ----
Hosts (integr w/ IP stack) Y Y Y Y Y Y Y Y
Hosts (betw/ IP and drivers) Y Y Y Y Y Y Y Y
S. Gwy (integr w/ IP stack) Y Y Y Y
Outboard crypto processor *

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

2. The packet is examined and demuxed into one of three categories:
- If the crypto processor system has its own IP address, then packet appears to be IPsec protected and it is
covered by addressed to
this device, an attempt is made to map it to an active SA
via the security gateway case. This box receives SAD.
- Traffic not addressed to this device is directed to BYPASS/DISCARD
lookup. If multiple SPDs are employed, the tag assigned to the packet from
in step 1 is used to select the host
and performs IPsec processing. It has appropriate SPD-I (and cache) to be able
search.
- ICMP traffic directed to handle the same AH, ESP, and
related IPv4/IPv6 tunnel processing that a security gateway would have this device is directed to handle.
"unprotected" ICMP
processing (see Section 6).

3a. If it doesn't have it's own address, then it the packet is similar addressed to the bump-in-the stack
implementation between IP IPsec device and AH or ESP is
specified as the network drivers.

The following analysis assumes that:

1. There protocol, the packet is only one IPsec module looked up in a given system's stack. There isn't
an IPsec module A (adding ESP/encryption and thus) hiding the transport protocol,
SRC port, and DEST port SAD
identified by the SPD-ID from IPsec module B.

2. There are several places where IPsec could be implemented (as shown in step 1. For unicast traffic, use only
the table above).

a. Hosts with integration of IPsec into SPI. For multicast traffic, use the native IP
implementation. Implementer has access to SPI plus the source for and/or
destination addresses, as specified in the stack.

b. Hosts with bump-in-the-stack implementations, where IPsec SAD. If there is
implemented between IP and no match,
discard the local network drivers. Source access for stack traffic. This is
not available; but there are well-defined interfaces that allows the IPsec code to
be incorporated into an auditable event. The audit log entry
for this event SHOULD include the system.

c. Security gateways current date/time, SPI, source and outboard crypto processors with
integration
destination of IPsec into the stack.

Kent [Page 55]

Internet Draft Security Architecture for IP October 2003

3. Not all packet, IPsec protocol, and any other selector
values of the above approaches are feasible in all hosts. But it was
assumed packet that for each approach, there are some hosts for whom available. If the approach packet is
feasible.

For each of found in
the above 3 categories, there are IPv4 and IPv6, AH
transport and tunnel modes, and ESP transport and tunnel modes -- for
a total of 24 cases (3 x 2 x SAD, process it accordingly (see step 4).

Some header fields and interface fields are listed here for ease of
reference -- they're not in

3b. If the header order, but instead listed packet is not addressed to
allow comparison between the columns. (* = not covered by AH
authentication. ESP authentication doesn't cover any headers that
precede it.)

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

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

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

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

Kent [Page 56]

Internet Draft Security Architecture for IP October 2003

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

b. Hosts (Bump-in-the-stack) -- put IPsec between IP layer packet
header in the (appropriate) SPD-I cache. If there is a match and network
drivers. In this case, the IPsec module would have
packet is to be discarded or bypassed, do something like one 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 following traffic. This is an auditable event. The audit log entry
for fragmentation this event SHOULD include the current date/time, SPI if
available, IPsec protocol if available, source and reassembly.

- do destination of the fragmentation/reassembly work itself
packet, and send/receive any other selector values of the packet directly to/from that are
available.

3c. Unprotected ICMP processing is assumed to take place on the network layer. In AH or ESP transport mode, this
unprotected side of the IPsec boundary. Unprotected ICMP messages are
examined and local policy is
fine. In AH applied to determine whether to accept
or ESP tunnel mode where the tunnel end reject these messages and, if accepted, what action to take as a

Kent [Page 36]

Internet Draft Security Architecture for IP January 2004

result. For example, if an ICMP unreachable message is at received, the ultimate
destination, this is fine. But in
implementation must decide whether to act on it, reject it, or act on
it with constraints. [See Section 6.]

4. Apply AH or ESP tunnel modes where the tunnel end is
different from the ultimate destination and where processing as specified, using the source host is multi-homed,
this approach could result SAD entry
selected in sub-optimal routing because step 2a above. Then match the IPsec module may be
unable to obtain packet against the information needed (LAN interface and next-hop gateway) inbound
selectors identified by the SAD entry to
direct verify that the received
packet to the appropriate network interface. This is not a problem if appropriate for the interface SA via which it was received.

If an IPsec system receives an inbound packet on an SA and next-hop gateway the
packet's header fields are not consistent with the same selectors for the ultimate destination and
SA, it MUST drop the packet. This is an auditable event. The audit
log entry for this event SHOULD include the tunnel end. But if they are different, then current date/time, SPI,
IPsec would need to know the
LAN interface protocol(s), source and destination of the next-hop gateway for packet, and any
other selector values of the tunnel end. (Note: The tunnel end
(security gateway) is highly likely to be on packet that are available, and the regular path to
selector values from the ultimate
destination. But there could relevant SAD entry. The system SHOULD also
be more than one path capable of generating and sending an IKE notification to the destination, e.g.,
sender (IPsec peer), indicating that the host could received packet was dropped
because of failure to pass selector checks.

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

MAY be at sent in an organization with 2 firewalls. And IKE INFORMATIONAL Exchange when a node
receives an ESP or AH packet whose selectors do not match
those of the path being used
could involve SA on which it was delivered (and which
caused the less commonly chosen firewall.) OR

- pass packet to be dropped). The Notification Data
contains the start of the IPsec'd offending packet back (as in ICMP
messages) and the SPI field of the notification is set to
match the IP layer where 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 extra IP
header would end up being pre-pended
administrator to configure the IPsec implementation to send or not
send this IKE notification, and if this facility is selected, to rate
limit the IPsec module would have transmission of such notifications.

After traffic is bypassed or processed through IPsec, it is handed to check and
let IPsec'd fragments go by.

- pass
the inbound forwarding function for disposition. This function may
cause the packet contents to be sent across the IP layer IPsec boundary for additional
inbound IPsec processing, e.g., in a form such support of nested SAs. If so, then
as with ALL outbound traffic that the IP
layer recreates an appropriate IP header At the network layer, the IPsec module
will have access is to the following selectors from be bypassed, the packet -- SRC address, DST
address, Next Protocol, and if there's a transport layer header --> SRC port and
DST port. One cannot assume IPsec has access to the Name. It is assumed that MUST
be matched against an SPD-O entry. Ultimately, the
available selector information is sufficient packet should be
forwarded to figure out the relevant Security
Policy entry and Security Association(s).

o AH-transport --> (IP1-AH-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer)
- IPv4 -- works destination host or process for disposition.

Kent [Page 57] 37]

Internet Draft Security Architecture for IP October 2003

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

c. Security gateways -- integrate January 2004

6. ICMP Processing [This section will be filled in when IPsec into the IP stack issue # 91
is resolved. The following text needs to be inserted somewhere, possibly
this section.]

NOTE: With the exception of IPv4 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 may only match
rules having port selectors of OPAQUE or "ANY".

7. Auditing

Not all systems that implement IPsec module will have access to implement auditing. For
the following selectors from most part, the packet -- SRC address, DST address, Next Protocol, and if there's granularity of auditing is a transport
layer header --> SRC port local matter.
However, several auditable events are identified in this document and DST port. It won't have access to the User ID (only
Hosts have access to User ID information.) Unlike some Bump-in-the-stack
implementations, security gateways may
for each of these events a minimum set of information that SHOULD be able to look up the Source Address
included in
the DNS to provide a System Name, e.g., an audit log is defined. Additional information also MAY
be included in situations involving use the audit log for each of dynamically
assigned IP addresses these events, and additional
events, not explicitly called out in conjunction with dynamically updated DNS entries. It this specification, also won't have access MAY
result in audit log entries. There is no requirement for the
receiver to transmit any message to the transport layer information if there is purported transmitter in
response to the detection of an ESP
header, or if it's not auditable event, because of the first fragment
potential to induce denial of a fragmented message. It is assumed service via such action.

8. Conformance Requirements

All IPv4 systems that the available selector information is sufficient claim to figure out the relevant 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.

9. Security Policy entry 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 from RFC 2401 in
detail and Security Association(s).

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

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

B.3 Path MTU Discovery

As mentioned earlier, "ICMP PMTU" refers to an ICMP message used for
Path MTU Discovery. in organization, but the fundamental notions are
unchanged.

Acknowledgements

The legend for authors would like to acknowledge the diagrams below contributions of Ran
Atkinson, who played a critical role in B.3.1 initial IPsec activities, and B.3.3 (but not B.3.2)
is:
who authored the first series of IPsec standards: RFCs 1825-1827.

Kent [Page 58] 38]

Internet Draft Security Architecture for IP October 2003

==== = security association (AH or ESP, transport or tunnel)
---- = connectivity (or if so labelled, administrative boundary)
.... = ICMP message (hereafter referred January 2004

Also a contributor who wishes to as ICMP PMTU) remain nameless, deserves special
thanks for

IPv4:
- Type = 3 (Destination Unreachable)
- Code = 4 (Fragmentation needed and DF set)
- Next-Hop MTU providing extensive help in the low-order 16 bits of the second word editing of the ICMP header
(labelled unused in RFC 792), with high-order 16 bits set this
specification. The authors also would like to zero

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

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

B.3.1 Identifying and MSEC working groups who have contributed to the Originating Host(s)

The amount
development of information returned with the ICMP message is limited this protocol specification.

Kent [Page 39]

Internet Draft Security Architecture for IP January 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 affects what selectors glossary are available to identify generic
security
associations, originating hosts, etc. for use in further propagating
the PMTU information.

In brief... An ICMP message must contain the following information
from the "offending" packet:
- IPv4 (RFC 792) -- IP header service and security mechanism terms, plus IPsec-specific
terms.

Access Control
Access control is a minimum security service that prevents unauthorized
use of 64 bits

Accordingly, a resource, including the prevention of use of a resource
in an unauthorized manner. In the IPv4 IPsec context, an ICMP PMTU may identify only the
first (outermost) resource to
which access is being controlled is often:
o for a host, computing cycles or data
o for a security association. gateway, a network behind the gateway
or bandwidth on that network.

Anti-replay
[See "Integrity" below]

Authentication
This term is because used informally to refer to the ICMP
PMTU may contain only 64 bits combination of two
nominally distinct security services, data origin authentication
and connectionless integrity. See the "offending" packet beyond the IP
header, which would capture only definitions below for each
of these services.

Availability
Availability, when viewed as a security service, addresses the first SPI from AH
security concerns engendered by attacks against networks that deny
or ESP. In degrade service. For example, in the IPv6 IPsec context, an ICMP PMTU will probably provide all the SPIs use of
anti-replay mechanisms in AH and ESP support availability.

Confidentiality
Confidentiality is the selectors security service that protects data from
unauthorized disclosure. The primary confidentiality concern in the IP header,
most instances is unauthorized disclosure of application level
data, but maybe not disclosure of the SRC/DST ports (in external characteristics of
communication also can be a concern in some circumstances.
Traffic flow confidentiality is the transport header) service that addresses this
latter concern by concealing source and destination addresses,
message length, or frequency of communication. In the encapsulated (TCP, UDP, etc.) protocol.
Moreover, if IPsec
context, using ESP is used, the transport ports and protocol selectors
may be encrypted.

Looking in tunnel mode, especially at the diagram below of a security gateway tunnel (as
mentioned elsewhere,
gateway, can provide some level of traffic flow confidentiality.
(See also traffic analysis, below.)

Data Origin Authentication
Data origin authentication is a security gateways do not use transport mode)... service that verifies the

Kent [Page 59] 40]

Internet Draft Security Architecture for IP October 2003

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

Suppose that January 2004

identity of the claimed source of data. This service is usually
bundled with connectionless integrity service.

Encryption
Encryption is a security policy for SG1 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 use generically refer to both processes.

Integrity
Integrity is a single SA security service that ensures that modifications to SG2
for all the traffic between hosts H0, H1, and H2
data are detectable. Integrity comes in various flavors to match
application requirements. IPsec supports two forms of integrity:
connectionless and hosts H3, H4, a form of partial sequence integrity.
Connectionless integrity is a service that detects modification of
an individual IP datagram, without regard to the ordering of the
datagram in a stream of traffic. The form of partial sequence
integrity offered in IPsec is referred to as anti-replay
integrity, and H5. And suppose H0 sends it detects arrival of duplicate IP datagrams
(within a data packet constrained window). This is in contrast to H5 connection-
oriented integrity, which causes R1 to
send an ICMP PMTU message imposes more stringent sequencing
requirements on traffic, e.g., to SG1. If the PMTU message has only the
SPI, SG1 will be able to look up the SA detect lost or re-
ordered messages. Although authentication and find the list of possible
hosts (H0, H1, H2, wildcard); but SG1 will have no way integrity services
often are cited separately, in practice they are intimately
connected and almost always offered in tandem.

Protected vs Unprotected

"Protected" refers to figure out
that H0 sent the traffic systems or interfaces that triggered are inside
the ICMP PMTU message.

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

(*) The 64 bits will include enough of the ESP (or AH) header protection boundary and "unprotected" refers to include the SPI.
- ESP -- SPI (32 bits), Seq number (32 bits)
- AH -- Next header (8 bits), Payload Len (8 bits), Reserved (16
bits), SPI (32 bits)

This limitation on
systems or interfaces that are outside the amount of information returned with an ICMP
message creates IPsec protection
boundary. IPsec provides a problem barrier through which traffic passes.
There is an asymmetry to this barrier, which is reflected in identifying the originating hosts for the packet (so as to know where to further propagate
processing model. Outbound data, if not discarded or bypassed, is
protected via the ICMP PMTU
information). If application of AH or ESP and the ICMP message contains only 64 bits addition of the IPsec
header (minimum for IPv4), then
corresponding headers. Inbound data, if not discarded or
bypassed, is processed via the removal of AH or ESP headers. In
this document, inbound traffic enters an IPsec selectors (e.g., Source and
Destination addresses, Next Protocol, Source and Destination ports,
etc.) will have been lost. But implementation from
the ICMP error message will still
provide SG1 with "unprotected" interface. Outbound traffic enters the SPI,
implementation via the "protected" interface, or is emitted by the
implementation on the "protected" side of the PMTU information boundary and
directed toward the source and
destination gateways for "unprotected" interface. An IPsec
implementation may support more than one interface on either or
both sides of the relevant security association. boundary. The destination security gateway and SPI uniquely define a security
association which protected interface may be
internal, e.g., in turn defines a set host implementation of possible originating
hosts. At this point, SG1 could: IPsec. The protected
interface may link to a socket layer interface presented by the

Kent [Page 60] 41]

Internet Draft Security Architecture for IP October 2003

a. send the PMTU information to all the possible originating hosts. This
would not work well if the host list January 2004

OS.

Security Association (SA)
A simplex (uni-directional) logical connection, created for
security purposes. All traffic traversing an SA is a wild card or if many/most of provided the hosts
weren't sending to SG1; but it might work if
same security processing. In IPsec, an SA is an internet layer
abstraction implemented through the SPI/destination/etc mapped to
just one or a small number use of hosts.

b. store the PMTU AH or ESP. State data
associated with an SA is represented in the SPI/etc and wait until Security Association
Database (SAD).

Security Gateway
A security gateway is an intermediate system that acts as the next packet(s) arrive
from
communications interface between two networks. The set of hosts
(and networks) on the originating host(s) for external side of the relevant security association. If it/they gateway is
termed unprotected (they are bigger at generally at least less protected
than those "behind the PMTU, drop SG), while the packet(s), networks and compose ICMP PMTU message(s)
with the new packet(s) hosts and on
the updated PMTU, internal side are viewed as protected. The internal subnets
and send the originating host(s) the
ICMP message(s) about the problem. This involves hosts served by a delay in notifying the
originating host(s), but avoids the problems security gateway are presumed to be trusted
by virtue of (a).

Since only sharing a common, local, security administration.
(See "Trusted Subnetwork" below.) In the latter approach is feasible in all instances, IPsec context, a
security gateway MUST provide such support, as an option. However,
if the ICMP message contains more information from the original
packet, then there may be enough information to immediately determine
to is a point at which host to propagate the ICMP/PMTU message and AH and/or ESP is implemented
in order to provide that
system serve a set of internal hosts, providing security
services for these hosts when they communicate with the 5 fields (source address, external hosts
also employing IPsec (either directly or via another security
gateway).

SPI
Acronym for "Security Parameters Index" (SPI). The combination of
a destination address, source
port, destination port, and transport protocol) needed to determine
where to store/update the PMTU. Under such circumstances, a security
gateway MUST generate an ICMP PMTU message immediately upon receipt
of protocol, and an ICMP PMTU from further down SPI uniquely
identifies a security association (SA, see above) in the path. NOTE: context
of unicast or anycast traffic. Additional IP address information
is used to identify multicast SAs. The Next Protocol
field may not be contained SPI is carried in the ICMP message AH and the use of
ESP
encryption may hide protocols to enable the selector fields that have been encrypted.

B.3.2 Calculation 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 PMTU

The calculation the SA (usually
the receiver of PMTU from the packet carrying the SPI); thus an ICMP PMTU has to take into account SPI is
generally viewed as an opaque bit string. However, the addition creator of any IPsec header by H1 -- AH and/or ESP transport, or
ESP or AH tunnel. Within a single host, multiple applications
an SA may
share choose to interpret the bits in an SPI and nesting of security associations may occur. (See
Section 4.5 Basic Combinations to facilitate
local processing.

Traffic Analysis
The analysis of Security Associations network traffic flow for
description of the combinations purpose of deducing
information that MUST be supported). The diagram
below illustrates is useful to an example adversary. Examples of security associations between a pair such
information are frequency of hosts (as viewed from transmission, the perspective of one identities of the hosts.) (ESPx
or AHx = transport mode)

Socket 1 -------------------------|
|
Socket 2 (ESPx/SPI-A) ---------- AHx (SPI-B) -- Internet

In order to figure out the PMTU for each socket that maps to SPI-B,
it will be necessary to have backpointers from SPI-B to each
conversing parties, sizes of the 2
paths that lead to it - - Socket 1 and Socket 2/SPI-A. packets, flow identifiers, etc.
[Sch94]

Kent [Page 61] 42]

Internet Draft Security Architecture for IP October 2003

B.3.3 Granularity of Maintaining PMTU Data

In hosts, the granularity with which PMTU ICMP processing can be done
differs depending January 2004

Appendix B - Decorrelation

This section is based on work done in the implementation situation. Looking at a
host, there are three situations that are of interest with respect to
PMTU issues:

a. Integration of IPsec into the native IP implementation

b. Bump-in-the-stack implementations, where IPsec Security Policy Working
Group by Luis Sanchez, Matt Condell, and John Zao.

Two SPD entries are correlated if there is implemented "underneath"
an existing implementation of a TCP/IP protocol stack, non-null intersection
between the native IP and
the local network drivers

c. No IPsec implementation -- This case is included because it is relevant values of corresponding selectors in
cases where a security gateway each entry. Caching
correlated SPD entries can lead to incorrect policy enforcement. A
solution to this problem, that still allows for caching, is sending PMTU information back to remove
the ambiguities by decorrelating the entries. That is, the SPD
entries must be rewritten so that for every pair of entries there
exists a selector for which there is a host.

Only in case (a) can the PMTU data be maintained at null intersection between the same
granularity as communication associations. In
values in both of the other cases, entries. Once the
IP layer entries are decorrelated,
there is no longer any ordering requirement on them, since only one
entry will maintain PMTU data at the granularity of Source and
Destination IP addresses (and optionally TOS/Class), as described match any lookup. The next section describes
decorrelation in
RFC 1191. This is an important difference, because more than one
communication association detail and presents an algorithm that may map be
used to the same source and destination
IP addresses, and implement decorrelation.

B.1 Decorrelation Algorithm

The basic decorrelation algorithm takes each communication association may have entry in a different
amount correlated
SPD and divides it up into a set of IPsec header overhead (e.g., due to use entries using a tree structure.
Those of different
transforms or different algorithms). The examples below illustrate
this.

In cases (a) and (b)... Suppose you have the following situation.
H1 is sending to H2 and the packet to be sent from R1 to R2 exceeds resulting entries that are decorrelated with the PMTU
decorrelated set of the network hop between them.

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

If R1 is configured entries are then added to that decorrelated set.

The basic algorithm does not fragment subscriber traffic, then R1 sends guarantee an ICMP PMTU message with the appropriate PMTU to H1. H1's
processing would vary with the nature optimal set of decorrelated
entries. That is, the implementation. In case
(a) (native IP), the security services are bound to sockets or the
equivalent. Here the IP/IPsec implementation in H1 can store/update
the PMTU for the associated socket. In case (b), the IP layer in H1
can store/update the PMTU but only at the granularity of Source and
Destination addresses and possibly TOS/Class, as noted above. So entries may be broken up into smaller sets
than is necessary, though they will still provide all the
result may be sub- optimal, since necessary
policy information. Some extensions to the PMTU for a given
SRC/DST/TOS/Class will be basic algorithm are
described later to improve this and improve the subtraction performance of the largest amount
algorithm.

C A set of
IPsec header used for any communication association between ordered, correlated entries (a correlated SPD)
Ci The ith entry in C.
U The set of decorrelated entries being built from C
Ui The ith entry in U.

A policy (SPD entry) P may be expressed as a given sequence 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

For each policy Cj (j > 1) in C

2) If Cj is decorrelated with every entry in U, then add it to U.

Kent [Page 62] 43]

Internet Draft Security Architecture for IP October 2003

source and destination.

In case (c), there January 2004

3) If Cj is correlated with one or more entries in U, create a tree
rooted at the policy Cj that partitions Cj into a set of decorrelated
entries. The algorithm starts with a root node where no selectors
have yet been chosen.

A) Choose a selector in Cj, Scjn, that has not yet been chosen when
traversing the tree from the root to be a security gateway this node. If there are no
selectors not yet used, continue to the next unfinished branch
until all branches have any IPsec
processing. So suppose you have been completed. When the following situation. H1 tree is
sending
completed, go to H2 and step D.

T is the packet to be sent from SG1 to R exceeds set of entries in U that are correlated with the entry
at this node.

The entry at this node is the entry formed by the
PMTU selector
values of each of the network hop branches between them.

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

As described above the root and this node.
Any selector values that are not yet represented by branches
assume the corresponding selector value in Cj, since the values
in Cj represent the maximum value for case (b), each selector.

B) Add a branch to the tree for each value of the IP layer selector Scjn that
appears in H1 can store/update any of the PMTU but only at entries in T. (If the granularity value is a superset
of Source and Destination
addresses, and possibly TOS/Class. So the result may be sub-optimal, value of Scjn in Cj, then use the value in Cj, since that
value represents the PMTU for universal set.) Also add a given SRC/DST/TOS/Class will be branch for the subtraction
complement of the largest amount of IPsec header used for any communication
association between a given source and destination.

B.3.4 Per Socket Maintenance union of PMTU Data

Implementation all the values of the calculation selector Scjn
in T. When taking the complement, remember that the universal
set is the value of PMTU (Section B.3.2) and support Scjn in Cj. A branch need not be created
for PMTUs at the granularity of individual "communication
associations" (Section B.3.3) null set.

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

D) The entry to each leaf now represents an entry that is a local matter. However, a socket-
based implementation subset
of IPsec in a host SHOULD maintain Cj. The entries at the
information on leaves completely partition Cj in
such a per socket basis. Bump way that each entry is either completely overridden by
an entry in U, or is decorrelated with the stack systems MUST
pass an ICMP PMTU to entries in U.

Add all the host IP implementation, after adjusting it
for any IPsec header overhead added by these systems. The
determination of decorrelated entries at the overhead SHOULD be determined by analysis leaves of the
SPI tree to U.

4) Get next Cj and any other selector information present go to 2.

5) When all entries in a returned ICMP
PMTU message.

B.3.5 Delivery C have been processed, then U will contain an
decorrelated version of PMTU Data C.

There are several optimizations that can be made to the Transport Layer

The host mechanism for getting the updated PMTU this algorithm.
A few of them are presented here.

It is possible to optimize, or at least improve, the transport
layer is unchanged, as specified in RFC 1191 (Path MTU Discovery).

B.3.6 Aging amount of PMTU Data

This topic is covered in Section 6.1.2.4.
branching that occurs by carefully choosing the order of the

Kent [Page 63] 44]

Internet Draft Security Architecture for IP October 2003

Appendix C -- Sequence Space Window Code Example [Will change to reflect
ESN mod to AH and ESP]

This appendix contains a routine that implements a bitmask check January 2004

selectors used for the next branch. For example, if a 32 packet window. It was provided by James Hughes
(jim_hughes@stortek.com) and Harry Varnis (hgv@anubis.network.com)
and is intended as an implementation example. Note selector Scjn
can be chosen so that this code
both checks all the values for that selector in T are equal
to or a replay and updates the window. Thus superset of the algorithm,
as shown, should value of Scjn in Cj, then only a single
branch needs to be called AFTER created (since the packet has been
authenticated. Implementers might wish to consider splitting complement will be null).

Branches of the
code to tree do not have to proceed with the check for replays before computing the ICV. If entire
decorrelation algorithm. For example, if a node represents an entry
that is decorrelated with all the
packet entries in U, then there is not no
reason to continue decorrelating that branch. Also, if a replay, the code would branch is
completely overridden by an entry in U, then compute there is no reason to
continue decorrelating the ICV, (discard
any bad packets), and branch.

An additional optimization is to check to see if the packet a branch is OK, update
overridden by one of the window.

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

enum {
ReplayWindowSize = 32
};

u_long bitmap = 0; /* session state - must be 32 bits */
u_long lastSeq = 0; /* session state */

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

int ChkReplayWindow(u_long seq) {
u_long diff;

if (seq == 0) return 0; /* first == 0 or wrapped */ CORRELATED entries in set C that has already
been decorrelated. That is, if (seq > lastSeq) { /* new larger sequence number */
diff = seq - lastSeq; the branch is part of decorrelating
Cj, then check to see if (diff it was overridden by an entry Cm, m < ReplayWindowSize) { /* In window */
bitmap <<= diff;
bitmap |= 1; /* set bit for this packet */
} else bitmap = 1; /* j.
This packet has is a "way larger" */
lastSeq = seq;
return 1; /* larger is good */
}
diff = lastSeq - seq;
if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */ valid check, since all the entries Cm are already expressed
in U.

Along with checking if (bitmap & ((u_long)1 << diff)) return 0; /* an entry is already seen */
bitmap |= ((u_long)1 << diff); /* mark as seen */
return 1; /* out of order but good */
}

Kent [Page 64]

Internet Draft Security Architecture for IP October 2003

char string_buffer[512];
#define STRING_BUFFER_SIZE sizeof(string_buffer)

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

printf("Input initial state (bits decorrelated in hex, last msgnum):\n"); step 2,
check if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0);
sscanf(string_buffer, "%lx %lu", &bits, &last); Cj is overridden by any entry in U. If it is, skip it since
it is not relevant. An entry x is overridden by another entry y if (last != 0)
bits |= 1;
bitmap = bits;
lastSeq = last;
printf("bits:%08lx last:%lu\n", bitmap, lastSeq);
printf("Input value
every selector in x is equal to test (current):\n");

while (1) {
if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break;
sscanf(string_buffer, "%lu", &current);
result = ChkReplayWindow(current);
printf("%-3s", result ? "OK" : "BAD");
printf(" bits:%08lx last:%lu\n", bitmap, lastSeq);
}
return 0;
} or a subset of the corresponding
selector in entry y.

Kent [Page 65] 45]

Internet Draft Security Architecture for IP October 2003 January 2004

Appendix D C -- 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 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 Network (or subnet) [RFC792]
2 Redirect Datagram for the Type of Service & Network[RFC792]
9 Router Advertisement [RFC1256]
18 Address Mask Reply [RFC950]

Kent [Page 66] 46]

Internet Draft Security Architecture for IP October 2003 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]

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 [Page 67] 47]

Internet Draft Security Architecture for IP October 2003 January 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 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 [Page 68] 48]

Internet Draft Security Architecture for IP October 2003 January 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, draft-ietf-ssm-arch-01.txt, November
3, 2002.

[Kau04]

[Kau03] Kaufman, C., "The Internet Key Exchange (IKEv2)", RFC ???,
??? 2004 (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 [Page 49]

Internet Draft Security Architecture for IP January 2004

[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 R. Atkinson, R., "On Internet Authentication",
RFC 1704, October 1994.

Kent [Page 69]

Internet Draft Security Architecture for IP October 2003 1994

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

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

[IBK93] John Ioannidis, Matt J., Blaze, & Phil 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.

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

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

[Sch94] Bruce 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.

[TDG97] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.

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

Kent [Page 70]

Internet Draft Security Architecture for IP October 2003

Author Information

Stephen Kent
BBN Corporation
70 Fawcett Technologies
10 Moulton Street
Cambridge, MA 02140 02138
USA

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

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

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

Kent [Page 51]

Internet Draft Security Architecture for IP January 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

Kent [Page 71]

Internet Draft Security Architecture for IP October 2003
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 [Page 52]

Internet Draft Security Architecture for IP January 2004

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Expires April July 2004

Kent [Page 72] 53]
----