- moved RFCs from ikev2 into doc dir
[strongswan.git] / doc / ikev2 / [IPsecArch] - Security Architecture for the Internet Protocol.txt
1 Network Working Group                                            S. Kent
2 Internet Draft                                                    K. Seo
3 draft-ietf-ipsec-rfc2401bis-06.txt                      BBN Technologies
4 Obsoletes: RFC 2401                                           March 2005
5 Expires September 2005
6
7
8
9
10
11
12
13             Security Architecture for the Internet Protocol
14
15
16
17       Dedicated to the memory of Charlie Lynn, a long time senior
18       colleague at BBN, who made very significant contributions to
19                           the IPsec documents.
20
21
22
23 Status of this Memo
24
25    By submitting this Internet-Draft, I certify that any applicable
26    patent or other IPR claims of which I am aware have been disclosed,
27    and any of which I become aware will be disclosed, in accordance with
28    RFC 3668.
29
30    This document is an Internet Draft and is subject to all provisions
31    of Section 10 of RFC2026. Internet-Drafts are working documents of
32    the Internet Engineering Task Force (IETF), its areas, and its
33    working groups. Note that other groups may also distribute working
34    documents as Internet-Drafts. Internet-Drafts are draft documents
35    valid for a maximum of six months and may be updated, replaced, or
36    obsoleted by other documents at any time.  It is inappropriate to use
37    Internet-Drafts as reference material or to cite them other than as
38    "work in progress". The list of current Internet-Drafts can be
39    accessed at http://www.ietf.org/1id-abstracts.html.  The list of
40    Internet-Draft Shadow Directories can be accessed at
41    http://www.ietf.org/shadow.html.
42
43    Copyright (C) The Internet Society (2005).  All Rights Reserved.
44
45 Abstract
46
47    This document describes an updated version of the "Security
48    Architecture for IP", which is designed to provide security services
49    for traffic at the IP layer. This document obsoletes RFC 2401
50    (November 1998).
51
52    Comments should be sent to Stephen Kent (kent@bbn.com).  [RFC Editor:
53    Please remove this line prior to publication as an RFC.]
54
55
56
57 Kent & Seo                                                      [Page 1]
58 \f
59 Internet Draft        Security Architecture for IP            March 2005
60
61
62 Table of Contents
63 1. Introduction........................................................4
64     1.1 Summary of Contents of Document................................4
65     1.2 Audience.......................................................4
66     1.3 Related Documents..............................................5
67 2. Design Objectives...................................................5
68     2.1 Goals/Objectives/Requirements/Problem Description..............5
69     2.2 Caveats and Assumptions........................................6
70 3. System Overview ....................................................7
71     3.1 What IPsec Does................................................7
72     3.2 How IPsec Works................................................9
73     3.3 Where IPsec Can Be Implemented................................10
74 4. Security Associations..............................................11
75     4.1 Definition and Scope..........................................11
76     4.2 SA Functionality..............................................16
77     4.3 Combining SAs.................................................17
78     4.4 Major IPsec Databases.........................................17
79        4.4.1 The Security Policy Database (SPD).......................19
80           4.4.1.1 Selectors...........................................25
81           4.4.1.2 Structure of an SPD entry...........................29
82           4.4.1.3 More re: Fields Associated with Next Layer
83                   Protocols...........................................31
84        4.4.2 Security Association Database (SAD)......................33
85           4.4.2.1 Data Items in the SAD...............................34
86           4.4.2.2 Relationship between SPD, PFP flag, packet, and SAD.36
87        4.4.3 Peer Authorization Database (PAD)........................41
88           4.4.3.1 PAD Entry IDs and Matching Rules....................42
89           4.4.3.2 IKE Peer Authentication Data........................43
90           4.4.3.3 Child SA Authorization Data.........................44
91           4.4.3.4 How the PAD Is Used.................................44
92     4.5 SA and Key Management.........................................45
93        4.5.1 Manual Techniques........................................46
94        4.5.2 Automated SA and Key Management..........................46
95        4.5.3 Locating a Security Gateway..............................47
96     4.6 SAs and Multicast.............................................48
97 5. IP Traffic Processing..............................................48
98     5.1 Outbound IP Traffic Processing (protected-to-unprotected).....49
99        5.1.1 Handling an Outbound Packet That Must Be Discarded.......52
100        5.1.2 Header Construction for Tunnel Mode......................53
101           5.1.2.1 IPv4 -- Header Construction for Tunnel Mode.........55
102           5.1.2.2 IPv6 -- Header Construction for Tunnel Mode.........56
103     5.2 Processing Inbound IP Traffic (unprotected-to-protected)......57
104 6. ICMP Processing ...................................................61
105     6.1 Processing ICMP Error Messages Directed to an IPsec
106                    Implementation.....................................61
107        6.1.1 ICMP Error Messages Received on the Unprotected
108                    Side of the Boundary...............................61
109        6.1.2 ICMP Error Messages Received on the Protected
110                    Side of the Boundary...............................62
111
112
113 Kent & Seo                                                      [Page 2]
114 \f
115 Internet Draft        Security Architecture for IP            March 2005
116
117
118     6.2 Processing Protected, Transit ICMP Error Messages.............62
119 7. Handling Fragments (on the protected side of the IPsec boundary)...64
120     7.1 Tunnel Mode SAs that Carry Initial and Non-Initial Fragments..65
121     7.2 Separate Tunnel Mode SAs for Non-Initial Fragments............65
122     7.3 Stateful Fragment Checking....................................66
123     7.4 BYPASS/DISCARD traffic........................................66
124 8. Path MTU/DF Processing.............................................67
125     8.1 DF Bit........................................................67
126     8.2 Path MTU (PMTU) Discovery.....................................67
127        8.2.1 Propagation of PMTU......................................68
128        8.2.2 PMTU Aging...............................................68
129 9. Auditing...........................................................69
130 10. Conformance Requirements..........................................69
131 11. Security Considerations...........................................69
132 12. IANA Considerations...............................................70
133 13. Differences from RFC 2401.........................................70
134 Acknowledgements......................................................73
135 Appendix A -- Glossary................................................74
136 Appendix B -- Decorrelation...........................................77
137 Appendix C -- ASN.1 for an SPD Entry..................................80
138 Appendix D -- Fragment Handling Rationale.............................86
139     D.1 Transport Mode and Fragments..................................86
140     D.2 Tunnel Mode and Fragments.....................................87
141     D.3 The Problem of Non-Initial Fragments..........................88
142     D.4 BYPASS/DISCARD traffic........................................91
143     D.5 Just say no to ports?.........................................91
144     D.6 Other Suggested Solutions.....................................92
145     D.7 Consistency...................................................93
146     D.8 Conclusions...................................................93
147 Appendix E -- Example of Supporting Nested SAs via SPD and Forwarding
148                     Table Entries.....................................94
149 References............................................................96
150 Author Information....................................................99
151 Notices..............................................................100
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169 Kent & Seo                                                      [Page 3]
170 \f
171 Internet Draft        Security Architecture for IP            March 2005
172
173
174 1. Introduction
175
176 1.1 Summary of Contents of Document
177
178    This document specifies the base architecture for IPsec compliant
179    systems.  It describes how to provide a set of security services for
180    traffic at the IP layer, in both the IPv4 [Pos81a] and IPv6 [DH98]
181    environments.  This document describes the requirements for systems
182    that implement IPsec, the fundamental elements of such systems, and
183    how the elements fit together and fit into the IP environment.  It
184    also describes the security services offered by the IPsec protocols,
185    and how these services can be employed in the IP environment.  This
186    document does not address all aspects of the IPsec architecture.
187    Other documents address additional architectural details in
188    specialized environments, e.g., use of IPsec in Network Address
189    Translation (NAT) environments and more comprehensive support for IP
190    multicast.  The fundamental components of the IPsec security
191    architecture are discussed in terms of their underlying, required
192    functionality.  Additional RFCs (see Section 1.3 for pointers to
193    other documents) define the protocols in (a), (c), and (d).
194
195         a. Security Protocols -- Authentication Header (AH) and
196            Encapsulating Security Payload (ESP)
197         b. Security Associations -- what they are and how they work,
198            how they are managed, associated processing
199         c. Key Management -- manual and automated (The Internet Key
200            Exchange (IKE))
201         d. Cryptographic algorithms for authentication and encryption
202
203    This document is not a Security Architecture for the Internet; it
204    addresses security only at the IP layer, provided through the use of
205    a combination of cryptographic and protocol security mechanisms.
206
207    The spelling "IPsec" is preferred and used throughout this and all
208    related IPsec standards.  All other capitalizations of IPsec (e.g.,
209    IPSEC, IPSec, ipsec) are deprecated. However, any capitalization of
210    the sequence of letters "IPsec" should be understood to refer to the
211    IPsec protocols.
212
213    The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
214    SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
215    document, are to be interpreted as described in RFC 2119 [Bra97].
216
217 1.2 Audience
218
219    The target audience for this document is primarily individuals who
220    implement this IP security technology or who architect systems that
221    will use this technology.  Technically adept users of this technology
222    (end users or system administrators) also are part of the target
223
224
225 Kent & Seo                                                      [Page 4]
226 \f
227 Internet Draft        Security Architecture for IP            March 2005
228
229
230    audience.  A glossary is provided in Appendix A to help fill in gaps
231    in background/vocabulary.  This document assumes that the reader is
232    familiar with the Internet Protocol (IP), related networking
233    technology, and general information system security terms and
234    concepts.
235
236 1.3 Related Documents
237
238    As mentioned above, other documents provide detailed definitions of
239    some of the components of IPsec and of their inter-relationship.
240    They include RFCs on the following topics:
241
242         a. security protocols -- RFCs describing the Authentication
243            Header (AH) [Ken05b] and Encapsulating Security Payload
244           (ESP) [Ken05a] protocols.
245         b. cryptographic algorithms for integrity and encryption - one
246            RFC that defines the mandatory, default algorithms for use
247            with AH and ESP [Eas05], a similar RFC that defines the
248            mandatory algorithms for use with IKE v2 [Sch05] plus a
249            separate RFC for each cryptographic algorithm.
250         c. automatic key management -- RFCs on "The Internet Key
251            Exchange (IKE v2) Protocol" [Kau05] and "Cryptographic
252            Algorithms for use in the Internet Key Exchange Version 2"
253            [Sch05].
254
255
256 2. Design Objectives
257
258 2.1 Goals/Objectives/Requirements/Problem Description
259
260    IPsec is designed to provide interoperable, high quality,
261    cryptographically-based security for IPv4 and IPv6.  The set of
262    security services offered includes access control, connectionless
263    integrity, data origin authentication, detection and rejection of
264    replays (a form of partial sequence integrity), confidentiality (via
265    encryption), and limited traffic flow confidentiality.  These
266    services are provided at the IP layer, offering protection in a
267    standard fashion for all protocols that may be carried over IP
268    (including IP itself).
269
270    IPsec includes a specification for minimal firewall functionality,
271    since that is an essential aspect of access control at the IP layer.
272    Implementations are free to provide more sophisticated firewall
273    mechanisms, and to implement the IPsec-mandated functionality using
274    those more sophisticated mechanisms. (Note that interoperability may
275    suffer if additional firewall constraints on traffic flows are
276    imposed by an IPsec implementation but cannot be negotiated based on
277    the traffic selector features defined in this document and negotiated
278    via IKE v2.) The IPsec firewall function makes use of the
279
280
281 Kent & Seo                                                      [Page 5]
282 \f
283 Internet Draft        Security Architecture for IP            March 2005
284
285
286    cryptographically-enforced authentication and integrity provided for
287    all IPsec traffic to offer better access control than could be
288    obtained through use of a firewall (one not privy to IPsec internal
289    parameters) plus separate cryptographic protection.
290
291    Most of the security services are provided through use of two traffic
292    security protocols, the Authentication Header (AH) and the
293    Encapsulating Security Payload (ESP), and through the use of
294    cryptographic key management procedures and protocols.  The set of
295    IPsec protocols employed in a context, and the ways in which they are
296    employed, will be determined by the users/administrators in that
297    context. It is the goal of the IPsec architecture to ensure that
298    compliant implementations include the services and management
299    interfaces needed to meet the security requirements of a broad user
300    population.
301
302    When IPsec is correctly implemented and deployed, it ought not
303    adversely affect users, hosts, and other Internet components that do
304    not employ IPsec for traffic protection.  IPsec security protocols
305    (AH & ESP, and to a lesser extent, IKE) are designed to be
306    cryptographic algorithm-independent.  This modularity permits
307    selection of different sets of cryptographic algorithms as
308    appropriate, without affecting the other parts of the implementation.
309    For example, different user communities may select different sets of
310    cryptographic algorithms (creating cryptographically-enforced
311    cliques) if required.
312
313    To facilitate interoperability in the global Internet, a set of
314    default cryptographic algorithms for use with AH and ESP is specified
315    in [Eas05] and a set of mandatory-to-implement algorithms for IKE v2
316    is specified in [Sch05].  [Eas05] and [Sch05] will be periodically
317    updated to keep pace with computational and cryptologic advances.  By
318    specifying these algorithms in documents that are separate from the
319    AH, ESP, and IKE v2 specifications, these algorithms can be updated
320    or replaced without affecting the standardization progress of the
321    rest of the IPsec document suite. The use of these cryptographic
322    algorithms, in conjunction with IPsec traffic protection and key
323    management protocols, is intended to permit system and application
324    developers to deploy high quality, Internet layer, cryptographic
325    security technology.
326
327 2.2 Caveats and Assumptions
328
329    The suite of IPsec protocols and associated default cryptographic
330    algorithms are designed to provide high quality security for Internet
331    traffic.  However, the security offered by use of these protocols
332    ultimately depends on the quality of the their implementation, which
333    is outside the scope of this set of standards.  Moreover, the
334    security of a computer system or network is a function of many
335
336
337 Kent & Seo                                                      [Page 6]
338 \f
339 Internet Draft        Security Architecture for IP            March 2005
340
341
342    factors, including personnel, physical, procedural, compromising
343    emanations, and computer security practices.  Thus IPsec is only one
344    part of an overall system security architecture.
345
346    Finally, the security afforded by the use of IPsec is critically
347    dependent on many aspects of the operating environment in which the
348    IPsec implementation executes.  For example, defects in OS security,
349    poor quality of random number sources, sloppy system management
350    protocols and practices, etc. can all degrade the security provided
351    by IPsec.  As above, none of these environmental attributes are
352    within the scope of this or other IPsec standards.
353
354 3. System Overview
355
356    This section provides a high level description of how IPsec works,
357    the components of the system, and how they fit together to provide
358    the security services noted above.  The goal of this description is
359    to enable the reader to "picture" the overall process/system, see how
360    it fits into the IP environment, and to provide context for later
361    sections of this document, which describe each of the components in
362    more detail.
363
364    An IPsec implementation operates in a host, as a security gateway, or
365    as an independent device, affording protection to IP traffic. (A
366    security gateway is an intermediate system implementing IPsec, e.g.,
367    a firewall or router that has been IPsec-enabled.) More detail on
368    these classes of implementations is provided later, in Section 3.3.
369    The protection offered by IPsec is based on requirements defined by a
370    Security Policy Database (SPD) established and maintained by a user
371    or system administrator, or by an application operating within
372    constraints established by either of the above.  In general, packets
373    are selected for one of three processing actions based on IP and next
374    layer header information (Selectors, Section 4.4.1.1) matched against
375    entries in the Security Policy Database (SPD).  Each packet is either
376    PROTECTed using IPsec security services, DISCARDed, or allowed to
377    BYPASS IPsec protection, based on the applicable SPD policies
378    identified by the Selectors.
379
380
381 3.1 What IPsec Does
382
383    IPsec creates a boundary between unprotected and protected
384    interfaces, for a host or a network (see Figure 1 below). Traffic
385    traversing the boundary is subject to the access controls specified
386    by the user or administrator responsible for the IPsec configuration.
387    These controls indicate whether packets cross the boundary unimpeded,
388    are afforded security services via AH or ESP, or are discarded. IPsec
389    security services are offered at the IP layer through selection of
390    appropriate security protocols, cryptographic algorithms, and
391
392
393 Kent & Seo                                                      [Page 7]
394 \f
395 Internet Draft        Security Architecture for IP            March 2005
396
397
398    cryptographic keys.  IPsec can be used to protect one or more "paths"
399    (a) between a pair of hosts, (b) between a pair of security gateways,
400    or (c) between a security gateway and a host. A compliant host
401    implementation MUST support (a) and (c) and a compliant security
402    gateway must support all three of these forms of connectivity, since
403    under certain circumstances a security gateway acts as a host.
404
405                         Unprotected
406                          ^       ^
407                          |       |
408            +-------------|-------|-------+
409            | +-------+   |       |       |
410            | |Discard|<--|       V       |
411            | +-------+   |B  +--------+  |
412          ................|y..| AH/ESP |..... IPsec Boundary
413            |   +---+     |p  +--------+  |
414            |   |IKE|<----|a      ^       |
415            |   +---+     |s      |       |
416            | +-------+   |s      |       |
417            | |Discard|<--|       |       |
418            | +-------+   |       |       |
419            +-------------|-------|-------+
420                          |       |
421                          V       V
422                          Protected
423
424             Figure 1.  Top Level IPsec Processing Model
425
426
427    In this diagram, "unprotected" refers to an interface that might also
428    be described as "black" or "ciphertext." Here, "protected" refers to
429    an interface that might also be described as "red" or "plaintext."
430    The protected interface noted above may be internal, e.g., in a host
431    implementation of IPsec, the protected interface may link to a socket
432    layer interface presented by the OS. In this document, the term
433    "inbound" refers to traffic entering an IPsec implementation via the
434    unprotected interface or emitted by the implementation on the
435    unprotected side of the boundary and directed towards the protected
436    interface. The term "outbound" refers to traffic entering the
437    implementation via the protected interface, or emitted by the
438    implementation on the protected side of the boundary and directed
439    toward the unprotected interface.  An IPsec implementation may
440    support more than one interface on either or both sides of the
441    boundary.
442
443    Note the facilities for discarding traffic on either side of the
444    IPsec boundary, the BYPASS facility that allows traffic to transit
445    the boundary without cryptographic protection, and the reference to
446    IKE as a protected-side key and security management function.
447
448
449 Kent & Seo                                                      [Page 8]
450 \f
451 Internet Draft        Security Architecture for IP            March 2005
452
453
454    IPsec optionally supports negotiation of IP compression [SMPT01],
455    motivated in part by the observation that when encryption is employed
456    within IPsec, it prevents effective compression by lower protocol
457    layers.
458
459 3.2 How IPsec Works
460
461    IPsec uses two protocols to provide traffic security services --
462    Authentication Header (AH) and Encapsulating Security Payload (ESP).
463    Both protocols are described in detail in their respective RFCs
464    [Ken05b, Ken05a]. IPsec implementations MUST support ESP and MAY
465    support AH. (Support for AH has been downgraded to MAY because
466    experience has shown that there are very few contexts in which ESP
467    cannot provide the requisite security services. Note that ESP can be
468    used to provide only integrity, without confidentiality, making it
469    comparable to AH in most contexts.)
470
471     o The IP Authentication Header (AH) [Ken05b] offers integrity and
472       data origin authentication, with optional (at the discretion of
473       the receiver) anti-replay features.
474
475     o The Encapsulating Security Payload (ESP) protocol [Ken05a] offers
476       the same set of services, and also offers confidentiality. Use of
477       ESP to provide confidentiality without integrity is NOT
478       RECOMMENDED. When ESP is used with confidentiality enabled, there
479       are provisions for limited traffic flow confidentiality, i.e.,
480       provisions for concealing packet length, and for facilitating
481       efficient generation and discard of dummy packets. This capability
482       is likely to be effective primarily in VPN and overlay network
483       contexts.
484
485     o Both AH and ESP offer access control, enforced through the
486       distribution of cryptographic keys and the management of traffic
487       flows as dictated by the Security Policy Database (SPD, Section
488       4.4.1).
489
490    These protocols may be applied individually or in combination with
491    each other to provide IPv4 and IPv6 security services. However, most
492    security requirements can be met through the use of ESP by itself.
493    Each protocol supports two modes of use: transport mode and tunnel
494    mode.  In transport mode, AH and ESP provide protection primarily for
495    next layer protocols; in tunnel mode, AH and ESP are applied to
496    tunneled IP packets.  The differences between the two modes are
497    discussed in Section 4.1.
498
499    IPsec allows the user (or system administrator) to control the
500    granularity at which a security service is offered.  For example, one
501    can create a single encrypted tunnel to carry all the traffic between
502    two security gateways or a separate encrypted tunnel can be created
503
504
505 Kent & Seo                                                      [Page 9]
506 \f
507 Internet Draft        Security Architecture for IP            March 2005
508
509
510    for each TCP connection between each pair of hosts communicating
511    across these gateways.  IPsec, through the SPD management paradigm,
512    incorporates facilities for specifying:
513
514     o which security protocol (AH or ESP) to employ, the mode (transport
515       or tunnel), security service options, what cryptographic
516       algorithms to use, and in what combinations to use the specified
517       protocols and services,
518
519     o the granularity at which protection should be applied.
520
521    Because most of the security services provided by IPsec require the
522    use of cryptographic keys, IPsec relies on a separate set of
523    mechanisms for putting these keys in place. This document requires
524    support for both manual and automated distribution of keys.  It
525    specifies a specific public-key based approach (IKE v2 [Kau05]) for
526    automated key management, but other automated key distribution
527    techniques MAY be used.
528
529    Note: This document mandates support for several features for which
530    support is available in IKE v2 but not in IKE v1, e.g., negotiation
531    of an SA representing ranges of local and remote ports or negotiation
532    of multiple SAs with the same selectors. Therefore this document
533    assumes use of IKE v2 or a key and security association management
534    system with comparable features.
535
536 3.3 Where IPsec Can Be Implemented
537
538    There are many ways in which IPsec may be implemented in a host, or
539    in conjunction with a router or firewall to create a security
540    gateway, or as an independent security device.
541
542    a. IPsec may be integrated into the native IP stack.  This requires
543       access to the IP source code and is applicable to both hosts and
544       security gateways, although native host implementations benefit
545       the most from this strategy, as explained later (Section 4.4.1,
546       paragraph 6; Section 4.4.1.1, last paragraph).
547
548    b. In a "bump-in-the-stack" (BITS) implementation, IPsec is
549       implemented "underneath" an existing implementation of an IP
550       protocol stack, between the native IP and the local network
551       drivers.  Source code access for the IP stack is not required in
552       this context, making this implementation approach appropriate for
553       use with legacy systems.  This approach, when it is adopted, is
554       usually employed in hosts.
555
556    c. The use of a dedicated, inline security protocol processor is a
557       common design feature of systems used by the military, and of some
558       commercial systems as well.  It is sometimes referred to as a
559
560
561 Kent & Seo                                                     [Page 10]
562 \f
563 Internet Draft        Security Architecture for IP            March 2005
564
565
566       "bump-in-the-wire" (BITW) implementation.  Such implementations
567       may be designed to serve either a host or a gateway.  Usually the
568       BITW device is itself IP addressable.  When supporting a single
569       host, it may be quite analogous to a BITS implementation, but in
570       supporting a router or firewall, it must operate like a security
571       gateway.
572
573    This document often talks in terms of use of IPsec by a host or a
574    security gateway, without regard to whether the implementation is
575    native, BITS or BITW. When the distinctions among these
576    implementation options are significant, the document makes reference
577    to specific implementation approaches.
578
579    A host implementation of IPsec may appear in devices that might not
580    be viewed as "hosts." For example, a router might employ IPsec to
581    protect routing protocols (e.g., BGP) and management functions (e.g.,
582    Telnet), without affecting subscriber traffic traversing the router.
583    A security gateway might employ separate IPsec implementations to
584    protect its management traffic and subscriber traffic. The
585    architecture described in this document is very flexible. For
586    example, a computer with a full-featured, compliant, native OS IPsec
587    implementation should be capable of being configured to protect
588    resident (host) applications and to provide security gateway
589    protection for traffic traversing the computer. Such configuration
590    would make use of the forwarding tables and the SPD selection
591    function described in Sections 5.1 and 5.2.
592
593 4. Security Associations
594
595    This section defines Security Association management requirements for
596    all IPv6 implementations and for those IPv4 implementations that
597    implement AH, ESP, or both AH and ESP.  The concept of a "Security
598    Association" (SA) is fundamental to IPsec.  Both AH and ESP make use
599    of SAs and a major function of IKE is the establishment and
600    maintenance of SAs.  All implementations of AH or ESP MUST support
601    the concept of an SA as described below.  The remainder of this
602    section describes various aspects of SA management, defining required
603    characteristics for SA policy management and SA management
604    techniques.
605
606 4.1 Definition and Scope
607
608    An SA is a simplex "connection" that affords security services to the
609    traffic carried by it.  Security services are afforded to an SA by
610    the use of AH, or ESP, but not both.  If both AH and ESP protection
611    are applied to a traffic stream, then two SAs must be created and
612    coordinated to effect protection through iterated application of the
613    security protocols.  To secure typical, bi-directional communication
614    between two IPsec-enabled systems, a pair of SAs (one in each
615
616
617 Kent & Seo                                                     [Page 11]
618 \f
619 Internet Draft        Security Architecture for IP            March 2005
620
621
622    direction) is required. IKE explicitly creates SA pairs in
623    recognition of this common usage requirement.
624
625    For an SA used to carry unicast traffic, the SPI (Security Parameters
626    Index - see Appendix A and AH [Ken05b] and ESP [Ken05a]
627    specifications) by itself suffices to specify an SA. However, as a
628    local matter, an implementation may choose to use the SPI in
629    conjunction with the IPsec protocol type (AH or ESP) for SA
630    identification. If an IPsec implementation supports multicast, then
631    it MUST support multicast SAs using the algorithm below for mapping
632    inbound IPsec datagrams to SAs. Implementations that support only
633    unicast traffic need not implement this demultiplexing algorithm.
634
635    In many secure multicast architectures, e.g., [RFC3740], a central
636    Group Controller/Key Server unilaterally assigns the Group Security
637    Association's (GSA's) SPI.  This SPI assignment is not negotiated or
638    coordinated with the key management (e.g., IKE) subsystems that
639    reside in the individual end systems that constitute the group.
640    Consequently, it is possible that a GSA and a unicast SA can
641    simultaneously use the same SPI. A multicast-capable IPsec
642    implementation MUST correctly de-multiplex inbound traffic even in
643    the context of SPI collisions.
644
645    Each entry in the SA Database (SAD) (Section 4.4.2) must indicate
646    whether the SA lookup makes use of the destination IP address, or the
647    destination and source IP addresses, in addition to the SPI. For
648    multicast SAs, the protocol field is not employed for SA lookups. For
649    each inbound, IPsec-protected packet, an implementation must conduct
650    its search of the SAD such that it finds the entry that matches the
651    "longest" SA identifier. In this context, if two or more SAD entries
652    match based on the SPI value, then the entry that also matches based
653    on destination address, or destination and source address (as
654    indicated in the SAD entry) is the "longest" match. This implies a
655    logical ordering of the SAD search as follows:
656
657
658       1. Search the SAD for a match on the combination of SPI,
659          destination address, and source address. If an SAD entry
660          matches, then process the inbound packet with that
661          matching SAD entry. Otherwise, proceed to step 2.
662
663       2. Search the SAD for a match on both SPI and destination address.
664          If the SAD entry matches then process the inbound packet
665          with that matching SAD entry. Otherwise, proceed to step 3.
666
667       3. Search the SAD for a match on only SPI if the receiver has
668          chosen to maintain a single SPI space for AH and ESP, and on
669          both SPI  and protocol otherwise. If an SAD entry matches then
670          process the inbound packet with that matching SAD entry.
671
672
673 Kent & Seo                                                     [Page 12]
674 \f
675 Internet Draft        Security Architecture for IP            March 2005
676
677
678          Otherwise, discard the packet and log an auditable event.
679
680
681    In practice, an implementation may choose any method (or none at all)
682    to accelerate this search, although its externally visible behavior
683    MUST be functionally equivalent to having searched the SAD in the
684    above order. For example, a software-based implementation could index
685    into a hash table by the SPI. The SAD entries in each hash table
686    bucket's linked list could be kept sorted to have those SAD entries
687    with the longest SA identifiers first in that linked list. Those SAD
688    entries having the shortest SA identifiers could be sorted so that
689    they are the last entries in the linked list. A hardware-based
690    implementation may be able to effect the longest match search
691    intrinsically, using commonly available Ternary Content-Addressable
692    Memory (TCAM) features.
693
694    The indication of whether source and destination address matching is
695    required to map inbound IPsec traffic to SAs MUST be set either as a
696    side effect of manual SA configuration or via negotiation using an SA
697    management protocol, e.g., IKE or GDOI [RFC3547]. Typically,
698    Source-Specific Multicast (SSM) [HC03] groups use a 3-tuple SA
699    identifier composed of an SPI, a destination multicast address, and
700    source address. An Any-Source Multicast group SA requires only an SPI
701    and a destination multicast address as an identifier.
702
703    If different classes of traffic (distinguished by Differentiated
704    Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the
705    same SA, and if the receiver is employing the optional anti-replay
706    feature available in both AH and ESP, this could result in
707    inappropriate discarding of lower priority packets due to the
708    windowing mechanism used by this feature.  Therefore a sender SHOULD
709    put traffic of different classes, but with the same selector values,
710    on different SAs to support QoS appropriately.  To permit this, the
711    IPsec implementation MUST permit establishment and maintenance of
712    multiple SAs between a given sender and receiver, with the same
713    selectors.  Distribution of traffic among these parallel SAs to
714    support QoS is locally determined by the sender and is not negotiated
715    by IKE. The receiver MUST process the packets from the different SAs
716    without prejudice. These requirements apply to both transport and
717    tunnel mode SAs. In the case of tunnel mode SAs, the DSCP values in
718    question appear in the inner IP header. In transport mode, the DSCP
719    value might change en route, but this should not cause problems with
720    respect to IPsec processing since the value is not employed for SA
721    selection and MUST NOT be checked as part of SA/packet validation.
722    However, if significant re-ordering of packets occurs in an SA, e.g.,
723    as a result of changes to DSCP values en route, this may trigger
724    packet discarding by a receiver due to application of the anti-replay
725    mechanism.
726
727
728
729 Kent & Seo                                                     [Page 13]
730 \f
731 Internet Draft        Security Architecture for IP            March 2005
732
733
734    DISCUSSION: While the DSCP [NiBlBaBL98, Gro02] and Explicit
735    Congestion Notification (ECN) [RaFlBl01] fields are not "selectors",
736    as that term in used in this architecture, the sender will need a
737    mechanism to direct packets with a given (set of) DSCP values to the
738    appropriate SA.  This mechanism might be termed a "classifier".
739
740    As noted above, two types of SAs are defined: transport mode and
741    tunnel mode. IKE creates pairs of SAs, so for simplicity, we choose
742    to require that both SAs in a pair be of the same mode, transport or
743    tunnel.
744
745    A transport mode SA is an SA typically employed between a pair of
746    hosts to provide end-to-end security services. When security is
747    desired between two intermediate systems along a path (vs. end-to-end
748    use of IPsec), transport mode MAY be used between security gateways
749    or between a security gateway and a host.  In the case where
750    transport mode is used between security gateways or between a
751    security gateway and a host, transport mode may be used to support
752    in-IP tunneling (e.g., IP-in-IP [Per96] or GRE tunneling
753    [FaLiHaMeTr00] or Dynamic routing [ToEgWa04]) over transport mode
754    SAs. To clarify, the use of transport mode by an intermediate system
755    (e.g., a security gateway) is permitted only when applied to packets
756    whose source address (for outbound packets) or destination address
757    (for inbound packets) is an address belonging to the intermediate
758    system itself. The access control functions that are an important
759    part of IPsec are significantly limited in this context, as they
760    cannot be applied to the end-to-end headers of the packets that
761    traverse a transport mode SA used in this fashion. Thus this way of
762    using transport mode should be evaluated carefully before being
763    employed in a specific context.
764
765    In IPv4, a transport mode security protocol header appears
766    immediately after the IP header and any options, and before any next
767    layer protocols (e.g., TCP or UDP).  In IPv6, the security protocol
768    header appears after the base IP header and selected extension
769    headers, but may appear before or after destination options; it MUST
770    appear before next layer protocols (e.g., TCP, UDP, SCTP).  In the
771    case of ESP, a transport mode SA provides security services only for
772    these next layer protocols, not for the IP header or any extension
773    headers preceding the ESP header.  In the case of AH, the protection
774    is also extended to selected portions of the IP header preceding it,
775    selected portions of extension headers, and selected options
776    (contained in the IPv4 header, IPv6 Hop-by-Hop extension header, or
777    IPv6 Destination extension headers).  For more details on the
778    coverage afforded by AH, see the AH specification [Ken05b].
779
780    A tunnel mode SA is essentially an SA applied to an IP tunnel, with
781    the access controls applied to the headers of the traffic inside the
782    tunnel.  Two hosts MAY establish a tunnel mode SA between themselves.
783
784
785 Kent & Seo                                                     [Page 14]
786 \f
787 Internet Draft        Security Architecture for IP            March 2005
788
789
790    Aside from the two exceptions below, whenever either end of a
791    security association is a security gateway, the SA MUST be tunnel
792    mode.  Thus an SA between two security gateways is typically a tunnel
793    mode SA, as is an SA between a host and a security gateway.  The two
794    exceptions are as follows.
795
796     o Where traffic is destined for a security gateway, e.g., SNMP
797       commands, the security gateway is acting as a host and transport
798       mode is allowed.  In this case, the SA terminates at a host
799       (management) function within a security gateway and thus merits
800       different treatment.
801
802     o As noted above, security gateways MAY support a transport mode SA
803       to provide security for IP traffic between two intermediate
804       systems along a path, e.g., between a host and a security gateway
805       or between two security gateways.
806
807    Several concerns motivate the use of tunnel mode for an SA involving
808    a security gateway. For example, if there are multiple paths (e.g.,
809    via different security gateways) to the same destination behind a
810    security gateway, it is important that an IPsec packet be sent to the
811    security gateway with which the SA was negotiated.  Similarly, a
812    packet that might be fragmented en-route must have all the fragments
813    delivered to the same IPsec instance for reassembly prior to
814    cryptographic processing. Also, when a fragment is processed by IPsec
815    and transmitted, then fragmented en-route, it is critical that there
816    be inner and outer headers to retain the fragmentation state data for
817    the pre- and post-IPsec packet formats. Hence there are several
818    reasons for employing tunnel mode when either end of an SA is a
819    security gateway. (Use of an IP-in-IP tunnel in conjunction with
820    transport mode can also address these fragmentation issues. However,
821    this configuration limits the ability of IPsec to enforce access
822    control policies on traffic.)
823
824    Note: AH and ESP cannot be applied using transport mode to IPv4
825    packets that are fragments. Only tunnel mode can be employed in such
826    cases. For IPv6, it would be feasible to carry a plaintext fragment
827    on a transport mode SA; however, for simplicity, this restriction
828    also applies to IPv6 packets.  See Section 7 for more details on
829    handling plaintext fragments on the protected side of the IPsec
830    barrier.
831
832    For a tunnel mode SA, there is an "outer" IP header that specifies
833    the IPsec processing source and destination, plus an "inner" IP
834    header that specifies the (apparently) ultimate source and
835    destination for the packet. The security protocol header appears
836    after the outer IP header, and before the inner IP header.  If AH is
837    employed in tunnel mode, portions of the outer IP header are afforded
838    protection (as above), as well as all of the tunneled IP packet
839
840
841 Kent & Seo                                                     [Page 15]
842 \f
843 Internet Draft        Security Architecture for IP            March 2005
844
845
846    (i.e., all of the inner IP header is protected, as well as next layer
847    protocols).  If ESP is employed, the protection is afforded only to
848    the tunneled packet, not to the outer header.
849
850    In summary,
851
852    a) A host implementation of IPsec MUST support both transport and
853       tunnel mode. This is true for native, BITS, and BITW
854       implementations for hosts.
855
856    b) A security gateway MUST support tunnel mode and MAY support
857       transport mode.  If it supports transport mode, that should be
858       used only when the security gateway is acting as a host, e.g., for
859       network management, or to provide security between two
860       intermediate systems along a path.
861
862 4.2 SA Functionality
863
864    The set of security services offered by an SA depends on the security
865    protocol selected, the SA mode, the endpoints of the SA, and on the
866    election of optional services within the protocol.
867
868    For example, both AH and ESP offer integrity and authentication
869    services, but the coverage differs for each protocol and differs for
870    transport vs. tunnel mode. If the integrity of an IPv4 option or IPv6
871    extension header must be protected en-route between sender and
872    receiver, AH can provide this service, except for IP or extension
873    headers that may change in a fashion not predictable by the sender.
874    However, the same security may be achieved in some contexts by
875    applying ESP to a tunnel carrying a packet.
876
877    The granularity of access control provided is determined by the
878    choice of the selectors that define each SA. Moreover, the
879    authentication means employed by IPsec peers, e.g., during creation
880    of an IKE (vs. child) SA also effects the granularity of the access
881    control afforded.
882
883    If confidentiality is selected, then an ESP (tunnel mode) SA between
884    two security gateways can offer partial traffic flow confidentiality.
885    The use of tunnel mode allows the inner IP headers to be encrypted,
886    concealing the identities of the (ultimate) traffic source and
887    destination.  Moreover, ESP payload padding also can be invoked to
888    hide the size of the packets, further concealing the external
889    characteristics of the traffic. Similar traffic flow confidentiality
890    services may be offered when a mobile user is assigned a dynamic IP
891    address in a dialup context, and establishes a (tunnel mode) ESP SA
892    to a corporate firewall (acting as a security gateway).  Note that
893    fine granularity SAs generally are more vulnerable to traffic
894    analysis than coarse granularity ones that are carrying traffic from
895
896
897 Kent & Seo                                                     [Page 16]
898 \f
899 Internet Draft        Security Architecture for IP            March 2005
900
901
902    many subscribers.
903
904    Note: A compliant implementation MUST NOT allow instantiation of an
905    ESP SA that employs both NULL encryption and no integrity algorithm.
906    An attempt to negotiate such an SA is an auditable event by both
907    initiator and responder. The audit log entry for this event SHOULD
908    include the current date/time, local IKE IP address, and remote IKE
909    IP address.  The initiator SHOULD record the relevant SPD entry.
910
911 4.3 Combining SAs
912
913    This document does not require support for nested security
914    associations or for what RFC 2401 called "SA bundles." These features
915    still can be effected by appropriate configuration of both the SPD
916    and the local forwarding functions (for inbound and outbound
917    traffic), but this capability is outside of the IPsec module and thus
918    the scope of this specification. As a result, management of
919    nested/bundled SAs is potentially more complex and less assured than
920    under the model implied by RFC 2401. An implementation that provides
921    support for nested SAs SHOULD provide a management interface that
922    enables a user or administrator to express the nesting requirement,
923    and then create the appropriate SPD entries and forwarding table
924    entries to effect the requisite processing. (See Appendix E for an
925    example of how to configure nested SAs.)
926
927 4.4 Major IPsec Databases
928
929    Many of the details associated with processing IP traffic in an IPsec
930    implementation are largely a local matter, not subject to
931    standardization.  However, some external aspects of the processing
932    must be standardized to ensure interoperability and to provide a
933    minimum management capability that is essential for productive use of
934    IPsec.  This section describes a general model for processing IP
935    traffic relative to IPsec functionality, in support of these
936    interoperability and functionality goals.  The model described below
937    is nominal; implementations need not match details of this model as
938    presented, but the external behavior of implementations MUST
939    correspond to the externally observable characteristics of this model
940    in order to be compliant.
941
942    There are three nominal databases in this model: the Security Policy
943    Database (SPD), the Security Association Database (SAD), and the Peer
944    Authorization Database (PAD).  The first specifies the policies that
945    determine the disposition of all IP traffic inbound or outbound from
946    a host or security gateway (Section 4.4.1).  The second database
947    contains parameters that are associated with each established (keyed)
948    SA (Section 4.4.2). The third database, the Peer Authorization
949    Database (PAD) provides a link between an SA management protocol like
950    IKE and the SPD (Section 4.4.3).
951
952
953 Kent & Seo                                                     [Page 17]
954 \f
955 Internet Draft        Security Architecture for IP            March 2005
956
957
958    Multiple Separate IPsec Contexts
959
960       If an IPsec implementation acts as a security gateway for multiple
961       subscribers, it MAY implement multiple separate IPsec contexts.
962       Each context MAY have and MAY use completely independent
963       identities, policies, key management SAs, and/or IPsec SAs.  This
964       is for the most part a local implementation matter. However, a
965       means for associating inbound (SA) proposals with local contexts
966       is required.  To this end, if supported by the key management
967       protocol in use, context identifiers MAY be conveyed from
968       initiator to responder in the signaling messages, with the result
969       that IPsec SAs are created with a binding to a particular context.
970       For example, a security gateway that provides VPN service to
971       multiple customers will be able to associate each customer's
972       traffic with the correct VPN.
973
974    Forwarding vs Security Decisions
975
976       The IPsec model described here embodies a clear separation between
977       forwarding (routing) and security decisions, to accommodate a wide
978       range of contexts where IPsec may be employed. Forwarding may be
979       trivial, in the case where there are only two interfaces, or it
980       may be complex, e.g., if the context in which IPsec is implemented
981       employs a sophisticated forwarding function. IPsec assumes only
982       that outbound and inbound traffic that has passed through IPsec
983       processing is forwarded in a fashion consistent with the context
984       in which IPsec is implemented. Support for nested SAs is optional;
985       if required, it requires coordination between forwarding tables
986       and SPD entries to cause a packet to traverse the IPsec boundary
987       more than once.
988
989    "Local" vs "Remote"
990
991       In this document, with respect to IP addresses and ports, the
992       terms "Local" and "Remote" are used for policy rules.  "Local"
993       refers to the entity being protected by an IPsec implementation,
994       i.e., the "source" address/port of outbound packets or the
995       "destination" address/port of inbound packets. "Remote" refers to
996       a peer entity or peer entities.  The terms "source" and
997       "destination" are used for packet header fields.
998
999    "Non-initial" vs "Initial" Fragments
1000
1001       Throughout this document, the phrase "non-initial" fragments is
1002       used to mean fragments that do not contain all of the selector
1003       values that may be needed for access control (e.g., they might not
1004       contain Next Layer Protocol, source and destination ports, ICMP
1005       message type/code, Mobility Header type). And the phrase "initial"
1006       fragment is used to mean a fragment that contains all the selector
1007
1008
1009 Kent & Seo                                                     [Page 18]
1010 \f
1011 Internet Draft        Security Architecture for IP            March 2005
1012
1013
1014       values needed for access control. However, it should be noted that
1015       for IPv6, which fragment contains the Next Layer Protocol and
1016       ports (or ICMP message type/code or Mobility Header type) will
1017       depend on the kind and number of extension headers present.  The
1018       "initial" fragment might not be the first fragment, in this
1019       context.
1020
1021 4.4.1 The Security Policy Database (SPD)
1022
1023    An SA is a management construct used to enforce security policy for
1024    traffic crossing the IPsec boundary. Thus an essential element of SA
1025    processing is an underlying Security Policy Database (SPD) that
1026    specifies what services are to be offered to IP datagrams and in what
1027    fashion.  The form of the database and its interface are outside the
1028    scope of this specification.  However, this section specifies minimum
1029    management functionality that must be provided, to allow a user or
1030    system administrator to control whether and how IPsec is applied to
1031    traffic transmitted or received by a host or transiting a security
1032    gateway.  The SPD, or relevant caches, must be consulted during the
1033    processing of all traffic (inbound and outbound), including traffic
1034    not protected by IPsec, that traverses the IPsec boundary.  This
1035    includes IPsec management traffic such as IKE.  An IPsec
1036    implementation MUST have at least one SPD, and it MAY support
1037    multiple SPDs, if appropriate for the context in which the IPsec
1038    implementation operates. There is no requirement to maintain SPDs on
1039    a per interface basis, as was specified in RFC 2401. However, if an
1040    implementation supports multiple SPDs, then it MUST include an
1041    explicit SPD selection function, that is invoked to select the
1042    appropriate SPD for outbound traffic processing. The inputs to this
1043    function are the outbound packet and any local metadata (e.g., the
1044    interface via which the packet arrived) required to effect the SPD
1045    selection function. The output of the function is an SPD identifier
1046    (SPD-ID).
1047
1048    The SPD is an ordered database, consistent with the use of ACLs or
1049    packet filters in firewalls, routers, etc. The ordering requirement
1050    arises because entries often will overlap due to the presence of
1051    (non-trivial) ranges as values for selectors.  Thus a user or
1052    administrator MUST be able to order the entries to express a desired
1053    access control policy. There is no way to impose a general, canonical
1054    order on SPD entries, because of the allowed use of wildcards for
1055    selector values and because the different types of selectors are not
1056    hierarchically related.
1057
1058    Processing Choices:  DISCARD, BYPASS, PROTECT
1059
1060       An SPD must discriminate among traffic that is afforded IPsec
1061       protection and traffic that is allowed to bypass IPsec. This
1062       applies to the IPsec protection to be applied by a sender and to
1063
1064
1065 Kent & Seo                                                     [Page 19]
1066 \f
1067 Internet Draft        Security Architecture for IP            March 2005
1068
1069
1070       the IPsec protection that must be present at the receiver.  For
1071       any outbound or inbound datagram, three processing choices are
1072       possible: DISCARD, BYPASS IPsec, or PROTECT using IPsec.  The
1073       first choice refers to traffic that is not allowed to traverse the
1074       IPsec boundary (in the specified direction).  The second choice
1075       refers to traffic that is allowed to cross the IPsec boundary
1076       without IPsec protection.  The third choice refers to traffic that
1077       is afforded IPsec protection, and for such traffic the SPD must
1078       specify the security protocols to be employed, their mode,
1079       security service options, and the cryptographic algorithms to be
1080       used.
1081
1082    SPD-S, SPD-I, SPD-O
1083
1084       An SPD is logically divided into three pieces. The SPD-S (secure
1085       traffic) contains entries for all traffic subject to IPsec
1086       protection. SPD-O (outbound) contains entries for all outbound
1087       traffic that is to be bypassed or discarded. SPD-I (inbound) is
1088       applied to inbound traffic that will be bypassed or discarded. All
1089       three of these can be decorrelated (with the exception noted above
1090       for native host implementations) to facilitate caching.  If an
1091       IPsec implementation supports only one SPD, then the SPD consists
1092       of all three parts. If multiple SPDs are supported, some of them
1093       may be partial, e.g., some SPDs might contain only SPD-I entries,
1094       to control inbound bypassed traffic on a per-interface basis.  The
1095       split allows SPD-I to be consulted without having to consult
1096       SPD-S, for such traffic. Since the SPD-I is just a part of the
1097       SPD, if a packet that is looked up in the SPD-I cannot be matched
1098       to an entry there, then the packet MUST be discarded.  Note that
1099       for outbound traffic, if a match is not found in SPD-S, then SPD-O
1100       must be checked to see if the traffic should be bypassed.
1101       Similarly, if SPD-O is checked first and no match is found, then
1102       SPD-S must be checked. In an ordered, non-decorrelated SPD, the
1103       entries for the SPD-S, SPD-I, and SPD-O are interleaved.  So there
1104       is one look up in the SPD.
1105
1106    SPD entries
1107
1108       Each SPD entry specifies packet disposition as BYPASS, DISCARD, or
1109       PROTECT. The entry is keyed by a list of one or more selectors.
1110       The SPD contains an ordered list of these entries. The required
1111       selector types are defined in Section 4.4.1.1. These selectors are
1112       used to define the granularity of the SAs that are created in
1113       response to an outbound packet or in response to a proposal from a
1114       peer. The detailed structure of an SPD entry is described in
1115       Section 4.4.1.2. Every SPD SHOULD have a nominal, final entry that
1116       matches anything that is otherwise unmatched, and discards it.
1117
1118       The SPD MUST permit a user or administrator to specify policy
1119
1120
1121 Kent & Seo                                                     [Page 20]
1122 \f
1123 Internet Draft        Security Architecture for IP            March 2005
1124
1125
1126       entries as follows:
1127
1128        - SPD-I: For inbound traffic that is to be bypassed or discarded,
1129          the entry consists of the values of the selectors that apply to
1130          the traffic to be bypassed or discarded.
1131
1132        - SPD-O: For outbound traffic that is to be bypassed or
1133          discarded, the entry consists of the values of the selectors
1134          that apply to the traffic to be bypassed or discarded.
1135
1136        - SPD-S: For traffic that is to be protected using IPsec, the
1137          entry consists of the values of the selectors that apply to the
1138          traffic to be protected via AH or ESP, controls on how to
1139          create SAs based on these selectors, and the parameters needed
1140          to effect this protection (e.g., algorithms, modes, etc.). Note
1141          that an SPD-S entry also contains information such as "populate
1142          from packet" (PFP) flag (see paragraphs below on "How To Derive
1143          the Values for an SAD entry") and bits indicating whether the
1144          SA lookup makes use of the local and remote IP addresses in
1145          addition to the SPI (see AH [Ken05b] or ESP [Ken05a]
1146          specifications).
1147
1148    Representing directionality in an SPD entry
1149
1150       For traffic protected by IPsec, the Local and Remote address and
1151       ports in an SPD entry are swapped to represent directionality,
1152       consistent with IKE conventions. In general, the protocols that
1153       IPsec deals with have the property of requiring symmetric SAs with
1154       flipped Local/Remote IP addresses. However, for ICMP, there is
1155       often no such bi-directional authorization requirement.
1156       Nonetheless, for the sake of uniformity and simplicity, SPD
1157       entries for ICMP are specified in the same way as for other
1158       protocols. Note also that for ICMP, Mobility Header, and
1159       non-initial fragments, there are no port fields in these packets.
1160       ICMP has message type and code and Mobility Header has mobility
1161       header type. Thus SPD entries have provisions for expressing
1162       access controls appropriate for these protocols, in lieu of the
1163       normal port field controls. For bypassed or discarded traffic,
1164       separate inbound and outbound entries are supported, e.g., to
1165       permit unidirectional flows if required.
1166
1167    OPAQUE and ANY
1168
1169       For each selector in an SPD entry, in addition to the literal
1170       values that define a match, there are two special values: ANY and
1171       OPAQUE. ANY is a wildcard that matches any value in the
1172       corresponding field of the packet, or that matches packets where
1173       that field is not present or is obscured. OPAQUE indicates that
1174       the corresponding selector field is not available for examination
1175
1176
1177 Kent & Seo                                                     [Page 21]
1178 \f
1179 Internet Draft        Security Architecture for IP            March 2005
1180
1181
1182       because it may not be present in a fragment, does not exist for
1183       the given Next Layer Protocol, or because prior application of
1184       IPsec may have encrypted the value. The ANY value encompasses the
1185       OPAQUE value. Thus OPAQUE need be used only when it is necessary
1186       to distinguish between the case of any allowed value for a field,
1187       vs. the absence or unavailability (e.g., due to encryption) of the
1188       field.
1189
1190    How To Derive the Values for an SAD entry
1191
1192       For each selector in an SPD entry, the entry specifies how to
1193       derive the corresponding values for a new SA Database (SAD, see
1194       Section 4.4.2) entry from those in the SPD and the packet. The
1195       goal is to allow an SAD entry and an SPD cache entry to be created
1196       based on specific selector values from the packet, or from the
1197       matching SPD entry. For outbound traffic, there are SPD-S cache
1198       entries and SPD-O cache entries.  For inbound traffic not
1199       protected by IPsec, there are SPD-I cache entries and there is the
1200       SAD, which represents the cache for inbound IPsec-protected
1201       traffic (See Section 4.4.2).  If IPsec processing is specified for
1202       an entry, a "populate from packet" (PFP) flag may be asserted for
1203       one or more of the selectors in the SPD entry (Local IP address;
1204       Remote IP address; Next Layer Protocol; and, depending on Next
1205       Layer Protocol, Local port and Remote port, or ICMP type/code, or
1206       Mobility Header type).  If asserted for a given selector X, the
1207       flag indicates that the SA to be created should take its value for
1208       X from the value in the packet.  Otherwise, the SA should take its
1209       value(s) for X from the value(s) in the SPD entry.  Note: In the
1210       non-PFP case, the selector values negotiated by the SA management
1211       protocol (e.g., IKE v2) may be a subset of those in the SPD entry,
1212       depending on the SPD policy of the peer.  Also, whether a single
1213       flag is used for, e.g., source port, ICMP type/code, and MH type,
1214       or a separate flag is used for each, is a local matter.
1215
1216       The following example illustrates the use of the PFP flag in the
1217       context of a security gateway or a BITS/BITW implementation.
1218       Consider an SPD entry where the allowed value for Remote address
1219       is a range of IPv4 addresses: 192.0.2.1 to 192.0.2.10. Suppose an
1220       outbound packet arrives with a destination address of 192.0.2.3,
1221       and there is no extant SA to carry this packet. The value used for
1222       the SA created to transmit this packet could be either of the two
1223       values shown below, depending on what the SPD entry for this
1224       selector says is the source of the selector value:
1225
1226
1227
1228
1229
1230
1231
1232
1233 Kent & Seo                                                     [Page 22]
1234 \f
1235 Internet Draft        Security Architecture for IP            March 2005
1236
1237
1238           PFP flag value  example of new
1239           for the Remote  SAD dest. address
1240           addr. selector  selector value
1241           --------------- ------------
1242           a. PFP TRUE     192.0.2.3 (one host)
1243           b. PFP FALSE    192.0.2.1 to 192.0.2.10 (range of hosts)
1244
1245       Note that if the SPD entry above had a value of ANY for the Remote
1246       address, then the SAD selector value would have to be ANY for case
1247       (b), but would still be as illustrated for case (a).  Thus the PFP
1248       flag can be used to prohibit sharing of an SA, even among packets
1249       that match the same SPD entry.
1250
1251    Management Interface
1252
1253       For every IPsec implementation, there MUST be a management
1254       interface that allows a user or system administrator to manage the
1255       SPD. The interface must allow the user (or administrator) to
1256       specify the security processing to be applied to every packet that
1257       traverses the IPsec boundary. (In a native host IPsec
1258       implementation making use of a socket interface, the SPD may not
1259       need to be consulted on a per packet basis, as noted above.)  The
1260       management interface for the SPD MUST allow creation of entries
1261       consistent with the selectors defined in Section 4.4.1.1, and MUST
1262       support (total) ordering of these entries, as seen via this
1263       interface. The SPD entries' selectors are analogous to the ACL or
1264       packet filters commonly found in a stateless firewall or packet
1265       filtering router and which are currently managed this way.
1266
1267       In host systems, applications MAY be allowed to create SPD
1268       entries.  (The means of signaling such requests to the IPsec
1269       implementation are outside the scope of this standard.)  However,
1270       the system administrator MUST be able to specify whether or not a
1271       user or application can override (default) system policies. The
1272       form of the management interface is not specified by this document
1273       and may differ for hosts vs. security gateways, and within hosts
1274       the interface may differ for socket-based vs. BITS
1275       implementations.  However, this document does specify a standard
1276       set of SPD elements that all IPsec implementations MUST support.
1277
1278    Decorrelation
1279
1280       The processing model described in this document assumes the
1281       ability to decorrelate overlapping SPD entries to permit caching,
1282       which enables more efficient processing of outbound traffic in
1283       security gateways and BITS/BITW implementations. Decorrelation
1284       [CoSa04] is only a means of improving performance and simplifying
1285       the processing description. This RFC does not require a compliant
1286       implementation to make use of decorrelation. For example, native
1287
1288
1289 Kent & Seo                                                     [Page 23]
1290 \f
1291 Internet Draft        Security Architecture for IP            March 2005
1292
1293
1294       host implementations typically make use of caching implicitly
1295       because they bind SAs to socket interfaces, and thus there is no
1296       requirement to be able to decorrelate SPD entries in these
1297       implementations.
1298
1299       Note:  Unless otherwise qualified, the use of "SPD" refers to the
1300       body of policy information in both ordered or decorrelated
1301       (unordered) state.  Appendix B provides an algorithm that can be
1302       used to decorrelate SPD entries, but any algorithm that produces
1303       equivalent output may be used. Note that when an SPD entry is
1304       decorrelated all the resulting entries MUST be linked together, so
1305       that all members of the group derived from an individual, SPD
1306       entry (prior to decorrelation) can all be placed into caches and
1307       into the SAD at the same time.  For example, suppose one starts
1308       with an entry A (from an ordered SPD) that when decorrelated,
1309       yields entries A1, A2 and A3.  When a packet comes along that
1310       matches, say A2, and triggers the creation of an SA, the SA
1311       management protocol, e.g., IKE v2, negotiates A.  And all 3
1312       decorrelated entries, A1, A2, and A3 are placed in the appropriate
1313       SPD-S cache and linked to the SA. The intent is that use of a
1314       decorrelated SPD ought not to create more SAs than would have
1315       resulted from use of a not-decorrelated SPD.
1316
1317       If a decorrelated SPD is employed, there are three options for
1318       what an initiator sends to a peer via an SA management protocol
1319       (e.g., IKE). By sending the complete set of linked, decorrelated
1320       entries that were selected from the SPD, a peer is given the best
1321       possible information to enable selection of the appropriate SPD
1322       entry at its end, especially if the peer has also decorrelated its
1323       SPD. However, if a large number of decorrelated entries are
1324       linked, this may create large packets for SA negotiation, and
1325       hence fragmentation problems for the SA management protocol.
1326
1327       Alternatively, the original entry from the (correlated) SPD may be
1328       retained and passed to the SA management protocol. Passing the
1329       correlated SPD entry keeps the use of a decorrelated SPD a local
1330       matter, not visible to peers, and avoids possible fragmentation
1331       concerns, although it provides less precise info to a responder
1332       for matching against the responder's SPD.
1333
1334       An intermediate approach is to send a subset of the complete set
1335       of linked, decorrelated SPD entries. This approach can avoid the
1336       fragmentation problems cited above and yet provide better
1337       information than the original, correlated entry. The major
1338       shortcoming of this approach is that it may cause additional SAs
1339       to be created later, since only a subset of the linked,
1340       decorrelated entries are sent to a peer. Implementers are free to
1341       employ any of the approaches cited above.
1342
1343
1344
1345 Kent & Seo                                                     [Page 24]
1346 \f
1347 Internet Draft        Security Architecture for IP            March 2005
1348
1349
1350       A responder uses the traffic selector proposals it receives via an
1351       SA management protocol to select an appropriate entry in its SPD.
1352       The intent of the matching is to select an SPD entry and create an
1353       SA that most closely matches the intent of the initiator, so that
1354       traffic traversing the resulting SA will be accepted at both ends.
1355       If the responder employs a decorrelated SPD, it SHOULD use the
1356       decorrelated SPD entries for matching, as this will generally
1357       result in creation of SAs that are more likely to match the intent
1358       of both peers. If the responder has a correlated SPD, then it
1359       SHOULD match the proposals against the correlated entries.  For
1360       IKE v2, use of a decorrelated SPD  offers the best opportunity for
1361       a responder to generate a "narrowed" response.
1362
1363       In all cases, when a decorrelated SPD is available, the
1364       decorrelated entries are used to populate the SPD-S cache. If the
1365       SPD is not decorrelated, caching is not allowed and an ordered
1366       search of SPD MUST be performed to verify that inbound traffic
1367       arriving on an SA is consistent with the access control policy
1368       expressed in the SPD.
1369
1370    Handling Changes to the SPD while the System is Running
1371
1372       If a change is made to the SPD while the system is running, a
1373       check SHOULD be made of the effect of this change on extant SAs.
1374       An implementation SHOULD check the impact of an SPD change on
1375       extant SAs and SHOULD provide a user/administrator with a
1376       mechanism for configuring what actions to take, e.g., delete an
1377       affected SA, allow an affected SA to continue unchanged, etc.
1378
1379 4.4.1.1  Selectors
1380
1381    An SA may be fine-grained or coarse-grained, depending on the
1382    selectors used to define the set of traffic for the SA.  For example,
1383    all traffic between two hosts may be carried via a single SA, and
1384    afforded a uniform set of security services.  Alternatively, traffic
1385    between a pair of hosts might be spread over multiple SAs, depending
1386    on the applications being used (as defined by the Next Layer Protocol
1387    and related fields, e.g., ports), with different security services
1388    offered by different SAs.  Similarly, all traffic between a pair of
1389    security gateways could be carried on a single SA, or one SA could be
1390    assigned for each communicating host pair.  The following selector
1391    parameters MUST be supported by all IPsec implementations to
1392    facilitate control of SA granularity. Note that both Local and Remote
1393    addresses should either be IPv4 or IPv6, but not a mix of address
1394    types. Also, note that the Local/Remote port selectors (and ICMP
1395    message type and code, and Mobility Header type) may be labeled as
1396    OPAQUE to accommodate situations where these fields are inaccessible
1397    due to packet fragmentation.
1398
1399
1400
1401 Kent & Seo                                                     [Page 25]
1402 \f
1403 Internet Draft        Security Architecture for IP            March 2005
1404
1405
1406       - Remote IP Address(es) (IPv4 or IPv6): this is a list of ranges
1407         of IP addresses (unicast, broadcast (IPv4 only)). This structure
1408         allows expression of a single IP address (via a trivial range),
1409         or a list of addresses (each a trivial range), or a range of
1410         addresses (low and high values, inclusive), as well as the most
1411         generic form of a list of ranges.  Address ranges are used to
1412         support more than one remote system sharing the same SA, e.g.,
1413         behind a security gateway.
1414
1415       - Local IP Address(es) (IPv4 or IPv6): this is a list of ranges of
1416         IP addresses (unicast, broadcast (IPv4 only)). This structure
1417         allows expression of a single IP address (via a trivial range),
1418         or a list of addresses (each a trivial range), or a range of
1419         addresses (low and high values, inclusive), as well as the most
1420         generic form of a list of ranges.  Address ranges are used to
1421         support more than one source system sharing the same SA, e.g.,
1422         behind a security gateway.  Local refers to the address(es)
1423         being protected by this implementation (or policy entry).
1424
1425         Note: The SPD does not include support for multicast address
1426         entries. To support multicast SAs, an implementation should make
1427         use of a Group SPD (GSPD) as defined in [RFC3740]. GSPD entries
1428         require a different structure, i.e., one cannot use of the
1429         symmetric relationship associated with local and remote address
1430         values for unicast SAs in a multicast context. Specifically,
1431         outbound traffic directed to a multicast address on an SA would
1432         not be received on a companion, inbound SA with the multicast
1433         address as the source.
1434
1435       - Next Layer Protocol: Obtained from the IPv4 "Protocol" or the
1436         IPv6 "Next Header" fields.  This is an individual protocol
1437         number, ANY, or for IPv6 only, OPAQUE. The Next Layer Protocol
1438         is whatever comes after any IP extension headers that are
1439         present. To simplify locating the Next Layer Protocol, there
1440         SHOULD be a mechanism for configuring which IPv6 extension
1441         headers to skip.  The default configuration for which protocols
1442         to skip SHOULD include the following protocols: 0 (Hop-by-hop
1443         options), 43 (Routing Header), 44 (Fragmentation Header), and 60
1444         (Destination Options).  Note: The default list does NOT include
1445         51 (AH), or 50 (ESP).  From a selector lookup point of view,
1446         IPsec treats AH and ESP as Next Layer Protocols.
1447
1448         Several additional selectors depend on the Next Layer Protocol
1449         value:
1450
1451          * If the Next Layer Protocol uses two ports (e.g., TCP, UDP,
1452            SCTP, ...), then there are selectors for Local and Remote
1453            Ports. Each of these selectors has a list of ranges of
1454            values. Note that the Local and Remote ports may not be
1455
1456
1457 Kent & Seo                                                     [Page 26]
1458 \f
1459 Internet Draft        Security Architecture for IP            March 2005
1460
1461
1462            available in the case of receipt of a fragmented packet or if
1463            the port fields have been protected by IPsec (encrypted),
1464            thus a value of OPAQUE also MUST be supported.  Note: In a
1465            non-initial fragment, port values will not be available. If a
1466            port selector specifies a value other than ANY or OPAQUE, it
1467            cannot match packets that are non-initial fragments.  If the
1468            SA requires a port value other than ANY or OPAQUE, an
1469            arriving fragment without ports MUST be discarded. (See
1470            Section 7 Handling Fragments.)
1471
1472          * If the Next Layer Protocol is a Mobility Header, then there
1473            is a selector for IPv6 Mobility Header Message Type (MH type)
1474            [Mobip].  This is an 8-bit value that identifies a particular
1475            mobility message.  Note that the MH type may not be available
1476            in the case of receipt of a fragmented packet. (See Section 7
1477            Handling Fragments.) For IKE, the IPv6 mobility header
1478            message type (MH type) is placed in the most significant
1479            eight bits of the 16-bit local "port" selector.
1480
1481          * If the Next Layer Protocol value is ICMP then there is a
1482            16-bit selector for the ICMP message type and code. The
1483            message type is a single 8-bit value, which defines the type
1484            of an ICMP message, or ANY. The ICMP code is a single 8-bit
1485            value that defines a specific subtype for an ICMP message.
1486            For IKE, the message type is placed in the most significant 8
1487            bits of the 16-bit selector and the code is placed in the
1488            least significant 8 bits. This 16-bit selector can contain a
1489            single type and a range of codes, a single type and ANY code,
1490            ANY type and ANY code. Given a policy entry with a range of
1491            Types (T-start to T-end) and a range of Codes (C-start to
1492            C-end), and an ICMP packet with Type t and Code c, an
1493            implementation MUST test for a match using
1494
1495                (T-start*256) + C-start <= (t*256) + c <= (T-end*256) +
1496                C-end
1497
1498            Note that the ICMP message type and code may not be available
1499            in the case of receipt of a fragmented packet. (See Section 7
1500            Handling Fragments.)
1501
1502       - Name:  This is not a selector like the others above.  It is not
1503         acquired from a packet. A name may be used as a symbolic
1504         identifier for an IPsec Local or Remote address. Named SPD
1505         entries are used in two ways:
1506
1507          1. A named SPD entry is used by a responder (not an initiator)
1508             in support of access control when an IP address would not be
1509             appropriate for the Remote IP address selector, e.g., for
1510             "road warriors."  The name used to match this field is
1511
1512
1513 Kent & Seo                                                     [Page 27]
1514 \f
1515 Internet Draft        Security Architecture for IP            March 2005
1516
1517
1518             communicated during the IKE negotiation in the ID payload.
1519             In this context, the initiator's Source IP address (inner IP
1520             header in tunnel mode) is bound to the Remote IP address in
1521             the SAD entry created by the IKE negotiation. This address
1522             overrides the Remote IP address value in the SPD, when the
1523             SPD entry is selected in this fashion.  All IPsec
1524             implementations MUST support this use of names.
1525
1526          2. A named SPD entry may be used by an initiator to identify a
1527             user for whom an IPsec SA will be created (or for whom
1528             traffic may be bypassed).  The initiator's IP source address
1529             (from inner IP header in tunnel mode) is used to replace the
1530             following if and when they are created:
1531
1532                     - local address in the SPD cache entry
1533                     - local address in the outbound SAD entry
1534                     - remote address in the inbound SAD entry
1535
1536             Support for this use is optional for multi-user, native host
1537             implementations and not applicable to other implementations.
1538             Note that this name is used only locally; it is not
1539             communicated by the key management protocol.  Also, name
1540             forms other than those used for case 1 above (responder) are
1541             applicable in the initiator context (see below).
1542
1543          An SPD entry can contain both a name (or a list of names) and
1544          also values for the Local or Remote IP address.
1545
1546          For case 1, responder, the identifiers employed in named SPD
1547          entries are one of the following four types:
1548
1549                  a. a fully qualified user name string (email), e.g.,
1550                     mozart@foo.example.com
1551                     (this corresponds to ID_RFC822_ADDR in IKE v2)
1552
1553                  b. a fully qualified DNS name, e.g.,
1554                     foo.example.com
1555                     (this corresponds to ID_FQDN in IKE v2)
1556
1557                  c. X.500 distinguished name, e.g., [WaKiHo97],
1558
1559
1560                     CN = Stephen T. Kent, O = BBN Technologies,
1561                     SP = MA, C = US
1562
1563                     (this corresponds to ID_DER_ASN1_DN in IKE v2, after
1564                     decoding)
1565
1566                  d. a byte string
1567
1568
1569 Kent & Seo                                                     [Page 28]
1570 \f
1571 Internet Draft        Security Architecture for IP            March 2005
1572
1573
1574                     (this corresponds to Key_ID in IKE v2)
1575
1576          For case 2, initiator, the identifiers employed in named SPD
1577          entries are of type byte string.  They are likely to be Unix
1578          UIDs, Windows security IDs or something similar, but could also
1579          be a user name or account name. In all cases, this identifier
1580          is only of local concern and is not transmitted.
1581
1582    The IPsec implementation context determines how selectors are used.
1583    For example, a native host implementation typically makes use of a
1584    socket interface.  When a new connection is established the SPD can
1585    be consulted and an SA bound to the socket.  Thus traffic sent via
1586    that socket need not result in additional lookups to the SPD (SPD-O
1587    and SPD-S) cache.  In contrast, a BITS, BITW, or security gateway
1588    implementation needs to look at each packet and perform an
1589    SPD-O/SPD-S cache lookup based on the selectors.
1590
1591 4.4.1.2  Structure of an SPD entry
1592
1593    This section contains a prose description of an SPD entry. Also,
1594    Appendix C provides an example of an ASN.1 definition of an SPD
1595    entry.
1596
1597    This text describes the SPD in a fashion that is intended to map
1598    directly into IKE payloads to ensure that the policy required by SPD
1599    entries can be negotiated through IKE. Unfortunately, the semantics
1600    of the version of IKE v2 published concurrently with this document
1601    [Kau05] do not align precisely with those defined for the SPD.
1602    Specifically, IKE v2 does not enable negotiation of a single SA that
1603    binds multiple pairs of local and remote addresses and ports to a
1604    single SA. Instead, when multiple local and remote addresses and
1605    ports are negotiated for an SA, IKE v2 treats these not as pairs, but
1606    as (unordered) sets of local and remote values that can be
1607    arbitrarily paired. Until IKE provides a facility that conveys the
1608    semantics that are expressed in the SPD via selector sets (as
1609    described below), users MUST NOT include multiple selector sets in a
1610    single SPD entry unless the access control intent aligns with the IKE
1611    "mix and match" semantics. An implementation MAY warn users, to alert
1612    them to this problem if users create SPD entries with multiple
1613    selector sets, the syntax of which indicates possible conflicts with
1614    current IKE semantics.
1615
1616    The management GUI can offer the user other forms of data entry and
1617    display, e.g., the option of using address prefixes as well as
1618    ranges, and symbolic names for protocols, ports, etc. (Do not confuse
1619    the use of symbolic names in a management interface with the SPD
1620    selector "Name".) Note that Remote/Local apply only to IP addresses
1621    and ports, not to ICMP message type/code or Mobility Header type.
1622    Also, if the reserved, symbolic selector value OPAQUE or ANY is
1623
1624
1625 Kent & Seo                                                     [Page 29]
1626 \f
1627 Internet Draft        Security Architecture for IP            March 2005
1628
1629
1630    employed for a given selector type, only that value may appear in the
1631    list for that selector, and it must appear only once in the list for
1632    that selector.  Note that ANY and OPAQUE are local syntax conventions
1633    -- IKE v2 negotiates these values via the ranges indicated below:
1634
1635           ANY:     start = 0        end = <max>
1636           OPAQUE:  start = <max>    end = 0
1637
1638    An SPD is an ordered list of entries each of which contains the
1639    following fields.
1640
1641            o Name -- a list of IDs.  This quasi-selector is optional.
1642              The forms that MUST be supported are described above in
1643              Section 4.4.1.1 under "Name".
1644
1645            o PFP flags -- one per traffic selector. A given flag, e.g.,
1646              for Next Layer Protocol, applies to the relevant selector
1647              across all "selector sets" (see below) contained in an SPD
1648              entry.  When creating an SA, each flag specifies for the
1649              corresponding traffic selector whether to instantiate the
1650              selector from the corresponding field in the packet that
1651
1652              triggered the creation of the SA or from the value(s) in
1653              the corresponding SPD entry (see Section 4.4.1, "How To
1654              Derive the Values for an SAD entry"). Whether a single
1655              flag is used for, e.g., source port, ICMP type/code, and
1656              MH type, or a separate flag is used for each, is a local
1657              matter. There are PFP flags for:
1658                 - Local Address
1659                 - Remote Address
1660                 - Next Layer Protocol
1661                 - Local Port, or ICMP message type/code or Mobility
1662                   Header type (depending on the next layer protocol)
1663                 - Remote Port, or ICMP message type/code or Mobility
1664                   Header type (depending on the next layer protocol)
1665
1666            o One to N selector sets that correspond to the "condition"
1667              for applying a particular IPsec action. Each selector set
1668              contains:
1669                 - Local Address
1670                 - Remote Address
1671                 - Next Layer Protocol
1672                 - Local Port, or ICMP message type/code or Mobility
1673                   Header type (depending on the next layer protocol)
1674                 - Remote Port, or ICMP message type/code or Mobility
1675                   Header type (depending on the next layer protocol)
1676
1677              Note: The "next protocol" selector is an individual value
1678              (unlike the local and remote IP addresses) in a selector
1679
1680
1681 Kent & Seo                                                     [Page 30]
1682 \f
1683 Internet Draft        Security Architecture for IP            March 2005
1684
1685
1686              set entry. This is consistent with how IKE v2 negotiates
1687              the TS values for an SA. It also makes sense because one
1688              may need to associate different port fields with different
1689              protocols. It is possible to associate multiple protocols
1690              (and ports) with a single SA by specifying multiple
1691              selector sets for that SA.
1692
1693            o processing info -- which action is required -- PROTECT,
1694              BYPASS, or DISCARD. There is just one action that goes with
1695              all the selector sets, not a separate action for each set.
1696              If the required processing is PROTECT, the entry contains
1697              the following information.
1698                 - IPsec mode -- tunnel or transport
1699                 - (if tunnel mode) local tunnel address -- For a
1700                   non-mobile host, if there is just one interface, this
1701                   is straightforward; and if there are multiple
1702                   interfaces, this must be statically configured. For a
1703                   mobile host, the specification of the local address
1704                   is handled externally to IPsec.
1705                 - (if tunnel mode) remote tunnel address -- There is no
1706                   standard way to determine this. See 4.5.3 "Locating a
1707                   Security Gateway".
1708                 - extended sequence number -- Is this SA using extended
1709                   sequence numbers?
1710                 - stateful fragment checking -- Is this SA using
1711                   stateful fragment checking (see Section 7 for more
1712                   details)
1713                 - Bypass DF bit (T/F) -- applicable to tunnel mode SAs
1714                 - Bypass DSCP (T/F) or map to unprotected DSCP values
1715                   (array) if needed to restrict bypass of DSCP values --
1716                   applicable to tunnel mode SAs
1717                 - IPsec protocol -- AH or ESP
1718                 - algorithms -- which ones to use for AH, which ones to
1719                   use for ESP, which ones to use for combined mode,
1720                   ordered by decreasing priority
1721
1722    It is a local matter as to what information is kept with regard to
1723    handling extant SAs when the SPD is changed.
1724
1725 4.4.1.3 More re: Fields Associated with Next Layer Protocols
1726
1727    Additional selectors are often associated with fields in the Next
1728    Layer Protocol header. A particular Next Layer Protocol can have
1729    zero, one, or two selectors.  There may be situations where there
1730    aren't both local and remote selectors for the fields that are
1731    dependent on the Next Layer Protocol. The IPv6 Mobility Header has
1732    only a Mobility Header message type. AH and ESP have no further
1733    selector fields.  A system may be willing to send an ICMP message
1734    type and code that it does not want to receive. In the descriptions
1735
1736
1737 Kent & Seo                                                     [Page 31]
1738 \f
1739 Internet Draft        Security Architecture for IP            March 2005
1740
1741
1742    below, "port" is used to mean a field that is dependent on the Next
1743    Layer Protocol.
1744
1745         A. If a Next Layer Protocol has no "port" selectors, then
1746            the Local and Remote "port" selectors are set to OPAQUE in
1747            the relevant SPD entry, e.g.,
1748
1749            Local's
1750              next layer protocol = AH
1751              "port" selector     = OPAQUE
1752
1753            Remote's
1754              next layer protocol = AH
1755              "port" selector     = OPAQUE
1756
1757         B. If a Next Layer Protocol has only one selector, e.g.,
1758            Mobility Header type, then that field is placed in the
1759            Local "port" selector in the relevant SPD entry, and the
1760            Remote "port" selector is set to OPAQUE in the relevant
1761            SPD entry, e.g.,
1762
1763            Local's
1764              next layer protocol = Mobility Header
1765              "port" selector     = Mobility Header message type
1766
1767            Remote's
1768              next layer protocol = Mobility Header
1769              "port" selector     = OPAQUE
1770
1771         C. If a system is willing to send traffic with a particular
1772            "port" value but NOT receive traffic with that kind of
1773            port value, the system's traffic selectors are set as
1774            follows in the relevant SPD entry:
1775
1776            Local's
1777              next layer protocol = ICMP
1778              "port" selector     = <specific ICMP type & code>
1779
1780            Remote's
1781              next layer protocol = ICMP
1782              "port" selector     = OPAQUE
1783
1784         D. To indicate that a system is willing to receive traffic
1785            with a particular "port" value but NOT send that kind of
1786            traffic, the system's traffic selectors are set as follows
1787            in the relevant SPD entry:
1788
1789            Local's
1790              next layer protocol = ICMP
1791
1792
1793 Kent & Seo                                                     [Page 32]
1794 \f
1795 Internet Draft        Security Architecture for IP            March 2005
1796
1797
1798              "port" selector     = OPAQUE
1799
1800            Remote's
1801              next layer protocol = ICMP
1802              "port" selector     = <specific ICMP type & code>
1803
1804            For example, if a security gateway is willing to allow
1805            systems behind it to send ICMP traceroutes, but is not
1806            willing to let outside systems run ICMP traceroutes to
1807            systems behind it, then the security gateway's traffic
1808            selectors are set as follows in the relevant SPD entry:
1809
1810            Local's
1811              next layer protocol = 1 (ICMPv4)
1812              "port" selector     = 30 (traceroute)
1813
1814            Remote's
1815              next layer protocol = 1 (ICMPv4)
1816              "port" selector     = OPAQUE
1817
1818 4.4.2 Security Association Database (SAD)
1819
1820    In each IPsec implementation there is a nominal Security Association
1821    Database (SAD), in which each entry defines the parameters associated
1822    with one SA.  Each SA has an entry in the SAD. For outbound
1823    processing, each SAD entry is pointed to by entries in the SPD-S part
1824    of the SPD cache. For inbound processing, for unicast SAs, the SPI is
1825    used either alone to look up an SA, or the SPI may be used in
1826    conjunction with the IPsec protocol type.  If an IPsec implementation
1827    supports multicast, the SPI plus destination address, or SPI plus
1828    destination and source addresses are used to look up the SA. (See
1829    Section 4.1 for details on the algorithm that MUST be used for
1830    mapping inbound IPsec datagrams to SAs.) The following parameters are
1831    associated with each entry in the SAD.  They should all be present
1832    except where otherwise noted, e.g., AH Authentication algorithm. This
1833    description does not purport to be a MIB, only a specification of the
1834    minimal data items required to support an SA in an IPsec
1835    implementation.
1836
1837    For each of the selectors defined in Section 4.4.1.1, the entry for
1838    an inbound SA in the SAD MUST be initially populated with the value
1839    or values negotiated at the time the SA was created. (See Section
1840    4.4.1, paragraph on  Handling Changes to the SPD while the System is
1841    Running for guidance on the effect of SPD changes on extant SAs.) For
1842    a receiver, these values are used to check that the header fields of
1843    an inbound packet (after IPsec processing) match the selector values
1844    negotiated for the SA. Thus, the SAD acts as a cache for checking the
1845    selectors of inbound traffic arriving on SAs.  For the receiver, this
1846    is part of verifying that a packet arriving on an SA is consistent
1847
1848
1849 Kent & Seo                                                     [Page 33]
1850 \f
1851 Internet Draft        Security Architecture for IP            March 2005
1852
1853
1854    with the policy for the SA. (See Section 6 for rules for ICMP
1855    messages.)  These fields can have the form of specific values,
1856    ranges, ANY, or OPAQUE, as described in section 4.4.1.1, "Selectors."
1857    Note also, that there are a couple of situations in which the SAD can
1858    have entries for SAs that do not have corresponding entries in the
1859    SPD. Since 2401bis does not mandate that the SAD be selectively
1860    cleared when the SPD is changed, SAD entries can remain when the SPD
1861    entries that created them are changed or deleted. Also, if a manually
1862    keyed SA is created, there could be an SAD entry for this SA that
1863    does not correspond to any SPD entry.
1864
1865    Note: The SAD can support multicast SAs, if manually configured. An
1866    outbound multicast SA has the same structure as a unicast SA. The
1867    source address is that of the sender and the destination address is
1868    the multicast group address. An inbound, multicast SA must be
1869    configured with the source addresses of each peer authorized to
1870    transmit to the multicast SA in question. The SPI value for a
1871    multicast SA is provided by a multicast group controller, not by the
1872    receiver, as for a unicast SA. Because an SAD entry may be required
1873    to accommodate multiple, individual IP source addresses that were
1874    part of an SPD entry (for unicast SAs), the required facility for
1875    inbound, multicast SAs is a feature already present in an IPsec
1876    implementation. However, because the SPD has no provisions for
1877    accommodating multicast entries, this document does not specify an
1878    automated way to create an SAD entry for a multicast, inbound SA.
1879    Only manually configured SAD entries can be created to accommodate
1880    inbound, multicast traffic.
1881
1882 4.4.2.1 Data Items in the SAD
1883
1884    The following data items MUST be in the SAD:
1885
1886     o Security Parameter Index (SPI): a 32-bit value selected by the
1887       receiving end of an SA to uniquely identify the SA. In an SAD
1888       entry for an outbound SA, the SPI is used to construct the
1889       packet's AH or ESP header. In an SAD entry for an inbound SA, the
1890       SPI is used to map traffic to the appropriate SA (see text on
1891       unicast/multicast in Section 4.1).
1892
1893     o Sequence Number Counter: a 64-bit counter used to generate the
1894       Sequence Number field in AH or ESP headers. 64-bit sequence
1895       numbers are the default, but 32-bit sequence numbers are also
1896       supported if negotiated.
1897
1898     o Sequence Counter Overflow: a flag indicating whether overflow of
1899       the Sequence Number Counter should generate an auditable event and
1900       prevent transmission of additional packets on the SA, or whether
1901       rollover is permitted. The audit log entry for this event SHOULD
1902       include the SPI value, current date/time, Local Address, Remote
1903
1904
1905 Kent & Seo                                                     [Page 34]
1906 \f
1907 Internet Draft        Security Architecture for IP            March 2005
1908
1909
1910       Address, and the selectors from the relevant SAD entry.
1911
1912     o Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent)
1913       used to determine whether an inbound AH or ESP packet is a replay.
1914
1915       Note: If anti-replay has been disabled by the receiver for an SA,
1916       e.g., in the case of a manually keyed SA, then the Anti-Replay
1917       Window is ignored for the SA in question. 64-bit sequence numbers
1918       are the default, but this counter size accommodates 32-bit
1919       sequence numbers as well.
1920
1921     o AH Authentication algorithm, key, etc. This is required only if AH
1922       is supported.
1923
1924     o ESP Encryption algorithm, key, mode, IV, etc. If a combined mode
1925       algorithm is used, these fields will not be applicable.
1926
1927
1928     o ESP integrity algorithm, keys, etc. If the integrity service is
1929       not selected, these fields will not be applicable. If a combined
1930       mode algorithm is used, these fields will not be applicable.
1931
1932
1933     o ESP combined mode algorithms, key(s), etc. This data is used when
1934       a combined mode (encryption and integrity) algorithm is used with
1935       ESP. If a combined mode algorithm is not used, these fields are
1936       not applicable.
1937
1938     o Lifetime of this SA: a time interval after which an SA must be
1939       replaced with a new SA (and new SPI) or terminated, plus an
1940       indication of which of these actions should occur.  This may be
1941       expressed as a time or byte count, or a simultaneous use of both
1942       with the first lifetime to expire taking precedence. A compliant
1943       implementation MUST support both types of lifetimes, and MUST
1944       support a simultaneous use of both.  If time is employed, and if
1945       IKE employs X.509 certificates for SA establishment, the SA
1946       lifetime must be constrained by the validity intervals of the
1947       certificates, and the NextIssueDate of the CRLs used in the IKE
1948       exchange for the SA.  Both initiator and responder are responsible
1949       for constraining the SA lifetime in this fashion.  Note: The
1950       details of how to handle the refreshing of keys when SAs expire is
1951       a local matter.  However, one reasonable approach is:
1952
1953      (a) If byte count is used, then the implementation SHOULD count the
1954          number of bytes to which the IPsec cryptographic algorithm is
1955          applied.  For ESP, this is the encryption algorithm (including
1956          Null encryption) and for AH, this is the authentication
1957          algorithm.  This includes pad bytes, etc.  Note that
1958          implementations MUST be able to handle having the counters at
1959
1960
1961 Kent & Seo                                                     [Page 35]
1962 \f
1963 Internet Draft        Security Architecture for IP            March 2005
1964
1965
1966          the ends of an SA get out of synch, e.g., because of packet
1967          loss or because the implementations at each end of the SA
1968          aren't doing things the same way.
1969
1970      (b) There SHOULD be two kinds of lifetime -- a soft lifetime that
1971          warns the implementation to initiate action such as setting up
1972          a replacement SA; and a hard lifetime when the current SA ends
1973          and is destroyed.
1974
1975      (c) If the entire packet does not get delivered during the SAs
1976          lifetime, the packet SHOULD be discarded.
1977
1978     o IPsec protocol mode: tunnel or transport.  Indicates which mode of
1979       AH or ESP is applied to traffic on this SA.
1980
1981     o Stateful fragment checking flag. Indicates whether or not stateful
1982       fragment checking applies to this SA.
1983
1984     o Bypass DF bit (T/F) - applicable to tunnel mode SAs where both
1985       inner and outer headers are IPv4.
1986
1987     o DSCP values -- the set of DSCP values allowed for packets carried
1988       over this SA. If no values are specified, no DSCP-specific
1989       filtering is applied. If one or more values are specified, these
1990       are used to select one SA among several that match the traffic
1991       selectors for an outbound packet. Note that these values are NOT
1992       checked against inbound traffic arriving on the SA.
1993
1994     o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if
1995       needed to restrict bypass of DSCP values - applicable to tunnel
1996       mode SAs. This feature maps DSCP values from an inner header to
1997       values in an outer header, e.g., to address covert channel
1998       signaling concerns.
1999
2000     o Path MTU: any observed path MTU and aging variables.
2001
2002     o Tunnel header IP source and destination address - both addresses
2003       must be either IPv4 or IPv6 addresses. The version implies the
2004       type of IP header to be used.  Only used when the IPsec protocol
2005       mode is tunnel.
2006
2007 4.4.2.2 Relationship between SPD, PFP flag, packet, and SAD
2008
2009       For each selector, the following tables show the relationship
2010       between the value in the SPD, the PFP flag, the value in the
2011       triggering packet and the resulting value in the SAD.  Note that
2012       the administrative interface for IPsec can use various syntactic
2013       options to make it easier for the administrator to enter rules.
2014       For example, although a list of ranges is what IKE v2 sends, it
2015
2016
2017 Kent & Seo                                                     [Page 36]
2018 \f
2019 Internet Draft        Security Architecture for IP            March 2005
2020
2021
2022       might be clearer and less error prone for the user to enter a
2023       single IP address or IP address prefix.
2024
2025                                         Value in
2026                                         Triggering   Resulting SAD
2027          Selector  SPD Entry        PFP Packet       Entry
2028          --------  ---------------- --- ------------ --------------
2029          loc addr  list of ranges    0  IP addr "S"  list of ranges
2030                    ANY               0  IP addr "S"  ANY
2031                    list of ranges    1  IP addr "S"  "S"
2032                    ANY               1  IP addr "S"  "S"
2033
2034          rem addr  list of ranges    0  IP addr "D"  list of ranges
2035                    ANY               0  IP addr "D"  ANY
2036                    list of ranges    1  IP addr "D"  "D"
2037                    ANY               1  IP addr "D"  "D"
2038
2039          protocol  list of prot's*   0  prot. "P"    list of prot's*
2040                    ANY**             0  prot. "P"    ANY
2041                    OPAQUE****        0  prot. "P"    OPAQUE
2042
2043                    list of prot's*   0  not avail.   discard packet
2044                    ANY**             0  not avail.   ANY
2045                    OPAQUE****        0  not avail.   OPAQUE
2046
2047                    list of prot's*   1  prot. "P"    "P"
2048                    ANY**             1  prot. "P"    "P"
2049                    OPAQUE****        1  prot. "P"    ***
2050
2051                    list of prot's*   1  not avail.   discard packet
2052                    ANY**             1  not avail.   discard packet
2053                    OPAQUE****        1  not avail.   ***
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073 Kent & Seo                                                     [Page 37]
2074 \f
2075 Internet Draft        Security Architecture for IP            March 2005
2076
2077
2078       If the protocol is one that has two ports then there will be
2079       selectors for both Local and Remote ports.
2080
2081                                         Value in
2082                                         Triggering   Resulting SAD
2083          Selector  SPD Entry        PFP Packet       Entry
2084          --------  ---------------- --- ------------ --------------
2085          loc port  list of ranges    0  src port "s" list of ranges
2086                    ANY               0  src port "s" ANY
2087                    OPAQUE            0  src port "s" OPAQUE
2088
2089                    list of ranges    0  not avail.   discard packet
2090                    ANY               0  not avail.   ANY
2091                    OPAQUE            0  not avail.   OPAQUE
2092
2093                    list of ranges    1  src port "s" "s"
2094                    ANY               1  src port "s" "s"
2095                    OPAQUE            1  src port "s" ***
2096
2097                    list of ranges    1  not avail.   discard packet
2098                    ANY               1  not avail.   discard packet
2099                    OPAQUE            1  not avail.   ***
2100
2101
2102          rem port  list of ranges    0  dst port "d" list of ranges
2103                    ANY               0  dst port "d" ANY
2104                    OPAQUE            0  dst port "d" OPAQUE
2105
2106                    list of ranges    0  not avail.   discard packet
2107                    ANY               0  not avail.   ANY
2108                    OPAQUE            0  not avail.   OPAQUE
2109
2110                    list of ranges    1  dst port "d" "d"
2111                    ANY               1  dst port "d" "d"
2112                    OPAQUE            1  dst port "d" ***
2113
2114                    list of ranges    1  not avail.   discard packet
2115                    ANY               1  not avail.   discard packet
2116                    OPAQUE            1  not avail.   ***
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129 Kent & Seo                                                     [Page 38]
2130 \f
2131 Internet Draft        Security Architecture for IP            March 2005
2132
2133
2134       If the protocol is mobility header then there will be a selector
2135       for mh type.
2136
2137                                         Value in
2138                                         Triggering   Resulting SAD
2139          Selector  SPD Entry        PFP Packet       Entry
2140          --------  ---------------- --- ------------ --------------
2141          mh type   list of ranges    0  mh type "T"  list of ranges
2142                    ANY               0  mh type "T"  ANY
2143                    OPAQUE            0  mh type "T"  OPAQUE
2144
2145                    list of ranges    0  not avail.   discard packet
2146                    ANY               0  not avail.   ANY
2147                    OPAQUE            0  not avail.   OPAQUE
2148
2149                    list of ranges    1  mh type "T"  "T"
2150                    ANY               1  mh type "T"  "T"
2151                    OPAQUE            1  mh type "T"  ***
2152
2153                    list of ranges    1  not avail.   discard packet
2154                    ANY               1  not avail.   discard packet
2155                    OPAQUE            1  not avail.   ***
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185 Kent & Seo                                                     [Page 39]
2186 \f
2187 Internet Draft        Security Architecture for IP            March 2005
2188
2189
2190       If the protocol is ICMP, then there will be a 16-bit selector for
2191       ICMP type and ICMP code.  Note that the type and code are bound to
2192       each other, i.e., the codes apply to the particular type. This
2193       16-bit selector can contain a single type and a range of codes, a
2194       single type and ANY code, and ANY type and ANY code.
2195
2196                                          Value in
2197                                          Triggering   Resulting SAD
2198          Selector   SPD Entry        PFP Packet       Entry
2199          ---------  ---------------- --- ------------ --------------
2200          ICMP type  a single type &   0  type "t" &   single type &
2201          and code    range of codes        code "c"    range of codes
2202                     a single type &   0  type "t" &   single type &
2203                      ANY code              code "c"    ANY code
2204                     ANY type & ANY    0  type "t" &   ANY type &
2205                      code                  code "c"    ANY code
2206                     OPAQUE            0  type "t" &   OPAQUE
2207                                            code "c"
2208
2209                     a single type &   0  not avail.   discard packet
2210                      range of codes
2211                     a single type &   0  not avail.   discard packet
2212                      ANY code
2213                     ANY type &        0  not avail.   ANY type &
2214                      ANY code                          ANY code
2215                     OPAQUE            0  not avail.   OPAQUE
2216
2217                     a single type &   1  type "t" &   "t" and "c"
2218                      range of codes        code "c"
2219                     a single type &   1  type "t" &   "t" and "c"
2220                      ANY code              code "c"
2221                     ANY type &        1  type "t" &   "t" and "c"
2222                      ANY code              code "c"
2223                     OPAQUE            1  type "t" &   ***
2224                                            code "c"
2225
2226                     a single type &   1  not avail.   discard packet
2227                      range of codes
2228                     a single type &   1  not avail.   discard packet
2229                      ANY code
2230                     ANY type &        1  not avail.   discard packet
2231                      ANY code
2232                     OPAQUE            1  not avail.   ***
2233
2234
2235
2236
2237
2238
2239
2240
2241 Kent & Seo                                                     [Page 40]
2242 \f
2243 Internet Draft        Security Architecture for IP            March 2005
2244
2245
2246       If the name selector is used...
2247
2248                                          Value in
2249                                          Triggering   Resulting SAD
2250          Selector   SPD Entry        PFP Packet       Entry
2251          ---------  ---------------- --- ------------ --------------
2252          name       list of user or  N/A     N/A           N/A
2253                     system names
2254
2255
2256             * "List of protocols" is the information, not the way
2257               that the SPD or SAD or IKv2 have to represent this
2258               information.
2259            ** 0 (zero) is used by IKE to indicate ANY for
2260               protocol.
2261           *** Use of PFP=1 with an OPAQUE value is an error and
2262               SHOULD be prohibited by an IPsec implementation.
2263          **** The protocol field cannot be OPAQUE in IPv4.  This
2264               table entry applies only to IPv6.
2265
2266 4.4.3 Peer Authorization Database (PAD)
2267
2268    The Peer Authorization Database (PAD) provides the link between the
2269    SPD and a security association management protocol such as IKE. It
2270    embodies several critical functions:
2271
2272         o identifies the peers or groups of peers that are authorized
2273           to communicate with this IPsec entity
2274         o specifies the protocol and method used to authenticate each
2275           peer
2276         o provides the authentication data for each peer
2277         o constrains the types and values of IDs that can be asserted
2278           by a peer with regard to child SA creation, to ensure that the
2279           peer does not assert identities for lookup in the SPD that it
2280           is not authorized to represent, when child SAs are created
2281         o peer gateway location info, e.g., IP address(es) or DNS names,
2282           MAY be included for peers that are known to be "behind" a
2283           security gateway
2284    The PAD provides these functions for an IKE peer when the peer acts
2285    as either the initiator or the responder.
2286
2287    To perform these functions, the PAD contains an entry for each peer
2288    or group of peers with which the IPsec entity will communicate. An
2289    entry names an individual peer (a user, end system or security
2290    gateway) or specifies a group of peers (using ID matching rules
2291    defined below). The entry specifies the authentication protocol
2292    (e.g., IKE v1, IKE v2, KINK) method used (e.g., certificates or pre-
2293    shared secrets) and the authentication data (e.g., the pre-shared
2294    secret or the trust anchor relative to which the peer's certificate
2295
2296
2297 Kent & Seo                                                     [Page 41]
2298 \f
2299 Internet Draft        Security Architecture for IP            March 2005
2300
2301
2302    will be validated). For certificate-based authentication, the entry
2303    also may provide information to assist in verifying the revocation
2304    status of the peer, e.g., a pointer to a CRL repository or the name
2305    of an OSCP server associated with the peer or with the trust anchor
2306    associated with the peer.
2307
2308    Each entry also specifies whether the IKE ID payload will be used as
2309    a symbolic name for SPD lookup, or whether the remote IP address
2310    provided in traffic selector payloads will be used for SPD lookups
2311    when child SAs are created.
2312
2313    Note that the PAD information MAY be used to support creation of more
2314    than one tunnel mode SA at a time between two peers, e.g., two
2315    tunnels to protect the same addresses/hosts, but with different
2316    tunnel endpoints.
2317
2318 4.4.3.1 PAD Entry IDs and Matching Rules
2319
2320    The PAD is an ordered database, where the order is defined by an
2321    administrator (or a user in the case of a single-user end system).
2322    Usually, the same administrator will be responsible for both the PAD
2323    and SPD, since the two databases must be coordinated. The ordering
2324    requirement for the PAD arises for the same reason as for the SPD,
2325    i.e., because use of "star name" entries allows for overlaps in the
2326    set of IKE IDs that could match a specific entry.
2327
2328    Six types of IDs are supported for entries in the PAD, consistent
2329    with the symbolic name types and IP addresses used to identify SPD
2330    entries. The ID for each entry acts as the index for the PAD, i.e.,
2331    it is the value used to select an entry. All of these ID types can be
2332    used to match IKE ID payload types. The six types are:
2333            o DNS name (specific or partial)
2334            o Distinguished Name (complete or sub-tree constrained)
2335            o RFC822 email address (complete or partially qualified)
2336            o IPv4 address (range)
2337            o IPv6 address (range)
2338            o Key ID (exact match only)
2339
2340    The first three name types can accommodate sub-tree matching as well
2341    as exact matches. A DNS name may be fully qualified and thus match
2342    exactly one name, e.g., foo.example.com. Alternatively, the name may
2343    encompass a group of peers by being partially specified, e.g., the
2344    string ".example.com" could be used to match any DNS name ending in
2345    these two domain name components.
2346
2347    Similarly, a Distinguished Name may specify a complete DN to match
2348    exactly one entry, e.g., CN = Stephen, O = BBN Technologies, SP = MA,
2349    C = US. Alternatively, an entry may encompass a group of peers by
2350    specifying a sub-tree, e.g., an entry of the form "C = US, SP = MA"
2351
2352
2353 Kent & Seo                                                     [Page 42]
2354 \f
2355 Internet Draft        Security Architecture for IP            March 2005
2356
2357
2358    might be used to match all DNs that contain these two attributes as
2359    the top two RDNs.
2360
2361    For an RFC822 e-mail addresses, the same options exist. A complete
2362    address such as foo@example.com matches one entity, but a sub-tree
2363    name such as "@example.com" could be used to match all the entities
2364    with names ending in those two domain names to the right of the @.
2365
2366    The specific syntax used by an implementation to accommodate sub-tree
2367    matching for distinguished names, domain names or RFC822 e-mail
2368    addresses is a local matter. But, at a minimum, sub-tree matching of
2369    the sort described above MUST be supported. (Substring matching
2370    within a DN, DNS name or RFC822 address MAY be supported, but is not
2371    required.)
2372
2373    For IPv4 and IPv6 addresses, the same address range syntax used for
2374    SPD entries MUST be supported. This allows specification of an
2375    individual address (via a trivial range), an address prefix (by
2376    choosing a range that adheres to CIDR-style prefixes), or an
2377    arbitrary address range.
2378
2379    The Key ID field is defined as an OCTET string in IKE. For this name
2380    type, only exact match syntax MUST be supported (since there is no
2381    explicit structure for this ID type. Additional matching functions
2382    MAY be supported for this ID type.
2383
2384 4.4.3.2 IKE Peer Authentication Data
2385
2386    Once an entry is located based on an ordered search of the PAD based
2387    on ID field matching, it is necessary to verify the asserted
2388    identity, i.e., to authenticate the asserted ID. For each PAD entry
2389    there is an indication of the type of authentication to be performed.
2390    This document requires support for two required authentication data
2391    types:
2392
2393         - X.509 certificate
2394         - pre-shared secret
2395
2396    For authentication based on an X.509 certificate, the PAD entry
2397    contains a trust anchor via which the end entity (EE) certificate for
2398    the peer must be verifiable, either directly or via a certificate
2399    path. See RFC 3280 for the definition of a trust anchor. An entry
2400    used with certificate-based authentication MAY include additional
2401    data to facilitate certificate revocation status, e.g., a list of
2402    appropriate OCSP responders or CRL repositories, and associated
2403    authentication data. For authentication based on a pre-shared secret,
2404    the PAD contains the pre-shared secret to be used by IKE.
2405
2406    This document does not require that the IKE ID asserted by a peer be
2407
2408
2409 Kent & Seo                                                     [Page 43]
2410 \f
2411 Internet Draft        Security Architecture for IP            March 2005
2412
2413
2414    syntactically related to a specific field in an end entity
2415    certificate that is employed to authenticate the identity of that
2416    peer. However, it often will be appropriate to impose such a
2417    requirement, e.g., when a single entry represents a set of peers each
2418    of whom may have a distinct SPD entry. Thus implementations MUST
2419    provide a means for an administrator to require a match between an
2420    asserted IKE ID and the subject name or subject alt name in a
2421    certificate. The former is applicable to IKE IDs expressed as
2422    distinguished names; the latter is appropriate for DNS names, RFC822
2423    e-mail addresses, and IP addresses. Since KEY ID is intended for
2424    identifying a peer authenticated via a pre-shred secret, there is no
2425    requirement to match this ID type to a certificate field.
2426
2427    See IKE v1 [HarCar98] and IKE v2 [Kau05] for details of how IKE
2428    performs peer authentication using certificates or pre-shared
2429    secrets.
2430
2431    This document does not mandate support for any other authentication
2432    methods, although such methods MAY be employed.
2433
2434 4.4.3.3 Child SA Authorization Data
2435
2436    Once an IKE peer is authenticated, child SAs may be created. Each PAD
2437    entry contains data to constrain the set of IDs that can be asserted
2438    by an IKE peer, for matching against the SPD. Each PAD entry
2439    indicates whether the IKE ID is to be used as a symbolic name for SPD
2440    matching, or whether an IP address asserted in a traffic selector
2441    payload is to be used.
2442
2443    If the entry indicates that the IKE ID is to be used, then the PAD
2444    entry ID field defines the authorized set of IDs. If the entry
2445    indicates that child SAs traffic selectors are to be used, then an
2446    additional data element is required, in the form of IPv4 and/or IPv6
2447    address ranges. (A peer may be authorized for both address types, so
2448    there MUST be provision for both a v4 and a v6 address range.)
2449
2450 4.4.3.4 How the PAD Is Used
2451
2452    During the initial IKE exchange, the initiator and responder each
2453    assert their identity via the IKE ID payload, and send an AUTH
2454    payload to verify the asserted identity. One or more CERT payloads
2455    may be transmitted to facilitate the verification of each asserted
2456    identity.
2457
2458    When an IKE entity receives an IKE ID payload, it uses the asserted
2459    ID to locate an entry in the PAD, using the matching rules described
2460    above. The PAD entry specifies the authentication method to be
2461    employed for the identified peer. This ensures that the right method
2462    is used for each peer and that different methods can be used for
2463
2464
2465 Kent & Seo                                                     [Page 44]
2466 \f
2467 Internet Draft        Security Architecture for IP            March 2005
2468
2469
2470    different peers. The entry also specifies the authentication data
2471    that will be used to verify the asserted identity.  This data is
2472    employed in conjunction with the specified method to authenticate the
2473    peer, before any CHILD SAs are created.
2474
2475
2476    Child SAs are created based on the exchange of traffic selector
2477    payloads, either at the end of the initial IKE exchange, or in
2478    subsequent CREATE_CHILD_SA exchanges. The PAD entry for the (now
2479    authenticated) IKE peer is used to constrain creation of child SAs,
2480    specifically the PAD entry specifies how the SPD is searched using a
2481    traffic selector proposal from a peer. There are two choices: either
2482    the IKE ID asserted by the peer is used to find an SPD entry via its
2483    symbolic name, or peer IP addresses asserted in traffic selector
2484    payloads are used for SPD lookups based on the remote IP address
2485    field portion of an SPD entry. It is necessary to impose these
2486    constraints on creation of child SAs, to prevent an authenticated
2487    peer from spoofing IDs associated with other, legitimate peers.
2488
2489    Note that because the PAD is checked before searching for an SPD
2490    entry, this safeguard protects an initiator against spoofing attacks.
2491    For example, assume that IKE A receives an outbound packet destined
2492    for IP address X, a host served by a security gateway. RFC 2401 and
2493    2401bis do not specify how A determines the address of the IKE peer
2494    serving X. However, any peer contacted by A as the presumed
2495    representative for X must be registered in the PAD in order to allow
2496    the IKE exchange to be authenticated. Moreover, when the
2497    authenticated peer asserts that it represents X in its traffic
2498    selector exchange, the PAD will be consulted to determine if the peer
2499    in question is authorized to represent X. Thus the PAD provides a
2500    binding of address ranges (or name sub-spaces) to peers, to counter
2501    such attacks.
2502
2503
2504 4.5 SA and Key Management
2505
2506    All IPsec implementations MUST support both manual and automated SA
2507    and cryptographic key management.  The IPsec protocols, AH and ESP,
2508    are largely independent of the associated SA management techniques,
2509    although the techniques involved do affect some of the security
2510    services offered by the protocols. For example, the optional
2511    anti-replay service available for AH and ESP requires automated SA
2512    management.  Moreover, the granularity of key distribution employed
2513    with IPsec determines the granularity of authentication provided. In
2514    general, data origin authentication in AH and ESP is limited by the
2515    extent to which secrets used with the integrity algorithm (or with a
2516    key management protocol that creates such secrets) are shared among
2517    multiple possible sources.
2518
2519
2520
2521 Kent & Seo                                                     [Page 45]
2522 \f
2523 Internet Draft        Security Architecture for IP            March 2005
2524
2525
2526    The following text describes the minimum requirements for both types
2527    of SA management.
2528
2529 4.5.1 Manual Techniques
2530
2531    The simplest form of management is manual management, in which a
2532    person manually configures each system with keying material and SA
2533    management data relevant to secure communication with other systems.
2534    Manual techniques are practical in small, static environments but
2535    they do not scale well.  For example, a company could create a
2536    Virtual Private Network (VPN) using IPsec in security gateways at
2537    several sites.  If the number of sites is small, and since all the
2538    sites come under the purview of a single administrative domain, this
2539    might be a feasible context for manual management techniques.  In
2540    this case, the security gateway might selectively protect traffic to
2541    and from other sites within the organization using a manually
2542    configured key, while not protecting traffic for other destinations.
2543    It also might be appropriate when only selected communications need
2544    to be secured.  A similar argument might apply to use of IPsec
2545    entirely within an organization for a small number of hosts and/or
2546    gateways.  Manual management techniques often employ statically
2547    configured, symmetric keys, though other options also exist.
2548
2549 4.5.2 Automated SA and Key Management
2550
2551    Widespread deployment and use of IPsec requires an Internet-standard,
2552    scalable, automated, SA management protocol. Such support is required
2553    to facilitate use of the anti-replay features of AH and ESP, and to
2554    accommodate on-demand creation of SAs, e.g., for user- and
2555    session-oriented keying.  (Note that the notion of "rekeying" an SA
2556    actually implies creation of a new SA with a new SPI, a process that
2557    generally implies use of an automated SA/key management protocol.)
2558
2559    The default automated key management protocol selected for use with
2560    IPsec is IKE v2 [Kau05].  This document assumes the availability of
2561    certain functions from the key management protocol which are not
2562    supported by IKE v1. Other automated SA management protocols MAY be
2563    employed.
2564
2565    When an automated SA/key management protocol is employed, the output
2566    from this protocol is used to generate multiple keys for a single SA.
2567    This also occurs because distinct keys are used for each of the two
2568    SAs created by IKE. If both integrity and confidentiality are
2569    employed, then a minimum of four keys are required.  Additionally,
2570    some cryptographic algorithms may require multiple keys, e.g., 3DES.
2571
2572    The Key Management System may provide a separate string of bits for
2573    each key or it may generate one string of bits from which all keys
2574    are extracted.  If a single string of bits is provided, care needs to
2575
2576
2577 Kent & Seo                                                     [Page 46]
2578 \f
2579 Internet Draft        Security Architecture for IP            March 2005
2580
2581
2582    be taken to ensure that the parts of the system that map the string
2583    of bits to the required keys do so in the same fashion at both ends
2584    of the SA.  To ensure that the IPsec implementations at each end of
2585    the SA use the same bits for the same keys, and irrespective of which
2586    part of the system divides the string of bits into individual keys,
2587    the encryption keys MUST be taken from the first (left-most,
2588    high-order) bits and the integrity keys MUST be taken from the
2589    remaining bits.  The number of bits for each key is defined in the
2590    relevant cryptographic algorithm specification RFC. In the case of
2591    multiple encryption keys or multiple integrity keys, the
2592    specification for the cryptographic algorithm must specify the order
2593    in which they are to be selected from a single string of bits
2594    provided to the cryptographic algorithm.
2595
2596 4.5.3 Locating a Security Gateway
2597
2598    This section discusses issues relating to how a host learns about the
2599    existence of relevant security gateways and once a host has contacted
2600    these security gateways, how it knows that these are the correct
2601    security gateways. The details of where the required information is
2602    stored is a local matter, but the Peer Authorization Database
2603    described in Section 4.4 is the most likely candidate. (Note: S*
2604    indicates a system that is running IPsec, e.g., SH1 and SG2 below.)
2605
2606    Consider a situation in which a remote host (SH1) is using the
2607    Internet to gain access to a server or other machine (H2) and there
2608    is a security gateway (SG2), e.g., a firewall, through which H1's
2609    traffic must pass. An example of this situation would be a mobile
2610    host crossing the Internet to his home organization's firewall (SG2).
2611    This situation raises several issues:
2612
2613    1. How does SH1 know/learn about the existence of the security
2614       gateway SG2?
2615
2616    2. How does it authenticate SG2, and once it has authenticated SG2,
2617       how does it confirm that SG2 has been authorized to represent H2?
2618
2619    3. How does SG2 authenticate SH1 and verify that SH1 is authorized to
2620       contact H2?
2621
2622    4. How does SH1 know/learn about any additional gateways that provide
2623       alternate paths to H2?
2624
2625    To address these problems, an IPsec-supporting host or security
2626    gateway MUST have an administrative interface that allows the
2627    user/administrator to configure the address of one or more security
2628    gateways for ranges of destination addresses that require its use.
2629    This includes the ability to configure information for locating and
2630    authenticating one or more security gateways and verifying the
2631
2632
2633 Kent & Seo                                                     [Page 47]
2634 \f
2635 Internet Draft        Security Architecture for IP            March 2005
2636
2637
2638    authorization of these gateways to represent the destination host.
2639    (The authorization function is implied in the PAD.) This document
2640    does not address the issue of how to automate the
2641    discovery/verification of security gateways.
2642
2643 4.6 SAs and Multicast
2644
2645    The receiver-orientation of the SA implies that, in the case of
2646    unicast traffic, the destination system will select the SPI value.
2647    By having the destination select the SPI value, there is no potential
2648    for manually configured SAs to conflict with automatically configured
2649    (e.g., via a key management protocol) SAs or for SAs from multiple
2650    sources to conflict with each other.  For multicast traffic, there
2651    are multiple destination systems associated with a single SA.  So
2652    some system or person will need to coordinate among all multicast
2653    groups to select an SPI or SPIs on behalf of each multicast group and
2654    then communicate the group's IPsec information to all of the
2655    legitimate members of that multicast group via mechanisms not defined
2656    here.
2657
2658    Multiple senders to a multicast group SHOULD use a single Security
2659    Association (and hence SPI) for all traffic to that group when a
2660    symmetric key encryption or integrity algorithm is employed. In such
2661    circumstances, the receiver knows only that the message came from a
2662    system possessing the key for that multicast group.  In such
2663    circumstances, a receiver generally will not be able to authenticate
2664    which system sent the multicast traffic.  Specifications for other,
2665    more general multicast approaches are deferred to the IETF Multicast
2666    Security Working Group.
2667
2668 5. IP Traffic Processing
2669
2670    As mentioned in Section 4.4.1 "The Security Policy Database (SPD)",
2671    the SPD (or associated caches) MUST be consulted during the
2672    processing of all traffic that crosses the IPsec protection boundary,
2673    including IPsec management traffic. If no policy is found in the SPD
2674    that matches a packet (for either inbound or outbound traffic), the
2675    packet MUST be discarded. To simplify processing, and to allow for
2676    very fast SA lookups (for SG/BITS/BITW), this document introduces the
2677    notion of an SPD cache for all outbound traffic (SPD-O plus SPD-S),
2678    and a cache for inbound, non-IPsec-protected traffic (SPD-I).  (As
2679    mentioned earlier, the SAD acts as a cache for checking the selectors
2680    of inbound IPsec-protected traffic arriving on SAs.) There is
2681    nominally one cache per SPD. For the purposes of this specification,
2682    it is assumed that each cached entry will map to exactly one SA.
2683    Note, however, exceptions arise when one uses multiple SAs to carry
2684    traffic of different priorities (e.g., as indicated by distinct DSCP
2685    values) but the same selectors.  Note also, that there are a couple
2686    of situations in which the SAD can have entries for SAs that do not
2687
2688
2689 Kent & Seo                                                     [Page 48]
2690 \f
2691 Internet Draft        Security Architecture for IP            March 2005
2692
2693
2694    have corresponding entries in the SPD. Since 2401bis does not mandate
2695    that the SAD be selectively cleared when the SPD is changed, SAD
2696    entries can remain when the SPD entries that created them are changed
2697    or deleted. Also, if a manually keyed SA is created, there could be
2698    an SAD entry for this SA that does not correspond to any SPD entry.
2699
2700    Since SPD entries may overlap, one cannot safely cache these entries
2701    in general. Simple caching might result in a match against a cache
2702    entry whereas an ordered search of the SPD would have resulted in a
2703    match against a different entry. But, if the SPD entries are first
2704    decorrelated, then the resulting entries can safely be cached. Each
2705    cached entry will indicate that matching traffic should be bypassed
2706    or discarded, appropriately. (Note: The original SPD entry might
2707    result in multiple SAs, e.g., because of PFP.) Unless otherwise
2708    noted, all references below to the "SPD" or "SPD cache" or "cache"
2709    are to a decorrelated SPD (SPD-I, SPD-O, SPD-S) or the SPD cache
2710    containing entries from the decorrelated SPD.
2711
2712    Note: In a host IPsec implementation based on sockets, the SPD will
2713    be consulted whenever a new socket is created, to determine what, if
2714    any, IPsec processing will be applied to the traffic that will flow
2715    on that socket.  This provides an implicit caching mechanism and the
2716    portions of the preceding discussion that address caching can be
2717    ignored in such implementations.
2718
2719    Note: It is assumed that one starts with a correlated SPD because
2720    that is how users and administrators are accustomed to managing these
2721    sorts of access control lists or firewall filter rules. Then the
2722    decorrelation algorithm is applied to build a list of cache-able SPD
2723    entries. The decorrelation is invisible at the management interface.
2724
2725    For inbound IPsec traffic, the SAD entry selected by the SPI serves
2726    as the cache for the selectors to be matched against arriving IPsec
2727    packets, after AH or ESP processing has been performed.
2728
2729 5.1 Outbound IP Traffic Processing (protected-to-unprotected)
2730
2731    First consider the path for traffic entering the implementation via a
2732    protected interface and exiting via an unprotected interface.
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745 Kent & Seo                                                    &n