[RFCs/IDs] [Plain Text] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: (RFC 2401) 00 01 02 03 04 05 06 RFC 4301
Network Working Group S. Kent
Internet Draft K. Seo
draft-ietf-ipsec-rfc2401bis-06.txt BBN Technologies
Obsoletes: RFC 2401 March 2005
Expires September 2005
Security Architecture for the Internet Protocol
Dedicated to the memory of Charlie Lynn, a long time senior
colleague at BBN, who made very significant contributions to
the IPsec documents.
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 six 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
"work in progress". The list of current Internet-Drafts can be
accessed at http://www.ietf.org/1id-abstracts.html. The list of
Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document describes an updated version of the "Security
Architecture for IP", which is designed to provide security services
for traffic at the IP layer. This document obsoletes RFC 2401
(November 1998).
Comments should be sent to Stephen Kent (kent@bbn.com). [RFC Editor:
Please remove this line prior to publication as an RFC.]
Kent & Seo [Page 1]
Internet Draft Security Architecture for IP March 2005
Table of Contents
1. Introduction........................................................4
1.1 Summary of Contents of Document................................4
1.2 Audience.......................................................4
1.3 Related Documents..............................................5
2. Design Objectives...................................................5
2.1 Goals/Objectives/Requirements/Problem Description..............5
2.2 Caveats and Assumptions........................................6
3. System Overview ....................................................7
3.1 What IPsec Does................................................7
3.2 How IPsec Works................................................9
3.3 Where IPsec Can Be Implemented................................10
4. Security Associations..............................................11
4.1 Definition and Scope..........................................11
4.2 SA Functionality..............................................16
4.3 Combining SAs.................................................17
4.4 Major IPsec Databases.........................................17
4.4.1 The Security Policy Database (SPD).......................19
4.4.1.1 Selectors...........................................25
4.4.1.2 Structure of an SPD entry...........................29
4.4.1.3 More re: Fields Associated with Next Layer
Protocols...........................................31
4.4.2 Security Association Database (SAD)......................33
4.4.2.1 Data Items in the SAD...............................34
4.4.2.2 Relationship between SPD, PFP flag, packet, and SAD.36
4.4.3 Peer Authorization Database (PAD)........................41
4.4.3.1 PAD Entry IDs and Matching Rules....................42
4.4.3.2 IKE Peer Authentication Data........................43
4.4.3.3 Child SA Authorization Data.........................44
4.4.3.4 How the PAD Is Used.................................44
4.5 SA and Key Management.........................................45
4.5.1 Manual Techniques........................................46
4.5.2 Automated SA and Key Management..........................46
4.5.3 Locating a Security Gateway..............................47
4.6 SAs and Multicast.............................................48
5. IP Traffic Processing..............................................48
5.1 Outbound IP Traffic Processing (protected-to-unprotected).....49
5.1.1 Handling an Outbound Packet That Must Be Discarded.......52
5.1.2 Header Construction for Tunnel Mode......................53
5.1.2.1 IPv4 -- Header Construction for Tunnel Mode.........55
5.1.2.2 IPv6 -- Header Construction for Tunnel Mode.........56
5.2 Processing Inbound IP Traffic (unprotected-to-protected)......57
6. ICMP Processing ...................................................61
6.1 Processing ICMP Error Messages Directed to an IPsec
Implementation.....................................61
6.1.1 ICMP Error Messages Received on the Unprotected
Side of the Boundary...............................61
6.1.2 ICMP Error Messages Received on the Protected
Side of the Boundary...............................62
Kent & Seo [Page 2]
Internet Draft Security Architecture for IP March 2005
6.2 Processing Protected, Transit ICMP Error Messages.............62
7. Handling Fragments (on the protected side of the IPsec boundary)...64
7.1 Tunnel Mode SAs that Carry Initial and Non-Initial Fragments..65
7.2 Separate Tunnel Mode SAs for Non-Initial Fragments............65
7.3 Stateful Fragment Checking....................................66
7.4 BYPASS/DISCARD traffic........................................66
8. Path MTU/DF Processing.............................................67
8.1 DF Bit........................................................67
8.2 Path MTU (PMTU) Discovery.....................................67
8.2.1 Propagation of PMTU......................................68
8.2.2 PMTU Aging...............................................68
9. Auditing...........................................................69
10. Conformance Requirements..........................................69
11. Security Considerations...........................................69
12. IANA Considerations...............................................70
13. Differences from RFC 2401.........................................70
Acknowledgements......................................................73
Appendix A -- Glossary................................................74
Appendix B -- Decorrelation...........................................77
Appendix C -- ASN.1 for an SPD Entry..................................80
Appendix D -- Fragment Handling Rationale.............................86
D.1 Transport Mode and Fragments..................................86
D.2 Tunnel Mode and Fragments.....................................87
D.3 The Problem of Non-Initial Fragments..........................88
D.4 BYPASS/DISCARD traffic........................................91
D.5 Just say no to ports?.........................................91
D.6 Other Suggested Solutions.....................................92
D.7 Consistency...................................................93
D.8 Conclusions...................................................93
Appendix E -- Example of Supporting Nested SAs via SPD and Forwarding
Table Entries.....................................94
References............................................................96
Author Information....................................................99
Notices..............................................................100
Kent & Seo [Page 3]
Internet Draft Security Architecture for IP March 2005
1. Introduction
1.1 Summary of Contents of Document
This document specifies the base architecture for IPsec compliant
systems. It describes how to provide a set of security services for
traffic at the IP layer, in both the IPv4 [Pos81a] and IPv6 [DH98]
environments. This document describes the requirements for systems
that implement IPsec, the fundamental elements of such systems, and
how the elements fit together and fit into the IP environment. It
also describes the security services offered by the IPsec protocols,
and how these services can be employed in the IP environment. This
document does not address all aspects of the IPsec architecture.
Other documents address additional architectural details in
specialized environments, e.g., use of IPsec in Network Address
Translation (NAT) environments and more comprehensive support for IP
multicast. The fundamental components of the IPsec security
architecture are discussed in terms of their underlying, required
functionality. Additional RFCs (see Section 1.3 for pointers to
other documents) define the protocols in (a), (c), and (d).
a. Security Protocols -- Authentication Header (AH) and
Encapsulating Security Payload (ESP)
b. Security Associations -- what they are and how they work,
how they are managed, associated processing
c. Key Management -- manual and automated (The Internet Key
Exchange (IKE))
d. Cryptographic algorithms for authentication and encryption
This document is not a Security Architecture for the Internet; it
addresses security only at the IP layer, provided through the use of
a combination of cryptographic and protocol security mechanisms.
The spelling "IPsec" is preferred and used throughout this and all
related IPsec standards. All other capitalizations of IPsec (e.g.,
IPSEC, IPSec, ipsec) are deprecated. However, any capitalization of
the sequence of letters "IPsec" should be understood to refer to the
IPsec protocols.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in RFC 2119 [Bra97].
1.2 Audience
The target audience for this document is primarily individuals who
implement this IP security technology or who architect systems that
will use this technology. Technically adept users of this technology
(end users or system administrators) also are part of the target
Kent & Seo [Page 4]
Internet Draft Security Architecture for IP March 2005
audience. A glossary is provided in Appendix A to help fill in gaps
in background/vocabulary. This document assumes that the reader is
familiar with the Internet Protocol (IP), related networking
technology, and general information system security terms and
concepts.
1.3 Related Documents
As mentioned above, other documents provide detailed definitions of
some of the components of IPsec and of their inter-relationship.
They include RFCs on the following topics:
a. security protocols -- RFCs describing the Authentication
Header (AH) [Ken05b] and Encapsulating Security Payload
(ESP) [Ken05a] protocols.
b. cryptographic algorithms for integrity and encryption - one
RFC that defines the mandatory, default algorithms for use
with AH and ESP [Eas05], a similar RFC that defines the
mandatory algorithms for use with IKE v2 [Sch05] plus a
separate RFC for each cryptographic algorithm.
c. automatic key management -- RFCs on "The Internet Key
Exchange (IKE v2) Protocol" [Kau05] and "Cryptographic
Algorithms for use in the Internet Key Exchange Version 2"
[Sch05].
2. Design Objectives
2.1 Goals/Objectives/Requirements/Problem Description
IPsec is designed to provide interoperable, high quality,
cryptographically-based security for IPv4 and IPv6. The set of
security services offered includes access control, connectionless
integrity, data origin authentication, detection and rejection of
replays (a form of partial sequence integrity), confidentiality (via
encryption), and limited traffic flow confidentiality. These
services are provided at the IP layer, offering protection in a
standard fashion for all protocols that may be carried over IP
(including IP itself).
IPsec includes a specification for minimal firewall functionality,
since that is an essential aspect of access control at the IP layer.
Implementations are free to provide more sophisticated firewall
mechanisms, and to implement the IPsec-mandated functionality using
those more sophisticated mechanisms. (Note that interoperability may
suffer if additional firewall constraints on traffic flows are
imposed by an IPsec implementation but cannot be negotiated based on
the traffic selector features defined in this document and negotiated
via IKE v2.) The IPsec firewall function makes use of the
Kent & Seo [Page 5]
Internet Draft Security Architecture for IP March 2005
cryptographically-enforced authentication and integrity provided for
all IPsec traffic to offer better access control than could be
obtained through use of a firewall (one not privy to IPsec internal
parameters) plus separate cryptographic protection.
Most of the security services are provided through use of two traffic
security protocols, the Authentication Header (AH) and the
Encapsulating Security Payload (ESP), and through the use of
cryptographic key management procedures and protocols. The set of
IPsec protocols employed in a context, and the ways in which they are
employed, will be determined by the users/administrators in that
context. It is the goal of the IPsec architecture to ensure that
compliant implementations include the services and management
interfaces needed to meet the security requirements of a broad user
population.
When IPsec is correctly implemented and deployed, it ought not
adversely affect users, hosts, and other Internet components that do
not employ IPsec for traffic protection. IPsec security protocols
(AH & ESP, and to a lesser extent, IKE) are designed to be
cryptographic algorithm-independent. This modularity permits
selection of different sets of cryptographic algorithms as
appropriate, without affecting the other parts of the implementation.
For example, different user communities may select different sets of
cryptographic algorithms (creating cryptographically-enforced
cliques) if required.
To facilitate interoperability in the global Internet, a set of
default cryptographic algorithms for use with AH and ESP is specified
in [Eas05] and a set of mandatory-to-implement algorithms for IKE v2
is specified in [Sch05]. [Eas05] and [Sch05] will be periodically
updated to keep pace with computational and cryptologic advances. By
specifying these algorithms in documents that are separate from the
AH, ESP, and IKE v2 specifications, these algorithms can be updated
or replaced without affecting the standardization progress of the
rest of the IPsec document suite. 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
Kent & Seo [Page 6]
Internet Draft Security Architecture for IP March 2005
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
IPsec implementation executes. For example, defects in OS security,
poor quality of random number sources, sloppy system management
protocols and practices, etc. can all degrade the security provided
by IPsec. As above, none of these environmental attributes are
within the scope of this or other IPsec standards.
3. System Overview
This section provides a high level description of how IPsec works,
the components of the system, and how they fit together to provide
the security services noted above. The goal of this description is
to enable the reader to "picture" the overall process/system, see how
it fits into the IP environment, and to provide context for later
sections of this document, which describe each of the components in
more detail.
An IPsec implementation operates in a host, as a security gateway, or
as an independent device, affording protection to IP traffic. (A
security gateway is an intermediate system implementing IPsec, e.g.,
a firewall or router that has been IPsec-enabled.) More detail on
these classes of implementations is provided later, in Section 3.3.
The protection offered by IPsec is based on requirements defined by a
Security Policy Database (SPD) established and maintained by a user
or system administrator, or by an application operating within
constraints established by either of the above. In general, packets
are selected for one of three processing actions based on IP and next
layer header information (Selectors, Section 4.4.1.1) matched against
entries in the Security Policy Database (SPD). Each packet is either
PROTECTed using IPsec security services, DISCARDed, or allowed to
BYPASS IPsec protection, based on the applicable SPD policies
identified by the Selectors.
3.1 What IPsec Does
IPsec creates a boundary between unprotected and protected
interfaces, for a host or a network (see Figure 1 below). Traffic
traversing the boundary is subject to the access controls specified
by the user or administrator responsible for the IPsec configuration.
These controls indicate whether packets cross the boundary unimpeded,
are afforded security services via AH or ESP, or are discarded. IPsec
security services are offered at the IP layer through selection of
appropriate security protocols, cryptographic algorithms, and
Kent & Seo [Page 7]
Internet Draft Security Architecture for IP March 2005
cryptographic keys. IPsec can be used to protect one or more "paths"
(a) between a pair of hosts, (b) between a pair of security gateways,
or (c) between a security gateway and a host. A compliant host
implementation MUST support (a) and (c) and a compliant security
gateway must support all three of these forms of connectivity, since
under certain circumstances a security gateway acts as a host.
Unprotected
^ ^
| |
+-------------|-------|-------+
| +-------+ | | |
| |Discard|<--| V |
| +-------+ |B +--------+ |
................|y..| AH/ESP |..... IPsec Boundary
| +---+ |p +--------+ |
| |IKE|<----|a ^ |
| +---+ |s | |
| +-------+ |s | |
| |Discard|<--| | |
| +-------+ | | |
+-------------|-------|-------+
| |
V V
Protected
Figure 1. Top Level IPsec Processing Model
In this diagram, "unprotected" refers to an interface that might also
be described as "black" or "ciphertext." Here, "protected" refers to
an interface that might also be described as "red" or "plaintext."
The protected interface noted above may be internal, e.g., in a host
implementation of IPsec, 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 or emitted by the implementation on the
unprotected side of the boundary and directed towards the protected
interface. The term "outbound" refers to traffic entering the
implementation via the protected interface, or emitted by the
implementation on the protected side of the boundary and directed
toward the unprotected interface. An IPsec implementation may
support more than one interface on either or both sides of the
boundary.
Note the facilities for discarding traffic on either side of the
IPsec boundary, the BYPASS 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.
Kent & Seo [Page 8]
Internet Draft Security Architecture for IP March 2005
IPsec optionally supports negotiation of IP compression [SMPT01],
motivated in part by the observation that when encryption is employed
within IPsec, it prevents effective compression by lower protocol
layers.
3.2 How IPsec Works
IPsec uses two protocols to provide traffic security services --
Authentication Header (AH) and Encapsulating Security Payload (ESP).
Both protocols are described in detail in their respective RFCs
[Ken05b, Ken05a]. IPsec implementations MUST support ESP and MAY
support AH. (Support for AH has been downgraded to MAY because
experience has shown that there are very few contexts in which ESP
cannot provide the requisite security services. Note that ESP can be
used to provide only integrity, without confidentiality, making it
comparable to AH in most contexts.)
o The IP Authentication Header (AH) [Ken05b] offers integrity and
data origin authentication, with optional (at the discretion of
the receiver) anti-replay features.
o The Encapsulating Security Payload (ESP) protocol [Ken05a] offers
the same set of services, and also offers confidentiality. Use of
ESP to provide confidentiality without integrity is NOT
RECOMMENDED. When ESP is used with confidentiality enabled, there
are provisions for limited traffic flow confidentiality, i.e.,
provisions for concealing packet length, and for facilitating
efficient generation and discard of dummy packets. This capability
is likely to be effective primarily in VPN and overlay network
contexts.
o Both AH and ESP offer access control, enforced through the
distribution of cryptographic keys and the management of traffic
flows as dictated by the Security Policy Database (SPD, Section
4.4.1).
These protocols may be applied individually or in combination with
each other to provide IPv4 and IPv6 security services. However, most
security requirements can be met through the use of ESP by itself.
Each protocol supports two modes of use: transport mode and tunnel
mode. In transport mode, AH and ESP provide protection primarily for
next layer protocols; in tunnel mode, AH and ESP are applied to
tunneled IP packets. The differences between the two modes are
discussed in Section 4.1.
IPsec allows the user (or system administrator) to control the
granularity at which a security service is offered. For example, one
can create a single encrypted tunnel to carry all the traffic between
two security gateways or a separate encrypted tunnel can be created
Kent & Seo [Page 9]
Internet Draft Security Architecture for IP March 2005
for each TCP connection between each pair of hosts communicating
across these gateways. IPsec, through the SPD management paradigm,
incorporates facilities for specifying:
o which security protocol (AH or ESP) to employ, the mode (transport
or tunnel), security service options, what cryptographic
algorithms to use, and in what combinations to use the specified
protocols and services,
o the granularity at which protection should be applied.
Because most of the security services provided by IPsec require the
use of cryptographic keys, IPsec relies on a separate set of
mechanisms for putting these keys in place. This document requires
support for both manual and automated distribution of keys. It
specifies a specific public-key based approach (IKE v2 [Kau05]) for
automated key management, but other automated key distribution
techniques MAY be used.
Note: This document mandates support for several features for which
support is available in IKE v2 but not in IKE v1, e.g., negotiation
of an SA representing ranges of local and remote ports or negotiation
of multiple SAs with the same selectors. Therefore this document
assumes use of IKE v2 or a key and security association management
system with comparable features.
3.3 Where IPsec Can Be Implemented
There are many ways in which IPsec may be implemented in a host, or
in conjunction with a router or firewall to create a security
gateway, or as an independent security device.
a. IPsec may be integrated into the native IP stack. This requires
access to the IP source code and is applicable to both hosts and
security gateways, although native host implementations benefit
the most from this strategy, as explained later (Section 4.4.1,
paragraph 6; Section 4.4.1.1, last paragraph).
b. In a "bump-in-the-stack" (BITS) implementation, IPsec is
implemented "underneath" an existing implementation of an IP
protocol stack, between the native IP and the local network
drivers. Source code access for the IP stack is not required in
this context, making this implementation approach appropriate for
use with legacy systems. This approach, when it is adopted, is
usually employed in hosts.
c. The use of a dedicated, inline security protocol processor is a
common design feature of systems used by the military, and of some
commercial systems as well. It is sometimes referred to as a
Kent & Seo [Page 10]
Internet Draft Security Architecture for IP March 2005
"bump-in-the-wire" (BITW) implementation. Such implementations
may be designed to serve either a host or a gateway. Usually the
BITW device is itself IP addressable. When supporting a single
host, it may be quite analogous to a BITS implementation, but in
supporting a router or firewall, it must operate like a security
gateway.
This document often talks in terms of use of IPsec by a host or a
security gateway, 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.
A host implementation of IPsec may appear in devices that might not
be viewed as "hosts." For example, a router might employ IPsec to
protect routing protocols (e.g., BGP) and management functions (e.g.,
Telnet), without affecting subscriber traffic traversing the router.
A security gateway might employ separate IPsec implementations to
protect its management traffic and subscriber traffic. The
architecture described in this document is very flexible. For
example, a computer with a full-featured, compliant, native OS IPsec
implementation should be capable of being configured to protect
resident (host) applications and to provide security gateway
protection for traffic traversing the computer. Such configuration
would make use of the forwarding tables and the SPD selection
function described in Sections 5.1 and 5.2.
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 AH and ESP. The concept of a "Security
Association" (SA) is fundamental to IPsec. Both AH and ESP make use
of SAs and a major function of IKE is the establishment and
maintenance of SAs. All implementations of AH or ESP MUST support
the concept of an SA as described below. The remainder of this
section describes various aspects of SA management, defining required
characteristics for SA policy management and SA management
techniques.
4.1 Definition and Scope
An SA is a simplex "connection" that affords security services to the
traffic carried by it. Security services are afforded to an SA by
the use of AH, or ESP, but not both. If both AH and ESP protection
are applied to a traffic stream, then two SAs must be created and
coordinated to effect protection through iterated application of the
security protocols. To secure typical, bi-directional communication
between two IPsec-enabled systems, a pair of SAs (one in each
Kent & Seo [Page 11]
Internet Draft Security Architecture for IP March 2005
direction) is required. IKE explicitly creates SA pairs in
recognition of this common usage requirement.
For an SA used to carry unicast traffic, the SPI (Security Parameters
Index - see Appendix A and AH [Ken05b] and ESP [Ken05a]
specifications) by itself suffices to specify an SA. However, as a
local matter, an implementation may choose to use the SPI in
conjunction with the IPsec protocol type (AH or ESP) for SA
identification. If an IPsec implementation supports multicast, then
it MUST support multicast SAs using the algorithm below for mapping
inbound IPsec datagrams to SAs. Implementations that support only
unicast traffic need not implement this demultiplexing algorithm.
In many secure multicast architectures, e.g., [RFC3740], a central
Group Controller/Key Server unilaterally assigns the Group Security
Association's (GSA's) SPI. This SPI assignment is not negotiated or
coordinated with the key management (e.g., IKE) subsystems that
reside in the individual end systems that constitute the group.
Consequently, it is possible that a GSA and a unicast SA can
simultaneously use the same SPI. A multicast-capable IPsec
implementation MUST correctly de-multiplex inbound traffic even in
the context of SPI collisions.
Each entry in the SA Database (SAD) (Section 4.4.2) must indicate
whether the SA lookup makes use of the destination IP address, or the
destination and source IP addresses, in addition to the SPI. For
multicast SAs, the protocol field is not employed for SA lookups. For
each inbound, IPsec-protected packet, an implementation must conduct
its search of the SAD such that it finds the entry that matches the
"longest" SA identifier. In this context, if two or more SAD entries
match based on the SPI value, then the entry that also matches based
on destination address, or destination and source address (as
indicated in the SAD entry) is the "longest" match. This implies a
logical ordering of the SAD search as follows:
1. Search the SAD for a match on the combination of SPI,
destination address, and source address. If an SAD entry
matches, then process the inbound packet with that
matching SAD entry. Otherwise, proceed to step 2.
2. Search the SAD for a match on both SPI and destination address.
If the SAD entry matches then process the inbound packet
with that matching SAD entry. Otherwise, proceed to step 3.
3. Search the SAD for a match on only SPI if the receiver has
chosen to maintain a single SPI space for AH and ESP, and on
both SPI and protocol otherwise. If an SAD entry matches then
process the inbound packet with that matching SAD entry.
Kent & Seo [Page 12]
Internet Draft Security Architecture for IP March 2005
Otherwise, discard the packet and log an auditable event.
In practice, an implementation may choose any method (or none at all)
to accelerate this search, although its externally visible behavior
MUST be functionally equivalent to having searched the SAD in the
above order. For example, a software-based implementation could index
into a hash table by the SPI. The SAD entries in each hash table
bucket's linked list could be kept sorted to have those SAD entries
with the longest SA identifiers first in that linked list. Those SAD
entries having the shortest SA identifiers could be sorted so that
they are the last entries in the linked list. A hardware-based
implementation may be able to effect the longest match search
intrinsically, using commonly available Ternary Content-Addressable
Memory (TCAM) features.
The indication of whether source and destination address matching is
required to map inbound IPsec traffic to SAs MUST be set either as a
side effect of manual SA configuration or via negotiation using an SA
management protocol, e.g., IKE or GDOI [RFC3547]. Typically,
Source-Specific Multicast (SSM) [HC03] groups use a 3-tuple SA
identifier composed of an SPI, a destination multicast address, and
source address. An Any-Source Multicast group SA requires only an SPI
and a destination multicast address as an identifier.
If different classes of traffic (distinguished by Differentiated
Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the
same SA, and if the receiver is employing the optional anti-replay
feature available in both AH and ESP, this could result in
inappropriate discarding of lower priority packets due to the
windowing mechanism used by this feature. Therefore a sender SHOULD
put traffic of different classes, but with the same selector values,
on different SAs to support QoS appropriately. 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
by IKE. The receiver MUST process the packets from the different SAs
without prejudice. These requirements apply to both transport and
tunnel mode SAs. In the case of tunnel mode SAs, the DSCP values in
question appear in the inner IP header. In transport mode, the DSCP
value might change en route, but this should not cause problems with
respect to IPsec processing since the value is not employed for SA
selection and MUST NOT be checked as part of SA/packet validation.
However, if significant re-ordering of packets occurs in an SA, e.g.,
as a result of changes to DSCP values en route, this may trigger
packet discarding by a receiver due to application of the anti-replay
mechanism.
Kent & Seo [Page 13]
Internet Draft Security Architecture for IP March 2005
DISCUSSION: While the DSCP [NiBlBaBL98, Gro02] and Explicit
Congestion Notification (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 "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 an SA typically employed between a pair of
hosts to provide end-to-end security services. When security is
desired between two intermediate systems along a path (vs. end-to-end
use of IPsec), transport mode MAY be used between security gateways
or between a security gateway and a host. In the case where
transport mode is used between security gateways or between a
security gateway and a host, transport mode may be used to support
in-IP tunneling (e.g., IP-in-IP [Per96] or GRE tunneling
[FaLiHaMeTr00] or Dynamic routing [ToEgWa04]) over transport mode
SAs. To clarify, the use of transport mode by an intermediate system
(e.g., a security gateway) is permitted only when applied to packets
whose source address (for outbound packets) or destination address
(for inbound packets) is an address belonging to the intermediate
system itself. The access control functions that are an important
part of IPsec are significantly limited in this context, as they
cannot be applied to the end-to-end headers of the packets that
traverse a transport mode SA used in this fashion. Thus this way of
using transport mode should be evaluated carefully before being
employed in a specific context.
In IPv4, a transport mode security protocol header appears
immediately after the IP header and any options, and before any next
layer protocols (e.g., TCP or UDP). In IPv6, the security protocol
header appears after the base IP header and selected extension
headers, but may appear before or after destination options; it MUST
appear before next layer protocols (e.g., TCP, UDP, SCTP). In the
case of ESP, a transport mode SA provides security services only for
these next layer protocols, not for the IP header or any extension
headers preceding the ESP header. In the case of AH, the protection
is also extended to selected portions of the IP header preceding it,
selected portions of extension headers, and selected options
(contained in the IPv4 header, IPv6 Hop-by-Hop extension header, or
IPv6 Destination extension headers). For more details on the
coverage afforded by AH, see the AH specification [Ken05b].
A tunnel mode SA is essentially an SA applied to an IP tunnel, with
the access controls applied to the headers of the traffic inside the
tunnel. Two hosts MAY establish a tunnel mode SA between themselves.
Kent & Seo [Page 14]
Internet Draft Security Architecture for IP March 2005
Aside from the two exceptions below, 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. The two
exceptions are as follows.
o 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. In this case, the SA terminates at a host
(management) function within a security gateway and thus merits
different treatment.
o As noted above, security gateways MAY support a transport mode SA
to provide security for IP traffic between two intermediate
systems along a path, e.g., between a host and a security gateway
or between two security gateways.
Several concerns motivate the use of tunnel mode for an SA involving
a security gateway. For example, if there are multiple paths (e.g.,
via different security gateways) to the same destination behind a
security gateway, it is important that an IPsec packet be sent to the
security gateway with which the SA was negotiated. Similarly, a
packet that might be fragmented en-route must have all the fragments
delivered to the same IPsec instance for reassembly prior to
cryptographic processing. Also, when a fragment is processed by 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. (Use of an IP-in-IP tunnel in conjunction with
transport mode can also address these fragmentation issues. However,
this configuration limits the ability of IPsec to enforce access
control policies on traffic.)
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 IPv6, it would be feasible to carry a plaintext fragment
on a transport mode SA; however, for simplicity, this restriction
also applies to IPv6 packets. See Section 7 for more details on
handling plaintext fragments on the protected side of the IPsec
barrier.
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
Kent & Seo [Page 15]
Internet Draft Security Architecture for IP March 2005
(i.e., all of the inner IP header is protected, as well as next layer
protocols). If ESP is employed, the protection is afforded only to
the tunneled packet, not 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.
b) A security gateway MUST support tunnel mode 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 security between two
intermediate systems along a path.
4.2 SA 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 and ESP offer integrity and authentication
services, but the coverage differs for each protocol and 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 IP or extension
headers that may change in a fashion not predictable by the sender.
However, the same security may be achieved in some contexts by
applying ESP to a tunnel carrying a packet.
The granularity of access control provided is determined by the
choice of the selectors that define each SA. Moreover, the
authentication means employed by IPsec peers, e.g., during creation
of an IKE (vs. child) SA also effects the granularity of the access
control afforded.
If confidentiality is selected, then an ESP (tunnel mode) SA between
two security gateways can offer partial traffic flow confidentiality.
The use of 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 that are carrying traffic from
Kent & Seo [Page 16]
Internet Draft Security Architecture for IP March 2005
many subscribers.
Note: A compliant implementation MUST NOT allow instantiation of an
ESP SA that employs both NULL encryption and no integrity algorithm.
An attempt to negotiate such an SA is an auditable event by both
initiator and responder. The audit log entry for 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.
4.3 Combining SAs
This document does not require support for nested security
associations or for what RFC 2401 called "SA bundles." These features
still can be effected by appropriate configuration of both the SPD
and the local forwarding functions (for inbound and outbound
traffic), but this capability is outside of the IPsec module and thus
the scope of this specification. As a 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 management interface that
enables a user or administrator to express the nesting requirement,
and then create the appropriate SPD entries and forwarding table
entries to effect the requisite processing. (See Appendix E for an
example of how to configure nested SAs.)
4.4 Major IPsec Databases
Many of the details associated with processing IP traffic in an IPsec
implementation are largely a local matter, not subject to
standardization. However, some external aspects of the processing
must be standardized to ensure interoperability and to provide a
minimum management capability that is essential for productive use of
IPsec. This section describes a general model for processing IP
traffic relative to IPsec functionality, in support of these
interoperability and functionality goals. The model described below
is 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 compliant.
There are three nominal databases in this model: the Security Policy
Database (SPD), the Security Association Database (SAD), and the Peer
Authorization Database (PAD). The first specifies the policies that
determine the disposition of all IP traffic inbound or outbound from
a host or security gateway (Section 4.4.1). The second database
contains parameters that are associated with each established (keyed)
SA (Section 4.4.2). The third database, the Peer Authorization
Database (PAD) provides a link between an SA management protocol like
IKE and the SPD (Section 4.4.3).
Kent & Seo [Page 17]
Internet Draft Security Architecture for IP March 2005
Multiple Separate IPsec Contexts
If an IPsec implementation acts as a security gateway for multiple
subscribers, it MAY implement multiple separate IPsec contexts.
Each context MAY have and MAY 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 (SA) proposals with local contexts
is required. To this end, if supported by the key management
protocol in use, context identifiers MAY be conveyed from
initiator to responder in the signaling messages, with the result
that IPsec SAs are created with a binding to a particular context.
For example, a security gateway that provides VPN service to
multiple customers will be able to associate each customer's
traffic with the correct VPN.
Forwarding vs Security Decisions
The IPsec model described here embodies a clear separation between
forwarding (routing) and security decisions, to accommodate a wide
range of contexts where IPsec may be employed. Forwarding may be
trivial, in the case where there are only two interfaces, or it
may be complex, e.g., if the context in which IPsec is implemented
employs a sophisticated forwarding function. IPsec assumes only
that outbound and inbound traffic that has passed through IPsec
processing 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 cause a packet to traverse the IPsec boundary
more than once.
"Local" vs "Remote"
In this document, with respect to IP addresses and ports, the
terms "Local" and "Remote" are used for policy rules. "Local"
refers to the entity being protected by an IPsec implementation,
i.e., the "source" address/port of outbound packets or the
"destination" address/port of inbound packets. "Remote" refers to
a peer entity or peer entities. The terms "source" and
"destination" are used for packet header fields.
"Non-initial" vs "Initial" Fragments
Throughout this document, the phrase "non-initial" fragments is
used to mean fragments that do not contain all of the selector
values that may be needed for access control (e.g., they might not
contain Next Layer Protocol, source and destination ports, ICMP
message type/code, Mobility Header type). And the phrase "initial"
fragment is used to mean a fragment that contains all the selector
Kent & Seo [Page 18]
Internet Draft Security Architecture for IP March 2005
values needed for access control. However, it should be noted that
for IPv6, which fragment contains the Next Layer Protocol and
ports (or ICMP message type/code or Mobility Header type) will
depend on the kind and number of extension headers present. The
"initial" fragment might not be the first fragment, in this
context.
4.4.1 The Security Policy Database (SPD)
An SA is a management construct used to enforce security policy for
traffic crossing the IPsec boundary. Thus an essential element of SA
processing is an underlying Security Policy Database (SPD) that
specifies what services are to be offered to IP datagrams and in what
fashion. The form of the database and its interface are outside the
scope of this specification. However, this section specifies minimum
management functionality that must be provided, to allow a user or
system administrator to control whether and how IPsec is applied to
traffic transmitted or received by a host or transiting a security
gateway. The SPD, or relevant caches, must be consulted during the
processing of all traffic (inbound and outbound), including traffic
not protected by IPsec, that 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
multiple SPDs, if appropriate for the context in which the IPsec
implementation operates. There is no requirement to maintain SPDs on
a 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 invoked to select the
appropriate SPD for outbound traffic processing. The inputs to this
function are the outbound packet and any local metadata (e.g., the
interface via which the packet arrived) required to effect the SPD
selection function. The output of the function is an SPD identifier
(SPD-ID).
The SPD is an ordered database, consistent with the use of ACLs or
packet filters in firewalls, routers, etc. The ordering requirement
arises because entries often will overlap due to the presence of
(non-trivial) ranges as values for selectors. Thus a user or
administrator MUST be able to order the entries to express a desired
access control policy. There is no way to impose a general, canonical
order on SPD entries, because of the allowed use of wildcards for
selector values and because the different types of selectors are not
hierarchically related.
Processing Choices: DISCARD, BYPASS, PROTECT
An SPD must discriminate among traffic that is afforded IPsec
protection and traffic that is allowed to bypass IPsec. This
applies to the IPsec protection to be applied by a sender and to
Kent & Seo [Page 19]
Internet Draft Security Architecture for IP March 2005
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 PROTECT using IPsec. The
first choice refers to traffic that is not allowed to traverse the
IPsec boundary (in the specified direction). The second choice
refers to traffic that is allowed to cross the IPsec boundary
without IPsec protection. The third choice refers to traffic that
is afforded IPsec protection, and for such traffic the SPD must
specify the security protocols to be employed, their mode,
security service options, and the cryptographic algorithms to be
used.
SPD-S, SPD-I, SPD-O
An SPD is logically divided into three pieces. The SPD-S (secure
traffic) contains entries for all traffic subject to IPsec
protection. SPD-O (outbound) contains entries for all outbound
traffic that is to be bypassed or discarded. SPD-I (inbound) is
applied to inbound traffic that will be bypassed or discarded. All
three of these can be decorrelated (with the exception noted above
for native host implementations) to facilitate caching. If an
IPsec implementation supports only one SPD, then the SPD consists
of all three parts. If multiple SPDs are supported, some of them
may be partial, e.g., some SPDs might contain only SPD-I entries,
to control inbound bypassed traffic on a per-interface basis. The
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, 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. In an ordered, non-decorrelated SPD, the
entries for the SPD-S, SPD-I, and SPD-O are interleaved. So there
is one look up in the SPD.
SPD entries
Each SPD entry specifies packet disposition as BYPASS, DISCARD, or
PROTECT. The entry is keyed by a list of one or more selectors.
The SPD contains an ordered list of these entries. The required
selector types are defined in Section 4.4.1.1. These selectors are
used to define the granularity of the SAs that are created in
response to an outbound packet or in response to a proposal from a
peer. The detailed structure of an SPD entry is described in
Section 4.4.1.2. Every SPD SHOULD have a nominal, final entry that
matches anything that is otherwise unmatched, and discards it.
The SPD MUST permit a user or administrator to specify policy
Kent & Seo [Page 20]
Internet Draft Security Architecture for IP March 2005
entries as follows:
- SPD-I: For inbound traffic that is to be bypassed or discarded,
the entry consists of the values of the selectors that apply to
the traffic to be bypassed or discarded.
- SPD-O: For outbound traffic that is to be bypassed or
discarded, the entry consists of the values of the selectors
that apply to the traffic to be bypassed or discarded.
- SPD-S: For traffic that is to be protected using IPsec, the
entry consists of the values of the selectors that apply to the
traffic to be protected via AH or ESP, controls on how to
create SAs based on these selectors, and the parameters needed
to effect this protection (e.g., algorithms, modes, etc.). Note
that an SPD-S entry also contains information such as "populate
from packet" (PFP) flag (see paragraphs below on "How To Derive
the Values for an SAD entry") and bits indicating whether the
SA lookup makes use of the local and remote IP addresses in
addition to the SPI (see AH [Ken05b] or ESP [Ken05a]
specifications).
Representing directionality in an SPD entry
For traffic protected by IPsec, the Local and Remote address and
ports in an SPD entry are swapped to represent directionality,
consistent with IKE conventions. In general, the protocols that
IPsec deals with have the property of requiring symmetric SAs with
flipped Local/Remote IP addresses. However, for ICMP, there is
often no such bi-directional authorization requirement.
Nonetheless, for the sake of uniformity and simplicity, SPD
entries for ICMP are specified in the same way as for other
protocols. Note also that for ICMP, Mobility Header, and
non-initial fragments, there are no port fields in these packets.
ICMP has message type and code and Mobility Header has mobility
header type. Thus SPD entries have provisions for expressing
access controls appropriate for these protocols, in lieu of the
normal port field controls. For bypassed or discarded traffic,
separate inbound and outbound entries are supported, e.g., to
permit unidirectional flows if required.
OPAQUE and ANY
For each selector in an SPD entry, in addition to the literal
values that define a match, there are two special values: ANY and
OPAQUE. ANY is a wildcard that matches any value in the
corresponding field of the packet, or that matches packets where
that field is not present or is obscured. OPAQUE indicates that
the corresponding selector field is not available for examination
Kent & Seo [Page 21]
Internet Draft Security Architecture for IP March 2005
because it may not be present in a fragment, does not exist for
the given Next Layer Protocol, or because prior application of
IPsec may have encrypted the value. The ANY value encompasses the
OPAQUE value. Thus OPAQUE need be used only when it is necessary
to distinguish between the case of any allowed value for a field,
vs. the absence or unavailability (e.g., due to encryption) of the
field.
How To Derive the Values for an SAD entry
For each selector in an SPD entry, the entry specifies how to
derive the corresponding values for a new SA Database (SAD, see
Section 4.4.2) entry from those in the SPD and the packet. The
goal is to allow an SAD entry and an SPD cache entry to be created
based on specific selector values from the packet, or from the
matching SPD entry. For outbound traffic, there are SPD-S cache
entries and SPD-O cache entries. For inbound traffic not
protected by IPsec, there are SPD-I cache entries and there is the
SAD, which represents the cache for inbound IPsec-protected
traffic (See Section 4.4.2). If IPsec processing is specified for
an entry, a "populate from packet" (PFP) flag may be asserted for
one or more of the selectors in the SPD entry (Local IP address;
Remote IP address; Next Layer Protocol; and, depending on Next
Layer Protocol, Local port and Remote port, or ICMP type/code, or
Mobility Header type). If asserted for a given selector X, the
flag indicates that the SA to be created should take its value for
X from the value in the packet. Otherwise, the SA should take its
value(s) for X from the value(s) in the SPD entry. Note: In the
non-PFP case, the selector values negotiated by the SA management
protocol (e.g., IKE v2) may be a subset of those in the SPD entry,
depending on the SPD policy of the peer. Also, whether a single
flag is used for, e.g., source port, ICMP type/code, and MH type,
or a separate flag is used for each, is a local matter.
The following example illustrates the use of the PFP flag in the
context of a security gateway or a BITS/BITW implementation.
Consider an SPD entry where the allowed value for Remote address
is a range of IPv4 addresses: 192.0.2.1 to 192.0.2.10. Suppose an
outbound packet arrives with a destination address of 192.0.2.3,
and there is no extant SA to carry this packet. The value used for
the SA created to transmit this packet could be either of the two
values shown below, depending on what the SPD entry for this
selector says is the source of the selector value:
Kent & Seo [Page 22]
Internet Draft Security Architecture for IP March 2005
PFP flag value example of new
for the Remote SAD dest. address
addr. selector selector value
--------------- ------------
a. PFP TRUE 192.0.2.3 (one host)
b. PFP FALSE 192.0.2.1 to 192.0.2.10 (range of hosts)
Note that if the SPD entry above had a value of ANY for the Remote
address, then the SAD selector value would have to be ANY for case
(b), but would still be as illustrated for case (a). Thus the PFP
flag can be used to prohibit sharing of an SA, even among packets
that match the same SPD entry.
Management Interface
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.1.1, and MUST
support (total) ordering of these entries, as seen via this
interface. The SPD entries' selectors are analogous to the ACL or
packet filters commonly found in a stateless firewall or packet
filtering router and which are currently managed this way.
In host systems, applications MAY be allowed to create SPD
entries. (The means of 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 application can override (default) system policies. 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 document does specify a standard
set of SPD elements that all IPsec implementations MUST support.
Decorrelation
The processing model described in this document assumes the
ability to decorrelate overlapping SPD entries to permit caching,
which enables more efficient processing of outbound traffic in
security gateways and BITS/BITW implementations. Decorrelation
[CoSa04] is only a means of improving performance and simplifying
the processing description. This RFC does not require a compliant
implementation to make use of decorrelation. For example, native
Kent & Seo [Page 23]
Internet Draft Security Architecture for IP March 2005
host implementations typically make use of caching implicitly
because they bind SAs to socket interfaces, and thus there is no
requirement to be able to decorrelate SPD entries in these
implementations.
Note: Unless otherwise qualified, the use of "SPD" refers to the
body of policy information in both ordered or decorrelated
(unordered) state. Appendix B provides an algorithm that can be
used to decorrelate SPD entries, but any algorithm that produces
equivalent output may be used. Note that when an SPD entry is
decorrelated all the resulting entries MUST be linked together, so
that all members of the group derived from an individual, SPD
entry (prior to decorrelation) can all be placed into caches and
into the SAD at the same time. For example, suppose one starts
with an entry A (from an ordered SPD) that when decorrelated,
yields entries A1, A2 and A3. When a packet comes along that
matches, say A2, and triggers the creation of an SA, the SA
management protocol, e.g., IKE v2, negotiates A. And all 3
decorrelated entries, A1, A2, and A3 are placed in the appropriate
SPD-S cache and linked to the SA. The intent is that use of a
decorrelated SPD ought not to create more SAs than would have
resulted from use of a not-decorrelated SPD.
If a decorrelated SPD is employed, there are three options for
what an initiator sends to a peer via an SA management protocol
(e.g., IKE). By sending the complete set of linked, decorrelated
entries that were selected from the SPD, a peer is given the best
possible information to enable selection of the appropriate SPD
entry at its end, especially if the peer has also decorrelated its
SPD. However, if a large number of decorrelated entries are
linked, this may create large packets for SA negotiation, and
hence fragmentation problems for the SA management protocol.
Alternatively, the original entry from the (correlated) SPD may be
retained and passed to the SA management protocol. Passing the
correlated SPD entry keeps the use of a decorrelated SPD a local
matter, not visible to peers, and avoids possible fragmentation
concerns, although it provides less precise info to a responder
for matching against the responder's SPD.
An intermediate approach is to send a subset of the complete set
of linked, decorrelated SPD entries. This approach can avoid the
fragmentation problems cited above and yet provide better
information than the original, correlated entry. The major
shortcoming of this approach is that it may cause additional SAs
to be created later, since only a subset of the linked,
decorrelated entries are sent to a peer. Implementers are free to
employ any of the approaches cited above.
Kent & Seo [Page 24]
Internet Draft Security Architecture for IP March 2005
A responder uses the traffic selector proposals it receives via an
SA management protocol to select an appropriate entry in its SPD.
The intent of the matching is to select an SPD entry and create an
SA that most closely matches the intent of the initiator, so that
traffic traversing the resulting SA will be accepted at both ends.
If the responder employs a decorrelated SPD, it SHOULD use the
decorrelated SPD entries for matching, as this will generally
result in creation of SAs that are more likely to match the intent
of both peers. If the responder has a correlated SPD, then it
SHOULD match the proposals against the correlated entries. For
IKE v2, use of a decorrelated SPD offers the best opportunity for
a responder to generate a "narrowed" response.
In all cases, when a decorrelated SPD is available, the
decorrelated entries are used to populate the SPD-S cache. If the
SPD is not decorrelated, caching is not allowed and an ordered
search of SPD MUST be performed to verify that inbound traffic
arriving on an SA is consistent with the access control policy
expressed in the SPD.
Handling Changes to the SPD while the System is Running
If a change is made to the SPD while the system is running, a
check SHOULD be made of the effect of this change on extant SAs.
An implementation SHOULD check the impact of an SPD change on
extant SAs and SHOULD provide a user/administrator with a
mechanism for configuring what actions to take, e.g., delete an
affected SA, allow an affected SA to continue unchanged, etc.
4.4.1.1 Selectors
An SA may 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 hosts may be carried via a single SA, and
afforded a uniform set of security services. Alternatively, traffic
between a pair of hosts might be spread over multiple SAs, depending
on the applications being used (as defined by the Next Layer Protocol
and related fields, e.g., ports), with different security services
offered by different SAs. Similarly, all traffic between a pair of
security gateways could be carried on a single SA, or one SA could be
assigned for each communicating host pair. The following selector
parameters MUST be supported by all IPsec implementations to
facilitate control of SA granularity. Note that both Local and Remote
addresses should either be IPv4 or IPv6, but not a mix of address
types. Also, note that the Local/Remote port selectors (and ICMP
message type and code, and Mobility Header type) may be labeled as
OPAQUE to accommodate situations where these fields are inaccessible
due to packet fragmentation.
Kent & Seo [Page 25]
Internet Draft Security Architecture for IP March 2005
- Remote IP Address(es) (IPv4 or IPv6): this is a list of ranges
of IP addresses (unicast, broadcast (IPv4 only)). This structure
allows expression of a single IP address (via a trivial range),
or a list of addresses (each a trivial range), or a range of
addresses (low and high values, inclusive), as well as the most
generic form of a list of ranges. Address ranges are used to
support more than one remote system sharing the same SA, e.g.,
behind a security gateway.
- Local IP Address(es) (IPv4 or IPv6): this is a list of ranges of
IP addresses (unicast, broadcast (IPv4 only)). This structure
allows expression of a single IP address (via a trivial range),
or a list of addresses (each a trivial range), or a range of
addresses (low and high values, inclusive), as well as the most
generic form of a list of ranges. Address ranges are used to
support more than one source system sharing the same SA, e.g.,
behind a security gateway. Local refers to the address(es)
being protected by this implementation (or policy entry).
Note: The SPD does not include support for multicast address
entries. To support multicast SAs, an implementation should make
use of a Group SPD (GSPD) as defined in [RFC3740]. GSPD entries
require a different structure, i.e., one cannot use of the
symmetric relationship associated with local and remote address
values for unicast SAs in a multicast context. Specifically,
outbound traffic directed to a multicast address on an SA would
not be received on a companion, inbound SA with the multicast
address as the source.
- Next Layer Protocol: Obtained from the IPv4 "Protocol" or the
IPv6 "Next Header" fields. This is an individual protocol
number, ANY, or for IPv6 only, OPAQUE. The Next Layer Protocol
is whatever comes after any IP extension headers that are
present. To simplify locating the Next Layer Protocol, there
SHOULD be a mechanism for configuring which IPv6 extension
headers to skip. The default configuration for which protocols
to skip SHOULD include the following protocols: 0 (Hop-by-hop
options), 43 (Routing Header), 44 (Fragmentation Header), and 60
(Destination Options). Note: The default list does NOT include
51 (AH), or 50 (ESP). From a selector lookup point of view,
IPsec treats AH and ESP as Next Layer Protocols.
Several additional selectors depend on the Next Layer Protocol
value:
* If the Next Layer Protocol uses two ports (e.g., TCP, UDP,
SCTP, ...), then there are selectors for Local and Remote
Ports. Each of these selectors has a list of ranges of
values. Note that the Local and Remote ports may not be
Kent & Seo [Page 26]
Internet Draft Security Architecture for IP March 2005
available in the case of receipt of a fragmented packet or if
the port fields have been protected by IPsec (encrypted),
thus a value of OPAQUE also MUST be supported. Note: In a
non-initial fragment, port values will not be available. If a
port selector specifies a value other than ANY or OPAQUE, it
cannot match packets that are non-initial fragments. If the
SA requires a port value other than ANY or OPAQUE, an
arriving fragment without ports MUST be discarded. (See
Section 7 Handling Fragments.)
* If the Next Layer Protocol is a Mobility Header, then there
is a selector for IPv6 Mobility Header Message Type (MH type)
[Mobip]. This is an 8-bit value that identifies a particular
mobility message. Note that the MH type may not be available
in the case of receipt of a fragmented packet. (See Section 7
Handling Fragments.) For IKE, the IPv6 mobility header
message type (MH type) is placed in the most significant
eight bits of the 16-bit local "port" selector.
* If the Next Layer Protocol value is ICMP then there is a
16-bit selector for the ICMP message type and code. The
message type is a single 8-bit value, which defines the type
of an ICMP message, or ANY. The ICMP code is a single 8-bit
value that defines a specific subtype for an ICMP message.
For IKE, the message type is placed in the most significant 8
bits of the 16-bit selector and the code is placed in the
least significant 8 bits. This 16-bit selector can contain a
single type and a range of codes, a single type and ANY code,
ANY type and ANY code. Given a policy entry with a range of
Types (T-start to T-end) and a range of Codes (C-start to
C-end), and an ICMP packet with Type t and Code c, an
implementation MUST test for a match using
(T-start*256) + C-start <= (t*256) + c <= (T-end*256) +
C-end
Note that the ICMP message type and code may not be available
in the case of receipt of a fragmented packet. (See Section 7
Handling Fragments.)
- Name: This is not a selector like the others above. It is not
acquired from a packet. A name may be used as a symbolic
identifier for an IPsec Local or Remote address. Named SPD
entries are used in two ways:
1. A named SPD entry is used by a responder (not an initiator)
in support of access control when an IP address would not be
appropriate for the Remote IP address selector, e.g., for
"road warriors." The name used to match this field is
Kent & Seo [Page 27]
Internet Draft Security Architecture for IP March 2005
communicated during the IKE negotiation in the ID payload.
In this context, the initiator's Source IP address (inner IP
header in tunnel mode) is bound to the Remote IP address in
the SAD entry created by the IKE negotiation. This address
overrides the Remote IP address value in the SPD, when the
SPD entry is selected in this fashion. All IPsec
implementations MUST support this use of names.
2. A named SPD entry may be used by an initiator to identify a
user for whom an IPsec SA will be created (or for whom
traffic may be bypassed). The initiator's IP source address
(from inner IP header in tunnel mode) is used to replace the
following if and when they are created:
- local address in the SPD cache entry
- local address in the outbound SAD entry
- remote address in the inbound SAD entry
Support for this use is optional for multi-user, native host
implementations and not applicable to other implementations.
Note that this name is used only locally; it is not
communicated by the key management protocol. Also, name
forms other than those used for case 1 above (responder) are
applicable in the initiator context (see below).
An SPD entry can contain both a name (or a list of names) and
also values for the Local or Remote IP address.
For case 1, responder, the identifiers employed in named SPD
entries are one of the following four types:
a. a fully qualified user name string (email), e.g.,
mozart@foo.example.com
(this corresponds to ID_RFC822_ADDR in IKE v2)
b. a fully qualified DNS name, e.g.,
foo.example.com
(this corresponds to ID_FQDN in IKE v2)
c. X.500 distinguished name, e.g., [WaKiHo97],
CN = Stephen T. Kent, O = BBN Technologies,
SP = MA, C = US
(this corresponds to ID_DER_ASN1_DN in IKE v2, after
decoding)
d. a byte string
Kent & Seo [Page 28]
Internet Draft Security Architecture for IP March 2005
(this corresponds to Key_ID in IKE v2)
For case 2, initiator, the identifiers employed in named SPD
entries are of type byte string. They are likely to be Unix
UIDs, Windows security IDs or something similar, but could also
be a user name or account name. In all cases, this identifier
is only of local concern and is not transmitted.
The IPsec implementation context determines how selectors are used.
For example, a native host implementation typically makes use of a
socket interface. When a new connection is established the SPD can
be consulted and an SA bound to the socket. Thus traffic sent via
that socket need not result in additional lookups to the SPD (SPD-O
and SPD-S) cache. In contrast, a BITS, BITW, or security gateway
implementation needs to look at each packet and perform an
SPD-O/SPD-S cache lookup based on the selectors.
4.4.1.2 Structure of an SPD entry
This section contains a prose description of an SPD entry. Also,
Appendix C provides an example of an ASN.1 definition of an SPD
entry.
This text describes the SPD in a fashion that is intended to map
directly into IKE payloads to ensure that the policy required by SPD
entries can be negotiated through IKE. Unfortunately, the semantics
of the version of IKE v2 published concurrently with this document
[Kau05] do not align precisely with those defined for the SPD.
Specifically, IKE v2 does not enable negotiation of a single SA that
binds multiple pairs of local and remote addresses and ports to a
single SA. Instead, when multiple local and remote addresses and
ports are negotiated for an SA, IKE v2 treats these not as pairs, but
as (unordered) sets of local and remote values that can be
arbitrarily paired. Until IKE provides a facility that conveys the
semantics that are expressed in the SPD via selector sets (as
described below), users MUST NOT include multiple selector sets in a
single SPD entry unless the access control intent aligns with the IKE
"mix and match" semantics. An implementation MAY warn users, to alert
them to this problem if users create SPD entries with multiple
selector sets, the syntax of which indicates possible conflicts with
current IKE semantics.
The management GUI can offer the user other forms of data entry and
display, e.g., the option of using address prefixes as well as
ranges, and symbolic names for protocols, ports, etc. (Do not confuse
the use of symbolic names in a management interface with the SPD
selector "Name".) Note that Remote/Local apply only to IP addresses
and ports, not to ICMP message type/code or Mobility Header type.
Also, if the reserved, symbolic selector value OPAQUE or ANY is
Kent & Seo [Page 29]
Internet Draft Security Architecture for IP March 2005
employed for a given selector type, only that value may appear in the
list for that selector, and it must appear only once in the list for
that selector. Note that ANY and OPAQUE are local syntax conventions
-- IKE v2 negotiates these values via the ranges indicated below:
ANY: start = 0 end = <max>
OPAQUE: start = <max> end = 0
An SPD is an ordered list of entries each of which contains the
following fields.
o Name -- a list of IDs. This quasi-selector is optional.
The forms that MUST be supported are described above in
Section 4.4.1.1 under "Name".
o PFP flags -- one per traffic selector. A given flag, e.g.,
for Next Layer Protocol, applies to the relevant selector
across all "selector sets" (see below) contained in an SPD
entry. When creating an SA, each flag specifies for the
corresponding traffic selector whether to instantiate the
selector from the corresponding field in the packet that
triggered the creation of the SA or from the value(s) in
the corresponding SPD entry (see Section 4.4.1, "How To
Derive the Values for an SAD entry"). Whether a single
flag is used for, e.g., source port, ICMP type/code, and
MH type, or a separate flag is used for each, is a local
matter. There are PFP flags for:
- Local Address
- Remote Address
- Next Layer Protocol
- Local Port, or ICMP message type/code or Mobility
Header type (depending on the next layer protocol)
- Remote Port, or ICMP message type/code or Mobility
Header type (depending on the next layer protocol)
o One to N selector sets that correspond to the "condition"
for applying a particular IPsec action. Each selector set
contains:
- Local Address
- Remote Address
- Next Layer Protocol
- Local Port, or ICMP message type/code or Mobility
Header type (depending on the next layer protocol)
- Remote Port, or ICMP message type/code or Mobility
Header type (depending on the next layer protocol)
Note: The "next protocol" selector is an individual value
(unlike the local and remote IP addresses) in a selector
Kent & Seo [Page 30]
Internet Draft Security Architecture for IP March 2005
set entry. This is consistent with how IKE v2 negotiates
the TS values for an SA. It also makes sense because one
may need to associate different port fields with different
protocols. It is possible to associate multiple protocols
(and ports) with a single SA by specifying multiple
selector sets for that SA.
o processing info -- which action is required -- PROTECT,
BYPASS, or DISCARD. There is just one action that goes with
all the selector sets, not a separate action for each set.
If the required processing is PROTECT, the entry contains
the following information.
- IPsec mode -- tunnel or transport
- (if tunnel mode) local tunnel address -- For a
non-mobile host, if there is just one interface, this
is straightforward; and if there are multiple
interfaces, this must be statically configured. For a
mobile host, the specification of the local address
is handled externally to IPsec.
- (if tunnel mode) remote tunnel address -- There is no
standard way to determine this. See 4.5.3 "Locating a
Security Gateway".
- extended sequence number -- Is this SA using extended
sequence numbers?
- stateful fragment checking -- Is this SA using
stateful fragment checking (see Section 7 for more
details)
- Bypass DF bit (T/F) -- applicable to tunnel mode SAs
- Bypass DSCP (T/F) or map to unprotected DSCP values
(array) if needed to restrict bypass of DSCP values --
applicable to tunnel mode SAs
- IPsec protocol -- AH or ESP
- algorithms -- which ones to use for AH, which ones to
use for ESP, which ones to use for combined mode,
ordered by decreasing priority
It is a local matter as to what information is kept with regard to
handling extant SAs when the SPD is changed.
4.4.1.3 More re: Fields Associated with Next Layer Protocols
Additional selectors are often associated with fields in the Next
Layer Protocol header. A particular Next Layer Protocol can have
zero, one, or two selectors. There may be situations where there
aren't both local and remote selectors for the fields that are
dependent on the Next Layer Protocol. The IPv6 Mobility Header has
only a Mobility Header message type. AH and ESP have no further
selector fields. A system may be willing to send an ICMP message
type and code that it does not want to receive. In the descriptions
Kent & Seo [Page 31]
Internet Draft Security Architecture for IP March 2005
below, "port" is used to mean a field that is dependent on the Next
Layer Protocol.
A. If a Next Layer Protocol has no "port" selectors, then
the Local and Remote "port" selectors are set to OPAQUE in
the relevant SPD entry, e.g.,
Local's
next layer protocol = AH
"port" selector = OPAQUE
Remote's
next layer protocol = AH
"port" selector = OPAQUE
B. If a Next Layer Protocol has only one selector, e.g.,
Mobility Header type, then that field is placed in the
Local "port" selector in the relevant SPD entry, and the
Remote "port" selector is set to OPAQUE in the relevant
SPD entry, e.g.,
Local's
next layer protocol = Mobility Header
"port" selector = Mobility Header message type
Remote's
next layer protocol = Mobility Header
"port" selector = OPAQUE
C. If a system is willing to send traffic with a particular
"port" value but NOT receive traffic with that kind of
port value, the system's traffic selectors are set as
follows in the relevant SPD entry:
Local's
next layer protocol = ICMP
"port" selector = <specific ICMP type & code>
Remote's
next layer protocol = ICMP
"port" selector = OPAQUE
D. To indicate that a system is willing to receive traffic
with a particular "port" value but NOT send that kind of
traffic, the system's traffic selectors are set as follows
in the relevant SPD entry:
Local's
next layer protocol = ICMP
Kent & Seo [Page 32]
Internet Draft Security Architecture for IP March 2005
"port" selector = OPAQUE
Remote's
next layer protocol = ICMP
"port" selector = <specific ICMP type & code>
For example, if a security gateway is willing to allow
systems behind it to send ICMP traceroutes, but is not
willing to let outside systems run ICMP traceroutes to
systems behind it, then the security gateway's traffic
selectors are set as follows in the relevant SPD entry:
Local's
next layer protocol = 1 (ICMPv4)
"port" selector = 30 (traceroute)
Remote's
next layer protocol = 1 (ICMPv4)
"port" selector = OPAQUE
4.4.2 Security Association Database (SAD)
In each IPsec implementation there is a nominal Security Association
Database (SAD), in which each entry defines the parameters associated
with one SA. Each SA has an entry in the SAD. For outbound
processing, each SAD entry is pointed to by entries in the SPD-S part
of the SPD cache. For inbound processing, for unicast SAs, the SPI is
used either alone to look up an SA, or the SPI may be used in
conjunction with the IPsec protocol type. If an IPsec implementation
supports multicast, the SPI plus destination address, or SPI plus
destination and source addresses are used to look up the SA. (See
Section 4.1 for details on the algorithm that MUST be used for
mapping inbound IPsec datagrams to SAs.) The following parameters are
associated with each entry in the SAD. They should all be present
except where otherwise noted, e.g., AH Authentication algorithm. This
description does not purport to be a MIB, only a specification of the
minimal data items required to support an SA in an IPsec
implementation.
For each of the selectors defined in Section 4.4.1.1, the entry for
an inbound SA in the SAD MUST be initially populated with the value
or values negotiated at the time the SA was created. (See Section
4.4.1, paragraph on Handling Changes to the SPD while the System is
Running for guidance on the effect of SPD changes on extant SAs.) For
a receiver, these values are used to check that the header fields of
an inbound packet (after IPsec processing) match the selector values
negotiated for the SA. Thus, the SAD acts as a cache for checking the
selectors of inbound traffic arriving on SAs. For the receiver, this
is part of verifying that a packet arriving on an SA is consistent
Kent & Seo [Page 33]
Internet Draft Security Architecture for IP March 2005
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, as described in section 4.4.1.1, "Selectors."
Note also, that there are a couple of situations in which the SAD can
have entries for SAs that do not have corresponding entries in the
SPD. Since 2401bis does not mandate that the SAD be selectively
cleared when the SPD is changed, SAD entries can remain when the SPD
entries that created them are changed or deleted. Also, if a manually
keyed SA is created, there could be an SAD entry for this SA that
does not correspond to any SPD entry.
Note: The SAD can support multicast SAs, if manually configured. An
outbound multicast SA has the same structure as a unicast SA. The
source address is that of the sender and the destination address is
the multicast group address. An inbound, multicast SA must be
configured with the source addresses of each peer authorized to
transmit to the multicast SA in question. The SPI value for a
multicast SA is provided by a multicast group controller, not by the
receiver, as for a unicast SA. Because an SAD entry may be required
to accommodate multiple, individual IP source addresses that were
part of an SPD entry (for unicast SAs), the required facility for
inbound, multicast SAs is a feature already present in an IPsec
implementation. However, because the SPD has no provisions for
accommodating multicast entries, this document does not specify an
automated way to create an SAD entry for a multicast, inbound SA.
Only manually configured SAD entries can be created to accommodate
inbound, multicast traffic.
4.4.2.1 Data Items in the SAD
The following data items MUST be in the SAD:
o Security Parameter Index (SPI): a 32-bit value selected by the
receiving end of an SA to uniquely identify the SA. In an SAD
entry for an outbound SA, the SPI is used to construct the
packet's AH or ESP header. In an SAD entry for an inbound SA, the
SPI is used to map traffic to the appropriate SA (see text on
unicast/multicast in Section 4.1).
o Sequence Number Counter: a 64-bit counter used to generate the
Sequence Number field in AH or ESP headers. 64-bit sequence
numbers are the default, but 32-bit sequence numbers are also
supported if negotiated.
o Sequence Counter Overflow: a flag indicating whether overflow of
the Sequence Number Counter should generate an auditable event and
prevent transmission of additional packets on the SA, or whether
rollover is permitted. The audit log entry for this event SHOULD
include the SPI value, current date/time, Local Address, Remote
Kent & Seo [Page 34]
Internet Draft Security Architecture for IP March 2005
Address, and the selectors from the relevant SAD entry.
o Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent)
used to determine whether an inbound AH or ESP packet is a replay.
Note: If anti-replay has been disabled by the receiver for an SA,
e.g., in the case of a manually keyed SA, then the 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 as well.
o AH Authentication algorithm, key, etc. This is required only if AH
is supported.
o ESP Encryption algorithm, key, mode, IV, etc. If a combined mode
algorithm is used, these fields will not be applicable.
o ESP integrity algorithm, keys, etc. If the integrity service is
not selected, these fields will not be applicable. If a combined
mode algorithm is used, these fields will not be applicable.
o ESP combined mode algorithms, key(s), etc. This data is used when
a combined mode (encryption and integrity) algorithm is used with
ESP. If a combined mode algorithm is not used, these fields are
not applicable.
o Lifetime of this SA: a time interval after which an SA must be
replaced with a new SA (and new SPI) or terminated, plus an
indication of which of these actions should occur. This may be
expressed as a time or byte count, or a simultaneous use of both
with the 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, and if
IKE employs X.509 certificates for SA establishment, the SA
lifetime must be constrained by the validity intervals of the
certificates, and the NextIssueDate of the CRLs used in the IKE
exchange for the SA. Both initiator and responder are responsible
for constraining the SA lifetime in this fashion. Note: The
details of how to handle the refreshing of keys when SAs expire is
a local matter. However, one reasonable approach is:
(a) If byte count is used, then the implementation SHOULD count the
number of bytes to which the IPsec cryptographic algorithm is
applied. For ESP, this is the encryption algorithm (including
Null encryption) and for AH, this is the authentication
algorithm. This includes pad bytes, etc. Note that
implementations MUST be able to handle having the counters at
Kent & Seo [Page 35]
Internet Draft Security Architecture for IP March 2005
the ends of an SA get out of synch, e.g., because of packet
loss or because the implementations at each end of the SA
aren't doing things the same way.
(b) There SHOULD be two kinds of lifetime -- a soft lifetime that
warns the implementation to initiate action such as setting up
a replacement SA; and a hard lifetime when the current SA ends
and is destroyed.
(c) If the entire packet does not get delivered during the SAs
lifetime, the packet SHOULD be discarded.
o IPsec protocol mode: tunnel or transport. Indicates which mode of
AH or ESP is applied to traffic on this SA.
o Stateful fragment checking flag. Indicates whether or not stateful
fragment checking applies to this SA.
o Bypass DF bit (T/F) - applicable to tunnel mode SAs where both
inner and outer headers are IPv4.
o DSCP values -- the set of DSCP values allowed for packets carried
over this SA. If no values are specified, no DSCP-specific
filtering is applied. If one or more values are specified, these
are used to select one SA among several that match the traffic
selectors for an outbound packet. Note that these values are NOT
checked against inbound traffic arriving on the SA.
o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if
needed to restrict bypass of DSCP values - applicable to tunnel
mode SAs. This feature maps DSCP values from an inner header to
values in an outer header, e.g., to address covert channel
signaling concerns.
o Path MTU: any observed path MTU and aging variables.
o Tunnel header IP source and destination address - both addresses
must be either IPv4 or IPv6 addresses. The version implies the
type of IP header to be used. Only used when the IPsec protocol
mode is tunnel.
4.4.2.2 Relationship between SPD, PFP flag, packet, and SAD
For each selector, the following tables show the relationship
between the value in the SPD, the PFP flag, the value in the
triggering packet and the resulting value in the SAD. Note that
the administrative interface for IPsec can use various syntactic
options to make it easier for the administrator to enter rules.
For example, although a list of ranges is what IKE v2 sends, it
Kent & Seo [Page 36]
Internet Draft Security Architecture for IP March 2005
might be clearer and less error prone for the user to enter a
single IP address or IP address prefix.
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
-------- ---------------- --- ------------ --------------
loc addr list of ranges 0 IP addr "S" list of ranges
ANY 0 IP addr "S" ANY
list of ranges 1 IP addr "S" "S"
ANY 1 IP addr "S" "S"
rem addr list of ranges 0 IP addr "D" list of ranges
ANY 0 IP addr "D" ANY
list of ranges 1 IP addr "D" "D"
ANY 1 IP addr "D" "D"
protocol list of prot's* 0 prot. "P" list of prot's*
ANY** 0 prot. "P" ANY
OPAQUE**** 0 prot. "P" OPAQUE
list of prot's* 0 not avail. discard packet
ANY** 0 not avail. ANY
OPAQUE**** 0 not avail. OPAQUE
list of prot's* 1 prot. "P" "P"
ANY** 1 prot. "P" "P"
OPAQUE**** 1 prot. "P" ***
list of prot's* 1 not avail. discard packet
ANY** 1 not avail. discard packet
OPAQUE**** 1 not avail. ***
Kent & Seo [Page 37]
Internet Draft Security Architecture for IP March 2005
If the protocol is one that has two ports then there will be
selectors for both Local and Remote ports.
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
-------- ---------------- --- ------------ --------------
loc port list of ranges 0 src port "s" list of ranges
ANY 0 src port "s" ANY
OPAQUE 0 src port "s" OPAQUE
list of ranges 0 not avail. discard packet
ANY 0 not avail. ANY
OPAQUE 0 not avail. OPAQUE
list of ranges 1 src port "s" "s"
ANY 1 src port "s" "s"
OPAQUE 1 src port "s" ***
list of ranges 1 not avail. discard packet
ANY 1 not avail. discard packet
OPAQUE 1 not avail. ***
rem port list of ranges 0 dst port "d" list of ranges
ANY 0 dst port "d" ANY
OPAQUE 0 dst port "d" OPAQUE
list of ranges 0 not avail. discard packet
ANY 0 not avail. ANY
OPAQUE 0 not avail. OPAQUE
list of ranges 1 dst port "d" "d"
ANY 1 dst port "d" "d"
OPAQUE 1 dst port "d" ***
list of ranges 1 not avail. discard packet
ANY 1 not avail. discard packet
OPAQUE 1 not avail. ***
Kent & Seo [Page 38]
Internet Draft Security Architecture for IP March 2005
If the protocol is mobility header then there will be a selector
for mh type.
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
-------- ---------------- --- ------------ --------------
mh type list of ranges 0 mh type "T" list of ranges
ANY 0 mh type "T" ANY
OPAQUE 0 mh type "T" OPAQUE
list of ranges 0 not avail. discard packet
ANY 0 not avail. ANY
OPAQUE 0 not avail. OPAQUE
list of ranges 1 mh type "T" "T"
ANY 1 mh type "T" "T"
OPAQUE 1 mh type "T" ***
list of ranges 1 not avail. discard packet
ANY 1 not avail. discard packet
OPAQUE 1 not avail. ***
Kent & Seo [Page 39]
Internet Draft Security Architecture for IP March 2005
If the protocol is ICMP, then there will be a 16-bit selector for
ICMP type and ICMP code. Note that the type and code are bound to
each other, i.e., the codes apply to the particular type. This
16-bit selector can contain a single type and a range of codes, a
single type and ANY code, and ANY type and ANY code.
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
--------- ---------------- --- ------------ --------------
ICMP type a single type & 0 type "t" & single type &
and code range of codes code "c" range of codes
a single type & 0 type "t" & single type &
ANY code code "c" ANY code
ANY type & ANY 0 type "t" & ANY type &
code code "c" ANY code
OPAQUE 0 type "t" & OPAQUE
code "c"
a single type & 0 not avail. discard packet
range of codes
a single type & 0 not avail. discard packet
ANY code
ANY type & 0 not avail. ANY type &
ANY code ANY code
OPAQUE 0 not