7 Network Working Group S. Kent
8 Request for Comments: 4301 K. Seo
9 Obsoletes: 2401 BBN Technologies
10 Category: Standards Track December 2005
13 Security Architecture for the Internet Protocol
17 This document specifies an Internet standards track protocol for the
18 Internet community, and requests discussion and suggestions for
19 improvements. Please refer to the current edition of the "Internet
20 Official Protocol Standards" (STD 1) for the standardization state
21 and status of this protocol. Distribution of this memo is unlimited.
25 Copyright (C) The Internet Society (2005).
29 This document describes an updated version of the "Security
30 Architecture for IP", which is designed to provide security services
31 for traffic at the IP layer. This document obsoletes RFC 2401
36 This document is dedicated to the memory of Charlie Lynn, a long-time
37 senior colleague at BBN, who made very significant contributions to
58 Kent & Seo Standards Track [Page 1]
60 RFC 4301 Security Architecture for IP December 2005
65 1. Introduction ....................................................4
66 1.1. Summary of Contents of Document ............................4
67 1.2. Audience ...................................................4
68 1.3. Related Documents ..........................................5
69 2. Design Objectives ...............................................5
70 2.1. Goals/Objectives/Requirements/Problem Description ..........5
71 2.2. Caveats and Assumptions ....................................6
72 3. System Overview .................................................7
73 3.1. What IPsec Does ............................................7
74 3.2. How IPsec Works ............................................9
75 3.3. Where IPsec Can Be Implemented ............................10
76 4. Security Associations ..........................................11
77 4.1. Definition and Scope ......................................12
78 4.2. SA Functionality ..........................................16
79 4.3. Combining SAs .............................................17
80 4.4. Major IPsec Databases .....................................18
81 4.4.1. The Security Policy Database (SPD) .................19
82 4.4.1.1. Selectors .................................26
83 4.4.1.2. Structure of an SPD Entry .................30
84 4.4.1.3. More Regarding Fields Associated
85 with Next Layer Protocols .................32
86 4.4.2. Security Association Database (SAD) ................34
87 4.4.2.1. Data Items in the SAD .....................36
88 4.4.2.2. Relationship between SPD, PFP
89 flag, packet, and SAD .....................38
90 4.4.3. Peer Authorization Database (PAD) ..................43
91 4.4.3.1. PAD Entry IDs and Matching Rules ..........44
92 4.4.3.2. IKE Peer Authentication Data ..............45
93 4.4.3.3. Child SA Authorization Data ...............46
94 4.4.3.4. How the PAD Is Used .......................46
95 4.5. SA and Key Management .....................................47
96 4.5.1. Manual Techniques ..................................48
97 4.5.2. Automated SA and Key Management ....................48
98 4.5.3. Locating a Security Gateway ........................49
99 4.6. SAs and Multicast .........................................50
100 5. IP Traffic Processing ..........................................50
101 5.1. Outbound IP Traffic Processing
102 (protected-to-unprotected) ................................52
103 5.1.1. Handling an Outbound Packet That Must Be
104 Discarded ..........................................54
105 5.1.2. Header Construction for Tunnel Mode ................55
106 5.1.2.1. IPv4: Header Construction for
107 Tunnel Mode ...............................57
108 5.1.2.2. IPv6: Header Construction for
109 Tunnel Mode ...............................59
110 5.2. Processing Inbound IP Traffic (unprotected-to-protected) ..59
114 Kent & Seo Standards Track [Page 2]
116 RFC 4301 Security Architecture for IP December 2005
119 6. ICMP Processing ................................................63
120 6.1. Processing ICMP Error Messages Directed to an
121 IPsec Implementation ......................................63
122 6.1.1. ICMP Error Messages Received on the
123 Unprotected Side of the Boundary ...................63
124 6.1.2. ICMP Error Messages Received on the
125 Protected Side of the Boundary .....................64
126 6.2. Processing Protected, Transit ICMP Error Messages .........64
127 7. Handling Fragments (on the protected side of the IPsec
128 boundary) ......................................................66
129 7.1. Tunnel Mode SAs that Carry Initial and Non-Initial
130 Fragments .................................................67
131 7.2. Separate Tunnel Mode SAs for Non-Initial Fragments ........67
132 7.3. Stateful Fragment Checking ................................68
133 7.4. BYPASS/DISCARD Traffic ....................................69
134 8. Path MTU/DF Processing .........................................69
135 8.1. DF Bit ....................................................69
136 8.2. Path MTU (PMTU) Discovery .................................70
137 8.2.1. Propagation of PMTU ................................70
138 8.2.2. PMTU Aging .........................................71
139 9. Auditing .......................................................71
140 10. Conformance Requirements ......................................71
141 11. Security Considerations .......................................72
142 12. IANA Considerations ...........................................72
143 13. Differences from RFC 2401 .....................................72
144 14. Acknowledgements ..............................................75
145 Appendix A: Glossary ..............................................76
146 Appendix B: Decorrelation .........................................79
147 B.1. Decorrelation Algorithm ...................................79
148 Appendix C: ASN.1 for an SPD Entry ................................82
149 Appendix D: Fragment Handling Rationale ...........................88
150 D.1. Transport Mode and Fragments ..............................88
151 D.2. Tunnel Mode and Fragments .................................89
152 D.3. The Problem of Non-Initial Fragments ......................90
153 D.4. BYPASS/DISCARD Traffic ....................................93
154 D.5. Just say no to ports? .....................................94
155 D.6. Other Suggested Solutions..................................94
156 D.7. Consistency................................................95
157 D.8. Conclusions................................................95
158 Appendix E: Example of Supporting Nested SAs via SPD and
159 Forwarding Table Entries...............................96
160 References.........................................................98
161 Normative References............................................98
162 Informative References..........................................99
170 Kent & Seo Standards Track [Page 3]
172 RFC 4301 Security Architecture for IP December 2005
177 1.1. Summary of Contents of Document
179 This document specifies the base architecture for IPsec-compliant
180 systems. It describes how to provide a set of security services for
181 traffic at the IP layer, in both the IPv4 [Pos81a] and IPv6 [DH98]
182 environments. This document describes the requirements for systems
183 that implement IPsec, the fundamental elements of such systems, and
184 how the elements fit together and fit into the IP environment. It
185 also describes the security services offered by the IPsec protocols,
186 and how these services can be employed in the IP environment. This
187 document does not address all aspects of the IPsec architecture.
188 Other documents address additional architectural details in
189 specialized environments, e.g., use of IPsec in Network Address
190 Translation (NAT) environments and more comprehensive support for IP
191 multicast. The fundamental components of the IPsec security
192 architecture are discussed in terms of their underlying, required
193 functionality. Additional RFCs (see Section 1.3 for pointers to
194 other documents) define the protocols in (a), (c), and (d).
196 a. Security Protocols -- Authentication Header (AH) and
197 Encapsulating Security Payload (ESP)
198 b. Security Associations -- what they are and how they work,
199 how they are managed, associated processing
200 c. Key Management -- manual and automated (The Internet Key
202 d. Cryptographic algorithms for authentication and encryption
204 This document is not a Security Architecture for the Internet; it
205 addresses security only at the IP layer, provided through the use of
206 a combination of cryptographic and protocol security mechanisms.
208 The spelling "IPsec" is preferred and used throughout this and all
209 related IPsec standards. All other capitalizations of IPsec (e.g.,
210 IPSEC, IPSec, ipsec) are deprecated. However, any capitalization of
211 the sequence of letters "IPsec" should be understood to refer to the
214 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
215 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
216 document, are to be interpreted as described in RFC 2119 [Bra97].
220 The target audience for this document is primarily individuals who
221 implement this IP security technology or who architect systems that
222 will use this technology. Technically adept users of this technology
226 Kent & Seo Standards Track [Page 4]
228 RFC 4301 Security Architecture for IP December 2005
231 (end users or system administrators) also are part of the target
232 audience. A glossary is provided in Appendix A to help fill in gaps
233 in background/vocabulary. This document assumes that the reader is
234 familiar with the Internet Protocol (IP), related networking
235 technology, and general information system security terms and
238 1.3. Related Documents
240 As mentioned above, other documents provide detailed definitions of
241 some of the components of IPsec and of their interrelationship. They
242 include RFCs on the following topics:
244 a. security protocols -- RFCs describing the Authentication
245 Header (AH) [Ken05b] and Encapsulating Security Payload
246 (ESP) [Ken05a] protocols.
247 b. cryptographic algorithms for integrity and encryption -- one
248 RFC that defines the mandatory, default algorithms for use
249 with AH and ESP [Eas05], a similar RFC that defines the
250 mandatory algorithms for use with IKEv2 [Sch05] plus a
251 separate RFC for each cryptographic algorithm.
252 c. automatic key management -- RFCs on "The Internet Key
253 Exchange (IKEv2) Protocol" [Kau05] and "Cryptographic
254 Algorithms for Use in the Internet Key Exchange Version 2
259 2.1. Goals/Objectives/Requirements/Problem Description
261 IPsec is designed to provide interoperable, high quality,
262 cryptographically-based security for IPv4 and IPv6. The set of
263 security services offered includes access control, connectionless
264 integrity, data origin authentication, detection and rejection of
265 replays (a form of partial sequence integrity), confidentiality (via
266 encryption), and limited traffic flow confidentiality. These
267 services are provided at the IP layer, offering protection in a
268 standard fashion for all protocols that may be carried over IP
269 (including IP itself).
271 IPsec includes a specification for minimal firewall functionality,
272 since that is an essential aspect of access control at the IP layer.
273 Implementations are free to provide more sophisticated firewall
274 mechanisms, and to implement the IPsec-mandated functionality using
275 those more sophisticated mechanisms. (Note that interoperability may
276 suffer if additional firewall constraints on traffic flows are
277 imposed by an IPsec implementation but cannot be negotiated based on
278 the traffic selector features defined in this document and negotiated
282 Kent & Seo Standards Track [Page 5]
284 RFC 4301 Security Architecture for IP December 2005
287 via IKEv2.) The IPsec firewall function makes use of the
288 cryptographically-enforced authentication and integrity provided for
289 all IPsec traffic to offer better access control than could be
290 obtained through use of a firewall (one not privy to IPsec internal
291 parameters) plus separate cryptographic protection.
293 Most of the security services are provided through use of two traffic
294 security protocols, the Authentication Header (AH) and the
295 Encapsulating Security Payload (ESP), and through the use of
296 cryptographic key management procedures and protocols. The set of
297 IPsec protocols employed in a context, and the ways in which they are
298 employed, will be determined by the users/administrators in that
299 context. It is the goal of the IPsec architecture to ensure that
300 compliant implementations include the services and management
301 interfaces needed to meet the security requirements of a broad user
304 When IPsec is correctly implemented and deployed, it ought not
305 adversely affect users, hosts, and other Internet components that do
306 not employ IPsec for traffic protection. IPsec security protocols
307 (AH and ESP, and to a lesser extent, IKE) are designed to be
308 cryptographic algorithm independent. This modularity permits
309 selection of different sets of cryptographic algorithms as
310 appropriate, without affecting the other parts of the implementation.
311 For example, different user communities may select different sets of
312 cryptographic algorithms (creating cryptographically-enforced
313 cliques) if required.
315 To facilitate interoperability in the global Internet, a set of
316 default cryptographic algorithms for use with AH and ESP is specified
317 in [Eas05] and a set of mandatory-to-implement algorithms for IKEv2
318 is specified in [Sch05]. [Eas05] and [Sch05] will be periodically
319 updated to keep pace with computational and cryptologic advances. By
320 specifying these algorithms in documents that are separate from the
321 AH, ESP, and IKEv2 specifications, these algorithms can be updated or
322 replaced without affecting the standardization progress of the rest
323 of the IPsec document suite. The use of these cryptographic
324 algorithms, in conjunction with IPsec traffic protection and key
325 management protocols, is intended to permit system and application
326 developers to deploy high quality, Internet-layer, cryptographic
329 2.2. Caveats and Assumptions
331 The suite of IPsec protocols and associated default cryptographic
332 algorithms are designed to provide high quality security for Internet
333 traffic. However, the security offered by use of these protocols
334 ultimately depends on the quality of their implementation, which is
338 Kent & Seo Standards Track [Page 6]
340 RFC 4301 Security Architecture for IP December 2005
343 outside the scope of this set of standards. Moreover, the security
344 of a computer system or network is a function of many factors,
345 including personnel, physical, procedural, compromising emanations,
346 and computer security practices. Thus, IPsec is only one part of an
347 overall system security architecture.
349 Finally, the security afforded by the use of IPsec is critically
350 dependent on many aspects of the operating environment in which the
351 IPsec implementation executes. For example, defects in OS security,
352 poor quality of random number sources, sloppy system management
353 protocols and practices, etc., can all degrade the security provided
354 by IPsec. As above, none of these environmental attributes are
355 within the scope of this or other IPsec standards.
359 This section provides a high level description of how IPsec works,
360 the components of the system, and how they fit together to provide
361 the security services noted above. The goal of this description is
362 to enable the reader to "picture" the overall process/system, see how
363 it fits into the IP environment, and to provide context for later
364 sections of this document, which describe each of the components in
367 An IPsec implementation operates in a host, as a security gateway
368 (SG), or as an independent device, affording protection to IP
369 traffic. (A security gateway is an intermediate system implementing
370 IPsec, e.g., a firewall or router that has been IPsec-enabled.) More
371 detail on these classes of implementations is provided later, in
372 Section 3.3. The protection offered by IPsec is based on requirements
373 defined by a Security Policy Database (SPD) established and
374 maintained by a user or system administrator, or by an application
375 operating within constraints established by either of the above. In
376 general, packets are selected for one of three processing actions
377 based on IP and next layer header information ("Selectors", Section
378 4.4.1.1) matched against entries in the SPD. Each packet is either
379 PROTECTed using IPsec security services, DISCARDed, or allowed to
380 BYPASS IPsec protection, based on the applicable SPD policies
381 identified by the Selectors.
385 IPsec creates a boundary between unprotected and protected
386 interfaces, for a host or a network (see Figure 1 below). Traffic
387 traversing the boundary is subject to the access controls specified
388 by the user or administrator responsible for the IPsec configuration.
389 These controls indicate whether packets cross the boundary unimpeded,
390 are afforded security services via AH or ESP, or are discarded.
394 Kent & Seo Standards Track [Page 7]
396 RFC 4301 Security Architecture for IP December 2005
399 IPsec security services are offered at the IP layer through selection
400 of appropriate security protocols, cryptographic algorithms, and
401 cryptographic keys. IPsec can be used to protect one or more "paths"
402 (a) between a pair of hosts, (b) between a pair of security gateways,
403 or (c) between a security gateway and a host. A compliant host
404 implementation MUST support (a) and (c) and a compliant security
405 gateway must support all three of these forms of connectivity, since
406 under certain circumstances a security gateway acts as a host.
411 +-------------|-------|-------+
414 | +-------+ |B +--------+ |
415 ................|y..| AH/ESP |..... IPsec Boundary
416 | +---+ |p +--------+ |
422 +-------------|-------|-------+
427 Figure 1. Top Level IPsec Processing Model
429 In this diagram, "unprotected" refers to an interface that might also
430 be described as "black" or "ciphertext". Here, "protected" refers to
431 an interface that might also be described as "red" or "plaintext".
432 The protected interface noted above may be internal, e.g., in a host
433 implementation of IPsec, the protected interface may link to a socket
434 layer interface presented by the OS. In this document, the term
435 "inbound" refers to traffic entering an IPsec implementation via the
436 unprotected interface or emitted by the implementation on the
437 unprotected side of the boundary and directed towards the protected
438 interface. The term "outbound" refers to traffic entering the
439 implementation via the protected interface, or emitted by the
440 implementation on the protected side of the boundary and directed
441 toward the unprotected interface. An IPsec implementation may
442 support more than one interface on either or both sides of the
450 Kent & Seo Standards Track [Page 8]
452 RFC 4301 Security Architecture for IP December 2005
455 Note the facilities for discarding traffic on either side of the
456 IPsec boundary, the BYPASS facility that allows traffic to transit
457 the boundary without cryptographic protection, and the reference to
458 IKE as a protected-side key and security management function.
460 IPsec optionally supports negotiation of IP compression [SMPT01],
461 motivated in part by the observation that when encryption is employed
462 within IPsec, it prevents effective compression by lower protocol
467 IPsec uses two protocols to provide traffic security services --
468 Authentication Header (AH) and Encapsulating Security Payload (ESP).
469 Both protocols are described in detail in their respective RFCs
470 [Ken05b, Ken05a]. IPsec implementations MUST support ESP and MAY
471 support AH. (Support for AH has been downgraded to MAY because
472 experience has shown that there are very few contexts in which ESP
473 cannot provide the requisite security services. Note that ESP can be
474 used to provide only integrity, without confidentiality, making it
475 comparable to AH in most contexts.)
477 o The IP Authentication Header (AH) [Ken05b] offers integrity and
478 data origin authentication, with optional (at the discretion of
479 the receiver) anti-replay features.
481 o The Encapsulating Security Payload (ESP) protocol [Ken05a] offers
482 the same set of services, and also offers confidentiality. Use of
483 ESP to provide confidentiality without integrity is NOT
484 RECOMMENDED. When ESP is used with confidentiality enabled, there
485 are provisions for limited traffic flow confidentiality, i.e.,
486 provisions for concealing packet length, and for facilitating
487 efficient generation and discard of dummy packets. This
488 capability is likely to be effective primarily in virtual private
489 network (VPN) and overlay network contexts.
491 o Both AH and ESP offer access control, enforced through the
492 distribution of cryptographic keys and the management of traffic
493 flows as dictated by the Security Policy Database (SPD, Section
496 These protocols may be applied individually or in combination with
497 each other to provide IPv4 and IPv6 security services. However, most
498 security requirements can be met through the use of ESP by itself.
499 Each protocol supports two modes of use: transport mode and tunnel
500 mode. In transport mode, AH and ESP provide protection primarily for
506 Kent & Seo Standards Track [Page 9]
508 RFC 4301 Security Architecture for IP December 2005
511 next layer protocols; in tunnel mode, AH and ESP are applied to
512 tunneled IP packets. The differences between the two modes are
513 discussed in Section 4.1.
515 IPsec allows the user (or system administrator) to control the
516 granularity at which a security service is offered. For example, one
517 can create a single encrypted tunnel to carry all the traffic between
518 two security gateways, or a separate encrypted tunnel can be created
519 for each TCP connection between each pair of hosts communicating
520 across these gateways. IPsec, through the SPD management paradigm,
521 incorporates facilities for specifying:
523 o which security protocol (AH or ESP) to employ, the mode (transport
524 or tunnel), security service options, what cryptographic
525 algorithms to use, and in what combinations to use the specified
526 protocols and services, and
528 o the granularity at which protection should be applied.
530 Because most of the security services provided by IPsec require the
531 use of cryptographic keys, IPsec relies on a separate set of
532 mechanisms for putting these keys in place. This document requires
533 support for both manual and automated distribution of keys. It
534 specifies a specific public-key based approach (IKEv2 [Kau05]) for
535 automated key management, but other automated key distribution
536 techniques MAY be used.
538 Note: This document mandates support for several features for which
539 support is available in IKEv2 but not in IKEv1, e.g., negotiation of
540 an SA representing ranges of local and remote ports or negotiation of
541 multiple SAs with the same selectors. Therefore, this document
542 assumes use of IKEv2 or a key and security association management
543 system with comparable features.
545 3.3. Where IPsec Can Be Implemented
547 There are many ways in which IPsec may be implemented in a host, or
548 in conjunction with a router or firewall to create a security
549 gateway, or as an independent security device.
551 a. IPsec may be integrated into the native IP stack. This requires
552 access to the IP source code and is applicable to both hosts and
553 security gateways, although native host implementations benefit
554 the most from this strategy, as explained later (Section 4.4.1,
555 paragraph 6; Section 4.4.1.1, last paragraph).
562 Kent & Seo Standards Track [Page 10]
564 RFC 4301 Security Architecture for IP December 2005
567 b. In a "bump-in-the-stack" (BITS) implementation, IPsec is
568 implemented "underneath" an existing implementation of an IP
569 protocol stack, between the native IP and the local network
570 drivers. Source code access for the IP stack is not required in
571 this context, making this implementation approach appropriate for
572 use with legacy systems. This approach, when it is adopted, is
573 usually employed in hosts.
575 c. The use of a dedicated, inline security protocol processor is a
576 common design feature of systems used by the military, and of some
577 commercial systems as well. It is sometimes referred to as a
578 "bump-in-the-wire" (BITW) implementation. Such implementations
579 may be designed to serve either a host or a gateway. Usually, the
580 BITW device is itself IP addressable. When supporting a single
581 host, it may be quite analogous to a BITS implementation, but in
582 supporting a router or firewall, it must operate like a security
585 This document often talks in terms of use of IPsec by a host or a
586 security gateway, without regard to whether the implementation is
587 native, BITS, or BITW. When the distinctions among these
588 implementation options are significant, the document makes reference
589 to specific implementation approaches.
591 A host implementation of IPsec may appear in devices that might not
592 be viewed as "hosts". For example, a router might employ IPsec to
593 protect routing protocols (e.g., BGP) and management functions (e.g.,
594 Telnet), without affecting subscriber traffic traversing the router.
595 A security gateway might employ separate IPsec implementations to
596 protect its management traffic and subscriber traffic. The
597 architecture described in this document is very flexible. For
598 example, a computer with a full-featured, compliant, native OS IPsec
599 implementation should be capable of being configured to protect
600 resident (host) applications and to provide security gateway
601 protection for traffic traversing the computer. Such configuration
602 would make use of the forwarding tables and the SPD selection
603 function described in Sections 5.1 and 5.2.
605 4. Security Associations
607 This section defines Security Association management requirements for
608 all IPv6 implementations and for those IPv4 implementations that
609 implement AH, ESP, or both AH and ESP. The concept of a "Security
610 Association" (SA) is fundamental to IPsec. Both AH and ESP make use
611 of SAs, and a major function of IKE is the establishment and
612 maintenance of SAs. All implementations of AH or ESP MUST support
613 the concept of an SA as described below. The remainder of this
618 Kent & Seo Standards Track [Page 11]
620 RFC 4301 Security Architecture for IP December 2005
623 section describes various aspects of SA management, defining required
624 characteristics for SA policy management and SA management
627 4.1. Definition and Scope
629 An SA is a simplex "connection" that affords security services to the
630 traffic carried by it. Security services are afforded to an SA by
631 the use of AH, or ESP, but not both. If both AH and ESP protection
632 are applied to a traffic stream, then two SAs must be created and
633 coordinated to effect protection through iterated application of the
634 security protocols. To secure typical, bi-directional communication
635 between two IPsec-enabled systems, a pair of SAs (one in each
636 direction) is required. IKE explicitly creates SA pairs in
637 recognition of this common usage requirement.
639 For an SA used to carry unicast traffic, the Security Parameters
640 Index (SPI) by itself suffices to specify an SA. (For information on
641 the SPI, see Appendix A and the AH and ESP specifications [Ken05b,
642 Ken05a].) However, as a local matter, an implementation may choose
643 to use the SPI in conjunction with the IPsec protocol type (AH or
644 ESP) for SA identification. If an IPsec implementation supports
645 multicast, then it MUST support multicast SAs using the algorithm
646 below for mapping inbound IPsec datagrams to SAs. Implementations
647 that support only unicast traffic need not implement this de-
648 multiplexing algorithm.
650 In many secure multicast architectures, e.g., [RFC3740], a central
651 Group Controller/Key Server unilaterally assigns the Group Security
652 Association's (GSA's) SPI. This SPI assignment is not negotiated or
653 coordinated with the key management (e.g., IKE) subsystems that
654 reside in the individual end systems that constitute the group.
655 Consequently, it is possible that a GSA and a unicast SA can
656 simultaneously use the same SPI. A multicast-capable IPsec
657 implementation MUST correctly de-multiplex inbound traffic even in
658 the context of SPI collisions.
660 Each entry in the SA Database (SAD) (Section 4.4.2) must indicate
661 whether the SA lookup makes use of the destination IP address, or the
662 destination and source IP addresses, in addition to the SPI. For
663 multicast SAs, the protocol field is not employed for SA lookups.
664 For each inbound, IPsec-protected packet, an implementation must
665 conduct its search of the SAD such that it finds the entry that
666 matches the "longest" SA identifier. In this context, if two or more
667 SAD entries match based on the SPI value, then the entry that also
668 matches based on destination address, or destination and source
669 address (as indicated in the SAD entry) is the "longest" match. This
670 implies a logical ordering of the SAD search as follows:
674 Kent & Seo Standards Track [Page 12]
676 RFC 4301 Security Architecture for IP December 2005
679 1. Search the SAD for a match on the combination of SPI,
680 destination address, and source address. If an SAD entry
681 matches, then process the inbound packet with that
682 matching SAD entry. Otherwise, proceed to step 2.
684 2. Search the SAD for a match on both SPI and destination address.
685 If the SAD entry matches, then process the inbound packet
686 with that matching SAD entry. Otherwise, proceed to step 3.
688 3. Search the SAD for a match on only SPI if the receiver has
689 chosen to maintain a single SPI space for AH and ESP, and on
690 both SPI and protocol, otherwise. If an SAD entry matches,
691 then process the inbound packet with that matching SAD entry.
692 Otherwise, discard the packet and log an auditable event.
694 In practice, an implementation may choose any method (or none at all)
695 to accelerate this search, although its externally visible behavior
696 MUST be functionally equivalent to having searched the SAD in the
697 above order. For example, a software-based implementation could
698 index into a hash table by the SPI. The SAD entries in each hash
699 table bucket's linked list could be kept sorted to have those SAD
700 entries with the longest SA identifiers first in that linked list.
701 Those SAD entries having the shortest SA identifiers could be sorted
702 so that they are the last entries in the linked list. A
703 hardware-based implementation may be able to effect the longest match
704 search intrinsically, using commonly available Ternary
705 Content-Addressable Memory (TCAM) features.
707 The indication of whether source and destination address matching is
708 required to map inbound IPsec traffic to SAs MUST be set either as a
709 side effect of manual SA configuration or via negotiation using an SA
710 management protocol, e.g., IKE or Group Domain of Interpretation
711 (GDOI) [RFC3547]. Typically, Source-Specific Multicast (SSM) [HC03]
712 groups use a 3-tuple SA identifier composed of an SPI, a destination
713 multicast address, and source address. An Any-Source Multicast group
714 SA requires only an SPI and a destination multicast address as an
717 If different classes of traffic (distinguished by Differentiated
718 Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on
719 the same SA, and if the receiver is employing the optional
720 anti-replay feature available in both AH and ESP, this could result
721 in inappropriate discarding of lower priority packets due to the
722 windowing mechanism used by this feature. Therefore, a sender SHOULD
723 put traffic of different classes, but with the same selector values,
724 on different SAs to support Quality of Service (QoS) appropriately.
725 To permit this, the IPsec implementation MUST permit establishment
726 and maintenance of multiple SAs between a given sender and receiver,
730 Kent & Seo Standards Track [Page 13]
732 RFC 4301 Security Architecture for IP December 2005
735 with the same selectors. Distribution of traffic among these
736 parallel SAs to support QoS is locally determined by the sender and
737 is not negotiated by IKE. The receiver MUST process the packets from
738 the different SAs without prejudice. These requirements apply to
739 both transport and tunnel mode SAs. In the case of tunnel mode SAs,
740 the DSCP values in question appear in the inner IP header. In
741 transport mode, the DSCP value might change en route, but this should
742 not cause problems with respect to IPsec processing since the value
743 is not employed for SA selection and MUST NOT be checked as part of
744 SA/packet validation. However, if significant re-ordering of packets
745 occurs in an SA, e.g., as a result of changes to DSCP values en
746 route, this may trigger packet discarding by a receiver due to
747 application of the anti-replay mechanism.
749 DISCUSSION: Although the DSCP [NiBlBaBL98, Gro02] and Explicit
750 Congestion Notification (ECN) [RaFlBl01] fields are not "selectors",
751 as that term in used in this architecture, the sender will need a
752 mechanism to direct packets with a given (set of) DSCP values to the
753 appropriate SA. This mechanism might be termed a "classifier".
755 As noted above, two types of SAs are defined: transport mode and
756 tunnel mode. IKE creates pairs of SAs, so for simplicity, we choose
757 to require that both SAs in a pair be of the same mode, transport or
760 A transport mode SA is an SA typically employed between a pair of
761 hosts to provide end-to-end security services. When security is
762 desired between two intermediate systems along a path (vs. end-to-end
763 use of IPsec), transport mode MAY be used between security gateways
764 or between a security gateway and a host. In the case where
765 transport mode is used between security gateways or between a
766 security gateway and a host, transport mode may be used to support
767 in-IP tunneling (e.g., IP-in-IP [Per96] or Generic Routing
768 Encapsulation (GRE) tunneling [FaLiHaMeTr00] or dynamic routing
769 [ToEgWa04]) over transport mode SAs. To clarify, the use of
770 transport mode by an intermediate system (e.g., a security gateway)
771 is permitted only when applied to packets whose source address (for
772 outbound packets) or destination address (for inbound packets) is an
773 address belonging to the intermediate system itself. The access
774 control functions that are an important part of IPsec are
775 significantly limited in this context, as they cannot be applied to
776 the end-to-end headers of the packets that traverse a transport mode
777 SA used in this fashion. Thus, this way of using transport mode
778 should be evaluated carefully before being employed in a specific
786 Kent & Seo Standards Track [Page 14]
788 RFC 4301 Security Architecture for IP December 2005
791 In IPv4, a transport mode security protocol header appears
792 immediately after the IP header and any options, and before any next
793 layer protocols (e.g., TCP or UDP). In IPv6, the security protocol
794 header appears after the base IP header and selected extension
795 headers, but may appear before or after destination options; it MUST
796 appear before next layer protocols (e.g., TCP, UDP, Stream Control
797 Transmission Protocol (SCTP)). In the case of ESP, a transport mode
798 SA provides security services only for these next layer protocols,
799 not for the IP header or any extension headers preceding the ESP
800 header. In the case of AH, the protection is also extended to
801 selected portions of the IP header preceding it, selected portions of
802 extension headers, and selected options (contained in the IPv4
803 header, IPv6 Hop-by-Hop extension header, or IPv6 Destination
804 extension headers). For more details on the coverage afforded by AH,
805 see the AH specification [Ken05b].
807 A tunnel mode SA is essentially an SA applied to an IP tunnel, with
808 the access controls applied to the headers of the traffic inside the
809 tunnel. Two hosts MAY establish a tunnel mode SA between themselves.
810 Aside from the two exceptions below, whenever either end of a
811 security association is a security gateway, the SA MUST be tunnel
812 mode. Thus, an SA between two security gateways is typically a
813 tunnel mode SA, as is an SA between a host and a security gateway.
814 The two exceptions are as follows.
816 o Where traffic is destined for a security gateway, e.g., Simple
817 Network Management Protocol (SNMP) commands, the security gateway
818 is acting as a host and transport mode is allowed. In this case,
819 the SA terminates at a host (management) function within a
820 security gateway and thus merits different treatment.
822 o As noted above, security gateways MAY support a transport mode SA
823 to provide security for IP traffic between two intermediate
824 systems along a path, e.g., between a host and a security gateway
825 or between two security gateways.
827 Several concerns motivate the use of tunnel mode for an SA involving
828 a security gateway. For example, if there are multiple paths (e.g.,
829 via different security gateways) to the same destination behind a
830 security gateway, it is important that an IPsec packet be sent to the
831 security gateway with which the SA was negotiated. Similarly, a
832 packet that might be fragmented en route must have all the fragments
833 delivered to the same IPsec instance for reassembly prior to
834 cryptographic processing. Also, when a fragment is processed by
835 IPsec and transmitted, then fragmented en route, it is critical that
836 there be inner and outer headers to retain the fragmentation state
837 data for the pre- and post-IPsec packet formats. Hence there are
838 several reasons for employing tunnel mode when either end of an SA is
842 Kent & Seo Standards Track [Page 15]
844 RFC 4301 Security Architecture for IP December 2005
847 a security gateway. (Use of an IP-in-IP tunnel in conjunction with
848 transport mode can also address these fragmentation issues. However,
849 this configuration limits the ability of IPsec to enforce access
850 control policies on traffic.)
852 Note: AH and ESP cannot be applied using transport mode to IPv4
853 packets that are fragments. Only tunnel mode can be employed in such
854 cases. For IPv6, it would be feasible to carry a plaintext fragment
855 on a transport mode SA; however, for simplicity, this restriction
856 also applies to IPv6 packets. See Section 7 for more details on
857 handling plaintext fragments on the protected side of the IPsec
860 For a tunnel mode SA, there is an "outer" IP header that specifies
861 the IPsec processing source and destination, plus an "inner" IP
862 header that specifies the (apparently) ultimate source and
863 destination for the packet. The security protocol header appears
864 after the outer IP header, and before the inner IP header. If AH is
865 employed in tunnel mode, portions of the outer IP header are afforded
866 protection (as above), as well as all of the tunneled IP packet
867 (i.e., all of the inner IP header is protected, as well as next layer
868 protocols). If ESP is employed, the protection is afforded only to
869 the tunneled packet, not to the outer header.
873 a) A host implementation of IPsec MUST support both transport and
874 tunnel mode. This is true for native, BITS, and BITW
875 implementations for hosts.
877 b) A security gateway MUST support tunnel mode and MAY support
878 transport mode. If it supports transport mode, that should be
879 used only when the security gateway is acting as a host, e.g., for
880 network management, or to provide security between two
881 intermediate systems along a path.
883 4.2. SA Functionality
885 The set of security services offered by an SA depends on the security
886 protocol selected, the SA mode, the endpoints of the SA, and the
887 election of optional services within the protocol.
889 For example, both AH and ESP offer integrity and authentication
890 services, but the coverage differs for each protocol and differs for
891 transport vs. tunnel mode. If the integrity of an IPv4 option or
892 IPv6 extension header must be protected en route between sender and
893 receiver, AH can provide this service, except for IP or extension
894 headers that may change in a fashion not predictable by the sender.
898 Kent & Seo Standards Track [Page 16]
900 RFC 4301 Security Architecture for IP December 2005
903 However, the same security may be achieved in some contexts by
904 applying ESP to a tunnel carrying a packet.
906 The granularity of access control provided is determined by the
907 choice of the selectors that define each SA. Moreover, the
908 authentication means employed by IPsec peers, e.g., during creation
909 of an IKE (vs. child) SA also affects the granularity of the access
912 If confidentiality is selected, then an ESP (tunnel mode) SA between
913 two security gateways can offer partial traffic flow confidentiality.
914 The use of tunnel mode allows the inner IP headers to be encrypted,
915 concealing the identities of the (ultimate) traffic source and
916 destination. Moreover, ESP payload padding also can be invoked to
917 hide the size of the packets, further concealing the external
918 characteristics of the traffic. Similar traffic flow confidentiality
919 services may be offered when a mobile user is assigned a dynamic IP
920 address in a dialup context, and establishes a (tunnel mode) ESP SA
921 to a corporate firewall (acting as a security gateway). Note that
922 fine-granularity SAs generally are more vulnerable to traffic
923 analysis than coarse-granularity ones that are carrying traffic from
926 Note: A compliant implementation MUST NOT allow instantiation of an
927 ESP SA that employs both NULL encryption and no integrity algorithm.
928 An attempt to negotiate such an SA is an auditable event by both
929 initiator and responder. The audit log entry for this event SHOULD
930 include the current date/time, local IKE IP address, and remote IKE
931 IP address. The initiator SHOULD record the relevant SPD entry.
935 This document does not require support for nested security
936 associations or for what RFC 2401 [RFC2401] called "SA bundles".
937 These features still can be effected by appropriate configuration of
938 both the SPD and the local forwarding functions (for inbound and
939 outbound traffic), but this capability is outside of the IPsec module
940 and thus the scope of this specification. As a result, management of
941 nested/bundled SAs is potentially more complex and less assured than
942 under the model implied by RFC 2401 [RFC2401]. An implementation
943 that provides support for nested SAs SHOULD provide a management
944 interface that enables a user or administrator to express the nesting
945 requirement, and then create the appropriate SPD entries and
946 forwarding table entries to effect the requisite processing. (See
947 Appendix E for an example of how to configure nested SAs.)
954 Kent & Seo Standards Track [Page 17]
956 RFC 4301 Security Architecture for IP December 2005
959 4.4. Major IPsec Databases
961 Many of the details associated with processing IP traffic in an IPsec
962 implementation are largely a local matter, not subject to
963 standardization. However, some external aspects of the processing
964 must be standardized to ensure interoperability and to provide a
965 minimum management capability that is essential for productive use of
966 IPsec. This section describes a general model for processing IP
967 traffic relative to IPsec functionality, in support of these
968 interoperability and functionality goals. The model described below
969 is nominal; implementations need not match details of this model as
970 presented, but the external behavior of implementations MUST
971 correspond to the externally observable characteristics of this model
972 in order to be compliant.
974 There are three nominal databases in this model: the Security Policy
975 Database (SPD), the Security Association Database (SAD), and the Peer
976 Authorization Database (PAD). The first specifies the policies that
977 determine the disposition of all IP traffic inbound or outbound from
978 a host or security gateway (Section 4.4.1). The second database
979 contains parameters that are associated with each established (keyed)
980 SA (Section 4.4.2). The third database, the PAD, provides a link
981 between an SA management protocol (such as IKE) and the SPD (Section
984 Multiple Separate IPsec Contexts
986 If an IPsec implementation acts as a security gateway for multiple
987 subscribers, it MAY implement multiple separate IPsec contexts.
988 Each context MAY have and MAY use completely independent
989 identities, policies, key management SAs, and/or IPsec SAs. This
990 is for the most part a local implementation matter. However, a
991 means for associating inbound (SA) proposals with local contexts
992 is required. To this end, if supported by the key management
993 protocol in use, context identifiers MAY be conveyed from
994 initiator to responder in the signaling messages, with the result
995 that IPsec SAs are created with a binding to a particular context.
996 For example, a security gateway that provides VPN service to
997 multiple customers will be able to associate each customer's
998 traffic with the correct VPN.
1000 Forwarding vs Security Decisions
1002 The IPsec model described here embodies a clear separation between
1003 forwarding (routing) and security decisions, to accommodate a wide
1004 range of contexts where IPsec may be employed. Forwarding may be
1005 trivial, in the case where there are only two interfaces, or it
1006 may be complex, e.g., if the context in which IPsec is implemented
1010 Kent & Seo Standards Track [Page 18]
1012 RFC 4301 Security Architecture for IP December 2005
1015 employs a sophisticated forwarding function. IPsec assumes only
1016 that outbound and inbound traffic that has passed through IPsec
1017 processing is forwarded in a fashion consistent with the context
1018 in which IPsec is implemented. Support for nested SAs is
1019 optional; if required, it requires coordination between forwarding
1020 tables and SPD entries to cause a packet to traverse the IPsec
1021 boundary more than once.
1025 In this document, with respect to IP addresses and ports, the
1026 terms "Local" and "Remote" are used for policy rules. "Local"
1027 refers to the entity being protected by an IPsec implementation,
1028 i.e., the "source" address/port of outbound packets or the
1029 "destination" address/port of inbound packets. "Remote" refers to
1030 a peer entity or peer entities. The terms "source" and
1031 "destination" are used for packet header fields.
1033 "Non-initial" vs "Initial" Fragments
1035 Throughout this document, the phrase "non-initial fragments" is
1036 used to mean fragments that do not contain all of the selector
1037 values that may be needed for access control (e.g., they might not
1038 contain Next Layer Protocol, source and destination ports, ICMP
1039 message type/code, Mobility Header type). And the phrase "initial
1040 fragment" is used to mean a fragment that contains all the
1041 selector values needed for access control. However, it should be
1042 noted that for IPv6, which fragment contains the Next Layer
1043 Protocol and ports (or ICMP message type/code or Mobility Header
1044 type [Mobip]) will depend on the kind and number of extension
1045 headers present. The "initial fragment" might not be the first
1046 fragment, in this context.
1048 4.4.1. The Security Policy Database (SPD)
1050 An SA is a management construct used to enforce security policy for
1051 traffic crossing the IPsec boundary. Thus, an essential element of
1052 SA processing is an underlying Security Policy Database (SPD) that
1053 specifies what services are to be offered to IP datagrams and in what
1054 fashion. The form of the database and its interface are outside the
1055 scope of this specification. However, this section specifies minimum
1056 management functionality that must be provided, to allow a user or
1057 system administrator to control whether and how IPsec is applied to
1058 traffic transmitted or received by a host or transiting a security
1059 gateway. The SPD, or relevant caches, must be consulted during the
1060 processing of all traffic (inbound and outbound), including traffic
1061 not protected by IPsec, that traverses the IPsec boundary. This
1062 includes IPsec management traffic such as IKE. An IPsec
1066 Kent & Seo Standards Track [Page 19]
1068 RFC 4301 Security Architecture for IP December 2005
1071 implementation MUST have at least one SPD, and it MAY support
1072 multiple SPDs, if appropriate for the context in which the IPsec
1073 implementation operates. There is no requirement to maintain SPDs on
1074 a per-interface basis, as was specified in RFC 2401 [RFC2401].
1075 However, if an implementation supports multiple SPDs, then it MUST
1076 include an explicit SPD selection function that is invoked to select
1077 the appropriate SPD for outbound traffic processing. The inputs to
1078 this function are the outbound packet and any local metadata (e.g.,
1079 the interface via which the packet arrived) required to effect the
1080 SPD selection function. The output of the function is an SPD
1081 identifier (SPD-ID).
1083 The SPD is an ordered database, consistent with the use of Access
1084 Control Lists (ACLs) or packet filters in firewalls, routers, etc.
1085 The ordering requirement arises because entries often will overlap
1086 due to the presence of (non-trivial) ranges as values for selectors.
1087 Thus, a user or administrator MUST be able to order the entries to
1088 express a desired access control policy. There is no way to impose a
1089 general, canonical order on SPD entries, because of the allowed use
1090 of wildcards for selector values and because the different types of
1091 selectors are not hierarchically related.
1093 Processing Choices: DISCARD, BYPASS, PROTECT
1095 An SPD must discriminate among traffic that is afforded IPsec
1096 protection and traffic that is allowed to bypass IPsec. This
1097 applies to the IPsec protection to be applied by a sender and to
1098 the IPsec protection that must be present at the receiver. For
1099 any outbound or inbound datagram, three processing choices are
1100 possible: DISCARD, BYPASS IPsec, or PROTECT using IPsec. The
1101 first choice refers to traffic that is not allowed to traverse the
1102 IPsec boundary (in the specified direction). The second choice
1103 refers to traffic that is allowed to cross the IPsec boundary
1104 without IPsec protection. The third choice refers to traffic that
1105 is afforded IPsec protection, and for such traffic the SPD must
1106 specify the security protocols to be employed, their mode,
1107 security service options, and the cryptographic algorithms to be
1112 An SPD is logically divided into three pieces. The SPD-S (secure
1113 traffic) contains entries for all traffic subject to IPsec
1114 protection. SPD-O (outbound) contains entries for all outbound
1115 traffic that is to be bypassed or discarded. SPD-I (inbound) is
1116 applied to inbound traffic that will be bypassed or discarded.
1117 All three of these can be decorrelated (with the exception noted
1118 above for native host implementations) to facilitate caching. If
1122 Kent & Seo Standards Track [Page 20]
1124 RFC 4301 Security Architecture for IP December 2005
1127 an IPsec implementation supports only one SPD, then the SPD
1128 consists of all three parts. If multiple SPDs are supported, some
1129 of them may be partial, e.g., some SPDs might contain only SPD-I
1130 entries, to control inbound bypassed traffic on a per-interface
1131 basis. The split allows SPD-I to be consulted without having to
1132 consult SPD-S, for such traffic. Since the SPD-I is just a part
1133 of the SPD, if a packet that is looked up in the SPD-I cannot be
1134 matched to an entry there, then the packet MUST be discarded.
1135 Note that for outbound traffic, if a match is not found in SPD-S,
1136 then SPD-O must be checked to see if the traffic should be
1137 bypassed. Similarly, if SPD-O is checked first and no match is
1138 found, then SPD-S must be checked. In an ordered,
1139 non-decorrelated SPD, the entries for the SPD-S, SPD-I, and SPD-O
1140 are interleaved. So there is one lookup in the SPD.
1144 Each SPD entry specifies packet disposition as BYPASS, DISCARD, or
1145 PROTECT. The entry is keyed by a list of one or more selectors.
1146 The SPD contains an ordered list of these entries. The required
1147 selector types are defined in Section 4.4.1.1. These selectors are
1148 used to define the granularity of the SAs that are created in
1149 response to an outbound packet or in response to a proposal from a
1150 peer. The detailed structure of an SPD entry is described in
1151 Section 4.4.1.2. Every SPD SHOULD have a nominal, final entry that
1152 matches anything that is otherwise unmatched, and discards it.
1154 The SPD MUST permit a user or administrator to specify policy
1157 - SPD-I: For inbound traffic that is to be bypassed or discarded,
1158 the entry consists of the values of the selectors that apply to
1159 the traffic to be bypassed or discarded.
1161 - SPD-O: For outbound traffic that is to be bypassed or
1162 discarded, the entry consists of the values of the selectors
1163 that apply to the traffic to be bypassed or discarded.
1165 - SPD-S: For traffic that is to be protected using IPsec, the
1166 entry consists of the values of the selectors that apply to the
1167 traffic to be protected via AH or ESP, controls on how to
1168 create SAs based on these selectors, and the parameters needed
1169 to effect this protection (e.g., algorithms, modes, etc.). Note
1170 that an SPD-S entry also contains information such as "populate
1171 from packet" (PFP) flag (see paragraphs below on "How To Derive
1172 the Values for an SAD entry") and bits indicating whether the
1178 Kent & Seo Standards Track [Page 21]
1180 RFC 4301 Security Architecture for IP December 2005
1183 SA lookup makes use of the local and remote IP addresses in
1184 addition to the SPI (see AH [Ken05b] or ESP [Ken05a]
1187 Representing Directionality in an SPD Entry
1189 For traffic protected by IPsec, the Local and Remote address and
1190 ports in an SPD entry are swapped to represent directionality,
1191 consistent with IKE conventions. In general, the protocols that
1192 IPsec deals with have the property of requiring symmetric SAs with
1193 flipped Local/Remote IP addresses. However, for ICMP, there is
1194 often no such bi-directional authorization requirement.
1195 Nonetheless, for the sake of uniformity and simplicity, SPD
1196 entries for ICMP are specified in the same way as for other
1197 protocols. Note also that for ICMP, Mobility Header, and
1198 non-initial fragments, there are no port fields in these packets.
1199 ICMP has message type and code and Mobility Header has mobility
1200 header type. Thus, SPD entries have provisions for expressing
1201 access controls appropriate for these protocols, in lieu of the
1202 normal port field controls. For bypassed or discarded traffic,
1203 separate inbound and outbound entries are supported, e.g., to
1204 permit unidirectional flows if required.
1208 For each selector in an SPD entry, in addition to the literal
1209 values that define a match, there are two special values: ANY and
1210 OPAQUE. ANY is a wildcard that matches any value in the
1211 corresponding field of the packet, or that matches packets where
1212 that field is not present or is obscured. OPAQUE indicates that
1213 the corresponding selector field is not available for examination
1214 because it may not be present in a fragment, it does not exist for
1215 the given Next Layer Protocol, or prior application of IPsec may
1216 have encrypted the value. The ANY value encompasses the OPAQUE
1217 value. Thus, OPAQUE need be used only when it is necessary to
1218 distinguish between the case of any allowed value for a field, vs.
1219 the absence or unavailability (e.g., due to encryption) of the
1222 How to Derive the Values for an SAD Entry
1224 For each selector in an SPD entry, the entry specifies how to
1225 derive the corresponding values for a new SA Database (SAD, see
1226 Section 4.4.2) entry from those in the SPD and the packet. The
1227 goal is to allow an SAD entry and an SPD cache entry to be created
1228 based on specific selector values from the packet, or from the
1229 matching SPD entry. For outbound traffic, there are SPD-S cache
1230 entries and SPD-O cache entries. For inbound traffic not
1234 Kent & Seo Standards Track [Page 22]
1236 RFC 4301 Security Architecture for IP December 2005
1239 protected by IPsec, there are SPD-I cache entries and there is the
1240 SAD, which represents the cache for inbound IPsec-protected
1241 traffic (see Section 4.4.2). If IPsec processing is specified for
1242 an entry, a "populate from packet" (PFP) flag may be asserted for
1243 one or more of the selectors in the SPD entry (Local IP address;
1244 Remote IP address; Next Layer Protocol; and, depending on Next
1245 Layer Protocol, Local port and Remote port, or ICMP type/code, or
1246 Mobility Header type). If asserted for a given selector X, the
1247 flag indicates that the SA to be created should take its value for
1248 X from the value in the packet. Otherwise, the SA should take its
1249 value(s) for X from the value(s) in the SPD entry. Note: In the
1250 non-PFP case, the selector values negotiated by the SA management
1251 protocol (e.g., IKEv2) may be a subset of those in the SPD entry,
1252 depending on the SPD policy of the peer. Also, whether a single
1253 flag is used for, e.g., source port, ICMP type/code, and Mobility
1254 Header (MH) type, or a separate flag is used for each, is a local
1257 The following example illustrates the use of the PFP flag in the
1258 context of a security gateway or a BITS/BITW implementation.
1259 Consider an SPD entry where the allowed value for Remote address
1260 is a range of IPv4 addresses: 192.0.2.1 to 192.0.2.10. Suppose an
1261 outbound packet arrives with a destination address of 192.0.2.3,
1262 and there is no extant SA to carry this packet. The value used
1263 for the SA created to transmit this packet could be either of the
1264 two values shown below, depending on what the SPD entry for this
1265 selector says is the source of the selector value:
1267 PFP flag value example of new
1268 for the Remote SAD dest. address
1269 addr. selector selector value
1270 --------------- ------------
1271 a. PFP TRUE 192.0.2.3 (one host)
1272 b. PFP FALSE 192.0.2.1 to 192.0.2.10 (range of hosts)
1274 Note that if the SPD entry above had a value of ANY for the Remote
1275 address, then the SAD selector value would have to be ANY for case
1276 (b), but would still be as illustrated for case (a). Thus, the
1277 PFP flag can be used to prohibit sharing of an SA, even among
1278 packets that match the same SPD entry.
1280 Management Interface
1282 For every IPsec implementation, there MUST be a management
1283 interface that allows a user or system administrator to manage the
1284 SPD. The interface must allow the user (or administrator) to
1285 specify the security processing to be applied to every packet that
1286 traverses the IPsec boundary. (In a native host IPsec
1290 Kent & Seo Standards Track [Page 23]
1292 RFC 4301 Security Architecture for IP December 2005
1295 implementation making use of a socket interface, the SPD may not
1296 need to be consulted on a per-packet basis, as noted at the end of
1297 Section 4.4.1.1 and in Section 5.) The management interface for
1298 the SPD MUST allow creation of entries consistent with the
1299 selectors defined in Section 4.4.1.1, and MUST support (total)
1300 ordering of these entries, as seen via this interface. The SPD
1301 entries' selectors are analogous to the ACL or packet filters
1302 commonly found in a stateless firewall or packet filtering router
1303 and which are currently managed this way.
1305 In host systems, applications MAY be allowed to create SPD
1306 entries. (The means of signaling such requests to the IPsec
1307 implementation are outside the scope of this standard.) However,
1308 the system administrator MUST be able to specify whether or not a
1309 user or application can override (default) system policies. The
1310 form of the management interface is not specified by this document
1311 and may differ for hosts vs. security gateways, and within hosts
1312 the interface may differ for socket-based vs. BITS
1313 implementations. However, this document does specify a standard
1314 set of SPD elements that all IPsec implementations MUST support.
1318 The processing model described in this document assumes the
1319 ability to decorrelate overlapping SPD entries to permit caching,
1320 which enables more efficient processing of outbound traffic in
1321 security gateways and BITS/BITW implementations. Decorrelation
1322 [CoSa04] is only a means of improving performance and simplifying
1323 the processing description. This RFC does not require a compliant
1324 implementation to make use of decorrelation. For example, native
1325 host implementations typically make use of caching implicitly
1326 because they bind SAs to socket interfaces, and thus there is no
1327 requirement to be able to decorrelate SPD entries in these
1330 Note: Unless otherwise qualified, the use of "SPD" refers to the
1331 body of policy information in both ordered or decorrelated
1332 (unordered) state. Appendix B provides an algorithm that can be
1333 used to decorrelate SPD entries, but any algorithm that produces
1334 equivalent output may be used. Note that when an SPD entry is
1335 decorrelated all the resulting entries MUST be linked together, so
1336 that all members of the group derived from an individual, SPD
1337 entry (prior to decorrelation) can all be placed into caches and
1338 into the SAD at the same time. For example, suppose one starts
1339 with an entry A (from an ordered SPD) that when decorrelated,
1340 yields entries A1, A2, and A3. When a packet comes along that
1341 matches, say A2, and triggers the creation of an SA, the SA
1342 management protocol (e.g., IKEv2) negotiates A. And all 3
1346 Kent & Seo Standards Track [Page 24]
1348 RFC 4301 Security Architecture for IP December 2005
1351 decorrelated entries, A1, A2, and A3, are placed in the
1352 appropriate SPD-S cache and linked to the SA. The intent is that
1353 use of a decorrelated SPD ought not to create more SAs than would
1354 have resulted from use of a not-decorrelated SPD.
1356 If a decorrelated SPD is employed, there are three options for
1357 what an initiator sends to a peer via an SA management protocol
1358 (e.g., IKE). By sending the complete set of linked, decorrelated
1359 entries that were selected from the SPD, a peer is given the best
1360 possible information to enable selection of the appropriate SPD
1361 entry at its end, especially if the peer has also decorrelated its
1362 SPD. However, if a large number of decorrelated entries are
1363 linked, this may create large packets for SA negotiation, and
1364 hence fragmentation problems for the SA management protocol.
1366 Alternatively, the original entry from the (correlated) SPD may be
1367 retained and passed to the SA management protocol. Passing the
1368 correlated SPD entry keeps the use of a decorrelated SPD a local
1369 matter, not visible to peers, and avoids possible fragmentation
1370 concerns, although it provides less precise information to a
1371 responder for matching against the responder's SPD.
1373 An intermediate approach is to send a subset of the complete set
1374 of linked, decorrelated SPD entries. This approach can avoid the
1375 fragmentation problems cited above yet provide better information
1376 than the original, correlated entry. The major shortcoming of
1377 this approach is that it may cause additional SAs to be created
1378 later, since only a subset of the linked, decorrelated entries are
1379 sent to a peer. Implementers are free to employ any of the
1380 approaches cited above.
1382 A responder uses the traffic selector proposals it receives via an
1383 SA management protocol to select an appropriate entry in its SPD.
1384 The intent of the matching is to select an SPD entry and create an
1385 SA that most closely matches the intent of the initiator, so that
1386 traffic traversing the resulting SA will be accepted at both ends.
1387 If the responder employs a decorrelated SPD, it SHOULD use the
1388 decorrelated SPD entries for matching, as this will generally
1389 result in creation of SAs that are more likely to match the intent
1390 of both peers. If the responder has a correlated SPD, then it
1391 SHOULD match the proposals against the correlated entries. For
1392 IKEv2, use of a decorrelated SPD offers the best opportunity for a
1393 responder to generate a "narrowed" response.
1395 In all cases, when a decorrelated SPD is available, the
1396 decorrelated entries are used to populate the SPD-S cache. If the
1397 SPD is not decorrelated, caching is not allowed and an ordered
1402 Kent & Seo Standards Track [Page 25]
1404 RFC 4301 Security Architecture for IP December 2005
1407 search of SPD MUST be performed to verify that inbound traffic
1408 arriving on an SA is consistent with the access control policy
1409 expressed in the SPD.
1411 Handling Changes to the SPD While the System Is Running
1413 If a change is made to the SPD while the system is running, a
1414 check SHOULD be made of the effect of this change on extant SAs.
1415 An implementation SHOULD check the impact of an SPD change on
1416 extant SAs and SHOULD provide a user/administrator with a
1417 mechanism for configuring what actions to take, e.g., delete an
1418 affected SA, allow an affected SA to continue unchanged, etc.
1422 An SA may be fine-grained or coarse-grained, depending on the
1423 selectors used to define the set of traffic for the SA. For example,
1424 all traffic between two hosts may be carried via a single SA, and
1425 afforded a uniform set of security services. Alternatively, traffic
1426 between a pair of hosts might be spread over multiple SAs, depending
1427 on the applications being used (as defined by the Next Layer Protocol
1428 and related fields, e.g., ports), with different security services
1429 offered by different SAs. Similarly, all traffic between a pair of
1430 security gateways could be carried on a single SA, or one SA could be
1431 assigned for each communicating host pair. The following selector
1432 parameters MUST be supported by all IPsec implementations to
1433 facilitate control of SA granularity. Note that both Local and
1434 Remote addresses should either be IPv4 or IPv6, but not a mix of
1435 address types. Also, note that the Local/Remote port selectors (and
1436 ICMP message type and code, and Mobility Header type) may be labeled
1437 as OPAQUE to accommodate situations where these fields are
1438 inaccessible due to packet fragmentation.
1440 - Remote IP Address(es) (IPv4 or IPv6): This is a list of ranges
1441 of IP addresses (unicast, broadcast (IPv4 only)). This
1442 structure allows expression of a single IP address (via a
1443 trivial range), or a list of addresses (each a trivial range),
1444 or a range of addresses (low and high values, inclusive), as
1445 well as the most generic form of a list of ranges. Address
1446 ranges are used to support more than one remote system sharing
1447 the same SA, e.g., behind a security gateway.
1449 - Local IP Address(es) (IPv4 or IPv6): This is a list of ranges of
1450 IP addresses (unicast, broadcast (IPv4 only)). This structure
1451 allows expression of a single IP address (via a trivial range),
1452 or a list of addresses (each a trivial range), or a range of
1453 addresses (low and high values, inclusive), as well as the most
1454 generic form of a list of ranges. Address ranges are used to
1458 Kent & Seo Standards Track [Page 26]
1460 RFC 4301 Security Architecture for IP December 2005
1463 support more than one source system sharing the same SA, e.g.,
1464 behind a security gateway. Local refers to the address(es)
1465 being protected by this implementation (or policy entry).
1467 Note: The SPD does not include support for multicast address
1468 entries. To support multicast SAs, an implementation should
1469 make use of a Group SPD (GSPD) as defined in [RFC3740]. GSPD
1470 entries require a different structure, i.e., one cannot use the
1471 symmetric relationship associated with local and remote address
1472 values for unicast SAs in a multicast context. Specifically,
1473 outbound traffic directed to a multicast address on an SA would
1474 not be received on a companion, inbound SA with the multicast
1475 address as the source.
1477 - Next Layer Protocol: Obtained from the IPv4 "Protocol" or the
1478 IPv6 "Next Header" fields. This is an individual protocol
1479 number, ANY, or for IPv6 only, OPAQUE. The Next Layer Protocol
1480 is whatever comes after any IP extension headers that are
1481 present. To simplify locating the Next Layer Protocol, there
1482 SHOULD be a mechanism for configuring which IPv6 extension
1483 headers to skip. The default configuration for which protocols
1484 to skip SHOULD include the following protocols: 0 (Hop-by-hop
1485 options), 43 (Routing Header), 44 (Fragmentation Header), and 60
1486 (Destination Options). Note: The default list does NOT include
1487 51 (AH) or 50 (ESP). From a selector lookup point of view,
1488 IPsec treats AH and ESP as Next Layer Protocols.
1490 Several additional selectors depend on the Next Layer Protocol
1493 * If the Next Layer Protocol uses two ports (as do TCP, UDP,
1494 SCTP, and others), then there are selectors for Local and
1495 Remote Ports. Each of these selectors has a list of ranges
1496 of values. Note that the Local and Remote ports may not be
1497 available in the case of receipt of a fragmented packet or if
1498 the port fields have been protected by IPsec (encrypted);
1499 thus, a value of OPAQUE also MUST be supported. Note: In a
1500 non-initial fragment, port values will not be available. If
1501 a port selector specifies a value other than ANY or OPAQUE,
1502 it cannot match packets that are non-initial fragments. If
1503 the SA requires a port value other than ANY or OPAQUE, an
1504 arriving fragment without ports MUST be discarded. (See
1505 Section 7, "Handling Fragments".)
1507 * If the Next Layer Protocol is a Mobility Header, then there
1508 is a selector for IPv6 Mobility Header message type (MH type)
1509 [Mobip]. This is an 8-bit value that identifies a particular
1510 mobility message. Note that the MH type may not be available
1514 Kent & Seo Standards Track [Page 27]
1516 RFC 4301 Security Architecture for IP December 2005
1519 in the case of receipt of a fragmented packet. (See Section
1520 7, "Handling Fragments".) For IKE, the IPv6 Mobility Header
1521 message type (MH type) is placed in the most significant
1522 eight bits of the 16-bit local "port" selector.
1524 * If the Next Layer Protocol value is ICMP, then there is a
1525 16-bit selector for the ICMP message type and code. The
1526 message type is a single 8-bit value, which defines the type
1527 of an ICMP message, or ANY. The ICMP code is a single 8-bit
1528 value that defines a specific subtype for an ICMP message.
1529 For IKE, the message type is placed in the most significant 8
1530 bits of the 16-bit selector and the code is placed in the
1531 least significant 8 bits. This 16-bit selector can contain a
1532 single type and a range of codes, a single type and ANY code,
1533 and ANY type and ANY code. Given a policy entry with a range
1534 of Types (T-start to T-end) and a range of Codes (C-start to
1535 C-end), and an ICMP packet with Type t and Code c, an
1536 implementation MUST test for a match using
1538 (T-start*256) + C-start <= (t*256) + c <= (T-end*256) +
1541 Note that the ICMP message type and code may not be available
1542 in the case of receipt of a fragmented packet. (See Section
1543 7, "Handling Fragments".)
1545 - Name: This is not a selector like the others above. It is not
1546 acquired from a packet. A name may be used as a symbolic
1547 identifier for an IPsec Local or Remote address. Named SPD
1548 entries are used in two ways:
1550 1. A named SPD entry is used by a responder (not an initiator)
1551 in support of access control when an IP address would not be
1552 appropriate for the Remote IP address selector, e.g., for
1553 "road warriors". The name used to match this field is
1554 communicated during the IKE negotiation in the ID payload.
1555 In this context, the initiator's Source IP address (inner IP
1556 header in tunnel mode) is bound to the Remote IP address in
1557 the SAD entry created by the IKE negotiation. This address
1558 overrides the Remote IP address value in the SPD, when the
1559 SPD entry is selected in this fashion. All IPsec
1560 implementations MUST support this use of names.
1562 2. A named SPD entry may be used by an initiator to identify a
1563 user for whom an IPsec SA will be created (or for whom
1564 traffic may be bypassed). The initiator's IP source address
1565 (from inner IP header in tunnel mode) is used to replace the
1566 following if and when they are created:
1570 Kent & Seo Standards Track [Page 28]
1572 RFC 4301 Security Architecture for IP December 2005
1575 - local address in the SPD cache entry
1576 - local address in the outbound SAD entry
1577 - remote address in the inbound SAD entry
1579 Support for this use is optional for multi-user, native host
1580 implementations and not applicable to other implementations.
1581 Note that this name is used only locally; it is not
1582 communicated by the key management protocol. Also, name
1583 forms other than those used for case 1 above (responder) are
1584 applicable in the initiator context (see below).
1586 An SPD entry can contain both a name (or a list of names) and
1587 also values for the Local or Remote IP address.
1589 For case 1, responder, the identifiers employed in named SPD
1590 entries are one of the following four types:
1592 a. a fully qualified user name string (email), e.g.,
1593 mozart@foo.example.com
1594 (this corresponds to ID_RFC822_ADDR in IKEv2)
1596 b. a fully qualified DNS name, e.g.,
1598 (this corresponds to ID_FQDN in IKEv2)
1600 c. X.500 distinguished name, e.g., [WaKiHo97],
1601 CN = Stephen T. Kent, O = BBN Technologies,
1603 (this corresponds to ID_DER_ASN1_DN in IKEv2, after
1607 (this corresponds to Key_ID in IKEv2)
1609 For case 2, initiator, the identifiers employed in named SPD
1610 entries are of type byte string. They are likely to be Unix
1611 UIDs, Windows security IDs, or something similar, but could
1612 also be a user name or account name. In all cases, this
1613 identifier is only of local concern and is not transmitted.
1615 The IPsec implementation context determines how selectors are used.
1616 For example, a native host implementation typically makes use of a
1617 socket interface. When a new connection is established, the SPD can
1618 be consulted and an SA bound to the socket. Thus, traffic sent via
1619 that socket need not result in additional lookups to the SPD (SPD-O
1620 and SPD-S) cache. In contrast, a BITS, BITW, or security gateway
1621 implementation needs to look at each packet and perform an
1622 SPD-O/SPD-S cache lookup based on the selectors.
1626 Kent & Seo Standards Track [Page 29]
1628 RFC 4301 Security Architecture for IP December 2005
1631 4.4.1.2. Structure of an SPD Entry
1633 This section contains a prose description of an SPD entry. Also,
1634 Appendix C provides an example of an ASN.1 definition of an SPD
1637 This text describes the SPD in a fashion that is intended to map
1638 directly into IKE payloads to ensure that the policy required by SPD
1639 entries can be negotiated through IKE. Unfortunately, the semantics
1640 of the version of IKEv2 published concurrently with this document
1641 [Kau05] do not align precisely with those defined for the SPD.
1642 Specifically, IKEv2 does not enable negotiation of a single SA that
1643 binds multiple pairs of local and remote addresses and ports to a
1644 single SA. Instead, when multiple local and remote addresses and
1645 ports are negotiated for an SA, IKEv2 treats these not as pairs, but
1646 as (unordered) sets of local and remote values that can be
1647 arbitrarily paired. Until IKE provides a facility that conveys the
1648 semantics that are expressed in the SPD via selector sets (as
1649 described below), users MUST NOT include multiple selector sets in a
1650 single SPD entry unless the access control intent aligns with the IKE
1651 "mix and match" semantics. An implementation MAY warn users, to
1652 alert them to this problem if users create SPD entries with multiple
1653 selector sets, the syntax of which indicates possible conflicts with
1654 current IKE semantics.
1656 The management GUI can offer the user other forms of data entry and
1657 display, e.g., the option of using address prefixes as well as
1658 ranges, and symbolic names for protocols, ports, etc. (Do not confuse
1659 the use of symbolic names in a management interface with the SPD
1660 selector "Name".) Note that Remote/Local apply only to IP addresses
1661 and ports, not to ICMP message type/code or Mobility Header type.
1662 Also, if the reserved, symbolic selector value OPAQUE or ANY is
1663 employed for a given selector type, only that value may appear in the
1664 list for that selector, and it must appear only once in the list for
1665 that selector. Note that ANY and OPAQUE are local syntax conventions
1666 -- IKEv2 negotiates these values via the ranges indicated below:
1668 ANY: start = 0 end = <max>
1669 OPAQUE: start = <max> end = 0
1671 An SPD is an ordered list of entries each of which contains the
1674 o Name -- a list of IDs. This quasi-selector is optional.
1675 The forms that MUST be supported are described above in
1676 Section 4.4.1.1 under "Name".
1682 Kent & Seo Standards Track [Page 30]
1684 RFC 4301 Security Architecture for IP December 2005
1687 o PFP flags -- one per traffic selector. A given flag, e.g.,
1688 for Next Layer Protocol, applies to the relevant selector
1689 across all "selector sets" (see below) contained in an SPD
1690 entry. When creating an SA, each flag specifies for the
1691 corresponding traffic selector whether to instantiate the
1692 selector from the corresponding field in the packet that
1693 triggered the creation of the SA or from the value(s) in
1694 the corresponding SPD entry (see Section 4.4.1, "How to
1695 Derive the Values for an SAD Entry"). Whether a single
1696 flag is used for, e.g., source port, ICMP type/code, and
1697 MH type, or a separate flag is used for each, is a local
1698 matter. There are PFP flags for:
1701 - Next Layer Protocol
1702 - Local Port, or ICMP message type/code or Mobility
1703 Header type (depending on the next layer protocol)
1704 - Remote Port, or ICMP message type/code or Mobility
1705 Header type (depending on the next layer protocol)
1707 o One to N selector sets that correspond to the "condition"
1708 for applying a particular IPsec action. Each selector set
1712 - Next Layer Protocol
1713 - Local Port, or ICMP message type/code or Mobility
1714 Header type (depending on the next layer protocol)
1715 - Remote Port, or ICMP message type/code or Mobility
1716 Header type (depending on the next layer protocol)
1718 Note: The "next protocol" selector is an individual value
1719 (unlike the local and remote IP addresses) in a selector
1720 set entry. This is consistent with how IKEv2 negotiates
1721 the Traffic Selector (TS) values for an SA. It also makes
1722 sense because one may need to associate different port
1723 fields with different protocols. It is possible to
1724 associate multiple protocols (and ports) with a single SA
1725 by specifying multiple selector sets for that SA.
1727 o Processing info -- which action is required -- PROTECT,
1728 BYPASS, or DISCARD. There is just one action that goes
1729 with all the selector sets, not a separate action for each
1730 set. If the required processing is PROTECT, the entry
1731 contains the following information.
1732 - IPsec mode -- tunnel or transport
1738 Kent & Seo Standards Track [Page 31]
1740 RFC 4301 Security Architecture for IP December 2005
1743 - (if tunnel mode) local tunnel address -- For a
1744 non-mobile host, if there is just one interface, this
1745 is straightforward; if there are multiple
1746 interfaces, this must be statically configured. For a
1747 mobile host, the specification of the local address
1748 is handled externally to IPsec.
1749 - (if tunnel mode) remote tunnel address -- There is no
1750 standard way to determine this. See 4.5.3, "Locating
1751 a Security Gateway".
1752 - Extended Sequence Number -- Is this SA using extended
1754 - stateful fragment checking -- Is this SA using
1755 stateful fragment checking? (See Section 7 for more
1757 - Bypass DF bit (T/F) -- applicable to tunnel mode SAs
1758 - Bypass DSCP (T/F) or map to unprotected DSCP values
1759 (array) if needed to restrict bypass of DSCP values --
1760 applicable to tunnel mode SAs
1761 - IPsec protocol -- AH or ESP
1762 - algorithms -- which ones to use for AH, which ones to
1763 use for ESP, which ones to use for combined mode,
1764 ordered by decreasing priority
1766 It is a local matter as to what information is kept with regard to
1767 handling extant SAs when the SPD is changed.
1769 4.4.1.3. More Regarding Fields Associated with Next Layer Protocols
1771 Additional selectors are often associated with fields in the Next
1772 Layer Protocol header. A particular Next Layer Protocol can have
1773 zero, one, or two selectors. There may be situations where there
1774 aren't both local and remote selectors for the fields that are
1775 dependent on the Next Layer Protocol. The IPv6 Mobility Header has
1776 only a Mobility Header message type. AH and ESP have no further
1777 selector fields. A system may be willing to send an ICMP message
1778 type and code that it does not want to receive. In the descriptions
1779 below, "port" is used to mean a field that is dependent on the Next
1782 A. If a Next Layer Protocol has no "port" selectors, then
1783 the Local and Remote "port" selectors are set to OPAQUE in
1784 the relevant SPD entry, e.g.,
1787 next layer protocol = AH
1788 "port" selector = OPAQUE
1794 Kent & Seo Standards Track [Page 32]
1796 RFC 4301 Security Architecture for IP December 2005
1800 next layer protocol = AH
1801 "port" selector = OPAQUE
1803 B. Even if a Next Layer Protocol has only one selector, e.g.,
1804 Mobility Header type, then the Local and Remote "port"
1805 selectors are used to indicate whether a system is
1806 willing to send and/or receive traffic with the specified
1807 "port" values. For example, if Mobility Headers of a
1808 specified type are allowed to be sent and received via an
1809 SA, then the relevant SPD entry would be set as follows:
1812 next layer protocol = Mobility Header
1813 "port" selector = Mobility Header message type
1816 next layer protocol = Mobility Header
1817 "port" selector = Mobility Header message type
1819 If Mobility Headers of a specified type are allowed to be
1820 sent but NOT received via an SA, then the relevant SPD
1821 entry would be set as follows:
1824 next layer protocol = Mobility Header
1825 "port" selector = Mobility Header message type
1828 next layer protocol = Mobility Header
1829 "port" selector = OPAQUE
1831 If Mobility Headers of a specified type are allowed to be
1832 received but NOT sent via an SA, then the relevant SPD
1833 entry would be set as follows:
1836 next layer protocol = Mobility Header
1837 "port" selector = OPAQUE
1840 next layer protocol = Mobility Header
1841 "port" selector = Mobility Header message type
1843 C. If a system is willing to send traffic with a particular
1844 "port" value but NOT receive traffic with that kind of
1845 port value, the system's traffic selectors are set as
1846 follows in the relevant SPD entry:
1850 Kent & Seo Standards Track [Page 33]
1852 RFC 4301 Security Architecture for IP December 2005
1856 next layer protocol = ICMP
1857 "port" selector = <specific ICMP type & code>
1860 next layer protocol = ICMP
1861 "port" selector = OPAQUE
1863 D. To indicate that a system is willing to receive traffic
1864 with a particular "port" value but NOT send that kind of
1865 traffic, the system's traffic selectors are set as follows
1866 in the relevant SPD entry:
1869 next layer protocol = ICMP
1870 "port" selector = OPAQUE
1873 next layer protocol = ICMP
1874 "port" selector = <specific ICMP type & code>
1876 For example, if a security gateway is willing to allow
1877 systems behind it to send ICMP traceroutes, but is not
1878 willing to let outside systems run ICMP traceroutes to
1879 systems behind it, then the security gateway's traffic
1880 selectors are set as follows in the relevant SPD entry:
1883 next layer protocol = 1 (ICMPv4)
1884 "port" selector = 30 (traceroute)
1887 next layer protocol = 1 (ICMPv4)
1888 "port" selector = OPAQUE
1890 4.4.2. Security Association Database (SAD)
1892 In each IPsec implementation, there is a nominal Security Association
1893 Database (SAD), in which each entry defines the parameters associated
1894 with one SA. Each SA has an entry in the SAD. For outbound
1895 processing, each SAD entry is pointed to by entries in the SPD-S part
1896 of the SPD cache. For inbound processing, for unicast SAs, the SPI
1897 is used either alone to look up an SA or in conjunction with the
1898 IPsec protocol type. If an IPsec implementation supports multicast,
1899 the SPI plus destination address, or SPI plus destination and source
1900 addresses are used to look up the SA. (See Section 4.1 for details on
1901 the algorithm that MUST be used for mapping inbound IPsec datagrams
1902 to SAs.) The following parameters are associated with each entry in
1906 Kent & Seo Standards Track [Page 34]
1908 RFC 4301 Security Architecture for IP December 2005
1911 the SAD. They should all be present except where otherwise noted,
1912 e.g., AH Authentication algorithm. This description does not purport
1913 to be a MIB, only a specification of the minimal data items required
1914 to support an SA in an IPsec implementation.
1916 For each of the selectors defined in Section 4.4.1.1, the entry for
1917 an inbound SA in the SAD MUST be initially populated with the value
1918 or values negotiated at the time the SA was created. (See the
1919 paragraph in Section 4.4.1 under "Handling Changes to the SPD while
1920 the System is Running" for guidance on the effect of SPD changes on
1921 extant SAs.) For a receiver, these values are used to check that the
1922 header fields of an inbound packet (after IPsec processing) match the
1923 selector values negotiated for the SA. Thus, the SAD acts as a cache
1924 for checking the selectors of inbound traffic arriving on SAs. For
1925 the receiver, this is part of verifying that a packet arriving on an
1926 SA is consistent with the policy for the SA. (See Section 6 for rules
1927 for ICMP messages.) These fields can have the form of specific
1928 values, ranges, ANY, or OPAQUE, as described in Section 4.4.1.1,
1929 "Selectors". Note also that there are a couple of situations in
1930 which the SAD can have entries for SAs that do not have corresponding
1931 entries in the SPD. Since this document does not mandate that the
1932 SAD be selectively cleared when the SPD is changed, SAD entries can
1933 remain when the SPD entries that created them are changed or deleted.
1934 Also, if a manually keyed SA is created, there could be an SAD entry
1935 for this SA that does not correspond to any SPD entry.
1937 Note: The SAD can support multicast SAs, if manually configured. An
1938 outbound multicast SA has the same structure as a unicast SA. The
1939 source address is that of the sender, and the destination address is
1940 the multicast group address. An inbound, multicast SA must be
1941 configured with the source addresses of each peer authorized to
1942 transmit to the multicast SA in question. The SPI value for a
1943 multicast SA is provided by a multicast group controller, not by the
1944 receiver, as for a unicast SA. Because an SAD entry may be required
1945 to accommodate multiple, individual IP source addresses that were
1946 part of an SPD entry (for unicast SAs), the required facility for
1947 inbound, multicast SAs is a feature already present in an IPsec
1948 implementation. However, because the SPD has no provisions for
1949 accommodating multicast entries, this document does not specify an
1950 automated way to create an SAD entry for a multicast, inbound SA.
1951 Only manually configured SAD entries can be created to accommodate
1952 inbound, multicast traffic.
1954 Implementation Guidance: This document does not specify how an SPD-S
1955 entry refers to the corresponding SAD entry, as this is an
1956 implementation-specific detail. However, some implementations (based
1957 on experience from RFC 2401) are known to have problems in this
1958 regard. In particular, simply storing the (remote tunnel header IP
1962 Kent & Seo Standards Track [Page 35]
1964 RFC 4301 Security Architecture for IP December 2005
1967 address, remote SPI) pair in the SPD cache is not sufficient, since
1968 the pair does not always uniquely identify a single SAD entry. For
1969 instance, two hosts behind the same NAT could choose the same SPI
1970 value. The situation also may arise if a host is assigned an IP
1971 address (e.g., via DHCP) previously used by some other host, and the
1972 SAs associated with the old host have not yet been deleted via dead
1973 peer detection mechanisms. This may lead to packets being sent over
1974 the wrong SA or, if key management ensures the pair is unique,
1975 denying the creation of otherwise valid SAs. Thus, implementors
1976 should implement links between the SPD cache and the SAD in a way
1977 that does not engender such problems.
1979 4.4.2.1. Data Items in the SAD
1981 The following data items MUST be in the SAD:
1983 o Security Parameter Index (SPI): a 32-bit value selected by the
1984 receiving end of an SA to uniquely identify the SA. In an SAD
1985 entry for an outbound SA, the SPI is used to construct the
1986 packet's AH or ESP header. In an SAD entry for an inbound SA, the
1987 SPI is used to map traffic to the appropriate SA (see text on
1988 unicast/multicast in Section 4.1).
1990 o Sequence Number Counter: a 64-bit counter used to generate the
1991 Sequence Number field in AH or ESP headers. 64-bit sequence
1992 numbers are the default, but 32-bit sequence numbers are also
1993 supported if negotiated.
1995 o Sequence Counter Overflow: a flag indicating whether overflow of
1996 the sequence number counter should generate an auditable event and
1997 prevent transmission of additional packets on the SA, or whether
1998 rollover is permitted. The audit log entry for this event SHOULD
1999 include the SPI value, current date/time, Local Address, Remote
2000 Address, and the selectors from the relevant SAD entry.
2002 o Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent)
2003 used to determine whether an inbound AH or ESP packet is a replay.
2005 Note: If anti-replay has been disabled by the receiver for an SA,
2006 e.g., in the case of a manually keyed SA, then the Anti-Replay
2007 Window is ignored for the SA in question. 64-bit sequence numbers
2008 are the default, but this counter size accommodates 32-bit
2009 sequence numbers as well.
2011 o AH Authentication algorithm, key, etc. This is required only if
2018 Kent & Seo Standards Track [Page 36]
2020 RFC 4301 Security Architecture for IP December 2005
2023 o ESP Encryption algorithm, key, mode, IV, etc. If a combined mode
2024 algorithm is used, these fields will not be applicable.
2026 o ESP integrity algorithm, keys, etc. If the integrity service is
2027 not selected, these fields will not be applicable. If a combined
2028 mode algorithm is used, these fields will not be applicable.
2030 o ESP combined mode algorithms, key(s), etc. This data is used when
2031 a combined mode (encryption and integrity) algorithm is used with
2032 ESP. If a combined mode algorithm is not used, these fields are
2035 o Lifetime of this SA: a time interval after which an SA must be
2036 replaced with a new SA (and new SPI) or terminated, plus an
2037 indication of which of these actions should occur. This may be
2038 expressed as a time or byte count, or a simultaneous use of both
2039 with the first lifetime to expire taking precedence. A compliant
2040 implementation MUST support both types of lifetimes, and MUST
2041 support a simultaneous use of both. If time is employed, and if
2042 IKE employs X.509 certificates for SA establishment, the SA
2043 lifetime must be constrained by the validity intervals of the
2044 certificates, and the NextIssueDate of the Certificate Revocation
2045 Lists (CRLs) used in the IKE exchange for the SA. Both initiator
2046 and responder are responsible for constraining the SA lifetime in
2047 this fashion. Note: The details of how to handle the refreshing
2048 of keys when SAs expire is a local matter. However, one
2049 reasonable approach is:
2051 (a) If byte count is used, then the implementation SHOULD count the
2052 number of bytes to which the IPsec cryptographic algorithm is
2053 applied. For ESP, this is the encryption algorithm (including
2054 Null encryption) and for AH, this is the authentication
2055 algorithm. This includes pad bytes, etc. Note that
2056 implementations MUST be able to handle having the counters at
2057 the ends of an SA get out of synch, e.g., because of packet
2058 loss or because the implementations at each end of the SA
2059 aren't doing things the same way.
2061 (b) There SHOULD be two kinds of lifetime -- a soft lifetime that
2062 warns the implementation to initiate action such as setting up
2063 a replacement SA, and a hard lifetime when the current SA ends
2066 (c) If the entire packet does not get delivered during the SA's
2067 lifetime, the packet SHOULD be discarded.
2069 o IPsec protocol mode: tunnel or transport. Indicates which mode of
2070 AH or ESP is applied to traffic on this SA.
2074 Kent & Seo Standards Track [Page 37]
2076 RFC 4301 Security Architecture for IP December 2005
2079 o Stateful fragment checking flag. Indicates whether or not
2080 stateful fragment checking applies to this SA.
2082 o Bypass DF bit (T/F) -- applicable to tunnel mode SAs where both
2083 inner and outer headers are IPv4.
2085 o DSCP values -- the set of DSCP values allowed for packets carried
2086 over this SA. If no values are specified, no DSCP-specific
2087 filtering is applied. If one or more values are specified, these
2088 are used to select one SA among several that match the traffic
2089 selectors for an outbound packet. Note that these values are NOT
2090 checked against inbound traffic arriving on the SA.
2092 o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if
2093 needed to restrict bypass of DSCP values -- applicable to tunnel
2094 mode SAs. This feature maps DSCP values from an inner header to
2095 values in an outer header, e.g., to address covert channel
2098 o Path MTU: any observed path MTU and aging variables.
2100 o Tunnel header IP source and destination address -- both addresses
2101 must be either IPv4 or IPv6 addresses. The version implies the
2102 type of IP header to be used. Only used when the IPsec protocol
2105 4.4.2.2. Relationship between SPD, PFP flag, packet, and SAD
2107 For each selector, the following tables show the relationship
2108 between the value in the SPD, the PFP flag, the value in the
2109 triggering packet, and the resulting value in the SAD. Note that
2110 the administrative interface for IPsec can use various syntactic
2111 options to make it easier for the administrator to enter rules.
2112 For example, although a list of ranges is what IKEv2 sends, it
2113 might be clearer and less error prone for the user to enter a
2114 single IP address or IP address prefix.
2130 Kent & Seo Standards Track [Page 38]
2132 RFC 4301 Security Architecture for IP December 2005
2136 Triggering Resulting SAD
2137 Selector SPD Entry PFP Packet Entry
2138 -------- ---------------- --- ------------ --------------
2139 loc addr list of ranges 0 IP addr "S" list of ranges
2140 ANY 0 IP addr "S" ANY
2141 list of ranges 1 IP addr "S" "S"
2142 ANY 1 IP addr "S" "S"
2144 rem addr list of ranges 0 IP addr "D" list of ranges
2145 ANY 0 IP addr "D" ANY
2146 list of ranges 1 IP addr "D" "D"
2147 ANY 1 IP addr "D" "D"
2149 protocol list of prot's* 0 prot. "P" list of prot's*
2150 ANY** 0 prot. "P" ANY
2151 OPAQUE**** 0 prot. "P" OPAQUE
2153 list of prot's* 0 not avail. discard packet
2154 ANY** 0 not avail. ANY
2155 OPAQUE**** 0 not avail. OPAQUE
2157 list of prot's* 1 prot. "P" "P"
2158 ANY** 1 prot. "P" "P"
2159 OPAQUE**** 1 prot. "P" ***
2161 list of prot's* 1 not avail. discard packet
2162 ANY** 1 not avail. discard packet
2163 OPAQUE**** 1 not avail. ***
2186 Kent & Seo Standards Track [Page 39]
2188 RFC 4301 Security Architecture for IP December 2005
2191 If the protocol is one that has two ports, then there will be
2192 selectors for both Local and Remote ports.
2195 Triggering Resulting SAD
2196 Selector SPD Entry PFP Packet Entry
2197 -------- ---------------- --- ------------ --------------
2198 loc port list of ranges 0 src port "s" list of ranges
2199 ANY 0 src port "s" ANY
2200 OPAQUE 0 src port "s" OPAQUE
2202 list of ranges 0 not avail. discard packet
2203 ANY 0 not avail. ANY
2204 OPAQUE 0 not avail. OPAQUE
2206 list of ranges 1 src port "s" "s"
2207 ANY 1 src port "s" "s"
2208 OPAQUE 1 src port "s" ***
2210 list of ranges 1 not avail. discard packet
2211 ANY 1 not avail. discard packet
2212 OPAQUE 1 not avail. ***
2215 rem port list of ranges 0 dst port "d" list of ranges
2216 ANY 0 dst port "d" ANY
2217 OPAQUE 0 dst port "d" OPAQUE
2219 list of ranges 0 not avail. discard packet
2220 ANY 0 not avail. ANY
2221 OPAQUE 0 not avail. OPAQUE
2223 list of ranges 1 dst port "d" "d"
2224 ANY 1 dst port "d" "d"
2225 OPAQUE 1 dst port "d" ***
2227 list of ranges 1 not avail. discard packet
2228 ANY 1 not avail. discard packet
2229 OPAQUE 1 not avail. ***
2242 Kent & Seo Standards Track [Page 40]
2244 RFC 4301 Security Architecture for IP December 2005
2247 If the protocol is mobility header, then there will be a selector
2251 Triggering Resulting SAD
2252 Selector SPD Entry PFP Packet Entry
2253 -------- ---------------- --- ------------ --------------
2254 mh type list of ranges 0 mh type "T" list of ranges
2255 ANY 0 mh type "T" ANY
2256 OPAQUE 0 mh type "T" OPAQUE
2258 list of ranges 0 not avail. discard packet
2259 ANY 0 not avail. ANY
2260 OPAQUE 0 not avail. OPAQUE
2262 list of ranges 1 mh type "T" "T"
2263 ANY 1 mh type "T" "T"
2264 OPAQUE 1 mh type "T" ***
2266 list of ranges 1 not avail. discard packet
2267 ANY 1 not avail. discard packet
2268 OPAQUE 1 not avail. ***
2298 Kent & Seo Standards Track [Page 41]
2300 RFC 4301 Security Architecture for IP December 2005
2303 If the protocol is ICMP, then there will be a 16-bit selector for
2304 ICMP type and ICMP code. Note that the type and code are bound to
2305 each other, i.e., the codes apply to the particular type. This
2306 16-bit selector can contain a single type and a range of codes, a
2307 single type and ANY code, and ANY type and ANY code.
2310 Triggering Resulting SAD
2311 Selector SPD Entry PFP Packet Entry
2312 --------- ---------------- --- ------------ --------------
2313 ICMP type a single type & 0 type "t" & single type &
2314 and code range of codes code "c" range of codes
2315 a single type & 0 type "t" & single type &
2316 ANY code code "c" ANY code
2317 ANY type & ANY 0 type "t" & ANY type &
2318 code code "c" ANY code
2319 OPAQUE 0 type "t" & OPAQUE
2322 a single type & 0 not avail. discard packet
2324 a single type & 0 not avail. discard packet
2326 ANY type & 0 not avail. ANY type &
2328 OPAQUE 0 not avail. OPAQUE
2330 a single type & 1 type "t" & "t" and "c"
2331 range of codes code "c"
2332 a single type & 1 type "t" & "t" and "c"
2334 ANY type & 1 type "t" & "t" and "c"
2336 OPAQUE 1 type "t" & ***
2339 a single type & 1 not avail. discard packet
2341 a single type & 1 not avail. discard packet
2343 ANY type & 1 not avail. discard packet
2345 OPAQUE 1 not avail. ***
2354 Kent & Seo Standards Track [Page 42]
2356 RFC 4301 Security Architecture for IP December 2005
2359 If the name selector is used:
2362 Triggering Resulting SAD
2363 Selector SPD Entry PFP Packet Entry
2364 --------- ---------------- --- ------------ --------------
2365 name list of user or N/A N/A N/A
2368 * "List of protocols" is the information, not the way
2369 that the SPD or SAD or IKEv2 have to represent this
2371 ** 0 (zero) is used by IKE to indicate ANY for
2373 *** Use of PFP=1 with an OPAQUE value is an error and
2374 SHOULD be prohibited by an IPsec implementation.
2375 **** The protocol field cannot be OPAQUE in IPv4. This
2376 table entry applies only to IPv6.
2378 4.4.3. Peer Authorization Database (PAD)
2380 The Peer Authorization Database (PAD) provides the link between the
2381 SPD and a security association management protocol such as IKE. It
2382 embodies several critical functions:
2384 o identifies the peers or groups of peers that are authorized
2385 to communicate with this IPsec entity
2386 o specifies the protocol and method used to authenticate each
2388 o provides the authentication data for each peer
2389 o constrains the types and values of IDs that can be asserted
2390 by a peer with regard to child SA creation, to ensure that the
2391 peer does not assert identities for lookup in the SPD that it
2392 is not authorized to represent, when child SAs are created
2393 o peer gateway location info, e.g., IP address(es) or DNS names,
2394 MAY be included for peers that are known to be "behind" a
2397 The PAD provides these functions for an IKE peer when the peer acts
2398 as either the initiator or the responder.
2400 To perform these functions, the PAD contains an entry for each peer
2401 or group of peers with which the IPsec entity will communicate. An
2402 entry names an individual peer (a user, end system or security
2403 gateway) or specifies a group of peers (using ID matching rules
2404 defined below). The entry specifies the authentication protocol
2405 (e.g., IKEv1, IKEv2, KINK) method used (e.g., certificates or pre-
2406 shared secrets) and the authentication data (e.g., the pre-shared
2410 Kent & Seo Standards Track [Page 43]
2412 RFC 4301 Security Architecture for IP December 2005
2415 secret or the trust anchor relative to which the peer's certificate
2416 will be validated). For certificate-based authentication, the entry
2417 also may provide information to assist in verifying the revocation
2418 status of the peer, e.g., a pointer to a CRL repository or the name
2419 of an Online Certificate Status Protocol (OCSP) server associated
2420 with the peer or with the trust anchor associated with the peer.
2422 Each entry also specifies whether the IKE ID payload will be used as
2423 a symbolic name for SPD lookup, or whether the remote IP address
2424 provided in traffic selector payloads will be used for SPD lookups
2425 when child SAs are created.
2427 Note that the PAD information MAY be used to support creation of more
2428 than one tunnel mode SA at a time between two peers, e.g., two
2429 tunnels to protect the same addresses/hosts, but with different
2432 4.4.3.1. PAD Entry IDs and Matching Rules
2434 The PAD is an ordered database, where the order is defined by an
2435 administrator (or a user in the case of a single-user end system).
2436 Usually, the same administrator will be responsible for both the PAD
2437 and SPD, since the two databases must be coordinated. The ordering
2438 requirement for the PAD arises for the same reason as for the SPD,
2439 i.e., because use of "star name" entries allows for overlaps in the
2440 set of IKE IDs that could match a specific entry.
2442 Six types of IDs are supported for entries in the PAD, consistent
2443 with the symbolic name types and IP addresses used to identify SPD
2444 entries. The ID for each entry acts as the index for the PAD, i.e.,
2445 it is the value used to select an entry. All of these ID types can
2446 be used to match IKE ID payload types. The six types are:
2448 o DNS name (specific or partial)
2449 o Distinguished Name (complete or sub-tree constrained)
2450 o RFC 822 email address (complete or partially qualified)
2451 o IPv4 address (range)
2452 o IPv6 address (range)
2453 o Key ID (exact match only)
2455 The first three name types can accommodate sub-tree matching as well
2456 as exact matches. A DNS name may be fully qualified and thus match
2457 exactly one name, e.g., foo.example.com. Alternatively, the name may
2458 encompass a group of peers by being partially specified, e.g., the
2459 string ".example.com" could be used to match any DNS name ending in
2460 these two domain name components.
2466 Kent & Seo Standards Track [Page 44]
2468 RFC 4301 Security Architecture for IP December 2005
2471 Similarly, a Distinguished Name may specify a complete Distinguished
2472 Name to match exactly one entry, e.g., CN = Stephen, O = BBN
2473 Technologies, SP = MA, C = US. Alternatively, an entry may encompass
2474 a group of peers by specifying a sub-tree, e.g., an entry of the form
2475 "C = US, SP = MA" might be used to match all DNs that contain these
2476 two attributes as the top two Relative Distinguished Names (RDNs).
2478 For an RFC 822 e-mail addresses, the same options exist. A complete
2479 address such as foo@example.com matches one entity, but a sub-tree
2480 name such as "@example.com" could be used to match all the entities
2481 with names ending in those two domain names to the right of the @.
2483 The specific syntax used by an implementation to accommodate sub-tree
2484 matching for distinguished names, domain names or RFC 822 e-mail
2485 addresses is a local matter. But, at a minimum, sub-tree matching of
2486 the sort described above MUST be supported. (Substring matching
2487 within a DN, DNS name, or RFC 822 address MAY be supported, but is
2490 For IPv4 and IPv6 addresses, the same address range syntax used for
2491 SPD entries MUST be supported. This allows specification of an
2492 individual address (via a trivial range), an address prefix (by
2493 choosing a range that adheres to Classless Inter-Domain Routing
2494 (CIDR)-style prefixes), or an arbitrary address range.
2496 The Key ID field is defined as an OCTET string in IKE. For this name
2497 type, only exact-match syntax MUST be supported (since there is no
2498 explicit structure for this ID type). Additional matching functions
2499 MAY be supported for this ID type.
2501 4.4.3.2. IKE Peer Authentication Data
2503 Once an entry is located based on an ordered search of the PAD based
2504 on ID field matching, it is necessary to verify the asserted
2505 identity, i.e., to authenticate the asserted ID. For each PAD entry,
2506 there is an indication of the type of authentication to be performed.
2507 This document requires support for two required authentication data
2513 For authentication based on an X.509 certificate, the PAD entry
2514 contains a trust anchor via which the end entity (EE) certificate for
2515 the peer must be verifiable, either directly or via a certificate
2516 path. See RFC 3280 for the definition of a trust anchor. An entry
2517 used with certificate-based authentication MAY include additional
2518 data to facilitate certificate revocation status, e.g., a list of
2522 Kent & Seo Standards Track [Page 45]
2524 RFC 4301 Security Architecture for IP December 2005
2527 appropriate OCSP responders or CRL repositories, and associated
2528 authentication data. For authentication based on a pre-shared
2529 secret, the PAD contains the pre-shared secret to be used by IKE.
2531 This document does not require that the IKE ID asserted by a peer be
2532 syntactically related to a specific field in an end entity
2533 certificate that is employed to authenticate the identity of that
2534 peer. However, it often will be appropriate to impose such a
2535 requirement, e.g., when a single entry represents a set of peers each
2536 of whom may have a distinct SPD entry. Thus, implementations MUST
2537 provide a means for an administrator to require a match between an
2538 asserted IKE ID and the subject name or subject alt name in a
2539 certificate. The former is applicable to IKE IDs expressed as
2540 distinguished names; the latter is appropriate for DNS names, RFC 822
2541 e-mail addresses, and IP addresses. Since KEY ID is intended for
2542 identifying a peer authenticated via a pre-shared secret, there is no
2543 requirement to match this ID type to a certificate field.
2545 See IKEv1 [HarCar98] and IKEv2 [Kau05] for details of how IKE
2546 performs peer authentication using certificates or pre-shared
2549 This document does not mandate support for any other authentication
2550 methods, although such methods MAY be employed.
2552 4.4.3.3. Child SA Authorization Data
2554 Once an IKE peer is authenticated, child SAs may be created. Each
2555 PAD entry contains data to constrain the set of IDs that can be
2556 asserted by an IKE peer, for matching against the SPD. Each PAD
2557 entry indicates whether the IKE ID is to be used as a symbolic name
2558 for SPD matching, or whether an IP address asserted in a traffic
2559 selector payload is to be used.
2561 If the entry indicates that the IKE ID is to be used, then the PAD
2562 entry ID field defines the authorized set of IDs. If the entry
2563 indicates that child SAs traffic selectors are to be used, then an
2564 additional data element is required, in the form of IPv4 and/or IPv6
2565 address ranges. (A peer may be authorized for both address types, so
2566 there MUST be provision for both a v4 and a v6 address range.)
2568 4.4.3.4. How the PAD Is Used
2570 During the initial IKE exchange, the initiator and responder each
2571 assert their identity via the IKE ID payload and send an AUTH payload
2572 to verify the asserted identity. One or more CERT payloads may be
2573 transmitted to facilitate the verification of each asserted identity.
2578 Kent & Seo Standards Track [Page 46]
2580 RFC 4301 Security Architecture for IP December 2005
2583 When an IKE entity receives an IKE ID payload, it uses the asserted
2584 ID to locate an entry in the PAD, using the matching rules described
2585 above. The PAD entry specifies the authentication method to be
2586 employed for the identified peer. This ensures that the right method
2587 is used for each peer and that different methods can be used for
2588 different peers. The entry also specifies the authentication data
2589 that will be used to verify the asserted identity. This data is
2590 employed in conjunction with the specified method to authenticate the
2591 peer, before any CHILD SAs are created.
2593 Child SAs are created based on the exchange of traffic selector
2594 payloads, either at the end of the initial IKE exchange or in
2595 subsequent CREATE_CHILD_SA exchanges. The PAD entry for the (now
2596 authenticated) IKE peer is used to constrain creation of child SAs;
2597 specifically, the PAD entry specifies how the SPD is searched using a
2598 traffic selector proposal from a peer. There are two choices: either
2599 the IKE ID asserted by the peer is used to find an SPD entry via its
2600 symbolic name, or peer IP addresses asserted in traffic selector
2601 payloads are used for SPD lookups based on the remote IP address
2602 field portion of an SPD entry. It is necessary to impose these
2603 constraints on creation of child SAs to prevent an authenticated peer
2604 from spoofing IDs associated with other, legitimate peers.
2606 Note that because the PAD is checked before searching for an SPD
2607 entry, this safeguard protects an initiator against spoofing attacks.
2608 For example, assume that IKE A receives an outbound packet destined
2609 for IP address X, a host served by a security gateway. RFC 2401
2610 [RFC2401] and this document do not specify how A determines the
2611 address of the IKE peer serving X. However, any peer contacted by A
2612 as the presumed representative for X must be registered in the PAD in
2613 order to allow the IKE exchange to be authenticated. Moreover, when
2614 the authenticated peer asserts that it represents X in its traffic
2615 selector exchange, the PAD will be consulted to determine if the peer
2616 in question is authorized to represent X. Thus, the PAD provides a
2617 binding of address ranges (or name sub-spaces) to peers, to counter
2620 4.5. SA and Key Management
2622 All IPsec implementations MUST support both manual and automated SA
2623 and cryptographic key management. The IPsec protocols, AH and ESP,
2624 are largely independent of the associated SA management techniques,
2625 although the techniques involved do affect some of the security
2626 services offered by the protocols. For example, the optional
2627 anti-replay service available for AH and ESP requires automated SA
2628 management. Moreover, the granularity of key distribution employed
2629 with IPsec determines the granularity of authentication provided. In
2630 general, data origin authentication in AH and ESP is limited by the
2634 Kent & Seo Standards Track [Page 47]
2636 RFC 4301 Security Architecture for IP December 2005
2639 extent to which secrets used with the integrity algorithm (or with a
2640 key management protocol that creates such secrets) are shared among
2641 multiple possible sources.
2643 The following text describes the minimum requirements for both types
2646 4.5.1. Manual Techniques
2648 The simplest form of management is manual management, in which a
2649 person manually configures each system with keying material and SA
2650 management data relevant to secure communication with other systems.
2651 Manual techniques are practical in small, static environments but
2652 they do not scale well. For example, a company could create a
2653 virtual private network (VPN) using IPsec in security gateways at
2654 several sites. If the number of sites is small, and since all the
2655 sites come under the purview of a single administrative domain, this
2656 might be a feasible context for manual management techniques. In
2657 this case, the security gateway might selectively protect traffic to
2658 and from other sites within the organization using a manually
2659 configured key, while not protecting traffic for other destinations.
2660 It also might be appropriate when only selected communications need
2661 to be secured. A similar argument might apply to use of IPsec
2662 entirely within an organization for a small number of hosts and/or
2663 gateways. Manual management techniques often employ statically
2664 configured, symmetric keys, though other options also exist.
2666 4.5.2. Automated SA and Key Management
2668 Widespread deployment and use of IPsec requires an Internet-standard,
2669 scalable, automated, SA management protocol. Such support is
2670 required to facilitate use of the anti-replay features of AH and ESP,
2671 and to accommodate on-demand creation of SAs, e.g., for user- and
2672 session-oriented keying. (Note that the notion of "rekeying" an SA
2673 actually implies creation of a new SA with a new SPI, a process that
2674 generally implies use of an automated SA/key management protocol.)
2676 The default automated key management protocol selected for use with
2677 IPsec is IKEv2 [Kau05]. This document assumes the availability of
2678 certain functions from the key management protocol that are not
2679 supported by IKEv1. Other automated SA management protocols MAY be
2682 When an automated SA/key management protocol is employed, the output
2683 from this protocol is used to generate multiple keys for a single SA.
2684 This also occurs because distinct keys are used for each of the two
2690 Kent & Seo Standards Track [Page 48]
2692 RFC 4301 Security Architecture for IP December 2005
2695 SAs created by IKE. If both integrity and confidentiality are
2696 employed, then a minimum of four keys are required. Additionally,
2697 some cryptographic algorithms may require multiple keys, e.g., 3DES.
2699 The Key Management System may provide a separate string of bits for
2700 each key or it may generate one string of bits from which all keys
2701 are extracted. If a single string of bits is provided, care needs to
2702 be taken to ensure that the parts of the system that map the string
2703 of bits to the required keys do so in the same fashion at both ends
2704 of the SA. To ensure that the IPsec implementations at each end of
2705 the SA use the same bits for the same keys, and irrespective of which
2706 part of the system divides the string of bits into individual keys,
2707 the encryption keys MUST be taken from the first (left-most,
2708 high-order) bits and the integrity keys MUST be taken from the
2709 remaining bits. The number of bits for each key is defined in the
2710 relevant cryptographic algorithm specification RFC. In the case of
2711 multiple encryption keys or multiple integrity keys, the
2712 specification for the cryptographic algorithm must specify the order
2713 in which they are to be selected from a single string of bits
2714 provided to the cryptographic algorithm.
2716 4.5.3. Locating a Security Gateway
2718 This section discusses issues relating to how a host learns about the
2719 existence of relevant security gateways and, once a host has
2720 contacted these security gateways, how it knows that these are the
2721 correct security gateways. The details of where the required
2722 information is stored is a local matter, but the Peer Authorization
2723 Database (PAD) described in Section 4.4 is the most likely candidate.
2724 (Note: S* indicates a system that is running IPsec, e.g., SH1 and SG2
2727 Consider a situation in which a remote host (SH1) is using the
2728 Internet to gain access to a server or other machine (H2) and there
2729 is a security gateway (SG2), e.g., a firewall, through which H1's
2730 traffic must pass. An example of this situation would be a mobile
2731 host crossing the Internet to his home organization's firewall (SG2).
2732 This situation raises several issues:
2734 1. How does SH1 know/learn about the existence of the security
2737 2. How does it authenticate SG2, and once it has authenticated SG2,
2738 how does it confirm that SG2 has been authorized to represent H2?
2740 3. How does SG2 authenticate SH1 and verify that SH1 is authorized to
2746 Kent & Seo Standards Track [Page 49]
2748 RFC 4301 Security Architecture for IP December 2005
2751 4. How does SH1 know/learn about any additional gateways that provide
2752 alternate paths to H2?
2754 To address these problems, an IPsec-supporting host or security
2755 gateway MUST have an administrative interface that allows the
2756 user/administrator to configure the address of one or more security
2757 gateways for ranges of destination addresses that require its use.
2758 This includes the ability to configure information for locating and
2759 authenticating one or more security gateways and verifying the
2760 authorization of these gateways to represent the destination host.
2761 (The authorization function is implied in the PAD.) This document
2762 does not address the issue of how to automate the
2763 discovery/verification of security gateways.
2765 4.6. SAs and Multicast
2767 The receiver-orientation of the SA implies that, in the case of
2768 unicast traffic, the destination system will select the SPI value.
2769 By having the destination select the SPI value, there is no potential
2770 for manually configured SAs to conflict with automatically configured
2771 (e.g., via a key management protocol) SAs or for SAs from multiple
2772 sources to conflict with each other. For multicast traffic, there
2773 are multiple destination systems associated with a single SA. So
2774 some system or person will need to coordinate among all multicast
2775 groups to select an SPI or SPIs on behalf of each multicast group and
2776 then communicate the group's IPsec information to all of the
2777 legitimate members of that multicast group via mechanisms not defined
2780 Multiple senders to a multicast group SHOULD use a single Security
2781 Association (and hence SPI) for all traffic to that group when a
2782 symmetric key encryption or integrity algorithm is employed. In such
2783 circumstances, the receiver knows only that the message came from a
2784 system possessing the key for that multicast group. In such
2785 circumstances, a receiver generally will not be able to authenticate
2786 which system sent the multicast traffic. Specifications for other,
2787 more general multicast approaches are deferred to the IETF Multicast
2788 Security Working Group.
2790 5. IP Traffic Processing
2792 As mentioned in Section 4.4.1, "The Security Policy Database (SPD)",
2793 the SPD (or associated caches) MUST be consulted during the
2794 processing of all traffic that crosses the IPsec protection boundary,
2795 including IPsec management traffic. If no policy is found in the SPD
2796 that matches a packet (for either inbound or outbound traffic), the
2797 packet MUST be discarded. To simplify processing, and to allow for
2798 very fast SA lookups (for SG/BITS/BITW), this document introduces the
2802 Kent & Seo Standards Track [Page 50]
2804 RFC 4301 Security Architecture for IP December 2005
2807 notion of an SPD cache for all outbound traffic (SPD-O plus SPD-S),
2808 and a cache for inbound, non-IPsec-protected traffic (SPD-I). (As
2809 mentioned earlier, the SAD acts as a cache for checking the selectors
2810 of inbound IPsec-protected traffic arriving on SAs.) There is
2811 nominally one cache per SPD. For the purposes of this specification,
2812 it is assumed that each cached entry will map to exactly one SA.
2813 Note, however, exceptions arise when one uses multiple SAs to carry
2814 traffic of different priorities (e.g., as indicated by distinct DSCP
2815 values) but the same selectors. Note also, that there are a couple
2816 of situations in which the SAD can have entries for SAs that do not
2817 have corresponding entries in the SPD. Since this document does not
2818 mandate that the SAD be selectively cleared when the SPD is changed,
2819 SAD entries can remain when the SPD entries that created them are
2820 changed or deleted. Also, if a manually keyed SA is created, there
2821 could be an SAD entry for this SA that does not correspond to any SPD
2824 Since SPD entries may overlap, one cannot safely cache these entries
2825 in general. Simple caching might result in a match against a cache
2826 entry, whereas an ordered search of the SPD would have resulted in a
2827 match against a different entry. But, if the SPD entries are first
2828 decorrelated, then the resulting entries can safely be cached. Each
2829 cached entry will indicate that matching traffic should be bypassed
2830 or discarded, appropriately. (Note: The original SPD entry might
2831 result in multiple SAs, e.g., because of PFP.) Unless otherwise
2832 noted, all references below to the "SPD" or "SPD cache" or "cache"
2833 are to a decorrelated SPD (SPD-I, SPD-O, SPD-S) or the SPD cache
2834 containing entries from the decorrelated SPD.
2836 Note: In a host IPsec implementation based on sockets, the SPD will
2837 be consulted whenever a new socket is created to determine what, if
2838 any, IPsec processing will be applied to the traffic that will flow
2839 on that socket. This provides an implicit caching mechanism, and the
2840 portions of the preceding discussion that address caching can be
2841 ignored in such implementations.
2843 Note: It is assumed that one starts with a correlated SPD because
2844 that is how users and administrators are accustomed to managing these
2845 sorts of access control lists or firewall filter rules. Then the
2846 decorrelation algorithm is applied to build a list of cache-able SPD
2847 entries. The decorrelation is invisible at the management interface.
2849 For inbound IPsec traffic, the SAD entry selected by the SPI serves
2850 as the cache for the selectors to be matched against arriving IPsec
2851 packets, after AH or ESP processing has been performed.
2858 Kent & Seo Standards Track [Page 51]
2860 RFC 4301 Security Architecture for IP December 2005
2863 5.1. Outbound IP Traffic Processing (protected-to-unprotected)
2865 First consider the path for traffic entering the implementation via a
2866 protected interface and exiting via an unprotected interface.
2868 Unprotected Interface
2871 (nested SAs) +----------+
2872 -------------------|Forwarding|<-----+
2877 +-------+ | SPD | +--------+
2878 ...| SPD-I |.................|Cache|.....|PROCESS |...IPsec
2879 | (*) | | (*) |---->|(AH/ESP)| boundary
2880 +-------+ +-----+ +--------+
2886 |---------------->|SPD Selection|
2898 Figure 2. Processing Model for Outbound Traffic
2899 (*) = The SPD caches are shown here. If there
2900 is a cache miss, then the SPD is checked.
2901 There is no requirement that an
2902 implementation buffer the packet if
2903 there is a cache miss.
2914 Kent & Seo Standards Track [Page 52]
2916 RFC 4301 Security Architecture for IP December 2005
2919 IPsec MUST perform the following steps when processing outbound
2922 1. When a packet arrives from the subscriber (protected) interface,
2923 invoke the SPD selection function to obtain the SPD-ID needed to
2924 choose the appropriate SPD. (If the implementation uses only one
2925 SPD, this step is a no-op.)
2927 2. Match the packet headers against the cache for the SPD specified
2928 by the SPD-ID from step 1. Note that this cache contains entries
2929 from SPD-O and SPD-S.
2931 3a. If there is a match, then process the packet as specified by the
2932 matching cache entry, i.e., BYPASS, DISCARD, or PROTECT using AH
2933 or ESP. If IPsec processing is applied, there is a link from the
2934 SPD cache entry to the relevant SAD entry (specifying the mode,
2935 cryptographic algorithms, keys, SPI, PMTU, etc.). IPsec
2936 processing is as previously defined, for tunnel or transport
2937 modes and for AH or ESP, as specified in their respective RFCs
2938 [Ken05b, Ken05a]. Note that the SA PMTU value, plus the value of
2939 the stateful fragment checking flag (and the DF bit in the IP
2940 header of the outbound packet) determine whether the packet can
2941 (must) be fragmented prior to or after IPsec processing, or if it
2942 must be discarded and an ICMP PMTU message is sent.
2944 3b. If no match is found in the cache, search the SPD (SPD-S and
2945 SPD-O parts) specified by SPD-ID. If the SPD entry calls for
2946 BYPASS or DISCARD, create one or more new outbound SPD cache
2947 entries and if BYPASS, create one or more new inbound SPD cache
2948 entries. (More than one cache entry may be created since a
2949 decorrelated SPD entry may be linked to other such entries that
2950 were created as a side effect of the decorrelation process.) If
2951 the SPD entry calls for PROTECT, i.e., creation of an SA, the key
2952 management mechanism (e.g., IKEv2) is invoked to create the SA.
2953 If SA creation succeeds, a new outbound (SPD-S) cache entry is
2954 created, along with outbound and inbound SAD entries, otherwise
2955 the packet is discarded. (A packet that triggers an SPD lookup
2956 MAY be discarded by the implementation, or it MAY be processed
2957 against the newly created cache entry, if one is created.) Since
2958 SAs are created in pairs, an SAD entry for the corresponding
2959 inbound SA also is created, and it contains the selector values
2960 derived from the SPD entry (and packet, if any PFP flags were
2961 "true") used to create the inbound SA, for use in checking
2962 inbound traffic delivered via the SA.
2964 4. The packet is passed to the outbound forwarding function
2965 (operating outside of the IPsec implementation), to select the
2966 interface to which the packet will be directed. This function
2970 Kent & Seo Standards Track [Page 53]
2972 RFC 4301 Security Architecture for IP December 2005
2975 may cause the packet to be passed back across the IPsec boundary,
2976 for additional IPsec processing, e.g., in support of nested SAs.
2977 If so, there MUST be an entry in SPD-I database that permits
2978 inbound bypassing of the packet, otherwise the packet will be
2979 discarded. If necessary, i.e., if there is more than one SPD-I,
2980 the traffic being looped back MAY be tagged as coming from this
2981 internal interface. This would allow the use of a different
2982 SPD-I for "real" external traffic vs. looped traffic, if needed.
2984 Note: With the exception of IPv4 and IPv6 transport mode, an SG,
2985 BITS, or BITW implementation MAY fragment packets before applying
2986 IPsec. (This applies only to IPv4. For IPv6 packets, only the
2987 originator is allowed to fragment them.) The device SHOULD have a
2988 configuration setting to disable this. The resulting fragments are
2989 evaluated against the SPD in the normal manner. Thus, fragments not
2990 containing port numbers (or ICMP message type and code, or Mobility
2991 Header type) will only match rules having port (or ICMP message type
2992 and code, or MH type) selectors of OPAQUE or ANY. (See Section 7 for
2995 Note: With regard to determining and enforcing the PMTU of an SA, the
2996 IPsec system MUST follow the steps described in Section 8.2.
2998 5.1.1. Handling an Outbound Packet That Must Be Discarded
3000 If an IPsec system receives an outbound packet that it finds it must
3001 discard, it SHOULD be capable of generating and sending an ICMP
3002 message to indicate to the sender of the outbound packet that the
3003 packet was discarded. The type and code of the ICMP message will
3004 depend on the reason for discarding the packet, as specified below.
3005 The reason SHOULD be recorded in the audit log. The audit log entry
3006 for this event SHOULD include the reason, current date/time, and the
3007 selector values from the packet.
3009 a. The selectors of the packet matched an SPD entry requiring the
3010 packet to be discarded.
3012 IPv4 Type = 3 (destination unreachable) Code = 13
3013 (Communication Administratively Prohibited)
3015 IPv6 Type = 1 (destination unreachable) Code = 1
3016 (Communication with destination administratively
3019 b1. The IPsec system successfully reached the remote peer but was
3020 unable to negotiate the SA required by the SPD entry matching the
3021 packet because, for example, the remote peer is administratively
3022 prohibited from communicating with the initiator, the initiating
3026 Kent & Seo Standards Track [Page 54]
3028 RFC 4301 Security Architecture for IP December 2005
3031 peer was unable to authenticate itself to the remote peer, the
3032 remote peer was unable to authenticate itself to the initiating
3033 peer, or the SPD at the remote peer did not have a suitable
3036 IPv4 Type = 3 (destination unreachable) Code = 13
3037 (Communication Administratively Prohibited)
3039 IPv6 Type = 1 (destination unreachable) Code = 1
3040 (Communication with destination administratively
3043 b2. The IPsec system was unable to set up the SA required by the SPD
3044 entry matching the packet because the IPsec peer at the other end
3045 of the exchange could not be contacted.
3047 IPv4 Type = 3 (destination unreachable) Code = 1 (host
3050 IPv6 Type = 1 (destination unreachable) Code = 3 (address
3053 Note that an attacker behind a security gateway could send packets
3054 with a spoofed source address, W.X.Y.Z, to an IPsec entity causing it
3055 to send ICMP messages to W.X.Y.Z. This creates an opportunity for a
3056 denial of service (DoS) attack among hosts behind a security gateway.
3057 To address this, a security gateway SHOULD include a management
3058 control to allow an administrator to configure an IPsec
3059 implementation to send or not send the ICMP messages under these
3060 circumstances, and if this facility is selected, to rate limit the
3061 transmission of such ICMP responses.
3063 5.1.2. Header Construction for Tunnel Mode
3065 This section describes the handling of the inner and outer IP
3066 headers, extension headers, and options for AH and ESP tunnels, with
3067 regard to outbound traffic processing. This includes how to
3068 construct the encapsulating (outer) IP header, how to process fields
3069 in the inner IP header, and what other actions should be taken for
3070 outbound, tunnel mode traffic. The general processing described here
3071 is modeled after RFC 2003, "IP Encapsulation within IP" [Per96]:
3073 o The outer IP header Source Address and Destination Address
3074 identify the "endpoints" of the tunnel (the encapsulator and
3075 decapsulator). The inner IP header Source Address and Destination
3076 Addresses identify the original sender and recipient of the
3077 datagram (from the perspective of this tunnel), respectively.
3082 Kent & Seo Standards Track [Page 55]
3084 RFC 4301 Security Architecture for IP December 2005
3087 (See footnote 3 after the table in 5.1.2.1 for more details on the
3088 encapsulating source IP address.)
3090 o The inner IP header is not changed except as noted below for TTL
3091 (or Hop Limit) and the DS/ECN Fields. The inner IP header
3092 otherwise remains unchanged during its delivery to the tunnel exit
3095 o No change to IP options or extension headers in the inner header
3096 occurs during delivery of the encapsulated datagram through the
3099 Note: IPsec tunnel mode is different from IP-in-IP tunneling (RFC
3100 2003 [Per96]) in several ways:
3102 o IPsec offers certain controls to a security administrator to
3103 manage covert channels (which would not normally be a concern for
3104 tunneling) and to ensure that the receiver examines the right
3105 portions of the received packet with respect to application of
3106 access controls. An IPsec implementation MAY be configurable with
3107 regard to how it processes the outer DS field for tunnel mode for
3108 transmitted packets. For outbound traffic, one configuration
3109 setting for the outer DS field will operate as described in the
3110 following sections on IPv4 and IPv6 header processing for IPsec
3111 tunnels. Another will allow the outer DS field to be mapped to a
3112 fixed value, which MAY be configured on a per-SA basis. (The value
3113 might really be fixed for all traffic outbound from a device, but
3114 per-SA granularity allows that as well.) This configuration option
3115 allows a local administrator to decide whether the covert channel
3116 provided by copying these bits outweighs the benefits of copying.
3118 o IPsec describes how to handle ECN or DS and provides the ability
3119 to control propagation of changes in these fields between
3120 unprotected and protected domains. In general, propagation from a
3121 protected to an unprotected domain is a covert channel and thus
3122 controls are provided to manage the bandwidth of this channel.
3123 Propagation of ECN values in the other direction are controlled so
3124 that only legitimate ECN changes (indicating occurrence of
3125 congestion between the tunnel endpoints) are propagated. By
3126 default, DS propagation from an unprotected domain to a protected
3127 domain is not permitted. However, if the sender and receiver do
3128 not share the same DS code space, and the receiver has no way of
3129 learning how to map between the two spaces, then it may be
3130 appropriate to deviate from the default. Specifically, an IPsec
3131 implementation MAY be configurable in terms of how it processes
3132 the outer DS field for tunnel mode for received packets. It may
3133 be configured to either discard the outer DS value (the default)
3134 OR to overwrite the inner DS field with the outer DS field. If
3138 Kent & Seo Standards Track [Page 56]
3140 RFC 4301 Security Architecture for IP December 2005
3143 offered, the discard vs. overwrite behavior MAY be configured on a
3144 per-SA basis. This configuration option allows a local
3145 administrator to decide whether the vulnerabilities created by
3146 copying these bits outweigh the benefits of copying. See
3147 [RFC2983] for further information on when each of these behaviors
3148 may be useful, and also for the possible need for diffserv traffic
3149 conditioning prior or subsequent to IPsec processing (including
3150 tunnel decapsulation).
3152 o IPsec allows the IP version of the encapsulating header to be
3153 different from that of the inner header.
3155 The tables in the following sub-sections show the handling for the
3156 different header/option fields ("constructed" means that the value in
3157 the outer field is constructed independently of the value in the
3160 5.1.2.1. IPv4: Header Construction for Tunnel Mode
3162 <-- How Outer Hdr Relates to Inner Hdr -->
3163 Outer Hdr at Inner Hdr at
3164 IPv4 Encapsulator Decapsulator
3165 Header fields: -------------------- ------------
3166 version 4 (1) no change
3167 header length constructed no change
3168 DS Field copied from inner hdr (5) no change
3169 ECN Field copied from inner hdr constructed (6)
3170 total length constructed no change
3171 ID constructed no change
3172 flags (DF,MF) constructed, DF (4) no change
3173 fragment offset constructed no change
3174 TTL constructed (2) decrement (2)
3175 protocol AH, ESP no change
3176 checksum constructed constructed (2)(6)
3177 src address constructed (3) no change
3178 dest address constructed (3) no change
3179 Options never copied no change
3183 (1) The IP version in the encapsulating header can be different
3184 from the value in the inner header.
3186 (2) The TTL in the inner header is decremented by the encapsulator
3187 prior to forwarding and by the decapsulator if it forwards the
3188 packet. (The IPv4 checksum changes when the TTL changes.)
3194 Kent & Seo Standards Track [Page 57]
3196 RFC 4301 Security Architecture for IP December 2005
3199 Note: Decrementing the TTL value is a normal part of
3200 forwarding a packet. Thus, a packet originating from the same
3201 node as the encapsulator does not have its TTL decremented,
3202 since the sending node is originating the packet rather than
3203 forwarding it. This applies to BITS and native IPsec
3204 implementations in hosts and routers. However, the IPsec
3205 processing model includes an external forwarding capability.
3206 TTL processing can be used to prevent looping of packets,
3207 e.g., due to configuration errors, within the context of this
3210 (3) Local and Remote addresses depend on the SA, which is used to
3211 determine the Remote address, which in turn determines which
3212 Local address (net interface) is used to forward the packet.
3214 Note: For multicast traffic, the destination address, or
3215 source and destination addresses, may be required for
3216 demuxing. In that case, it is important to ensure consistency
3217 over the lifetime of the SA by ensuring that the source
3218 address that appears in the encapsulating tunnel header is the
3219 same as the one that was negotiated during the SA
3220 establishment process. There is an exception to this general
3221 rule, i.e., a mobile IPsec implementation will update its
3222 source address as it moves.
3224 (4) Configuration determines whether to copy from the inner header
3225 (IPv4 only), clear, or set the DF.
3227 (5) If the packet will immediately enter a domain for which the
3228 DSCP value in the outer header is not appropriate, that value
3229 MUST be mapped to an appropriate value for the domain
3230 [NiBlBaBL98]. See RFC 2475 [BBCDWW98] for further
3233 (6) If the ECN field in the inner header is set to ECT(0) or
3234 ECT(1), where ECT is ECN-Capable Transport (ECT), and if the
3235 ECN field in the outer header is set to Congestion Experienced
3236 (CE), then set the ECN field in the inner header to CE;
3237 otherwise, make no change to the ECN field in the inner
3238 header. (The IPv4 checksum changes when the ECN changes.)
3240 Note: IPsec does not copy the options from the inner header into the
3241 outer header, nor does IPsec construct the options in the outer
3242 header. However, post-IPsec code MAY insert/construct options for
3250 Kent & Seo Standards Track [Page 58]
3252 RFC 4301 Security Architecture for IP December 2005
3255 5.1.2.2. IPv6: Header Construction for Tunnel Mode
3257 <-- How Outer Hdr Relates Inner Hdr --->
3258 Outer Hdr at Inner Hdr at
3259 IPv6 Encapsulator Decapsulator
3260 Header fields: -------------------- ------------
3261 version 6 (1) no change
3262 DS Field copied from inner hdr (5) no change (9)
3263 ECN Field copied from inner hdr constructed (6)
3264 flow label copied or configured (8) no change
3265 payload length constructed no change
3266 next header AH,ESP,routing hdr no change
3267 hop limit constructed (2) decrement (2)
3268 src address constructed (3) no change
3269 dest address constructed (3) no change
3270 Extension headers never copied (7) no change
3274 (1) - (6) See Section 5.1.2.1.
3276 (7) IPsec does not copy the extension headers from the inner
3277 packet into outer headers, nor does IPsec construct extension
3278 headers in the outer header. However, post-IPsec code MAY
3279 insert/construct extension headers for the outer header.
3281 (8) See [RaCoCaDe04]. Copying is acceptable only for end systems,
3282 not SGs. If an SG copied flow labels from the inner header to
3283 the outer header, collisions might result.
3285 (9) An implementation MAY choose to provide a facility to pass the
3286 DS value from the outer header to the inner header, on a per-
3287 SA basis, for received tunnel mode packets. The motivation
3288 for providing this feature is to accommodate situations in
3289 which the DS code space at the receiver is different from that
3290 of the sender and the receiver has no way of knowing how to
3291 translate from the sender's space. There is a danger in
3292 copying this value from the outer header to the inner header,
3293 since it enables an attacker to modify the outer DSCP value in
3294 a fashion that may adversely affect other traffic at the
3295 receiver. Hence the default behavior for IPsec
3296 implementations is NOT to permit such copying.
3298 5.2. Processing Inbound IP Traffic (unprotected-to-protected)
3300 Inbound processing is somewhat different from outbound processing,
3301 because of the use of SPIs to map IPsec-protected traffic to SAs.
3302 The inbound SPD cache (SPD-I) is applied only to bypassed or
3306 Kent & Seo Standards Track [Page 59]
3308 RFC 4301 Security Architecture for IP December 2005
3311 discarded traffic. If an arriving packet appears to be an IPsec
3312 fragment from an unprotected interface, reassembly is performed prior
3313 to IPsec processing. The intent for any SPD cache is that a packet
3314 that fails to match any entry is then referred to the corresponding
3315 SPD. Every SPD SHOULD have a nominal, final entry that catches
3316 anything that is otherwise unmatched, and discards it. This ensures
3317 that non-IPsec-protected traffic that arrives and does not match any
3318 SPD-I entry will be discarded.
3320 Unprotected Interface
3323 +-----+ IPsec protected
3324 ------------------->|Demux|-------------------+
3330 | +-------+ +---------+ |
3331 | |DISCARD|<---|SPD-I (*)| |
3332 | +-------+ +---------+ |
3341 +---------+ | +-----------+
3342 ....|SPD-O (*)|............|...................|PROCESS(**)|...IPsec
3343 +---------+ | | (AH/ESP) | Boundary
3346 | BYPASS | +-->|IKE| |
3349 | +----------+ +---------+ +----+
3350 |--------<------|Forwarding|<---------|SAD Check|-->|ICMP|
3351 nested SAs +----------+ | (***) | +----+
3356 Figure 3. Processing Model for Inbound Traffic
3362 Kent & Seo Standards Track [Page 60]
3364 RFC 4301 Security Architecture for IP December 2005
3367 (*) = The caches are shown here. If there is
3368 a cache miss, then the SPD is checked.
3369 There is no requirement that an
3370 implementation buffer the packet if
3371 there is a cache miss.
3372 (**) = This processing includes using the
3373 packet's SPI, etc., to look up the SA
3374 in the SAD, which forms a cache of the
3375 SPD for inbound packets (except for
3376 cases noted in Sections 4.4.2 and 5).
3378 (***) = This SAD check refers to step 4 below.
3380 Prior to performing AH or ESP processing, any IP fragments that
3381 arrive via the unprotected interface are reassembled (by IP). Each
3382 inbound IP datagram to which IPsec processing will be applied is
3383 identified by the appearance of the AH or ESP values in the IP Next
3384 Protocol field (or of AH or ESP as a next layer protocol in the IPv6
3387 IPsec MUST perform the following steps:
3389 1. When a packet arrives, it may be tagged with the ID of the
3390 interface (physical or virtual) via which it arrived, if
3391 necessary, to support multiple SPDs and associated SPD-I caches.
3392 (The interface ID is mapped to a corresponding SPD-ID.)
3394 2. The packet is examined and demuxed into one of two categories:
3395 - If the packet appears to be IPsec protected and it is addressed
3396 to this device, an attempt is made to map it to an active SA
3397 via the SAD. Note that the device may have multiple IP
3398 addresses that may be used in the SAD lookup, e.g., in the case
3399 of protocols such as SCTP.
3400 - Traffic not addressed to this device, or addressed to this
3401 device and not AH or ESP, is directed to SPD-I lookup. (This
3402 implies that IKE traffic MUST have an explicit BYPASS entry in
3403 the SPD.) If multiple SPDs are employed, the tag assigned to
3404 the packet in step 1 is used to select the appropriate SPD-I
3405 (and cache) to search. SPD-I lookup determines whether the
3406 action is DISCARD or BYPASS.
3408 3a. If the packet is addressed to the IPsec device and AH or ESP is
3409 specified as the protocol, the packet is looked up in the SAD.
3410 For unicast traffic, use only the SPI (or SPI plus protocol).
3411 For multicast traffic, use the SPI plus the destination or SPI
3412 plus destination and source addresses, as specified in Section
3413 4.1. In either case (unicast or multicast), if there is no match,
3414 discard the traffic. This is an auditable event. The audit log
3418 Kent & Seo Standards Track [Page 61]
3420 RFC 4301 Security Architecture for IP December 2005
3423 entry for this event SHOULD include the current date/time, SPI,
3424 source and destination of the packet, IPsec protocol, and any
3425 other selector values of the packet that are available. If the
3426 packet is found in the SAD, process it accordingly (see step 4).
3428 3b. If the packet is not addressed to the device or is addressed to
3429 this device and is not AH or ESP, look up the packet header in
3430 the (appropriate) SPD-I cache. If there is a match and the
3431 packet is to be discarded or bypassed, do so. If there is no
3432 cache match, look up the packet in the corresponding SPD-I and
3433 create a cache entry as appropriate. (No SAs are created in
3434 response to receipt of a packet that requires IPsec protection;
3435 only BYPASS or DISCARD cache entries can be created this way.) If
3436 there is no match, discard the traffic. This is an auditable
3437 event. The audit log entry for this event SHOULD include the
3438 current date/time, SPI if available, IPsec protocol if available,
3439 source and destination of the packet, and any other selector
3440 values of the packet that are available.
3442 3c. Processing of ICMP messages is assumed to take place on the
3443 unprotected side of the IPsec boundary. Unprotected ICMP
3444 messages are examined and local policy is applied to determine
3445 whether to accept or reject these messages and, if accepted, what
3446 action to take as a result. For example, if an ICMP unreachable
3447 message is received, the implementation must decide whether to
3448 act on it, reject it, or act on it with constraints. (See Section
3451 4. Apply AH or ESP processing as specified, using the SAD entry
3452 selected in step 3a above. Then match the packet against the
3453 inbound selectors identified by the SAD entry to verify that the
3454 received packet is appropriate for the SA via which it was
3457 5. If an IPsec system receives an inbound packet on an SA and the
3458 packet's header fields are not consistent with the selectors for
3459 the SA, it MUST discard the packet. This is an auditable event.
3460 The audit log entry for this event SHOULD include the current
3461 date/time, SPI, IPsec protocol(s), source and destination of the
3462 packet, any other selector values of the packet that are
3463 available, and the selector values from the relevant SAD entry.
3464 The system SHOULD also be capable of generating and sending an
3465 IKE notification of INVALID_SELECTORS to the sender (IPsec peer),
3466 indicating that the received packet was discarded because of
3467 failure to pass selector checks.
3474 Kent & Seo Standards Track [Page 62]
3476 RFC 4301 Security Architecture for IP December 2005
3479 To minimize the impact of a DoS attack, or a mis-configured peer, the
3480 IPsec system SHOULD include a management control to allow an
3481 administrator to configure the IPsec implementation to send or not
3482 send this IKE notification, and if this facility is selected, to rate
3483 limit the transmission of such notifications.
3485 After traffic is bypassed or processed through IPsec, it is handed to
3486 the inbound forwarding function for disposition. This function may
3487 cause the packet to be sent (outbound) across the IPsec boundary for
3488 additional inbound IPsec processing, e.g., in support of nested SAs.
3489 If so, then as with ALL outbound traffic that is to be bypassed, the
3490 packet MUST be matched against an SPD-O entry. Ultimately, the
3491 packet should be forwarded to the destination host or process for
3496 This section describes IPsec handling of ICMP traffic. There are two
3497 categories of ICMP traffic: error messages (e.g., type = destination
3498 unreachable) and non-error messages (e.g., type = echo). This
3499 section applies exclusively to error messages. Disposition of
3500 non-error, ICMP messages (that are not addressed to the IPsec
3501 implementation itself) MUST be explicitly accounted for using SPD
3504 The discussion in this section applies to ICMPv6 as well as to
3505 ICMPv4. Also, a mechanism SHOULD be provided to allow an
3506 administrator to cause ICMP error messages (selected, all, or none)
3507 to be logged as an aid to problem diagnosis.
3509 6.1. Processing ICMP Error Messages Directed to an IPsec Implementation
3511 6.1.1. ICMP Error Messages Received on the Unprotected Side of the
3514 Figure 3 in Section 5.2 shows a distinct ICMP processing module on
3515 the unprotected side of the IPsec boundary, for processing ICMP
3516 messages (error or otherwise) that are addressed to the IPsec device
3517 and that are not protected via AH or ESP. An ICMP message of this
3518 sort is unauthenticated, and its processing may result in denial or
3519 degradation of service. This suggests that, in general, it would be
3520 desirable to ignore such messages. However, many ICMP messages will
3521 be received by hosts or security gateways from unauthenticated
3522 sources, e.g., routers in the public Internet. Ignoring these ICMP
3523 messages can degrade service, e.g., because of a failure to process
3524 PMTU message and redirection messages. Thus, there is also a
3525 motivation for accepting and acting upon unauthenticated ICMP
3530 Kent & Seo Standards Track [Page 63]
3532 RFC 4301 Security Architecture for IP December 2005
3535 To accommodate both ends of this spectrum, a compliant IPsec
3536 implementation MUST permit a local administrator to configure an
3537 IPsec implementation to accept or reject unauthenticated ICMP
3538 traffic. This control MUST be at the granularity of ICMP type and
3539 MAY be at the granularity of ICMP type and code. Additionally, an
3540 implementation SHOULD incorporate mechanisms and parameters for
3541 dealing with such traffic. For example, there could be the ability
3542 to establish a minimum PMTU for traffic (on a per destination basis),
3543 to prevent receipt of an unauthenticated ICMP from setting the PMTU
3546 If an ICMP PMTU message passes the checks above and the system is
3547 configured to accept it, then there are two possibilities. If the
3548 implementation applies fragmentation on the ciphertext side of the
3549 boundary, then the accepted PMTU information is passed to the
3550 forwarding module (outside of the IPsec implementation), which uses
3551 it to manage outbound packet fragmentation. If the implementation is
3552 configured to effect plaintext side fragmentation, then the PMTU
3553 information is passed to the plaintext side and processed as
3554 described in Section 8.2.
3556 6.1.2. ICMP Error Messages Received on the Protected Side of the
3559 These ICMP messages are not authenticated, but they do come from
3560 sources on the protected side of the IPsec boundary. Thus, these
3561 messages generally are viewed as more "trustworthy" than their
3562 counterparts arriving from sources on the unprotected side of the
3563 boundary. The major security concern here is that a compromised host
3564 or router might emit erroneous ICMP error messages that could degrade
3565 service for other devices "behind" the security gateway, or that
3566 could even result in violations of confidentiality. For example, if
3567 a bogus ICMP redirect were consumed by a security gateway, it could
3568 cause the forwarding table on the protected side of the boundary to
3569 be modified so as to deliver traffic to an inappropriate destination
3570 "behind" the gateway. Thus, implementers MUST provide controls to
3571 allow local administrators to constrain the processing of ICMP error
3572 messages received on the protected side of the boundary, and directed
3573 to the IPsec implementation. These controls are of the same type as
3574 those employed on the unprotected side, described above in Section
3577 6.2. Processing Protected, Transit ICMP Error Messages
3579 When an ICMP error message is transmitted via an SA to a device
3580 "behind" an IPsec implementation, both the payload and the header of
3581 the ICMP message require checking from an access control perspective.
3582 If one of these messages is forwarded to a host behind a security
3586 Kent & Seo Standards Track [Page 64]
3588 RFC 4301 Security Architecture for IP December 2005
3591 gateway, the receiving host IP implementation will make decisions
3592 based on the payload, i.e., the header of the packet that purportedly
3593 triggered the error response. Thus, an IPsec implementation MUST be
3594 configurable to check that this payload header information is
3595 consistent with the SA via which it arrives. (This means that the
3596 payload header, with source and destination address and port fields
3597 reversed, matches the traffic selectors for the SA.) If this sort of
3598 check is not performed, then, for example, anyone with whom the
3599 receiving IPsec system (A) has an active SA could send an ICMP
3600 Destination Unreachable message that refers to any host/net with
3601 which A is currently communicating, and thus effect a highly
3602 efficient DoS attack regarding communication with other peers of A.
3603 Normal IPsec receiver processing of traffic is not sufficient to
3604 protect against such attacks. However, not all contexts may require
3605 such checks, so it is also necessary to allow a local administrator
3606 to configure an implementation to NOT perform such checks.
3608 To accommodate both policies, the following convention is adopted.
3609 If an administrator wants to allow ICMP error messages to be carried
3610 by an SA without inspection of the payload, then configure an SPD
3611 entry that explicitly allows for carriage of such traffic. If an
3612 administrator wants IPsec to check the payload of ICMP error messages
3613 for consistency, then do not create any SPD entries that accommodate
3614 carriage of such traffic based on the ICMP packet header. This
3615 convention motivates the following processing description.
3617 IPsec senders and receivers MUST support the following processing for
3618 ICMP error messages that are sent and received via SAs.
3620 If an SA exists that accommodates an outbound ICMP error message,
3621 then the message is mapped to the SA and only the IP and ICMP headers
3622 are checked upon receipt, just as would be the case for other
3623 traffic. If no SA exists that matches the traffic selectors
3624 associated with an ICMP error message, then the SPD is searched to
3625 determine if such an SA can be created. If so, the SA is created and
3626 the ICMP error message is transmitted via that SA. Upon receipt,
3627 this message is subject to the usual traffic selector checks at the
3628 receiver. This processing is exactly what would happen for traffic
3629 in general, and thus does not represent any special processing for
3630 ICMP error messages.
3632 If no SA exists that would carry the outbound ICMP message in
3633 question, and if no SPD entry would allow carriage of this outbound
3634 ICMP error message, then an IPsec implementation MUST map the message
3635 to the SA that would carry the return traffic associated with the
3636 packet that triggered the ICMP error message. This requires an IPsec
3637 implementation to detect outbound ICMP error messages that map to no
3638 extant SA or SPD entry, and treat them specially with regard to SA
3642 Kent & Seo Standards Track [Page 65]
3644 RFC 4301 Security Architecture for IP December 2005
3647 creation and lookup. The implementation extracts the header for the
3648 packet that triggered the error (from the ICMP message payload),
3649 reverses the source and destination IP address fields, extracts the
3650 protocol field, and reverses the port fields (if accessible). It
3651 then uses this extracted information to locate an appropriate, active
3652 outbound SA, and transmits the error message via this SA. If no such
3653 SA exists, no SA will be created, and this is an auditable event.
3655 If an IPsec implementation receives an inbound ICMP error message on
3656 an SA, and the IP and ICMP headers of the message do not match the
3657 traffic selectors for the SA, the receiver MUST process the received
3658 message in a special fashion. Specifically, the receiver must
3659 extract the header of the triggering packet from the ICMP payload,
3660 and reverse fields as described above to determine if the packet is
3661 consistent with the selectors for the SA via which the ICMP error
3662 message was received. If the packet fails this check, the IPsec
3663 implementation MUST NOT forwarded the ICMP message to the
3664 destination. This is an auditable event.
3666 7. Handling Fragments (on the protected side of the IPsec boundary)
3668 Earlier sections of this document describe mechanisms for (a)
3669 fragmenting an outbound packet after IPsec processing has been
3670 applied and reassembling it at the receiver before IPsec processing
3671 and (b) handling inbound fragments received from the unprotected side
3672 of the IPsec boundary. This section describes how an implementation
3673 should handle the processing of outbound plaintext fragments on the
3674 protected side of the IPsec boundary. (See Appendix D, "Fragment
3675 Handling Rationale".) In&n
projects / strongswan.git / blob