- moved RFCs from ikev2 into doc dir
[strongswan.git] / doc / ikev2 / [RFC4301] - Security Architecture for the Internet Protocol.txt
1
2
3
4
5
6
7 Network Working Group                                            S. Kent
8 Request for Comments: 4301                                        K. Seo
9 Obsoletes: 2401                                         BBN Technologies
10 Category: Standards Track                                  December 2005
11
12
13             Security Architecture for the Internet Protocol
14
15 Status of This Memo
16
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.
22
23 Copyright Notice
24
25    Copyright (C) The Internet Society (2005).
26
27 Abstract
28
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
32    (November 1998).
33
34 Dedication
35
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
38    the IPsec documents.
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58 Kent & Seo                  Standards Track                     [Page 1]
59 \f
60 RFC 4301              Security Architecture for IP         December 2005
61
62
63 Table of Contents
64
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
111
112
113
114 Kent & Seo                  Standards Track                     [Page 2]
115 \f
116 RFC 4301              Security Architecture for IP         December 2005
117
118
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
163
164
165
166
167
168
169
170 Kent & Seo                  Standards Track                     [Page 3]
171 \f
172 RFC 4301              Security Architecture for IP         December 2005
173
174
175 1.  Introduction
176
177 1.1.  Summary of Contents of Document
178
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).
195
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
201            Exchange (IKE))
202         d. Cryptographic algorithms for authentication and encryption
203
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.
207
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
212    IPsec protocols.
213
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].
217
218 1.2.  Audience
219
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
223
224
225
226 Kent & Seo                  Standards Track                     [Page 4]
227 \f
228 RFC 4301              Security Architecture for IP         December 2005
229
230
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
236    concepts.
237
238 1.3.  Related Documents
239
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:
243
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
255            (IKEv2)" [Sch05].
256
257 2.  Design Objectives
258
259 2.1.  Goals/Objectives/Requirements/Problem Description
260
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).
270
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
279
280
281
282 Kent & Seo                  Standards Track                     [Page 5]
283 \f
284 RFC 4301              Security Architecture for IP         December 2005
285
286
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.
292
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
302    population.
303
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.
314
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
327    security technology.
328
329 2.2.  Caveats and Assumptions
330
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
335
336
337
338 Kent & Seo                  Standards Track                     [Page 6]
339 \f
340 RFC 4301              Security Architecture for IP         December 2005
341
342
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.
348
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.
356
357 3.  System Overview
358
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
365    more detail.
366
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.
382
383 3.1.  What IPsec Does
384
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.
391
392
393
394 Kent & Seo                  Standards Track                     [Page 7]
395 \f
396 RFC 4301              Security Architecture for IP         December 2005
397
398
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.
407
408                         Unprotected
409                          ^       ^
410                          |       |
411            +-------------|-------|-------+
412            | +-------+   |       |       |
413            | |Discard|<--|       V       |
414            | +-------+   |B  +--------+  |
415          ................|y..| AH/ESP |..... IPsec Boundary
416            |   +---+     |p  +--------+  |
417            |   |IKE|<----|a      ^       |
418            |   +---+     |s      |       |
419            | +-------+   |s      |       |
420            | |Discard|<--|       |       |
421            | +-------+   |       |       |
422            +-------------|-------|-------+
423                          |       |
424                          V       V
425                          Protected
426
427             Figure 1.  Top Level IPsec Processing Model
428
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
443    boundary.
444
445
446
447
448
449
450 Kent & Seo                  Standards Track                     [Page 8]
451 \f
452 RFC 4301              Security Architecture for IP         December 2005
453
454
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.
459
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
463    layers.
464
465 3.2.  How IPsec Works
466
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.)
476
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.
480
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.
490
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
494       4.4.1).
495
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
501
502
503
504
505
506 Kent & Seo                  Standards Track                     [Page 9]
507 \f
508 RFC 4301              Security Architecture for IP         December 2005
509
510
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.
514
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:
522
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
527
528     o the granularity at which protection should be applied.
529
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.
537
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.
544
545 3.3.  Where IPsec Can Be Implemented
546
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.
550
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).
556
557
558
559
560
561
562 Kent & Seo                  Standards Track                    [Page 10]
563 \f
564 RFC 4301              Security Architecture for IP         December 2005
565
566
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.
574
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
583       gateway.
584
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.
590
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.
604
605 4.  Security Associations
606
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
614
615
616
617
618 Kent & Seo                  Standards Track                    [Page 11]
619 \f
620 RFC 4301              Security Architecture for IP         December 2005
621
622
623    section describes various aspects of SA management, defining required
624    characteristics for SA policy management and SA management
625    techniques.
626
627 4.1.  Definition and Scope
628
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.
638
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.
649
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.
659
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:
671
672
673
674 Kent & Seo                  Standards Track                    [Page 12]
675 \f
676 RFC 4301              Security Architecture for IP         December 2005
677
678
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.
683
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.
687
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.
693
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.
706
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
715    identifier.
716
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,
727
728
729
730 Kent & Seo                  Standards Track                    [Page 13]
731 \f
732 RFC 4301              Security Architecture for IP         December 2005
733
734
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.
748
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".
754
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
758    tunnel.
759
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
779    context.
780
781
782
783
784
785
786 Kent & Seo                  Standards Track                    [Page 14]
787 \f
788 RFC 4301              Security Architecture for IP         December 2005
789
790
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].
806
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.
815
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.
821
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.
826
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
839
840
841
842 Kent & Seo                  Standards Track                    [Page 15]
843 \f
844 RFC 4301              Security Architecture for IP         December 2005
845
846
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.)
851
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
858    barrier.
859
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.
870
871    In summary,
872
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.
876
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.
882
883 4.2.  SA Functionality
884
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.
888
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.
895
896
897
898 Kent & Seo                  Standards Track                    [Page 16]
899 \f
900 RFC 4301              Security Architecture for IP         December 2005
901
902
903    However, the same security may be achieved in some contexts by
904    applying ESP to a tunnel carrying a packet.
905
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
910    control afforded.
911
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
924    many subscribers.
925
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.
932
933 4.3.  Combining SAs
934
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.)
948
949
950
951
952
953
954 Kent & Seo                  Standards Track                    [Page 17]
955 \f
956 RFC 4301              Security Architecture for IP         December 2005
957
958
959 4.4.  Major IPsec Databases
960
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.
973
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
982    4.4.3).
983
984    Multiple Separate IPsec Contexts
985
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.
999
1000    Forwarding vs Security Decisions
1001
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
1007
1008
1009
1010 Kent & Seo                  Standards Track                    [Page 18]
1011 \f
1012 RFC 4301              Security Architecture for IP         December 2005
1013
1014
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.
1022
1023    "Local" vs "Remote"
1024
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.
1032
1033    "Non-initial" vs "Initial" Fragments
1034
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.
1047
1048 4.4.1.  The Security Policy Database (SPD)
1049
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
1063
1064
1065
1066 Kent & Seo                  Standards Track                    [Page 19]
1067 \f
1068 RFC 4301              Security Architecture for IP         December 2005
1069
1070
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).
1082
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.
1092
1093    Processing Choices:  DISCARD, BYPASS, PROTECT
1094
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
1108       used.
1109
1110    SPD-S, SPD-I, SPD-O
1111
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
1119
1120
1121
1122 Kent & Seo                  Standards Track                    [Page 20]
1123 \f
1124 RFC 4301              Security Architecture for IP         December 2005
1125
1126
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.
1141
1142    SPD Entries
1143
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.
1153
1154       The SPD MUST permit a user or administrator to specify policy
1155       entries as follows:
1156
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.
1160
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.
1164
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
1173
1174
1175
1176
1177
1178 Kent & Seo                  Standards Track                    [Page 21]
1179 \f
1180 RFC 4301              Security Architecture for IP         December 2005
1181
1182
1183          SA lookup makes use of the local and remote IP addresses in
1184          addition to the SPI (see AH [Ken05b] or ESP [Ken05a]
1185          specifications).
1186
1187    Representing Directionality in an SPD Entry
1188
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.
1205
1206    OPAQUE and ANY
1207
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
1220       field.
1221
1222    How to Derive the Values for an SAD Entry
1223
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
1231
1232
1233
1234 Kent & Seo                  Standards Track                    [Page 22]
1235 \f
1236 RFC 4301              Security Architecture for IP         December 2005
1237
1238
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
1255       matter.
1256
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:
1266
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)
1273
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.
1279
1280    Management Interface
1281
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
1287
1288
1289
1290 Kent & Seo                  Standards Track                    [Page 23]
1291 \f
1292 RFC 4301              Security Architecture for IP         December 2005
1293
1294
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.
1304
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.
1315
1316    Decorrelation
1317
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
1328       implementations.
1329
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
1343
1344
1345
1346 Kent & Seo                  Standards Track                    [Page 24]
1347 \f
1348 RFC 4301              Security Architecture for IP         December 2005
1349
1350
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.
1355
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.
1365
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.
1372
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.
1381
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.
1394
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
1398
1399
1400
1401
1402 Kent & Seo                  Standards Track                    [Page 25]
1403 \f
1404 RFC 4301              Security Architecture for IP         December 2005
1405
1406
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.
1410
1411    Handling Changes to the SPD While the System Is Running
1412
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.
1419
1420 4.4.1.1.   Selectors
1421
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.
1439
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.
1448
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
1455
1456
1457
1458 Kent & Seo                  Standards Track                    [Page 26]
1459 \f
1460 RFC 4301              Security Architecture for IP         December 2005
1461
1462
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).
1466
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.
1476
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.
1489
1490         Several additional selectors depend on the Next Layer Protocol
1491         value:
1492
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".)
1506
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
1511
1512
1513
1514 Kent & Seo                  Standards Track                    [Page 27]
1515 \f
1516 RFC 4301              Security Architecture for IP         December 2005
1517
1518
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.
1523
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
1537
1538                (T-start*256) + C-start <= (t*256) + c <= (T-end*256) +
1539                C-end
1540
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".)
1544
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:
1549
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.
1561
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:
1567
1568
1569
1570 Kent & Seo                  Standards Track                    [Page 28]
1571 \f
1572 RFC 4301              Security Architecture for IP         December 2005
1573
1574
1575                     - local address in the SPD cache entry
1576                     - local address in the outbound SAD entry
1577                     - remote address in the inbound SAD entry
1578
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).
1585
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.
1588
1589          For case 1, responder, the identifiers employed in named SPD
1590          entries are one of the following four types:
1591
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)
1595
1596                  b. a fully qualified DNS name, e.g.,
1597                     foo.example.com
1598                     (this corresponds to ID_FQDN in IKEv2)
1599
1600                  c. X.500 distinguished name, e.g., [WaKiHo97],
1601                     CN = Stephen T. Kent, O = BBN Technologies,
1602                     SP = MA, C = US
1603                     (this corresponds to ID_DER_ASN1_DN in IKEv2, after
1604                     decoding)
1605
1606                  d. a byte string
1607                     (this corresponds to Key_ID in IKEv2)
1608
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.
1614
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.
1623
1624
1625
1626 Kent & Seo                  Standards Track                    [Page 29]
1627 \f
1628 RFC 4301              Security Architecture for IP         December 2005
1629
1630
1631 4.4.1.2.  Structure of an SPD Entry
1632
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
1635    entry.
1636
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.
1655
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:
1667
1668           ANY:     start = 0        end = <max>
1669           OPAQUE:  start = <max>    end = 0
1670
1671    An SPD is an ordered list of entries each of which contains the
1672    following fields.
1673
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".
1677
1678
1679
1680
1681
1682 Kent & Seo                  Standards Track                    [Page 30]
1683 \f
1684 RFC 4301              Security Architecture for IP         December 2005
1685
1686
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:
1699                 - Local Address
1700                 - Remote Address
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)
1706
1707            o One to N selector sets that correspond to the "condition"
1708              for applying a particular IPsec action.  Each selector set
1709              contains:
1710                 - Local Address
1711                 - Remote Address
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)
1717
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.
1726
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
1733
1734
1735
1736
1737
1738 Kent & Seo                  Standards Track                    [Page 31]
1739 \f
1740 RFC 4301              Security Architecture for IP         December 2005
1741
1742
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
1753                   sequence numbers?
1754                 - stateful fragment checking -- Is this SA using
1755                   stateful fragment checking?  (See Section 7 for more
1756                   details.)
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
1765
1766    It is a local matter as to what information is kept with regard to
1767    handling extant SAs when the SPD is changed.
1768
1769 4.4.1.3.  More Regarding Fields Associated with Next Layer Protocols
1770
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
1780    Layer Protocol.
1781
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.,
1785
1786            Local's
1787              next layer protocol = AH
1788              "port" selector     = OPAQUE
1789
1790
1791
1792
1793
1794 Kent & Seo                  Standards Track                    [Page 32]
1795 \f
1796 RFC 4301              Security Architecture for IP         December 2005
1797
1798
1799            Remote's
1800              next layer protocol = AH
1801              "port" selector     = OPAQUE
1802
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:
1810
1811            Local's
1812              next layer protocol = Mobility Header
1813              "port" selector     = Mobility Header message type
1814
1815            Remote's
1816              next layer protocol = Mobility Header
1817              "port" selector     = Mobility Header message type
1818
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:
1822
1823            Local's
1824              next layer protocol = Mobility Header
1825              "port" selector     = Mobility Header message type
1826
1827            Remote's
1828              next layer protocol = Mobility Header
1829              "port" selector     = OPAQUE
1830
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:
1834
1835            Local's
1836              next layer protocol = Mobility Header
1837              "port" selector     = OPAQUE
1838
1839            Remote's
1840              next layer protocol = Mobility Header
1841              "port" selector     = Mobility Header message type
1842
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:
1847
1848
1849
1850 Kent & Seo                  Standards Track                    [Page 33]
1851 \f
1852 RFC 4301              Security Architecture for IP         December 2005
1853
1854
1855            Local's
1856              next layer protocol = ICMP
1857              "port" selector     = <specific ICMP type & code>
1858
1859            Remote's
1860              next layer protocol = ICMP
1861              "port" selector     = OPAQUE
1862
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:
1867
1868            Local's
1869              next layer protocol = ICMP
1870              "port" selector     = OPAQUE
1871
1872            Remote's
1873              next layer protocol = ICMP
1874              "port" selector     = <specific ICMP type & code>
1875
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:
1881
1882            Local's
1883              next layer protocol = 1 (ICMPv4)
1884              "port" selector     = 30 (traceroute)
1885
1886            Remote's
1887              next layer protocol = 1 (ICMPv4)
1888              "port" selector     = OPAQUE
1889
1890 4.4.2.  Security Association Database (SAD)
1891
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
1903
1904
1905
1906 Kent & Seo                  Standards Track                    [Page 34]
1907 \f
1908 RFC 4301              Security Architecture for IP         December 2005
1909
1910
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.
1915
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.
1936
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.
1953
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
1959
1960
1961
1962 Kent & Seo                  Standards Track                    [Page 35]
1963 \f
1964 RFC 4301              Security Architecture for IP         December 2005
1965
1966
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.
1978
1979 4.4.2.1.  Data Items in the SAD
1980
1981    The following data items MUST be in the SAD:
1982
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).
1989
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.
1994
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.
2001
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.
2004
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.
2010
2011     o AH Authentication algorithm, key, etc.  This is required only if
2012       AH is supported.
2013
2014
2015
2016
2017
2018 Kent & Seo                  Standards Track                    [Page 36]
2019 \f
2020 RFC 4301              Security Architecture for IP         December 2005
2021
2022
2023     o ESP Encryption algorithm, key, mode, IV, etc.  If a combined mode
2024       algorithm is used, these fields will not be applicable.
2025
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.
2029
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
2033       not applicable.
2034
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:
2050
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.
2060
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
2064          and is destroyed.
2065
2066      (c) If the entire packet does not get delivered during the SA's
2067          lifetime, the packet SHOULD be discarded.
2068
2069     o IPsec protocol mode: tunnel or transport.  Indicates which mode of
2070       AH or ESP is applied to traffic on this SA.
2071
2072
2073
2074 Kent & Seo                  Standards Track                    [Page 37]
2075 \f
2076 RFC 4301              Security Architecture for IP         December 2005
2077
2078
2079     o Stateful fragment checking flag.  Indicates whether or not
2080       stateful fragment checking applies to this SA.
2081
2082     o Bypass DF bit (T/F) -- applicable to tunnel mode SAs where both
2083       inner and outer headers are IPv4.
2084
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.
2091
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
2096       signaling concerns.
2097
2098     o Path MTU: any observed path MTU and aging variables.
2099
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
2103       mode is tunnel.
2104
2105 4.4.2.2.  Relationship between SPD, PFP flag, packet, and SAD
2106
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.
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130 Kent & Seo                  Standards Track                    [Page 38]
2131 \f
2132 RFC 4301              Security Architecture for IP         December 2005
2133
2134
2135                                         Value in
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"
2143
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"
2148
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
2152
2153                    list of prot's*   0  not avail.   discard packet
2154                    ANY**             0  not avail.   ANY
2155                    OPAQUE****        0  not avail.   OPAQUE
2156
2157                    list of prot's*   1  prot. "P"    "P"
2158                    ANY**             1  prot. "P"    "P"
2159                    OPAQUE****        1  prot. "P"    ***
2160
2161                    list of prot's*   1  not avail.   discard packet
2162                    ANY**             1  not avail.   discard packet
2163                    OPAQUE****        1  not avail.   ***
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186 Kent & Seo                  Standards Track                    [Page 39]
2187 \f
2188 RFC 4301              Security Architecture for IP         December 2005
2189
2190
2191       If the protocol is one that has two ports, then there will be
2192       selectors for both Local and Remote ports.
2193
2194                                         Value in
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
2201
2202                    list of ranges    0  not avail.   discard packet
2203                    ANY               0  not avail.   ANY
2204                    OPAQUE            0  not avail.   OPAQUE
2205
2206                    list of ranges    1  src port "s" "s"
2207                    ANY               1  src port "s" "s"
2208                    OPAQUE            1  src port "s" ***
2209
2210                    list of ranges    1  not avail.   discard packet
2211                    ANY               1  not avail.   discard packet
2212                    OPAQUE            1  not avail.   ***
2213
2214
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
2218
2219                    list of ranges    0  not avail.   discard packet
2220                    ANY               0  not avail.   ANY
2221                    OPAQUE            0  not avail.   OPAQUE
2222
2223                    list of ranges    1  dst port "d" "d"
2224                    ANY               1  dst port "d" "d"
2225                    OPAQUE            1  dst port "d" ***
2226
2227                    list of ranges    1  not avail.   discard packet
2228                    ANY               1  not avail.   discard packet
2229                    OPAQUE            1  not avail.   ***
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242 Kent & Seo                  Standards Track                    [Page 40]
2243 \f
2244 RFC 4301              Security Architecture for IP         December 2005
2245
2246
2247       If the protocol is mobility header, then there will be a selector
2248       for mh type.
2249
2250                                         Value in
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
2257
2258                    list of ranges    0  not avail.   discard packet
2259                    ANY               0  not avail.   ANY
2260                    OPAQUE            0  not avail.   OPAQUE
2261
2262                    list of ranges    1  mh type "T"  "T"
2263                    ANY               1  mh type "T"  "T"
2264                    OPAQUE            1  mh type "T"  ***
2265
2266                    list of ranges    1  not avail.   discard packet
2267                    ANY               1  not avail.   discard packet
2268                    OPAQUE            1  not avail.   ***
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298 Kent & Seo                  Standards Track                    [Page 41]
2299 \f
2300 RFC 4301              Security Architecture for IP         December 2005
2301
2302
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.
2308
2309                                          Value in
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
2320                                            code "c"
2321
2322                     a single type &   0  not avail.   discard packet
2323                      range of codes
2324                     a single type &   0  not avail.   discard packet
2325                      ANY code
2326                     ANY type &        0  not avail.   ANY type &
2327                      ANY code                          ANY code
2328                     OPAQUE            0  not avail.   OPAQUE
2329
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"
2333                      ANY code              code "c"
2334                     ANY type &        1  type "t" &   "t" and "c"
2335                      ANY code              code "c"
2336                     OPAQUE            1  type "t" &   ***
2337                                            code "c"
2338
2339                     a single type &   1  not avail.   discard packet
2340                      range of codes
2341                     a single type &   1  not avail.   discard packet
2342                      ANY code
2343                     ANY type &        1  not avail.   discard packet
2344                      ANY code
2345                     OPAQUE            1  not avail.   ***
2346
2347
2348
2349
2350
2351
2352
2353
2354 Kent & Seo                  Standards Track                    [Page 42]
2355 \f
2356 RFC 4301              Security Architecture for IP         December 2005
2357
2358
2359       If the name selector is used:
2360
2361                                          Value in
2362                                          Triggering   Resulting SAD
2363          Selector   SPD Entry        PFP Packet       Entry
2364          ---------  ---------------- --- ------------ --------------
2365          name       list of user or  N/A     N/A           N/A
2366                     system names
2367
2368             * "List of protocols" is the information, not the way
2369               that the SPD or SAD or IKEv2 have to represent this
2370               information.
2371            ** 0 (zero) is used by IKE to indicate ANY for
2372               protocol.
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.
2377
2378 4.4.3.  Peer Authorization Database (PAD)
2379
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:
2383
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
2387           peer
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
2395           security gateway
2396
2397    The PAD provides these functions for an IKE peer when the peer acts
2398    as either the initiator or the responder.
2399
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
2407
2408
2409
2410 Kent & Seo                  Standards Track                    [Page 43]
2411 \f
2412 RFC 4301              Security Architecture for IP         December 2005
2413
2414
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.
2421
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.
2426
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
2430    tunnel endpoints.
2431
2432 4.4.3.1.  PAD Entry IDs and Matching Rules
2433
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.
2441
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:
2447
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)
2454
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.
2461
2462
2463
2464
2465
2466 Kent & Seo                  Standards Track                    [Page 44]
2467 \f
2468 RFC 4301              Security Architecture for IP         December 2005
2469
2470
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).
2477
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 @.
2482
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
2488    not required.)
2489
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.
2495
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.
2500
2501 4.4.3.2.  IKE Peer Authentication Data
2502
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
2508    types:
2509
2510         - X.509 certificate
2511         - pre-shared secret
2512
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
2519
2520
2521
2522 Kent & Seo                  Standards Track                    [Page 45]
2523 \f
2524 RFC 4301              Security Architecture for IP         December 2005
2525
2526
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.
2530
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.
2544
2545    See IKEv1 [HarCar98] and IKEv2 [Kau05] for details of how IKE
2546    performs peer authentication using certificates or pre-shared
2547    secrets.
2548
2549    This document does not mandate support for any other authentication
2550    methods, although such methods MAY be employed.
2551
2552 4.4.3.3.  Child SA Authorization Data
2553
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.
2560
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.)
2567
2568 4.4.3.4.  How the PAD Is Used
2569
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.
2574
2575
2576
2577
2578 Kent & Seo                  Standards Track                    [Page 46]
2579 \f
2580 RFC 4301              Security Architecture for IP         December 2005
2581
2582
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.
2592
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.
2605
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
2618    such attacks.
2619
2620 4.5.  SA and Key Management
2621
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
2631
2632
2633
2634 Kent & Seo                  Standards Track                    [Page 47]
2635 \f
2636 RFC 4301              Security Architecture for IP         December 2005
2637
2638
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.
2642
2643    The following text describes the minimum requirements for both types
2644    of SA management.
2645
2646 4.5.1.  Manual Techniques
2647
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.
2665
2666 4.5.2.  Automated SA and Key Management
2667
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.)
2675
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
2680    employed.
2681
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
2685
2686
2687
2688
2689
2690 Kent & Seo                  Standards Track                    [Page 48]
2691 \f
2692 RFC 4301              Security Architecture for IP         December 2005
2693
2694
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.
2698
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.
2715
2716 4.5.3.  Locating a Security Gateway
2717
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
2725    below.)
2726
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:
2733
2734    1. How does SH1 know/learn about the existence of the security
2735       gateway SG2?
2736
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?
2739
2740    3. How does SG2 authenticate SH1 and verify that SH1 is authorized to
2741       contact H2?
2742
2743
2744
2745
2746 Kent & Seo                  Standards Track                    [Page 49]
2747 \f
2748 RFC 4301              Security Architecture for IP         December 2005
2749
2750
2751    4. How does SH1 know/learn about any additional gateways that provide
2752       alternate paths to H2?
2753
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.
2764
2765 4.6.  SAs and Multicast
2766
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