5660 lines
256 KiB
Plaintext
5660 lines
256 KiB
Plaintext
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Network Working Group S. Kent
|
|||
|
Request for Comments: 4301 K. Seo
|
|||
|
Obsoletes: 2401 BBN Technologies
|
|||
|
Category: Standards Track December 2005
|
|||
|
|
|||
|
|
|||
|
Security Architecture for the Internet Protocol
|
|||
|
|
|||
|
Status of This Memo
|
|||
|
|
|||
|
This document specifies an Internet standards track protocol for the
|
|||
|
Internet community, and requests discussion and suggestions for
|
|||
|
improvements. Please refer to the current edition of the "Internet
|
|||
|
Official Protocol Standards" (STD 1) for the standardization state
|
|||
|
and status of this protocol. Distribution of this memo is unlimited.
|
|||
|
|
|||
|
Copyright Notice
|
|||
|
|
|||
|
Copyright (C) The Internet Society (2005).
|
|||
|
|
|||
|
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).
|
|||
|
|
|||
|
Dedication
|
|||
|
|
|||
|
This document is dedicated to the memory of Charlie Lynn, a long-time
|
|||
|
senior colleague at BBN, who made very significant contributions to
|
|||
|
the IPsec documents.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 1]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 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 ......................................12
|
|||
|
4.2. SA Functionality ..........................................16
|
|||
|
4.3. Combining SAs .............................................17
|
|||
|
4.4. Major IPsec Databases .....................................18
|
|||
|
4.4.1. The Security Policy Database (SPD) .................19
|
|||
|
4.4.1.1. Selectors .................................26
|
|||
|
4.4.1.2. Structure of an SPD Entry .................30
|
|||
|
4.4.1.3. More Regarding Fields Associated
|
|||
|
with Next Layer Protocols .................32
|
|||
|
4.4.2. Security Association Database (SAD) ................34
|
|||
|
4.4.2.1. Data Items in the SAD .....................36
|
|||
|
4.4.2.2. Relationship between SPD, PFP
|
|||
|
flag, packet, and SAD .....................38
|
|||
|
4.4.3. Peer Authorization Database (PAD) ..................43
|
|||
|
4.4.3.1. PAD Entry IDs and Matching Rules ..........44
|
|||
|
4.4.3.2. IKE Peer Authentication Data ..............45
|
|||
|
4.4.3.3. Child SA Authorization Data ...............46
|
|||
|
4.4.3.4. How the PAD Is Used .......................46
|
|||
|
4.5. SA and Key Management .....................................47
|
|||
|
4.5.1. Manual Techniques ..................................48
|
|||
|
4.5.2. Automated SA and Key Management ....................48
|
|||
|
4.5.3. Locating a Security Gateway ........................49
|
|||
|
4.6. SAs and Multicast .........................................50
|
|||
|
5. IP Traffic Processing ..........................................50
|
|||
|
5.1. Outbound IP Traffic Processing
|
|||
|
(protected-to-unprotected) ................................52
|
|||
|
5.1.1. Handling an Outbound Packet That Must Be
|
|||
|
Discarded ..........................................54
|
|||
|
5.1.2. Header Construction for Tunnel Mode ................55
|
|||
|
5.1.2.1. IPv4: Header Construction for
|
|||
|
Tunnel Mode ...............................57
|
|||
|
5.1.2.2. IPv6: Header Construction for
|
|||
|
Tunnel Mode ...............................59
|
|||
|
5.2. Processing Inbound IP Traffic (unprotected-to-protected) ..59
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 2]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
6. ICMP Processing ................................................63
|
|||
|
6.1. Processing ICMP Error Messages Directed to an
|
|||
|
IPsec Implementation ......................................63
|
|||
|
6.1.1. ICMP Error Messages Received on the
|
|||
|
Unprotected Side of the Boundary ...................63
|
|||
|
6.1.2. ICMP Error Messages Received on the
|
|||
|
Protected Side of the Boundary .....................64
|
|||
|
6.2. Processing Protected, Transit ICMP Error Messages .........64
|
|||
|
7. Handling Fragments (on the protected side of the IPsec
|
|||
|
boundary) ......................................................66
|
|||
|
7.1. Tunnel Mode SAs that Carry Initial and Non-Initial
|
|||
|
Fragments .................................................67
|
|||
|
7.2. Separate Tunnel Mode SAs for Non-Initial Fragments ........67
|
|||
|
7.3. Stateful Fragment Checking ................................68
|
|||
|
7.4. BYPASS/DISCARD Traffic ....................................69
|
|||
|
8. Path MTU/DF Processing .........................................69
|
|||
|
8.1. DF Bit ....................................................69
|
|||
|
8.2. Path MTU (PMTU) Discovery .................................70
|
|||
|
8.2.1. Propagation of PMTU ................................70
|
|||
|
8.2.2. PMTU Aging .........................................71
|
|||
|
9. Auditing .......................................................71
|
|||
|
10. Conformance Requirements ......................................71
|
|||
|
11. Security Considerations .......................................72
|
|||
|
12. IANA Considerations ...........................................72
|
|||
|
13. Differences from RFC 2401 .....................................72
|
|||
|
14. Acknowledgements ..............................................75
|
|||
|
Appendix A: Glossary ..............................................76
|
|||
|
Appendix B: Decorrelation .........................................79
|
|||
|
B.1. Decorrelation Algorithm ...................................79
|
|||
|
Appendix C: ASN.1 for an SPD Entry ................................82
|
|||
|
Appendix D: Fragment Handling Rationale ...........................88
|
|||
|
D.1. Transport Mode and Fragments ..............................88
|
|||
|
D.2. Tunnel Mode and Fragments .................................89
|
|||
|
D.3. The Problem of Non-Initial Fragments ......................90
|
|||
|
D.4. BYPASS/DISCARD Traffic ....................................93
|
|||
|
D.5. Just say no to ports? .....................................94
|
|||
|
D.6. Other Suggested Solutions..................................94
|
|||
|
D.7. Consistency................................................95
|
|||
|
D.8. Conclusions................................................95
|
|||
|
Appendix E: Example of Supporting Nested SAs via SPD and
|
|||
|
Forwarding Table Entries...............................96
|
|||
|
References.........................................................98
|
|||
|
Normative References............................................98
|
|||
|
Informative References..........................................99
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 3]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 4]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
(end users or system administrators) also are part of the target
|
|||
|
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 interrelationship. 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 IKEv2 [Sch05] plus a
|
|||
|
separate RFC for each cryptographic algorithm.
|
|||
|
c. automatic key management -- RFCs on "The Internet Key
|
|||
|
Exchange (IKEv2) Protocol" [Kau05] and "Cryptographic
|
|||
|
Algorithms for Use in the Internet Key Exchange Version 2
|
|||
|
(IKEv2)" [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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 5]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
via IKEv2.) The IPsec firewall function makes use of the
|
|||
|
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 and 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 IKEv2
|
|||
|
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 IKEv2 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 their implementation, which is
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 6]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
outside the scope of this set of standards. Moreover, the security
|
|||
|
of a computer system or network is a function of many factors,
|
|||
|
including personnel, physical, procedural, compromising emanations,
|
|||
|
and computer security practices. Thus, IPsec is only one part of an
|
|||
|
overall system security architecture.
|
|||
|
|
|||
|
Finally, the security afforded by the use of IPsec is critically
|
|||
|
dependent on many aspects of the operating environment in which the
|
|||
|
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
|
|||
|
(SG), 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 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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 7]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
IPsec security services are offered at the IP layer through selection
|
|||
|
of appropriate security protocols, cryptographic algorithms, and
|
|||
|
cryptographic keys. IPsec can be used to protect one or more "paths"
|
|||
|
(a) between a pair of hosts, (b) between a pair of security gateways,
|
|||
|
or (c) between a security gateway and a host. 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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 8]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
Note the facilities for discarding traffic on either side of the
|
|||
|
IPsec boundary, the BYPASS facility that allows traffic to transit
|
|||
|
the boundary without cryptographic protection, and the reference to
|
|||
|
IKE as a protected-side key and security management function.
|
|||
|
|
|||
|
IPsec optionally supports negotiation of IP compression [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 virtual private
|
|||
|
network (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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 9]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
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, and
|
|||
|
|
|||
|
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 (IKEv2 [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 IKEv2 but not in IKEv1, 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 IKEv2 or a key and security association management
|
|||
|
system with comparable features.
|
|||
|
|
|||
|
3.3. Where IPsec Can Be Implemented
|
|||
|
|
|||
|
There are many ways in which IPsec may be implemented in a host, or
|
|||
|
in conjunction with a router or firewall to create a security
|
|||
|
gateway, or as an independent security device.
|
|||
|
|
|||
|
a. IPsec may be integrated into the native IP stack. This requires
|
|||
|
access to the IP source code and is applicable to both hosts and
|
|||
|
security gateways, although native host implementations benefit
|
|||
|
the most from this strategy, as explained later (Section 4.4.1,
|
|||
|
paragraph 6; Section 4.4.1.1, last paragraph).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 10]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
"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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 11]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
direction) is required. IKE explicitly creates SA pairs in
|
|||
|
recognition of this common usage requirement.
|
|||
|
|
|||
|
For an SA used to carry unicast traffic, the Security Parameters
|
|||
|
Index (SPI) by itself suffices to specify an SA. (For information on
|
|||
|
the SPI, see Appendix A and the AH and ESP specifications [Ken05b,
|
|||
|
Ken05a].) 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 de-
|
|||
|
multiplexing 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:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 12]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
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 Group Domain of Interpretation
|
|||
|
(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 Code Point (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 Quality of Service (QoS) appropriately.
|
|||
|
To permit this, the IPsec implementation MUST permit establishment
|
|||
|
and maintenance of multiple SAs between a given sender and receiver,
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 13]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
DISCUSSION: Although 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 Generic Routing
|
|||
|
Encapsulation (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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 14]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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, Stream Control
|
|||
|
Transmission Protocol (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.
|
|||
|
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., Simple
|
|||
|
Network Management Protocol (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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 15]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
(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 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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 16]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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 affects 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
|
|||
|
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 [RFC2401] 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 [RFC2401]. 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.)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 17]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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 PAD, provides a link
|
|||
|
between an SA management protocol (such as IKE) and the SPD (Section
|
|||
|
4.4.3).
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 18]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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 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 [Mobip]) 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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 19]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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 [RFC2401].
|
|||
|
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 Access
|
|||
|
Control Lists (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
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 20]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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 lookup 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
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 21]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
because it may not be present in a fragment, it does not exist for
|
|||
|
the given Next Layer Protocol, or 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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 22]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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., IKEv2) 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 Mobility
|
|||
|
Header (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:
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 23]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
implementation making use of a socket interface, the SPD may not
|
|||
|
need to be consulted on a per-packet basis, as noted at the end of
|
|||
|
Section 4.4.1.1 and in Section 5.) 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
|
|||
|
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., IKEv2) negotiates A. And all 3
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 24]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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 information 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 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.
|
|||
|
|
|||
|
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
|
|||
|
IKEv2, 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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 25]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
- 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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 26]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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 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 (as do TCP, UDP,
|
|||
|
SCTP, and others), 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
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 27]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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,
|
|||
|
and 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
|
|||
|
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:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 28]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
- 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 IKEv2)
|
|||
|
|
|||
|
b. a fully qualified DNS name, e.g.,
|
|||
|
foo.example.com
|
|||
|
(this corresponds to ID_FQDN in IKEv2)
|
|||
|
|
|||
|
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 IKEv2, after
|
|||
|
decoding)
|
|||
|
|
|||
|
d. a byte string
|
|||
|
(this corresponds to Key_ID in IKEv2)
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 29]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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 IKEv2 published concurrently with this document
|
|||
|
[Kau05] do not align precisely with those defined for the SPD.
|
|||
|
Specifically, IKEv2 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, IKEv2 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
|
|||
|
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
|
|||
|
-- IKEv2 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".
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 30]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
set entry. This is consistent with how IKEv2 negotiates
|
|||
|
the Traffic Selector (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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 31]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
- (if tunnel mode) local tunnel address -- For a
|
|||
|
non-mobile host, if there is just one interface, this
|
|||
|
is straightforward; 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 Regarding 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
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 32]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
Remote's
|
|||
|
next layer protocol = AH
|
|||
|
"port" selector = OPAQUE
|
|||
|
|
|||
|
B. Even if a Next Layer Protocol has only one selector, e.g.,
|
|||
|
Mobility Header type, then the Local and Remote "port"
|
|||
|
selectors are used to indicate whether a system is
|
|||
|
willing to send and/or receive traffic with the specified
|
|||
|
"port" values. For example, if Mobility Headers of a
|
|||
|
specified type are allowed to be sent and received via an
|
|||
|
SA, then the relevant SPD entry would be set as follows:
|
|||
|
|
|||
|
Local's
|
|||
|
next layer protocol = Mobility Header
|
|||
|
"port" selector = Mobility Header message type
|
|||
|
|
|||
|
Remote's
|
|||
|
next layer protocol = Mobility Header
|
|||
|
"port" selector = Mobility Header message type
|
|||
|
|
|||
|
If Mobility Headers of a specified type are allowed to be
|
|||
|
sent but NOT received via an SA, then the relevant SPD
|
|||
|
entry would be set as follows:
|
|||
|
|
|||
|
Local's
|
|||
|
next layer protocol = Mobility Header
|
|||
|
"port" selector = Mobility Header message type
|
|||
|
|
|||
|
Remote's
|
|||
|
next layer protocol = Mobility Header
|
|||
|
"port" selector = OPAQUE
|
|||
|
|
|||
|
If Mobility Headers of a specified type are allowed to be
|
|||
|
received but NOT sent via an SA, then the relevant SPD
|
|||
|
entry would be set as follows:
|
|||
|
|
|||
|
Local's
|
|||
|
next layer protocol = Mobility Header
|
|||
|
"port" selector = OPAQUE
|
|||
|
|
|||
|
Remote's
|
|||
|
next layer protocol = Mobility Header
|
|||
|
"port" selector = Mobility Header message type
|
|||
|
|
|||
|
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:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 33]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
"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 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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 34]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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 the
|
|||
|
paragraph in Section 4.4.1 under "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 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 this document 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.
|
|||
|
|
|||
|
Implementation Guidance: This document does not specify how an SPD-S
|
|||
|
entry refers to the corresponding SAD entry, as this is an
|
|||
|
implementation-specific detail. However, some implementations (based
|
|||
|
on experience from RFC 2401) are known to have problems in this
|
|||
|
regard. In particular, simply storing the (remote tunnel header IP
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 35]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
address, remote SPI) pair in the SPD cache is not sufficient, since
|
|||
|
the pair does not always uniquely identify a single SAD entry. For
|
|||
|
instance, two hosts behind the same NAT could choose the same SPI
|
|||
|
value. The situation also may arise if a host is assigned an IP
|
|||
|
address (e.g., via DHCP) previously used by some other host, and the
|
|||
|
SAs associated with the old host have not yet been deleted via dead
|
|||
|
peer detection mechanisms. This may lead to packets being sent over
|
|||
|
the wrong SA or, if key management ensures the pair is unique,
|
|||
|
denying the creation of otherwise valid SAs. Thus, implementors
|
|||
|
should implement links between the SPD cache and the SAD in a way
|
|||
|
that does not engender such problems.
|
|||
|
|
|||
|
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
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 36]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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 Certificate Revocation
|
|||
|
Lists (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
|
|||
|
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 SA's
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 37]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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 IKEv2 sends, it
|
|||
|
might be clearer and less error prone for the user to enter a
|
|||
|
single IP address or IP address prefix.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 38]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
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 Standards Track [Page 39]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 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 Standards Track [Page 40]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 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 Standards Track [Page 41]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 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 avail. OPAQUE
|
|||
|
|
|||
|
a single type & 1 type "t" & "t" and "c"
|
|||
|
range of codes code "c"
|
|||
|
a single type & 1 type "t" & "t" and "c"
|
|||
|
ANY code code "c"
|
|||
|
ANY type & 1 type "t" & "t" and "c"
|
|||
|
ANY code code "c"
|
|||
|
OPAQUE 1 type "t" & ***
|
|||
|
code "c"
|
|||
|
|
|||
|
a single type & 1 not avail. discard packet
|
|||
|
range of codes
|
|||
|
a single type & 1 not avail. discard packet
|
|||
|
ANY code
|
|||
|
ANY type & 1 not avail. discard packet
|
|||
|
ANY code
|
|||
|
OPAQUE 1 not avail. ***
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 42]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
If the name selector is used:
|
|||
|
|
|||
|
Value in
|
|||
|
Triggering Resulting SAD
|
|||
|
Selector SPD Entry PFP Packet Entry
|
|||
|
--------- ---------------- --- ------------ --------------
|
|||
|
name list of user or N/A N/A N/A
|
|||
|
system names
|
|||
|
|
|||
|
* "List of protocols" is the information, not the way
|
|||
|
that the SPD or SAD or IKEv2 have to represent this
|
|||
|
information.
|
|||
|
** 0 (zero) is used by IKE to indicate ANY for
|
|||
|
protocol.
|
|||
|
*** Use of PFP=1 with an OPAQUE value is an error and
|
|||
|
SHOULD be prohibited by an IPsec implementation.
|
|||
|
**** The protocol field cannot be OPAQUE in IPv4. This
|
|||
|
table entry applies only to IPv6.
|
|||
|
|
|||
|
4.4.3. Peer Authorization Database (PAD)
|
|||
|
|
|||
|
The Peer Authorization Database (PAD) provides the link between the
|
|||
|
SPD and a security association management protocol such as IKE. It
|
|||
|
embodies several critical functions:
|
|||
|
|
|||
|
o identifies the peers or groups of peers that are authorized
|
|||
|
to communicate with this IPsec entity
|
|||
|
o specifies the protocol and method used to authenticate each
|
|||
|
peer
|
|||
|
o provides the authentication data for each peer
|
|||
|
o constrains the types and values of IDs that can be asserted
|
|||
|
by a peer with regard to child SA creation, to ensure that the
|
|||
|
peer does not assert identities for lookup in the SPD that it
|
|||
|
is not authorized to represent, when child SAs are created
|
|||
|
o peer gateway location info, e.g., IP address(es) or DNS names,
|
|||
|
MAY be included for peers that are known to be "behind" a
|
|||
|
security gateway
|
|||
|
|
|||
|
The PAD provides these functions for an IKE peer when the peer acts
|
|||
|
as either the initiator or the responder.
|
|||
|
|
|||
|
To perform these functions, the PAD contains an entry for each peer
|
|||
|
or group of peers with which the IPsec entity will communicate. An
|
|||
|
entry names an individual peer (a user, end system or security
|
|||
|
gateway) or specifies a group of peers (using ID matching rules
|
|||
|
defined below). The entry specifies the authentication protocol
|
|||
|
(e.g., IKEv1, IKEv2, KINK) method used (e.g., certificates or pre-
|
|||
|
shared secrets) and the authentication data (e.g., the pre-shared
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 43]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
secret or the trust anchor relative to which the peer's certificate
|
|||
|
will be validated). For certificate-based authentication, the entry
|
|||
|
also may provide information to assist in verifying the revocation
|
|||
|
status of the peer, e.g., a pointer to a CRL repository or the name
|
|||
|
of an Online Certificate Status Protocol (OCSP) server associated
|
|||
|
with the peer or with the trust anchor associated with the peer.
|
|||
|
|
|||
|
Each entry also specifies whether the IKE ID payload will be used as
|
|||
|
a symbolic name for SPD lookup, or whether the remote IP address
|
|||
|
provided in traffic selector payloads will be used for SPD lookups
|
|||
|
when child SAs are created.
|
|||
|
|
|||
|
Note that the PAD information MAY be used to support creation of more
|
|||
|
than one tunnel mode SA at a time between two peers, e.g., two
|
|||
|
tunnels to protect the same addresses/hosts, but with different
|
|||
|
tunnel endpoints.
|
|||
|
|
|||
|
4.4.3.1. PAD Entry IDs and Matching Rules
|
|||
|
|
|||
|
The PAD is an ordered database, where the order is defined by an
|
|||
|
administrator (or a user in the case of a single-user end system).
|
|||
|
Usually, the same administrator will be responsible for both the PAD
|
|||
|
and SPD, since the two databases must be coordinated. The ordering
|
|||
|
requirement for the PAD arises for the same reason as for the SPD,
|
|||
|
i.e., because use of "star name" entries allows for overlaps in the
|
|||
|
set of IKE IDs that could match a specific entry.
|
|||
|
|
|||
|
Six types of IDs are supported for entries in the PAD, consistent
|
|||
|
with the symbolic name types and IP addresses used to identify SPD
|
|||
|
entries. The ID for each entry acts as the index for the PAD, i.e.,
|
|||
|
it is the value used to select an entry. All of these ID types can
|
|||
|
be used to match IKE ID payload types. The six types are:
|
|||
|
|
|||
|
o DNS name (specific or partial)
|
|||
|
o Distinguished Name (complete or sub-tree constrained)
|
|||
|
o RFC 822 email address (complete or partially qualified)
|
|||
|
o IPv4 address (range)
|
|||
|
o IPv6 address (range)
|
|||
|
o Key ID (exact match only)
|
|||
|
|
|||
|
The first three name types can accommodate sub-tree matching as well
|
|||
|
as exact matches. A DNS name may be fully qualified and thus match
|
|||
|
exactly one name, e.g., foo.example.com. Alternatively, the name may
|
|||
|
encompass a group of peers by being partially specified, e.g., the
|
|||
|
string ".example.com" could be used to match any DNS name ending in
|
|||
|
these two domain name components.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 44]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
Similarly, a Distinguished Name may specify a complete Distinguished
|
|||
|
Name to match exactly one entry, e.g., CN = Stephen, O = BBN
|
|||
|
Technologies, SP = MA, C = US. Alternatively, an entry may encompass
|
|||
|
a group of peers by specifying a sub-tree, e.g., an entry of the form
|
|||
|
"C = US, SP = MA" might be used to match all DNs that contain these
|
|||
|
two attributes as the top two Relative Distinguished Names (RDNs).
|
|||
|
|
|||
|
For an RFC 822 e-mail addresses, the same options exist. A complete
|
|||
|
address such as foo@example.com matches one entity, but a sub-tree
|
|||
|
name such as "@example.com" could be used to match all the entities
|
|||
|
with names ending in those two domain names to the right of the @.
|
|||
|
|
|||
|
The specific syntax used by an implementation to accommodate sub-tree
|
|||
|
matching for distinguished names, domain names or RFC 822 e-mail
|
|||
|
addresses is a local matter. But, at a minimum, sub-tree matching of
|
|||
|
the sort described above MUST be supported. (Substring matching
|
|||
|
within a DN, DNS name, or RFC 822 address MAY be supported, but is
|
|||
|
not required.)
|
|||
|
|
|||
|
For IPv4 and IPv6 addresses, the same address range syntax used for
|
|||
|
SPD entries MUST be supported. This allows specification of an
|
|||
|
individual address (via a trivial range), an address prefix (by
|
|||
|
choosing a range that adheres to Classless Inter-Domain Routing
|
|||
|
(CIDR)-style prefixes), or an arbitrary address range.
|
|||
|
|
|||
|
The Key ID field is defined as an OCTET string in IKE. For this name
|
|||
|
type, only exact-match syntax MUST be supported (since there is no
|
|||
|
explicit structure for this ID type). Additional matching functions
|
|||
|
MAY be supported for this ID type.
|
|||
|
|
|||
|
4.4.3.2. IKE Peer Authentication Data
|
|||
|
|
|||
|
Once an entry is located based on an ordered search of the PAD based
|
|||
|
on ID field matching, it is necessary to verify the asserted
|
|||
|
identity, i.e., to authenticate the asserted ID. For each PAD entry,
|
|||
|
there is an indication of the type of authentication to be performed.
|
|||
|
This document requires support for two required authentication data
|
|||
|
types:
|
|||
|
|
|||
|
- X.509 certificate
|
|||
|
- pre-shared secret
|
|||
|
|
|||
|
For authentication based on an X.509 certificate, the PAD entry
|
|||
|
contains a trust anchor via which the end entity (EE) certificate for
|
|||
|
the peer must be verifiable, either directly or via a certificate
|
|||
|
path. See RFC 3280 for the definition of a trust anchor. An entry
|
|||
|
used with certificate-based authentication MAY include additional
|
|||
|
data to facilitate certificate revocation status, e.g., a list of
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 45]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
appropriate OCSP responders or CRL repositories, and associated
|
|||
|
authentication data. For authentication based on a pre-shared
|
|||
|
secret, the PAD contains the pre-shared secret to be used by IKE.
|
|||
|
|
|||
|
This document does not require that the IKE ID asserted by a peer be
|
|||
|
syntactically related to a specific field in an end entity
|
|||
|
certificate that is employed to authenticate the identity of that
|
|||
|
peer. However, it often will be appropriate to impose such a
|
|||
|
requirement, e.g., when a single entry represents a set of peers each
|
|||
|
of whom may have a distinct SPD entry. Thus, implementations MUST
|
|||
|
provide a means for an administrator to require a match between an
|
|||
|
asserted IKE ID and the subject name or subject alt name in a
|
|||
|
certificate. The former is applicable to IKE IDs expressed as
|
|||
|
distinguished names; the latter is appropriate for DNS names, RFC 822
|
|||
|
e-mail addresses, and IP addresses. Since KEY ID is intended for
|
|||
|
identifying a peer authenticated via a pre-shared secret, there is no
|
|||
|
requirement to match this ID type to a certificate field.
|
|||
|
|
|||
|
See IKEv1 [HarCar98] and IKEv2 [Kau05] for details of how IKE
|
|||
|
performs peer authentication using certificates or pre-shared
|
|||
|
secrets.
|
|||
|
|
|||
|
This document does not mandate support for any other authentication
|
|||
|
methods, although such methods MAY be employed.
|
|||
|
|
|||
|
4.4.3.3. Child SA Authorization Data
|
|||
|
|
|||
|
Once an IKE peer is authenticated, child SAs may be created. Each
|
|||
|
PAD entry contains data to constrain the set of IDs that can be
|
|||
|
asserted by an IKE peer, for matching against the SPD. Each PAD
|
|||
|
entry indicates whether the IKE ID is to be used as a symbolic name
|
|||
|
for SPD matching, or whether an IP address asserted in a traffic
|
|||
|
selector payload is to be used.
|
|||
|
|
|||
|
If the entry indicates that the IKE ID is to be used, then the PAD
|
|||
|
entry ID field defines the authorized set of IDs. If the entry
|
|||
|
indicates that child SAs traffic selectors are to be used, then an
|
|||
|
additional data element is required, in the form of IPv4 and/or IPv6
|
|||
|
address ranges. (A peer may be authorized for both address types, so
|
|||
|
there MUST be provision for both a v4 and a v6 address range.)
|
|||
|
|
|||
|
4.4.3.4. How the PAD Is Used
|
|||
|
|
|||
|
During the initial IKE exchange, the initiator and responder each
|
|||
|
assert their identity via the IKE ID payload and send an AUTH payload
|
|||
|
to verify the asserted identity. One or more CERT payloads may be
|
|||
|
transmitted to facilitate the verification of each asserted identity.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 46]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
When an IKE entity receives an IKE ID payload, it uses the asserted
|
|||
|
ID to locate an entry in the PAD, using the matching rules described
|
|||
|
above. The PAD entry specifies the authentication method to be
|
|||
|
employed for the identified peer. This ensures that the right method
|
|||
|
is used for each peer and that different methods can be used for
|
|||
|
different peers. The entry also specifies the authentication data
|
|||
|
that will be used to verify the asserted identity. This data is
|
|||
|
employed in conjunction with the specified method to authenticate the
|
|||
|
peer, before any CHILD SAs are created.
|
|||
|
|
|||
|
Child SAs are created based on the exchange of traffic selector
|
|||
|
payloads, either at the end of the initial IKE exchange or in
|
|||
|
subsequent CREATE_CHILD_SA exchanges. The PAD entry for the (now
|
|||
|
authenticated) IKE peer is used to constrain creation of child SAs;
|
|||
|
specifically, the PAD entry specifies how the SPD is searched using a
|
|||
|
traffic selector proposal from a peer. There are two choices: either
|
|||
|
the IKE ID asserted by the peer is used to find an SPD entry via its
|
|||
|
symbolic name, or peer IP addresses asserted in traffic selector
|
|||
|
payloads are used for SPD lookups based on the remote IP address
|
|||
|
field portion of an SPD entry. It is necessary to impose these
|
|||
|
constraints on creation of child SAs to prevent an authenticated peer
|
|||
|
from spoofing IDs associated with other, legitimate peers.
|
|||
|
|
|||
|
Note that because the PAD is checked before searching for an SPD
|
|||
|
entry, this safeguard protects an initiator against spoofing attacks.
|
|||
|
For example, assume that IKE A receives an outbound packet destined
|
|||
|
for IP address X, a host served by a security gateway. RFC 2401
|
|||
|
[RFC2401] and this document do not specify how A determines the
|
|||
|
address of the IKE peer serving X. However, any peer contacted by A
|
|||
|
as the presumed representative for X must be registered in the PAD in
|
|||
|
order to allow the IKE exchange to be authenticated. Moreover, when
|
|||
|
the authenticated peer asserts that it represents X in its traffic
|
|||
|
selector exchange, the PAD will be consulted to determine if the peer
|
|||
|
in question is authorized to represent X. Thus, the PAD provides a
|
|||
|
binding of address ranges (or name sub-spaces) to peers, to counter
|
|||
|
such attacks.
|
|||
|
|
|||
|
4.5. SA and Key Management
|
|||
|
|
|||
|
All IPsec implementations MUST support both manual and automated SA
|
|||
|
and cryptographic key management. The IPsec protocols, AH and ESP,
|
|||
|
are largely independent of the associated SA management techniques,
|
|||
|
although the techniques involved do affect some of the security
|
|||
|
services offered by the protocols. For example, the optional
|
|||
|
anti-replay service available for AH and ESP requires automated SA
|
|||
|
management. Moreover, the granularity of key distribution employed
|
|||
|
with IPsec determines the granularity of authentication provided. In
|
|||
|
general, data origin authentication in AH and ESP is limited by the
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 47]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
extent to which secrets used with the integrity algorithm (or with a
|
|||
|
key management protocol that creates such secrets) are shared among
|
|||
|
multiple possible sources.
|
|||
|
|
|||
|
The following text describes the minimum requirements for both types
|
|||
|
of SA management.
|
|||
|
|
|||
|
4.5.1. Manual Techniques
|
|||
|
|
|||
|
The simplest form of management is manual management, in which a
|
|||
|
person manually configures each system with keying material and SA
|
|||
|
management data relevant to secure communication with other systems.
|
|||
|
Manual techniques are practical in small, static environments but
|
|||
|
they do not scale well. For example, a company could create a
|
|||
|
virtual private network (VPN) using IPsec in security gateways at
|
|||
|
several sites. If the number of sites is small, and since all the
|
|||
|
sites come under the purview of a single administrative domain, this
|
|||
|
might be a feasible context for manual management techniques. In
|
|||
|
this case, the security gateway might selectively protect traffic to
|
|||
|
and from other sites within the organization using a manually
|
|||
|
configured key, while not protecting traffic for other destinations.
|
|||
|
It also might be appropriate when only selected communications need
|
|||
|
to be secured. A similar argument might apply to use of IPsec
|
|||
|
entirely within an organization for a small number of hosts and/or
|
|||
|
gateways. Manual management techniques often employ statically
|
|||
|
configured, symmetric keys, though other options also exist.
|
|||
|
|
|||
|
4.5.2. Automated SA and Key Management
|
|||
|
|
|||
|
Widespread deployment and use of IPsec requires an Internet-standard,
|
|||
|
scalable, automated, SA management protocol. Such support is
|
|||
|
required to facilitate use of the anti-replay features of AH and ESP,
|
|||
|
and to accommodate on-demand creation of SAs, e.g., for user- and
|
|||
|
session-oriented keying. (Note that the notion of "rekeying" an SA
|
|||
|
actually implies creation of a new SA with a new SPI, a process that
|
|||
|
generally implies use of an automated SA/key management protocol.)
|
|||
|
|
|||
|
The default automated key management protocol selected for use with
|
|||
|
IPsec is IKEv2 [Kau05]. This document assumes the availability of
|
|||
|
certain functions from the key management protocol that are not
|
|||
|
supported by IKEv1. Other automated SA management protocols MAY be
|
|||
|
employed.
|
|||
|
|
|||
|
When an automated SA/key management protocol is employed, the output
|
|||
|
from this protocol is used to generate multiple keys for a single SA.
|
|||
|
This also occurs because distinct keys are used for each of the two
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 48]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
SAs created by IKE. If both integrity and confidentiality are
|
|||
|
employed, then a minimum of four keys are required. Additionally,
|
|||
|
some cryptographic algorithms may require multiple keys, e.g., 3DES.
|
|||
|
|
|||
|
The Key Management System may provide a separate string of bits for
|
|||
|
each key or it may generate one string of bits from which all keys
|
|||
|
are extracted. If a single string of bits is provided, care needs to
|
|||
|
be taken to ensure that the parts of the system that map the string
|
|||
|
of bits to the required keys do so in the same fashion at both ends
|
|||
|
of the SA. To ensure that the IPsec implementations at each end of
|
|||
|
the SA use the same bits for the same keys, and irrespective of which
|
|||
|
part of the system divides the string of bits into individual keys,
|
|||
|
the encryption keys MUST be taken from the first (left-most,
|
|||
|
high-order) bits and the integrity keys MUST be taken from the
|
|||
|
remaining bits. The number of bits for each key is defined in the
|
|||
|
relevant cryptographic algorithm specification RFC. In the case of
|
|||
|
multiple encryption keys or multiple integrity keys, the
|
|||
|
specification for the cryptographic algorithm must specify the order
|
|||
|
in which they are to be selected from a single string of bits
|
|||
|
provided to the cryptographic algorithm.
|
|||
|
|
|||
|
4.5.3. Locating a Security Gateway
|
|||
|
|
|||
|
This section discusses issues relating to how a host learns about the
|
|||
|
existence of relevant security gateways and, once a host has
|
|||
|
contacted these security gateways, how it knows that these are the
|
|||
|
correct security gateways. The details of where the required
|
|||
|
information is stored is a local matter, but the Peer Authorization
|
|||
|
Database (PAD) described in Section 4.4 is the most likely candidate.
|
|||
|
(Note: S* indicates a system that is running IPsec, e.g., SH1 and SG2
|
|||
|
below.)
|
|||
|
|
|||
|
Consider a situation in which a remote host (SH1) is using the
|
|||
|
Internet to gain access to a server or other machine (H2) and there
|
|||
|
is a security gateway (SG2), e.g., a firewall, through which H1's
|
|||
|
traffic must pass. An example of this situation would be a mobile
|
|||
|
host crossing the Internet to his home organization's firewall (SG2).
|
|||
|
This situation raises several issues:
|
|||
|
|
|||
|
1. How does SH1 know/learn about the existence of the security
|
|||
|
gateway SG2?
|
|||
|
|
|||
|
2. How does it authenticate SG2, and once it has authenticated SG2,
|
|||
|
how does it confirm that SG2 has been authorized to represent H2?
|
|||
|
|
|||
|
3. How does SG2 authenticate SH1 and verify that SH1 is authorized to
|
|||
|
contact H2?
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 49]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
4. How does SH1 know/learn about any additional gateways that provide
|
|||
|
alternate paths to H2?
|
|||
|
|
|||
|
To address these problems, an IPsec-supporting host or security
|
|||
|
gateway MUST have an administrative interface that allows the
|
|||
|
user/administrator to configure the address of one or more security
|
|||
|
gateways for ranges of destination addresses that require its use.
|
|||
|
This includes the ability to configure information for locating and
|
|||
|
authenticating one or more security gateways and verifying the
|
|||
|
authorization of these gateways to represent the destination host.
|
|||
|
(The authorization function is implied in the PAD.) This document
|
|||
|
does not address the issue of how to automate the
|
|||
|
discovery/verification of security gateways.
|
|||
|
|
|||
|
4.6. SAs and Multicast
|
|||
|
|
|||
|
The receiver-orientation of the SA implies that, in the case of
|
|||
|
unicast traffic, the destination system will select the SPI value.
|
|||
|
By having the destination select the SPI value, there is no potential
|
|||
|
for manually configured SAs to conflict with automatically configured
|
|||
|
(e.g., via a key management protocol) SAs or for SAs from multiple
|
|||
|
sources to conflict with each other. For multicast traffic, there
|
|||
|
are multiple destination systems associated with a single SA. So
|
|||
|
some system or person will need to coordinate among all multicast
|
|||
|
groups to select an SPI or SPIs on behalf of each multicast group and
|
|||
|
then communicate the group's IPsec information to all of the
|
|||
|
legitimate members of that multicast group via mechanisms not defined
|
|||
|
here.
|
|||
|
|
|||
|
Multiple senders to a multicast group SHOULD use a single Security
|
|||
|
Association (and hence SPI) for all traffic to that group when a
|
|||
|
symmetric key encryption or integrity algorithm is employed. In such
|
|||
|
circumstances, the receiver knows only that the message came from a
|
|||
|
system possessing the key for that multicast group. In such
|
|||
|
circumstances, a receiver generally will not be able to authenticate
|
|||
|
which system sent the multicast traffic. Specifications for other,
|
|||
|
more general multicast approaches are deferred to the IETF Multicast
|
|||
|
Security Working Group.
|
|||
|
|
|||
|
5. IP Traffic Processing
|
|||
|
|
|||
|
As mentioned in Section 4.4.1, "The Security Policy Database (SPD)",
|
|||
|
the SPD (or associated caches) MUST be consulted during the
|
|||
|
processing of all traffic that crosses the IPsec protection boundary,
|
|||
|
including IPsec management traffic. If no policy is found in the SPD
|
|||
|
that matches a packet (for either inbound or outbound traffic), the
|
|||
|
packet MUST be discarded. To simplify processing, and to allow for
|
|||
|
very fast SA lookups (for SG/BITS/BITW), this document introduces the
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 50]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
notion of an SPD cache for all outbound traffic (SPD-O plus SPD-S),
|
|||
|
and a cache for inbound, non-IPsec-protected traffic (SPD-I). (As
|
|||
|
mentioned earlier, the SAD acts as a cache for checking the selectors
|
|||
|
of inbound IPsec-protected traffic arriving on SAs.) There is
|
|||
|
nominally one cache per SPD. For the purposes of this specification,
|
|||
|
it is assumed that each cached entry will map to exactly one SA.
|
|||
|
Note, however, exceptions arise when one uses multiple SAs to carry
|
|||
|
traffic of different priorities (e.g., as indicated by distinct DSCP
|
|||
|
values) but the same 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 this document 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.
|
|||
|
|
|||
|
Since SPD entries may overlap, one cannot safely cache these entries
|
|||
|
in general. Simple caching might result in a match against a cache
|
|||
|
entry, whereas an ordered search of the SPD would have resulted in a
|
|||
|
match against a different entry. But, if the SPD entries are first
|
|||
|
decorrelated, then the resulting entries can safely be cached. Each
|
|||
|
cached entry will indicate that matching traffic should be bypassed
|
|||
|
or discarded, appropriately. (Note: The original SPD entry might
|
|||
|
result in multiple SAs, e.g., because of PFP.) Unless otherwise
|
|||
|
noted, all references below to the "SPD" or "SPD cache" or "cache"
|
|||
|
are to a decorrelated SPD (SPD-I, SPD-O, SPD-S) or the SPD cache
|
|||
|
containing entries from the decorrelated SPD.
|
|||
|
|
|||
|
Note: In a host IPsec implementation based on sockets, the SPD will
|
|||
|
be consulted whenever a new socket is created to determine what, if
|
|||
|
any, IPsec processing will be applied to the traffic that will flow
|
|||
|
on that socket. This provides an implicit caching mechanism, and the
|
|||
|
portions of the preceding discussion that address caching can be
|
|||
|
ignored in such implementations.
|
|||
|
|
|||
|
Note: It is assumed that one starts with a correlated SPD because
|
|||
|
that is how users and administrators are accustomed to managing these
|
|||
|
sorts of access control lists or firewall filter rules. Then the
|
|||
|
decorrelation algorithm is applied to build a list of cache-able SPD
|
|||
|
entries. The decorrelation is invisible at the management interface.
|
|||
|
|
|||
|
For inbound IPsec traffic, the SAD entry selected by the SPI serves
|
|||
|
as the cache for the selectors to be matched against arriving IPsec
|
|||
|
packets, after AH or ESP processing has been performed.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 51]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
5.1. Outbound IP Traffic Processing (protected-to-unprotected)
|
|||
|
|
|||
|
First consider the path for traffic entering the implementation via a
|
|||
|
protected interface and exiting via an unprotected interface.
|
|||
|
|
|||
|
Unprotected Interface
|
|||
|
^
|
|||
|
|
|
|||
|
(nested SAs) +----------+
|
|||
|
-------------------|Forwarding|<-----+
|
|||
|
| +----------+ |
|
|||
|
| ^ |
|
|||
|
| | BYPASS |
|
|||
|
V +-----+ |
|
|||
|
+-------+ | SPD | +--------+
|
|||
|
...| SPD-I |.................|Cache|.....|PROCESS |...IPsec
|
|||
|
| (*) | | (*) |---->|(AH/ESP)| boundary
|
|||
|
+-------+ +-----+ +--------+
|
|||
|
| +-------+ / ^
|
|||
|
| |DISCARD| <--/ |
|
|||
|
| +-------+ |
|
|||
|
| |
|
|||
|
| +-------------+
|
|||
|
|---------------->|SPD Selection|
|
|||
|
+-------------+
|
|||
|
^
|
|||
|
| +------+
|
|||
|
| -->| ICMP |
|
|||
|
| / +------+
|
|||
|
|/
|
|||
|
|
|
|||
|
|
|
|||
|
Protected Interface
|
|||
|
|
|||
|
|
|||
|
Figure 2. Processing Model for Outbound Traffic
|
|||
|
(*) = The SPD caches are shown here. If there
|
|||
|
is a cache miss, then the SPD is checked.
|
|||
|
There is no requirement that an
|
|||
|
implementation buffer the packet if
|
|||
|
there is a cache miss.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 52]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
IPsec MUST perform the following steps when processing outbound
|
|||
|
packets:
|
|||
|
|
|||
|
1. When a packet arrives from the subscriber (protected) interface,
|
|||
|
invoke the SPD selection function to obtain the SPD-ID needed to
|
|||
|
choose the appropriate SPD. (If the implementation uses only one
|
|||
|
SPD, this step is a no-op.)
|
|||
|
|
|||
|
2. Match the packet headers against the cache for the SPD specified
|
|||
|
by the SPD-ID from step 1. Note that this cache contains entries
|
|||
|
from SPD-O and SPD-S.
|
|||
|
|
|||
|
3a. If there is a match, then process the packet as specified by the
|
|||
|
matching cache entry, i.e., BYPASS, DISCARD, or PROTECT using AH
|
|||
|
or ESP. If IPsec processing is applied, there is a link from the
|
|||
|
SPD cache entry to the relevant SAD entry (specifying the mode,
|
|||
|
cryptographic algorithms, keys, SPI, PMTU, etc.). IPsec
|
|||
|
processing is as previously defined, for tunnel or transport
|
|||
|
modes and for AH or ESP, as specified in their respective RFCs
|
|||
|
[Ken05b, Ken05a]. Note that the SA PMTU value, plus the value of
|
|||
|
the stateful fragment checking flag (and the DF bit in the IP
|
|||
|
header of the outbound packet) determine whether the packet can
|
|||
|
(must) be fragmented prior to or after IPsec processing, or if it
|
|||
|
must be discarded and an ICMP PMTU message is sent.
|
|||
|
|
|||
|
3b. If no match is found in the cache, search the SPD (SPD-S and
|
|||
|
SPD-O parts) specified by SPD-ID. If the SPD entry calls for
|
|||
|
BYPASS or DISCARD, create one or more new outbound SPD cache
|
|||
|
entries and if BYPASS, create one or more new inbound SPD cache
|
|||
|
entries. (More than one cache entry may be created since a
|
|||
|
decorrelated SPD entry may be linked to other such entries that
|
|||
|
were created as a side effect of the decorrelation process.) If
|
|||
|
the SPD entry calls for PROTECT, i.e., creation of an SA, the key
|
|||
|
management mechanism (e.g., IKEv2) is invoked to create the SA.
|
|||
|
If SA creation succeeds, a new outbound (SPD-S) cache entry is
|
|||
|
created, along with outbound and inbound SAD entries, otherwise
|
|||
|
the packet is discarded. (A packet that triggers an SPD lookup
|
|||
|
MAY be discarded by the implementation, or it MAY be processed
|
|||
|
against the newly created cache entry, if one is created.) Since
|
|||
|
SAs are created in pairs, an SAD entry for the corresponding
|
|||
|
inbound SA also is created, and it contains the selector values
|
|||
|
derived from the SPD entry (and packet, if any PFP flags were
|
|||
|
"true") used to create the inbound SA, for use in checking
|
|||
|
inbound traffic delivered via the SA.
|
|||
|
|
|||
|
4. The packet is passed to the outbound forwarding function
|
|||
|
(operating outside of the IPsec implementation), to select the
|
|||
|
interface to which the packet will be directed. This function
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 53]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
may cause the packet to be passed back across the IPsec boundary,
|
|||
|
for additional IPsec processing, e.g., in support of nested SAs.
|
|||
|
If so, there MUST be an entry in SPD-I database that permits
|
|||
|
inbound bypassing of the packet, otherwise the packet will be
|
|||
|
discarded. If necessary, i.e., if there is more than one SPD-I,
|
|||
|
the traffic being looped back MAY be tagged as coming from this
|
|||
|
internal interface. This would allow the use of a different
|
|||
|
SPD-I for "real" external traffic vs. looped traffic, if needed.
|
|||
|
|
|||
|
Note: With the exception of IPv4 and IPv6 transport mode, an SG,
|
|||
|
BITS, or BITW implementation MAY fragment packets before applying
|
|||
|
IPsec. (This applies only to IPv4. For IPv6 packets, only the
|
|||
|
originator is allowed to fragment them.) The device SHOULD have a
|
|||
|
configuration setting to disable this. The resulting fragments are
|
|||
|
evaluated against the SPD in the normal manner. Thus, fragments not
|
|||
|
containing port numbers (or ICMP message type and code, or Mobility
|
|||
|
Header type) will only match rules having port (or ICMP message type
|
|||
|
and code, or MH type) selectors of OPAQUE or ANY. (See Section 7 for
|
|||
|
more details.)
|
|||
|
|
|||
|
Note: With regard to determining and enforcing the PMTU of an SA, the
|
|||
|
IPsec system MUST follow the steps described in Section 8.2.
|
|||
|
|
|||
|
5.1.1. Handling an Outbound Packet That Must Be Discarded
|
|||
|
|
|||
|
If an IPsec system receives an outbound packet that it finds it must
|
|||
|
discard, it SHOULD be capable of generating and sending an ICMP
|
|||
|
message to indicate to the sender of the outbound packet that the
|
|||
|
packet was discarded. The type and code of the ICMP message will
|
|||
|
depend on the reason for discarding the packet, as specified below.
|
|||
|
The reason SHOULD be recorded in the audit log. The audit log entry
|
|||
|
for this event SHOULD include the reason, current date/time, and the
|
|||
|
selector values from the packet.
|
|||
|
|
|||
|
a. The selectors of the packet matched an SPD entry requiring the
|
|||
|
packet to be discarded.
|
|||
|
|
|||
|
IPv4 Type = 3 (destination unreachable) Code = 13
|
|||
|
(Communication Administratively Prohibited)
|
|||
|
|
|||
|
IPv6 Type = 1 (destination unreachable) Code = 1
|
|||
|
(Communication with destination administratively
|
|||
|
prohibited)
|
|||
|
|
|||
|
b1. The IPsec system successfully reached the remote peer but was
|
|||
|
unable to negotiate the SA required by the SPD entry matching the
|
|||
|
packet because, for example, the remote peer is administratively
|
|||
|
prohibited from communicating with the initiator, the initiating
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 54]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
peer was unable to authenticate itself to the remote peer, the
|
|||
|
remote peer was unable to authenticate itself to the initiating
|
|||
|
peer, or the SPD at the remote peer did not have a suitable
|
|||
|
entry.
|
|||
|
|
|||
|
IPv4 Type = 3 (destination unreachable) Code = 13
|
|||
|
(Communication Administratively Prohibited)
|
|||
|
|
|||
|
IPv6 Type = 1 (destination unreachable) Code = 1
|
|||
|
(Communication with destination administratively
|
|||
|
prohibited)
|
|||
|
|
|||
|
b2. The IPsec system was unable to set up the SA required by the SPD
|
|||
|
entry matching the packet because the IPsec peer at the other end
|
|||
|
of the exchange could not be contacted.
|
|||
|
|
|||
|
IPv4 Type = 3 (destination unreachable) Code = 1 (host
|
|||
|
unreachable)
|
|||
|
|
|||
|
IPv6 Type = 1 (destination unreachable) Code = 3 (address
|
|||
|
unreachable)
|
|||
|
|
|||
|
Note that an attacker behind a security gateway could send packets
|
|||
|
with a spoofed source address, W.X.Y.Z, to an IPsec entity causing it
|
|||
|
to send ICMP messages to W.X.Y.Z. This creates an opportunity for a
|
|||
|
denial of service (DoS) attack among hosts behind a security gateway.
|
|||
|
To address this, a security gateway SHOULD include a management
|
|||
|
control to allow an administrator to configure an IPsec
|
|||
|
implementation to send or not send the ICMP messages under these
|
|||
|
circumstances, and if this facility is selected, to rate limit the
|
|||
|
transmission of such ICMP responses.
|
|||
|
|
|||
|
5.1.2. Header Construction for Tunnel Mode
|
|||
|
|
|||
|
This section describes the handling of the inner and outer IP
|
|||
|
headers, extension headers, and options for AH and ESP tunnels, with
|
|||
|
regard to outbound traffic processing. This includes how to
|
|||
|
construct the encapsulating (outer) IP header, how to process fields
|
|||
|
in the inner IP header, and what other actions should be taken for
|
|||
|
outbound, tunnel mode traffic. The general processing described here
|
|||
|
is modeled after RFC 2003, "IP Encapsulation within IP" [Per96]:
|
|||
|
|
|||
|
o The outer IP header Source Address and Destination Address
|
|||
|
identify the "endpoints" of the tunnel (the encapsulator and
|
|||
|
decapsulator). The inner IP header Source Address and Destination
|
|||
|
Addresses identify the original sender and recipient of the
|
|||
|
datagram (from the perspective of this tunnel), respectively.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 55]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
(See footnote 3 after the table in 5.1.2.1 for more details on the
|
|||
|
encapsulating source IP address.)
|
|||
|
|
|||
|
o The inner IP header is not changed except as noted below for TTL
|
|||
|
(or Hop Limit) and the DS/ECN Fields. The inner IP header
|
|||
|
otherwise remains unchanged during its delivery to the tunnel exit
|
|||
|
point.
|
|||
|
|
|||
|
o No change to IP options or extension headers in the inner header
|
|||
|
occurs during delivery of the encapsulated datagram through the
|
|||
|
tunnel.
|
|||
|
|
|||
|
Note: IPsec tunnel mode is different from IP-in-IP tunneling (RFC
|
|||
|
2003 [Per96]) in several ways:
|
|||
|
|
|||
|
o IPsec offers certain controls to a security administrator to
|
|||
|
manage covert channels (which would not normally be a concern for
|
|||
|
tunneling) and to ensure that the receiver examines the right
|
|||
|
portions of the received packet with respect to application of
|
|||
|
access controls. An IPsec implementation MAY be configurable with
|
|||
|
regard to how it processes the outer DS field for tunnel mode for
|
|||
|
transmitted packets. For outbound traffic, one configuration
|
|||
|
setting for the outer DS field will operate as described in the
|
|||
|
following sections on IPv4 and IPv6 header processing for IPsec
|
|||
|
tunnels. Another will allow the outer DS field to be mapped to a
|
|||
|
fixed value, which MAY be configured on a per-SA basis. (The value
|
|||
|
might really be fixed for all traffic outbound from a device, but
|
|||
|
per-SA granularity allows that as well.) This configuration option
|
|||
|
allows a local administrator to decide whether the covert channel
|
|||
|
provided by copying these bits outweighs the benefits of copying.
|
|||
|
|
|||
|
o IPsec describes how to handle ECN or DS and provides the ability
|
|||
|
to control propagation of changes in these fields between
|
|||
|
unprotected and protected domains. In general, propagation from a
|
|||
|
protected to an unprotected domain is a covert channel and thus
|
|||
|
controls are provided to manage the bandwidth of this channel.
|
|||
|
Propagation of ECN values in the other direction are controlled so
|
|||
|
that only legitimate ECN changes (indicating occurrence of
|
|||
|
congestion between the tunnel endpoints) are propagated. By
|
|||
|
default, DS propagation from an unprotected domain to a protected
|
|||
|
domain is not permitted. However, if the sender and receiver do
|
|||
|
not share the same DS code space, and the receiver has no way of
|
|||
|
learning how to map between the two spaces, then it may be
|
|||
|
appropriate to deviate from the default. Specifically, an IPsec
|
|||
|
implementation MAY be configurable in terms of how it processes
|
|||
|
the outer DS field for tunnel mode for received packets. It may
|
|||
|
be configured to either discard the outer DS value (the default)
|
|||
|
OR to overwrite the inner DS field with the outer DS field. If
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 56]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
offered, the discard vs. overwrite behavior MAY be configured on a
|
|||
|
per-SA basis. This configuration option allows a local
|
|||
|
administrator to decide whether the vulnerabilities created by
|
|||
|
copying these bits outweigh the benefits of copying. See
|
|||
|
[RFC2983] for further information on when each of these behaviors
|
|||
|
may be useful, and also for the possible need for diffserv traffic
|
|||
|
conditioning prior or subsequent to IPsec processing (including
|
|||
|
tunnel decapsulation).
|
|||
|
|
|||
|
o IPsec allows the IP version of the encapsulating header to be
|
|||
|
different from that of the inner header.
|
|||
|
|
|||
|
The tables in the following sub-sections show the handling for the
|
|||
|
different header/option fields ("constructed" means that the value in
|
|||
|
the outer field is constructed independently of the value in the
|
|||
|
inner).
|
|||
|
|
|||
|
5.1.2.1. IPv4: Header Construction for Tunnel Mode
|
|||
|
|
|||
|
<-- How Outer Hdr Relates to Inner Hdr -->
|
|||
|
Outer Hdr at Inner Hdr at
|
|||
|
IPv4 Encapsulator Decapsulator
|
|||
|
Header fields: -------------------- ------------
|
|||
|
version 4 (1) no change
|
|||
|
header length constructed no change
|
|||
|
DS Field copied from inner hdr (5) no change
|
|||
|
ECN Field copied from inner hdr constructed (6)
|
|||
|
total length constructed no change
|
|||
|
ID constructed no change
|
|||
|
flags (DF,MF) constructed, DF (4) no change
|
|||
|
fragment offset constructed no change
|
|||
|
TTL constructed (2) decrement (2)
|
|||
|
protocol AH, ESP no change
|
|||
|
checksum constructed constructed (2)(6)
|
|||
|
src address constructed (3) no change
|
|||
|
dest address constructed (3) no change
|
|||
|
Options never copied no change
|
|||
|
|
|||
|
Notes:
|
|||
|
|
|||
|
(1) The IP version in the encapsulating header can be different
|
|||
|
from the value in the inner header.
|
|||
|
|
|||
|
(2) The TTL in the inner header is decremented by the encapsulator
|
|||
|
prior to forwarding and by the decapsulator if it forwards the
|
|||
|
packet. (The IPv4 checksum changes when the TTL changes.)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 57]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
Note: Decrementing the TTL value is a normal part of
|
|||
|
forwarding a packet. Thus, a packet originating from the same
|
|||
|
node as the encapsulator does not have its TTL decremented,
|
|||
|
since the sending node is originating the packet rather than
|
|||
|
forwarding it. This applies to BITS and native IPsec
|
|||
|
implementations in hosts and routers. However, the IPsec
|
|||
|
processing model includes an external forwarding capability.
|
|||
|
TTL processing can be used to prevent looping of packets,
|
|||
|
e.g., due to configuration errors, within the context of this
|
|||
|
processing model.
|
|||
|
|
|||
|
(3) Local and Remote addresses depend on the SA, which is used to
|
|||
|
determine the Remote address, which in turn determines which
|
|||
|
Local address (net interface) is used to forward the packet.
|
|||
|
|
|||
|
Note: For multicast traffic, the destination address, or
|
|||
|
source and destination addresses, may be required for
|
|||
|
demuxing. In that case, it is important to ensure consistency
|
|||
|
over the lifetime of the SA by ensuring that the source
|
|||
|
address that appears in the encapsulating tunnel header is the
|
|||
|
same as the one that was negotiated during the SA
|
|||
|
establishment process. There is an exception to this general
|
|||
|
rule, i.e., a mobile IPsec implementation will update its
|
|||
|
source address as it moves.
|
|||
|
|
|||
|
(4) Configuration determines whether to copy from the inner header
|
|||
|
(IPv4 only), clear, or set the DF.
|
|||
|
|
|||
|
(5) If the packet will immediately enter a domain for which the
|
|||
|
DSCP value in the outer header is not appropriate, that value
|
|||
|
MUST be mapped to an appropriate value for the domain
|
|||
|
[NiBlBaBL98]. See RFC 2475 [BBCDWW98] for further
|
|||
|
information.
|
|||
|
|
|||
|
(6) If the ECN field in the inner header is set to ECT(0) or
|
|||
|
ECT(1), where ECT is ECN-Capable Transport (ECT), and if the
|
|||
|
ECN field in the outer header is set to Congestion Experienced
|
|||
|
(CE), then set the ECN field in the inner header to CE;
|
|||
|
otherwise, make no change to the ECN field in the inner
|
|||
|
header. (The IPv4 checksum changes when the ECN changes.)
|
|||
|
|
|||
|
Note: IPsec does not copy the options from the inner header into the
|
|||
|
outer header, nor does IPsec construct the options in the outer
|
|||
|
header. However, post-IPsec code MAY insert/construct options for
|
|||
|
the outer header.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 58]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
5.1.2.2. IPv6: Header Construction for Tunnel Mode
|
|||
|
|
|||
|
<-- How Outer Hdr Relates Inner Hdr --->
|
|||
|
Outer Hdr at Inner Hdr at
|
|||
|
IPv6 Encapsulator Decapsulator
|
|||
|
Header fields: -------------------- ------------
|
|||
|
version 6 (1) no change
|
|||
|
DS Field copied from inner hdr (5) no change (9)
|
|||
|
ECN Field copied from inner hdr constructed (6)
|
|||
|
flow label copied or configured (8) no change
|
|||
|
payload length constructed no change
|
|||
|
next header AH,ESP,routing hdr no change
|
|||
|
hop limit constructed (2) decrement (2)
|
|||
|
src address constructed (3) no change
|
|||
|
dest address constructed (3) no change
|
|||
|
Extension headers never copied (7) no change
|
|||
|
|
|||
|
Notes:
|
|||
|
|
|||
|
(1) - (6) See Section 5.1.2.1.
|
|||
|
|
|||
|
(7) IPsec does not copy the extension headers from the inner
|
|||
|
packet into outer headers, nor does IPsec construct extension
|
|||
|
headers in the outer header. However, post-IPsec code MAY
|
|||
|
insert/construct extension headers for the outer header.
|
|||
|
|
|||
|
(8) See [RaCoCaDe04]. Copying is acceptable only for end systems,
|
|||
|
not SGs. If an SG copied flow labels from the inner header to
|
|||
|
the outer header, collisions might result.
|
|||
|
|
|||
|
(9) An implementation MAY choose to provide a facility to pass the
|
|||
|
DS value from the outer header to the inner header, on a per-
|
|||
|
SA basis, for received tunnel mode packets. The motivation
|
|||
|
for providing this feature is to accommodate situations in
|
|||
|
which the DS code space at the receiver is different from that
|
|||
|
of the sender and the receiver has no way of knowing how to
|
|||
|
translate from the sender's space. There is a danger in
|
|||
|
copying this value from the outer header to the inner header,
|
|||
|
since it enables an attacker to modify the outer DSCP value in
|
|||
|
a fashion that may adversely affect other traffic at the
|
|||
|
receiver. Hence the default behavior for IPsec
|
|||
|
implementations is NOT to permit such copying.
|
|||
|
|
|||
|
5.2. Processing Inbound IP Traffic (unprotected-to-protected)
|
|||
|
|
|||
|
Inbound processing is somewhat different from outbound processing,
|
|||
|
because of the use of SPIs to map IPsec-protected traffic to SAs.
|
|||
|
The inbound SPD cache (SPD-I) is applied only to bypassed or
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 59]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
discarded traffic. If an arriving packet appears to be an IPsec
|
|||
|
fragment from an unprotected interface, reassembly is performed prior
|
|||
|
to IPsec processing. The intent for any SPD cache is that a packet
|
|||
|
that fails to match any entry is then referred to the corresponding
|
|||
|
SPD. Every SPD SHOULD have a nominal, final entry that catches
|
|||
|
anything that is otherwise unmatched, and discards it. This ensures
|
|||
|
that non-IPsec-protected traffic that arrives and does not match any
|
|||
|
SPD-I entry will be discarded.
|
|||
|
|
|||
|
Unprotected Interface
|
|||
|
|
|
|||
|
V
|
|||
|
+-----+ IPsec protected
|
|||
|
------------------->|Demux|-------------------+
|
|||
|
| +-----+ |
|
|||
|
| | |
|
|||
|
| Not IPsec | |
|
|||
|
| | |
|
|||
|
| V |
|
|||
|
| +-------+ +---------+ |
|
|||
|
| |DISCARD|<---|SPD-I (*)| |
|
|||
|
| +-------+ +---------+ |
|
|||
|
| | |
|
|||
|
| |-----+ |
|
|||
|
| | | |
|
|||
|
| | V |
|
|||
|
| | +------+ |
|
|||
|
| | | ICMP | |
|
|||
|
| | +------+ |
|
|||
|
| | V
|
|||
|
+---------+ | +-----------+
|
|||
|
....|SPD-O (*)|............|...................|PROCESS(**)|...IPsec
|
|||
|
+---------+ | | (AH/ESP) | Boundary
|
|||
|
^ | +-----------+
|
|||
|
| | +---+ |
|
|||
|
| BYPASS | +-->|IKE| |
|
|||
|
| | | +---+ |
|
|||
|
| V | V
|
|||
|
| +----------+ +---------+ +----+
|
|||
|
|--------<------|Forwarding|<---------|SAD Check|-->|ICMP|
|
|||
|
nested SAs +----------+ | (***) | +----+
|
|||
|
| +---------+
|
|||
|
V
|
|||
|
Protected Interface
|
|||
|
|
|||
|
Figure 3. Processing Model for Inbound Traffic
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 60]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
(*) = The caches are shown here. If there is
|
|||
|
a cache miss, then the SPD is checked.
|
|||
|
There is no requirement that an
|
|||
|
implementation buffer the packet if
|
|||
|
there is a cache miss.
|
|||
|
(**) = This processing includes using the
|
|||
|
packet's SPI, etc., to look up the SA
|
|||
|
in the SAD, which forms a cache of the
|
|||
|
SPD for inbound packets (except for
|
|||
|
cases noted in Sections 4.4.2 and 5).
|
|||
|
See step 3a below.
|
|||
|
(***) = This SAD check refers to step 4 below.
|
|||
|
|
|||
|
Prior to performing AH or ESP processing, any IP fragments that
|
|||
|
arrive via the unprotected interface are reassembled (by IP). Each
|
|||
|
inbound IP datagram to which IPsec processing will be applied is
|
|||
|
identified by the appearance of the AH or ESP values in the IP Next
|
|||
|
Protocol field (or of AH or ESP as a next layer protocol in the IPv6
|
|||
|
context).
|
|||
|
|
|||
|
IPsec MUST perform the following steps:
|
|||
|
|
|||
|
1. When a packet arrives, it may be tagged with the ID of the
|
|||
|
interface (physical or virtual) via which it arrived, if
|
|||
|
necessary, to support multiple SPDs and associated SPD-I caches.
|
|||
|
(The interface ID is mapped to a corresponding SPD-ID.)
|
|||
|
|
|||
|
2. The packet is examined and demuxed into one of two categories:
|
|||
|
- If the packet appears to be IPsec protected and it is addressed
|
|||
|
to this device, an attempt is made to map it to an active SA
|
|||
|
via the SAD. Note that the device may have multiple IP
|
|||
|
addresses that may be used in the SAD lookup, e.g., in the case
|
|||
|
of protocols such as SCTP.
|
|||
|
- Traffic not addressed to this device, or addressed to this
|
|||
|
device and not AH or ESP, is directed to SPD-I lookup. (This
|
|||
|
implies that IKE traffic MUST have an explicit BYPASS entry in
|
|||
|
the SPD.) If multiple SPDs are employed, the tag assigned to
|
|||
|
the packet in step 1 is used to select the appropriate SPD-I
|
|||
|
(and cache) to search. SPD-I lookup determines whether the
|
|||
|
action is DISCARD or BYPASS.
|
|||
|
|
|||
|
3a. If the packet is addressed to the IPsec device and AH or ESP is
|
|||
|
specified as the protocol, the packet is looked up in the SAD.
|
|||
|
For unicast traffic, use only the SPI (or SPI plus protocol).
|
|||
|
For multicast traffic, use the SPI plus the destination or SPI
|
|||
|
plus destination and source addresses, as specified in Section
|
|||
|
4.1. In either case (unicast or multicast), if there is no match,
|
|||
|
discard the traffic. This is an auditable event. The audit log
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 61]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
entry for this event SHOULD include the current date/time, SPI,
|
|||
|
source and destination of the packet, IPsec protocol, and any
|
|||
|
other selector values of the packet that are available. If the
|
|||
|
packet is found in the SAD, process it accordingly (see step 4).
|
|||
|
|
|||
|
3b. If the packet is not addressed to the device or is addressed to
|
|||
|
this device and is not AH or ESP, look up the packet header in
|
|||
|
the (appropriate) SPD-I cache. If there is a match and the
|
|||
|
packet is to be discarded or bypassed, do so. If there is no
|
|||
|
cache match, look up the packet in the corresponding SPD-I and
|
|||
|
create a cache entry as appropriate. (No SAs are created in
|
|||
|
response to receipt of a packet that requires IPsec protection;
|
|||
|
only BYPASS or DISCARD cache entries can be created this way.) If
|
|||
|
there is no match, discard the traffic. This is an auditable
|
|||
|
event. The audit log entry for this event SHOULD include the
|
|||
|
current date/time, SPI if available, IPsec protocol if available,
|
|||
|
source and destination of the packet, and any other selector
|
|||
|
values of the packet that are available.
|
|||
|
|
|||
|
3c. Processing of ICMP messages is assumed to take place on the
|
|||
|
unprotected side of the IPsec boundary. Unprotected ICMP
|
|||
|
messages are examined and local policy is applied to determine
|
|||
|
whether to accept or reject these messages and, if accepted, what
|
|||
|
action to take as a result. For example, if an ICMP unreachable
|
|||
|
message is received, the implementation must decide whether to
|
|||
|
act on it, reject it, or act on it with constraints. (See Section
|
|||
|
6.)
|
|||
|
|
|||
|
4. Apply AH or ESP processing as specified, using the SAD entry
|
|||
|
selected in step 3a above. Then match the packet against the
|
|||
|
inbound selectors identified by the SAD entry to verify that the
|
|||
|
received packet is appropriate for the SA via which it was
|
|||
|
received.
|
|||
|
|
|||
|
5. If an IPsec system receives an inbound packet on an SA and the
|
|||
|
packet's header fields are not consistent with the selectors for
|
|||
|
the SA, it MUST discard the packet. This is an auditable event.
|
|||
|
The audit log entry for this event SHOULD include the current
|
|||
|
date/time, SPI, IPsec protocol(s), source and destination of the
|
|||
|
packet, any other selector values of the packet that are
|
|||
|
available, and the selector values from the relevant SAD entry.
|
|||
|
The system SHOULD also be capable of generating and sending an
|
|||
|
IKE notification of INVALID_SELECTORS to the sender (IPsec peer),
|
|||
|
indicating that the received packet was discarded because of
|
|||
|
failure to pass selector checks.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 62]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
To minimize the impact of a DoS attack, or a mis-configured peer, the
|
|||
|
IPsec system SHOULD include a management control to allow an
|
|||
|
administrator to configure the IPsec implementation to send or not
|
|||
|
send this IKE notification, and if this facility is selected, to rate
|
|||
|
limit the transmission of such notifications.
|
|||
|
|
|||
|
After traffic is bypassed or processed through IPsec, it is handed to
|
|||
|
the inbound forwarding function for disposition. This function may
|
|||
|
cause the packet to be sent (outbound) across the IPsec boundary for
|
|||
|
additional inbound IPsec processing, e.g., in support of nested SAs.
|
|||
|
If so, then as with ALL outbound traffic that is to be bypassed, the
|
|||
|
packet MUST be matched against an SPD-O entry. Ultimately, the
|
|||
|
packet should be forwarded to the destination host or process for
|
|||
|
disposition.
|
|||
|
|
|||
|
6. ICMP Processing
|
|||
|
|
|||
|
This section describes IPsec handling of ICMP traffic. There are two
|
|||
|
categories of ICMP traffic: error messages (e.g., type = destination
|
|||
|
unreachable) and non-error messages (e.g., type = echo). This
|
|||
|
section applies exclusively to error messages. Disposition of
|
|||
|
non-error, ICMP messages (that are not addressed to the IPsec
|
|||
|
implementation itself) MUST be explicitly accounted for using SPD
|
|||
|
entries.
|
|||
|
|
|||
|
The discussion in this section applies to ICMPv6 as well as to
|
|||
|
ICMPv4. Also, a mechanism SHOULD be provided to allow an
|
|||
|
administrator to cause ICMP error messages (selected, all, or none)
|
|||
|
to be logged as an aid to problem diagnosis.
|
|||
|
|
|||
|
6.1. Processing ICMP Error Messages Directed to an IPsec Implementation
|
|||
|
|
|||
|
6.1.1. ICMP Error Messages Received on the Unprotected Side of the
|
|||
|
Boundary
|
|||
|
|
|||
|
Figure 3 in Section 5.2 shows a distinct ICMP processing module on
|
|||
|
the unprotected side of the IPsec boundary, for processing ICMP
|
|||
|
messages (error or otherwise) that are addressed to the IPsec device
|
|||
|
and that are not protected via AH or ESP. An ICMP message of this
|
|||
|
sort is unauthenticated, and its processing may result in denial or
|
|||
|
degradation of service. This suggests that, in general, it would be
|
|||
|
desirable to ignore such messages. However, many ICMP messages will
|
|||
|
be received by hosts or security gateways from unauthenticated
|
|||
|
sources, e.g., routers in the public Internet. Ignoring these ICMP
|
|||
|
messages can degrade service, e.g., because of a failure to process
|
|||
|
PMTU message and redirection messages. Thus, there is also a
|
|||
|
motivation for accepting and acting upon unauthenticated ICMP
|
|||
|
messages.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 63]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
To accommodate both ends of this spectrum, a compliant IPsec
|
|||
|
implementation MUST permit a local administrator to configure an
|
|||
|
IPsec implementation to accept or reject unauthenticated ICMP
|
|||
|
traffic. This control MUST be at the granularity of ICMP type and
|
|||
|
MAY be at the granularity of ICMP type and code. Additionally, an
|
|||
|
implementation SHOULD incorporate mechanisms and parameters for
|
|||
|
dealing with such traffic. For example, there could be the ability
|
|||
|
to establish a minimum PMTU for traffic (on a per destination basis),
|
|||
|
to prevent receipt of an unauthenticated ICMP from setting the PMTU
|
|||
|
to a trivial size.
|
|||
|
|
|||
|
If an ICMP PMTU message passes the checks above and the system is
|
|||
|
configured to accept it, then there are two possibilities. If the
|
|||
|
implementation applies fragmentation on the ciphertext side of the
|
|||
|
boundary, then the accepted PMTU information is passed to the
|
|||
|
forwarding module (outside of the IPsec implementation), which uses
|
|||
|
it to manage outbound packet fragmentation. If the implementation is
|
|||
|
configured to effect plaintext side fragmentation, then the PMTU
|
|||
|
information is passed to the plaintext side and processed as
|
|||
|
described in Section 8.2.
|
|||
|
|
|||
|
6.1.2. ICMP Error Messages Received on the Protected Side of the
|
|||
|
Boundary
|
|||
|
|
|||
|
These ICMP messages are not authenticated, but they do come from
|
|||
|
sources on the protected side of the IPsec boundary. Thus, these
|
|||
|
messages generally are viewed as more "trustworthy" than their
|
|||
|
counterparts arriving from sources on the unprotected side of the
|
|||
|
boundary. The major security concern here is that a compromised host
|
|||
|
or router might emit erroneous ICMP error messages that could degrade
|
|||
|
service for other devices "behind" the security gateway, or that
|
|||
|
could even result in violations of confidentiality. For example, if
|
|||
|
a bogus ICMP redirect were consumed by a security gateway, it could
|
|||
|
cause the forwarding table on the protected side of the boundary to
|
|||
|
be modified so as to deliver traffic to an inappropriate destination
|
|||
|
"behind" the gateway. Thus, implementers MUST provide controls to
|
|||
|
allow local administrators to constrain the processing of ICMP error
|
|||
|
messages received on the protected side of the boundary, and directed
|
|||
|
to the IPsec implementation. These controls are of the same type as
|
|||
|
those employed on the unprotected side, described above in Section
|
|||
|
6.1.1.
|
|||
|
|
|||
|
6.2. Processing Protected, Transit ICMP Error Messages
|
|||
|
|
|||
|
When an ICMP error message is transmitted via an SA to a device
|
|||
|
"behind" an IPsec implementation, both the payload and the header of
|
|||
|
the ICMP message require checking from an access control perspective.
|
|||
|
If one of these messages is forwarded to a host behind a security
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 64]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
gateway, the receiving host IP implementation will make decisions
|
|||
|
based on the payload, i.e., the header of the packet that purportedly
|
|||
|
triggered the error response. Thus, an IPsec implementation MUST be
|
|||
|
configurable to check that this payload header information is
|
|||
|
consistent with the SA via which it arrives. (This means that the
|
|||
|
payload header, with source and destination address and port fields
|
|||
|
reversed, matches the traffic selectors for the SA.) If this sort of
|
|||
|
check is not performed, then, for example, anyone with whom the
|
|||
|
receiving IPsec system (A) has an active SA could send an ICMP
|
|||
|
Destination Unreachable message that refers to any host/net with
|
|||
|
which A is currently communicating, and thus effect a highly
|
|||
|
efficient DoS attack regarding communication with other peers of A.
|
|||
|
Normal IPsec receiver processing of traffic is not sufficient to
|
|||
|
protect against such attacks. However, not all contexts may require
|
|||
|
such checks, so it is also necessary to allow a local administrator
|
|||
|
to configure an implementation to NOT perform such checks.
|
|||
|
|
|||
|
To accommodate both policies, the following convention is adopted.
|
|||
|
If an administrator wants to allow ICMP error messages to be carried
|
|||
|
by an SA without inspection of the payload, then configure an SPD
|
|||
|
entry that explicitly allows for carriage of such traffic. If an
|
|||
|
administrator wants IPsec to check the payload of ICMP error messages
|
|||
|
for consistency, then do not create any SPD entries that accommodate
|
|||
|
carriage of such traffic based on the ICMP packet header. This
|
|||
|
convention motivates the following processing description.
|
|||
|
|
|||
|
IPsec senders and receivers MUST support the following processing for
|
|||
|
ICMP error messages that are sent and received via SAs.
|
|||
|
|
|||
|
If an SA exists that accommodates an outbound ICMP error message,
|
|||
|
then the message is mapped to the SA and only the IP and ICMP headers
|
|||
|
are checked upon receipt, just as would be the case for other
|
|||
|
traffic. If no SA exists that matches the traffic selectors
|
|||
|
associated with an ICMP error message, then the SPD is searched to
|
|||
|
determine if such an SA can be created. If so, the SA is created and
|
|||
|
the ICMP error message is transmitted via that SA. Upon receipt,
|
|||
|
this message is subject to the usual traffic selector checks at the
|
|||
|
receiver. This processing is exactly what would happen for traffic
|
|||
|
in general, and thus does not represent any special processing for
|
|||
|
ICMP error messages.
|
|||
|
|
|||
|
If no SA exists that would carry the outbound ICMP message in
|
|||
|
question, and if no SPD entry would allow carriage of this outbound
|
|||
|
ICMP error message, then an IPsec implementation MUST map the message
|
|||
|
to the SA that would carry the return traffic associated with the
|
|||
|
packet that triggered the ICMP error message. This requires an IPsec
|
|||
|
implementation to detect outbound ICMP error messages that map to no
|
|||
|
extant SA or SPD entry, and treat them specially with regard to SA
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 65]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
creation and lookup. The implementation extracts the header for the
|
|||
|
packet that triggered the error (from the ICMP message payload),
|
|||
|
reverses the source and destination IP address fields, extracts the
|
|||
|
protocol field, and reverses the port fields (if accessible). It
|
|||
|
then uses this extracted information to locate an appropriate, active
|
|||
|
outbound SA, and transmits the error message via this SA. If no such
|
|||
|
SA exists, no SA will be created, and this is an auditable event.
|
|||
|
|
|||
|
If an IPsec implementation receives an inbound ICMP error message on
|
|||
|
an SA, and the IP and ICMP headers of the message do not match the
|
|||
|
traffic selectors for the SA, the receiver MUST process the received
|
|||
|
message in a special fashion. Specifically, the receiver must
|
|||
|
extract the header of the triggering packet from the ICMP payload,
|
|||
|
and reverse fields as described above to determine if the packet is
|
|||
|
consistent with the selectors for the SA via which the ICMP error
|
|||
|
message was received. If the packet fails this check, the IPsec
|
|||
|
implementation MUST NOT forwarded the ICMP message to the
|
|||
|
destination. This is an auditable event.
|
|||
|
|
|||
|
7. Handling Fragments (on the protected side of the IPsec boundary)
|
|||
|
|
|||
|
Earlier sections of this document describe mechanisms for (a)
|
|||
|
fragmenting an outbound packet after IPsec processing has been
|
|||
|
applied and reassembling it at the receiver before IPsec processing
|
|||
|
and (b) handling inbound fragments received from the unprotected side
|
|||
|
of the IPsec boundary. This section describes how an implementation
|
|||
|
should handle the processing of outbound plaintext fragments on the
|
|||
|
protected side of the IPsec boundary. (See Appendix D, "Fragment
|
|||
|
Handling Rationale".) In particular, it addresses:
|
|||
|
|
|||
|
o mapping an outbound non-initial fragment to the right SA
|
|||
|
(or finding the right SPD entry)
|
|||
|
o verifying that a received non-initial fragment is
|
|||
|
authorized for the SA via which it was received
|
|||
|
o mapping outbound and inbound non-initial fragments to the
|
|||
|
right SPD-O/SPD-I entry or the relevant cache entry, for
|
|||
|
BYPASS/DISCARD traffic
|
|||
|
|
|||
|
Note: In Section 4.1, transport mode SAs have been defined to not
|
|||
|
carry fragments (IPv4 or IPv6). Note also that in Section 4.4.1, two
|
|||
|
special values, ANY and OPAQUE, were defined for selectors and that
|
|||
|
ANY includes OPAQUE. The term "non-trivial" is used to mean that the
|
|||
|
selector has a value other than OPAQUE or ANY.
|
|||
|
|
|||
|
Note: The term "non-initial fragment" is used here to indicate a
|
|||
|
fragment that does not contain all the selector values that may be
|
|||
|
needed for access control. As observed in Section 4.4.1, depending
|
|||
|
on the Next Layer Protocol, in addition to Ports, the ICMP message
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 66]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
type/code or Mobility Header type could be missing from non-initial
|
|||
|
fragments. Also, for IPv6, even the first fragment might NOT contain
|
|||
|
the Next Layer Protocol or Ports (or ICMP message type/code, or
|
|||
|
Mobility Header type) depending on the kind and number of extension
|
|||
|
headers present. If a non-initial fragment contains the Port (or
|
|||
|
ICMP type and code or Mobility Header type) but not the Next Layer
|
|||
|
Protocol, then unless there is an SPD entry for the relevant
|
|||
|
Local/Remote addresses with ANY for Next Layer Protocol and Port (or
|
|||
|
ICMP type and code or Mobility Header type), the fragment would not
|
|||
|
contain all the selector information needed for access control.
|
|||
|
|
|||
|
To address the above issues, three approaches have been defined:
|
|||
|
|
|||
|
o Tunnel mode SAs that carry initial and non-initial fragments
|
|||
|
(See Section 7.1.)
|
|||
|
o Separate tunnel mode SAs for non-initial fragments (See
|
|||
|
Section 7.2.)
|
|||
|
o Stateful fragment checking (See Section 7.3.)
|
|||
|
|
|||
|
7.1. Tunnel Mode SAs that Carry Initial and Non-Initial Fragments
|
|||
|
|
|||
|
All implementations MUST support tunnel mode SAs that are configured
|
|||
|
to pass traffic without regard to port field (or ICMP type/code or
|
|||
|
Mobility Header type) values. If the SA will carry traffic for
|
|||
|
specified protocols, the selector set for the SA MUST specify the
|
|||
|
port fields (or ICMP type/code or Mobility Header type) as ANY. An
|
|||
|
SA defined in this fashion will carry all traffic including initial
|
|||
|
and non-initial fragments for the indicated Local/Remote addresses
|
|||
|
and specified Next Layer protocol(s). If the SA will carry traffic
|
|||
|
without regard to a specific protocol value (i.e., ANY is specified
|
|||
|
as the (Next Layer) protocol selector value), then the port field
|
|||
|
values are undefined and MUST be set to ANY as well. (As noted in
|
|||
|
4.4.1, ANY includes OPAQUE as well as all specific values.)
|
|||
|
|
|||
|
7.2. Separate Tunnel Mode SAs for Non-Initial Fragments
|
|||
|
|
|||
|
An implementation MAY support tunnel mode SAs that will carry only
|
|||
|
non-initial fragments, separate from non-fragmented packets and
|
|||
|
initial fragments. The OPAQUE value will be used to specify port (or
|
|||
|
ICMP type/code or Mobility Header type) field selectors for an SA to
|
|||
|
carry such fragments. Receivers MUST perform a minimum offset check
|
|||
|
on IPv4 (non-initial) fragments to protect against overlapping
|
|||
|
fragment attacks when SAs of this type are employed. Because such
|
|||
|
checks cannot be performed on IPv6 non-initial fragments, users and
|
|||
|
administrators are advised that carriage of such fragments may be
|
|||
|
dangerous, and implementers may choose to NOT support such SAs for
|
|||
|
IPv6 traffic. Also, an SA of this sort will carry all non-initial
|
|||
|
fragments that match a specified Local/Remote address pair and
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 67]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
protocol value, i.e., the fragments carried on this SA belong to
|
|||
|
packets that if not fragmented, might have gone on separate SAs of
|
|||
|
differing security. Therefore, users and administrators are advised
|
|||
|
to protect such traffic using ESP (with integrity) and the
|
|||
|
"strongest" integrity and encryption algorithms in use between both
|
|||
|
peers. (Determination of the "strongest" algorithms requires
|
|||
|
imposing an ordering of the available algorithms, a local
|
|||
|
determination at the discretion of the initiator of the SA.)
|
|||
|
|
|||
|
Specific port (or ICMP type/code or Mobility Header type) selector
|
|||
|
values will be used to define SAs to carry initial fragments and
|
|||
|
non-fragmented packets. This approach can be used if a user or
|
|||
|
administrator wants to create one or more tunnel mode SAs between the
|
|||
|
same Local/Remote addresses that discriminate based on port (or ICMP
|
|||
|
type/code or Mobility Header type) fields. These SAs MUST have
|
|||
|
non-trivial protocol selector values, otherwise approach #1 above
|
|||
|
MUST be used.
|
|||
|
|
|||
|
Note: In general, for the approach described in this section, one
|
|||
|
needs only a single SA between two implementations to carry all
|
|||
|
non-initial fragments. However, if one chooses to have multiple SAs
|
|||
|
between the two implementations for QoS differentiation, then one
|
|||
|
might also want multiple SAs to carry fragments-without-ports, one
|
|||
|
for each supported QoS class. Since support for QoS via distinct SAs
|
|||
|
is a local matter, not mandated by this document, the choice to have
|
|||
|
multiple SAs to carry non-initial fragments should also be local.
|
|||
|
|
|||
|
7.3. Stateful Fragment Checking
|
|||
|
|
|||
|
An implementation MAY support some form of stateful fragment checking
|
|||
|
for a tunnel mode SA with non-trivial port (or ICMP type/code or MH
|
|||
|
type) field values (not ANY or OPAQUE). Implementations that will
|
|||
|
transmit non-initial fragments on a tunnel mode SA that makes use of
|
|||
|
non-trivial port (or ICMP type/code or MH type) selectors MUST notify
|
|||
|
a peer via the IKE NOTIFY NON_FIRST_FRAGMENTS_ALSO payload.
|
|||
|
|
|||
|
The peer MUST reject this proposal if it will not accept non-initial
|
|||
|
fragments in this context. If an implementation does not
|
|||
|
successfully negotiate transmission of non-initial fragments for such
|
|||
|
an SA, it MUST NOT send such fragments over the SA. This standard
|
|||
|
does not specify how peers will deal with such fragments, e.g., via
|
|||
|
reassembly or other means, at either sender or receiver. However, a
|
|||
|
receiver MUST discard non-initial fragments that arrive on an SA with
|
|||
|
non-trivial port (or ICMP type/code or MH type) selector values
|
|||
|
unless this feature has been negotiated. Also, the receiver MUST
|
|||
|
discard non-initial fragments that do not comply with the security
|
|||
|
policy applied to the overall packet. Discarding such packets is an
|
|||
|
auditable event. Note that in network configurations where fragments
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 68]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
of a packet might be sent or received via different security gateways
|
|||
|
or BITW implementations, stateful strategies for tracking fragments
|
|||
|
may fail.
|
|||
|
|
|||
|
7.4. BYPASS/DISCARD Traffic
|
|||
|
|
|||
|
All implementations MUST support DISCARDing of fragments using the
|
|||
|
normal SPD packet classification mechanisms. All implementations
|
|||
|
MUST support stateful fragment checking to accommodate BYPASS traffic
|
|||
|
for which a non-trivial port range is specified. The concern is that
|
|||
|
BYPASS of a cleartext, non-initial fragment arriving at an IPsec
|
|||
|
implementation could undermine the security afforded IPsec-protected
|
|||
|
traffic directed to the same destination. For example, consider an
|
|||
|
IPsec implementation configured with an SPD entry that calls for
|
|||
|
IPsec protection of traffic between a specific source/destination
|
|||
|
address pair, and for a specific protocol and destination port, e.g.,
|
|||
|
TCP traffic on port 23 (Telnet). Assume that the implementation also
|
|||
|
allows BYPASS of traffic from the same source/destination address
|
|||
|
pair and protocol, but for a different destination port, e.g., port
|
|||
|
119 (NNTP). An attacker could send a non-initial fragment (with a
|
|||
|
forged source address) that, if bypassed, could overlap with
|
|||
|
IPsec-protected traffic from the same source and thus violate the
|
|||
|
integrity of the IPsec-protected traffic. Requiring stateful
|
|||
|
fragment checking for BYPASS entries with non-trivial port ranges
|
|||
|
prevents attacks of this sort. As noted above, in network
|
|||
|
configurations where fragments of a packet might be sent or received
|
|||
|
via different security gateways or BITW implementations, stateful
|
|||
|
strategies for tracking fragments may fail.
|
|||
|
|
|||
|
8. Path MTU/DF Processing
|
|||
|
|
|||
|
The application of AH or ESP to an outbound packet increases the size
|
|||
|
of a packet and thus may cause a packet to exceed the PMTU for the SA
|
|||
|
via which the packet will travel. An IPsec implementation also may
|
|||
|
receive an unprotected ICMP PMTU message and, if it chooses to act
|
|||
|
upon the message, the result will affect outbound traffic processing.
|
|||
|
This section describes the processing required of an IPsec
|
|||
|
implementation to deal with these two PMTU issues.
|
|||
|
|
|||
|
8.1. DF Bit
|
|||
|
|
|||
|
All IPsec implementations MUST support the option of copying the DF
|
|||
|
bit from an outbound packet to the tunnel mode header that it emits,
|
|||
|
when traffic is carried via a tunnel mode SA. This means that it
|
|||
|
MUST be possible to configure the implementation's treatment of the
|
|||
|
DF bit (set, clear, copy from inner header) for each SA. This
|
|||
|
applies to SAs where both inner and outer headers are IPv4.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 69]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
8.2. Path MTU (PMTU) Discovery
|
|||
|
|
|||
|
This section discusses IPsec handling for unprotected Path MTU
|
|||
|
Discovery messages. ICMP PMTU is used here to refer to an ICMP
|
|||
|
message for:
|
|||
|
|
|||
|
IPv4 (RFC 792 [Pos81b]):
|
|||
|
- Type = 3 (Destination Unreachable)
|
|||
|
- Code = 4 (Fragmentation needed and DF set)
|
|||
|
- Next-Hop MTU in the low-order 16 bits of the
|
|||
|
second word of the ICMP header (labeled "unused"
|
|||
|
in RFC 792), with high-order 16 bits set to zero)
|
|||
|
|
|||
|
IPv6 (RFC 2463 [CD98]):
|
|||
|
- Type = 2 (Packet Too Big)
|
|||
|
- Code = 0 (Fragmentation needed)
|
|||
|
- Next-Hop MTU in the 32-bit MTU field of the ICMP6
|
|||
|
message
|
|||
|
|
|||
|
8.2.1. Propagation of PMTU
|
|||
|
|
|||
|
When an IPsec implementation receives an unauthenticated PMTU
|
|||
|
message, and it is configured to process (vs. ignore) such messages,
|
|||
|
it maps the message to the SA to which it corresponds. This mapping
|
|||
|
is effected by extracting the header information from the payload of
|
|||
|
the PMTU message and applying the procedure described in Section 5.2.
|
|||
|
The PMTU determined by this message is used to update the SAD PMTU
|
|||
|
field, taking into account the size of the AH or ESP header that will
|
|||
|
be applied, any crypto synchronization data, and the overhead imposed
|
|||
|
by an additional IP header, in the case of a tunnel mode SA.
|
|||
|
|
|||
|
In a native host implementation, it is possible to maintain PMTU data
|
|||
|
at the same granularity as for unprotected communication, so there is
|
|||
|
no loss of functionality. Signaling of the PMTU information is
|
|||
|
internal to the host. For all other IPsec implementation options,
|
|||
|
the PMTU data must be propagated via a synthesized ICMP PMTU. In
|
|||
|
these cases, the IPsec implementation SHOULD wait for outbound
|
|||
|
traffic to be mapped to the SAD entry. When such traffic arrives, if
|
|||
|
the traffic would exceed the updated PMTU value the traffic MUST be
|
|||
|
handled as follows:
|
|||
|
|
|||
|
Case 1: Original (cleartext) packet is IPv4 and has the DF
|
|||
|
bit set. The implementation SHOULD discard the packet
|
|||
|
and send a PMTU ICMP message.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 70]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
Case 2: Original (cleartext) packet is IPv4 and has the DF
|
|||
|
bit clear. The implementation SHOULD fragment (before or
|
|||
|
after encryption per its configuration) and then forward
|
|||
|
the fragments. It SHOULD NOT send a PMTU ICMP message.
|
|||
|
|
|||
|
Case 3: Original (cleartext) packet is IPv6. The implementation
|
|||
|
SHOULD discard the packet and send a PMTU ICMP message.
|
|||
|
|
|||
|
8.2.2. PMTU Aging
|
|||
|
|
|||
|
In all IPsec implementations, the PMTU associated with an SA MUST be
|
|||
|
"aged" and some mechanism is required to update the PMTU in a timely
|
|||
|
manner, especially for discovering if the PMTU is smaller than
|
|||
|
required by current network conditions. A given PMTU has to remain
|
|||
|
in place long enough for a packet to get from the source of the SA to
|
|||
|
the peer, and to propagate an ICMP error message if the current PMTU
|
|||
|
is too big.
|
|||
|
|
|||
|
Implementations SHOULD use the approach described in the Path MTU
|
|||
|
Discovery document (RFC 1191 [MD90], Section 6.3), which suggests
|
|||
|
periodically resetting the PMTU to the first-hop data-link MTU and
|
|||
|
then letting the normal PMTU Discovery processes update the PMTU as
|
|||
|
necessary. The period SHOULD be configurable.
|
|||
|
|
|||
|
9. Auditing
|
|||
|
|
|||
|
IPsec implementations are not required to support auditing. For the
|
|||
|
most part, the granularity of auditing is a local matter. However,
|
|||
|
several auditable events are identified in this document, and for
|
|||
|
each of these events a minimum set of information that SHOULD be
|
|||
|
included in an audit log is defined. Additional information also MAY
|
|||
|
be included in the audit log for each of these events, and additional
|
|||
|
events, not explicitly called out in this specification, also MAY
|
|||
|
result in audit log entries. There is no requirement for the
|
|||
|
receiver to transmit any message to the purported transmitter in
|
|||
|
response to the detection of an auditable event, because of the
|
|||
|
potential to induce denial of service via such action.
|
|||
|
|
|||
|
10. Conformance Requirements
|
|||
|
|
|||
|
All IPv4 IPsec implementations MUST comply with all requirements of
|
|||
|
this document. All IPv6 implementations MUST comply with all
|
|||
|
requirements of this document.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 71]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
11. Security Considerations
|
|||
|
|
|||
|
The focus of this document is security; hence security considerations
|
|||
|
permeate this specification.
|
|||
|
|
|||
|
IPsec imposes stringent constraints on bypass of IP header data in
|
|||
|
both directions, across the IPsec barrier, especially when tunnel
|
|||
|
mode SAs are employed. Some constraints are absolute, while others
|
|||
|
are subject to local administrative controls, often on a per-SA
|
|||
|
basis. For outbound traffic, these constraints are designed to limit
|
|||
|
covert channel bandwidth. For inbound traffic, the constraints are
|
|||
|
designed to prevent an adversary who has the ability to tamper with
|
|||
|
one data stream (on the unprotected side of the IPsec barrier) from
|
|||
|
adversely affecting other data streams (on the protected side of the
|
|||
|
barrier). The discussion in Section 5 dealing with processing DSCP
|
|||
|
values for tunnel mode SAs illustrates this concern.
|
|||
|
|
|||
|
If an IPsec implementation is configured to pass ICMP error messages
|
|||
|
over SAs based on the ICMP header values, without checking the header
|
|||
|
information from the ICMP message payload, serious vulnerabilities
|
|||
|
may arise. Consider a scenario in which several sites (A, B, and C)
|
|||
|
are connected to one another via ESP-protected tunnels: A-B, A-C, and
|
|||
|
B-C. Also assume that the traffic selectors for each tunnel specify
|
|||
|
ANY for protocol and port fields and IP source/destination address
|
|||
|
ranges that encompass the address range for the systems behind the
|
|||
|
security gateways serving each site. This would allow a host at site
|
|||
|
B to send an ICMP Destination Unreachable message to any host at site
|
|||
|
A, that declares all hosts on the net at site C to be unreachable.
|
|||
|
This is a very efficient DoS attack that could have been prevented if
|
|||
|
the ICMP error messages were subjected to the checks that IPsec
|
|||
|
provides, if the SPD is suitably configured, as described in Section
|
|||
|
6.2.
|
|||
|
|
|||
|
12. IANA Considerations
|
|||
|
|
|||
|
The IANA has assigned the value (3) for the asn1-modules registry and
|
|||
|
has assigned the object identifier 1.3.6.1.5.8.3.1 for the SPD
|
|||
|
module. See Appendix C, "ASN.1 for an SPD Entry".
|
|||
|
|
|||
|
13. Differences from RFC 2401
|
|||
|
|
|||
|
This architecture document differs substantially from RFC 2401
|
|||
|
[RFC2401] in detail and in organization, but the fundamental notions
|
|||
|
are unchanged.
|
|||
|
|
|||
|
o The processing model has been revised to address new IPsec
|
|||
|
scenarios, improve performance, and simplify implementation. This
|
|||
|
includes a separation between forwarding (routing) and SPD
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 72]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
selection, several SPD changes, and the addition of an outbound SPD
|
|||
|
cache and an inbound SPD cache for bypassed or discarded traffic.
|
|||
|
There is also a new database, the Peer Authorization Database
|
|||
|
(PAD). This provides a link between an SA management protocol
|
|||
|
(such as IKE) and the SPD.
|
|||
|
|
|||
|
o There is no longer a requirement to support nested SAs or "SA
|
|||
|
bundles". Instead this functionality can be achieved through SPD
|
|||
|
and forwarding table configuration. An example of a configuration
|
|||
|
has been added in Appendix E.
|
|||
|
|
|||
|
o SPD entries were redefined to provide more flexibility. Each SPD
|
|||
|
entry now consists of 1 to N sets of selectors, where each selector
|
|||
|
set contains one protocol and a "list of ranges" can now be
|
|||
|
specified for the Local IP address, Remote IP address, and whatever
|
|||
|
fields (if any) are associated with the Next Layer Protocol (Local
|
|||
|
Port, Remote Port, ICMP message type and code, and Mobility Header
|
|||
|
type). An individual value for a selector is represented via a
|
|||
|
trivial range and ANY is represented via a range than spans all
|
|||
|
values for the selector. An example of an ASN.1 description is
|
|||
|
included in Appendix C.
|
|||
|
|
|||
|
o TOS (IPv4) and Traffic Class (IPv6) have been replaced by DSCP and
|
|||
|
ECN. The tunnel section has been updated to explain how to handle
|
|||
|
DSCP and ECN bits.
|
|||
|
|
|||
|
o For tunnel mode SAs, an SG, BITS, or BITW implementation is now
|
|||
|
allowed to fragment packets before applying IPsec. This applies
|
|||
|
only to IPv4. For IPv6 packets, only the originator is allowed to
|
|||
|
fragment them.
|
|||
|
|
|||
|
o When security is desired between two intermediate systems along a
|
|||
|
path or between an intermediate system and an end system, transport
|
|||
|
mode may now be used between security gateways and between a
|
|||
|
security gateway and a host.
|
|||
|
|
|||
|
o This document clarifies that for all traffic that crosses the IPsec
|
|||
|
boundary, including IPsec management traffic, the SPD or associated
|
|||
|
caches must be consulted.
|
|||
|
|
|||
|
o This document defines how to handle the situation of a security
|
|||
|
gateway with multiple subscribers requiring separate IPsec
|
|||
|
contexts.
|
|||
|
|
|||
|
o A definition of reserved SPIs has been added.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 73]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
o Text has been added explaining why ALL IP packets must be checked
|
|||
|
-- IPsec includes minimal firewall functionality to support access
|
|||
|
control at the IP layer.
|
|||
|
|
|||
|
o The tunnel section has been updated to clarify how to handle the IP
|
|||
|
options field and IPv6 extension headers when constructing the
|
|||
|
outer header.
|
|||
|
|
|||
|
o SA mapping for inbound traffic has been updated to be consistent
|
|||
|
with the changes made in AH and ESP for support of unicast and
|
|||
|
multicast SAs.
|
|||
|
|
|||
|
o Guidance has been added regarding how to handle the covert channel
|
|||
|
created in tunnel mode by copying the DSCP value to outer header.
|
|||
|
|
|||
|
o Support for AH in both IPv4 and IPv6 is no longer required.
|
|||
|
|
|||
|
o PMTU handling has been updated. The appendix on
|
|||
|
PMTU/DF/Fragmentation has been deleted.
|
|||
|
|
|||
|
o Three approaches have been added for handling plaintext fragments
|
|||
|
on the protected side of the IPsec boundary. Appendix D documents
|
|||
|
the rationale behind them.
|
|||
|
|
|||
|
o Added revised text describing how to derive selector values for SAs
|
|||
|
(from the SPD entry or from the packet, etc.)
|
|||
|
|
|||
|
o Added a new table describing the relationship between selector
|
|||
|
values in an SPD entry, the PFP flag, and resulting selector values
|
|||
|
in the corresponding SAD entry.
|
|||
|
|
|||
|
o Added Appendix B to describe decorrelation.
|
|||
|
|
|||
|
o Added text describing how to handle an outbound packet that must be
|
|||
|
discarded.
|
|||
|
|
|||
|
o Added text describing how to handle a DISCARDED inbound packet,
|
|||
|
i.e., one that does not match the SA upon which it arrived.
|
|||
|
|
|||
|
o IPv6 mobility header has been added as a possible Next Layer
|
|||
|
Protocol. IPv6 Mobility Header message type has been added as a
|
|||
|
selector.
|
|||
|
|
|||
|
o ICMP message type and code have been added as selectors.
|
|||
|
|
|||
|
o The selector "data sensitivity level" has been removed to simplify
|
|||
|
things.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 74]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
o Updated text describing handling ICMP error messages. The appendix
|
|||
|
on "Categorization of ICMP Messages" has been deleted.
|
|||
|
|
|||
|
o The text for the selector name has been updated and clarified.
|
|||
|
|
|||
|
o The "Next Layer Protocol" has been further explained and a default
|
|||
|
list of protocols to skip when looking for the Next Layer Protocol
|
|||
|
has been added.
|
|||
|
|
|||
|
o The text has been amended to say that this document assumes use of
|
|||
|
IKEv2 or an SA management protocol with comparable features.
|
|||
|
|
|||
|
o Text has been added clarifying the algorithm for mapping inbound
|
|||
|
IPsec datagrams to SAs in the presence of multicast SAs.
|
|||
|
|
|||
|
o The appendix "Sequence Space Window Code Example" has been removed.
|
|||
|
|
|||
|
o With respect to IP addresses and ports, the terms "Local" and
|
|||
|
"Remote" are used for policy rules (replacing source and
|
|||
|
destination). "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 still used for packet header fields.
|
|||
|
|
|||
|
14. Acknowledgements
|
|||
|
|
|||
|
The authors would like to acknowledge the contributions of Ran
|
|||
|
Atkinson, who played a critical role in initial IPsec activities, and
|
|||
|
who authored the first series of IPsec standards: RFCs 1825-1827; and
|
|||
|
Charlie Lynn, who made significant contributions to the second series
|
|||
|
of IPsec standards (RFCs 2401, 2402, and 2406) and to the current
|
|||
|
versions, especially with regard to IPv6 issues. The authors also
|
|||
|
would like to thank the members of the IPsec and MSEC working groups
|
|||
|
who have contributed to the development of this protocol
|
|||
|
specification.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 75]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
Appendix A: Glossary
|
|||
|
|
|||
|
This section provides definitions for several key terms that are
|
|||
|
employed in this document. Other documents provide additional
|
|||
|
definitions and background information relevant to this technology,
|
|||
|
e.g., [Shi00], [VK83], and [HA94]. Included in this glossary are
|
|||
|
generic security service and security mechanism terms, plus
|
|||
|
IPsec-specific terms.
|
|||
|
|
|||
|
Access Control
|
|||
|
A security service that prevents unauthorized use of a resource,
|
|||
|
including the prevention of use of a resource in an unauthorized
|
|||
|
manner. In the IPsec context, the resource to which access is
|
|||
|
being controlled is often:
|
|||
|
|
|||
|
o for a host, computing cycles or data
|
|||
|
o for a security gateway, a network behind the gateway
|
|||
|
or bandwidth on that network.
|
|||
|
|
|||
|
Anti-replay
|
|||
|
See "Integrity" below.
|
|||
|
|
|||
|
Authentication
|
|||
|
Used informally to refer to the combination of two nominally
|
|||
|
distinct security services, data origin authentication and
|
|||
|
connectionless integrity. See the definitions below for each of
|
|||
|
these services.
|
|||
|
|
|||
|
Availability
|
|||
|
When viewed as a security service, addresses the security concerns
|
|||
|
engendered by attacks against networks that deny or degrade
|
|||
|
service. For example, in the IPsec context, the use of
|
|||
|
anti-replay mechanisms in AH and ESP support availability.
|
|||
|
|
|||
|
Confidentiality
|
|||
|
The security service that protects data from unauthorized
|
|||
|
disclosure. The primary confidentiality concern in most instances
|
|||
|
is unauthorized disclosure of application-level data, but
|
|||
|
disclosure of the external characteristics of communication also
|
|||
|
can be a concern in some circumstances. Traffic flow
|
|||
|
confidentiality is the service that addresses this latter concern
|
|||
|
by concealing source and destination addresses, message length, or
|
|||
|
frequency of communication. In the IPsec context, using ESP in
|
|||
|
tunnel mode, especially at a security gateway, can provide some
|
|||
|
level of traffic flow confidentiality. (See also "Traffic
|
|||
|
Analysis" below.)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 76]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
Data Origin Authentication
|
|||
|
A security service that verifies the identity of the claimed
|
|||
|
source of data. This service is usually bundled with
|
|||
|
connectionless integrity service.
|
|||
|
|
|||
|
Encryption
|
|||
|
A security mechanism used to transform data from an intelligible
|
|||
|
form (plaintext) into an unintelligible form (ciphertext), to
|
|||
|
provide confidentiality. The inverse transformation process is
|
|||
|
designated "decryption". Often the term "encryption" is used to
|
|||
|
generically refer to both processes.
|
|||
|
|
|||
|
Integrity
|
|||
|
A security service that ensures that modifications to data are
|
|||
|
detectable. Integrity comes in various flavors to match
|
|||
|
application requirements. IPsec supports two forms of integrity:
|
|||
|
connectionless and a form of partial sequence integrity.
|
|||
|
Connectionless integrity is a service that detects modification of
|
|||
|
an individual IP datagram, without regard to the ordering of the
|
|||
|
datagram in a stream of traffic. The form of partial sequence
|
|||
|
integrity offered in IPsec is referred to as anti-replay
|
|||
|
integrity, and it detects arrival of duplicate IP datagrams
|
|||
|
(within a constrained window). This is in contrast to
|
|||
|
connection-oriented integrity, which imposes more stringent
|
|||
|
sequencing requirements on traffic, e.g., to be able to detect
|
|||
|
lost or re-ordered messages. Although authentication and
|
|||
|
integrity services often are cited separately, in practice they
|
|||
|
are intimately connected and almost always offered in tandem.
|
|||
|
|
|||
|
Protected vs. Unprotected
|
|||
|
"Protected" refers to the systems or interfaces that are inside
|
|||
|
the IPsec protection boundary, and "unprotected" refers to the
|
|||
|
systems or interfaces that are outside the IPsec protection
|
|||
|
boundary. IPsec provides a boundary through which traffic passes.
|
|||
|
There is an asymmetry to this barrier, which is reflected in the
|
|||
|
processing model. Outbound data, if not discarded or bypassed, is
|
|||
|
protected via the application of AH or ESP and the addition of the
|
|||
|
corresponding headers. Inbound data, if not discarded or
|
|||
|
bypassed, is processed via the removal of AH or ESP headers. In
|
|||
|
this document, inbound traffic enters an IPsec implementation from
|
|||
|
the "unprotected" interface. Outbound traffic enters the
|
|||
|
implementation via the "protected" interface, or is internally
|
|||
|
generated 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. The protected interface may be
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 77]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
internal, e.g., in a host implementation of IPsec. The protected
|
|||
|
interface may link to a socket layer interface presented by the
|
|||
|
OS.
|
|||
|
|
|||
|
Security Association (SA)
|
|||
|
A simplex (uni-directional) logical connection, created for
|
|||
|
security purposes. All traffic traversing an SA is provided the
|
|||
|
same security processing. In IPsec, an SA is an Internet-layer
|
|||
|
abstraction implemented through the use of AH or ESP. State data
|
|||
|
associated with an SA is represented in the SA Database (SAD).
|
|||
|
|
|||
|
Security Gateway
|
|||
|
An intermediate system that acts as the communications interface
|
|||
|
between two networks. The set of hosts (and networks) on the
|
|||
|
external side of the security gateway is termed unprotected (they
|
|||
|
are generally at least less protected than those "behind" the SG),
|
|||
|
while the networks and hosts on the internal side are viewed as
|
|||
|
protected. The internal subnets and hosts served by a security
|
|||
|
gateway are presumed to be trusted by virtue of sharing a common,
|
|||
|
local, security administration. In the IPsec context, a security
|
|||
|
gateway is a point at which AH and/or ESP is implemented in order
|
|||
|
to serve a set of internal hosts, providing security services for
|
|||
|
these hosts when they communicate with external hosts also
|
|||
|
employing IPsec (either directly or via another security gateway).
|
|||
|
|
|||
|
Security Parameters Index (SPI)
|
|||
|
An arbitrary 32-bit value that is used by a receiver to identify
|
|||
|
the SA to which an incoming packet should be bound. For a unicast
|
|||
|
SA, the SPI can be used by itself to specify an SA, or it may be
|
|||
|
used in conjunction with the IPsec protocol type. Additional IP
|
|||
|
address information is used to identify multicast SAs. The SPI is
|
|||
|
carried in AH and ESP protocols to enable the receiving system to
|
|||
|
select the SA under which a received packet will be processed. An
|
|||
|
SPI has only local significance, as defined by the creator of the
|
|||
|
SA (usually the receiver of the packet carrying the SPI); thus an
|
|||
|
SPI is generally viewed as an opaque bit string. However, the
|
|||
|
creator of an SA may choose to interpret the bits in an SPI to
|
|||
|
facilitate local processing.
|
|||
|
|
|||
|
Traffic Analysis
|
|||
|
The analysis of network traffic flow for the purpose of deducing
|
|||
|
information that is useful to an adversary. Examples of such
|
|||
|
information are frequency of transmission, the identities of the
|
|||
|
conversing parties, sizes of packets, and flow identifiers
|
|||
|
[Sch94].
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 78]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
Appendix B: Decorrelation
|
|||
|
|
|||
|
This appendix is based on work done for caching of policies in the IP
|
|||
|
Security Policy Working Group by Luis Sanchez, Matt Condell, and John
|
|||
|
Zao.
|
|||
|
|
|||
|
Two SPD entries are correlated if there is a non-null intersection
|
|||
|
between the values of corresponding selectors in each entry. Caching
|
|||
|
correlated SPD entries can lead to incorrect policy enforcement. A
|
|||
|
solution to this problem, which still allows for caching, is to
|
|||
|
remove the ambiguities by decorrelating the entries. That is, the
|
|||
|
SPD entries must be rewritten so that for every pair of entries there
|
|||
|
exists a selector for which there is a null intersection between the
|
|||
|
values in both of the entries. Once the entries are decorrelated,
|
|||
|
there is no longer any ordering requirement on them, since only one
|
|||
|
entry will match any lookup. The next section describes
|
|||
|
decorrelation in more detail and presents an algorithm that may be
|
|||
|
used to implement decorrelation.
|
|||
|
|
|||
|
B.1. Decorrelation Algorithm
|
|||
|
|
|||
|
The basic decorrelation algorithm takes each entry in a correlated
|
|||
|
SPD and divides it into a set of entries using a tree structure.
|
|||
|
The nodes of the tree are the selectors that may overlap between the
|
|||
|
policies. At each node, the algorithm creates a branch for each of
|
|||
|
the values of the selector. It also creates one branch for the
|
|||
|
complement of the union of all selector values. Policies are then
|
|||
|
formed by traversing the tree from the root to each leaf. The
|
|||
|
policies at the leaves are compared to the set of already
|
|||
|
decorrelated policy rules. Each policy at a leaf is either
|
|||
|
completely overridden by a policy in the already decorrelated set and
|
|||
|
is discarded or is decorrelated with all the policies in the
|
|||
|
decorrelated set and is added to it.
|
|||
|
|
|||
|
The basic algorithm does not guarantee an optimal set of decorrelated
|
|||
|
entries. That is, the entries may be broken up into smaller sets
|
|||
|
than is necessary, though they will still provide all the necessary
|
|||
|
policy information. Some extensions to the basic algorithm are
|
|||
|
described later to improve this and improve the performance of the
|
|||
|
algorithm.
|
|||
|
|
|||
|
C A set of ordered, correlated entries (a correlated SPD).
|
|||
|
Ci The ith entry in C.
|
|||
|
U The set of decorrelated entries being built from C.
|
|||
|
Ui The ith entry in U.
|
|||
|
Sik The kth selection for policy Ci.
|
|||
|
Ai The action for policy Ci.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 79]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
A policy (SPD entry) P may be expressed as a sequence of selector
|
|||
|
values and an action (BYPASS, DISCARD, or PROTECT):
|
|||
|
|
|||
|
Ci = Si1 x Si2 x ... x Sik -> Ai
|
|||
|
|
|||
|
1) Put C1 in set U as U1
|
|||
|
|
|||
|
For each policy Cj (j > 1) in C
|
|||
|
|
|||
|
2) If Cj is decorrelated with every entry in U, then add it to U.
|
|||
|
|
|||
|
3) If Cj is correlated with one or more entries in U, create a tree
|
|||
|
rooted at the policy Cj that partitions Cj into a set of decorrelated
|
|||
|
entries. The algorithm starts with a root node where no selectors
|
|||
|
have yet been chosen.
|
|||
|
|
|||
|
A) Choose a selector in Cj, Sjn, that has not yet been chosen when
|
|||
|
traversing the tree from the root to this node. If there are no
|
|||
|
selectors not yet used, continue to the next unfinished branch
|
|||
|
until all branches have been completed. When the tree is
|
|||
|
completed, go to step D.
|
|||
|
|
|||
|
T is the set of entries in U that are correlated with the entry
|
|||
|
at this node.
|
|||
|
|
|||
|
The entry at this node is the entry formed by the selector
|
|||
|
values of each of the branches between the root and this node.
|
|||
|
Any selector values that are not yet represented by branches
|
|||
|
assume the corresponding selector value in Cj, since the values
|
|||
|
in Cj represent the maximum value for each selector.
|
|||
|
|
|||
|
B) Add a branch to the tree for each value of the selector Sjn that
|
|||
|
appears in any of the entries in T. (If the value is a superset
|
|||
|
of the value of Sjn in Cj, then use the value in Cj, since that
|
|||
|
value represents the universal set.) Also add a branch for the
|
|||
|
complement of the union of all the values of the selector Sjn
|
|||
|
in T. When taking the complement, remember that the universal
|
|||
|
set is the value of Sjn in Cj. A branch need not be created
|
|||
|
for the null set.
|
|||
|
|
|||
|
C) Repeat A and B until the tree is completed.
|
|||
|
|
|||
|
D) The entry to each leaf now represents an entry that is a subset
|
|||
|
of Cj. The entries at the leaves completely partition Cj in
|
|||
|
such a way that each entry is either completely overridden by
|
|||
|
an entry in U, or is decorrelated with the entries in U.
|
|||
|
|
|||
|
Add all the decorrelated entries at the leaves of the tree to U.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 80]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
4) Get next Cj and go to 2.
|
|||
|
|
|||
|
5) When all entries in C have been processed, then U will contain an
|
|||
|
decorrelated version of C.
|
|||
|
|
|||
|
There are several optimizations that can be made to this algorithm.
|
|||
|
A few of them are presented here.
|
|||
|
|
|||
|
It is possible to optimize, or at least improve, the amount of
|
|||
|
branching that occurs by carefully choosing the order of the
|
|||
|
selectors used for the next branch. For example, if a selector Sjn
|
|||
|
can be chosen so that all the values for that selector in T are equal
|
|||
|
to or a superset of the value of Sjn in Cj, then only a single branch
|
|||
|
needs to be created (since the complement will be null).
|
|||
|
|
|||
|
Branches of the tree do not have to proceed with the entire
|
|||
|
decorrelation algorithm. For example, if a node represents an entry
|
|||
|
that is decorrelated with all the entries in U, then there is no
|
|||
|
reason to continue decorrelating that branch. Also, if a branch is
|
|||
|
completely overridden by an entry in U, then there is no reason to
|
|||
|
continue decorrelating the branch.
|
|||
|
|
|||
|
An additional optimization is to check to see if a branch is
|
|||
|
overridden by one of the CORRELATED entries in set C that has already
|
|||
|
been decorrelated. That is, if the branch is part of decorrelating
|
|||
|
Cj, then check to see if it was overridden by an entry Cm, m < j.
|
|||
|
This is a valid check, since all the entries Cm are already expressed
|
|||
|
in U.
|
|||
|
|
|||
|
Along with checking if an entry is already decorrelated in step 2,
|
|||
|
check if Cj is overridden by any entry in U. If it is, skip it since
|
|||
|
it is not relevant. An entry x is overridden by another entry y if
|
|||
|
every selector in x is equal to or a subset of the corresponding
|
|||
|
selector in entry y.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 81]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
Appendix C: ASN.1 for an SPD Entry
|
|||
|
|
|||
|
This appendix is included as an additional way to describe SPD
|
|||
|
entries, as defined in Section 4.4.1. It uses ASN.1 syntax that has
|
|||
|
been successfully compiled. This syntax is merely illustrative and
|
|||
|
need not be employed in an implementation to achieve compliance. The
|
|||
|
SPD description in Section 4.4.1 is normative.
|
|||
|
|
|||
|
SPDModule
|
|||
|
|
|||
|
{iso(1) org (3) dod (6) internet (1) security (5) mechanisms (5)
|
|||
|
ipsec (8) asn1-modules (3) spd-module (1) }
|
|||
|
|
|||
|
DEFINITIONS IMPLICIT TAGS ::=
|
|||
|
|
|||
|
BEGIN
|
|||
|
|
|||
|
IMPORTS
|
|||
|
RDNSequence FROM PKIX1Explicit88
|
|||
|
{ iso(1) identified-organization(3)
|
|||
|
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
|
|||
|
id-mod(0) id-pkix1-explicit(18) } ;
|
|||
|
|
|||
|
-- An SPD is a list of policies in decreasing order of preference
|
|||
|
SPD ::= SEQUENCE OF SPDEntry
|
|||
|
|
|||
|
SPDEntry ::= CHOICE {
|
|||
|
iPsecEntry IPsecEntry, -- PROTECT traffic
|
|||
|
bypassOrDiscard [0] BypassOrDiscardEntry } -- DISCARD/BYPASS
|
|||
|
|
|||
|
IPsecEntry ::= SEQUENCE { -- Each entry consists of
|
|||
|
name NameSets OPTIONAL,
|
|||
|
pFPs PacketFlags, -- Populate from packet flags
|
|||
|
-- Applies to ALL of the corresponding
|
|||
|
-- traffic selectors in the SelectorLists
|
|||
|
condition SelectorLists, -- Policy "condition"
|
|||
|
processing Processing -- Policy "action"
|
|||
|
}
|
|||
|
|
|||
|
BypassOrDiscardEntry ::= SEQUENCE {
|
|||
|
bypass BOOLEAN, -- TRUE BYPASS, FALSE DISCARD
|
|||
|
condition InOutBound }
|
|||
|
|
|||
|
InOutBound ::= CHOICE {
|
|||
|
outbound [0] SelectorLists,
|
|||
|
inbound [1] SelectorLists,
|
|||
|
bothways [2] BothWays }
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 82]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
BothWays ::= SEQUENCE {
|
|||
|
inbound SelectorLists,
|
|||
|
outbound SelectorLists }
|
|||
|
|
|||
|
NameSets ::= SEQUENCE {
|
|||
|
passed SET OF Names-R, -- Matched to IKE ID by
|
|||
|
-- responder
|
|||
|
local SET OF Names-I } -- Used internally by IKE
|
|||
|
-- initiator
|
|||
|
|
|||
|
Names-R ::= CHOICE { -- IKEv2 IDs
|
|||
|
dName RDNSequence, -- ID_DER_ASN1_DN
|
|||
|
fqdn FQDN, -- ID_FQDN
|
|||
|
rfc822 [0] RFC822Name, -- ID_RFC822_ADDR
|
|||
|
keyID OCTET STRING } -- KEY_ID
|
|||
|
|
|||
|
Names-I ::= OCTET STRING -- Used internally by IKE
|
|||
|
-- initiator
|
|||
|
|
|||
|
FQDN ::= IA5String
|
|||
|
|
|||
|
RFC822Name ::= IA5String
|
|||
|
|
|||
|
PacketFlags ::= BIT STRING {
|
|||
|
-- if set, take selector value from packet
|
|||
|
-- establishing SA
|
|||
|
-- else use value in SPD entry
|
|||
|
localAddr (0),
|
|||
|
remoteAddr (1),
|
|||
|
protocol (2),
|
|||
|
localPort (3),
|
|||
|
remotePort (4) }
|
|||
|
|
|||
|
SelectorLists ::= SET OF SelectorList
|
|||
|
|
|||
|
SelectorList ::= SEQUENCE {
|
|||
|
localAddr AddrList,
|
|||
|
remoteAddr AddrList,
|
|||
|
protocol ProtocolChoice }
|
|||
|
|
|||
|
Processing ::= SEQUENCE {
|
|||
|
extSeqNum BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit
|
|||
|
seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit
|
|||
|
fragCheck BOOLEAN, -- TRUE stateful fragment checking,
|
|||
|
-- FALSE no stateful fragment checking
|
|||
|
lifetime SALifetime,
|
|||
|
spi ManualSPI,
|
|||
|
algorithms ProcessingAlgs,
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 83]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
tunnel TunnelOptions OPTIONAL } -- if absent, use
|
|||
|
-- transport mode
|
|||
|
|
|||
|
SALifetime ::= SEQUENCE {
|
|||
|
seconds [0] INTEGER OPTIONAL,
|
|||
|
bytes [1] INTEGER OPTIONAL }
|
|||
|
|
|||
|
ManualSPI ::= SEQUENCE {
|
|||
|
spi INTEGER,
|
|||
|
keys KeyIDs }
|
|||
|
|
|||
|
KeyIDs ::= SEQUENCE OF OCTET STRING
|
|||
|
|
|||
|
ProcessingAlgs ::= CHOICE {
|
|||
|
ah [0] IntegrityAlgs, -- AH
|
|||
|
esp [1] ESPAlgs} -- ESP
|
|||
|
|
|||
|
ESPAlgs ::= CHOICE {
|
|||
|
integrity [0] IntegrityAlgs, -- integrity only
|
|||
|
confidentiality [1] ConfidentialityAlgs, -- confidentiality
|
|||
|
-- only
|
|||
|
both [2] IntegrityConfidentialityAlgs,
|
|||
|
combined [3] CombinedModeAlgs }
|
|||
|
|
|||
|
IntegrityConfidentialityAlgs ::= SEQUENCE {
|
|||
|
integrity IntegrityAlgs,
|
|||
|
confidentiality ConfidentialityAlgs }
|
|||
|
|
|||
|
-- Integrity Algorithms, ordered by decreasing preference
|
|||
|
IntegrityAlgs ::= SEQUENCE OF IntegrityAlg
|
|||
|
|
|||
|
-- Confidentiality Algorithms, ordered by decreasing preference
|
|||
|
ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg
|
|||
|
|
|||
|
-- Integrity Algorithms
|
|||
|
IntegrityAlg ::= SEQUENCE {
|
|||
|
algorithm IntegrityAlgType,
|
|||
|
parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
|
|||
|
|
|||
|
IntegrityAlgType ::= INTEGER {
|
|||
|
none (0),
|
|||
|
auth-HMAC-MD5-96 (1),
|
|||
|
auth-HMAC-SHA1-96 (2),
|
|||
|
auth-DES-MAC (3),
|
|||
|
auth-KPDK-MD5 (4),
|
|||
|
auth-AES-XCBC-96 (5)
|
|||
|
-- tbd (6..65535)
|
|||
|
}
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 84]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
-- Confidentiality Algorithms
|
|||
|
ConfidentialityAlg ::= SEQUENCE {
|
|||
|
algorithm ConfidentialityAlgType,
|
|||
|
parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
|
|||
|
|
|||
|
ConfidentialityAlgType ::= INTEGER {
|
|||
|
encr-DES-IV64 (1),
|
|||
|
encr-DES (2),
|
|||
|
encr-3DES (3),
|
|||
|
encr-RC5 (4),
|
|||
|
encr-IDEA (5),
|
|||
|
encr-CAST (6),
|
|||
|
encr-BLOWFISH (7),
|
|||
|
encr-3IDEA (8),
|
|||
|
encr-DES-IV32 (9),
|
|||
|
encr-RC4 (10),
|
|||
|
encr-NULL (11),
|
|||
|
encr-AES-CBC (12),
|
|||
|
encr-AES-CTR (13)
|
|||
|
-- tbd (14..65535)
|
|||
|
}
|
|||
|
|
|||
|
CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg
|
|||
|
|
|||
|
CombinedModeAlg ::= SEQUENCE {
|
|||
|
algorithm CombinedModeType,
|
|||
|
parameters ANY -- DEFINED BY algorithm} -- defined outside
|
|||
|
-- of this document for AES modes.
|
|||
|
|
|||
|
CombinedModeType ::= INTEGER {
|
|||
|
comb-AES-CCM (1),
|
|||
|
comb-AES-GCM (2)
|
|||
|
-- tbd (3..65535)
|
|||
|
}
|
|||
|
|
|||
|
TunnelOptions ::= SEQUENCE {
|
|||
|
dscp DSCP,
|
|||
|
ecn BOOLEAN, -- TRUE Copy CE to inner header
|
|||
|
df DF,
|
|||
|
addresses TunnelAddresses }
|
|||
|
|
|||
|
TunnelAddresses ::= CHOICE {
|
|||
|
ipv4 IPv4Pair,
|
|||
|
ipv6 [0] IPv6Pair }
|
|||
|
|
|||
|
IPv4Pair ::= SEQUENCE {
|
|||
|
local OCTET STRING (SIZE(4)),
|
|||
|
remote OCTET STRING (SIZE(4)) }
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 85]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
IPv6Pair ::= SEQUENCE {
|
|||
|
local OCTET STRING (SIZE(16)),
|
|||
|
remote OCTET STRING (SIZE(16)) }
|
|||
|
|
|||
|
DSCP ::= SEQUENCE {
|
|||
|
copy BOOLEAN, -- TRUE copy from inner header
|
|||
|
-- FALSE do not copy
|
|||
|
mapping OCTET STRING OPTIONAL} -- points to table
|
|||
|
-- if no copy
|
|||
|
|
|||
|
DF ::= INTEGER {
|
|||
|
clear (0),
|
|||
|
set (1),
|
|||
|
copy (2) }
|
|||
|
|
|||
|
ProtocolChoice::= CHOICE {
|
|||
|
anyProt AnyProtocol, -- for ANY protocol
|
|||
|
noNext [0] NoNextLayerProtocol, -- has no next layer
|
|||
|
-- items
|
|||
|
oneNext [1] OneNextLayerProtocol, -- has one next layer
|
|||
|
-- item
|
|||
|
twoNext [2] TwoNextLayerProtocol, -- has two next layer
|
|||
|
-- items
|
|||
|
fragment FragmentNoNext } -- has no next layer
|
|||
|
-- info
|
|||
|
|
|||
|
AnyProtocol ::= SEQUENCE {
|
|||
|
id INTEGER (0), -- ANY protocol
|
|||
|
nextLayer AnyNextLayers }
|
|||
|
|
|||
|
AnyNextLayers ::= SEQUENCE { -- with either
|
|||
|
first AnyNextLayer, -- ANY next layer selector
|
|||
|
second AnyNextLayer } -- ANY next layer selector
|
|||
|
|
|||
|
NoNextLayerProtocol ::= INTEGER (2..254)
|
|||
|
|
|||
|
FragmentNoNext ::= INTEGER (44) -- Fragment identifier
|
|||
|
|
|||
|
OneNextLayerProtocol ::= SEQUENCE {
|
|||
|
id INTEGER (1..254), -- ICMP, MH, ICMPv6
|
|||
|
nextLayer NextLayerChoice } -- ICMP Type*256+Code
|
|||
|
-- MH Type*256
|
|||
|
|
|||
|
TwoNextLayerProtocol ::= SEQUENCE {
|
|||
|
id INTEGER (2..254), -- Protocol
|
|||
|
local NextLayerChoice, -- Local and
|
|||
|
remote NextLayerChoice } -- Remote ports
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 86]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
NextLayerChoice ::= CHOICE {
|
|||
|
any AnyNextLayer,
|
|||
|
opaque [0] OpaqueNextLayer,
|
|||
|
range [1] NextLayerRange }
|
|||
|
|
|||
|
-- Representation of ANY in next layer field
|
|||
|
AnyNextLayer ::= SEQUENCE {
|
|||
|
start INTEGER (0),
|
|||
|
end INTEGER (65535) }
|
|||
|
|
|||
|
-- Representation of OPAQUE in next layer field.
|
|||
|
-- Matches IKE convention
|
|||
|
OpaqueNextLayer ::= SEQUENCE {
|
|||
|
start INTEGER (65535),
|
|||
|
end INTEGER (0) }
|
|||
|
|
|||
|
-- Range for a next layer field
|
|||
|
NextLayerRange ::= SEQUENCE {
|
|||
|
start INTEGER (0..65535),
|
|||
|
end INTEGER (0..65535) }
|
|||
|
|
|||
|
-- List of IP addresses
|
|||
|
AddrList ::= SEQUENCE {
|
|||
|
v4List IPv4List OPTIONAL,
|
|||
|
v6List [0] IPv6List OPTIONAL }
|
|||
|
|
|||
|
-- IPv4 address representations
|
|||
|
IPv4List ::= SEQUENCE OF IPv4Range
|
|||
|
|
|||
|
IPv4Range ::= SEQUENCE { -- close, but not quite right ...
|
|||
|
ipv4Start OCTET STRING (SIZE (4)),
|
|||
|
ipv4End OCTET STRING (SIZE (4)) }
|
|||
|
|
|||
|
-- IPv6 address representations
|
|||
|
IPv6List ::= SEQUENCE OF IPv6Range
|
|||
|
|
|||
|
IPv6Range ::= SEQUENCE { -- close, but not quite right ...
|
|||
|
ipv6Start OCTET STRING (SIZE (16)),
|
|||
|
ipv6End OCTET STRING (SIZE (16)) }
|
|||
|
|
|||
|
END
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 87]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
Appendix D: Fragment Handling Rationale
|
|||
|
|
|||
|
There are three issues that must be resolved regarding processing of
|
|||
|
(plaintext) fragments in IPsec:
|
|||
|
|
|||
|
- mapping a non-initial, outbound fragment to the right SA
|
|||
|
(or finding the right SPD entry)
|
|||
|
- verifying that a received, non-initial fragment is authorized
|
|||
|
for the SA via which it is received
|
|||
|
- mapping outbound and inbound non-initial fragments to the
|
|||
|
right SPD/cache entry, for BYPASS/DISCARD traffic
|
|||
|
|
|||
|
The first and third issues arise because we need a deterministic
|
|||
|
algorithm for mapping traffic to SAs (and SPD/cache entries). All
|
|||
|
three issues are important because we want to make sure that
|
|||
|
non-initial fragments that cross the IPsec boundary do not cause the
|
|||
|
access control policies in place at the receiver (or transmitter) to
|
|||
|
be violated.
|
|||
|
|
|||
|
D.1. Transport Mode and Fragments
|
|||
|
|
|||
|
First, we note that transport mode SAs have been defined to not carry
|
|||
|
fragments. This is a carryover from RFC 2401, where transport mode
|
|||
|
SAs always terminated at endpoints. This is a fundamental
|
|||
|
requirement because, in the worst case, an IPv4 fragment to which
|
|||
|
IPsec was applied might then be fragmented (as a ciphertext packet),
|
|||
|
en route to the destination. IP fragment reassembly procedures at
|
|||
|
the IPsec receiver would not be able to distinguish between pre-IPsec
|
|||
|
fragments and fragments created after IPsec processing.
|
|||
|
|
|||
|
For IPv6, only the sender is allowed to fragment a packet. As for
|
|||
|
IPv4, an IPsec implementation is allowed to fragment tunnel mode
|
|||
|
packets after IPsec processing, because it is the sender relative to
|
|||
|
the (outer) tunnel header. However, unlike IPv4, it would be
|
|||
|
feasible to carry a plaintext fragment on a transport mode SA,
|
|||
|
because the fragment header in IPv6 would appear after the AH or ESP
|
|||
|
header, and thus would not cause confusion at the receiver with
|
|||
|
respect to reassembly. Specifically, the receiver would not attempt
|
|||
|
reassembly for the fragment until after IPsec processing. To keep
|
|||
|
things simple, this specification prohibits carriage of fragments on
|
|||
|
transport mode SAs for IPv6 traffic.
|
|||
|
|
|||
|
When only end systems used transport mode SAs, the prohibition on
|
|||
|
carriage of fragments was not a problem, since we assumed that the
|
|||
|
end system could be configured to not offer a fragment to IPsec. For
|
|||
|
a native host implementation, this seems reasonable, and, as someone
|
|||
|
already noted, RFC 2401 warned that a BITS implementation might have
|
|||
|
to reassemble fragments before performing an SA lookup. (It would
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 88]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
then apply AH or ESP and could re-fragment the packet after IPsec
|
|||
|
processing.) Because a BITS implementation is assumed to be able to
|
|||
|
have access to all traffic emanating from its host, even if the host
|
|||
|
has multiple interfaces, this was deemed a reasonable mandate.
|
|||
|
|
|||
|
In this specification, it is acceptable to use transport mode in
|
|||
|
cases where the IPsec implementation is not the ultimate destination,
|
|||
|
e.g., between two SGs. In principle, this creates a new opportunity
|
|||
|
for outbound, plaintext fragments to be mapped to a transport mode SA
|
|||
|
for IPsec processing. However, in these new contexts in which a
|
|||
|
transport mode SA is now approved for use, it seems likely that we
|
|||
|
can continue to prohibit transmission of fragments, as seen by IPsec,
|
|||
|
i.e., packets that have an "outer header" with a non-zero fragment
|
|||
|
offset field. For example, in an IP overlay network, packets being
|
|||
|
sent over transport mode SAs are IP-in-IP tunneled and thus have the
|
|||
|
necessary inner header to accommodate fragmentation prior to IPsec
|
|||
|
processing. When carried via a transport mode SA, IPsec would not
|
|||
|
examine the inner IP header for such traffic, and thus would not
|
|||
|
consider the packet to be a fragment.
|
|||
|
|
|||
|
D.2. Tunnel Mode and Fragments
|
|||
|
|
|||
|
For tunnel mode SAs, it has always been the case that outbound
|
|||
|
fragments might arrive for processing at an IPsec implementation.
|
|||
|
The need to accommodate fragmented outbound packets can pose a
|
|||
|
problem because a non-initial fragment generally will not contain the
|
|||
|
port fields associated with a next layer protocol such as TCP, UDP,
|
|||
|
or SCTP. Thus, depending on the SPD configuration for a given IPsec
|
|||
|
implementation, plaintext fragments might or might not pose a
|
|||
|
problem.
|
|||
|
|
|||
|
For example, if the SPD requires that all traffic between two address
|
|||
|
ranges is offered IPsec protection (no BYPASS or DISCARD SPD entries
|
|||
|
apply to this address range), then it should be easy to carry
|
|||
|
non-initial fragments on the SA defined for this address range, since
|
|||
|
the SPD entry implies an intent to carry ALL traffic between the
|
|||
|
address ranges. But, if there are multiple SPD entries that could
|
|||
|
match a fragment, and if these entries reference different subsets of
|
|||
|
port fields (vs. ANY), then it is not possible to map an outbound
|
|||
|
non-initial fragment to the right entry, unambiguously. (If we choose
|
|||
|
to allow carriage of fragments on transport mode SAs for IPv6, the
|
|||
|
problems arises in that context as well.)
|
|||
|
|
|||
|
This problem largely, though not exclusively, motivated the
|
|||
|
definition of OPAQUE as a selector value for port fields in RFC 2401.
|
|||
|
The other motivation for OPAQUE is the observation that port fields
|
|||
|
might not be accessible due to the prior application of IPsec. For
|
|||
|
example, if a host applied IPsec to its traffic and that traffic
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 89]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
arrived at an SG, these fields would be encrypted. The algorithm
|
|||
|
specified for locating the "next layer protocol" described in RFC
|
|||
|
2401 also motivated use of OPAQUE to accommodate an encrypted next
|
|||
|
layer protocol field in such circumstances. Nonetheless, the primary
|
|||
|
use of the OPAQUE value was to match traffic selector fields in
|
|||
|
packets that did not contain port fields (non-initial fragments), or
|
|||
|
packets in which the port fields were already encrypted (as a result
|
|||
|
of nested application of IPsec). RFC 2401 was ambiguous in
|
|||
|
discussing the use of OPAQUE vs. ANY, suggesting in some places that
|
|||
|
ANY might be an alternative to OPAQUE.
|
|||
|
|
|||
|
We gain additional access control capability by defining both ANY and
|
|||
|
OPAQUE values. OPAQUE can be defined to match only fields that are
|
|||
|
not accessible. We could define ANY as the complement of OPAQUE,
|
|||
|
i.e., it would match all values but only for accessible port fields.
|
|||
|
We have therefore simplified the procedure employed to locate the
|
|||
|
next layer protocol in this document, so that we treat ESP and AH as
|
|||
|
next layer protocols. As a result, the notion of an encrypted next
|
|||
|
layer protocol field has vanished, and there is also no need to worry
|
|||
|
about encrypted port fields either. And accordingly, OPAQUE will be
|
|||
|
applicable only to non-initial fragments.
|
|||
|
|
|||
|
Since we have adopted the definitions above for ANY and OPAQUE, we
|
|||
|
need to clarify how these values work when the specified protocol
|
|||
|
does not have port fields, and when ANY is used for the protocol
|
|||
|
selector. Accordingly, if a specific protocol value is used as a
|
|||
|
selector, and if that protocol has no port fields, then the port
|
|||
|
field selectors are to be ignored and ANY MUST be specified as the
|
|||
|
value for the port fields. (In this context, ICMP TYPE and CODE
|
|||
|
values are lumped together as a single port field (for IKEv2
|
|||
|
negotiation), as is the IPv6 Mobility Header TYPE value.) If the
|
|||
|
protocol selector is ANY, then this should be treated as equivalent
|
|||
|
to specifying a protocol for which no port fields are defined, and
|
|||
|
thus the port selectors should be ignored, and MUST be set to ANY.
|
|||
|
|
|||
|
D.3. The Problem of Non-Initial Fragments
|
|||
|
|
|||
|
For an SG implementation, it is obvious that fragments might arrive
|
|||
|
from end systems behind the SG. A BITW implementation also may
|
|||
|
encounter fragments from a host or gateway behind it. (As noted
|
|||
|
earlier, native host implementations and BITS implementations
|
|||
|
probably can avoid the problems described below.) In the worst case,
|
|||
|
fragments from a packet might arrive at distinct BITW or SG
|
|||
|
instantiations and thus preclude reassembly as a solution option.
|
|||
|
Hence, in RFC 2401 we adopted a general requirement that fragments
|
|||
|
must be accommodated in tunnel mode for all implementations. However,
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 90]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
RFC 2401 did not provide a perfect solution. The use of OPAQUE as a
|
|||
|
selector value for port fields (a SHOULD in RFC 2401) allowed an SA
|
|||
|
to carry non-initial fragments.
|
|||
|
|
|||
|
Using the features defined in RFC 2401, if one defined an SA between
|
|||
|
two IPsec (SG or BITW) implementations using the OPAQUE value for
|
|||
|
both port fields, then all non-initial fragments matching the
|
|||
|
source/destination (S/D) address and protocol values for the SA would
|
|||
|
be mapped to that SA. Initial fragments would NOT map to this SA, if
|
|||
|
we adopt a strict definition of OPAQUE. However, RFC 2401 did not
|
|||
|
provide detailed guidance on this and thus it may not have been
|
|||
|
apparent that use of this feature would essentially create a
|
|||
|
"non-initial fragment only" SA.
|
|||
|
|
|||
|
In the course of discussing the "fragment-only" SA approach, it was
|
|||
|
noted that some subtle problems, problems not considered in RFC 2401,
|
|||
|
would have to be avoided. For example, an SA of this sort must be
|
|||
|
configured to offer the "highest quality" security services for any
|
|||
|
traffic between the indicated S/D addresses (for the specified
|
|||
|
protocol). This is necessary to ensure that any traffic captured by
|
|||
|
the fragment-only SA is not offered degraded security relative to
|
|||
|
what it would have been offered if the packet were not fragmented. A
|
|||
|
possible problem here is that we may not be able to identify the
|
|||
|
"highest quality" security services defined for use between two IPsec
|
|||
|
implementation, since the choice of security protocols, options, and
|
|||
|
algorithms is a lattice, not a totally ordered set. (We might safely
|
|||
|
say that BYPASS < AH < ESP w/integrity, but it gets complicated if we
|
|||
|
have multiple ESP encryption or integrity algorithm options.) So, one
|
|||
|
has to impose a total ordering on these security parameters to make
|
|||
|
this work, but this can be done locally.
|
|||
|
|
|||
|
However, this conservative strategy has a possible performance
|
|||
|
downside. If most traffic traversing an IPsec implementation for a
|
|||
|
given S/D address pair (and specified protocol) is bypassed, then a
|
|||
|
fragment-only SA for that address pair might cause a dramatic
|
|||
|
increase in the volume of traffic afforded crypto processing. If the
|
|||
|
crypto implementation cannot support high traffic rates, this could
|
|||
|
cause problems. (An IPsec implementation that is capable of line rate
|
|||
|
or near line rate crypto performance would not be adversely affected
|
|||
|
by this SA configuration approach. Nonetheless, the performance
|
|||
|
impact is a potential concern, specific to implementation
|
|||
|
capabilities.)
|
|||
|
|
|||
|
Another concern is that non-initial fragments sent over a dedicated
|
|||
|
SA might be used to effect overlapping reassembly attacks, when
|
|||
|
combined with an apparently acceptable initial fragment. (This sort
|
|||
|
of attack assumes creation of bogus fragments and is not a side
|
|||
|
effect of normal fragmentation.) This concern is easily addressed in
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 91]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
IPv4, by checking the fragment offset value to ensure that no
|
|||
|
non-initial fragments have a small enough offset to overlap port
|
|||
|
fields that should be contained in the initial fragment. Recall that
|
|||
|
the IPv4 MTU minimum is 576 bytes, and the max IP header length is 60
|
|||
|
bytes, so any ports should be present in the initial fragment. If we
|
|||
|
require all non-initial fragments to have an offset of, say, 128 or
|
|||
|
greater, just to be on the safe side, this should prevent successful
|
|||
|
attacks of this sort. If the intent is only to protect against this
|
|||
|
sort of reassembly attack, this check need be implemented only by a
|
|||
|
receiver.
|
|||
|
|
|||
|
IPv6 also has a fragment offset, carried in the fragmentation
|
|||
|
extension header. However, IPv6 extension headers are variable in
|
|||
|
length and there is no analogous max header length value that we can
|
|||
|
use to check non-initial fragments, to reject ones that might be used
|
|||
|
for an attack of the sort noted above. A receiver would need to
|
|||
|
maintain state analogous to reassembly state, to provide equivalent
|
|||
|
protection. So, only for IPv4 is it feasible to impose a fragment
|
|||
|
offset check that would reject attacks designed to circumvent port
|
|||
|
field checks by IPsec (or firewalls) when passing non-initial
|
|||
|
fragments.
|
|||
|
|
|||
|
Another possible concern is that in some topologies and SPD
|
|||
|
configurations this approach might result in an access control
|
|||
|
surprise. The notion is that if we create an SA to carry ALL
|
|||
|
(non-initial) fragments, then that SA would carry some traffic that
|
|||
|
might otherwise arrive as plaintext via a separate path, e.g., a path
|
|||
|
monitored by a proxy firewall. But, this concern arises only if the
|
|||
|
other path allows initial fragments to traverse it without requiring
|
|||
|
reassembly, presumably a bad idea for a proxy firewall. Nonetheless,
|
|||
|
this does represent a potential problem in some topologies and under
|
|||
|
certain assumptions with respect to SPD and (other) firewall rule
|
|||
|
sets, and administrators need to be warned of this possibility.
|
|||
|
|
|||
|
A less serious concern is that non-initial fragments sent over a
|
|||
|
non-initial fragment-only SA might represent a DoS opportunity, in
|
|||
|
that they could be sent when no valid, initial fragment will ever
|
|||
|
arrive. This might be used to attack hosts behind an SG or BITW
|
|||
|
device. However, the incremental risk posed by this sort of attack,
|
|||
|
which can be mounted only by hosts behind an SG or BITW device, seems
|
|||
|
small.
|
|||
|
|
|||
|
If we interpret the ANY selector value as encompassing OPAQUE, then a
|
|||
|
single SA with ANY values for both port fields would be able to
|
|||
|
accommodate all traffic matching the S/D address and protocol traffic
|
|||
|
selectors, an alternative to using the OPAQUE value. But, using ANY
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 92]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
here precludes multiple, distinct SAs between the same IPsec
|
|||
|
implementations for the same address pairs and protocol. So, it is
|
|||
|
not an exactly equivalent alternative.
|
|||
|
|
|||
|
Fundamentally, fragment handling problems arise only when more than
|
|||
|
one SA is defined with the same S/D address and protocol selector
|
|||
|
values, but with different port field selector values.
|
|||
|
|
|||
|
D.4. BYPASS/DISCARD Traffic
|
|||
|
|
|||
|
We also have to address the non-initial fragment processing issue for
|
|||
|
BYPASS/DISCARD entries, independent of SA processing. This is
|
|||
|
largely a local matter for two reasons:
|
|||
|
|
|||
|
1) We have no means for coordinating SPD entries for such
|
|||
|
traffic between IPsec implementations since IKE is not
|
|||
|
invoked.
|
|||
|
2) Many of these entries refer to traffic that is NOT
|
|||
|
directed to or received from a location that is using
|
|||
|
IPsec. So there is no peer IPsec implementation with
|
|||
|
which to coordinate via any means.
|
|||
|
|
|||
|
However, this document should provide guidance here, consistent with
|
|||
|
our goal of offering a well-defined, access control function for all
|
|||
|
traffic, relative to the IPsec boundary. To that end, this document
|
|||
|
says that implementations MUST support fragment reassembly for
|
|||
|
BYPASS/DISCARD traffic when port fields are specified. An
|
|||
|
implementation also MUST permit a user or administrator to accept
|
|||
|
such traffic or reject such traffic using the SPD conventions
|
|||
|
described in Section 4.4.1. The concern is that BYPASS of a
|
|||
|
cleartext, non-initial fragment arriving at an IPsec implementation
|
|||
|
could undermine the security afforded IPsec-protected traffic
|
|||
|
directed to the same destination. For example, consider an IPsec
|
|||
|
implementation configured with an SPD entry that calls for
|
|||
|
IPsec-protection of traffic between a specific source/destination
|
|||
|
address pair, and for a specific protocol and destination port, e.g.,
|
|||
|
TCP traffic on port 23 (Telnet). Assume that the implementation also
|
|||
|
allows BYPASS of traffic from the same source/destination address
|
|||
|
pair and protocol, but for a different destination port, e.g., port
|
|||
|
119 (NNTP). An attacker could send a non-initial fragment (with a
|
|||
|
forged source address) that, if bypassed, could overlap with
|
|||
|
IPsec-protected traffic from the same source and thus violate the
|
|||
|
integrity of the IPsec-protected traffic. Requiring stateful
|
|||
|
fragment checking for BYPASS entries with non-trivial port ranges
|
|||
|
prevents attacks of this sort.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 93]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
D.5. Just say no to ports?
|
|||
|
|
|||
|
It has been suggested that we could avoid the problems described
|
|||
|
above by not allowing port field selectors to be used in tunnel mode.
|
|||
|
But the discussion above shows this to be an unnecessarily stringent
|
|||
|
approach, i.e., since no problems arise for the native OS and BITS
|
|||
|
implementations. Moreover, some WG members have described scenarios
|
|||
|
where use of tunnel mode SAs with (non-trivial) port field selectors
|
|||
|
is appropriate. So the challenge is defining a strategy that can
|
|||
|
deal with this problem in BITW and SG contexts. Also note that
|
|||
|
BYPASS/DISCARD entries in the SPD that make use of ports pose the
|
|||
|
same problems, irrespective of tunnel vs. transport mode notions.
|
|||
|
|
|||
|
Some folks have suggested that a firewall behind an SG or BITW should
|
|||
|
be left to enforce port-level access controls and the effects of
|
|||
|
fragmentation. However, this seems to be an incongruous suggestion
|
|||
|
in that elsewhere in IPsec (e.g., in IKE payloads) we are concerned
|
|||
|
about firewalls that always discard fragments. If many firewalls
|
|||
|
don't pass fragments in general, why should we expect them to deal
|
|||
|
with fragments in this case? So, this analysis rejects the suggestion
|
|||
|
of disallowing use of port field selectors with tunnel mode SAs.
|
|||
|
|
|||
|
D.6. Other Suggested Solutions
|
|||
|
|
|||
|
One suggestion is to reassemble fragments at the sending IPsec
|
|||
|
implementation, and thus avoid the problem entirely. This approach
|
|||
|
is invisible to a receiver and thus could be adopted as a purely
|
|||
|
local implementation option.
|
|||
|
|
|||
|
A more sophisticated version of this suggestion calls for
|
|||
|
establishing and maintaining minimal state from each initial fragment
|
|||
|
encountered, to allow non-initial fragments to be matched to the
|
|||
|
right SAs or SPD/cache entries. This implies an extension to the
|
|||
|
current processing model (and the old one). The IPsec implementation
|
|||
|
would intercept all fragments; capture Source/Destination IP
|
|||
|
addresses, protocol, packet ID, and port fields from initial
|
|||
|
fragments; and then use this data to map non-initial fragments to SAs
|
|||
|
that require port fields. If this approach is employed, the receiver
|
|||
|
needs to employ an equivalent scheme, as it too must verify that
|
|||
|
received fragments are consistent with SA selector values. A
|
|||
|
non-initial fragment that arrives prior to an initial fragment could
|
|||
|
be cached or discarded, awaiting arrival of the corresponding initial
|
|||
|
fragment.
|
|||
|
|
|||
|
A downside of both approaches noted above is that they will not
|
|||
|
always work. When a BITW device or SG is configured in a topology
|
|||
|
that might allow some fragments for a packet to be processed at
|
|||
|
different SGs or BITW devices, then there is no guarantee that all
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 94]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
fragments will ever arrive at the same IPsec device. This approach
|
|||
|
also raises possible processing problems. If the sender caches
|
|||
|
non-initial fragments until the corresponding initial fragment
|
|||
|
arrives, buffering problems might arise, especially at high speeds.
|
|||
|
If the non-initial fragments are discarded rather than cached, there
|
|||
|
is no guarantee that traffic will ever pass, e.g., retransmission
|
|||
|
will result in different packet IDs that cannot be matched with prior
|
|||
|
transmissions. In any case, housekeeping procedures will be needed
|
|||
|
to decide when to delete the fragment state data, adding some
|
|||
|
complexity to the system. Nonetheless, this is a viable solution in
|
|||
|
some topologies, and these are likely to be common topologies.
|
|||
|
|
|||
|
The Working Group rejected an earlier version of the convention of
|
|||
|
creating an SA to carry only non-initial fragments, something that
|
|||
|
was supported implicitly under the RFC 2401 model via use of OPAQUE
|
|||
|
port fields, but never clearly articulated in RFC 2401. The
|
|||
|
(rejected) text called for each non-initial fragment to be treated as
|
|||
|
protocol 44 (the IPv6 fragment header protocol ID) by the sender and
|
|||
|
receiver. This approach has the potential to make IPv4 and IPv6
|
|||
|
fragment handling more uniform, but it does not fundamentally change
|
|||
|
the problem, nor does it address the issue of fragment handling for
|
|||
|
BYPASS/DISCARD traffic. Given the fragment overlap attack problem
|
|||
|
that IPv6 poses, it does not seem that it is worth the effort to
|
|||
|
adopt this strategy.
|
|||
|
|
|||
|
D.7. Consistency
|
|||
|
|
|||
|
Earlier, the WG agreed to allow an IPsec BITS, BITW, or SG to perform
|
|||
|
fragmentation prior to IPsec processing. If this fragmentation is
|
|||
|
performed after SA lookup at the sender, there is no "mapping to the
|
|||
|
right SA" problem. But, the receiver still needs to be able to
|
|||
|
verify that the non-initial fragments are consistent with the SA via
|
|||
|
which they are received. Since the initial fragment might be lost en
|
|||
|
route, the receiver encounters all of the potential problems noted
|
|||
|
above. Thus, if we are to be consistent in our decisions, we need to
|
|||
|
say how a receiver will deal with the non-initial fragments that
|
|||
|
arrive.
|
|||
|
|
|||
|
D.8. Conclusions
|
|||
|
|
|||
|
There is no simple, uniform way to handle fragments in all contexts.
|
|||
|
Different approaches work better in different contexts. Thus, this
|
|||
|
document offers 3 choices -- one MUST and two MAYs. At some point in
|
|||
|
the future, if the community gains experience with the two MAYs, they
|
|||
|
may become SHOULDs or MUSTs or other approaches may be proposed.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 95]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
Appendix E: Example of Supporting Nested SAs via SPD and Forwarding
|
|||
|
Table Entries
|
|||
|
|
|||
|
This appendix provides an example of how to configure the SPD and
|
|||
|
forwarding tables to support a nested pair of SAs, consistent with
|
|||
|
the new processing model. For simplicity, this example assumes just
|
|||
|
one SPD-I.
|
|||
|
|
|||
|
The goal in this example is to support a transport mode SA from A to
|
|||
|
C, carried over a tunnel mode SA from A to B. For example, A might
|
|||
|
be a laptop connected to the public Internet, B might be a firewall
|
|||
|
that protects a corporate network, and C might be a server on the
|
|||
|
corporate network that demands end-to-end authentication of A's
|
|||
|
traffic.
|
|||
|
|
|||
|
+---+ +---+ +---+
|
|||
|
| A |=====| B | | C |
|
|||
|
| |------------| |
|
|||
|
| |=====| | | |
|
|||
|
+---+ +---+ +---+
|
|||
|
|
|||
|
A's SPD contains entries of the form:
|
|||
|
|
|||
|
Next Layer
|
|||
|
Rule Local Remote Protocol Action
|
|||
|
---- ----- ------ ---------- -----------------------
|
|||
|
1 C A ESP BYPASS
|
|||
|
2 A C ICMP,ESP PROTECT(ESP,tunnel,integr+conf)
|
|||
|
3 A C ANY PROTECT(ESP,transport,integr-only)
|
|||
|
4 A B ICMP,IKE BYPASS
|
|||
|
|
|||
|
A's unprotected-side forwarding table is set so that outbound packets
|
|||
|
destined for C are looped back to the protected side. A's
|
|||
|
protected-side forwarding table is set so that inbound ESP packets
|
|||
|
are looped back to the unprotected side. A's forwarding tables
|
|||
|
contain entries of the form:
|
|||
|
|
|||
|
Unprotected-side forwarding table
|
|||
|
|
|||
|
Rule Local Remote Protocol Action
|
|||
|
---- ----- ------ -------- ---------------------------
|
|||
|
1 A C ANY loop back to protected side
|
|||
|
2 A B ANY forward to B
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 96]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
Protected-side forwarding table
|
|||
|
|
|||
|
Rule Local Remote Protocol Action
|
|||
|
---- ----- ------ -------- -----------------------------
|
|||
|
1 A C ESP loop back to unprotected side
|
|||
|
|
|||
|
An outbound TCP packet from A to C would match SPD rule 3 and have
|
|||
|
transport mode ESP applied to it. The unprotected-side forwarding
|
|||
|
table would then loop back the packet. The packet is compared
|
|||
|
against SPD-I (see Figure 2), matches SPD rule 1, and so it is
|
|||
|
BYPASSed. The packet is treated as an outbound packet and compared
|
|||
|
against the SPD for a third time. This time it matches SPD rule 2,
|
|||
|
so ESP is applied in tunnel mode. This time the forwarding table
|
|||
|
doesn't loop back the packet, because the outer destination address
|
|||
|
is B, so the packet goes out onto the wire.
|
|||
|
|
|||
|
An inbound TCP packet from C to A is wrapped in two ESP headers; the
|
|||
|
outer header (ESP in tunnel mode) shows B as the source, whereas the
|
|||
|
inner header (ESP transport mode) shows C as the source. Upon
|
|||
|
arrival at A, the packet would be mapped to an SA based on the SPI,
|
|||
|
have the outer header removed, and be decrypted and
|
|||
|
integrity-checked. Then it would be matched against the SAD
|
|||
|
selectors for this SA, which would specify C as the source and A as
|
|||
|
the destination, derived from SPD rule 2. The protected-side
|
|||
|
forwarding function would then send it back to the unprotected side
|
|||
|
based on the addresses and the next layer protocol (ESP), indicative
|
|||
|
of nesting. It is compared against SPD-O (see Figure 3) and found to
|
|||
|
match SPD rule 1, so it is BYPASSed. The packet is mapped to an SA
|
|||
|
based on the SPI, integrity-checked, and compared against the SAD
|
|||
|
selectors derived from SPD rule 3. The forwarding function then
|
|||
|
passes it up to the next layer, because it isn't an ESP packet.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 97]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
References
|
|||
|
|
|||
|
Normative References
|
|||
|
|
|||
|
[BBCDWW98] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
|
|||
|
Z., and W. Weiss, "An Architecture for Differentiated
|
|||
|
Service", RFC 2475, December 1998.
|
|||
|
|
|||
|
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
Requirement Level", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|||
|
[CD98] Conta, A. and S. Deering, "Internet Control Message
|
|||
|
Protocol (ICMPv6) for the Internet Protocol Version 6
|
|||
|
(IPv6) Specification", RFC 2463, December 1998.
|
|||
|
|
|||
|
[DH98] Deering, S., and R. Hinden, "Internet Protocol,
|
|||
|
Version 6 (IPv6) Specification", RFC 2460, December
|
|||
|
1998.
|
|||
|
|
|||
|
[Eas05] 3rd Eastlake, D., "Cryptographic Algorithm
|
|||
|
Implementation Requirements For Encapsulating Security
|
|||
|
Payload (ESP) and Authentication Header (AH)", RFC
|
|||
|
4305, December 2005.
|
|||
|
|
|||
|
[HarCar98] Harkins, D. and D. Carrel, "The Internet Key Exchange
|
|||
|
(IKE)", RFC 2409, November 1998.
|
|||
|
|
|||
|
[Kau05] Kaufman, C., Ed., "The Internet Key Exchange (IKEv2)
|
|||
|
Protocol", RFC 4306, December 2005.
|
|||
|
|
|||
|
[Ken05a] Kent, S., "IP Encapsulating Security Payload (ESP)",
|
|||
|
RFC 4303, December 2005.
|
|||
|
|
|||
|
[Ken05b] Kent, S., "IP Authentication Header", RFC 4302,
|
|||
|
December 2005.
|
|||
|
|
|||
|
[MD90] Mogul, J. and S. Deering, "Path MTU discovery", RFC
|
|||
|
1191, November 1990.
|
|||
|
|
|||
|
[Mobip] Johnson, D., Perkins, C., and J. Arkko, "Mobility
|
|||
|
Support in IPv6", RFC 3775, June 2004.
|
|||
|
|
|||
|
[Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791,
|
|||
|
September 1981.
|
|||
|
|
|||
|
[Pos81b] Postel, J., "Internet Control Message Protocol", RFC
|
|||
|
792, September 1981.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 98]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
[Sch05] Schiller, J., "Cryptographic Algorithms for use in the
|
|||
|
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
|
|||
|
December 2005.
|
|||
|
|
|||
|
[WaKiHo97] Wahl, M., Kille, S., and T. Howes, "Lightweight
|
|||
|
Directory Access Protocol (v3): UTF-8 String
|
|||
|
Representation of Distinguished Names", RFC 2253,
|
|||
|
December 1997.
|
|||
|
|
|||
|
Informative References
|
|||
|
|
|||
|
[CoSa04] Condell, M., and L. Sanchez, "On the Deterministic
|
|||
|
Enforcement of Un-ordered Security Policies", BBN
|
|||
|
Technical Memo 1346, March 2004.
|
|||
|
|
|||
|
[FaLiHaMeTr00] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
|
|||
|
Traina, "Generic Routing Encapsulation (GRE)", RFC
|
|||
|
2784, March 2000.
|
|||
|
|
|||
|
[Gro02] Grossman, D., "New Terminology and Clarifications for
|
|||
|
Diffserv", RFC 3260, April 2002.
|
|||
|
[HC03] Holbrook, H. and B. Cain, "Source Specific Multicast
|
|||
|
for IP", Work in Progress, November 3, 2002.
|
|||
|
|
|||
|
[HA94] Haller, N. and R. Atkinson, "On Internet
|
|||
|
Authentication", RFC 1704, October 1994.
|
|||
|
|
|||
|
[NiBlBaBL98] Nichols, K., Blake, S., Baker, F., and D. Black,
|
|||
|
"Definition of the Differentiated Services Field (DS
|
|||
|
Field) in the IPv4 and IPv6 Headers", RFC 2474,
|
|||
|
December 1998.
|
|||
|
|
|||
|
[Per96] Perkins, C., "IP Encapsulation within IP", RFC 2003,
|
|||
|
October 1996.
|
|||
|
|
|||
|
[RaFlBl01] Ramakrishnan, K., Floyd, S., and D. Black, "The
|
|||
|
Addition of Explicit Congestion Notification (ECN) to
|
|||
|
IP", RFC 3168, September 2001.
|
|||
|
|
|||
|
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
|
|||
|
the Internet Protocol", RFC 2401, November 1998.
|
|||
|
|
|||
|
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
|
|||
|
2983, October 2000.
|
|||
|
|
|||
|
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney,
|
|||
|
"The Group Domain of Interpretation", RFC 3547, July
|
|||
|
2003.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 99]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group
|
|||
|
Security Architecture", RFC 3740, March 2004.
|
|||
|
|
|||
|
[RaCoCaDe04] Rajahalme, J., Conta, A., Carpenter, B., and S.
|
|||
|
Deering, "IPv6 Flow Label Specification", RFC 3697,
|
|||
|
March 2004.
|
|||
|
|
|||
|
[Sch94] Schneier, B., Applied Cryptography, Section 8.6, John
|
|||
|
Wiley & Sons, New York, NY, 1994.
|
|||
|
|
|||
|
[Shi00] Shirey, R., "Internet Security Glossary", RFC 2828,
|
|||
|
May 2000.
|
|||
|
|
|||
|
[SMPT01] Shacham, A., Monsour, B., Pereira, R., and M. Thomas,
|
|||
|
"IP Payload Compression Protocol (IPComp)", RFC 3173,
|
|||
|
September 2001.
|
|||
|
|
|||
|
[ToEgWa04] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec
|
|||
|
Transport Mode for Dynamic Routing", RFC 3884,
|
|||
|
September 2004.
|
|||
|
|
|||
|
[VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in
|
|||
|
High-level Networks", ACM Computing Surveys, Vol. 15,
|
|||
|
No. 2, June 1983.
|
|||
|
|
|||
|
Authors' Addresses
|
|||
|
|
|||
|
Stephen Kent
|
|||
|
BBN Technologies
|
|||
|
10 Moulton Street
|
|||
|
Cambridge, MA 02138
|
|||
|
USA
|
|||
|
|
|||
|
Phone: +1 (617) 873-3988
|
|||
|
EMail: kent@bbn.com
|
|||
|
|
|||
|
|
|||
|
Karen Seo
|
|||
|
BBN Technologies
|
|||
|
10 Moulton Street
|
|||
|
Cambridge, MA 02138
|
|||
|
USA
|
|||
|
|
|||
|
Phone: +1 (617) 873-3152
|
|||
|
EMail: kseo@bbn.com
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 100]
|
|||
|
|
|||
|
RFC 4301 Security Architecture for IP December 2005
|
|||
|
|
|||
|
|
|||
|
Full Copyright Statement
|
|||
|
|
|||
|
Copyright (C) The Internet Society (2005).
|
|||
|
|
|||
|
This document is subject to the rights, licenses and restrictions
|
|||
|
contained in BCP 78, and except as set forth therein, the authors
|
|||
|
retain all their rights.
|
|||
|
|
|||
|
This document and the information contained herein are provided on an
|
|||
|
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
|||
|
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
|||
|
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
|||
|
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
|||
|
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
|||
|
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|||
|
Intellectual Property
|
|||
|
|
|||
|
The IETF takes no position regarding the validity or scope of any
|
|||
|
Intellectual Property Rights or other rights that might be claimed to
|
|||
|
pertain to the implementation or use of the technology described in
|
|||
|
this document or the extent to which any license under such rights
|
|||
|
might or might not be available; nor does it represent that it has
|
|||
|
made any independent effort to identify any such rights. Information
|
|||
|
on the procedures with respect to rights in RFC documents can be
|
|||
|
found in BCP 78 and BCP 79.
|
|||
|
|
|||
|
Copies of IPR disclosures made to the IETF Secretariat and any
|
|||
|
assurances of licenses to be made available, or the result of an
|
|||
|
attempt made to obtain a general license or permission for the use of
|
|||
|
such proprietary rights by implementers or users of this
|
|||
|
specification can be obtained from the IETF on-line IPR repository at
|
|||
|
http://www.ietf.org/ipr.
|
|||
|
|
|||
|
The IETF invites any interested party to bring to its attention any
|
|||
|
copyrights, patents or patent applications, or other proprietary
|
|||
|
rights that may cover technology that may be required to implement
|
|||
|
this standard. Please address the information to the IETF at ietf-
|
|||
|
ipr@ietf.org.
|
|||
|
|
|||
|
Acknowledgement
|
|||
|
|
|||
|
Funding for the RFC Editor function is currently provided by the
|
|||
|
Internet Society.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Kent & Seo Standards Track [Page 101]
|
|||
|
|