]>
Commit | Line | Data |
---|---|---|
f91513e3 MW |
1 | |
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | Network Working Group S. Kent | |
8 | Request for Comments: 4301 K. Seo | |
9 | Obsoletes: 2401 BBN Technologies | |
10 | Category: Standards Track December 2005 | |
11 | ||
12 | ||
13 | Security Architecture for the Internet Protocol | |
14 | ||
15 | Status of This Memo | |
16 | ||
17 | This document specifies an Internet standards track protocol for the | |
18 | Internet community, and requests discussion and suggestions for | |
19 | improvements. Please refer to the current edition of the "Internet | |
20 | Official Protocol Standards" (STD 1) for the standardization state | |
21 | and status of this protocol. Distribution of this memo is unlimited. | |
22 | ||
23 | Copyright Notice | |
24 | ||
25 | Copyright (C) The Internet Society (2005). | |
26 | ||
27 | Abstract | |
28 | ||
29 | This document describes an updated version of the "Security | |
30 | Architecture for IP", which is designed to provide security services | |
31 | for traffic at the IP layer. This document obsoletes RFC 2401 | |
32 | (November 1998). | |
33 | ||
34 | Dedication | |
35 | ||
36 | This document is dedicated to the memory of Charlie Lynn, a long-time | |
37 | senior colleague at BBN, who made very significant contributions to | |
38 | the IPsec documents. | |
39 | ||
40 | ||
41 | ||
42 | ||
43 | ||
44 | ||
45 | ||
46 | ||
47 | ||
48 | ||
49 | ||
50 | ||
51 | ||
52 | ||
53 | ||
54 | ||
55 | ||
56 | ||
57 | ||
58 | Kent & Seo Standards Track [Page 1] | |
59 | \f | |
60 | RFC 4301 Security Architecture for IP December 2005 | |
61 | ||
62 | ||
63 | Table of Contents | |
64 | ||
65 | 1. Introduction ....................................................4 | |
66 | 1.1. Summary of Contents of Document ............................4 | |
67 | 1.2. Audience ...................................................4 | |
68 | 1.3. Related Documents ..........................................5 | |
69 | 2. Design Objectives ...............................................5 | |
70 | 2.1. Goals/Objectives/Requirements/Problem Description ..........5 | |
71 | 2.2. Caveats and Assumptions ....................................6 | |
72 | 3. System Overview .................................................7 | |
73 | 3.1. What IPsec Does ............................................7 | |
74 | 3.2. How IPsec Works ............................................9 | |
75 | 3.3. Where IPsec Can Be Implemented ............................10 | |
76 | 4. Security Associations ..........................................11 | |
77 | 4.1. Definition and Scope ......................................12 | |
78 | 4.2. SA Functionality ..........................................16 | |
79 | 4.3. Combining SAs .............................................17 | |
80 | 4.4. Major IPsec Databases .....................................18 | |
81 | 4.4.1. The Security Policy Database (SPD) .................19 | |
82 | 4.4.1.1. Selectors .................................26 | |
83 | 4.4.1.2. Structure of an SPD Entry .................30 | |
84 | 4.4.1.3. More Regarding Fields Associated | |
85 | with Next Layer Protocols .................32 | |
86 | 4.4.2. Security Association Database (SAD) ................34 | |
87 | 4.4.2.1. Data Items in the SAD .....................36 | |
88 | 4.4.2.2. Relationship between SPD, PFP | |
89 | flag, packet, and SAD .....................38 | |
90 | 4.4.3. Peer Authorization Database (PAD) ..................43 | |
91 | 4.4.3.1. PAD Entry IDs and Matching Rules ..........44 | |
92 | 4.4.3.2. IKE Peer Authentication Data ..............45 | |
93 | 4.4.3.3. Child SA Authorization Data ...............46 | |
94 | 4.4.3.4. How the PAD Is Used .......................46 | |
95 | 4.5. SA and Key Management .....................................47 | |
96 | 4.5.1. Manual Techniques ..................................48 | |
97 | 4.5.2. Automated SA and Key Management ....................48 | |
98 | 4.5.3. Locating a Security Gateway ........................49 | |
99 | 4.6. SAs and Multicast .........................................50 | |
100 | 5. IP Traffic Processing ..........................................50 | |
101 | 5.1. Outbound IP Traffic Processing | |
102 | (protected-to-unprotected) ................................52 | |
103 | 5.1.1. Handling an Outbound Packet That Must Be | |
104 | Discarded ..........................................54 | |
105 | 5.1.2. Header Construction for Tunnel Mode ................55 | |
106 | 5.1.2.1. IPv4: Header Construction for | |
107 | Tunnel Mode ...............................57 | |
108 | 5.1.2.2. IPv6: Header Construction for | |
109 | Tunnel Mode ...............................59 | |
110 | 5.2. Processing Inbound IP Traffic (unprotected-to-protected) ..59 | |
111 | ||
112 | ||
113 | ||
114 | Kent & Seo Standards Track [Page 2] | |
115 | \f | |
116 | RFC 4301 Security Architecture for IP December 2005 | |
117 | ||
118 | ||
119 | 6. ICMP Processing ................................................63 | |
120 | 6.1. Processing ICMP Error Messages Directed to an | |
121 | IPsec Implementation ......................................63 | |
122 | 6.1.1. ICMP Error Messages Received on the | |
123 | Unprotected Side of the Boundary ...................63 | |
124 | 6.1.2. ICMP Error Messages Received on the | |
125 | Protected Side of the Boundary .....................64 | |
126 | 6.2. Processing Protected, Transit ICMP Error Messages .........64 | |
127 | 7. Handling Fragments (on the protected side of the IPsec | |
128 | boundary) ......................................................66 | |
129 | 7.1. Tunnel Mode SAs that Carry Initial and Non-Initial | |
130 | Fragments .................................................67 | |
131 | 7.2. Separate Tunnel Mode SAs for Non-Initial Fragments ........67 | |
132 | 7.3. Stateful Fragment Checking ................................68 | |
133 | 7.4. BYPASS/DISCARD Traffic ....................................69 | |
134 | 8. Path MTU/DF Processing .........................................69 | |
135 | 8.1. DF Bit ....................................................69 | |
136 | 8.2. Path MTU (PMTU) Discovery .................................70 | |
137 | 8.2.1. Propagation of PMTU ................................70 | |
138 | 8.2.2. PMTU Aging .........................................71 | |
139 | 9. Auditing .......................................................71 | |
140 | 10. Conformance Requirements ......................................71 | |
141 | 11. Security Considerations .......................................72 | |
142 | 12. IANA Considerations ...........................................72 | |
143 | 13. Differences from RFC 2401 .....................................72 | |
144 | 14. Acknowledgements ..............................................75 | |
145 | Appendix A: Glossary ..............................................76 | |
146 | Appendix B: Decorrelation .........................................79 | |
147 | B.1. Decorrelation Algorithm ...................................79 | |
148 | Appendix C: ASN.1 for an SPD Entry ................................82 | |
149 | Appendix D: Fragment Handling Rationale ...........................88 | |
150 | D.1. Transport Mode and Fragments ..............................88 | |
151 | D.2. Tunnel Mode and Fragments .................................89 | |
152 | D.3. The Problem of Non-Initial Fragments ......................90 | |
153 | D.4. BYPASS/DISCARD Traffic ....................................93 | |
154 | D.5. Just say no to ports? .....................................94 | |
155 | D.6. Other Suggested Solutions..................................94 | |
156 | D.7. Consistency................................................95 | |
157 | D.8. Conclusions................................................95 | |
158 | Appendix E: Example of Supporting Nested SAs via SPD and | |
159 | Forwarding Table Entries...............................96 | |
160 | References.........................................................98 | |
161 | Normative References............................................98 | |
162 | Informative References..........................................99 | |
163 | ||
164 | ||
165 | ||
166 | ||
167 | ||
168 | ||
169 | ||
170 | Kent & Seo Standards Track [Page 3] | |
171 | \f | |
172 | RFC 4301 Security Architecture for IP December 2005 | |
173 | ||
174 | ||
175 | 1. Introduction | |
176 | ||
177 | 1.1. Summary of Contents of Document | |
178 | ||
179 | This document specifies the base architecture for IPsec-compliant | |
180 | systems. It describes how to provide a set of security services for | |
181 | traffic at the IP layer, in both the IPv4 [Pos81a] and IPv6 [DH98] | |
182 | environments. This document describes the requirements for systems | |
183 | that implement IPsec, the fundamental elements of such systems, and | |
184 | how the elements fit together and fit into the IP environment. It | |
185 | also describes the security services offered by the IPsec protocols, | |
186 | and how these services can be employed in the IP environment. This | |
187 | document does not address all aspects of the IPsec architecture. | |
188 | Other documents address additional architectural details in | |
189 | specialized environments, e.g., use of IPsec in Network Address | |
190 | Translation (NAT) environments and more comprehensive support for IP | |
191 | multicast. The fundamental components of the IPsec security | |
192 | architecture are discussed in terms of their underlying, required | |
193 | functionality. Additional RFCs (see Section 1.3 for pointers to | |
194 | other documents) define the protocols in (a), (c), and (d). | |
195 | ||
196 | a. Security Protocols -- Authentication Header (AH) and | |
197 | Encapsulating Security Payload (ESP) | |
198 | b. Security Associations -- what they are and how they work, | |
199 | how they are managed, associated processing | |
200 | c. Key Management -- manual and automated (The Internet Key | |
201 | Exchange (IKE)) | |
202 | d. Cryptographic algorithms for authentication and encryption | |
203 | ||
204 | This document is not a Security Architecture for the Internet; it | |
205 | addresses security only at the IP layer, provided through the use of | |
206 | a combination of cryptographic and protocol security mechanisms. | |
207 | ||
208 | The spelling "IPsec" is preferred and used throughout this and all | |
209 | related IPsec standards. All other capitalizations of IPsec (e.g., | |
210 | IPSEC, IPSec, ipsec) are deprecated. However, any capitalization of | |
211 | the sequence of letters "IPsec" should be understood to refer to the | |
212 | IPsec protocols. | |
213 | ||
214 | The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, | |
215 | SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this | |
216 | document, are to be interpreted as described in RFC 2119 [Bra97]. | |
217 | ||
218 | 1.2. Audience | |
219 | ||
220 | The target audience for this document is primarily individuals who | |
221 | implement this IP security technology or who architect systems that | |
222 | will use this technology. Technically adept users of this technology | |
223 | ||
224 | ||
225 | ||
226 | Kent & Seo Standards Track [Page 4] | |
227 | \f | |
228 | RFC 4301 Security Architecture for IP December 2005 | |
229 | ||
230 | ||
231 | (end users or system administrators) also are part of the target | |
232 | audience. A glossary is provided in Appendix A to help fill in gaps | |
233 | in background/vocabulary. This document assumes that the reader is | |
234 | familiar with the Internet Protocol (IP), related networking | |
235 | technology, and general information system security terms and | |
236 | concepts. | |
237 | ||
238 | 1.3. Related Documents | |
239 | ||
240 | As mentioned above, other documents provide detailed definitions of | |
241 | some of the components of IPsec and of their interrelationship. They | |
242 | include RFCs on the following topics: | |
243 | ||
244 | a. security protocols -- RFCs describing the Authentication | |
245 | Header (AH) [Ken05b] and Encapsulating Security Payload | |
246 | (ESP) [Ken05a] protocols. | |
247 | b. cryptographic algorithms for integrity and encryption -- one | |
248 | RFC that defines the mandatory, default algorithms for use | |
249 | with AH and ESP [Eas05], a similar RFC that defines the | |
250 | mandatory algorithms for use with IKEv2 [Sch05] plus a | |
251 | separate RFC for each cryptographic algorithm. | |
252 | c. automatic key management -- RFCs on "The Internet Key | |
253 | Exchange (IKEv2) Protocol" [Kau05] and "Cryptographic | |
254 | Algorithms for Use in the Internet Key Exchange Version 2 | |
255 | (IKEv2)" [Sch05]. | |
256 | ||
257 | 2. Design Objectives | |
258 | ||
259 | 2.1. Goals/Objectives/Requirements/Problem Description | |
260 | ||
261 | IPsec is designed to provide interoperable, high quality, | |
262 | cryptographically-based security for IPv4 and IPv6. The set of | |
263 | security services offered includes access control, connectionless | |
264 | integrity, data origin authentication, detection and rejection of | |
265 | replays (a form of partial sequence integrity), confidentiality (via | |
266 | encryption), and limited traffic flow confidentiality. These | |
267 | services are provided at the IP layer, offering protection in a | |
268 | standard fashion for all protocols that may be carried over IP | |
269 | (including IP itself). | |
270 | ||
271 | IPsec includes a specification for minimal firewall functionality, | |
272 | since that is an essential aspect of access control at the IP layer. | |
273 | Implementations are free to provide more sophisticated firewall | |
274 | mechanisms, and to implement the IPsec-mandated functionality using | |
275 | those more sophisticated mechanisms. (Note that interoperability may | |
276 | suffer if additional firewall constraints on traffic flows are | |
277 | imposed by an IPsec implementation but cannot be negotiated based on | |
278 | the traffic selector features defined in this document and negotiated | |
279 | ||
280 | ||
281 | ||
282 | Kent & Seo Standards Track [Page 5] | |
283 | \f | |
284 | RFC 4301 Security Architecture for IP December 2005 | |
285 | ||
286 | ||
287 | via IKEv2.) The IPsec firewall function makes use of the | |
288 | cryptographically-enforced authentication and integrity provided for | |
289 | all IPsec traffic to offer better access control than could be | |
290 | obtained through use of a firewall (one not privy to IPsec internal | |
291 | parameters) plus separate cryptographic protection. | |
292 | ||
293 | Most of the security services are provided through use of two traffic | |
294 | security protocols, the Authentication Header (AH) and the | |
295 | Encapsulating Security Payload (ESP), and through the use of | |
296 | cryptographic key management procedures and protocols. The set of | |
297 | IPsec protocols employed in a context, and the ways in which they are | |
298 | employed, will be determined by the users/administrators in that | |
299 | context. It is the goal of the IPsec architecture to ensure that | |
300 | compliant implementations include the services and management | |
301 | interfaces needed to meet the security requirements of a broad user | |
302 | population. | |
303 | ||
304 | When IPsec is correctly implemented and deployed, it ought not | |
305 | adversely affect users, hosts, and other Internet components that do | |
306 | not employ IPsec for traffic protection. IPsec security protocols | |
307 | (AH and ESP, and to a lesser extent, IKE) are designed to be | |
308 | cryptographic algorithm independent. This modularity permits | |
309 | selection of different sets of cryptographic algorithms as | |
310 | appropriate, without affecting the other parts of the implementation. | |
311 | For example, different user communities may select different sets of | |
312 | cryptographic algorithms (creating cryptographically-enforced | |
313 | cliques) if required. | |
314 | ||
315 | To facilitate interoperability in the global Internet, a set of | |
316 | default cryptographic algorithms for use with AH and ESP is specified | |
317 | in [Eas05] and a set of mandatory-to-implement algorithms for IKEv2 | |
318 | is specified in [Sch05]. [Eas05] and [Sch05] will be periodically | |
319 | updated to keep pace with computational and cryptologic advances. By | |
320 | specifying these algorithms in documents that are separate from the | |
321 | AH, ESP, and IKEv2 specifications, these algorithms can be updated or | |
322 | replaced without affecting the standardization progress of the rest | |
323 | of the IPsec document suite. The use of these cryptographic | |
324 | algorithms, in conjunction with IPsec traffic protection and key | |
325 | management protocols, is intended to permit system and application | |
326 | developers to deploy high quality, Internet-layer, cryptographic | |
327 | security technology. | |
328 | ||
329 | 2.2. Caveats and Assumptions | |
330 | ||
331 | The suite of IPsec protocols and associated default cryptographic | |
332 | algorithms are designed to provide high quality security for Internet | |
333 | traffic. However, the security offered by use of these protocols | |
334 | ultimately depends on the quality of their implementation, which is | |
335 | ||
336 | ||
337 | ||
338 | Kent & Seo Standards Track [Page 6] | |
339 | \f | |
340 | RFC 4301 Security Architecture for IP December 2005 | |
341 | ||
342 | ||
343 | outside the scope of this set of standards. Moreover, the security | |
344 | of a computer system or network is a function of many factors, | |
345 | including personnel, physical, procedural, compromising emanations, | |
346 | and computer security practices. Thus, IPsec is only one part of an | |
347 | overall system security architecture. | |
348 | ||
349 | Finally, the security afforded by the use of IPsec is critically | |
350 | dependent on many aspects of the operating environment in which the | |
351 | IPsec implementation executes. For example, defects in OS security, | |
352 | poor quality of random number sources, sloppy system management | |
353 | protocols and practices, etc., can all degrade the security provided | |
354 | by IPsec. As above, none of these environmental attributes are | |
355 | within the scope of this or other IPsec standards. | |
356 | ||
357 | 3. System Overview | |
358 | ||
359 | This section provides a high level description of how IPsec works, | |
360 | the components of the system, and how they fit together to provide | |
361 | the security services noted above. The goal of this description is | |
362 | to enable the reader to "picture" the overall process/system, see how | |
363 | it fits into the IP environment, and to provide context for later | |
364 | sections of this document, which describe each of the components in | |
365 | more detail. | |
366 | ||
367 | An IPsec implementation operates in a host, as a security gateway | |
368 | (SG), or as an independent device, affording protection to IP | |
369 | traffic. (A security gateway is an intermediate system implementing | |
370 | IPsec, e.g., a firewall or router that has been IPsec-enabled.) More | |
371 | detail on these classes of implementations is provided later, in | |
372 | Section 3.3. The protection offered by IPsec is based on requirements | |
373 | defined by a Security Policy Database (SPD) established and | |
374 | maintained by a user or system administrator, or by an application | |
375 | operating within constraints established by either of the above. In | |
376 | general, packets are selected for one of three processing actions | |
377 | based on IP and next layer header information ("Selectors", Section | |
378 | 4.4.1.1) matched against entries in the SPD. Each packet is either | |
379 | PROTECTed using IPsec security services, DISCARDed, or allowed to | |
380 | BYPASS IPsec protection, based on the applicable SPD policies | |
381 | identified by the Selectors. | |
382 | ||
383 | 3.1. What IPsec Does | |
384 | ||
385 | IPsec creates a boundary between unprotected and protected | |
386 | interfaces, for a host or a network (see Figure 1 below). Traffic | |
387 | traversing the boundary is subject to the access controls specified | |
388 | by the user or administrator responsible for the IPsec configuration. | |
389 | These controls indicate whether packets cross the boundary unimpeded, | |
390 | are afforded security services via AH or ESP, or are discarded. | |
391 | ||
392 | ||
393 | ||
394 | Kent & Seo Standards Track [Page 7] | |
395 | \f | |
396 | RFC 4301 Security Architecture for IP December 2005 | |
397 | ||
398 | ||
399 | IPsec security services are offered at the IP layer through selection | |
400 | of appropriate security protocols, cryptographic algorithms, and | |
401 | cryptographic keys. IPsec can be used to protect one or more "paths" | |
402 | (a) between a pair of hosts, (b) between a pair of security gateways, | |
403 | or (c) between a security gateway and a host. A compliant host | |
404 | implementation MUST support (a) and (c) and a compliant security | |
405 | gateway must support all three of these forms of connectivity, since | |
406 | under certain circumstances a security gateway acts as a host. | |
407 | ||
408 | Unprotected | |
409 | ^ ^ | |
410 | | | | |
411 | +-------------|-------|-------+ | |
412 | | +-------+ | | | | |
413 | | |Discard|<--| V | | |
414 | | +-------+ |B +--------+ | | |
415 | ................|y..| AH/ESP |..... IPsec Boundary | |
416 | | +---+ |p +--------+ | | |
417 | | |IKE|<----|a ^ | | |
418 | | +---+ |s | | | |
419 | | +-------+ |s | | | |
420 | | |Discard|<--| | | | |
421 | | +-------+ | | | | |
422 | +-------------|-------|-------+ | |
423 | | | | |
424 | V V | |
425 | Protected | |
426 | ||
427 | Figure 1. Top Level IPsec Processing Model | |
428 | ||
429 | In this diagram, "unprotected" refers to an interface that might also | |
430 | be described as "black" or "ciphertext". Here, "protected" refers to | |
431 | an interface that might also be described as "red" or "plaintext". | |
432 | The protected interface noted above may be internal, e.g., in a host | |
433 | implementation of IPsec, the protected interface may link to a socket | |
434 | layer interface presented by the OS. In this document, the term | |
435 | "inbound" refers to traffic entering an IPsec implementation via the | |
436 | unprotected interface or emitted by the implementation on the | |
437 | unprotected side of the boundary and directed towards the protected | |
438 | interface. The term "outbound" refers to traffic entering the | |
439 | implementation via the protected interface, or emitted by the | |
440 | implementation on the protected side of the boundary and directed | |
441 | toward the unprotected interface. An IPsec implementation may | |
442 | support more than one interface on either or both sides of the | |
443 | boundary. | |
444 | ||
445 | ||
446 | ||
447 | ||
448 | ||
449 | ||
450 | Kent & Seo Standards Track [Page 8] | |
451 | \f | |
452 | RFC 4301 Security Architecture for IP December 2005 | |
453 | ||
454 | ||
455 | Note the facilities for discarding traffic on either side of the | |
456 | IPsec boundary, the BYPASS facility that allows traffic to transit | |
457 | the boundary without cryptographic protection, and the reference to | |
458 | IKE as a protected-side key and security management function. | |
459 | ||
460 | IPsec optionally supports negotiation of IP compression [SMPT01], | |
461 | motivated in part by the observation that when encryption is employed | |
462 | within IPsec, it prevents effective compression by lower protocol | |
463 | layers. | |
464 | ||
465 | 3.2. How IPsec Works | |
466 | ||
467 | IPsec uses two protocols to provide traffic security services -- | |
468 | Authentication Header (AH) and Encapsulating Security Payload (ESP). | |
469 | Both protocols are described in detail in their respective RFCs | |
470 | [Ken05b, Ken05a]. IPsec implementations MUST support ESP and MAY | |
471 | support AH. (Support for AH has been downgraded to MAY because | |
472 | experience has shown that there are very few contexts in which ESP | |
473 | cannot provide the requisite security services. Note that ESP can be | |
474 | used to provide only integrity, without confidentiality, making it | |
475 | comparable to AH in most contexts.) | |
476 | ||
477 | o The IP Authentication Header (AH) [Ken05b] offers integrity and | |
478 | data origin authentication, with optional (at the discretion of | |
479 | the receiver) anti-replay features. | |
480 | ||
481 | o The Encapsulating Security Payload (ESP) protocol [Ken05a] offers | |
482 | the same set of services, and also offers confidentiality. Use of | |
483 | ESP to provide confidentiality without integrity is NOT | |
484 | RECOMMENDED. When ESP is used with confidentiality enabled, there | |
485 | are provisions for limited traffic flow confidentiality, i.e., | |
486 | provisions for concealing packet length, and for facilitating | |
487 | efficient generation and discard of dummy packets. This | |
488 | capability is likely to be effective primarily in virtual private | |
489 | network (VPN) and overlay network contexts. | |
490 | ||
491 | o Both AH and ESP offer access control, enforced through the | |
492 | distribution of cryptographic keys and the management of traffic | |
493 | flows as dictated by the Security Policy Database (SPD, Section | |
494 | 4.4.1). | |
495 | ||
496 | These protocols may be applied individually or in combination with | |
497 | each other to provide IPv4 and IPv6 security services. However, most | |
498 | security requirements can be met through the use of ESP by itself. | |
499 | Each protocol supports two modes of use: transport mode and tunnel | |
500 | mode. In transport mode, AH and ESP provide protection primarily for | |
501 | ||
502 | ||
503 | ||
504 | ||
505 | ||
506 | Kent & Seo Standards Track [Page 9] | |
507 | \f | |
508 | RFC 4301 Security Architecture for IP December 2005 | |
509 | ||
510 | ||
511 | next layer protocols; in tunnel mode, AH and ESP are applied to | |
512 | tunneled IP packets. The differences between the two modes are | |
513 | discussed in Section 4.1. | |
514 | ||
515 | IPsec allows the user (or system administrator) to control the | |
516 | granularity at which a security service is offered. For example, one | |
517 | can create a single encrypted tunnel to carry all the traffic between | |
518 | two security gateways, or a separate encrypted tunnel can be created | |
519 | for each TCP connection between each pair of hosts communicating | |
520 | across these gateways. IPsec, through the SPD management paradigm, | |
521 | incorporates facilities for specifying: | |
522 | ||
523 | o which security protocol (AH or ESP) to employ, the mode (transport | |
524 | or tunnel), security service options, what cryptographic | |
525 | algorithms to use, and in what combinations to use the specified | |
526 | protocols and services, and | |
527 | ||
528 | o the granularity at which protection should be applied. | |
529 | ||
530 | Because most of the security services provided by IPsec require the | |
531 | use of cryptographic keys, IPsec relies on a separate set of | |
532 | mechanisms for putting these keys in place. This document requires | |
533 | support for both manual and automated distribution of keys. It | |
534 | specifies a specific public-key based approach (IKEv2 [Kau05]) for | |
535 | automated key management, but other automated key distribution | |
536 | techniques MAY be used. | |
537 | ||
538 | Note: This document mandates support for several features for which | |
539 | support is available in IKEv2 but not in IKEv1, e.g., negotiation of | |
540 | an SA representing ranges of local and remote ports or negotiation of | |
541 | multiple SAs with the same selectors. Therefore, this document | |
542 | assumes use of IKEv2 or a key and security association management | |
543 | system with comparable features. | |
544 | ||
545 | 3.3. Where IPsec Can Be Implemented | |
546 | ||
547 | There are many ways in which IPsec may be implemented in a host, or | |
548 | in conjunction with a router or firewall to create a security | |
549 | gateway, or as an independent security device. | |
550 | ||
551 | a. IPsec may be integrated into the native IP stack. This requires | |
552 | access to the IP source code and is applicable to both hosts and | |
553 | security gateways, although native host implementations benefit | |
554 | the most from this strategy, as explained later (Section 4.4.1, | |
555 | paragraph 6; Section 4.4.1.1, last paragraph). | |
556 | ||
557 | ||
558 | ||
559 | ||
560 | ||
561 | ||
562 | Kent & Seo Standards Track [Page 10] | |
563 | \f | |
564 | RFC 4301 Security Architecture for IP December 2005 | |
565 | ||
566 | ||
567 | b. In a "bump-in-the-stack" (BITS) implementation, IPsec is | |
568 | implemented "underneath" an existing implementation of an IP | |
569 | protocol stack, between the native IP and the local network | |
570 | drivers. Source code access for the IP stack is not required in | |
571 | this context, making this implementation approach appropriate for | |
572 | use with legacy systems. This approach, when it is adopted, is | |
573 | usually employed in hosts. | |
574 | ||
575 | c. The use of a dedicated, inline security protocol processor is a | |
576 | common design feature of systems used by the military, and of some | |
577 | commercial systems as well. It is sometimes referred to as a | |
578 | "bump-in-the-wire" (BITW) implementation. Such implementations | |
579 | may be designed to serve either a host or a gateway. Usually, the | |
580 | BITW device is itself IP addressable. When supporting a single | |
581 | host, it may be quite analogous to a BITS implementation, but in | |
582 | supporting a router or firewall, it must operate like a security | |
583 | gateway. | |
584 | ||
585 | This document often talks in terms of use of IPsec by a host or a | |
586 | security gateway, without regard to whether the implementation is | |
587 | native, BITS, or BITW. When the distinctions among these | |
588 | implementation options are significant, the document makes reference | |
589 | to specific implementation approaches. | |
590 | ||
591 | A host implementation of IPsec may appear in devices that might not | |
592 | be viewed as "hosts". For example, a router might employ IPsec to | |
593 | protect routing protocols (e.g., BGP) and management functions (e.g., | |
594 | Telnet), without affecting subscriber traffic traversing the router. | |
595 | A security gateway might employ separate IPsec implementations to | |
596 | protect its management traffic and subscriber traffic. The | |
597 | architecture described in this document is very flexible. For | |
598 | example, a computer with a full-featured, compliant, native OS IPsec | |
599 | implementation should be capable of being configured to protect | |
600 | resident (host) applications and to provide security gateway | |
601 | protection for traffic traversing the computer. Such configuration | |
602 | would make use of the forwarding tables and the SPD selection | |
603 | function described in Sections 5.1 and 5.2. | |
604 | ||
605 | 4. Security Associations | |
606 | ||
607 | This section defines Security Association management requirements for | |
608 | all IPv6 implementations and for those IPv4 implementations that | |
609 | implement AH, ESP, or both AH and ESP. The concept of a "Security | |
610 | Association" (SA) is fundamental to IPsec. Both AH and ESP make use | |
611 | of SAs, and a major function of IKE is the establishment and | |
612 | maintenance of SAs. All implementations of AH or ESP MUST support | |
613 | the concept of an SA as described below. The remainder of this | |
614 | ||
615 | ||
616 | ||
617 | ||
618 | Kent & Seo Standards Track [Page 11] | |
619 | \f | |
620 | RFC 4301 Security Architecture for IP December 2005 | |
621 | ||
622 | ||
623 | section describes various aspects of SA management, defining required | |
624 | characteristics for SA policy management and SA management | |
625 | techniques. | |
626 | ||
627 | 4.1. Definition and Scope | |
628 | ||
629 | An SA is a simplex "connection" that affords security services to the | |
630 | traffic carried by it. Security services are afforded to an SA by | |
631 | the use of AH, or ESP, but not both. If both AH and ESP protection | |
632 | are applied to a traffic stream, then two SAs must be created and | |
633 | coordinated to effect protection through iterated application of the | |
634 | security protocols. To secure typical, bi-directional communication | |
635 | between two IPsec-enabled systems, a pair of SAs (one in each | |
636 | direction) is required. IKE explicitly creates SA pairs in | |
637 | recognition of this common usage requirement. | |
638 | ||
639 | For an SA used to carry unicast traffic, the Security Parameters | |
640 | Index (SPI) by itself suffices to specify an SA. (For information on | |
641 | the SPI, see Appendix A and the AH and ESP specifications [Ken05b, | |
642 | Ken05a].) However, as a local matter, an implementation may choose | |
643 | to use the SPI in conjunction with the IPsec protocol type (AH or | |
644 | ESP) for SA identification. If an IPsec implementation supports | |
645 | multicast, then it MUST support multicast SAs using the algorithm | |
646 | below for mapping inbound IPsec datagrams to SAs. Implementations | |
647 | that support only unicast traffic need not implement this de- | |
648 | multiplexing algorithm. | |
649 | ||
650 | In many secure multicast architectures, e.g., [RFC3740], a central | |
651 | Group Controller/Key Server unilaterally assigns the Group Security | |
652 | Association's (GSA's) SPI. This SPI assignment is not negotiated or | |
653 | coordinated with the key management (e.g., IKE) subsystems that | |
654 | reside in the individual end systems that constitute the group. | |
655 | Consequently, it is possible that a GSA and a unicast SA can | |
656 | simultaneously use the same SPI. A multicast-capable IPsec | |
657 | implementation MUST correctly de-multiplex inbound traffic even in | |
658 | the context of SPI collisions. | |
659 | ||
660 | Each entry in the SA Database (SAD) (Section 4.4.2) must indicate | |
661 | whether the SA lookup makes use of the destination IP address, or the | |
662 | destination and source IP addresses, in addition to the SPI. For | |
663 | multicast SAs, the protocol field is not employed for SA lookups. | |
664 | For each inbound, IPsec-protected packet, an implementation must | |
665 | conduct its search of the SAD such that it finds the entry that | |
666 | matches the "longest" SA identifier. In this context, if two or more | |
667 | SAD entries match based on the SPI value, then the entry that also | |
668 | matches based on destination address, or destination and source | |
669 | address (as indicated in the SAD entry) is the "longest" match. This | |
670 | implies a logical ordering of the SAD search as follows: | |
671 | ||
672 | ||
673 | ||
674 | Kent & Seo Standards Track [Page 12] | |
675 | \f | |
676 | RFC 4301 Security Architecture for IP December 2005 | |
677 | ||
678 | ||
679 | 1. Search the SAD for a match on the combination of SPI, | |
680 | destination address, and source address. If an SAD entry | |
681 | matches, then process the inbound packet with that | |
682 | matching SAD entry. Otherwise, proceed to step 2. | |
683 | ||
684 | 2. Search the SAD for a match on both SPI and destination address. | |
685 | If the SAD entry matches, then process the inbound packet | |
686 | with that matching SAD entry. Otherwise, proceed to step 3. | |
687 | ||
688 | 3. Search the SAD for a match on only SPI if the receiver has | |
689 | chosen to maintain a single SPI space for AH and ESP, and on | |
690 | both SPI and protocol, otherwise. If an SAD entry matches, | |
691 | then process the inbound packet with that matching SAD entry. | |
692 | Otherwise, discard the packet and log an auditable event. | |
693 | ||
694 | In practice, an implementation may choose any method (or none at all) | |
695 | to accelerate this search, although its externally visible behavior | |
696 | MUST be functionally equivalent to having searched the SAD in the | |
697 | above order. For example, a software-based implementation could | |
698 | index into a hash table by the SPI. The SAD entries in each hash | |
699 | table bucket's linked list could be kept sorted to have those SAD | |
700 | entries with the longest SA identifiers first in that linked list. | |
701 | Those SAD entries having the shortest SA identifiers could be sorted | |
702 | so that they are the last entries in the linked list. A | |
703 | hardware-based implementation may be able to effect the longest match | |
704 | search intrinsically, using commonly available Ternary | |
705 | Content-Addressable Memory (TCAM) features. | |
706 | ||
707 | The indication of whether source and destination address matching is | |
708 | required to map inbound IPsec traffic to SAs MUST be set either as a | |
709 | side effect of manual SA configuration or via negotiation using an SA | |
710 | management protocol, e.g., IKE or Group Domain of Interpretation | |
711 | (GDOI) [RFC3547]. Typically, Source-Specific Multicast (SSM) [HC03] | |
712 | groups use a 3-tuple SA identifier composed of an SPI, a destination | |
713 | multicast address, and source address. An Any-Source Multicast group | |
714 | SA requires only an SPI and a destination multicast address as an | |
715 | identifier. | |
716 | ||
717 | If different classes of traffic (distinguished by Differentiated | |
718 | Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on | |
719 | the same SA, and if the receiver is employing the optional | |
720 | anti-replay feature available in both AH and ESP, this could result | |
721 | in inappropriate discarding of lower priority packets due to the | |
722 | windowing mechanism used by this feature. Therefore, a sender SHOULD | |
723 | put traffic of different classes, but with the same selector values, | |
724 | on different SAs to support Quality of Service (QoS) appropriately. | |
725 | To permit this, the IPsec implementation MUST permit establishment | |
726 | and maintenance of multiple SAs between a given sender and receiver, | |
727 | ||
728 | ||
729 | ||
730 | Kent & Seo Standards Track [Page 13] | |
731 | \f | |
732 | RFC 4301 Security Architecture for IP December 2005 | |
733 | ||
734 | ||
735 | with the same selectors. Distribution of traffic among these | |
736 | parallel SAs to support QoS is locally determined by the sender and | |
737 | is not negotiated by IKE. The receiver MUST process the packets from | |
738 | the different SAs without prejudice. These requirements apply to | |
739 | both transport and tunnel mode SAs. In the case of tunnel mode SAs, | |
740 | the DSCP values in question appear in the inner IP header. In | |
741 | transport mode, the DSCP value might change en route, but this should | |
742 | not cause problems with respect to IPsec processing since the value | |
743 | is not employed for SA selection and MUST NOT be checked as part of | |
744 | SA/packet validation. However, if significant re-ordering of packets | |
745 | occurs in an SA, e.g., as a result of changes to DSCP values en | |
746 | route, this may trigger packet discarding by a receiver due to | |
747 | application of the anti-replay mechanism. | |
748 | ||
749 | DISCUSSION: Although the DSCP [NiBlBaBL98, Gro02] and Explicit | |
750 | Congestion Notification (ECN) [RaFlBl01] fields are not "selectors", | |
751 | as that term in used in this architecture, the sender will need a | |
752 | mechanism to direct packets with a given (set of) DSCP values to the | |
753 | appropriate SA. This mechanism might be termed a "classifier". | |
754 | ||
755 | As noted above, two types of SAs are defined: transport mode and | |
756 | tunnel mode. IKE creates pairs of SAs, so for simplicity, we choose | |
757 | to require that both SAs in a pair be of the same mode, transport or | |
758 | tunnel. | |
759 | ||
760 | A transport mode SA is an SA typically employed between a pair of | |
761 | hosts to provide end-to-end security services. When security is | |
762 | desired between two intermediate systems along a path (vs. end-to-end | |
763 | use of IPsec), transport mode MAY be used between security gateways | |
764 | or between a security gateway and a host. In the case where | |
765 | transport mode is used between security gateways or between a | |
766 | security gateway and a host, transport mode may be used to support | |
767 | in-IP tunneling (e.g., IP-in-IP [Per96] or Generic Routing | |
768 | Encapsulation (GRE) tunneling [FaLiHaMeTr00] or dynamic routing | |
769 | [ToEgWa04]) over transport mode SAs. To clarify, the use of | |
770 | transport mode by an intermediate system (e.g., a security gateway) | |
771 | is permitted only when applied to packets whose source address (for | |
772 | outbound packets) or destination address (for inbound packets) is an | |
773 | address belonging to the intermediate system itself. The access | |
774 | control functions that are an important part of IPsec are | |
775 | significantly limited in this context, as they cannot be applied to | |
776 | the end-to-end headers of the packets that traverse a transport mode | |
777 | SA used in this fashion. Thus, this way of using transport mode | |
778 | should be evaluated carefully before being employed in a specific | |
779 | context. | |
780 | ||
781 | ||
782 | ||
783 | ||
784 | ||
785 | ||
786 | Kent & Seo Standards Track [Page 14] | |
787 | \f | |
788 | RFC 4301 Security Architecture for IP December 2005 | |
789 | ||
790 | ||
791 | In IPv4, a transport mode security protocol header appears | |
792 | immediately after the IP header and any options, and before any next | |
793 | layer protocols (e.g., TCP or UDP). In IPv6, the security protocol | |
794 | header appears after the base IP header and selected extension | |
795 | headers, but may appear before or after destination options; it MUST | |
796 | appear before next layer protocols (e.g., TCP, UDP, Stream Control | |
797 | Transmission Protocol (SCTP)). In the case of ESP, a transport mode | |
798 | SA provides security services only for these next layer protocols, | |
799 | not for the IP header or any extension headers preceding the ESP | |
800 | header. In the case of AH, the protection is also extended to | |
801 | selected portions of the IP header preceding it, selected portions of | |
802 | extension headers, and selected options (contained in the IPv4 | |
803 | header, IPv6 Hop-by-Hop extension header, or IPv6 Destination | |
804 | extension headers). For more details on the coverage afforded by AH, | |
805 | see the AH specification [Ken05b]. | |
806 | ||
807 | A tunnel mode SA is essentially an SA applied to an IP tunnel, with | |
808 | the access controls applied to the headers of the traffic inside the | |
809 | tunnel. Two hosts MAY establish a tunnel mode SA between themselves. | |
810 | Aside from the two exceptions below, whenever either end of a | |
811 | security association is a security gateway, the SA MUST be tunnel | |
812 | mode. Thus, an SA between two security gateways is typically a | |
813 | tunnel mode SA, as is an SA between a host and a security gateway. | |
814 | The two exceptions are as follows. | |
815 | ||
816 | o Where traffic is destined for a security gateway, e.g., Simple | |
817 | Network Management Protocol (SNMP) commands, the security gateway | |
818 | is acting as a host and transport mode is allowed. In this case, | |
819 | the SA terminates at a host (management) function within a | |
820 | security gateway and thus merits different treatment. | |
821 | ||
822 | o As noted above, security gateways MAY support a transport mode SA | |
823 | to provide security for IP traffic between two intermediate | |
824 | systems along a path, e.g., between a host and a security gateway | |
825 | or between two security gateways. | |
826 | ||
827 | Several concerns motivate the use of tunnel mode for an SA involving | |
828 | a security gateway. For example, if there are multiple paths (e.g., | |
829 | via different security gateways) to the same destination behind a | |
830 | security gateway, it is important that an IPsec packet be sent to the | |
831 | security gateway with which the SA was negotiated. Similarly, a | |
832 | packet that might be fragmented en route must have all the fragments | |
833 | delivered to the same IPsec instance for reassembly prior to | |
834 | cryptographic processing. Also, when a fragment is processed by | |
835 | IPsec and transmitted, then fragmented en route, it is critical that | |
836 | there be inner and outer headers to retain the fragmentation state | |
837 | data for the pre- and post-IPsec packet formats. Hence there are | |
838 | several reasons for employing tunnel mode when either end of an SA is | |
839 | ||
840 | ||
841 | ||
842 | Kent & Seo Standards Track [Page 15] | |
843 | \f | |
844 | RFC 4301 Security Architecture for IP December 2005 | |
845 | ||
846 | ||
847 | a security gateway. (Use of an IP-in-IP tunnel in conjunction with | |
848 | transport mode can also address these fragmentation issues. However, | |
849 | this configuration limits the ability of IPsec to enforce access | |
850 | control policies on traffic.) | |
851 | ||
852 | Note: AH and ESP cannot be applied using transport mode to IPv4 | |
853 | packets that are fragments. Only tunnel mode can be employed in such | |
854 | cases. For IPv6, it would be feasible to carry a plaintext fragment | |
855 | on a transport mode SA; however, for simplicity, this restriction | |
856 | also applies to IPv6 packets. See Section 7 for more details on | |
857 | handling plaintext fragments on the protected side of the IPsec | |
858 | barrier. | |
859 | ||
860 | For a tunnel mode SA, there is an "outer" IP header that specifies | |
861 | the IPsec processing source and destination, plus an "inner" IP | |
862 | header that specifies the (apparently) ultimate source and | |
863 | destination for the packet. The security protocol header appears | |
864 | after the outer IP header, and before the inner IP header. If AH is | |
865 | employed in tunnel mode, portions of the outer IP header are afforded | |
866 | protection (as above), as well as all of the tunneled IP packet | |
867 | (i.e., all of the inner IP header is protected, as well as next layer | |
868 | protocols). If ESP is employed, the protection is afforded only to | |
869 | the tunneled packet, not to the outer header. | |
870 | ||
871 | In summary, | |
872 | ||
873 | a) A host implementation of IPsec MUST support both transport and | |
874 | tunnel mode. This is true for native, BITS, and BITW | |
875 | implementations for hosts. | |
876 | ||
877 | b) A security gateway MUST support tunnel mode and MAY support | |
878 | transport mode. If it supports transport mode, that should be | |
879 | used only when the security gateway is acting as a host, e.g., for | |
880 | network management, or to provide security between two | |
881 | intermediate systems along a path. | |
882 | ||
883 | 4.2. SA Functionality | |
884 | ||
885 | The set of security services offered by an SA depends on the security | |
886 | protocol selected, the SA mode, the endpoints of the SA, and the | |
887 | election of optional services within the protocol. | |
888 | ||
889 | For example, both AH and ESP offer integrity and authentication | |
890 | services, but the coverage differs for each protocol and differs for | |
891 | transport vs. tunnel mode. If the integrity of an IPv4 option or | |
892 | IPv6 extension header must be protected en route between sender and | |
893 | receiver, AH can provide this service, except for IP or extension | |
894 | headers that may change in a fashion not predictable by the sender. | |
895 | ||
896 | ||
897 | ||
898 | Kent & Seo Standards Track [Page 16] | |
899 | \f | |
900 | RFC 4301 Security Architecture for IP December 2005 | |
901 | ||
902 | ||
903 | However, the same security may be achieved in some contexts by | |
904 | applying ESP to a tunnel carrying a packet. | |
905 | ||
906 | The granularity of access control provided is determined by the | |
907 | choice of the selectors that define each SA. Moreover, the | |
908 | authentication means employed by IPsec peers, e.g., during creation | |
909 | of an IKE (vs. child) SA also affects the granularity of the access | |
910 | control afforded. | |
911 | ||
912 | If confidentiality is selected, then an ESP (tunnel mode) SA between | |
913 | two security gateways can offer partial traffic flow confidentiality. | |
914 | The use of tunnel mode allows the inner IP headers to be encrypted, | |
915 | concealing the identities of the (ultimate) traffic source and | |
916 | destination. Moreover, ESP payload padding also can be invoked to | |
917 | hide the size of the packets, further concealing the external | |
918 | characteristics of the traffic. Similar traffic flow confidentiality | |
919 | services may be offered when a mobile user is assigned a dynamic IP | |
920 | address in a dialup context, and establishes a (tunnel mode) ESP SA | |
921 | to a corporate firewall (acting as a security gateway). Note that | |
922 | fine-granularity SAs generally are more vulnerable to traffic | |
923 | analysis than coarse-granularity ones that are carrying traffic from | |
924 | many subscribers. | |
925 | ||
926 | Note: A compliant implementation MUST NOT allow instantiation of an | |
927 | ESP SA that employs both NULL encryption and no integrity algorithm. | |
928 | An attempt to negotiate such an SA is an auditable event by both | |
929 | initiator and responder. The audit log entry for this event SHOULD | |
930 | include the current date/time, local IKE IP address, and remote IKE | |
931 | IP address. The initiator SHOULD record the relevant SPD entry. | |
932 | ||
933 | 4.3. Combining SAs | |
934 | ||
935 | This document does not require support for nested security | |
936 | associations or for what RFC 2401 [RFC2401] called "SA bundles". | |
937 | These features still can be effected by appropriate configuration of | |
938 | both the SPD and the local forwarding functions (for inbound and | |
939 | outbound traffic), but this capability is outside of the IPsec module | |
940 | and thus the scope of this specification. As a result, management of | |
941 | nested/bundled SAs is potentially more complex and less assured than | |
942 | under the model implied by RFC 2401 [RFC2401]. An implementation | |
943 | that provides support for nested SAs SHOULD provide a management | |
944 | interface that enables a user or administrator to express the nesting | |
945 | requirement, and then create the appropriate SPD entries and | |
946 | forwarding table entries to effect the requisite processing. (See | |
947 | Appendix E for an example of how to configure nested SAs.) | |
948 | ||
949 | ||
950 | ||
951 | ||
952 | ||
953 | ||
954 | Kent & Seo Standards Track [Page 17] | |
955 | \f | |
956 | RFC 4301 Security Architecture for IP December 2005 | |
957 | ||
958 | ||
959 | 4.4. Major IPsec Databases | |
960 | ||
961 | Many of the details associated with processing IP traffic in an IPsec | |
962 | implementation are largely a local matter, not subject to | |
963 | standardization. However, some external aspects of the processing | |
964 | must be standardized to ensure interoperability and to provide a | |
965 | minimum management capability that is essential for productive use of | |
966 | IPsec. This section describes a general model for processing IP | |
967 | traffic relative to IPsec functionality, in support of these | |
968 | interoperability and functionality goals. The model described below | |
969 | is nominal; implementations need not match details of this model as | |
970 | presented, but the external behavior of implementations MUST | |
971 | correspond to the externally observable characteristics of this model | |
972 | in order to be compliant. | |
973 | ||
974 | There are three nominal databases in this model: the Security Policy | |
975 | Database (SPD), the Security Association Database (SAD), and the Peer | |
976 | Authorization Database (PAD). The first specifies the policies that | |
977 | determine the disposition of all IP traffic inbound or outbound from | |
978 | a host or security gateway (Section 4.4.1). The second database | |
979 | contains parameters that are associated with each established (keyed) | |
980 | SA (Section 4.4.2). The third database, the PAD, provides a link | |
981 | between an SA management protocol (such as IKE) and the SPD (Section | |
982 | 4.4.3). | |
983 | ||
984 | Multiple Separate IPsec Contexts | |
985 | ||
986 | If an IPsec implementation acts as a security gateway for multiple | |
987 | subscribers, it MAY implement multiple separate IPsec contexts. | |
988 | Each context MAY have and MAY use completely independent | |
989 | identities, policies, key management SAs, and/or IPsec SAs. This | |
990 | is for the most part a local implementation matter. However, a | |
991 | means for associating inbound (SA) proposals with local contexts | |
992 | is required. To this end, if supported by the key management | |
993 | protocol in use, context identifiers MAY be conveyed from | |
994 | initiator to responder in the signaling messages, with the result | |
995 | that IPsec SAs are created with a binding to a particular context. | |
996 | For example, a security gateway that provides VPN service to | |
997 | multiple customers will be able to associate each customer's | |
998 | traffic with the correct VPN. | |
999 | ||
1000 | Forwarding vs Security Decisions | |
1001 | ||
1002 | The IPsec model described here embodies a clear separation between | |
1003 | forwarding (routing) and security decisions, to accommodate a wide | |
1004 | range of contexts where IPsec may be employed. Forwarding may be | |
1005 | trivial, in the case where there are only two interfaces, or it | |
1006 | may be complex, e.g., if the context in which IPsec is implemented | |
1007 | ||
1008 | ||
1009 | ||
1010 | Kent & Seo Standards Track [Page 18] | |
1011 | \f | |
1012 | RFC 4301 Security Architecture for IP December 2005 | |
1013 | ||
1014 | ||
1015 | employs a sophisticated forwarding function. IPsec assumes only | |
1016 | that outbound and inbound traffic that has passed through IPsec | |
1017 | processing is forwarded in a fashion consistent with the context | |
1018 | in which IPsec is implemented. Support for nested SAs is | |
1019 | optional; if required, it requires coordination between forwarding | |
1020 | tables and SPD entries to cause a packet to traverse the IPsec | |
1021 | boundary more than once. | |
1022 | ||
1023 | "Local" vs "Remote" | |
1024 | ||
1025 | In this document, with respect to IP addresses and ports, the | |
1026 | terms "Local" and "Remote" are used for policy rules. "Local" | |
1027 | refers to the entity being protected by an IPsec implementation, | |
1028 | i.e., the "source" address/port of outbound packets or the | |
1029 | "destination" address/port of inbound packets. "Remote" refers to | |
1030 | a peer entity or peer entities. The terms "source" and | |
1031 | "destination" are used for packet header fields. | |
1032 | ||
1033 | "Non-initial" vs "Initial" Fragments | |
1034 | ||
1035 | Throughout this document, the phrase "non-initial fragments" is | |
1036 | used to mean fragments that do not contain all of the selector | |
1037 | values that may be needed for access control (e.g., they might not | |
1038 | contain Next Layer Protocol, source and destination ports, ICMP | |
1039 | message type/code, Mobility Header type). And the phrase "initial | |
1040 | fragment" is used to mean a fragment that contains all the | |
1041 | selector values needed for access control. However, it should be | |
1042 | noted that for IPv6, which fragment contains the Next Layer | |
1043 | Protocol and ports (or ICMP message type/code or Mobility Header | |
1044 | type [Mobip]) will depend on the kind and number of extension | |
1045 | headers present. The "initial fragment" might not be the first | |
1046 | fragment, in this context. | |
1047 | ||
1048 | 4.4.1. The Security Policy Database (SPD) | |
1049 | ||
1050 | An SA is a management construct used to enforce security policy for | |
1051 | traffic crossing the IPsec boundary. Thus, an essential element of | |
1052 | SA processing is an underlying Security Policy Database (SPD) that | |
1053 | specifies what services are to be offered to IP datagrams and in what | |
1054 | fashion. The form of the database and its interface are outside the | |
1055 | scope of this specification. However, this section specifies minimum | |
1056 | management functionality that must be provided, to allow a user or | |
1057 | system administrator to control whether and how IPsec is applied to | |
1058 | traffic transmitted or received by a host or transiting a security | |
1059 | gateway. The SPD, or relevant caches, must be consulted during the | |
1060 | processing of all traffic (inbound and outbound), including traffic | |
1061 | not protected by IPsec, that traverses the IPsec boundary. This | |
1062 | includes IPsec management traffic such as IKE. An IPsec | |
1063 | ||
1064 | ||
1065 | ||
1066 | Kent & Seo Standards Track [Page 19] | |
1067 | \f | |
1068 | RFC 4301 Security Architecture for IP December 2005 | |
1069 | ||
1070 | ||
1071 | implementation MUST have at least one SPD, and it MAY support | |
1072 | multiple SPDs, if appropriate for the context in which the IPsec | |
1073 | implementation operates. There is no requirement to maintain SPDs on | |
1074 | a per-interface basis, as was specified in RFC 2401 [RFC2401]. | |
1075 | However, if an implementation supports multiple SPDs, then it MUST | |
1076 | include an explicit SPD selection function that is invoked to select | |
1077 | the appropriate SPD for outbound traffic processing. The inputs to | |
1078 | this function are the outbound packet and any local metadata (e.g., | |
1079 | the interface via which the packet arrived) required to effect the | |
1080 | SPD selection function. The output of the function is an SPD | |
1081 | identifier (SPD-ID). | |
1082 | ||
1083 | The SPD is an ordered database, consistent with the use of Access | |
1084 | Control Lists (ACLs) or packet filters in firewalls, routers, etc. | |
1085 | The ordering requirement arises because entries often will overlap | |
1086 | due to the presence of (non-trivial) ranges as values for selectors. | |
1087 | Thus, a user or administrator MUST be able to order the entries to | |
1088 | express a desired access control policy. There is no way to impose a | |
1089 | general, canonical order on SPD entries, because of the allowed use | |
1090 | of wildcards for selector values and because the different types of | |
1091 | selectors are not hierarchically related. | |
1092 | ||
1093 | Processing Choices: DISCARD, BYPASS, PROTECT | |
1094 | ||
1095 | An SPD must discriminate among traffic that is afforded IPsec | |
1096 | protection and traffic that is allowed to bypass IPsec. This | |
1097 | applies to the IPsec protection to be applied by a sender and to | |
1098 | the IPsec protection that must be present at the receiver. For | |
1099 | any outbound or inbound datagram, three processing choices are | |
1100 | possible: DISCARD, BYPASS IPsec, or PROTECT using IPsec. The | |
1101 | first choice refers to traffic that is not allowed to traverse the | |
1102 | IPsec boundary (in the specified direction). The second choice | |
1103 | refers to traffic that is allowed to cross the IPsec boundary | |
1104 | without IPsec protection. The third choice refers to traffic that | |
1105 | is afforded IPsec protection, and for such traffic the SPD must | |
1106 | specify the security protocols to be employed, their mode, | |
1107 | security service options, and the cryptographic algorithms to be | |
1108 | used. | |
1109 | ||
1110 | SPD-S, SPD-I, SPD-O | |
1111 | ||
1112 | An SPD is logically divided into three pieces. The SPD-S (secure | |
1113 | traffic) contains entries for all traffic subject to IPsec | |
1114 | protection. SPD-O (outbound) contains entries for all outbound | |
1115 | traffic that is to be bypassed or discarded. SPD-I (inbound) is | |
1116 | applied to inbound traffic that will be bypassed or discarded. | |
1117 | All three of these can be decorrelated (with the exception noted | |
1118 | above for native host implementations) to facilitate caching. If | |
1119 | ||
1120 | ||
1121 | ||
1122 | Kent & Seo Standards Track [Page 20] | |
1123 | \f | |
1124 | RFC 4301 Security Architecture for IP December 2005 | |
1125 | ||
1126 | ||
1127 | an IPsec implementation supports only one SPD, then the SPD | |
1128 | consists of all three parts. If multiple SPDs are supported, some | |
1129 | of them may be partial, e.g., some SPDs might contain only SPD-I | |
1130 | entries, to control inbound bypassed traffic on a per-interface | |
1131 | basis. The split allows SPD-I to be consulted without having to | |
1132 | consult SPD-S, for such traffic. Since the SPD-I is just a part | |
1133 | of the SPD, if a packet that is looked up in the SPD-I cannot be | |
1134 | matched to an entry there, then the packet MUST be discarded. | |
1135 | Note that for outbound traffic, if a match is not found in SPD-S, | |
1136 | then SPD-O must be checked to see if the traffic should be | |
1137 | bypassed. Similarly, if SPD-O is checked first and no match is | |
1138 | found, then SPD-S must be checked. In an ordered, | |
1139 | non-decorrelated SPD, the entries for the SPD-S, SPD-I, and SPD-O | |
1140 | are interleaved. So there is one lookup in the SPD. | |
1141 | ||
1142 | SPD Entries | |
1143 | ||
1144 | Each SPD entry specifies packet disposition as BYPASS, DISCARD, or | |
1145 | PROTECT. The entry is keyed by a list of one or more selectors. | |
1146 | The SPD contains an ordered list of these entries. The required | |
1147 | selector types are defined in Section 4.4.1.1. These selectors are | |
1148 | used to define the granularity of the SAs that are created in | |
1149 | response to an outbound packet or in response to a proposal from a | |
1150 | peer. The detailed structure of an SPD entry is described in | |
1151 | Section 4.4.1.2. Every SPD SHOULD have a nominal, final entry that | |
1152 | matches anything that is otherwise unmatched, and discards it. | |
1153 | ||
1154 | The SPD MUST permit a user or administrator to specify policy | |
1155 | entries as follows: | |
1156 | ||
1157 | - SPD-I: For inbound traffic that is to be bypassed or discarded, | |
1158 | the entry consists of the values of the selectors that apply to | |
1159 | the traffic to be bypassed or discarded. | |
1160 | ||
1161 | - SPD-O: For outbound traffic that is to be bypassed or | |
1162 | discarded, the entry consists of the values of the selectors | |
1163 | that apply to the traffic to be bypassed or discarded. | |
1164 | ||
1165 | - SPD-S: For traffic that is to be protected using IPsec, the | |
1166 | entry consists of the values of the selectors that apply to the | |
1167 | traffic to be protected via AH or ESP, controls on how to | |
1168 | create SAs based on these selectors, and the parameters needed | |
1169 | to effect this protection (e.g., algorithms, modes, etc.). Note | |
1170 | that an SPD-S entry also contains information such as "populate | |
1171 | from packet" (PFP) flag (see paragraphs below on "How To Derive | |
1172 | the Values for an SAD entry") and bits indicating whether the | |
1173 | ||
1174 | ||
1175 | ||
1176 | ||
1177 | ||
1178 | Kent & Seo Standards Track [Page 21] | |
1179 | \f | |
1180 | RFC 4301 Security Architecture for IP December 2005 | |
1181 | ||
1182 | ||
1183 | SA lookup makes use of the local and remote IP addresses in | |
1184 | addition to the SPI (see AH [Ken05b] or ESP [Ken05a] | |
1185 | specifications). | |
1186 | ||
1187 | Representing Directionality in an SPD Entry | |
1188 | ||
1189 | For traffic protected by IPsec, the Local and Remote address and | |
1190 | ports in an SPD entry are swapped to represent directionality, | |
1191 | consistent with IKE conventions. In general, the protocols that | |
1192 | IPsec deals with have the property of requiring symmetric SAs with | |
1193 | flipped Local/Remote IP addresses. However, for ICMP, there is | |
1194 | often no such bi-directional authorization requirement. | |
1195 | Nonetheless, for the sake of uniformity and simplicity, SPD | |
1196 | entries for ICMP are specified in the same way as for other | |
1197 | protocols. Note also that for ICMP, Mobility Header, and | |
1198 | non-initial fragments, there are no port fields in these packets. | |
1199 | ICMP has message type and code and Mobility Header has mobility | |
1200 | header type. Thus, SPD entries have provisions for expressing | |
1201 | access controls appropriate for these protocols, in lieu of the | |
1202 | normal port field controls. For bypassed or discarded traffic, | |
1203 | separate inbound and outbound entries are supported, e.g., to | |
1204 | permit unidirectional flows if required. | |
1205 | ||
1206 | OPAQUE and ANY | |
1207 | ||
1208 | For each selector in an SPD entry, in addition to the literal | |
1209 | values that define a match, there are two special values: ANY and | |
1210 | OPAQUE. ANY is a wildcard that matches any value in the | |
1211 | corresponding field of the packet, or that matches packets where | |
1212 | that field is not present or is obscured. OPAQUE indicates that | |
1213 | the corresponding selector field is not available for examination | |
1214 | because it may not be present in a fragment, it does not exist for | |
1215 | the given Next Layer Protocol, or prior application of IPsec may | |
1216 | have encrypted the value. The ANY value encompasses the OPAQUE | |
1217 | value. Thus, OPAQUE need be used only when it is necessary to | |
1218 | distinguish between the case of any allowed value for a field, vs. | |
1219 | the absence or unavailability (e.g., due to encryption) of the | |
1220 | field. | |
1221 | ||
1222 | How to Derive the Values for an SAD Entry | |
1223 | ||
1224 | For each selector in an SPD entry, the entry specifies how to | |
1225 | derive the corresponding values for a new SA Database (SAD, see | |
1226 | Section 4.4.2) entry from those in the SPD and the packet. The | |
1227 | goal is to allow an SAD entry and an SPD cache entry to be created | |
1228 | based on specific selector values from the packet, or from the | |
1229 | matching SPD entry. For outbound traffic, there are SPD-S cache | |
1230 | entries and SPD-O cache entries. For inbound traffic not | |
1231 | ||
1232 | ||
1233 | ||
1234 | Kent & Seo Standards Track [Page 22] | |
1235 | \f | |
1236 | RFC 4301 Security Architecture for IP December 2005 | |
1237 | ||
1238 | ||
1239 | protected by IPsec, there are SPD-I cache entries and there is the | |
1240 | SAD, which represents the cache for inbound IPsec-protected | |
1241 | traffic (see Section 4.4.2). If IPsec processing is specified for | |
1242 | an entry, a "populate from packet" (PFP) flag may be asserted for | |
1243 | one or more of the selectors in the SPD entry (Local IP address; | |
1244 | Remote IP address; Next Layer Protocol; and, depending on Next | |
1245 | Layer Protocol, Local port and Remote port, or ICMP type/code, or | |
1246 | Mobility Header type). If asserted for a given selector X, the | |
1247 | flag indicates that the SA to be created should take its value for | |
1248 | X from the value in the packet. Otherwise, the SA should take its | |
1249 | value(s) for X from the value(s) in the SPD entry. Note: In the | |
1250 | non-PFP case, the selector values negotiated by the SA management | |
1251 | protocol (e.g., IKEv2) may be a subset of those in the SPD entry, | |
1252 | depending on the SPD policy of the peer. Also, whether a single | |
1253 | flag is used for, e.g., source port, ICMP type/code, and Mobility | |
1254 | Header (MH) type, or a separate flag is used for each, is a local | |
1255 | matter. | |
1256 | ||
1257 | The following example illustrates the use of the PFP flag in the | |
1258 | context of a security gateway or a BITS/BITW implementation. | |
1259 | Consider an SPD entry where the allowed value for Remote address | |
1260 | is a range of IPv4 addresses: 192.0.2.1 to 192.0.2.10. Suppose an | |
1261 | outbound packet arrives with a destination address of 192.0.2.3, | |
1262 | and there is no extant SA to carry this packet. The value used | |
1263 | for the SA created to transmit this packet could be either of the | |
1264 | two values shown below, depending on what the SPD entry for this | |
1265 | selector says is the source of the selector value: | |
1266 | ||
1267 | PFP flag value example of new | |
1268 | for the Remote SAD dest. address | |
1269 | addr. selector selector value | |
1270 | --------------- ------------ | |
1271 | a. PFP TRUE 192.0.2.3 (one host) | |
1272 | b. PFP FALSE 192.0.2.1 to 192.0.2.10 (range of hosts) | |
1273 | ||
1274 | Note that if the SPD entry above had a value of ANY for the Remote | |
1275 | address, then the SAD selector value would have to be ANY for case | |
1276 | (b), but would still be as illustrated for case (a). Thus, the | |
1277 | PFP flag can be used to prohibit sharing of an SA, even among | |
1278 | packets that match the same SPD entry. | |
1279 | ||
1280 | Management Interface | |
1281 | ||
1282 | For every IPsec implementation, there MUST be a management | |
1283 | interface that allows a user or system administrator to manage the | |
1284 | SPD. The interface must allow the user (or administrator) to | |
1285 | specify the security processing to be applied to every packet that | |
1286 | traverses the IPsec boundary. (In a native host IPsec | |
1287 | ||
1288 | ||
1289 | ||
1290 | Kent & Seo Standards Track [Page 23] | |
1291 | \f | |
1292 | RFC 4301 Security Architecture for IP December 2005 | |
1293 | ||
1294 | ||
1295 | implementation making use of a socket interface, the SPD may not | |
1296 | need to be consulted on a per-packet basis, as noted at the end of | |
1297 | Section 4.4.1.1 and in Section 5.) The management interface for | |
1298 | the SPD MUST allow creation of entries consistent with the | |
1299 | selectors defined in Section 4.4.1.1, and MUST support (total) | |
1300 | ordering of these entries, as seen via this interface. The SPD | |
1301 | entries' selectors are analogous to the ACL or packet filters | |
1302 | commonly found in a stateless firewall or packet filtering router | |
1303 | and which are currently managed this way. | |
1304 | ||
1305 | In host systems, applications MAY be allowed to create SPD | |
1306 | entries. (The means of signaling such requests to the IPsec | |
1307 | implementation are outside the scope of this standard.) However, | |
1308 | the system administrator MUST be able to specify whether or not a | |
1309 | user or application can override (default) system policies. The | |
1310 | form of the management interface is not specified by this document | |
1311 | and may differ for hosts vs. security gateways, and within hosts | |
1312 | the interface may differ for socket-based vs. BITS | |
1313 | implementations. However, this document does specify a standard | |
1314 | set of SPD elements that all IPsec implementations MUST support. | |
1315 | ||
1316 | Decorrelation | |
1317 | ||
1318 | The processing model described in this document assumes the | |
1319 | ability to decorrelate overlapping SPD entries to permit caching, | |
1320 | which enables more efficient processing of outbound traffic in | |
1321 | security gateways and BITS/BITW implementations. Decorrelation | |
1322 | [CoSa04] is only a means of improving performance and simplifying | |
1323 | the processing description. This RFC does not require a compliant | |
1324 | implementation to make use of decorrelation. For example, native | |
1325 | host implementations typically make use of caching implicitly | |
1326 | because they bind SAs to socket interfaces, and thus there is no | |
1327 | requirement to be able to decorrelate SPD entries in these | |
1328 | implementations. | |
1329 | ||
1330 | Note: Unless otherwise qualified, the use of "SPD" refers to the | |
1331 | body of policy information in both ordered or decorrelated | |
1332 | (unordered) state. Appendix B provides an algorithm that can be | |
1333 | used to decorrelate SPD entries, but any algorithm that produces | |
1334 | equivalent output may be used. Note that when an SPD entry is | |
1335 | decorrelated all the resulting entries MUST be linked together, so | |
1336 | that all members of the group derived from an individual, SPD | |
1337 | entry (prior to decorrelation) can all be placed into caches and | |
1338 | into the SAD at the same time. For example, suppose one starts | |
1339 | with an entry A (from an ordered SPD) that when decorrelated, | |
1340 | yields entries A1, A2, and A3. When a packet comes along that | |
1341 | matches, say A2, and triggers the creation of an SA, the SA | |
1342 | management protocol (e.g., IKEv2) negotiates A. And all 3 | |
1343 | ||
1344 | ||
1345 | ||
1346 | Kent & Seo Standards Track [Page 24] | |
1347 | \f | |
1348 | RFC 4301 Security Architecture for IP December 2005 | |
1349 | ||
1350 | ||
1351 | decorrelated entries, A1, A2, and A3, are placed in the | |
1352 | appropriate SPD-S cache and linked to the SA. The intent is that | |
1353 | use of a decorrelated SPD ought not to create more SAs than would | |
1354 | have resulted from use of a not-decorrelated SPD. | |
1355 | ||
1356 | If a decorrelated SPD is employed, there are three options for | |
1357 | what an initiator sends to a peer via an SA management protocol | |
1358 | (e.g., IKE). By sending the complete set of linked, decorrelated | |
1359 | entries that were selected from the SPD, a peer is given the best | |
1360 | possible information to enable selection of the appropriate SPD | |
1361 | entry at its end, especially if the peer has also decorrelated its | |
1362 | SPD. However, if a large number of decorrelated entries are | |
1363 | linked, this may create large packets for SA negotiation, and | |
1364 | hence fragmentation problems for the SA management protocol. | |
1365 | ||
1366 | Alternatively, the original entry from the (correlated) SPD may be | |
1367 | retained and passed to the SA management protocol. Passing the | |
1368 | correlated SPD entry keeps the use of a decorrelated SPD a local | |
1369 | matter, not visible to peers, and avoids possible fragmentation | |
1370 | concerns, although it provides less precise information to a | |
1371 | responder for matching against the responder's SPD. | |
1372 | ||
1373 | An intermediate approach is to send a subset of the complete set | |
1374 | of linked, decorrelated SPD entries. This approach can avoid the | |
1375 | fragmentation problems cited above yet provide better information | |
1376 | than the original, correlated entry. The major shortcoming of | |
1377 | this approach is that it may cause additional SAs to be created | |
1378 | later, since only a subset of the linked, decorrelated entries are | |
1379 | sent to a peer. Implementers are free to employ any of the | |
1380 | approaches cited above. | |
1381 | ||
1382 | A responder uses the traffic selector proposals it receives via an | |
1383 | SA management protocol to select an appropriate entry in its SPD. | |
1384 | The intent of the matching is to select an SPD entry and create an | |
1385 | SA that most closely matches the intent of the initiator, so that | |
1386 | traffic traversing the resulting SA will be accepted at both ends. | |
1387 | If the responder employs a decorrelated SPD, it SHOULD use the | |
1388 | decorrelated SPD entries for matching, as this will generally | |
1389 | result in creation of SAs that are more likely to match the intent | |
1390 | of both peers. If the responder has a correlated SPD, then it | |
1391 | SHOULD match the proposals against the correlated entries. For | |
1392 | IKEv2, use of a decorrelated SPD offers the best opportunity for a | |
1393 | responder to generate a "narrowed" response. | |
1394 | ||
1395 | In all cases, when a decorrelated SPD is available, the | |
1396 | decorrelated entries are used to populate the SPD-S cache. If the | |
1397 | SPD is not decorrelated, caching is not allowed and an ordered | |
1398 | ||
1399 | ||
1400 | ||
1401 | ||
1402 | Kent & Seo Standards Track [Page 25] | |
1403 | \f | |
1404 | RFC 4301 Security Architecture for IP December 2005 | |
1405 | ||
1406 | ||
1407 | search of SPD MUST be performed to verify that inbound traffic | |
1408 | arriving on an SA is consistent with the access control policy | |
1409 | expressed in the SPD. | |
1410 | ||
1411 | Handling Changes to the SPD While the System Is Running | |
1412 | ||
1413 | If a change is made to the SPD while the system is running, a | |
1414 | check SHOULD be made of the effect of this change on extant SAs. | |
1415 | An implementation SHOULD check the impact of an SPD change on | |
1416 | extant SAs and SHOULD provide a user/administrator with a | |
1417 | mechanism for configuring what actions to take, e.g., delete an | |
1418 | affected SA, allow an affected SA to continue unchanged, etc. | |
1419 | ||
1420 | 4.4.1.1. Selectors | |
1421 | ||
1422 | An SA may be fine-grained or coarse-grained, depending on the | |
1423 | selectors used to define the set of traffic for the SA. For example, | |
1424 | all traffic between two hosts may be carried via a single SA, and | |
1425 | afforded a uniform set of security services. Alternatively, traffic | |
1426 | between a pair of hosts might be spread over multiple SAs, depending | |
1427 | on the applications being used (as defined by the Next Layer Protocol | |
1428 | and related fields, e.g., ports), with different security services | |
1429 | offered by different SAs. Similarly, all traffic between a pair of | |
1430 | security gateways could be carried on a single SA, or one SA could be | |
1431 | assigned for each communicating host pair. The following selector | |
1432 | parameters MUST be supported by all IPsec implementations to | |
1433 | facilitate control of SA granularity. Note that both Local and | |
1434 | Remote addresses should either be IPv4 or IPv6, but not a mix of | |
1435 | address types. Also, note that the Local/Remote port selectors (and | |
1436 | ICMP message type and code, and Mobility Header type) may be labeled | |
1437 | as OPAQUE to accommodate situations where these fields are | |
1438 | inaccessible due to packet fragmentation. | |
1439 | ||
1440 | - Remote IP Address(es) (IPv4 or IPv6): This is a list of ranges | |
1441 | of IP addresses (unicast, broadcast (IPv4 only)). This | |
1442 | structure allows expression of a single IP address (via a | |
1443 | trivial range), or a list of addresses (each a trivial range), | |
1444 | or a range of addresses (low and high values, inclusive), as | |
1445 | well as the most generic form of a list of ranges. Address | |
1446 | ranges are used to support more than one remote system sharing | |
1447 | the same SA, e.g., behind a security gateway. | |
1448 | ||
1449 | - Local IP Address(es) (IPv4 or IPv6): This is a list of ranges of | |
1450 | IP addresses (unicast, broadcast (IPv4 only)). This structure | |
1451 | allows expression of a single IP address (via a trivial range), | |
1452 | or a list of addresses (each a trivial range), or a range of | |
1453 | addresses (low and high values, inclusive), as well as the most | |
1454 | generic form of a list of ranges. Address ranges are used to | |
1455 | ||
1456 | ||
1457 | ||
1458 | Kent & Seo Standards Track [Page 26] | |
1459 | \f | |
1460 | RFC 4301 Security Architecture for IP December 2005 | |
1461 | ||
1462 | ||
1463 | support more than one source system sharing the same SA, e.g., | |
1464 | behind a security gateway. Local refers to the address(es) | |
1465 | being protected by this implementation (or policy entry). | |
1466 | ||
1467 | Note: The SPD does not include support for multicast address | |
1468 | entries. To support multicast SAs, an implementation should | |
1469 | make use of a Group SPD (GSPD) as defined in [RFC3740]. GSPD | |
1470 | entries require a different structure, i.e., one cannot use the | |
1471 | symmetric relationship associated with local and remote address | |
1472 | values for unicast SAs in a multicast context. Specifically, | |
1473 | outbound traffic directed to a multicast address on an SA would | |
1474 | not be received on a companion, inbound SA with the multicast | |
1475 | address as the source. | |
1476 | ||
1477 | - Next Layer Protocol: Obtained from the IPv4 "Protocol" or the | |
1478 | IPv6 "Next Header" fields. This is an individual protocol | |
1479 | number, ANY, or for IPv6 only, OPAQUE. The Next Layer Protocol | |
1480 | is whatever comes after any IP extension headers that are | |
1481 | present. To simplify locating the Next Layer Protocol, there | |
1482 | SHOULD be a mechanism for configuring which IPv6 extension | |
1483 | headers to skip. The default configuration for which protocols | |
1484 | to skip SHOULD include the following protocols: 0 (Hop-by-hop | |
1485 | options), 43 (Routing Header), 44 (Fragmentation Header), and 60 | |
1486 | (Destination Options). Note: The default list does NOT include | |
1487 | 51 (AH) or 50 (ESP). From a selector lookup point of view, | |
1488 | IPsec treats AH and ESP as Next Layer Protocols. | |
1489 | ||
1490 | Several additional selectors depend on the Next Layer Protocol | |
1491 | value: | |
1492 | ||
1493 | * If the Next Layer Protocol uses two ports (as do TCP, UDP, | |
1494 | SCTP, and others), then there are selectors for Local and | |
1495 | Remote Ports. Each of these selectors has a list of ranges | |
1496 | of values. Note that the Local and Remote ports may not be | |
1497 | available in the case of receipt of a fragmented packet or if | |
1498 | the port fields have been protected by IPsec (encrypted); | |
1499 | thus, a value of OPAQUE also MUST be supported. Note: In a | |
1500 | non-initial fragment, port values will not be available. If | |
1501 | a port selector specifies a value other than ANY or OPAQUE, | |
1502 | it cannot match packets that are non-initial fragments. If | |
1503 | the SA requires a port value other than ANY or OPAQUE, an | |
1504 | arriving fragment without ports MUST be discarded. (See | |
1505 | Section 7, "Handling Fragments".) | |
1506 | ||
1507 | * If the Next Layer Protocol is a Mobility Header, then there | |
1508 | is a selector for IPv6 Mobility Header message type (MH type) | |
1509 | [Mobip]. This is an 8-bit value that identifies a particular | |
1510 | mobility message. Note that the MH type may not be available | |
1511 | ||
1512 | ||
1513 | ||
1514 | Kent & Seo Standards Track [Page 27] | |
1515 | \f | |
1516 | RFC 4301 Security Architecture for IP December 2005 | |
1517 | ||
1518 | ||
1519 | in the case of receipt of a fragmented packet. (See Section | |
1520 | 7, "Handling Fragments".) For IKE, the IPv6 Mobility Header | |
1521 | message type (MH type) is placed in the most significant | |
1522 | eight bits of the 16-bit local "port" selector. | |
1523 | ||
1524 | * If the Next Layer Protocol value is ICMP, then there is a | |
1525 | 16-bit selector for the ICMP message type and code. The | |
1526 | message type is a single 8-bit value, which defines the type | |
1527 | of an ICMP message, or ANY. The ICMP code is a single 8-bit | |
1528 | value that defines a specific subtype for an ICMP message. | |
1529 | For IKE, the message type is placed in the most significant 8 | |
1530 | bits of the 16-bit selector and the code is placed in the | |
1531 | least significant 8 bits. This 16-bit selector can contain a | |
1532 | single type and a range of codes, a single type and ANY code, | |
1533 | and ANY type and ANY code. Given a policy entry with a range | |
1534 | of Types (T-start to T-end) and a range of Codes (C-start to | |
1535 | C-end), and an ICMP packet with Type t and Code c, an | |
1536 | implementation MUST test for a match using | |
1537 | ||
1538 | (T-start*256) + C-start <= (t*256) + c <= (T-end*256) + | |
1539 | C-end | |
1540 | ||
1541 | Note that the ICMP message type and code may not be available | |
1542 | in the case of receipt of a fragmented packet. (See Section | |
1543 | 7, "Handling Fragments".) | |
1544 | ||
1545 | - Name: This is not a selector like the others above. It is not | |
1546 | acquired from a packet. A name may be used as a symbolic | |
1547 | identifier for an IPsec Local or Remote address. Named SPD | |
1548 | entries are used in two ways: | |
1549 | ||
1550 | 1. A named SPD entry is used by a responder (not an initiator) | |
1551 | in support of access control when an IP address would not be | |
1552 | appropriate for the Remote IP address selector, e.g., for | |
1553 | "road warriors". The name used to match this field is | |
1554 | communicated during the IKE negotiation in the ID payload. | |
1555 | In this context, the initiator's Source IP address (inner IP | |
1556 | header in tunnel mode) is bound to the Remote IP address in | |
1557 | the SAD entry created by the IKE negotiation. This address | |
1558 | overrides the Remote IP address value in the SPD, when the | |
1559 | SPD entry is selected in this fashion. All IPsec | |
1560 | implementations MUST support this use of names. | |
1561 | ||
1562 | 2. A named SPD entry may be used by an initiator to identify a | |
1563 | user for whom an IPsec SA will be created (or for whom | |
1564 | traffic may be bypassed). The initiator's IP source address | |
1565 | (from inner IP header in tunnel mode) is used to replace the | |
1566 | following if and when they are created: | |
1567 | ||
1568 | ||
1569 | ||
1570 | Kent & Seo Standards Track [Page 28] | |
1571 | \f | |
1572 | RFC 4301 Security Architecture for IP December 2005 | |
1573 | ||
1574 | ||
1575 | - local address in the SPD cache entry | |
1576 | - local address in the outbound SAD entry | |
1577 | - remote address in the inbound SAD entry | |
1578 | ||
1579 | Support for this use is optional for multi-user, native host | |
1580 | implementations and not applicable to other implementations. | |
1581 | Note that this name is used only locally; it is not | |
1582 | communicated by the key management protocol. Also, name | |
1583 | forms other than those used for case 1 above (responder) are | |
1584 | applicable in the initiator context (see below). | |
1585 | ||
1586 | An SPD entry can contain both a name (or a list of names) and | |
1587 | also values for the Local or Remote IP address. | |
1588 | ||
1589 | For case 1, responder, the identifiers employed in named SPD | |
1590 | entries are one of the following four types: | |
1591 | ||
1592 | a. a fully qualified user name string (email), e.g., | |
1593 | mozart@foo.example.com | |
1594 | (this corresponds to ID_RFC822_ADDR in IKEv2) | |
1595 | ||
1596 | b. a fully qualified DNS name, e.g., | |
1597 | foo.example.com | |
1598 | (this corresponds to ID_FQDN in IKEv2) | |
1599 | ||
1600 | c. X.500 distinguished name, e.g., [WaKiHo97], | |
1601 | CN = Stephen T. Kent, O = BBN Technologies, | |
1602 | SP = MA, C = US | |
1603 | (this corresponds to ID_DER_ASN1_DN in IKEv2, after | |
1604 | decoding) | |
1605 | ||
1606 | d. a byte string | |
1607 | (this corresponds to Key_ID in IKEv2) | |
1608 | ||
1609 | For case 2, initiator, the identifiers employed in named SPD | |
1610 | entries are of type byte string. They are likely to be Unix | |
1611 | UIDs, Windows security IDs, or something similar, but could | |
1612 | also be a user name or account name. In all cases, this | |
1613 | identifier is only of local concern and is not transmitted. | |
1614 | ||
1615 | The IPsec implementation context determines how selectors are used. | |
1616 | For example, a native host implementation typically makes use of a | |
1617 | socket interface. When a new connection is established, the SPD can | |
1618 | be consulted and an SA bound to the socket. Thus, traffic sent via | |
1619 | that socket need not result in additional lookups to the SPD (SPD-O | |
1620 | and SPD-S) cache. In contrast, a BITS, BITW, or security gateway | |
1621 | implementation needs to look at each packet and perform an | |
1622 | SPD-O/SPD-S cache lookup based on the selectors. | |
1623 | ||
1624 | ||
1625 | ||
1626 | Kent & Seo Standards Track [Page 29] | |
1627 | \f | |
1628 | RFC 4301 Security Architecture for IP December 2005 | |
1629 | ||
1630 | ||
1631 | 4.4.1.2. Structure of an SPD Entry | |
1632 | ||
1633 | This section contains a prose description of an SPD entry. Also, | |
1634 | Appendix C provides an example of an ASN.1 definition of an SPD | |
1635 | entry. | |
1636 | ||
1637 | This text describes the SPD in a fashion that is intended to map | |
1638 | directly into IKE payloads to ensure that the policy required by SPD | |
1639 | entries can be negotiated through IKE. Unfortunately, the semantics | |
1640 | of the version of IKEv2 published concurrently with this document | |
1641 | [Kau05] do not align precisely with those defined for the SPD. | |
1642 | Specifically, IKEv2 does not enable negotiation of a single SA that | |
1643 | binds multiple pairs of local and remote addresses and ports to a | |
1644 | single SA. Instead, when multiple local and remote addresses and | |
1645 | ports are negotiated for an SA, IKEv2 treats these not as pairs, but | |
1646 | as (unordered) sets of local and remote values that can be | |
1647 | arbitrarily paired. Until IKE provides a facility that conveys the | |
1648 | semantics that are expressed in the SPD via selector sets (as | |
1649 | described below), users MUST NOT include multiple selector sets in a | |
1650 | single SPD entry unless the access control intent aligns with the IKE | |
1651 | "mix and match" semantics. An implementation MAY warn users, to | |
1652 | alert them to this problem if users create SPD entries with multiple | |
1653 | selector sets, the syntax of which indicates possible conflicts with | |
1654 | current IKE semantics. | |
1655 | ||
1656 | The management GUI can offer the user other forms of data entry and | |
1657 | display, e.g., the option of using address prefixes as well as | |
1658 | ranges, and symbolic names for protocols, ports, etc. (Do not confuse | |
1659 | the use of symbolic names in a management interface with the SPD | |
1660 | selector "Name".) Note that Remote/Local apply only to IP addresses | |
1661 | and ports, not to ICMP message type/code or Mobility Header type. | |
1662 | Also, if the reserved, symbolic selector value OPAQUE or ANY is | |
1663 | employed for a given selector type, only that value may appear in the | |
1664 | list for that selector, and it must appear only once in the list for | |
1665 | that selector. Note that ANY and OPAQUE are local syntax conventions | |
1666 | -- IKEv2 negotiates these values via the ranges indicated below: | |
1667 | ||
1668 | ANY: start = 0 end = <max> | |
1669 | OPAQUE: start = <max> end = 0 | |
1670 | ||
1671 | An SPD is an ordered list of entries each of which contains the | |
1672 | following fields. | |
1673 | ||
1674 | o Name -- a list of IDs. This quasi-selector is optional. | |
1675 | The forms that MUST be supported are described above in | |
1676 | Section 4.4.1.1 under "Name". | |
1677 | ||
1678 | ||
1679 | ||
1680 | ||
1681 | ||
1682 | Kent & Seo Standards Track [Page 30] | |
1683 | \f | |
1684 | RFC 4301 Security Architecture for IP December 2005 | |
1685 | ||
1686 | ||
1687 | o PFP flags -- one per traffic selector. A given flag, e.g., | |
1688 | for Next Layer Protocol, applies to the relevant selector | |
1689 | across all "selector sets" (see below) contained in an SPD | |
1690 | entry. When creating an SA, each flag specifies for the | |
1691 | corresponding traffic selector whether to instantiate the | |
1692 | selector from the corresponding field in the packet that | |
1693 | triggered the creation of the SA or from the value(s) in | |
1694 | the corresponding SPD entry (see Section 4.4.1, "How to | |
1695 | Derive the Values for an SAD Entry"). Whether a single | |
1696 | flag is used for, e.g., source port, ICMP type/code, and | |
1697 | MH type, or a separate flag is used for each, is a local | |
1698 | matter. There are PFP flags for: | |
1699 | - Local Address | |
1700 | - Remote Address | |
1701 | - Next Layer Protocol | |
1702 | - Local Port, or ICMP message type/code or Mobility | |
1703 | Header type (depending on the next layer protocol) | |
1704 | - Remote Port, or ICMP message type/code or Mobility | |
1705 | Header type (depending on the next layer protocol) | |
1706 | ||
1707 | o One to N selector sets that correspond to the "condition" | |
1708 | for applying a particular IPsec action. Each selector set | |
1709 | contains: | |
1710 | - Local Address | |
1711 | - Remote Address | |
1712 | - Next Layer Protocol | |
1713 | - Local Port, or ICMP message type/code or Mobility | |
1714 | Header type (depending on the next layer protocol) | |
1715 | - Remote Port, or ICMP message type/code or Mobility | |
1716 | Header type (depending on the next layer protocol) | |
1717 | ||
1718 | Note: The "next protocol" selector is an individual value | |
1719 | (unlike the local and remote IP addresses) in a selector | |
1720 | set entry. This is consistent with how IKEv2 negotiates | |
1721 | the Traffic Selector (TS) values for an SA. It also makes | |
1722 | sense because one may need to associate different port | |
1723 | fields with different protocols. It is possible to | |
1724 | associate multiple protocols (and ports) with a single SA | |
1725 | by specifying multiple selector sets for that SA. | |
1726 | ||
1727 | o Processing info -- which action is required -- PROTECT, | |
1728 | BYPASS, or DISCARD. There is just one action that goes | |
1729 | with all the selector sets, not a separate action for each | |
1730 | set. If the required processing is PROTECT, the entry | |
1731 | contains the following information. | |
1732 | - IPsec mode -- tunnel or transport | |
1733 | ||
1734 | ||
1735 | ||
1736 | ||
1737 | ||
1738 | Kent & Seo Standards Track [Page 31] | |
1739 | \f | |
1740 | RFC 4301 Security Architecture for IP December 2005 | |
1741 | ||
1742 | ||
1743 | - (if tunnel mode) local tunnel address -- For a | |
1744 | non-mobile host, if there is just one interface, this | |
1745 | is straightforward; if there are multiple | |
1746 | interfaces, this must be statically configured. For a | |
1747 | mobile host, the specification of the local address | |
1748 | is handled externally to IPsec. | |
1749 | - (if tunnel mode) remote tunnel address -- There is no | |
1750 | standard way to determine this. See 4.5.3, "Locating | |
1751 | a Security Gateway". | |
1752 | - Extended Sequence Number -- Is this SA using extended | |
1753 | sequence numbers? | |
1754 | - stateful fragment checking -- Is this SA using | |
1755 | stateful fragment checking? (See Section 7 for more | |
1756 | details.) | |
1757 | - Bypass DF bit (T/F) -- applicable to tunnel mode SAs | |
1758 | - Bypass DSCP (T/F) or map to unprotected DSCP values | |
1759 | (array) if needed to restrict bypass of DSCP values -- | |
1760 | applicable to tunnel mode SAs | |
1761 | - IPsec protocol -- AH or ESP | |
1762 | - algorithms -- which ones to use for AH, which ones to | |
1763 | use for ESP, which ones to use for combined mode, | |
1764 | ordered by decreasing priority | |
1765 | ||
1766 | It is a local matter as to what information is kept with regard to | |
1767 | handling extant SAs when the SPD is changed. | |
1768 | ||
1769 | 4.4.1.3. More Regarding Fields Associated with Next Layer Protocols | |
1770 | ||
1771 | Additional selectors are often associated with fields in the Next | |
1772 | Layer Protocol header. A particular Next Layer Protocol can have | |
1773 | zero, one, or two selectors. There may be situations where there | |
1774 | aren't both local and remote selectors for the fields that are | |
1775 | dependent on the Next Layer Protocol. The IPv6 Mobility Header has | |
1776 | only a Mobility Header message type. AH and ESP have no further | |
1777 | selector fields. A system may be willing to send an ICMP message | |
1778 | type and code that it does not want to receive. In the descriptions | |
1779 | below, "port" is used to mean a field that is dependent on the Next | |
1780 | Layer Protocol. | |
1781 | ||
1782 | A. If a Next Layer Protocol has no "port" selectors, then | |
1783 | the Local and Remote "port" selectors are set to OPAQUE in | |
1784 | the relevant SPD entry, e.g., | |
1785 | ||
1786 | Local's | |
1787 | next layer protocol = AH | |
1788 | "port" selector = OPAQUE | |
1789 | ||
1790 | ||
1791 | ||
1792 | ||
1793 | ||
1794 | Kent & Seo Standards Track [Page 32] | |
1795 | \f | |
1796 | RFC 4301 Security Architecture for IP December 2005 | |
1797 | ||
1798 | ||
1799 | Remote's | |
1800 | next layer protocol = AH | |
1801 | "port" selector = OPAQUE | |
1802 | ||
1803 | B. Even if a Next Layer Protocol has only one selector, e.g., | |
1804 | Mobility Header type, then the Local and Remote "port" | |
1805 | selectors are used to indicate whether a system is | |
1806 | willing to send and/or receive traffic with the specified | |
1807 | "port" values. For example, if Mobility Headers of a | |
1808 | specified type are allowed to be sent and received via an | |
1809 | SA, then the relevant SPD entry would be set as follows: | |
1810 | ||
1811 | Local's | |
1812 | next layer protocol = Mobility Header | |
1813 | "port" selector = Mobility Header message type | |
1814 | ||
1815 | Remote's | |
1816 | next layer protocol = Mobility Header | |
1817 | "port" selector = Mobility Header message type | |
1818 | ||
1819 | If Mobility Headers of a specified type are allowed to be | |
1820 | sent but NOT received via an SA, then the relevant SPD | |
1821 | entry would be set as follows: | |
1822 | ||
1823 | Local's | |
1824 | next layer protocol = Mobility Header | |
1825 | "port" selector = Mobility Header message type | |
1826 | ||
1827 | Remote's | |
1828 | next layer protocol = Mobility Header | |
1829 | "port" selector = OPAQUE | |
1830 | ||
1831 | If Mobility Headers of a specified type are allowed to be | |
1832 | received but NOT sent via an SA, then the relevant SPD | |
1833 | entry would be set as follows: | |
1834 | ||
1835 | Local's | |
1836 | next layer protocol = Mobility Header | |
1837 | "port" selector = OPAQUE | |
1838 | ||
1839 | Remote's | |
1840 | next layer protocol = Mobility Header | |
1841 | "port" selector = Mobility Header message type | |
1842 | ||
1843 | C. If a system is willing to send traffic with a particular | |
1844 | "port" value but NOT receive traffic with that kind of | |
1845 | port value, the system's traffic selectors are set as | |
1846 | follows in the relevant SPD entry: | |
1847 | ||
1848 | ||
1849 | ||
1850 | Kent & Seo Standards Track [Page 33] | |
1851 | \f | |
1852 | RFC 4301 Security Architecture for IP December 2005 | |
1853 | ||
1854 | ||
1855 | Local's | |
1856 | next layer protocol = ICMP | |
1857 | "port" selector = <specific ICMP type & code> | |
1858 | ||
1859 | Remote's | |
1860 | next layer protocol = ICMP | |
1861 | "port" selector = OPAQUE | |
1862 | ||
1863 | D. To indicate that a system is willing to receive traffic | |
1864 | with a particular "port" value but NOT send that kind of | |
1865 | traffic, the system's traffic selectors are set as follows | |
1866 | in the relevant SPD entry: | |
1867 | ||
1868 | Local's | |
1869 | next layer protocol = ICMP | |
1870 | "port" selector = OPAQUE | |
1871 | ||
1872 | Remote's | |
1873 | next layer protocol = ICMP | |
1874 | "port" selector = <specific ICMP type & code> | |
1875 | ||
1876 | For example, if a security gateway is willing to allow | |
1877 | systems behind it to send ICMP traceroutes, but is not | |
1878 | willing to let outside systems run ICMP traceroutes to | |
1879 | systems behind it, then the security gateway's traffic | |
1880 | selectors are set as follows in the relevant SPD entry: | |
1881 | ||
1882 | Local's | |
1883 | next layer protocol = 1 (ICMPv4) | |
1884 | "port" selector = 30 (traceroute) | |
1885 | ||
1886 | Remote's | |
1887 | next layer protocol = 1 (ICMPv4) | |
1888 | "port" selector = OPAQUE | |
1889 | ||
1890 | 4.4.2. Security Association Database (SAD) | |
1891 | ||
1892 | In each IPsec implementation, there is a nominal Security Association | |
1893 | Database (SAD), in which each entry defines the parameters associated | |
1894 | with one SA. Each SA has an entry in the SAD. For outbound | |
1895 | processing, each SAD entry is pointed to by entries in the SPD-S part | |
1896 | of the SPD cache. For inbound processing, for unicast SAs, the SPI | |
1897 | is used either alone to look up an SA or in conjunction with the | |
1898 | IPsec protocol type. If an IPsec implementation supports multicast, | |
1899 | the SPI plus destination address, or SPI plus destination and source | |
1900 | addresses are used to look up the SA. (See Section 4.1 for details on | |
1901 | the algorithm that MUST be used for mapping inbound IPsec datagrams | |
1902 | to SAs.) The following parameters are associated with each entry in | |
1903 | ||
1904 | ||
1905 | ||
1906 | Kent & Seo Standards Track [Page 34] | |
1907 | \f | |
1908 | RFC 4301 Security Architecture for IP December 2005 | |
1909 | ||
1910 | ||
1911 | the SAD. They should all be present except where otherwise noted, | |
1912 | e.g., AH Authentication algorithm. This description does not purport | |
1913 | to be a MIB, only a specification of the minimal data items required | |
1914 | to support an SA in an IPsec implementation. | |
1915 | ||
1916 | For each of the selectors defined in Section 4.4.1.1, the entry for | |
1917 | an inbound SA in the SAD MUST be initially populated with the value | |
1918 | or values negotiated at the time the SA was created. (See the | |
1919 | paragraph in Section 4.4.1 under "Handling Changes to the SPD while | |
1920 | the System is Running" for guidance on the effect of SPD changes on | |
1921 | extant SAs.) For a receiver, these values are used to check that the | |
1922 | header fields of an inbound packet (after IPsec processing) match the | |
1923 | selector values negotiated for the SA. Thus, the SAD acts as a cache | |
1924 | for checking the selectors of inbound traffic arriving on SAs. For | |
1925 | the receiver, this is part of verifying that a packet arriving on an | |
1926 | SA is consistent with the policy for the SA. (See Section 6 for rules | |
1927 | for ICMP messages.) These fields can have the form of specific | |
1928 | values, ranges, ANY, or OPAQUE, as described in Section 4.4.1.1, | |
1929 | "Selectors". Note also that there are a couple of situations in | |
1930 | which the SAD can have entries for SAs that do not have corresponding | |
1931 | entries in the SPD. Since this document does not mandate that the | |
1932 | SAD be selectively cleared when the SPD is changed, SAD entries can | |
1933 | remain when the SPD entries that created them are changed or deleted. | |
1934 | Also, if a manually keyed SA is created, there could be an SAD entry | |
1935 | for this SA that does not correspond to any SPD entry. | |
1936 | ||
1937 | Note: The SAD can support multicast SAs, if manually configured. An | |
1938 | outbound multicast SA has the same structure as a unicast SA. The | |
1939 | source address is that of the sender, and the destination address is | |
1940 | the multicast group address. An inbound, multicast SA must be | |
1941 | configured with the source addresses of each peer authorized to | |
1942 | transmit to the multicast SA in question. The SPI value for a | |
1943 | multicast SA is provided by a multicast group controller, not by the | |
1944 | receiver, as for a unicast SA. Because an SAD entry may be required | |
1945 | to accommodate multiple, individual IP source addresses that were | |
1946 | part of an SPD entry (for unicast SAs), the required facility for | |
1947 | inbound, multicast SAs is a feature already present in an IPsec | |
1948 | implementation. However, because the SPD has no provisions for | |
1949 | accommodating multicast entries, this document does not specify an | |
1950 | automated way to create an SAD entry for a multicast, inbound SA. | |
1951 | Only manually configured SAD entries can be created to accommodate | |
1952 | inbound, multicast traffic. | |
1953 | ||
1954 | Implementation Guidance: This document does not specify how an SPD-S | |
1955 | entry refers to the corresponding SAD entry, as this is an | |
1956 | implementation-specific detail. However, some implementations (based | |
1957 | on experience from RFC 2401) are known to have problems in this | |
1958 | regard. In particular, simply storing the (remote tunnel header IP | |
1959 | ||
1960 | ||
1961 | ||
1962 | Kent & Seo Standards Track [Page 35] | |
1963 | \f | |
1964 | RFC 4301 Security Architecture for IP December 2005 | |
1965 | ||
1966 | ||
1967 | address, remote SPI) pair in the SPD cache is not sufficient, since | |
1968 | the pair does not always uniquely identify a single SAD entry. For | |
1969 | instance, two hosts behind the same NAT could choose the same SPI | |
1970 | value. The situation also may arise if a host is assigned an IP | |
1971 | address (e.g., via DHCP) previously used by some other host, and the | |
1972 | SAs associated with the old host have not yet been deleted via dead | |
1973 | peer detection mechanisms. This may lead to packets being sent over | |
1974 | the wrong SA or, if key management ensures the pair is unique, | |
1975 | denying the creation of otherwise valid SAs. Thus, implementors | |
1976 | should implement links between the SPD cache and the SAD in a way | |
1977 | that does not engender such problems. | |
1978 | ||
1979 | 4.4.2.1. Data Items in the SAD | |
1980 | ||
1981 | The following data items MUST be in the SAD: | |
1982 | ||
1983 | o Security Parameter Index (SPI): a 32-bit value selected by the | |
1984 | receiving end of an SA to uniquely identify the SA. In an SAD | |
1985 | entry for an outbound SA, the SPI is used to construct the | |
1986 | packet's AH or ESP header. In an SAD entry for an inbound SA, the | |
1987 | SPI is used to map traffic to the appropriate SA (see text on | |
1988 | unicast/multicast in Section 4.1). | |
1989 | ||
1990 | o Sequence Number Counter: a 64-bit counter used to generate the | |
1991 | Sequence Number field in AH or ESP headers. 64-bit sequence | |
1992 | numbers are the default, but 32-bit sequence numbers are also | |
1993 | supported if negotiated. | |
1994 | ||
1995 | o Sequence Counter Overflow: a flag indicating whether overflow of | |
1996 | the sequence number counter should generate an auditable event and | |
1997 | prevent transmission of additional packets on the SA, or whether | |
1998 | rollover is permitted. The audit log entry for this event SHOULD | |
1999 | include the SPI value, current date/time, Local Address, Remote | |
2000 | Address, and the selectors from the relevant SAD entry. | |
2001 | ||
2002 | o Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent) | |
2003 | used to determine whether an inbound AH or ESP packet is a replay. | |
2004 | ||
2005 | Note: If anti-replay has been disabled by the receiver for an SA, | |
2006 | e.g., in the case of a manually keyed SA, then the Anti-Replay | |
2007 | Window is ignored for the SA in question. 64-bit sequence numbers | |
2008 | are the default, but this counter size accommodates 32-bit | |
2009 | sequence numbers as well. | |
2010 | ||
2011 | o AH Authentication algorithm, key, etc. This is required only if | |
2012 | AH is supported. | |
2013 | ||
2014 | ||
2015 | ||
2016 | ||
2017 | ||
2018 | Kent & Seo Standards Track [Page 36] | |
2019 | \f | |
2020 | RFC 4301 Security Architecture for IP December 2005 | |
2021 | ||
2022 | ||
2023 | o ESP Encryption algorithm, key, mode, IV, etc. If a combined mode | |
2024 | algorithm is used, these fields will not be applicable. | |
2025 | ||
2026 | o ESP integrity algorithm, keys, etc. If the integrity service is | |
2027 | not selected, these fields will not be applicable. If a combined | |
2028 | mode algorithm is used, these fields will not be applicable. | |
2029 | ||
2030 | o ESP combined mode algorithms, key(s), etc. This data is used when | |
2031 | a combined mode (encryption and integrity) algorithm is used with | |
2032 | ESP. If a combined mode algorithm is not used, these fields are | |
2033 | not applicable. | |
2034 | ||
2035 | o Lifetime of this SA: a time interval after which an SA must be | |
2036 | replaced with a new SA (and new SPI) or terminated, plus an | |
2037 | indication of which of these actions should occur. This may be | |
2038 | expressed as a time or byte count, or a simultaneous use of both | |
2039 | with the first lifetime to expire taking precedence. A compliant | |
2040 | implementation MUST support both types of lifetimes, and MUST | |
2041 | support a simultaneous use of both. If time is employed, and if | |
2042 | IKE employs X.509 certificates for SA establishment, the SA | |
2043 | lifetime must be constrained by the validity intervals of the | |
2044 | certificates, and the NextIssueDate of the Certificate Revocation | |
2045 | Lists (CRLs) used in the IKE exchange for the SA. Both initiator | |
2046 | and responder are responsible for constraining the SA lifetime in | |
2047 | this fashion. Note: The details of how to handle the refreshing | |
2048 | of keys when SAs expire is a local matter. However, one | |
2049 | reasonable approach is: | |
2050 | ||
2051 | (a) If byte count is used, then the implementation SHOULD count the | |
2052 | number of bytes to which the IPsec cryptographic algorithm is | |
2053 | applied. For ESP, this is the encryption algorithm (including | |
2054 | Null encryption) and for AH, this is the authentication | |
2055 | algorithm. This includes pad bytes, etc. Note that | |
2056 | implementations MUST be able to handle having the counters at | |
2057 | the ends of an SA get out of synch, e.g., because of packet | |
2058 | loss or because the implementations at each end of the SA | |
2059 | aren't doing things the same way. | |
2060 | ||
2061 | (b) There SHOULD be two kinds of lifetime -- a soft lifetime that | |
2062 | warns the implementation to initiate action such as setting up | |
2063 | a replacement SA, and a hard lifetime when the current SA ends | |
2064 | and is destroyed. | |
2065 | ||
2066 | (c) If the entire packet does not get delivered during the SA's | |
2067 | lifetime, the packet SHOULD be discarded. | |
2068 | ||
2069 | o IPsec protocol mode: tunnel or transport. Indicates which mode of | |
2070 | AH or ESP is applied to traffic on this SA. | |
2071 | ||
2072 | ||
2073 | ||
2074 | Kent & Seo Standards Track [Page 37] | |
2075 | \f | |
2076 | RFC 4301 Security Architecture for IP December 2005 | |
2077 | ||
2078 | ||
2079 | o Stateful fragment checking flag. Indicates whether or not | |
2080 | stateful fragment checking applies to this SA. | |
2081 | ||
2082 | o Bypass DF bit (T/F) -- applicable to tunnel mode SAs where both | |
2083 | inner and outer headers are IPv4. | |
2084 | ||
2085 | o DSCP values -- the set of DSCP values allowed for packets carried | |
2086 | over this SA. If no values are specified, no DSCP-specific | |
2087 | filtering is applied. If one or more values are specified, these | |
2088 | are used to select one SA among several that match the traffic | |
2089 | selectors for an outbound packet. Note that these values are NOT | |
2090 | checked against inbound traffic arriving on the SA. | |
2091 | ||
2092 | o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if | |
2093 | needed to restrict bypass of DSCP values -- applicable to tunnel | |
2094 | mode SAs. This feature maps DSCP values from an inner header to | |
2095 | values in an outer header, e.g., to address covert channel | |
2096 | signaling concerns. | |
2097 | ||
2098 | o Path MTU: any observed path MTU and aging variables. | |
2099 | ||
2100 | o Tunnel header IP source and destination address -- both addresses | |
2101 | must be either IPv4 or IPv6 addresses. The version implies the | |
2102 | type of IP header to be used. Only used when the IPsec protocol | |
2103 | mode is tunnel. | |
2104 | ||
2105 | 4.4.2.2. Relationship between SPD, PFP flag, packet, and SAD | |
2106 | ||
2107 | For each selector, the following tables show the relationship | |
2108 | between the value in the SPD, the PFP flag, the value in the | |
2109 | triggering packet, and the resulting value in the SAD. Note that | |
2110 | the administrative interface for IPsec can use various syntactic | |
2111 | options to make it easier for the administrator to enter rules. | |
2112 | For example, although a list of ranges is what IKEv2 sends, it | |
2113 | might be clearer and less error prone for the user to enter a | |
2114 | single IP address or IP address prefix. | |
2115 | ||
2116 | ||
2117 | ||
2118 | ||
2119 | ||
2120 | ||
2121 | ||
2122 | ||
2123 | ||
2124 | ||
2125 | ||
2126 | ||
2127 | ||
2128 | ||
2129 | ||
2130 | Kent & Seo Standards Track [Page 38] | |
2131 | \f | |
2132 | RFC 4301 Security Architecture for IP December 2005 | |
2133 | ||
2134 | ||
2135 | Value in | |
2136 | Triggering Resulting SAD | |
2137 | Selector SPD Entry PFP Packet Entry | |
2138 | -------- ---------------- --- ------------ -------------- | |
2139 | loc addr list of ranges 0 IP addr "S" list of ranges | |
2140 | ANY 0 IP addr "S" ANY | |
2141 | list of ranges 1 IP addr "S" "S" | |
2142 | ANY 1 IP addr "S" "S" | |
2143 | ||
2144 | rem addr list of ranges 0 IP addr "D" list of ranges | |
2145 | ANY 0 IP addr "D" ANY | |
2146 | list of ranges 1 IP addr "D" "D" | |
2147 | ANY 1 IP addr "D" "D" | |
2148 | ||
2149 | protocol list of prot's* 0 prot. "P" list of prot's* | |
2150 | ANY** 0 prot. "P" ANY | |
2151 | OPAQUE**** 0 prot. "P" OPAQUE | |
2152 | ||
2153 | list of prot's* 0 not avail. discard packet | |
2154 | ANY** 0 not avail. ANY | |
2155 | OPAQUE**** 0 not avail. OPAQUE | |
2156 | ||
2157 | list of prot's* 1 prot. "P" "P" | |
2158 | ANY** 1 prot. "P" "P" | |
2159 | OPAQUE**** 1 prot. "P" *** | |
2160 | ||
2161 | list of prot's* 1 not avail. discard packet | |
2162 | ANY** 1 not avail. discard packet | |
2163 | OPAQUE**** 1 not avail. *** | |
2164 | ||
2165 | ||
2166 | ||
2167 | ||
2168 | ||
2169 | ||
2170 | ||
2171 | ||
2172 | ||
2173 | ||
2174 | ||
2175 | ||
2176 | ||
2177 | ||
2178 | ||
2179 | ||
2180 | ||
2181 | ||
2182 | ||
2183 | ||
2184 | ||
2185 | ||
2186 | Kent & Seo Standards Track [Page 39] | |
2187 | \f | |
2188 | RFC 4301 Security Architecture for IP December 2005 | |
2189 | ||
2190 | ||
2191 | If the protocol is one that has two ports, then there will be | |
2192 | selectors for both Local and Remote ports. | |
2193 | ||
2194 | Value in | |
2195 | Triggering Resulting SAD | |
2196 | Selector SPD Entry PFP Packet Entry | |
2197 | -------- ---------------- --- ------------ -------------- | |
2198 | loc port list of ranges 0 src port "s" list of ranges | |
2199 | ANY 0 src port "s" ANY | |
2200 | OPAQUE 0 src port "s" OPAQUE | |
2201 | ||
2202 | list of ranges 0 not avail. discard packet | |
2203 | ANY 0 not avail. ANY | |
2204 | OPAQUE 0 not avail. OPAQUE | |
2205 | ||
2206 | list of ranges 1 src port "s" "s" | |
2207 | ANY 1 src port "s" "s" | |
2208 | OPAQUE 1 src port "s" *** | |
2209 | ||
2210 | list of ranges 1 not avail. discard packet | |
2211 | ANY 1 not avail. discard packet | |
2212 | OPAQUE 1 not avail. *** | |
2213 | ||
2214 | ||
2215 | rem port list of ranges 0 dst port "d" list of ranges | |
2216 | ANY 0 dst port "d" ANY | |
2217 | OPAQUE 0 dst port "d" OPAQUE | |
2218 | ||
2219 | list of ranges 0 not avail. discard packet | |
2220 | ANY 0 not avail. ANY | |
2221 | OPAQUE 0 not avail. OPAQUE | |
2222 | ||
2223 | list of ranges 1 dst port "d" "d" | |
2224 | ANY 1 dst port "d" "d" | |
2225 | OPAQUE 1 dst port "d" *** | |
2226 | ||
2227 | list of ranges 1 not avail. discard packet | |
2228 | ANY 1 not avail. discard packet | |
2229 | OPAQUE 1 not avail. *** | |
2230 | ||
2231 | ||
2232 | ||
2233 | ||
2234 | ||
2235 | ||
2236 | ||
2237 | ||
2238 | ||
2239 | ||
2240 | ||
2241 | ||
2242 | Kent & Seo Standards Track [Page 40] | |
2243 | \f | |
2244 | RFC 4301 Security Architecture for IP December 2005 | |
2245 | ||
2246 | ||
2247 | If the protocol is mobility header, then there will be a selector | |
2248 | for mh type. | |
2249 | ||
2250 | Value in | |
2251 | Triggering Resulting SAD | |
2252 | Selector SPD Entry PFP Packet Entry | |
2253 | -------- ---------------- --- ------------ -------------- | |
2254 | mh type list of ranges 0 mh type "T" list of ranges | |
2255 | ANY 0 mh type "T" ANY | |
2256 | OPAQUE 0 mh type "T" OPAQUE | |
2257 | ||
2258 | list of ranges 0 not avail. discard packet | |
2259 | ANY 0 not avail. ANY | |
2260 | OPAQUE 0 not avail. OPAQUE | |
2261 | ||
2262 | list of ranges 1 mh type "T" "T" | |
2263 | ANY 1 mh type "T" "T" | |
2264 | OPAQUE 1 mh type "T" *** | |
2265 | ||
2266 | list of ranges 1 not avail. discard packet | |
2267 | ANY 1 not avail. discard packet | |
2268 | OPAQUE 1 not avail. *** | |
2269 | ||
2270 | ||
2271 | ||
2272 | ||
2273 | ||
2274 | ||
2275 | ||
2276 | ||
2277 | ||
2278 | ||
2279 | ||
2280 | ||
2281 | ||
2282 | ||
2283 | ||
2284 | ||
2285 | ||
2286 | ||
2287 | ||
2288 | ||
2289 | ||
2290 | ||
2291 | ||
2292 | ||
2293 | ||
2294 | ||
2295 | ||
2296 | ||
2297 | ||
2298 | Kent & Seo Standards Track [Page 41] | |
2299 | \f | |
2300 | RFC 4301 Security Architecture for IP December 2005 | |
2301 | ||
2302 | ||
2303 | If the protocol is ICMP, then there will be a 16-bit selector for | |
2304 | ICMP type and ICMP code. Note that the type and code are bound to | |
2305 | each other, i.e., the codes apply to the particular type. This | |
2306 | 16-bit selector can contain a single type and a range of codes, a | |
2307 | single type and ANY code, and ANY type and ANY code. | |
2308 | ||
2309 | Value in | |
2310 | Triggering Resulting SAD | |
2311 | Selector SPD Entry PFP Packet Entry | |
2312 | --------- ---------------- --- ------------ -------------- | |
2313 | ICMP type a single type & 0 type "t" & single type & | |
2314 | and code range of codes code "c" range of codes | |
2315 | a single type & 0 type "t" & single type & | |
2316 | ANY code code "c" ANY code | |
2317 | ANY type & ANY 0 type "t" & ANY type & | |
2318 | code code "c" ANY code | |
2319 | OPAQUE 0 type "t" & OPAQUE | |
2320 | code "c" | |
2321 | ||
2322 | a single type & 0 not avail. discard packet | |
2323 | range of codes | |
2324 | a single type & 0 not avail. discard packet | |
2325 | ANY code | |
2326 | ANY type & 0 not avail. ANY type & | |
2327 | ANY code ANY code | |
2328 | OPAQUE 0 not avail. OPAQUE | |
2329 | ||
2330 | a single type & 1 type "t" & "t" and "c" | |
2331 | range of codes code "c" | |
2332 | a single type & 1 type "t" & "t" and "c" | |
2333 | ANY code code "c" | |
2334 | ANY type & 1 type "t" & "t" and "c" | |
2335 | ANY code code "c" | |
2336 | OPAQUE 1 type "t" & *** | |
2337 | code "c" | |
2338 | ||
2339 | a single type & 1 not avail. discard packet | |
2340 | range of codes | |
2341 | a single type & 1 not avail. discard packet | |
2342 | ANY code | |
2343 | ANY type & 1 not avail. discard packet | |
2344 | ANY code | |
2345 | OPAQUE 1 not avail. *** | |
2346 | ||
2347 | ||
2348 | ||
2349 | ||
2350 | ||
2351 | ||
2352 | ||
2353 | ||
2354 | Kent & Seo Standards Track [Page 42] | |
2355 | \f | |
2356 | RFC 4301 Security Architecture for IP December 2005 | |
2357 | ||
2358 | ||
2359 | If the name selector is used: | |
2360 | ||
2361 | Value in | |
2362 | Triggering Resulting SAD | |
2363 | Selector SPD Entry PFP Packet Entry | |
2364 | --------- ---------------- --- ------------ -------------- | |
2365 | name list of user or N/A N/A N/A | |
2366 | system names | |
2367 | ||
2368 | * "List of protocols" is the information, not the way | |
2369 | that the SPD or SAD or IKEv2 have to represent this | |
2370 | information. | |
2371 | ** 0 (zero) is used by IKE to indicate ANY for | |
2372 | protocol. | |
2373 | *** Use of PFP=1 with an OPAQUE value is an error and | |
2374 | SHOULD be prohibited by an IPsec implementation. | |
2375 | **** The protocol field cannot be OPAQUE in IPv4. This | |
2376 | table entry applies only to IPv6. | |
2377 | ||
2378 | 4.4.3. Peer Authorization Database (PAD) | |
2379 | ||
2380 | The Peer Authorization Database (PAD) provides the link between the | |
2381 | SPD and a security association management protocol such as IKE. It | |
2382 | embodies several critical functions: | |
2383 | ||
2384 | o identifies the peers or groups of peers that are authorized | |
2385 | to communicate with this IPsec entity | |
2386 | o specifies the protocol and method used to authenticate each | |
2387 | peer | |
2388 | o provides the authentication data for each peer | |
2389 | o constrains the types and values of IDs that can be asserted | |
2390 | by a peer with regard to child SA creation, to ensure that the | |
2391 | peer does not assert identities for lookup in the SPD that it | |
2392 | is not authorized to represent, when child SAs are created | |
2393 | o peer gateway location info, e.g., IP address(es) or DNS names, | |
2394 | MAY be included for peers that are known to be "behind" a | |
2395 | security gateway | |
2396 | ||
2397 | The PAD provides these functions for an IKE peer when the peer acts | |
2398 | as either the initiator or the responder. | |
2399 | ||
2400 | To perform these functions, the PAD contains an entry for each peer | |
2401 | or group of peers with which the IPsec entity will communicate. An | |
2402 | entry names an individual peer (a user, end system or security | |
2403 | gateway) or specifies a group of peers (using ID matching rules | |
2404 | defined below). The entry specifies the authentication protocol | |
2405 | (e.g., IKEv1, IKEv2, KINK) method used (e.g., certificates or pre- | |
2406 | shared secrets) and the authentication data (e.g., the pre-shared | |
2407 | ||
2408 | ||
2409 | ||
2410 | Kent & Seo Standards Track [Page 43] | |
2411 | \f | |
2412 | RFC 4301 Security Architecture for IP December 2005 | |
2413 | ||
2414 | ||
2415 | secret or the trust anchor relative to which the peer's certificate | |
2416 | will be validated). For certificate-based authentication, the entry | |
2417 | also may provide information to assist in verifying the revocation | |
2418 | status of the peer, e.g., a pointer to a CRL repository or the name | |
2419 | of an Online Certificate Status Protocol (OCSP) server associated | |
2420 | with the peer or with the trust anchor associated with the peer. | |
2421 | ||
2422 | Each entry also specifies whether the IKE ID payload will be used as | |
2423 | a symbolic name for SPD lookup, or whether the remote IP address | |
2424 | provided in traffic selector payloads will be used for SPD lookups | |
2425 | when child SAs are created. | |
2426 | ||
2427 | Note that the PAD information MAY be used to support creation of more | |
2428 | than one tunnel mode SA at a time between two peers, e.g., two | |
2429 | tunnels to protect the same addresses/hosts, but with different | |
2430 | tunnel endpoints. | |
2431 | ||
2432 | 4.4.3.1. PAD Entry IDs and Matching Rules | |
2433 | ||
2434 | The PAD is an ordered database, where the order is defined by an | |
2435 | administrator (or a user in the case of a single-user end system). | |
2436 | Usually, the same administrator will be responsible for both the PAD | |
2437 | and SPD, since the two databases must be coordinated. The ordering | |
2438 | requirement for the PAD arises for the same reason as for the SPD, | |
2439 | i.e., because use of "star name" entries allows for overlaps in the | |
2440 | set of IKE IDs that could match a specific entry. | |
2441 | ||
2442 | Six types of IDs are supported for entries in the PAD, consistent | |
2443 | with the symbolic name types and IP addresses used to identify SPD | |
2444 | entries. The ID for each entry acts as the index for the PAD, i.e., | |
2445 | it is the value used to select an entry. All of these ID types can | |
2446 | be used to match IKE ID payload types. The six types are: | |
2447 | ||
2448 | o DNS name (specific or partial) | |
2449 | o Distinguished Name (complete or sub-tree constrained) | |
2450 | o RFC 822 email address (complete or partially qualified) | |
2451 | o IPv4 address (range) | |
2452 | o IPv6 address (range) | |
2453 | o Key ID (exact match only) | |
2454 | ||
2455 | The first three name types can accommodate sub-tree matching as well | |
2456 | as exact matches. A DNS name may be fully qualified and thus match | |
2457 | exactly one name, e.g., foo.example.com. Alternatively, the name may | |
2458 | encompass a group of peers by being partially specified, e.g., the | |
2459 | string ".example.com" could be used to match any DNS name ending in | |
2460 | these two domain name components. | |
2461 | ||
2462 | ||
2463 | ||
2464 | ||
2465 | ||
2466 | Kent & Seo Standards Track [Page 44] | |
2467 | \f | |
2468 | RFC 4301 Security Architecture for IP December 2005 | |
2469 | ||
2470 | ||
2471 | Similarly, a Distinguished Name may specify a complete Distinguished | |
2472 | Name to match exactly one entry, e.g., CN = Stephen, O = BBN | |
2473 | Technologies, SP = MA, C = US. Alternatively, an entry may encompass | |
2474 | a group of peers by specifying a sub-tree, e.g., an entry of the form | |
2475 | "C = US, SP = MA" might be used to match all DNs that contain these | |
2476 | two attributes as the top two Relative Distinguished Names (RDNs). | |
2477 | ||
2478 | For an RFC 822 e-mail addresses, the same options exist. A complete | |
2479 | address such as foo@example.com matches one entity, but a sub-tree | |
2480 | name such as "@example.com" could be used to match all the entities | |
2481 | with names ending in those two domain names to the right of the @. | |
2482 | ||
2483 | The specific syntax used by an implementation to accommodate sub-tree | |
2484 | matching for distinguished names, domain names or RFC 822 e-mail | |
2485 | addresses is a local matter. But, at a minimum, sub-tree matching of | |
2486 | the sort described above MUST be supported. (Substring matching | |
2487 | within a DN, DNS name, or RFC 822 address MAY be supported, but is | |
2488 | not required.) | |
2489 | ||
2490 | For IPv4 and IPv6 addresses, the same address range syntax used for | |
2491 | SPD entries MUST be supported. This allows specification of an | |
2492 | individual address (via a trivial range), an address prefix (by | |
2493 | choosing a range that adheres to Classless Inter-Domain Routing | |
2494 | (CIDR)-style prefixes), or an arbitrary address range. | |
2495 | ||
2496 | The Key ID field is defined as an OCTET string in IKE. For this name | |
2497 | type, only exact-match syntax MUST be supported (since there is no | |
2498 | explicit structure for this ID type). Additional matching functions | |
2499 | MAY be supported for this ID type. | |
2500 | ||
2501 | 4.4.3.2. IKE Peer Authentication Data | |
2502 | ||
2503 | Once an entry is located based on an ordered search of the PAD based | |
2504 | on ID field matching, it is necessary to verify the asserted | |
2505 | identity, i.e., to authenticate the asserted ID. For each PAD entry, | |
2506 | there is an indication of the type of authentication to be performed. | |
2507 | This document requires support for two required authentication data | |
2508 | types: | |
2509 | ||
2510 | - X.509 certificate | |
2511 | - pre-shared secret | |
2512 | ||
2513 | For authentication based on an X.509 certificate, the PAD entry | |
2514 | contains a trust anchor via which the end entity (EE) certificate for | |
2515 | the peer must be verifiable, either directly or via a certificate | |
2516 | path. See RFC 3280 for the definition of a trust anchor. An entry | |
2517 | used with certificate-based authentication MAY include additional | |
2518 | data to facilitate certificate revocation status, e.g., a list of | |
2519 | ||
2520 | ||
2521 | ||
2522 | Kent & Seo Standards Track [Page 45] | |
2523 | \f | |
2524 | RFC 4301 Security Architecture for IP December 2005 | |
2525 | ||
2526 | ||
2527 | appropriate OCSP responders or CRL repositories, and associated | |
2528 | authentication data. For authentication based on a pre-shared | |
2529 | secret, the PAD contains the pre-shared secret to be used by IKE. | |
2530 | ||
2531 | This document does not require that the IKE ID asserted by a peer be | |
2532 | syntactically related to a specific field in an end entity | |
2533 | certificate that is employed to authenticate the identity of that | |
2534 | peer. However, it often will be appropriate to impose such a | |
2535 | requirement, e.g., when a single entry represents a set of peers each | |
2536 | of whom may have a distinct SPD entry. Thus, implementations MUST | |
2537 | provide a means for an administrator to require a match between an | |
2538 | asserted IKE ID and the subject name or subject alt name in a | |
2539 | certificate. The former is applicable to IKE IDs expressed as | |
2540 | distinguished names; the latter is appropriate for DNS names, RFC 822 | |
2541 | e-mail addresses, and IP addresses. Since KEY ID is intended for | |
2542 | identifying a peer authenticated via a pre-shared secret, there is no | |
2543 | requirement to match this ID type to a certificate field. | |
2544 | ||
2545 | See IKEv1 [HarCar98] and IKEv2 [Kau05] for details of how IKE | |
2546 | performs peer authentication using certificates or pre-shared | |
2547 | secrets. | |
2548 | ||
2549 | This document does not mandate support for any other authentication | |
2550 | methods, although such methods MAY be employed. | |
2551 | ||
2552 | 4.4.3.3. Child SA Authorization Data | |
2553 | ||
2554 | Once an IKE peer is authenticated, child SAs may be created. Each | |
2555 | PAD entry contains data to constrain the set of IDs that can be | |
2556 | asserted by an IKE peer, for matching against the SPD. Each PAD | |
2557 | entry indicates whether the IKE ID is to be used as a symbolic name | |
2558 | for SPD matching, or whether an IP address asserted in a traffic | |
2559 | selector payload is to be used. | |
2560 | ||
2561 | If the entry indicates that the IKE ID is to be used, then the PAD | |
2562 | entry ID field defines the authorized set of IDs. If the entry | |
2563 | indicates that child SAs traffic selectors are to be used, then an | |
2564 | additional data element is required, in the form of IPv4 and/or IPv6 | |
2565 | address ranges. (A peer may be authorized for both address types, so | |
2566 | there MUST be provision for both a v4 and a v6 address range.) | |
2567 | ||
2568 | 4.4.3.4. How the PAD Is Used | |
2569 | ||
2570 | During the initial IKE exchange, the initiator and responder each | |
2571 | assert their identity via the IKE ID payload and send an AUTH payload | |
2572 | to verify the asserted identity. One or more CERT payloads may be | |
2573 | transmitted to facilitate the verification of each asserted identity. | |
2574 | ||
2575 | ||
2576 | ||
2577 | ||
2578 | Kent & Seo Standards Track [Page 46] | |
2579 | \f | |
2580 | RFC 4301 Security Architecture for IP December 2005 | |
2581 | ||
2582 | ||
2583 | When an IKE entity receives an IKE ID payload, it uses the asserted | |
2584 | ID to locate an entry in the PAD, using the matching rules described | |
2585 | above. The PAD entry specifies the authentication method to be | |
2586 | employed for the identified peer. This ensures that the right method | |
2587 | is used for each peer and that different methods can be used for | |
2588 | different peers. The entry also specifies the authentication data | |
2589 | that will be used to verify the asserted identity. This data is | |
2590 | employed in conjunction with the specified method to authenticate the | |
2591 | peer, before any CHILD SAs are created. | |
2592 | ||
2593 | Child SAs are created based on the exchange of traffic selector | |
2594 | payloads, either at the end of the initial IKE exchange or in | |
2595 | subsequent CREATE_CHILD_SA exchanges. The PAD entry for the (now | |
2596 | authenticated) IKE peer is used to constrain creation of child SAs; | |
2597 | specifically, the PAD entry specifies how the SPD is searched using a | |
2598 | traffic selector proposal from a peer. There are two choices: either | |
2599 | the IKE ID asserted by the peer is used to find an SPD entry via its | |
2600 | symbolic name, or peer IP addresses asserted in traffic selector | |
2601 | payloads are used for SPD lookups based on the remote IP address | |
2602 | field portion of an SPD entry. It is necessary to impose these | |
2603 | constraints on creation of child SAs to prevent an authenticated peer | |
2604 | from spoofing IDs associated with other, legitimate peers. | |
2605 | ||
2606 | Note that because the PAD is checked before searching for an SPD | |
2607 | entry, this safeguard protects an initiator against spoofing attacks. | |
2608 | For example, assume that IKE A receives an outbound packet destined | |
2609 | for IP address X, a host served by a security gateway. RFC 2401 | |
2610 | [RFC2401] and this document do not specify how A determines the | |
2611 | address of the IKE peer serving X. However, any peer contacted by A | |
2612 | as the presumed representative for X must be registered in the PAD in | |
2613 | order to allow the IKE exchange to be authenticated. Moreover, when | |
2614 | the authenticated peer asserts that it represents X in its traffic | |
2615 | selector exchange, the PAD will be consulted to determine if the peer | |
2616 | in question is authorized to represent X. Thus, the PAD provides a | |
2617 | binding of address ranges (or name sub-spaces) to peers, to counter | |
2618 | such attacks. | |
2619 | ||
2620 | 4.5. SA and Key Management | |
2621 | ||
2622 | All IPsec implementations MUST support both manual and automated SA | |
2623 | and cryptographic key management. The IPsec protocols, AH and ESP, | |
2624 | are largely independent of the associated SA management techniques, | |
2625 | although the techniques involved do affect some of the security | |
2626 | services offered by the protocols. For example, the optional | |
2627 | anti-replay service available for AH and ESP requires automated SA | |
2628 | management. Moreover, the granularity of key distribution employed | |
2629 | with IPsec determines the granularity of authentication provided. In | |
2630 | general, data origin authentication in AH and ESP is limited by the | |
2631 | ||
2632 | ||
2633 | ||
2634 | Kent & Seo Standards Track [Page 47] | |
2635 | \f | |
2636 | RFC 4301 Security Architecture for IP December 2005 | |
2637 | ||
2638 | ||
2639 | extent to which secrets used with the integrity algorithm (or with a | |
2640 | key management protocol that creates such secrets) are shared among | |
2641 | multiple possible sources. | |
2642 | ||
2643 | The following text describes the minimum requirements for both types | |
2644 | of SA management. | |
2645 | ||
2646 | 4.5.1. Manual Techniques | |
2647 | ||
2648 | The simplest form of management is manual management, in which a | |
2649 | person manually configures each system with keying material and SA | |
2650 | management data relevant to secure communication with other systems. | |
2651 | Manual techniques are practical in small, static environments but | |
2652 | they do not scale well. For example, a company could create a | |
2653 | virtual private network (VPN) using IPsec in security gateways at | |
2654 | several sites. If the number of sites is small, and since all the | |
2655 | sites come under the purview of a single administrative domain, this | |
2656 | might be a feasible context for manual management techniques. In | |
2657 | this case, the security gateway might selectively protect traffic to | |
2658 | and from other sites within the organization using a manually | |
2659 | configured key, while not protecting traffic for other destinations. | |
2660 | It also might be appropriate when only selected communications need | |
2661 | to be secured. A similar argument might apply to use of IPsec | |
2662 | entirely within an organization for a small number of hosts and/or | |
2663 | gateways. Manual management techniques often employ statically | |
2664 | configured, symmetric keys, though other options also exist. | |
2665 | ||
2666 | 4.5.2. Automated SA and Key Management | |
2667 | ||
2668 | Widespread deployment and use of IPsec requires an Internet-standard, | |
2669 | scalable, automated, SA management protocol. Such support is | |
2670 | required to facilitate use of the anti-replay features of AH and ESP, | |
2671 | and to accommodate on-demand creation of SAs, e.g., for user- and | |
2672 | session-oriented keying. (Note that the notion of "rekeying" an SA | |
2673 | actually implies creation of a new SA with a new SPI, a process that | |
2674 | generally implies use of an automated SA/key management protocol.) | |
2675 | ||
2676 | The default automated key management protocol selected for use with | |
2677 | IPsec is IKEv2 [Kau05]. This document assumes the availability of | |
2678 | certain functions from the key management protocol that are not | |
2679 | supported by IKEv1. Other automated SA management protocols MAY be | |
2680 | employed. | |
2681 | ||
2682 | When an automated SA/key management protocol is employed, the output | |
2683 | from this protocol is used to generate multiple keys for a single SA. | |
2684 | This also occurs because distinct keys are used for each of the two | |
2685 | ||
2686 | ||
2687 | ||
2688 | ||
2689 | ||
2690 | Kent & Seo Standards Track [Page 48] | |
2691 | \f | |
2692 | RFC 4301 Security Architecture for IP December 2005 | |
2693 | ||
2694 | ||
2695 | SAs created by IKE. If both integrity and confidentiality are | |
2696 | employed, then a minimum of four keys are required. Additionally, | |
2697 | some cryptographic algorithms may require multiple keys, e.g., 3DES. | |
2698 | ||
2699 | The Key Management System may provide a separate string of bits for | |
2700 | each key or it may generate one string of bits from which all keys | |
2701 | are extracted. If a single string of bits is provided, care needs to | |
2702 | be taken to ensure that the parts of the system that map the string | |
2703 | of bits to the required keys do so in the same fashion at both ends | |
2704 | of the SA. To ensure that the IPsec implementations at each end of | |
2705 | the SA use the same bits for the same keys, and irrespective of which | |
2706 | part of the system divides the string of bits into individual keys, | |
2707 | the encryption keys MUST be taken from the first (left-most, | |
2708 | high-order) bits and the integrity keys MUST be taken from the | |
2709 | remaining bits. The number of bits for each key is defined in the | |
2710 | relevant cryptographic algorithm specification RFC. In the case of | |
2711 | multiple encryption keys or multiple integrity keys, the | |
2712 | specification for the cryptographic algorithm must specify the order | |
2713 | in which they are to be selected from a single string of bits | |
2714 | provided to the cryptographic algorithm. | |
2715 | ||
2716 | 4.5.3. Locating a Security Gateway | |
2717 | ||
2718 | This section discusses issues relating to how a host learns about the | |
2719 | existence of relevant security gateways and, once a host has | |
2720 | contacted these security gateways, how it knows that these are the | |
2721 | correct security gateways. The details of where the required | |
2722 | information is stored is a local matter, but the Peer Authorization | |
2723 | Database (PAD) described in Section 4.4 is the most likely candidate. | |
2724 | (Note: S* indicates a system that is running IPsec, e.g., SH1 and SG2 | |
2725 | below.) | |
2726 | ||
2727 | Consider a situation in which a remote host (SH1) is using the | |
2728 | Internet to gain access to a server or other machine (H2) and there | |
2729 | is a security gateway (SG2), e.g., a firewall, through which H1's | |
2730 | traffic must pass. An example of this situation would be a mobile | |
2731 | host crossing the Internet to his home organization's firewall (SG2). | |
2732 | This situation raises several issues: | |
2733 | ||
2734 | 1. How does SH1 know/learn about the existence of the security | |
2735 | gateway SG2? | |
2736 | ||
2737 | 2. How does it authenticate SG2, and once it has authenticated SG2, | |
2738 | how does it confirm that SG2 has been authorized to represent H2? | |
2739 | ||
2740 | 3. How does SG2 authenticate SH1 and verify that SH1 is authorized to | |
2741 | contact H2? | |
2742 | ||
2743 | ||
2744 | ||
2745 | ||
2746 | Kent & Seo Standards Track [Page 49] | |
2747 | \f | |
2748 | RFC 4301 Security Architecture for IP December 2005 | |
2749 | ||
2750 | ||
2751 | 4. How does SH1 know/learn about any additional gateways that provide | |
2752 | alternate paths to H2? | |
2753 | ||
2754 | To address these problems, an IPsec-supporting host or security | |
2755 | gateway MUST have an administrative interface that allows the | |
2756 | user/administrator to configure the address of one or more security | |
2757 | gateways for ranges of destination addresses that require its use. | |
2758 | This includes the ability to configure information for locating and | |
2759 | authenticating one or more security gateways and verifying the | |
2760 | authorization of these gateways to represent the destination host. | |
2761 | (The authorization function is implied in the PAD.) This document | |
2762 | does not address the issue of how to automate the | |
2763 | discovery/verification of security gateways. | |
2764 | ||
2765 | 4.6. SAs and Multicast | |
2766 | ||
2767 | The receiver-orientation of the SA implies that, in the case of | |
2768 | unicast traffic, the destination system will select the SPI value. | |
2769 | By having the destination select the SPI value, there is no potential | |
2770 | for manually configured SAs to conflict with automatically configured | |
2771 | (e.g., via a key management protocol) SAs or for SAs from multiple | |
2772 | sources to conflict with each other. For multicast traffic, there | |
2773 | are multiple destination systems associated with a single SA. So | |
2774 | some system or person will need to coordinate among all multicast | |
2775 | groups to select an SPI or SPIs on behalf of each multicast group and | |
2776 | then communicate the group's IPsec information to all of the | |
2777 | legitimate members of that multicast group via mechanisms not defined | |
2778 | here. | |
2779 | ||
2780 | Multiple senders to a multicast group SHOULD use a single Security | |
2781 | Association (and hence SPI) for all traffic to that group when a | |
2782 | symmetric key encryption or integrity algorithm is employed. In such | |
2783 | circumstances, the receiver knows only that the message came from a | |
2784 | system possessing the key for that multicast group. In such | |
2785 | circumstances, a receiver generally will not be able to authenticate | |
2786 | which system sent the multicast traffic. Specifications for other, | |
2787 | more general multicast approaches are deferred to the IETF Multicast | |
2788 | Security Working Group. | |
2789 | ||
2790 | 5. IP Traffic Processing | |
2791 | ||
2792 | As mentioned in Section 4.4.1, "The Security Policy Database (SPD)", | |
2793 | the SPD (or associated caches) MUST be consulted during the | |
2794 | processing of all traffic that crosses the IPsec protection boundary, | |
2795 | including IPsec management traffic. If no policy is found in the SPD | |
2796 | that matches a packet (for either inbound or outbound traffic), the | |
2797 | packet MUST be discarded. To simplify processing, and to allow for | |
2798 | very fast SA lookups (for SG/BITS/BITW), this document introduces the | |
2799 | ||
2800 | ||
2801 | ||
2802 | Kent & Seo Standards Track [Page 50] | |
2803 | \f | |
2804 | RFC 4301 Security Architecture for IP December 2005 | |
2805 | ||
2806 | ||
2807 | notion of an SPD cache for all outbound traffic (SPD-O plus SPD-S), | |
2808 | and a cache for inbound, non-IPsec-protected traffic (SPD-I). (As | |
2809 | mentioned earlier, the SAD acts as a cache for checking the selectors | |
2810 | of inbound IPsec-protected traffic arriving on SAs.) There is | |
2811 | nominally one cache per SPD. For the purposes of this specification, | |
2812 | it is assumed that each cached entry will map to exactly one SA. | |
2813 | Note, however, exceptions arise when one uses multiple SAs to carry | |
2814 | traffic of different priorities (e.g., as indicated by distinct DSCP | |
2815 | values) but the same selectors. Note also, that there are a couple | |
2816 | of situations in which the SAD can have entries for SAs that do not | |
2817 | have corresponding entries in the SPD. Since this document does not | |
2818 | mandate that the SAD be selectively cleared when the SPD is changed, | |
2819 | SAD entries can remain when the SPD entries that created them are | |
2820 | changed or deleted. Also, if a manually keyed SA is created, there | |
2821 | could be an SAD entry for this SA that does not correspond to any SPD | |
2822 | entry. | |
2823 | ||
2824 | Since SPD entries may overlap, one cannot safely cache these entries | |
2825 | in general. Simple caching might result in a match against a cache | |
2826 | entry, whereas an ordered search of the SPD would have resulted in a | |
2827 | match against a different entry. But, if the SPD entries are first | |
2828 | decorrelated, then the resulting entries can safely be cached. Each | |
2829 | cached entry will indicate that matching traffic should be bypassed | |
2830 | or discarded, appropriately. (Note: The original SPD entry might | |
2831 | result in multiple SAs, e.g., because of PFP.) Unless otherwise | |
2832 | noted, all references below to the "SPD" or "SPD cache" or "cache" | |
2833 | are to a decorrelated SPD (SPD-I, SPD-O, SPD-S) or the SPD cache | |
2834 | containing entries from the decorrelated SPD. | |
2835 | ||
2836 | Note: In a host IPsec implementation based on sockets, the SPD will | |
2837 | be consulted whenever a new socket is created to determine what, if | |
2838 | any, IPsec processing will be applied to the traffic that will flow | |
2839 | on that socket. This provides an implicit caching mechanism, and the | |
2840 | portions of the preceding discussion that address caching can be | |
2841 | ignored in such implementations. | |
2842 | ||
2843 | Note: It is assumed that one starts with a correlated SPD because | |
2844 | that is how users and administrators are accustomed to managing these | |
2845 | sorts of access control lists or firewall filter rules. Then the | |
2846 | decorrelation algorithm is applied to build a list of cache-able SPD | |
2847 | entries. The decorrelation is invisible at the management interface. | |
2848 | ||
2849 | For inbound IPsec traffic, the SAD entry selected by the SPI serves | |
2850 | as the cache for the selectors to be matched against arriving IPsec | |
2851 | packets, after AH or ESP processing has been performed. | |
2852 | ||
2853 | ||
2854 | ||
2855 | ||
2856 | ||
2857 | ||
2858 | Kent & Seo Standards Track [Page 51] | |
2859 | \f | |
2860 | RFC 4301 Security Architecture for IP December 2005 | |
2861 | ||
2862 | ||
2863 | 5.1. Outbound IP Traffic Processing (protected-to-unprotected) | |
2864 | ||
2865 | First consider the path for traffic entering the implementation via a | |
2866 | protected interface and exiting via an unprotected interface. | |
2867 | ||
2868 | Unprotected Interface | |
2869 | ^ | |
2870 | | | |
2871 | (nested SAs) +----------+ | |
2872 | -------------------|Forwarding|<-----+ | |
2873 | | +----------+ | | |
2874 | | ^ | | |
2875 | | | BYPASS | | |
2876 | V +-----+ | | |
2877 | +-------+ | SPD | +--------+ | |
2878 | ...| SPD-I |.................|Cache|.....|PROCESS |...IPsec | |
2879 | | (*) | | (*) |---->|(AH/ESP)| boundary | |
2880 | +-------+ +-----+ +--------+ | |
2881 | | +-------+ / ^ | |
2882 | | |DISCARD| <--/ | | |
2883 | | +-------+ | | |
2884 | | | | |
2885 | | +-------------+ | |
2886 | |---------------->|SPD Selection| | |
2887 | +-------------+ | |
2888 | ^ | |
2889 | | +------+ | |
2890 | | -->| ICMP | | |
2891 | | / +------+ | |
2892 | |/ | |
2893 | | | |
2894 | | | |
2895 | Protected Interface | |
2896 | ||
2897 | ||
2898 | Figure 2. Processing Model for Outbound Traffic | |
2899 | (*) = The SPD caches are shown here. If there | |
2900 | is a cache miss, then the SPD is checked. | |
2901 | There is no requirement that an | |
2902 | implementation buffer the packet if | |
2903 | there is a cache miss. | |
2904 | ||
2905 | ||
2906 | ||
2907 | ||
2908 | ||
2909 | ||
2910 | ||
2911 | ||
2912 | ||
2913 | ||
2914 | Kent & Seo Standards Track [Page 52] | |
2915 | \f | |
2916 | RFC 4301 Security Architecture for IP December 2005 | |
2917 | ||
2918 | ||
2919 | IPsec MUST perform the following steps when processing outbound | |
2920 | packets: | |
2921 | ||
2922 | 1. When a packet arrives from the subscriber (protected) interface, | |
2923 | invoke the SPD selection function to obtain the SPD-ID needed to | |
2924 | choose the appropriate SPD. (If the implementation uses only one | |
2925 | SPD, this step is a no-op.) | |
2926 | ||
2927 | 2. Match the packet headers against the cache for the SPD specified | |
2928 | by the SPD-ID from step 1. Note that this cache contains entries | |
2929 | from SPD-O and SPD-S. | |
2930 | ||
2931 | 3a. If there is a match, then process the packet as specified by the | |
2932 | matching cache entry, i.e., BYPASS, DISCARD, or PROTECT using AH | |
2933 | or ESP. If IPsec processing is applied, there is a link from the | |
2934 | SPD cache entry to the relevant SAD entry (specifying the mode, | |
2935 | cryptographic algorithms, keys, SPI, PMTU, etc.). IPsec | |
2936 | processing is as previously defined, for tunnel or transport | |
2937 | modes and for AH or ESP, as specified in their respective RFCs | |
2938 | [Ken05b, Ken05a]. Note that the SA PMTU value, plus the value of | |
2939 | the stateful fragment checking flag (and the DF bit in the IP | |
2940 | header of the outbound packet) determine whether the packet can | |
2941 | (must) be fragmented prior to or after IPsec processing, or if it | |
2942 | must be discarded and an ICMP PMTU message is sent. | |
2943 | ||
2944 | 3b. If no match is found in the cache, search the SPD (SPD-S and | |
2945 | SPD-O parts) specified by SPD-ID. If the SPD entry calls for | |
2946 | BYPASS or DISCARD, create one or more new outbound SPD cache | |
2947 | entries and if BYPASS, create one or more new inbound SPD cache | |
2948 | entries. (More than one cache entry may be created since a | |
2949 | decorrelated SPD entry may be linked to other such entries that | |
2950 | were created as a side effect of the decorrelation process.) If | |
2951 | the SPD entry calls for PROTECT, i.e., creation of an SA, the key | |
2952 | management mechanism (e.g., IKEv2) is invoked to create the SA. | |
2953 | If SA creation succeeds, a new outbound (SPD-S) cache entry is | |
2954 | created, along with outbound and inbound SAD entries, otherwise | |
2955 | the packet is discarded. (A packet that triggers an SPD lookup | |
2956 | MAY be discarded by the implementation, or it MAY be processed | |
2957 | against the newly created cache entry, if one is created.) Since | |
2958 | SAs are created in pairs, an SAD entry for the corresponding | |
2959 | inbound SA also is created, and it contains the selector values | |
2960 | derived from the SPD entry (and packet, if any PFP flags were | |
2961 | "true") used to create the inbound SA, for use in checking | |
2962 | inbound traffic delivered via the SA. | |
2963 | ||
2964 | 4. The packet is passed to the outbound forwarding function | |
2965 | (operating outside of the IPsec implementation), to select the | |
2966 | interface to which the packet will be directed. This function | |
2967 | ||
2968 | ||
2969 | ||
2970 | Kent & Seo Standards Track [Page 53] | |
2971 | \f | |
2972 | RFC 4301 Security Architecture for IP December 2005 | |
2973 | ||
2974 | ||
2975 | may cause the packet to be passed back across the IPsec boundary, | |
2976 | for additional IPsec processing, e.g., in support of nested SAs. | |
2977 | If so, there MUST be an entry in SPD-I database that permits | |
2978 | inbound bypassing of the packet, otherwise the packet will be | |
2979 | discarded. If necessary, i.e., if there is more than one SPD-I, | |
2980 | the traffic being looped back MAY be tagged as coming from this | |
2981 | internal interface. This would allow the use of a different | |
2982 | SPD-I for "real" external traffic vs. looped traffic, if needed. | |
2983 | ||
2984 | Note: With the exception of IPv4 and IPv6 transport mode, an SG, | |
2985 | BITS, or BITW implementation MAY fragment packets before applying | |
2986 | IPsec. (This applies only to IPv4. For IPv6 packets, only the | |
2987 | originator is allowed to fragment them.) The device SHOULD have a | |
2988 | configuration setting to disable this. The resulting fragments are | |
2989 | evaluated against the SPD in the normal manner. Thus, fragments not | |
2990 | containing port numbers (or ICMP message type and code, or Mobility | |
2991 | Header type) will only match rules having port (or ICMP message type | |
2992 | and code, or MH type) selectors of OPAQUE or ANY. (See Section 7 for | |
2993 | more details.) | |
2994 | ||
2995 | Note: With regard to determining and enforcing the PMTU of an SA, the | |
2996 | IPsec system MUST follow the steps described in Section 8.2. | |
2997 | ||
2998 | 5.1.1. Handling an Outbound Packet That Must Be Discarded | |
2999 | ||
3000 | If an IPsec system receives an outbound packet that it finds it must | |
3001 | discard, it SHOULD be capable of generating and sending an ICMP | |
3002 | message to indicate to the sender of the outbound packet that the | |
3003 | packet was discarded. The type and code of the ICMP message will | |
3004 | depend on the reason for discarding the packet, as specified below. | |
3005 | The reason SHOULD be recorded in the audit log. The audit log entry | |
3006 | for this event SHOULD include the reason, current date/time, and the | |
3007 | selector values from the packet. | |
3008 | ||
3009 | a. The selectors of the packet matched an SPD entry requiring the | |
3010 | packet to be discarded. | |
3011 | ||
3012 | IPv4 Type = 3 (destination unreachable) Code = 13 | |
3013 | (Communication Administratively Prohibited) | |
3014 | ||
3015 | IPv6 Type = 1 (destination unreachable) Code = 1 | |
3016 | (Communication with destination administratively | |
3017 | prohibited) | |
3018 | ||
3019 | b1. The IPsec system successfully reached the remote peer but was | |
3020 | unable to negotiate the SA required by the SPD entry matching the | |
3021 | packet because, for example, the remote peer is administratively | |
3022 | prohibited from communicating with the initiator, the initiating | |
3023 | ||
3024 | ||
3025 | ||
3026 | Kent & Seo Standards Track [Page 54] | |
3027 | \f | |
3028 | RFC 4301 Security Architecture for IP December 2005 | |
3029 | ||
3030 | ||
3031 | peer was unable to authenticate itself to the remote peer, the | |
3032 | remote peer was unable to authenticate itself to the initiating | |
3033 | peer, or the SPD at the remote peer did not have a suitable | |
3034 | entry. | |
3035 | ||
3036 | IPv4 Type = 3 (destination unreachable) Code = 13 | |
3037 | (Communication Administratively Prohibited) | |
3038 | ||
3039 | IPv6 Type = 1 (destination unreachable) Code = 1 | |
3040 | (Communication with destination administratively | |
3041 | prohibited) | |
3042 | ||
3043 | b2. The IPsec system was unable to set up the SA required by the SPD | |
3044 | entry matching the packet because the IPsec peer at the other end | |
3045 | of the exchange could not be contacted. | |
3046 | ||
3047 | IPv4 Type = 3 (destination unreachable) Code = 1 (host | |
3048 | unreachable) | |
3049 | ||
3050 | IPv6 Type = 1 (destination unreachable) Code = 3 (address | |
3051 | unreachable) | |
3052 | ||
3053 | Note that an attacker behind a security gateway could send packets | |
3054 | with a spoofed source address, W.X.Y.Z, to an IPsec entity causing it | |
3055 | to send ICMP messages to W.X.Y.Z. This creates an opportunity for a | |
3056 | denial of service (DoS) attack among hosts behind a security gateway. | |
3057 | To address this, a security gateway SHOULD include a management | |
3058 | control to allow an administrator to configure an IPsec | |
3059 | implementation to send or not send the ICMP messages under these | |
3060 | circumstances, and if this facility is selected, to rate limit the | |
3061 | transmission of such ICMP responses. | |
3062 | ||
3063 | 5.1.2. Header Construction for Tunnel Mode | |
3064 | ||
3065 | This section describes the handling of the inner and outer IP | |
3066 | headers, extension headers, and options for AH and ESP tunnels, with | |
3067 | regard to outbound traffic processing. This includes how to | |
3068 | construct the encapsulating (outer) IP header, how to process fields | |
3069 | in the inner IP header, and what other actions should be taken for | |
3070 | outbound, tunnel mode traffic. The general processing described here | |
3071 | is modeled after RFC 2003, "IP Encapsulation within IP" [Per96]: | |
3072 | ||
3073 | o The outer IP header Source Address and Destination Address | |
3074 | identify the "endpoints" of the tunnel (the encapsulator and | |
3075 | decapsulator). The inner IP header Source Address and Destination | |
3076 | Addresses identify the original sender and recipient of the | |
3077 | datagram (from the perspective of this tunnel), respectively. | |
3078 | ||
3079 | ||
3080 | ||
3081 | ||
3082 | Kent & Seo Standards Track [Page 55] | |
3083 | \f | |
3084 | RFC 4301 Security Architecture for IP December 2005 | |
3085 | ||
3086 | ||
3087 | (See footnote 3 after the table in 5.1.2.1 for more details on the | |
3088 | encapsulating source IP address.) | |
3089 | ||
3090 | o The inner IP header is not changed except as noted below for TTL | |
3091 | (or Hop Limit) and the DS/ECN Fields. The inner IP header | |
3092 | otherwise remains unchanged during its delivery to the tunnel exit | |
3093 | point. | |
3094 | ||
3095 | o No change to IP options or extension headers in the inner header | |
3096 | occurs during delivery of the encapsulated datagram through the | |
3097 | tunnel. | |
3098 | ||
3099 | Note: IPsec tunnel mode is different from IP-in-IP tunneling (RFC | |
3100 | 2003 [Per96]) in several ways: | |
3101 | ||
3102 | o IPsec offers certain controls to a security administrator to | |
3103 | manage covert channels (which would not normally be a concern for | |
3104 | tunneling) and to ensure that the receiver examines the right | |
3105 | portions of the received packet with respect to application of | |
3106 | access controls. An IPsec implementation MAY be configurable with | |
3107 | regard to how it processes the outer DS field for tunnel mode for | |
3108 | transmitted packets. For outbound traffic, one configuration | |
3109 | setting for the outer DS field will operate as described in the | |
3110 | following sections on IPv4 and IPv6 header processing for IPsec | |
3111 | tunnels. Another will allow the outer DS field to be mapped to a | |
3112 | fixed value, which MAY be configured on a per-SA basis. (The value | |
3113 | might really be fixed for all traffic outbound from a device, but | |
3114 | per-SA granularity allows that as well.) This configuration option | |
3115 | allows a local administrator to decide whether the covert channel | |
3116 | provided by copying these bits outweighs the benefits of copying. | |
3117 | ||
3118 | o IPsec describes how to handle ECN or DS and provides the ability | |
3119 | to control propagation of changes in these fields between | |
3120 | unprotected and protected domains. In general, propagation from a | |
3121 | protected to an unprotected domain is a covert channel and thus | |
3122 | controls are provided to manage the bandwidth of this channel. | |
3123 | Propagation of ECN values in the other direction are controlled so | |
3124 | that only legitimate ECN changes (indicating occurrence of | |
3125 | congestion between the tunnel endpoints) are propagated. By | |
3126 | default, DS propagation from an unprotected domain to a protected | |
3127 | domain is not permitted. However, if the sender and receiver do | |
3128 | not share the same DS code space, and the receiver has no way of | |
3129 | learning how to map between the two spaces, then it may be | |
3130 | appropriate to deviate from the default. Specifically, an IPsec | |
3131 | implementation MAY be configurable in terms of how it processes | |
3132 | the outer DS field for tunnel mode for received packets. It may | |
3133 | be configured to either discard the outer DS value (the default) | |
3134 | OR to overwrite the inner DS field with the outer DS field. If | |
3135 | ||
3136 | ||
3137 | ||
3138 | Kent & Seo Standards Track [Page 56] | |
3139 | \f | |
3140 | RFC 4301 Security Architecture for IP December 2005 | |
3141 | ||
3142 | ||
3143 | offered, the discard vs. overwrite behavior MAY be configured on a | |
3144 | per-SA basis. This configuration option allows a local | |
3145 | administrator to decide whether the vulnerabilities created by | |
3146 | copying these bits outweigh the benefits of copying. See | |
3147 | [RFC2983] for further information on when each of these behaviors | |
3148 | may be useful, and also for the possible need for diffserv traffic | |
3149 | conditioning prior or subsequent to IPsec processing (including | |
3150 | tunnel decapsulation). | |
3151 | ||
3152 | o IPsec allows the IP version of the encapsulating header to be | |
3153 | different from that of the inner header. | |
3154 | ||
3155 | The tables in the following sub-sections show the handling for the | |
3156 | different header/option fields ("constructed" means that the value in | |
3157 | the outer field is constructed independently of the value in the | |
3158 | inner). | |
3159 | ||
3160 | 5.1.2.1. IPv4: Header Construction for Tunnel Mode | |
3161 | ||
3162 | <-- How Outer Hdr Relates to Inner Hdr --> | |
3163 | Outer Hdr at Inner Hdr at | |
3164 | IPv4 Encapsulator Decapsulator | |
3165 | Header fields: -------------------- ------------ | |
3166 | version 4 (1) no change | |
3167 | header length constructed no change | |
3168 | DS Field copied from inner hdr (5) no change | |
3169 | ECN Field copied from inner hdr constructed (6) | |
3170 | total length constructed no change | |
3171 | ID constructed no change | |
3172 | flags (DF,MF) constructed, DF (4) no change | |
3173 | fragment offset constructed no change | |
3174 | TTL constructed (2) decrement (2) | |
3175 | protocol AH, ESP no change | |
3176 | checksum constructed constructed (2)(6) | |
3177 | src address constructed (3) no change | |
3178 | dest address constructed (3) no change | |
3179 | Options never copied no change | |
3180 | ||
3181 | Notes: | |
3182 | ||
3183 | (1) The IP version in the encapsulating header can be different | |
3184 | from the value in the inner header. | |
3185 | ||
3186 | (2) The TTL in the inner header is decremented by the encapsulator | |
3187 | prior to forwarding and by the decapsulator if it forwards the | |
3188 | packet. (The IPv4 checksum changes when the TTL changes.) | |
3189 | ||
3190 | ||
3191 | ||
3192 | ||
3193 | ||
3194 | Kent & Seo Standards Track [Page 57] | |
3195 | \f | |
3196 | RFC 4301 Security Architecture for IP December 2005 | |
3197 | ||
3198 | ||
3199 | Note: Decrementing the TTL value is a normal part of | |
3200 | forwarding a packet. Thus, a packet originating from the same | |
3201 | node as the encapsulator does not have its TTL decremented, | |
3202 | since the sending node is originating the packet rather than | |
3203 | forwarding it. This applies to BITS and native IPsec | |
3204 | implementations in hosts and routers. However, the IPsec | |
3205 | processing model includes an external forwarding capability. | |
3206 | TTL processing can be used to prevent looping of packets, | |
3207 | e.g., due to configuration errors, within the context of this | |
3208 | processing model. | |
3209 | ||
3210 | (3) Local and Remote addresses depend on the SA, which is used to | |
3211 | determine the Remote address, which in turn determines which | |
3212 | Local address (net interface) is used to forward the packet. | |
3213 | ||
3214 | Note: For multicast traffic, the destination address, or | |
3215 | source and destination addresses, may be required for | |
3216 | demuxing. In that case, it is important to ensure consistency | |
3217 | over the lifetime of the SA by ensuring that the source | |
3218 | address that appears in the encapsulating tunnel header is the | |
3219 | same as the one that was negotiated during the SA | |
3220 | establishment process. There is an exception to this general | |
3221 | rule, i.e., a mobile IPsec implementation will update its | |
3222 | source address as it moves. | |
3223 | ||
3224 | (4) Configuration determines whether to copy from the inner header | |
3225 | (IPv4 only), clear, or set the DF. | |
3226 | ||
3227 | (5) If the packet will immediately enter a domain for which the | |
3228 | DSCP value in the outer header is not appropriate, that value | |
3229 | MUST be mapped to an appropriate value for the domain | |
3230 | [NiBlBaBL98]. See RFC 2475 [BBCDWW98] for further | |
3231 | information. | |
3232 | ||
3233 | (6) If the ECN field in the inner header is set to ECT(0) or | |
3234 | ECT(1), where ECT is ECN-Capable Transport (ECT), and if the | |
3235 | ECN field in the outer header is set to Congestion Experienced | |
3236 | (CE), then set the ECN field in the inner header to CE; | |
3237 | otherwise, make no change to the ECN field in the inner | |
3238 | header. (The IPv4 checksum changes when the ECN changes.) | |
3239 | ||
3240 | Note: IPsec does not copy the options from the inner header into the | |
3241 | outer header, nor does IPsec construct the options in the outer | |
3242 | header. However, post-IPsec code MAY insert/construct options for | |
3243 | the outer header. | |
3244 | ||
3245 | ||
3246 | ||
3247 | ||
3248 | ||
3249 | ||
3250 | Kent & Seo Standards Track [Page 58] | |
3251 | \f | |
3252 | RFC 4301 Security Architecture for IP December 2005 | |
3253 | ||
3254 | ||
3255 | 5.1.2.2. IPv6: Header Construction for Tunnel Mode | |
3256 | ||
3257 | <-- How Outer Hdr Relates Inner Hdr ---> | |
3258 | Outer Hdr at Inner Hdr at | |
3259 | IPv6 Encapsulator Decapsulator | |
3260 | Header fields: -------------------- ------------ | |
3261 | version 6 (1) no change | |
3262 | DS Field copied from inner hdr (5) no change (9) | |
3263 | ECN Field copied from inner hdr constructed (6) | |
3264 | flow label copied or configured (8) no change | |
3265 | payload length constructed no change | |
3266 | next header AH,ESP,routing hdr no change | |
3267 | hop limit constructed (2) decrement (2) | |
3268 | src address constructed (3) no change | |
3269 | dest address constructed (3) no change | |
3270 | Extension headers never copied (7) no change | |
3271 | ||
3272 | Notes: | |
3273 | ||
3274 | (1) - (6) See Section 5.1.2.1. | |
3275 | ||
3276 | (7) IPsec does not copy the extension headers from the inner | |
3277 | packet into outer headers, nor does IPsec construct extension | |
3278 | headers in the outer header. However, post-IPsec code MAY | |
3279 | insert/construct extension headers for the outer header. | |
3280 | ||
3281 | (8) See [RaCoCaDe04]. Copying is acceptable only for end systems, | |
3282 | not SGs. If an SG copied flow labels from the inner header to | |
3283 | the outer header, collisions might result. | |
3284 | ||
3285 | (9) An implementation MAY choose to provide a facility to pass the | |
3286 | DS value from the outer header to the inner header, on a per- | |
3287 | SA basis, for received tunnel mode packets. The motivation | |
3288 | for providing this feature is to accommodate situations in | |
3289 | which the DS code space at the receiver is different from that | |
3290 | of the sender and the receiver has no way of knowing how to | |
3291 | translate from the sender's space. There is a danger in | |
3292 | copying this value from the outer header to the inner header, | |
3293 | since it enables an attacker to modify the outer DSCP value in | |
3294 | a fashion that may adversely affect other traffic at the | |
3295 | receiver. Hence the default behavior for IPsec | |
3296 | implementations is NOT to permit such copying. | |
3297 | ||
3298 | 5.2. Processing Inbound IP Traffic (unprotected-to-protected) | |
3299 | ||
3300 | Inbound processing is somewhat different from outbound processing, | |
3301 | because of the use of SPIs to map IPsec-protected traffic to SAs. | |
3302 | The inbound SPD cache (SPD-I) is applied only to bypassed or | |
3303 | ||
3304 | ||
3305 | ||
3306 | Kent & Seo Standards Track [Page 59] | |
3307 | \f | |
3308 | RFC 4301 Security Architecture for IP December 2005 | |
3309 | ||
3310 | ||
3311 | discarded traffic. If an arriving packet appears to be an IPsec | |
3312 | fragment from an unprotected interface, reassembly is performed prior | |
3313 | to IPsec processing. The intent for any SPD cache is that a packet | |
3314 | that fails to match any entry is then referred to the corresponding | |
3315 | SPD. Every SPD SHOULD have a nominal, final entry that catches | |
3316 | anything that is otherwise unmatched, and discards it. This ensures | |
3317 | that non-IPsec-protected traffic that arrives and does not match any | |
3318 | SPD-I entry will be discarded. | |
3319 | ||
3320 | Unprotected Interface | |
3321 | | | |
3322 | V | |
3323 | +-----+ IPsec protected | |
3324 | ------------------->|Demux|-------------------+ | |
3325 | | +-----+ | | |
3326 | | | | | |
3327 | | Not IPsec | | | |
3328 | | | | | |
3329 | | V | | |
3330 | | +-------+ +---------+ | | |
3331 | | |DISCARD|<---|SPD-I (*)| | | |
3332 | | +-------+ +---------+ | | |
3333 | | | | | |
3334 | | |-----+ | | |
3335 | | | | | | |
3336 | | | V | | |
3337 | | | +------+ | | |
3338 | | | | ICMP | | | |
3339 | | | +------+ | | |
3340 | | | V | |
3341 | +---------+ | +-----------+ | |
3342 | ....|SPD-O (*)|............|...................|PROCESS(**)|...IPsec | |
3343 | +---------+ | | (AH/ESP) | Boundary | |
3344 | ^ | +-----------+ | |
3345 | | | +---+ | | |
3346 | | BYPASS | +-->|IKE| | | |
3347 | | | | +---+ | | |
3348 | | V | V | |
3349 | | +----------+ +---------+ +----+ | |
3350 | |--------<------|Forwarding|<---------|SAD Check|-->|ICMP| | |
3351 | nested SAs +----------+ | (***) | +----+ | |
3352 | | +---------+ | |
3353 | V | |
3354 | Protected Interface | |
3355 | ||
3356 | Figure 3. Processing Model for Inbound Traffic | |
3357 | ||
3358 | ||
3359 | ||
3360 | ||
3361 | ||
3362 | Kent & Seo Standards Track [Page 60] | |
3363 | \f | |
3364 | RFC 4301 Security Architecture for IP December 2005 | |
3365 | ||
3366 | ||
3367 | (*) = The caches are shown here. If there is | |
3368 | a cache miss, then the SPD is checked. | |
3369 | There is no requirement that an | |
3370 | implementation buffer the packet if | |
3371 | there is a cache miss. | |
3372 | (**) = This processing includes using the | |
3373 | packet's SPI, etc., to look up the SA | |
3374 | in the SAD, which forms a cache of the | |
3375 | SPD for inbound packets (except for | |
3376 | cases noted in Sections 4.4.2 and 5). | |
3377 | See step 3a below. | |
3378 | (***) = This SAD check refers to step 4 below. | |
3379 | ||
3380 | Prior to performing AH or ESP processing, any IP fragments that | |
3381 | arrive via the unprotected interface are reassembled (by IP). Each | |
3382 | inbound IP datagram to which IPsec processing will be applied is | |
3383 | identified by the appearance of the AH or ESP values in the IP Next | |
3384 | Protocol field (or of AH or ESP as a next layer protocol in the IPv6 | |
3385 | context). | |
3386 | ||
3387 | IPsec MUST perform the following steps: | |
3388 | ||
3389 | 1. When a packet arrives, it may be tagged with the ID of the | |
3390 | interface (physical or virtual) via which it arrived, if | |
3391 | necessary, to support multiple SPDs and associated SPD-I caches. | |
3392 | (The interface ID is mapped to a corresponding SPD-ID.) | |
3393 | ||
3394 | 2. The packet is examined and demuxed into one of two categories: | |
3395 | - If the packet appears to be IPsec protected and it is addressed | |
3396 | to this device, an attempt is made to map it to an active SA | |
3397 | via the SAD. Note that the device may have multiple IP | |
3398 | addresses that may be used in the SAD lookup, e.g., in the case | |
3399 | of protocols such as SCTP. | |
3400 | - Traffic not addressed to this device, or addressed to this | |
3401 | device and not AH or ESP, is directed to SPD-I lookup. (This | |
3402 | implies that IKE traffic MUST have an explicit BYPASS entry in | |
3403 | the SPD.) If multiple SPDs are employed, the tag assigned to | |
3404 | the packet in step 1 is used to select the appropriate SPD-I | |
3405 | (and cache) to search. SPD-I lookup determines whether the | |
3406 | action is DISCARD or BYPASS. | |
3407 | ||
3408 | 3a. If the packet is addressed to the IPsec device and AH or ESP is | |
3409 | specified as the protocol, the packet is looked up in the SAD. | |
3410 | For unicast traffic, use only the SPI (or SPI plus protocol). | |
3411 | For multicast traffic, use the SPI plus the destination or SPI | |
3412 | plus destination and source addresses, as specified in Section | |
3413 | 4.1. In either case (unicast or multicast), if there is no match, | |
3414 | discard the traffic. This is an auditable event. The audit log | |
3415 | ||
3416 | ||
3417 | ||
3418 | Kent & Seo Standards Track [Page 61] | |
3419 | \f | |
3420 | RFC 4301 Security Architecture for IP December 2005 | |
3421 | ||
3422 | ||
3423 | entry for this event SHOULD include the current date/time, SPI, | |
3424 | source and destination of the packet, IPsec protocol, and any | |
3425 | other selector values of the packet that are available. If the | |
3426 | packet is found in the SAD, process it accordingly (see step 4). | |
3427 | ||
3428 | 3b. If the packet is not addressed to the device or is addressed to | |
3429 | this device and is not AH or ESP, look up the packet header in | |
3430 | the (appropriate) SPD-I cache. If there is a match and the | |
3431 | packet is to be discarded or bypassed, do so. If there is no | |
3432 | cache match, look up the packet in the corresponding SPD-I and | |
3433 | create a cache entry as appropriate. (No SAs are created in | |
3434 | response to receipt of a packet that requires IPsec protection; | |
3435 | only BYPASS or DISCARD cache entries can be created this way.) If | |
3436 | there is no match, discard the traffic. This is an auditable | |
3437 | event. The audit log entry for this event SHOULD include the | |
3438 | current date/time, SPI if available, IPsec protocol if available, | |
3439 | source and destination of the packet, and any other selector | |
3440 | values of the packet that are available. | |
3441 | ||
3442 | 3c. Processing of ICMP messages is assumed to take place on the | |
3443 | unprotected side of the IPsec boundary. Unprotected ICMP | |
3444 | messages are examined and local policy is applied to determine | |
3445 | whether to accept or reject these messages and, if accepted, what | |
3446 | action to take as a result. For example, if an ICMP unreachable | |
3447 | message is received, the implementation must decide whether to | |
3448 | act on it, reject it, or act on it with constraints. (See Section | |
3449 | 6.) | |
3450 | ||
3451 | 4. Apply AH or ESP processing as specified, using the SAD entry | |
3452 | selected in step 3a above. Then match the packet against the | |
3453 | inbound selectors identified by the SAD entry to verify that the | |
3454 | received packet is appropriate for the SA via which it was | |
3455 | received. | |
3456 | ||
3457 | 5. If an IPsec system receives an inbound packet on an SA and the | |
3458 | packet's header fields are not consistent with the selectors for | |
3459 | the SA, it MUST discard the packet. This is an auditable event. | |
3460 | The audit log entry for this event SHOULD include the current | |
3461 | date/time, SPI, IPsec protocol(s), source and destination of the | |
3462 | packet, any other selector values of the packet that are | |
3463 | available, and the selector values from the relevant SAD entry. | |
3464 | The system SHOULD also be capable of generating and sending an | |
3465 | IKE notification of INVALID_SELECTORS to the sender (IPsec peer), | |
3466 | indicating that the received packet was discarded because of | |
3467 | failure to pass selector checks. | |
3468 | ||
3469 | ||
3470 | ||
3471 | ||
3472 | ||
3473 | ||
3474 | Kent & Seo Standards Track [Page 62] | |
3475 | \f | |
3476 | RFC 4301 Security Architecture for IP December 2005 | |
3477 | ||
3478 | ||
3479 | To minimize the impact of a DoS attack, or a mis-configured peer, the | |
3480 | IPsec system SHOULD include a management control to allow an | |
3481 | administrator to configure the IPsec implementation to send or not | |
3482 | send this IKE notification, and if this facility is selected, to rate | |
3483 | limit the transmission of such notifications. | |
3484 | ||
3485 | After traffic is bypassed or processed through IPsec, it is handed to | |
3486 | the inbound forwarding function for disposition. This function may | |
3487 | cause the packet to be sent (outbound) across the IPsec boundary for | |
3488 | additional inbound IPsec processing, e.g., in support of nested SAs. | |
3489 | If so, then as with ALL outbound traffic that is to be bypassed, the | |
3490 | packet MUST be matched against an SPD-O entry. Ultimately, the | |
3491 | packet should be forwarded to the destination host or process for | |
3492 | disposition. | |
3493 | ||
3494 | 6. ICMP Processing | |
3495 | ||
3496 | This section describes IPsec handling of ICMP traffic. There are two | |
3497 | categories of ICMP traffic: error messages (e.g., type = destination | |
3498 | unreachable) and non-error messages (e.g., type = echo). This | |
3499 | section applies exclusively to error messages. Disposition of | |
3500 | non-error, ICMP messages (that are not addressed to the IPsec | |
3501 | implementation itself) MUST be explicitly accounted for using SPD | |
3502 | entries. | |
3503 | ||
3504 | The discussion in this section applies to ICMPv6 as well as to | |
3505 | ICMPv4. Also, a mechanism SHOULD be provided to allow an | |
3506 | administrator to cause ICMP error messages (selected, all, or none) | |
3507 | to be logged as an aid to problem diagnosis. | |
3508 | ||
3509 | 6.1. Processing ICMP Error Messages Directed to an IPsec Implementation | |
3510 | ||
3511 | 6.1.1. ICMP Error Messages Received on the Unprotected Side of the | |
3512 | Boundary | |
3513 | ||
3514 | Figure 3 in Section 5.2 shows a distinct ICMP processing module on | |
3515 | the unprotected side of the IPsec boundary, for processing ICMP | |
3516 | messages (error or otherwise) that are addressed to the IPsec device | |
3517 | and that are not protected via AH or ESP. An ICMP message of this | |
3518 | sort is unauthenticated, and its processing may result in denial or | |
3519 | degradation of service. This suggests that, in general, it would be | |
3520 | desirable to ignore such messages. However, many ICMP messages will | |
3521 | be received by hosts or security gateways from unauthenticated | |
3522 | sources, e.g., routers in the public Internet. Ignoring these ICMP | |
3523 | messages can degrade service, e.g., because of a failure to process | |
3524 | PMTU message and redirection messages. Thus, there is also a | |
3525 | motivation for accepting and acting upon unauthenticated ICMP | |
3526 | messages. | |
3527 | ||
3528 | ||
3529 | ||
3530 | Kent & Seo Standards Track [Page 63] | |
3531 | \f | |
3532 | RFC 4301 Security Architecture for IP December 2005 | |
3533 | ||
3534 | ||
3535 | To accommodate both ends of this spectrum, a compliant IPsec | |
3536 | implementation MUST permit a local administrator to configure an | |
3537 | IPsec implementation to accept or reject unauthenticated ICMP | |
3538 | traffic. This control MUST be at the granularity of ICMP type and | |
3539 | MAY be at the granularity of ICMP type and code. Additionally, an | |
3540 | implementation SHOULD incorporate mechanisms and parameters for | |
3541 | dealing with such traffic. For example, there could be the ability | |
3542 | to establish a minimum PMTU for traffic (on a per destination basis), | |
3543 | to prevent receipt of an unauthenticated ICMP from setting the PMTU | |
3544 | to a trivial size. | |
3545 | ||
3546 | If an ICMP PMTU message passes the checks above and the system is | |
3547 | configured to accept it, then there are two possibilities. If the | |
3548 | implementation applies fragmentation on the ciphertext side of the | |
3549 | boundary, then the accepted PMTU information is passed to the | |
3550 | forwarding module (outside of the IPsec implementation), which uses | |
3551 | it to manage outbound packet fragmentation. If the implementation is | |
3552 | configured to effect plaintext side fragmentation, then the PMTU | |
3553 | information is passed to the plaintext side and processed as | |
3554 | described in Section 8.2. | |
3555 | ||
3556 | 6.1.2. ICMP Error Messages Received on the Protected Side of the | |
3557 | Boundary | |
3558 | ||
3559 | These ICMP messages are not authenticated, but they do come from | |
3560 | sources on the protected side of the IPsec boundary. Thus, these | |
3561 | messages generally are viewed as more "trustworthy" than their | |
3562 | counterparts arriving from sources on the unprotected side of the | |
3563 | boundary. The major security concern here is that a compromised host | |
3564 | or router might emit erroneous ICMP error messages that could degrade | |
3565 | service for other devices "behind" the security gateway, or that | |
3566 | could even result in violations of confidentiality. For example, if | |
3567 | a bogus ICMP redirect were consumed by a security gateway, it could | |
3568 | cause the forwarding table on the protected side of the boundary to | |
3569 | be modified so as to deliver traffic to an inappropriate destination | |
3570 | "behind" the gateway. Thus, implementers MUST provide controls to | |
3571 | allow local administrators to constrain the processing of ICMP error | |
3572 | messages received on the protected side of the boundary, and directed | |
3573 | to the IPsec implementation. These controls are of the same type as | |
3574 | those employed on the unprotected side, described above in Section | |
3575 | 6.1.1. | |
3576 | ||
3577 | 6.2. Processing Protected, Transit ICMP Error Messages | |
3578 | ||
3579 | When an ICMP error message is transmitted via an SA to a device | |
3580 | "behind" an IPsec implementation, both the payload and the header of | |
3581 | the ICMP message require checking from an access control perspective. | |
3582 | If one of these messages is forwarded to a host behind a security | |
3583 | ||
3584 | ||
3585 | ||
3586 | Kent & Seo Standards Track [Page 64] | |
3587 | \f | |
3588 | RFC 4301 Security Architecture for IP December 2005 | |
3589 | ||
3590 | ||
3591 | gateway, the receiving host IP implementation will make decisions | |
3592 | based on the payload, i.e., the header of the packet that purportedly | |
3593 | triggered the error response. Thus, an IPsec implementation MUST be | |
3594 | configurable to check that this payload header information is | |
3595 | consistent with the SA via which it arrives. (This means that the | |
3596 | payload header, with source and destination address and port fields | |
3597 | reversed, matches the traffic selectors for the SA.) If this sort of | |
3598 | check is not performed, then, for example, anyone with whom the | |
3599 | receiving IPsec system (A) has an active SA could send an ICMP | |
3600 | Destination Unreachable message that refers to any host/net with | |
3601 | which A is currently communicating, and thus effect a highly | |
3602 | efficient DoS attack regarding communication with other peers of A. | |
3603 | Normal IPsec receiver processing of traffic is not sufficient to | |
3604 | protect against such attacks. However, not all contexts may require | |
3605 | such checks, so it is also necessary to allow a local administrator | |
3606 | to configure an implementation to NOT perform such checks. | |
3607 | ||
3608 | To accommodate both policies, the following convention is adopted. | |
3609 | If an administrator wants to allow ICMP error messages to be carried | |
3610 | by an SA without inspection of the payload, then configure an SPD | |
3611 | entry that explicitly allows for carriage of such traffic. If an | |
3612 | administrator wants IPsec to check the payload of ICMP error messages | |
3613 | for consistency, then do not create any SPD entries that accommodate | |
3614 | carriage of such traffic based on the ICMP packet header. This | |
3615 | convention motivates the following processing description. | |
3616 | ||
3617 | IPsec senders and receivers MUST support the following processing for | |
3618 | ICMP error messages that are sent and received via SAs. | |
3619 | ||
3620 | If an SA exists that accommodates an outbound ICMP error message, | |
3621 | then the message is mapped to the SA and only the IP and ICMP headers | |
3622 | are checked upon receipt, just as would be the case for other | |
3623 | traffic. If no SA exists that matches the traffic selectors | |
3624 | associated with an ICMP error message, then the SPD is searched to | |
3625 | determine if such an SA can be created. If so, the SA is created and | |
3626 | the ICMP error message is transmitted via that SA. Upon receipt, | |
3627 | this message is subject to the usual traffic selector checks at the | |
3628 | receiver. This processing is exactly what would happen for traffic | |
3629 | in general, and thus does not represent any special processing for | |
3630 | ICMP error messages. | |
3631 | ||
3632 | If no SA exists that would carry the outbound ICMP message in | |
3633 | question, and if no SPD entry would allow carriage of this outbound | |
3634 | ICMP error message, then an IPsec implementation MUST map the message | |
3635 | to the SA that would carry the return traffic associated with the | |
3636 | packet that triggered the ICMP error message. This requires an IPsec | |
3637 | implementation to detect outbound ICMP error messages that map to no | |
3638 | extant SA or SPD entry, and treat them specially with regard to SA | |
3639 | ||
3640 | ||
3641 | ||
3642 | Kent & Seo Standards Track [Page 65] | |
3643 | \f | |
3644 | RFC 4301 Security Architecture for IP December 2005 | |
3645 | ||
3646 | ||
3647 | creation and lookup. The implementation extracts the header for the | |
3648 | packet that triggered the error (from the ICMP message payload), | |
3649 | reverses the source and destination IP address fields, extracts the | |
3650 | protocol field, and reverses the port fields (if accessible). It | |
3651 | then uses this extracted information to locate an appropriate, active | |
3652 | outbound SA, and transmits the error message via this SA. If no such | |
3653 | SA exists, no SA will be created, and this is an auditable event. | |
3654 | ||
3655 | If an IPsec implementation receives an inbound ICMP error message on | |
3656 | an SA, and the IP and ICMP headers of the message do not match the | |
3657 | traffic selectors for the SA, the receiver MUST process the received | |
3658 | message in a special fashion. Specifically, the receiver must | |
3659 | extract the header of the triggering packet from the ICMP payload, | |
3660 | and reverse fields as described above to determine if the packet is | |
3661 | consistent with the selectors for the SA via which the ICMP error | |
3662 | message was received. If the packet fails this check, the IPsec | |
3663 | implementation MUST NOT forwarded the ICMP message to the | |
3664 | destination. This is an auditable event. | |
3665 | ||
3666 | 7. Handling Fragments (on the protected side of the IPsec boundary) | |
3667 | ||
3668 | Earlier sections of this document describe mechanisms for (a) | |
3669 | fragmenting an outbound packet after IPsec processing has been | |
3670 | applied and reassembling it at the receiver before IPsec processing | |
3671 | and (b) handling inbound fragments received from the unprotected side | |
3672 | of the IPsec boundary. This section describes how an implementation | |
3673 | should handle the processing of outbound plaintext fragments on the | |
3674 | protected side of the IPsec boundary. (See Appendix D, "Fragment | |
3675 | Handling Rationale".) In particular, it addresses: | |
3676 | ||
3677 | o mapping an outbound non-initial fragment to the right SA | |
3678 | (or finding the right SPD entry) | |
3679 | o verifying that a received non-initial fragment is | |
3680 | authorized for the SA via which it was received | |
3681 | o mapping outbound and inbound non-initial fragments to the | |
3682 | right SPD-O/SPD-I entry or the relevant cache entry, for | |
3683 | BYPASS/DISCARD traffic | |
3684 | ||
3685 | Note: In Section 4.1, transport mode SAs have been defined to not | |
3686 | carry fragments (IPv4 or IPv6). Note also that in Section 4.4.1, two | |
3687 | special values, ANY and OPAQUE, were defined for selectors and that | |
3688 | ANY includes OPAQUE. The term "non-trivial" is used to mean that the | |
3689 | selector has a value other than OPAQUE or ANY. | |
3690 | ||
3691 | Note: The term "non-initial fragment" is used here to indicate a | |
3692 | fragment that does not contain all the selector values that may be | |
3693 | needed for access control. As observed in Section 4.4.1, depending | |
3694 | on the Next Layer Protocol, in addition to Ports, the ICMP message | |
3695 | ||
3696 | ||
3697 | ||
3698 | Kent & Seo Standards Track [Page 66] | |
3699 | \f | |
3700 | RFC 4301 Security Architecture for IP December 2005 | |
3701 | ||
3702 | ||
3703 | type/code or Mobility Header type could be missing from non-initial | |
3704 | fragments. Also, for IPv6, even the first fragment might NOT contain | |
3705 | the Next Layer Protocol or Ports (or ICMP message type/code, or | |
3706 | Mobility Header type) depending on the kind and number of extension | |
3707 | headers present. If a non-initial fragment contains the Port (or | |
3708 | ICMP type and code or Mobility Header type) but not the Next Layer | |
3709 | Protocol, then unless there is an SPD entry for the relevant | |
3710 | Local/Remote addresses with ANY for Next Layer Protocol and Port (or | |
3711 | ICMP type and code or Mobility Header type), the fragment would not | |
3712 | contain all the selector information needed for access control. | |
3713 | ||
3714 | To address the above issues, three approaches have been defined: | |
3715 | ||
3716 | o Tunnel mode SAs that carry initial and non-initial fragments | |
3717 | (See Section 7.1.) | |
3718 | o Separate tunnel mode SAs for non-initial fragments (See | |
3719 | Section 7.2.) | |
3720 | o Stateful fragment checking (See Section 7.3.) | |
3721 | ||
3722 | 7.1. Tunnel Mode SAs that Carry Initial and Non-Initial Fragments | |
3723 | ||
3724 | All implementations MUST support tunnel mode SAs that are configured | |
3725 | to pass traffic without regard to port field (or ICMP type/code or | |
3726 | Mobility Header type) values. If the SA will carry traffic for | |
3727 | specified protocols, the selector set for the SA MUST specify the | |
3728 | port fields (or ICMP type/code or Mobility Header type) as ANY. An | |
3729 | SA defined in this fashion will carry all traffic including initial | |
3730 | and non-initial fragments for the indicated Local/Remote addresses | |
3731 | and specified Next Layer protocol(s). If the SA will carry traffic | |
3732 | without regard to a specific protocol value (i.e., ANY is specified | |
3733 | as the (Next Layer) protocol selector value), then the port field | |
3734 | values are undefined and MUST be set to ANY as well. (As noted in | |
3735 | 4.4.1, ANY includes OPAQUE as well as all specific values.) | |
3736 | ||
3737 | 7.2. Separate Tunnel Mode SAs for Non-Initial Fragments | |
3738 | ||
3739 | An implementation MAY support tunnel mode SAs that will carry only | |
3740 | non-initial fragments, separate from non-fragmented packets and | |
3741 | initial fragments. The OPAQUE value will be used to specify port (or | |
3742 | ICMP type/code or Mobility Header type) field selectors for an SA to | |
3743 | carry such fragments. Receivers MUST perform a minimum offset check | |
3744 | on IPv4 (non-initial) fragments to protect against overlapping | |
3745 | fragment attacks when SAs of this type are employed. Because such | |
3746 | checks cannot be performed on IPv6 non-initial fragments, users and | |
3747 | administrators are advised that carriage of such fragments may be | |
3748 | dangerous, and implementers may choose to NOT support such SAs for | |
3749 | IPv6 traffic. Also, an SA of this sort will carry all non-initial | |
3750 | fragments that match a specified Local/Remote address pair and | |
3751 | ||
3752 | ||
3753 | ||
3754 | Kent & Seo Standards Track [Page 67] | |
3755 | \f | |
3756 | RFC 4301 Security Architecture for IP December 2005 | |
3757 | ||
3758 | ||
3759 | protocol value, i.e., the fragments carried on this SA belong to | |
3760 | packets that if not fragmented, might have gone on separate SAs of | |
3761 | differing security. Therefore, users and administrators are advised | |
3762 | to protect such traffic using ESP (with integrity) and the | |
3763 | "strongest" integrity and encryption algorithms in use between both | |
3764 | peers. (Determination of the "strongest" algorithms requires | |
3765 | imposing an ordering of the available algorithms, a local | |
3766 | determination at the discretion of the initiator of the SA.) | |
3767 | ||
3768 | Specific port (or ICMP type/code or Mobility Header type) selector | |
3769 | values will be used to define SAs to carry initial fragments and | |
3770 | non-fragmented packets. This approach can be used if a user or | |
3771 | administrator wants to create one or more tunnel mode SAs between the | |
3772 | same Local/Remote addresses that discriminate based on port (or ICMP | |
3773 | type/code or Mobility Header type) fields. These SAs MUST have | |
3774 | non-trivial protocol selector values, otherwise approach #1 above | |
3775 | MUST be used. | |
3776 | ||
3777 | Note: In general, for the approach described in this section, one | |
3778 | needs only a single SA between two implementations to carry all | |
3779 | non-initial fragments. However, if one chooses to have multiple SAs | |
3780 | between the two implementations for QoS differentiation, then one | |
3781 | might also want multiple SAs to carry fragments-without-ports, one | |
3782 | for each supported QoS class. Since support for QoS via distinct SAs | |
3783 | is a local matter, not mandated by this document, the choice to have | |
3784 | multiple SAs to carry non-initial fragments should also be local. | |
3785 | ||
3786 | 7.3. Stateful Fragment Checking | |
3787 | ||
3788 | An implementation MAY support some form of stateful fragment checking | |
3789 | for a tunnel mode SA with non-trivial port (or ICMP type/code or MH | |
3790 | type) field values (not ANY or OPAQUE). Implementations that will | |
3791 | transmit non-initial fragments on a tunnel mode SA that makes use of | |
3792 | non-trivial port (or ICMP type/code or MH type) selectors MUST notify | |
3793 | a peer via the IKE NOTIFY NON_FIRST_FRAGMENTS_ALSO payload. | |
3794 | ||
3795 | The peer MUST reject this proposal if it will not accept non-initial | |
3796 | fragments in this context. If an implementation does not | |
3797 | successfully negotiate transmission of non-initial fragments for such | |
3798 | an SA, it MUST NOT send such fragments over the SA. This standard | |
3799 | does not specify how peers will deal with such fragments, e.g., via | |
3800 | reassembly or other means, at either sender or receiver. However, a | |
3801 | receiver MUST discard non-initial fragments that arrive on an SA with | |
3802 | non-trivial port (or ICMP type/code or MH type) selector values | |
3803 | unless this feature has been negotiated. Also, the receiver MUST | |
3804 | discard non-initial fragments that do not comply with the security | |
3805 | policy applied to the overall packet. Discarding such packets is an | |
3806 | auditable event. Note that in network configurations where fragments | |
3807 | ||
3808 | ||
3809 | ||
3810 | Kent & Seo Standards Track [Page 68] | |
3811 | \f | |
3812 | RFC 4301 Security Architecture for IP December 2005 | |
3813 | ||
3814 | ||
3815 | of a packet might be sent or received via different security gateways | |
3816 | or BITW implementations, stateful strategies for tracking fragments | |
3817 | may fail. | |
3818 | ||
3819 | 7.4. BYPASS/DISCARD Traffic | |
3820 | ||
3821 | All implementations MUST support DISCARDing of fragments using the | |
3822 | normal SPD packet classification mechanisms. All implementations | |
3823 | MUST support stateful fragment checking to accommodate BYPASS traffic | |
3824 | for which a non-trivial port range is specified. The concern is that | |
3825 | BYPASS of a cleartext, non-initial fragment arriving at an IPsec | |
3826 | implementation could undermine the security afforded IPsec-protected | |
3827 | traffic directed to the same destination. For example, consider an | |
3828 | IPsec implementation configured with an SPD entry that calls for | |
3829 | IPsec protection of traffic between a specific source/destination | |
3830 | address pair, and for a specific protocol and destination port, e.g., | |
3831 | TCP traffic on port 23 (Telnet). Assume that the implementation also | |
3832 | allows BYPASS of traffic from the same source/destination address | |
3833 | pair and protocol, but for a different destination port, e.g., port | |
3834 | 119 (NNTP). An attacker could send a non-initial fragment (with a | |
3835 | forged source address) that, if bypassed, could overlap with | |
3836 | IPsec-protected traffic from the same source and thus violate the | |
3837 | integrity of the IPsec-protected traffic. Requiring stateful | |
3838 | fragment checking for BYPASS entries with non-trivial port ranges | |
3839 | prevents attacks of this sort. As noted above, in network | |
3840 | configurations where fragments of a packet might be sent or received | |
3841 | via different security gateways or BITW implementations, stateful | |
3842 | strategies for tracking fragments may fail. | |
3843 | ||
3844 | 8. Path MTU/DF Processing | |
3845 | ||
3846 | The application of AH or ESP to an outbound packet increases the size | |
3847 | of a packet and thus may cause a packet to exceed the PMTU for the SA | |
3848 | via which the packet will travel. An IPsec implementation also may | |
3849 | receive an unprotected ICMP PMTU message and, if it chooses to act | |
3850 | upon the message, the result will affect outbound traffic processing. | |
3851 | This section describes the processing required of an IPsec | |
3852 | implementation to deal with these two PMTU issues. | |
3853 | ||
3854 | 8.1. DF Bit | |
3855 | ||
3856 | All IPsec implementations MUST support the option of copying the DF | |
3857 | bit from an outbound packet to the tunnel mode header that it emits, | |
3858 | when traffic is carried via a tunnel mode SA. This means that it | |
3859 | MUST be possible to configure the implementation's treatment of the | |
3860 | DF bit (set, clear, copy from inner header) for each SA. This | |
3861 | applies to SAs where both inner and outer headers are IPv4. | |
3862 | ||
3863 | ||
3864 | ||
3865 | ||
3866 | Kent & Seo Standards Track [Page 69] | |
3867 | \f | |
3868 | RFC 4301 Security Architecture for IP December 2005 | |
3869 | ||
3870 | ||
3871 | 8.2. Path MTU (PMTU) Discovery | |
3872 | ||
3873 | This section discusses IPsec handling for unprotected Path MTU | |
3874 | Discovery messages. ICMP PMTU is used here to refer to an ICMP | |
3875 | message for: | |
3876 | ||
3877 | IPv4 (RFC 792 [Pos81b]): | |
3878 | - Type = 3 (Destination Unreachable) | |
3879 | - Code = 4 (Fragmentation needed and DF set) | |
3880 | - Next-Hop MTU in the low-order 16 bits of the | |
3881 | second word of the ICMP header (labeled "unused" | |
3882 | in RFC 792), with high-order 16 bits set to zero) | |
3883 | ||
3884 | IPv6 (RFC 2463 [CD98]): | |
3885 | - Type = 2 (Packet Too Big) | |
3886 | - Code = 0 (Fragmentation needed) | |
3887 | - Next-Hop MTU in the 32-bit MTU field of the ICMP6 | |
3888 | message | |
3889 | ||
3890 | 8.2.1. Propagation of PMTU | |
3891 | ||
3892 | When an IPsec implementation receives an unauthenticated PMTU | |
3893 | message, and it is configured to process (vs. ignore) such messages, | |
3894 | it maps the message to the SA to which it corresponds. This mapping | |
3895 | is effected by extracting the header information from the payload of | |
3896 | the PMTU message and applying the procedure described in Section 5.2. | |
3897 | The PMTU determined by this message is used to update the SAD PMTU | |
3898 | field, taking into account the size of the AH or ESP header that will | |
3899 | be applied, any crypto synchronization data, and the overhead imposed | |
3900 | by an additional IP header, in the case of a tunnel mode SA. | |
3901 | ||
3902 | In a native host implementation, it is possible to maintain PMTU data | |
3903 | at the same granularity as for unprotected communication, so there is | |
3904 | no loss of functionality. Signaling of the PMTU information is | |
3905 | internal to the host. For all other IPsec implementation options, | |
3906 | the PMTU data must be propagated via a synthesized ICMP PMTU. In | |
3907 | these cases, the IPsec implementation SHOULD wait for outbound | |
3908 | traffic to be mapped to the SAD entry. When such traffic arrives, if | |
3909 | the traffic would exceed the updated PMTU value the traffic MUST be | |
3910 | handled as follows: | |
3911 | ||
3912 | Case 1: Original (cleartext) packet is IPv4 and has the DF | |
3913 | bit set. The implementation SHOULD discard the packet | |
3914 | and send a PMTU ICMP message. | |
3915 | ||
3916 | ||
3917 | ||
3918 | ||
3919 | ||
3920 | ||
3921 | ||
3922 | Kent & Seo Standards Track [Page 70] | |
3923 | \f | |
3924 | RFC 4301 Security Architecture for IP December 2005 | |
3925 | ||
3926 | ||
3927 | Case 2: Original (cleartext) packet is IPv4 and has the DF | |
3928 | bit clear. The implementation SHOULD fragment (before or | |
3929 | after encryption per its configuration) and then forward | |
3930 | the fragments. It SHOULD NOT send a PMTU ICMP message. | |
3931 | ||
3932 | Case 3: Original (cleartext) packet is IPv6. The implementation | |
3933 | SHOULD discard the packet and send a PMTU ICMP message. | |
3934 | ||
3935 | 8.2.2. PMTU Aging | |
3936 | ||
3937 | In all IPsec implementations, the PMTU associated with an SA MUST be | |
3938 | "aged" and some mechanism is required to update the PMTU in a timely | |
3939 | manner, especially for discovering if the PMTU is smaller than | |
3940 | required by current network conditions. A given PMTU has to remain | |
3941 | in place long enough for a packet to get from the source of the SA to | |
3942 | the peer, and to propagate an ICMP error message if the current PMTU | |
3943 | is too big. | |
3944 | ||
3945 | Implementations SHOULD use the approach described in the Path MTU | |
3946 | Discovery document (RFC 1191 [MD90], Section 6.3), which suggests | |
3947 | periodically resetting the PMTU to the first-hop data-link MTU and | |
3948 | then letting the normal PMTU Discovery processes update the PMTU as | |
3949 | necessary. The period SHOULD be configurable. | |
3950 | ||
3951 | 9. Auditing | |
3952 | ||
3953 | IPsec implementations are not required to support auditing. For the | |
3954 | most part, the granularity of auditing is a local matter. However, | |
3955 | several auditable events are identified in this document, and for | |
3956 | each of these events a minimum set of information that SHOULD be | |
3957 | included in an audit log is defined. Additional information also MAY | |
3958 | be included in the audit log for each of these events, and additional | |
3959 | events, not explicitly called out in this specification, also MAY | |
3960 | result in audit log entries. There is no requirement for the | |
3961 | receiver to transmit any message to the purported transmitter in | |
3962 | response to the detection of an auditable event, because of the | |
3963 | potential to induce denial of service via such action. | |
3964 | ||
3965 | 10. Conformance Requirements | |
3966 | ||
3967 | All IPv4 IPsec implementations MUST comply with all requirements of | |
3968 | this document. All IPv6 implementations MUST comply with all | |
3969 | requirements of this document. | |
3970 | ||
3971 | ||
3972 | ||
3973 | ||
3974 | ||
3975 | ||
3976 | ||
3977 | ||
3978 | Kent & Seo Standards Track [Page 71] | |
3979 | \f | |
3980 | RFC 4301 Security Architecture for IP December 2005 | |
3981 | ||
3982 | ||
3983 | 11. Security Considerations | |
3984 | ||
3985 | The focus of this document is security; hence security considerations | |
3986 | permeate this specification. | |
3987 | ||
3988 | IPsec imposes stringent constraints on bypass of IP header data in | |
3989 | both directions, across the IPsec barrier, especially when tunnel | |
3990 | mode SAs are employed. Some constraints are absolute, while others | |
3991 | are subject to local administrative controls, often on a per-SA | |
3992 | basis. For outbound traffic, these constraints are designed to limit | |
3993 | covert channel bandwidth. For inbound traffic, the constraints are | |
3994 | designed to prevent an adversary who has the ability to tamper with | |
3995 | one data stream (on the unprotected side of the IPsec barrier) from | |
3996 | adversely affecting other data streams (on the protected side of the | |
3997 | barrier). The discussion in Section 5 dealing with processing DSCP | |
3998 | values for tunnel mode SAs illustrates this concern. | |
3999 | ||
4000 | If an IPsec implementation is configured to pass ICMP error messages | |
4001 | over SAs based on the ICMP header values, without checking the header | |
4002 | information from the ICMP message payload, serious vulnerabilities | |
4003 | may arise. Consider a scenario in which several sites (A, B, and C) | |
4004 | are connected to one another via ESP-protected tunnels: A-B, A-C, and | |
4005 | B-C. Also assume that the traffic selectors for each tunnel specify | |
4006 | ANY for protocol and port fields and IP source/destination address | |
4007 | ranges that encompass the address range for the systems behind the | |
4008 | security gateways serving each site. This would allow a host at site | |
4009 | B to send an ICMP Destination Unreachable message to any host at site | |
4010 | A, that declares all hosts on the net at site C to be unreachable. | |
4011 | This is a very efficient DoS attack that could have been prevented if | |
4012 | the ICMP error messages were subjected to the checks that IPsec | |
4013 | provides, if the SPD is suitably configured, as described in Section | |
4014 | 6.2. | |
4015 | ||
4016 | 12. IANA Considerations | |
4017 | ||
4018 | The IANA has assigned the value (3) for the asn1-modules registry and | |
4019 | has assigned the object identifier 1.3.6.1.5.8.3.1 for the SPD | |
4020 | module. See Appendix C, "ASN.1 for an SPD Entry". | |
4021 | ||
4022 | 13. Differences from RFC 2401 | |
4023 | ||
4024 | This architecture document differs substantially from RFC 2401 | |
4025 | [RFC2401] in detail and in organization, but the fundamental notions | |
4026 | are unchanged. | |
4027 | ||
4028 | o The processing model has been revised to address new IPsec | |
4029 | scenarios, improve performance, and simplify implementation. This | |
4030 | includes a separation between forwarding (routing) and SPD | |
4031 | ||
4032 | ||
4033 | ||
4034 | Kent & Seo Standards Track [Page 72] | |
4035 | \f | |
4036 | RFC 4301 Security Architecture for IP December 2005 | |
4037 | ||
4038 | ||
4039 | selection, several SPD changes, and the addition of an outbound SPD | |
4040 | cache and an inbound SPD cache for bypassed or discarded traffic. | |
4041 | There is also a new database, the Peer Authorization Database | |
4042 | (PAD). This provides a link between an SA management protocol | |
4043 | (such as IKE) and the SPD. | |
4044 | ||
4045 | o There is no longer a requirement to support nested SAs or "SA | |
4046 | bundles". Instead this functionality can be achieved through SPD | |
4047 | and forwarding table configuration. An example of a configuration | |
4048 | has been added in Appendix E. | |
4049 | ||
4050 | o SPD entries were redefined to provide more flexibility. Each SPD | |
4051 | entry now consists of 1 to N sets of selectors, where each selector | |
4052 | set contains one protocol and a "list of ranges" can now be | |
4053 | specified for the Local IP address, Remote IP address, and whatever | |
4054 | fields (if any) are associated with the Next Layer Protocol (Local | |
4055 | Port, Remote Port, ICMP message type and code, and Mobility Header | |
4056 | type). An individual value for a selector is represented via a | |
4057 | trivial range and ANY is represented via a range than spans all | |
4058 | values for the selector. An example of an ASN.1 description is | |
4059 | included in Appendix C. | |
4060 | ||
4061 | o TOS (IPv4) and Traffic Class (IPv6) have been replaced by DSCP and | |
4062 | ECN. The tunnel section has been updated to explain how to handle | |
4063 | DSCP and ECN bits. | |
4064 | ||
4065 | o For tunnel mode SAs, an SG, BITS, or BITW implementation is now | |
4066 | allowed to fragment packets before applying IPsec. This applies | |
4067 | only to IPv4. For IPv6 packets, only the originator is allowed to | |
4068 | fragment them. | |
4069 | ||
4070 | o When security is desired between two intermediate systems along a | |
4071 | path or between an intermediate system and an end system, transport | |
4072 | mode may now be used between security gateways and between a | |
4073 | security gateway and a host. | |
4074 | ||
4075 | o This document clarifies that for all traffic that crosses the IPsec | |
4076 | boundary, including IPsec management traffic, the SPD or associated | |
4077 | caches must be consulted. | |
4078 | ||
4079 | o This document defines how to handle the situation of a security | |
4080 | gateway with multiple subscribers requiring separate IPsec | |
4081 | contexts. | |
4082 | ||
4083 | o A definition of reserved SPIs has been added. | |
4084 | ||
4085 | ||
4086 | ||
4087 | ||
4088 | ||
4089 | ||
4090 | Kent & Seo Standards Track [Page 73] | |
4091 | \f | |
4092 | RFC 4301 Security Architecture for IP December 2005 | |
4093 | ||
4094 | ||
4095 | o Text has been added explaining why ALL IP packets must be checked | |
4096 | -- IPsec includes minimal firewall functionality to support access | |
4097 | control at the IP layer. | |
4098 | ||
4099 | o The tunnel section has been updated to clarify how to handle the IP | |
4100 | options field and IPv6 extension headers when constructing the | |
4101 | outer header. | |
4102 | ||
4103 | o SA mapping for inbound traffic has been updated to be consistent | |
4104 | with the changes made in AH and ESP for support of unicast and | |
4105 | multicast SAs. | |
4106 | ||
4107 | o Guidance has been added regarding how to handle the covert channel | |
4108 | created in tunnel mode by copying the DSCP value to outer header. | |
4109 | ||
4110 | o Support for AH in both IPv4 and IPv6 is no longer required. | |
4111 | ||
4112 | o PMTU handling has been updated. The appendix on | |
4113 | PMTU/DF/Fragmentation has been deleted. | |
4114 | ||
4115 | o Three approaches have been added for handling plaintext fragments | |
4116 | on the protected side of the IPsec boundary. Appendix D documents | |
4117 | the rationale behind them. | |
4118 | ||
4119 | o Added revised text describing how to derive selector values for SAs | |
4120 | (from the SPD entry or from the packet, etc.) | |
4121 | ||
4122 | o Added a new table describing the relationship between selector | |
4123 | values in an SPD entry, the PFP flag, and resulting selector values | |
4124 | in the corresponding SAD entry. | |
4125 | ||
4126 | o Added Appendix B to describe decorrelation. | |
4127 | ||
4128 | o Added text describing how to handle an outbound packet that must be | |
4129 | discarded. | |
4130 | ||
4131 | o Added text describing how to handle a DISCARDED inbound packet, | |
4132 | i.e., one that does not match the SA upon which it arrived. | |
4133 | ||
4134 | o IPv6 mobility header has been added as a possible Next Layer | |
4135 | Protocol. IPv6 Mobility Header message type has been added as a | |
4136 | selector. | |
4137 | ||
4138 | o ICMP message type and code have been added as selectors. | |
4139 | ||
4140 | o The selector "data sensitivity level" has been removed to simplify | |
4141 | things. | |
4142 | ||
4143 | ||
4144 | ||
4145 | ||
4146 | Kent & Seo Standards Track [Page 74] | |
4147 | \f | |
4148 | RFC 4301 Security Architecture for IP December 2005 | |
4149 | ||
4150 | ||
4151 | o Updated text describing handling ICMP error messages. The appendix | |
4152 | on "Categorization of ICMP Messages" has been deleted. | |
4153 | ||
4154 | o The text for the selector name has been updated and clarified. | |
4155 | ||
4156 | o The "Next Layer Protocol" has been further explained and a default | |
4157 | list of protocols to skip when looking for the Next Layer Protocol | |
4158 | has been added. | |
4159 | ||
4160 | o The text has been amended to say that this document assumes use of | |
4161 | IKEv2 or an SA management protocol with comparable features. | |
4162 | ||
4163 | o Text has been added clarifying the algorithm for mapping inbound | |
4164 | IPsec datagrams to SAs in the presence of multicast SAs. | |
4165 | ||
4166 | o The appendix "Sequence Space Window Code Example" has been removed. | |
4167 | ||
4168 | o With respect to IP addresses and ports, the terms "Local" and | |
4169 | "Remote" are used for policy rules (replacing source and | |
4170 | destination). "Local" refers to the entity being protected by an | |
4171 | IPsec implementation, i.e., the "source" address/port of outbound | |
4172 | packets or the "destination" address/port of inbound packets. | |
4173 | "Remote" refers to a peer entity or peer entities. The terms | |
4174 | "source" and "destination" are still used for packet header fields. | |
4175 | ||
4176 | 14. Acknowledgements | |
4177 | ||
4178 | The authors would like to acknowledge the contributions of Ran | |
4179 | Atkinson, who played a critical role in initial IPsec activities, and | |
4180 | who authored the first series of IPsec standards: RFCs 1825-1827; and | |
4181 | Charlie Lynn, who made significant contributions to the second series | |
4182 | of IPsec standards (RFCs 2401, 2402, and 2406) and to the current | |
4183 | versions, especially with regard to IPv6 issues. The authors also | |
4184 | would like to thank the members of the IPsec and MSEC working groups | |
4185 | who have contributed to the development of this protocol | |
4186 | specification. | |
4187 | ||
4188 | ||
4189 | ||
4190 | ||
4191 | ||
4192 | ||
4193 | ||
4194 | ||
4195 | ||
4196 | ||
4197 | ||
4198 | ||
4199 | ||
4200 | ||
4201 | ||
4202 | Kent & Seo Standards Track [Page 75] | |
4203 | \f | |
4204 | RFC 4301 Security Architecture for IP December 2005 | |
4205 | ||
4206 | ||
4207 | Appendix A: Glossary | |
4208 | ||
4209 | This section provides definitions for several key terms that are | |
4210 | employed in this document. Other documents provide additional | |
4211 | definitions and background information relevant to this technology, | |
4212 | e.g., [Shi00], [VK83], and [HA94]. Included in this glossary are | |
4213 | generic security service and security mechanism terms, plus | |
4214 | IPsec-specific terms. | |
4215 | ||
4216 | Access Control | |
4217 | A security service that prevents unauthorized use of a resource, | |
4218 | including the prevention of use of a resource in an unauthorized | |
4219 | manner. In the IPsec context, the resource to which access is | |
4220 | being controlled is often: | |
4221 | ||
4222 | o for a host, computing cycles or data | |
4223 | o for a security gateway, a network behind the gateway | |
4224 | or bandwidth on that network. | |
4225 | ||
4226 | Anti-replay | |
4227 | See "Integrity" below. | |
4228 | ||
4229 | Authentication | |
4230 | Used informally to refer to the combination of two nominally | |
4231 | distinct security services, data origin authentication and | |
4232 | connectionless integrity. See the definitions below for each of | |
4233 | these services. | |
4234 | ||
4235 | Availability | |
4236 | When viewed as a security service, addresses the security concerns | |
4237 | engendered by attacks against networks that deny or degrade | |
4238 | service. For example, in the IPsec context, the use of | |
4239 | anti-replay mechanisms in AH and ESP support availability. | |
4240 | ||
4241 | Confidentiality | |
4242 | The security service that protects data from unauthorized | |
4243 | disclosure. The primary confidentiality concern in most instances | |
4244 | is unauthorized disclosure of application-level data, but | |
4245 | disclosure of the external characteristics of communication also | |
4246 | can be a concern in some circumstances. Traffic flow | |
4247 | confidentiality is the service that addresses this latter concern | |
4248 | by concealing source and destination addresses, message length, or | |
4249 | frequency of communication. In the IPsec context, using ESP in | |
4250 | tunnel mode, especially at a security gateway, can provide some | |
4251 | level of traffic flow confidentiality. (See also "Traffic | |
4252 | Analysis" below.) | |
4253 | ||
4254 | ||
4255 | ||
4256 | ||
4257 | ||
4258 | Kent & Seo Standards Track [Page 76] | |
4259 | \f | |
4260 | RFC 4301 Security Architecture for IP December 2005 | |
4261 | ||
4262 | ||
4263 | Data Origin Authentication | |
4264 | A security service that verifies the identity of the claimed | |
4265 | source of data. This service is usually bundled with | |
4266 | connectionless integrity service. | |
4267 | ||
4268 | Encryption | |
4269 | A security mechanism used to transform data from an intelligible | |
4270 | form (plaintext) into an unintelligible form (ciphertext), to | |
4271 | provide confidentiality. The inverse transformation process is | |
4272 | designated "decryption". Often the term "encryption" is used to | |
4273 | generically refer to both processes. | |
4274 | ||
4275 | Integrity | |
4276 | A security service that ensures that modifications to data are | |
4277 | detectable. Integrity comes in various flavors to match | |
4278 | application requirements. IPsec supports two forms of integrity: | |
4279 | connectionless and a form of partial sequence integrity. | |
4280 | Connectionless integrity is a service that detects modification of | |
4281 | an individual IP datagram, without regard to the ordering of the | |
4282 | datagram in a stream of traffic. The form of partial sequence | |
4283 | integrity offered in IPsec is referred to as anti-replay | |
4284 | integrity, and it detects arrival of duplicate IP datagrams | |
4285 | (within a constrained window). This is in contrast to | |
4286 | connection-oriented integrity, which imposes more stringent | |
4287 | sequencing requirements on traffic, e.g., to be able to detect | |
4288 | lost or re-ordered messages. Although authentication and | |
4289 | integrity services often are cited separately, in practice they | |
4290 | are intimately connected and almost always offered in tandem. | |
4291 | ||
4292 | Protected vs. Unprotected | |
4293 | "Protected" refers to the systems or interfaces that are inside | |
4294 | the IPsec protection boundary, and "unprotected" refers to the | |
4295 | systems or interfaces that are outside the IPsec protection | |
4296 | boundary. IPsec provides a boundary through which traffic passes. | |
4297 | There is an asymmetry to this barrier, which is reflected in the | |
4298 | processing model. Outbound data, if not discarded or bypassed, is | |
4299 | protected via the application of AH or ESP and the addition of the | |
4300 | corresponding headers. Inbound data, if not discarded or | |
4301 | bypassed, is processed via the removal of AH or ESP headers. In | |
4302 | this document, inbound traffic enters an IPsec implementation from | |
4303 | the "unprotected" interface. Outbound traffic enters the | |
4304 | implementation via the "protected" interface, or is internally | |
4305 | generated by the implementation on the "protected" side of the | |
4306 | boundary and directed toward the "unprotected" interface. An | |
4307 | IPsec implementation may support more than one interface on either | |
4308 | or both sides of the boundary. The protected interface may be | |
4309 | ||
4310 | ||
4311 | ||
4312 | ||
4313 | ||
4314 | Kent & Seo Standards Track [Page 77] | |
4315 | \f | |
4316 | RFC 4301 Security Architecture for IP December 2005 | |
4317 | ||
4318 | ||
4319 | internal, e.g., in a host implementation of IPsec. The protected | |
4320 | interface may link to a socket layer interface presented by the | |
4321 | OS. | |
4322 | ||
4323 | Security Association (SA) | |
4324 | A simplex (uni-directional) logical connection, created for | |
4325 | security purposes. All traffic traversing an SA is provided the | |
4326 | same security processing. In IPsec, an SA is an Internet-layer | |
4327 | abstraction implemented through the use of AH or ESP. State data | |
4328 | associated with an SA is represented in the SA Database (SAD). | |
4329 | ||
4330 | Security Gateway | |
4331 | An intermediate system that acts as the communications interface | |
4332 | between two networks. The set of hosts (and networks) on the | |
4333 | external side of the security gateway is termed unprotected (they | |
4334 | are generally at least less protected than those "behind" the SG), | |
4335 | while the networks and hosts on the internal side are viewed as | |
4336 | protected. The internal subnets and hosts served by a security | |
4337 | gateway are presumed to be trusted by virtue of sharing a common, | |
4338 | local, security administration. In the IPsec context, a security | |
4339 | gateway is a point at which AH and/or ESP is implemented in order | |
4340 | to serve a set of internal hosts, providing security services for | |
4341 | these hosts when they communicate with external hosts also | |
4342 | employing IPsec (either directly or via another security gateway). | |
4343 | ||
4344 | Security Parameters Index (SPI) | |
4345 | An arbitrary 32-bit value that is used by a receiver to identify | |
4346 | the SA to which an incoming packet should be bound. For a unicast | |
4347 | SA, the SPI can be used by itself to specify an SA, or it may be | |
4348 | used in conjunction with the IPsec protocol type. Additional IP | |
4349 | address information is used to identify multicast SAs. The SPI is | |
4350 | carried in AH and ESP protocols to enable the receiving system to | |
4351 | select the SA under which a received packet will be processed. An | |
4352 | SPI has only local significance, as defined by the creator of the | |
4353 | SA (usually the receiver of the packet carrying the SPI); thus an | |
4354 | SPI is generally viewed as an opaque bit string. However, the | |
4355 | creator of an SA may choose to interpret the bits in an SPI to | |
4356 | facilitate local processing. | |
4357 | ||
4358 | Traffic Analysis | |
4359 | The analysis of network traffic flow for the purpose of deducing | |
4360 | information that is useful to an adversary. Examples of such | |
4361 | information are frequency of transmission, the identities of the | |
4362 | conversing parties, sizes of packets, and flow identifiers | |
4363 | [Sch94]. | |
4364 | ||
4365 | ||
4366 | ||
4367 | ||
4368 | ||
4369 | ||
4370 | Kent & Seo Standards Track [Page 78] | |
4371 | \f | |
4372 | RFC 4301 Security Architecture for IP December 2005 | |
4373 | ||
4374 | ||
4375 | Appendix B: Decorrelation | |
4376 | ||
4377 | This appendix is based on work done for caching of policies in the IP | |
4378 | Security Policy Working Group by Luis Sanchez, Matt Condell, and John | |
4379 | Zao. | |
4380 | ||
4381 | Two SPD entries are correlated if there is a non-null intersection | |
4382 | between the values of corresponding selectors in each entry. Caching | |
4383 | correlated SPD entries can lead to incorrect policy enforcement. A | |
4384 | solution to this problem, which still allows for caching, is to | |
4385 | remove the ambiguities by decorrelating the entries. That is, the | |
4386 | SPD entries must be rewritten so that for every pair of entries there | |
4387 | exists a selector for which there is a null intersection between the | |
4388 | values in both of the entries. Once the entries are decorrelated, | |
4389 | there is no longer any ordering requirement on them, since only one | |
4390 | entry will match any lookup. The next section describes | |
4391 | decorrelation in more detail and presents an algorithm that may be | |
4392 | used to implement decorrelation. | |
4393 | ||
4394 | B.1. Decorrelation Algorithm | |
4395 | ||
4396 | The basic decorrelation algorithm takes each entry in a correlated | |
4397 | SPD and divides it into a set of entries using a tree structure. | |
4398 | The nodes of the tree are the selectors that may overlap between the | |
4399 | policies. At each node, the algorithm creates a branch for each of | |
4400 | the values of the selector. It also creates one branch for the | |
4401 | complement of the union of all selector values. Policies are then | |
4402 | formed by traversing the tree from the root to each leaf. The | |
4403 | policies at the leaves are compared to the set of already | |
4404 | decorrelated policy rules. Each policy at a leaf is either | |
4405 | completely overridden by a policy in the already decorrelated set and | |
4406 | is discarded or is decorrelated with all the policies in the | |
4407 | decorrelated set and is added to it. | |
4408 | ||
4409 | The basic algorithm does not guarantee an optimal set of decorrelated | |
4410 | entries. That is, the entries may be broken up into smaller sets | |
4411 | than is necessary, though they will still provide all the necessary | |
4412 | policy information. Some extensions to the basic algorithm are | |
4413 | described later to improve this and improve the performance of the | |
4414 | algorithm. | |
4415 | ||
4416 | C A set of ordered, correlated entries (a correlated SPD). | |
4417 | Ci The ith entry in C. | |
4418 | U The set of decorrelated entries being built from C. | |
4419 | Ui The ith entry in U. | |
4420 | Sik The kth selection for policy Ci. | |
4421 | Ai The action for policy Ci. | |
4422 | ||
4423 | ||
4424 | ||
4425 | ||
4426 | Kent & Seo Standards Track [Page 79] | |
4427 | \f | |
4428 | RFC 4301 Security Architecture for IP December 2005 | |
4429 | ||
4430 | ||
4431 | A policy (SPD entry) P may be expressed as a sequence of selector | |
4432 | values and an action (BYPASS, DISCARD, or PROTECT): | |
4433 | ||
4434 | Ci = Si1 x Si2 x ... x Sik -> Ai | |
4435 | ||
4436 | 1) Put C1 in set U as U1 | |
4437 | ||
4438 | For each policy Cj (j > 1) in C | |
4439 | ||
4440 | 2) If Cj is decorrelated with every entry in U, then add it to U. | |
4441 | ||
4442 | 3) If Cj is correlated with one or more entries in U, create a tree | |
4443 | rooted at the policy Cj that partitions Cj into a set of decorrelated | |
4444 | entries. The algorithm starts with a root node where no selectors | |
4445 | have yet been chosen. | |
4446 | ||
4447 | A) Choose a selector in Cj, Sjn, that has not yet been chosen when | |
4448 | traversing the tree from the root to this node. If there are no | |
4449 | selectors not yet used, continue to the next unfinished branch | |
4450 | until all branches have been completed. When the tree is | |
4451 | completed, go to step D. | |
4452 | ||
4453 | T is the set of entries in U that are correlated with the entry | |
4454 | at this node. | |
4455 | ||
4456 | The entry at this node is the entry formed by the selector | |
4457 | values of each of the branches between the root and this node. | |
4458 | Any selector values that are not yet represented by branches | |
4459 | assume the corresponding selector value in Cj, since the values | |
4460 | in Cj represent the maximum value for each selector. | |
4461 | ||
4462 | B) Add a branch to the tree for each value of the selector Sjn that | |
4463 | appears in any of the entries in T. (If the value is a superset | |
4464 | of the value of Sjn in Cj, then use the value in Cj, since that | |
4465 | value represents the universal set.) Also add a branch for the | |
4466 | complement of the union of all the values of the selector Sjn | |
4467 | in T. When taking the complement, remember that the universal | |
4468 | set is the value of Sjn in Cj. A branch need not be created | |
4469 | for the null set. | |
4470 | ||
4471 | C) Repeat A and B until the tree is completed. | |
4472 | ||
4473 | D) The entry to each leaf now represents an entry that is a subset | |
4474 | of Cj. The entries at the leaves completely partition Cj in | |
4475 | such a way that each entry is either completely overridden by | |
4476 | an entry in U, or is decorrelated with the entries in U. | |
4477 | ||
4478 | Add all the decorrelated entries at the leaves of the tree to U. | |
4479 | ||
4480 | ||
4481 | ||
4482 | Kent & Seo Standards Track [Page 80] | |
4483 | \f | |
4484 | RFC 4301 Security Architecture for IP December 2005 | |
4485 | ||
4486 | ||
4487 | 4) Get next Cj and go to 2. | |
4488 | ||
4489 | 5) When all entries in C have been processed, then U will contain an | |
4490 | decorrelated version of C. | |
4491 | ||
4492 | There are several optimizations that can be made to this algorithm. | |
4493 | A few of them are presented here. | |
4494 | ||
4495 | It is possible to optimize, or at least improve, the amount of | |
4496 | branching that occurs by carefully choosing the order of the | |
4497 | selectors used for the next branch. For example, if a selector Sjn | |
4498 | can be chosen so that all the values for that selector in T are equal | |
4499 | to or a superset of the value of Sjn in Cj, then only a single branch | |
4500 | needs to be created (since the complement will be null). | |
4501 | ||
4502 | Branches of the tree do not have to proceed with the entire | |
4503 | decorrelation algorithm. For example, if a node represents an entry | |
4504 | that is decorrelated with all the entries in U, then there is no | |
4505 | reason to continue decorrelating that branch. Also, if a branch is | |
4506 | completely overridden by an entry in U, then there is no reason to | |
4507 | continue decorrelating the branch. | |
4508 | ||
4509 | An additional optimization is to check to see if a branch is | |
4510 | overridden by one of the CORRELATED entries in set C that has already | |
4511 | been decorrelated. That is, if the branch is part of decorrelating | |
4512 | Cj, then check to see if it was overridden by an entry Cm, m < j. | |
4513 | This is a valid check, since all the entries Cm are already expressed | |
4514 | in U. | |
4515 | ||
4516 | Along with checking if an entry is already decorrelated in step 2, | |
4517 | check if Cj is overridden by any entry in U. If it is, skip it since | |
4518 | it is not relevant. An entry x is overridden by another entry y if | |
4519 | every selector in x is equal to or a subset of the corresponding | |
4520 | selector in entry y. | |
4521 | ||
4522 | ||
4523 | ||
4524 | ||
4525 | ||
4526 | ||
4527 | ||
4528 | ||
4529 | ||
4530 | ||
4531 | ||
4532 | ||
4533 | ||
4534 | ||
4535 | ||
4536 | ||
4537 | ||
4538 | Kent & Seo Standards Track [Page 81] | |
4539 | \f | |
4540 | RFC 4301 Security Architecture for IP December 2005 | |
4541 | ||
4542 | ||
4543 | Appendix C: ASN.1 for an SPD Entry | |
4544 | ||
4545 | This appendix is included as an additional way to describe SPD | |
4546 | entries, as defined in Section 4.4.1. It uses ASN.1 syntax that has | |
4547 | been successfully compiled. This syntax is merely illustrative and | |
4548 | need not be employed in an implementation to achieve compliance. The | |
4549 | SPD description in Section 4.4.1 is normative. | |
4550 | ||
4551 | SPDModule | |
4552 | ||
4553 | {iso(1) org (3) dod (6) internet (1) security (5) mechanisms (5) | |
4554 | ipsec (8) asn1-modules (3) spd-module (1) } | |
4555 | ||
4556 | DEFINITIONS IMPLICIT TAGS ::= | |
4557 | ||
4558 | BEGIN | |
4559 | ||
4560 | IMPORTS | |
4561 | RDNSequence FROM PKIX1Explicit88 | |
4562 | { iso(1) identified-organization(3) | |
4563 | dod(6) internet(1) security(5) mechanisms(5) pkix(7) | |
4564 | id-mod(0) id-pkix1-explicit(18) } ; | |
4565 | ||
4566 | -- An SPD is a list of policies in decreasing order of preference | |
4567 | SPD ::= SEQUENCE OF SPDEntry | |
4568 | ||
4569 | SPDEntry ::= CHOICE { | |
4570 | iPsecEntry IPsecEntry, -- PROTECT traffic | |
4571 | bypassOrDiscard [0] BypassOrDiscardEntry } -- DISCARD/BYPASS | |
4572 | ||
4573 | IPsecEntry ::= SEQUENCE { -- Each entry consists of | |
4574 | name NameSets OPTIONAL, | |
4575 | pFPs PacketFlags, -- Populate from packet flags | |
4576 | -- Applies to ALL of the corresponding | |
4577 | -- traffic selectors in the SelectorLists | |
4578 | condition SelectorLists, -- Policy "condition" | |
4579 | processing Processing -- Policy "action" | |
4580 | } | |
4581 | ||
4582 | BypassOrDiscardEntry ::= SEQUENCE { | |
4583 | bypass BOOLEAN, -- TRUE BYPASS, FALSE DISCARD | |
4584 | condition InOutBound } | |
4585 | ||
4586 | InOutBound ::= CHOICE { | |
4587 | outbound [0] SelectorLists, | |
4588 | inbound [1] SelectorLists, | |
4589 | bothways [2] BothWays } | |
4590 | ||
4591 | ||
4592 | ||
4593 | ||
4594 | Kent & Seo Standards Track [Page 82] | |
4595 | \f | |
4596 | RFC 4301 Security Architecture for IP December 2005 | |
4597 | ||
4598 | ||
4599 | BothWays ::= SEQUENCE { | |
4600 | inbound SelectorLists, | |
4601 | outbound SelectorLists } | |
4602 | ||
4603 | NameSets ::= SEQUENCE { | |
4604 | passed SET OF Names-R, -- Matched to IKE ID by | |
4605 | -- responder | |
4606 | local SET OF Names-I } -- Used internally by IKE | |
4607 | -- initiator | |
4608 | ||
4609 | Names-R ::= CHOICE { -- IKEv2 IDs | |
4610 | dName RDNSequence, -- ID_DER_ASN1_DN | |
4611 | fqdn FQDN, -- ID_FQDN | |
4612 | rfc822 [0] RFC822Name, -- ID_RFC822_ADDR | |
4613 | keyID OCTET STRING } -- KEY_ID | |
4614 | ||
4615 | Names-I ::= OCTET STRING -- Used internally by IKE | |
4616 | -- initiator | |
4617 | ||
4618 | FQDN ::= IA5String | |
4619 | ||
4620 | RFC822Name ::= IA5String | |
4621 | ||
4622 | PacketFlags ::= BIT STRING { | |
4623 | -- if set, take selector value from packet | |
4624 | -- establishing SA | |
4625 | -- else use value in SPD entry | |
4626 | localAddr (0), | |
4627 | remoteAddr (1), | |
4628 | protocol (2), | |
4629 | localPort (3), | |
4630 | remotePort (4) } | |
4631 | ||
4632 | SelectorLists ::= SET OF SelectorList | |
4633 | ||
4634 | SelectorList ::= SEQUENCE { | |
4635 | localAddr AddrList, | |
4636 | remoteAddr AddrList, | |
4637 | protocol ProtocolChoice } | |
4638 | ||
4639 | Processing ::= SEQUENCE { | |
4640 | extSeqNum BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit | |
4641 | seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit | |
4642 | fragCheck BOOLEAN, -- TRUE stateful fragment checking, | |
4643 | -- FALSE no stateful fragment checking | |
4644 | lifetime SALifetime, | |
4645 | spi ManualSPI, | |
4646 | algorithms ProcessingAlgs, | |
4647 | ||
4648 | ||
4649 | ||
4650 | Kent & Seo Standards Track [Page 83] | |
4651 | \f | |
4652 | RFC 4301 Security Architecture for IP December 2005 | |
4653 | ||
4654 | ||
4655 | tunnel TunnelOptions OPTIONAL } -- if absent, use | |
4656 | -- transport mode | |
4657 | ||
4658 | SALifetime ::= SEQUENCE { | |
4659 | seconds [0] INTEGER OPTIONAL, | |
4660 | bytes [1] INTEGER OPTIONAL } | |
4661 | ||
4662 | ManualSPI ::= SEQUENCE { | |
4663 | spi INTEGER, | |
4664 | keys KeyIDs } | |
4665 | ||
4666 | KeyIDs ::= SEQUENCE OF OCTET STRING | |
4667 | ||
4668 | ProcessingAlgs ::= CHOICE { | |
4669 | ah [0] IntegrityAlgs, -- AH | |
4670 | esp [1] ESPAlgs} -- ESP | |
4671 | ||
4672 | ESPAlgs ::= CHOICE { | |
4673 | integrity [0] IntegrityAlgs, -- integrity only | |
4674 | confidentiality [1] ConfidentialityAlgs, -- confidentiality | |
4675 | -- only | |
4676 | both [2] IntegrityConfidentialityAlgs, | |
4677 | combined [3] CombinedModeAlgs } | |
4678 | ||
4679 | IntegrityConfidentialityAlgs ::= SEQUENCE { | |
4680 | integrity IntegrityAlgs, | |
4681 | confidentiality ConfidentialityAlgs } | |
4682 | ||
4683 | -- Integrity Algorithms, ordered by decreasing preference | |
4684 | IntegrityAlgs ::= SEQUENCE OF IntegrityAlg | |
4685 | ||
4686 | -- Confidentiality Algorithms, ordered by decreasing preference | |
4687 | ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg | |
4688 | ||
4689 | -- Integrity Algorithms | |
4690 | IntegrityAlg ::= SEQUENCE { | |
4691 | algorithm IntegrityAlgType, | |
4692 | parameters ANY -- DEFINED BY algorithm -- OPTIONAL } | |
4693 | ||
4694 | IntegrityAlgType ::= INTEGER { | |
4695 | none (0), | |
4696 | auth-HMAC-MD5-96 (1), | |
4697 | auth-HMAC-SHA1-96 (2), | |
4698 | auth-DES-MAC (3), | |
4699 | auth-KPDK-MD5 (4), | |
4700 | auth-AES-XCBC-96 (5) | |
4701 | -- tbd (6..65535) | |
4702 | } | |
4703 | ||
4704 | ||
4705 | ||
4706 | Kent & Seo Standards Track [Page 84] | |
4707 | \f | |
4708 | RFC 4301 Security Architecture for IP December 2005 | |
4709 | ||
4710 | ||
4711 | -- Confidentiality Algorithms | |
4712 | ConfidentialityAlg ::= SEQUENCE { | |
4713 | algorithm ConfidentialityAlgType, | |
4714 | parameters ANY -- DEFINED BY algorithm -- OPTIONAL } | |
4715 | ||
4716 | ConfidentialityAlgType ::= INTEGER { | |
4717 | encr-DES-IV64 (1), | |
4718 | encr-DES (2), | |
4719 | encr-3DES (3), | |
4720 | encr-RC5 (4), | |
4721 | encr-IDEA (5), | |
4722 | encr-CAST (6), | |
4723 | encr-BLOWFISH (7), | |
4724 | encr-3IDEA (8), | |
4725 | encr-DES-IV32 (9), | |
4726 | encr-RC4 (10), | |
4727 | encr-NULL (11), | |
4728 | encr-AES-CBC (12), | |
4729 | encr-AES-CTR (13) | |
4730 | -- tbd (14..65535) | |
4731 | } | |
4732 | ||
4733 | CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg | |
4734 | ||
4735 | CombinedModeAlg ::= SEQUENCE { | |
4736 | algorithm CombinedModeType, | |
4737 | parameters ANY -- DEFINED BY algorithm} -- defined outside | |
4738 | -- of this document for AES modes. | |
4739 | ||
4740 | CombinedModeType ::= INTEGER { | |
4741 | comb-AES-CCM (1), | |
4742 | comb-AES-GCM (2) | |
4743 | -- tbd (3..65535) | |
4744 | } | |
4745 | ||
4746 | TunnelOptions ::= SEQUENCE { | |
4747 | dscp DSCP, | |
4748 | ecn BOOLEAN, -- TRUE Copy CE to inner header | |
4749 | df DF, | |
4750 | addresses TunnelAddresses } | |
4751 | ||
4752 | TunnelAddresses ::= CHOICE { | |
4753 | ipv4 IPv4Pair, | |
4754 | ipv6 [0] IPv6Pair } | |
4755 | ||
4756 | IPv4Pair ::= SEQUENCE { | |
4757 | local OCTET STRING (SIZE(4)), | |
4758 | remote OCTET STRING (SIZE(4)) } | |
4759 | ||
4760 | ||
4761 | ||
4762 | Kent & Seo Standards Track [Page 85] | |
4763 | \f | |
4764 | RFC 4301 Security Architecture for IP December 2005 | |
4765 | ||
4766 | ||
4767 | IPv6Pair ::= SEQUENCE { | |
4768 | local OCTET STRING (SIZE(16)), | |
4769 | remote OCTET STRING (SIZE(16)) } | |
4770 | ||
4771 | DSCP ::= SEQUENCE { | |
4772 | copy BOOLEAN, -- TRUE copy from inner header | |
4773 | -- FALSE do not copy | |
4774 | mapping OCTET STRING OPTIONAL} -- points to table | |
4775 | -- if no copy | |
4776 | ||
4777 | DF ::= INTEGER { | |
4778 | clear (0), | |
4779 | set (1), | |
4780 | copy (2) } | |
4781 | ||
4782 | ProtocolChoice::= CHOICE { | |
4783 | anyProt AnyProtocol, -- for ANY protocol | |
4784 | noNext [0] NoNextLayerProtocol, -- has no next layer | |
4785 | -- items | |
4786 | oneNext [1] OneNextLayerProtocol, -- has one next layer | |
4787 | -- item | |
4788 | twoNext [2] TwoNextLayerProtocol, -- has two next layer | |
4789 | -- items | |
4790 | fragment FragmentNoNext } -- has no next layer | |
4791 | -- info | |
4792 | ||
4793 | AnyProtocol ::= SEQUENCE { | |
4794 | id INTEGER (0), -- ANY protocol | |
4795 | nextLayer AnyNextLayers } | |
4796 | ||
4797 | AnyNextLayers ::= SEQUENCE { -- with either | |
4798 | first AnyNextLayer, -- ANY next layer selector | |
4799 | second AnyNextLayer } -- ANY next layer selector | |
4800 | ||
4801 | NoNextLayerProtocol ::= INTEGER (2..254) | |
4802 | ||
4803 | FragmentNoNext ::= INTEGER (44) -- Fragment identifier | |
4804 | ||
4805 | OneNextLayerProtocol ::= SEQUENCE { | |
4806 | id INTEGER (1..254), -- ICMP, MH, ICMPv6 | |
4807 | nextLayer NextLayerChoice } -- ICMP Type*256+Code | |
4808 | -- MH Type*256 | |
4809 | ||
4810 | TwoNextLayerProtocol ::= SEQUENCE { | |
4811 | id INTEGER (2..254), -- Protocol | |
4812 | local NextLayerChoice, -- Local and | |
4813 | remote NextLayerChoice } -- Remote ports | |
4814 | ||
4815 | ||
4816 | ||
4817 | ||
4818 | Kent & Seo Standards Track [Page 86] | |
4819 | \f | |
4820 | RFC 4301 Security Architecture for IP December 2005 | |
4821 | ||
4822 | ||
4823 | NextLayerChoice ::= CHOICE { | |
4824 | any AnyNextLayer, | |
4825 | opaque [0] OpaqueNextLayer, | |
4826 | range [1] NextLayerRange } | |
4827 | ||
4828 | -- Representation of ANY in next layer field | |
4829 | AnyNextLayer ::= SEQUENCE { | |
4830 | start INTEGER (0), | |
4831 | end INTEGER (65535) } | |
4832 | ||
4833 | -- Representation of OPAQUE in next layer field. | |
4834 | -- Matches IKE convention | |
4835 | OpaqueNextLayer ::= SEQUENCE { | |
4836 | start INTEGER (65535), | |
4837 | end INTEGER (0) } | |
4838 | ||
4839 | -- Range for a next layer field | |
4840 | NextLayerRange ::= SEQUENCE { | |
4841 | start INTEGER (0..65535), | |
4842 | end INTEGER (0..65535) } | |
4843 | ||
4844 | -- List of IP addresses | |
4845 | AddrList ::= SEQUENCE { | |
4846 | v4List IPv4List OPTIONAL, | |
4847 | v6List [0] IPv6List OPTIONAL } | |
4848 | ||
4849 | -- IPv4 address representations | |
4850 | IPv4List ::= SEQUENCE OF IPv4Range | |
4851 | ||
4852 | IPv4Range ::= SEQUENCE { -- close, but not quite right ... | |
4853 | ipv4Start OCTET STRING (SIZE (4)), | |
4854 | ipv4End OCTET STRING (SIZE (4)) } | |
4855 | ||
4856 | -- IPv6 address representations | |
4857 | IPv6List ::= SEQUENCE OF IPv6Range | |
4858 | ||
4859 | IPv6Range ::= SEQUENCE { -- close, but not quite right ... | |
4860 | ipv6Start OCTET STRING (SIZE (16)), | |
4861 | ipv6End OCTET STRING (SIZE (16)) } | |
4862 | ||
4863 | END | |
4864 | ||
4865 | ||
4866 | ||
4867 | ||
4868 | ||
4869 | ||
4870 | ||
4871 | ||
4872 | ||
4873 | ||
4874 | Kent & Seo Standards Track [Page 87] | |
4875 | \f | |
4876 | RFC 4301 Security Architecture for IP December 2005 | |
4877 | ||
4878 | ||
4879 | Appendix D: Fragment Handling Rationale | |
4880 | ||
4881 | There are three issues that must be resolved regarding processing of | |
4882 | (plaintext) fragments in IPsec: | |
4883 | ||
4884 | - mapping a non-initial, outbound fragment to the right SA | |
4885 | (or finding the right SPD entry) | |
4886 | - verifying that a received, non-initial fragment is authorized | |
4887 | for the SA via which it is received | |
4888 | - mapping outbound and inbound non-initial fragments to the | |
4889 | right SPD/cache entry, for BYPASS/DISCARD traffic | |
4890 | ||
4891 | The first and third issues arise because we need a deterministic | |
4892 | algorithm for mapping traffic to SAs (and SPD/cache entries). All | |
4893 | three issues are important because we want to make sure that | |
4894 | non-initial fragments that cross the IPsec boundary do not cause the | |
4895 | access control policies in place at the receiver (or transmitter) to | |
4896 | be violated. | |
4897 | ||
4898 | D.1. Transport Mode and Fragments | |
4899 | ||
4900 | First, we note that transport mode SAs have been defined to not carry | |
4901 | fragments. This is a carryover from RFC 2401, where transport mode | |
4902 | SAs always terminated at endpoints. This is a fundamental | |
4903 | requirement because, in the worst case, an IPv4 fragment to which | |
4904 | IPsec was applied might then be fragmented (as a ciphertext packet), | |
4905 | en route to the destination. IP fragment reassembly procedures at | |
4906 | the IPsec receiver would not be able to distinguish between pre-IPsec | |
4907 | fragments and fragments created after IPsec processing. | |
4908 | ||
4909 | For IPv6, only the sender is allowed to fragment a packet. As for | |
4910 | IPv4, an IPsec implementation is allowed to fragment tunnel mode | |
4911 | packets after IPsec processing, because it is the sender relative to | |
4912 | the (outer) tunnel header. However, unlike IPv4, it would be | |
4913 | feasible to carry a plaintext fragment on a transport mode SA, | |
4914 | because the fragment header in IPv6 would appear after the AH or ESP | |
4915 | header, and thus would not cause confusion at the receiver with | |
4916 | respect to reassembly. Specifically, the receiver would not attempt | |
4917 | reassembly for the fragment until after IPsec processing. To keep | |
4918 | things simple, this specification prohibits carriage of fragments on | |
4919 | transport mode SAs for IPv6 traffic. | |
4920 | ||
4921 | When only end systems used transport mode SAs, the prohibition on | |
4922 | carriage of fragments was not a problem, since we assumed that the | |
4923 | end system could be configured to not offer a fragment to IPsec. For | |
4924 | a native host implementation, this seems reasonable, and, as someone | |
4925 | already noted, RFC 2401 warned that a BITS implementation might have | |
4926 | to reassemble fragments before performing an SA lookup. (It would | |
4927 | ||
4928 | ||
4929 | ||
4930 | Kent & Seo Standards Track [Page 88] | |
4931 | \f | |
4932 | RFC 4301 Security Architecture for IP December 2005 | |
4933 | ||
4934 | ||
4935 | then apply AH or ESP and could re-fragment the packet after IPsec | |
4936 | processing.) Because a BITS implementation is assumed to be able to | |
4937 | have access to all traffic emanating from its host, even if the host | |
4938 | has multiple interfaces, this was deemed a reasonable mandate. | |
4939 | ||
4940 | In this specification, it is acceptable to use transport mode in | |
4941 | cases where the IPsec implementation is not the ultimate destination, | |
4942 | e.g., between two SGs. In principle, this creates a new opportunity | |
4943 | for outbound, plaintext fragments to be mapped to a transport mode SA | |
4944 | for IPsec processing. However, in these new contexts in which a | |
4945 | transport mode SA is now approved for use, it seems likely that we | |
4946 | can continue to prohibit transmission of fragments, as seen by IPsec, | |
4947 | i.e., packets that have an "outer header" with a non-zero fragment | |
4948 | offset field. For example, in an IP overlay network, packets being | |
4949 | sent over transport mode SAs are IP-in-IP tunneled and thus have the | |
4950 | necessary inner header to accommodate fragmentation prior to IPsec | |
4951 | processing. When carried via a transport mode SA, IPsec would not | |
4952 | examine the inner IP header for such traffic, and thus would not | |
4953 | consider the packet to be a fragment. | |
4954 | ||
4955 | D.2. Tunnel Mode and Fragments | |
4956 | ||
4957 | For tunnel mode SAs, it has always been the case that outbound | |
4958 | fragments might arrive for processing at an IPsec implementation. | |
4959 | The need to accommodate fragmented outbound packets can pose a | |
4960 | problem because a non-initial fragment generally will not contain the | |
4961 | port fields associated with a next layer protocol such as TCP, UDP, | |
4962 | or SCTP. Thus, depending on the SPD configuration for a given IPsec | |
4963 | implementation, plaintext fragments might or might not pose a | |
4964 | problem. | |
4965 | ||
4966 | For example, if the SPD requires that all traffic between two address | |
4967 | ranges is offered IPsec protection (no BYPASS or DISCARD SPD entries | |
4968 | apply to this address range), then it should be easy to carry | |
4969 | non-initial fragments on the SA defined for this address range, since | |
4970 | the SPD entry implies an intent to carry ALL traffic between the | |
4971 | address ranges. But, if there are multiple SPD entries that could | |
4972 | match a fragment, and if these entries reference different subsets of | |
4973 | port fields (vs. ANY), then it is not possible to map an outbound | |
4974 | non-initial fragment to the right entry, unambiguously. (If we choose | |
4975 | to allow carriage of fragments on transport mode SAs for IPv6, the | |
4976 | problems arises in that context as well.) | |
4977 | ||
4978 | This problem largely, though not exclusively, motivated the | |
4979 | definition of OPAQUE as a selector value for port fields in RFC 2401. | |
4980 | The other motivation for OPAQUE is the observation that port fields | |
4981 | might not be accessible due to the prior application of IPsec. For | |
4982 | example, if a host applied IPsec to its traffic and that traffic | |
4983 | ||
4984 | ||
4985 | ||
4986 | Kent & Seo Standards Track [Page 89] | |
4987 | \f | |
4988 | RFC 4301 Security Architecture for IP December 2005 | |
4989 | ||
4990 | ||
4991 | arrived at an SG, these fields would be encrypted. The algorithm | |
4992 | specified for locating the "next layer protocol" described in RFC | |
4993 | 2401 also motivated use of OPAQUE to accommodate an encrypted next | |
4994 | layer protocol field in such circumstances. Nonetheless, the primary | |
4995 | use of the OPAQUE value was to match traffic selector fields in | |
4996 | packets that did not contain port fields (non-initial fragments), or | |
4997 | packets in which the port fields were already encrypted (as a result | |
4998 | of nested application of IPsec). RFC 2401 was ambiguous in | |
4999 | discussing the use of OPAQUE vs. ANY, suggesting in some places that | |
5000 | ANY might be an alternative to OPAQUE. | |
5001 | ||
5002 | We gain additional access control capability by defining both ANY and | |
5003 | OPAQUE values. OPAQUE can be defined to match only fields that are | |
5004 | not accessible. We could define ANY as the complement of OPAQUE, | |
5005 | i.e., it would match all values but only for accessible port fields. | |
5006 | We have therefore simplified the procedure employed to locate the | |
5007 | next layer protocol in this document, so that we treat ESP and AH as | |
5008 | next layer protocols. As a result, the notion of an encrypted next | |
5009 | layer protocol field has vanished, and there is also no need to worry | |
5010 | about encrypted port fields either. And accordingly, OPAQUE will be | |
5011 | applicable only to non-initial fragments. | |
5012 | ||
5013 | Since we have adopted the definitions above for ANY and OPAQUE, we | |
5014 | need to clarify how these values work when the specified protocol | |
5015 | does not have port fields, and when ANY is used for the protocol | |
5016 | selector. Accordingly, if a specific protocol value is used as a | |
5017 | selector, and if that protocol has no port fields, then the port | |
5018 | field selectors are to be ignored and ANY MUST be specified as the | |
5019 | value for the port fields. (In this context, ICMP TYPE and CODE | |
5020 | values are lumped together as a single port field (for IKEv2 | |
5021 | negotiation), as is the IPv6 Mobility Header TYPE value.) If the | |
5022 | protocol selector is ANY, then this should be treated as equivalent | |
5023 | to specifying a protocol for which no port fields are defined, and | |
5024 | thus the port selectors should be ignored, and MUST be set to ANY. | |
5025 | ||
5026 | D.3. The Problem of Non-Initial Fragments | |
5027 | ||
5028 | For an SG implementation, it is obvious that fragments might arrive | |
5029 | from end systems behind the SG. A BITW implementation also may | |
5030 | encounter fragments from a host or gateway behind it. (As noted | |
5031 | earlier, native host implementations and BITS implementations | |
5032 | probably can avoid the problems described below.) In the worst case, | |
5033 | fragments from a packet might arrive at distinct BITW or SG | |
5034 | instantiations and thus preclude reassembly as a solution option. | |
5035 | Hence, in RFC 2401 we adopted a general requirement that fragments | |
5036 | must be accommodated in tunnel mode for all implementations. However, | |
5037 | ||
5038 | ||
5039 | ||
5040 | ||
5041 | ||
5042 | Kent & Seo Standards Track [Page 90] | |
5043 | \f | |
5044 | RFC 4301 Security Architecture for IP December 2005 | |
5045 | ||
5046 | ||
5047 | RFC 2401 did not provide a perfect solution. The use of OPAQUE as a | |
5048 | selector value for port fields (a SHOULD in RFC 2401) allowed an SA | |
5049 | to carry non-initial fragments. | |
5050 | ||
5051 | Using the features defined in RFC 2401, if one defined an SA between | |
5052 | two IPsec (SG or BITW) implementations using the OPAQUE value for | |
5053 | both port fields, then all non-initial fragments matching the | |
5054 | source/destination (S/D) address and protocol values for the SA would | |
5055 | be mapped to that SA. Initial fragments would NOT map to this SA, if | |
5056 | we adopt a strict definition of OPAQUE. However, RFC 2401 did not | |
5057 | provide detailed guidance on this and thus it may not have been | |
5058 | apparent that use of this feature would essentially create a | |
5059 | "non-initial fragment only" SA. | |
5060 | ||
5061 | In the course of discussing the "fragment-only" SA approach, it was | |
5062 | noted that some subtle problems, problems not considered in RFC 2401, | |
5063 | would have to be avoided. For example, an SA of this sort must be | |
5064 | configured to offer the "highest quality" security services for any | |
5065 | traffic between the indicated S/D addresses (for the specified | |
5066 | protocol). This is necessary to ensure that any traffic captured by | |
5067 | the fragment-only SA is not offered degraded security relative to | |
5068 | what it would have been offered if the packet were not fragmented. A | |
5069 | possible problem here is that we may not be able to identify the | |
5070 | "highest quality" security services defined for use between two IPsec | |
5071 | implementation, since the choice of security protocols, options, and | |
5072 | algorithms is a lattice, not a totally ordered set. (We might safely | |
5073 | say that BYPASS < AH < ESP w/integrity, but it gets complicated if we | |
5074 | have multiple ESP encryption or integrity algorithm options.) So, one | |
5075 | has to impose a total ordering on these security parameters to make | |
5076 | this work, but this can be done locally. | |
5077 | ||
5078 | However, this conservative strategy has a possible performance | |
5079 | downside. If most traffic traversing an IPsec implementation for a | |
5080 | given S/D address pair (and specified protocol) is bypassed, then a | |
5081 | fragment-only SA for that address pair might cause a dramatic | |
5082 | increase in the volume of traffic afforded crypto processing. If the | |
5083 | crypto implementation cannot support high traffic rates, this could | |
5084 | cause problems. (An IPsec implementation that is capable of line rate | |
5085 | or near line rate crypto performance would not be adversely affected | |
5086 | by this SA configuration approach. Nonetheless, the performance | |
5087 | impact is a potential concern, specific to implementation | |
5088 | capabilities.) | |
5089 | ||
5090 | Another concern is that non-initial fragments sent over a dedicated | |
5091 | SA might be used to effect overlapping reassembly attacks, when | |
5092 | combined with an apparently acceptable initial fragment. (This sort | |
5093 | of attack assumes creation of bogus fragments and is not a side | |
5094 | effect of normal fragmentation.) This concern is easily addressed in | |
5095 | ||
5096 | ||
5097 | ||
5098 | Kent & Seo Standards Track [Page 91] | |
5099 | \f | |
5100 | RFC 4301 Security Architecture for IP December 2005 | |
5101 | ||
5102 | ||
5103 | IPv4, by checking the fragment offset value to ensure that no | |
5104 | non-initial fragments have a small enough offset to overlap port | |
5105 | fields that should be contained in the initial fragment. Recall that | |
5106 | the IPv4 MTU minimum is 576 bytes, and the max IP header length is 60 | |
5107 | bytes, so any ports should be present in the initial fragment. If we | |
5108 | require all non-initial fragments to have an offset of, say, 128 or | |
5109 | greater, just to be on the safe side, this should prevent successful | |
5110 | attacks of this sort. If the intent is only to protect against this | |
5111 | sort of reassembly attack, this check need be implemented only by a | |
5112 | receiver. | |
5113 | ||
5114 | IPv6 also has a fragment offset, carried in the fragmentation | |
5115 | extension header. However, IPv6 extension headers are variable in | |
5116 | length and there is no analogous max header length value that we can | |
5117 | use to check non-initial fragments, to reject ones that might be used | |
5118 | for an attack of the sort noted above. A receiver would need to | |
5119 | maintain state analogous to reassembly state, to provide equivalent | |
5120 | protection. So, only for IPv4 is it feasible to impose a fragment | |
5121 | offset check that would reject attacks designed to circumvent port | |
5122 | field checks by IPsec (or firewalls) when passing non-initial | |
5123 | fragments. | |
5124 | ||
5125 | Another possible concern is that in some topologies and SPD | |
5126 | configurations this approach might result in an access control | |
5127 | surprise. The notion is that if we create an SA to carry ALL | |
5128 | (non-initial) fragments, then that SA would carry some traffic that | |
5129 | might otherwise arrive as plaintext via a separate path, e.g., a path | |
5130 | monitored by a proxy firewall. But, this concern arises only if the | |
5131 | other path allows initial fragments to traverse it without requiring | |
5132 | reassembly, presumably a bad idea for a proxy firewall. Nonetheless, | |
5133 | this does represent a potential problem in some topologies and under | |
5134 | certain assumptions with respect to SPD and (other) firewall rule | |
5135 | sets, and administrators need to be warned of this possibility. | |
5136 | ||
5137 | A less serious concern is that non-initial fragments sent over a | |
5138 | non-initial fragment-only SA might represent a DoS opportunity, in | |
5139 | that they could be sent when no valid, initial fragment will ever | |
5140 | arrive. This might be used to attack hosts behind an SG or BITW | |
5141 | device. However, the incremental risk posed by this sort of attack, | |
5142 | which can be mounted only by hosts behind an SG or BITW device, seems | |
5143 | small. | |
5144 | ||
5145 | If we interpret the ANY selector value as encompassing OPAQUE, then a | |
5146 | single SA with ANY values for both port fields would be able to | |
5147 | accommodate all traffic matching the S/D address and protocol traffic | |
5148 | selectors, an alternative to using the OPAQUE value. But, using ANY | |
5149 | ||
5150 | ||
5151 | ||
5152 | ||
5153 | ||
5154 | Kent & Seo Standards Track [Page 92] | |
5155 | \f | |
5156 | RFC 4301 Security Architecture for IP December 2005 | |
5157 | ||
5158 | ||
5159 | here precludes multiple, distinct SAs between the same IPsec | |
5160 | implementations for the same address pairs and protocol. So, it is | |
5161 | not an exactly equivalent alternative. | |
5162 | ||
5163 | Fundamentally, fragment handling problems arise only when more than | |
5164 | one SA is defined with the same S/D address and protocol selector | |
5165 | values, but with different port field selector values. | |
5166 | ||
5167 | D.4. BYPASS/DISCARD Traffic | |
5168 | ||
5169 | We also have to address the non-initial fragment processing issue for | |
5170 | BYPASS/DISCARD entries, independent of SA processing. This is | |
5171 | largely a local matter for two reasons: | |
5172 | ||
5173 | 1) We have no means for coordinating SPD entries for such | |
5174 | traffic between IPsec implementations since IKE is not | |
5175 | invoked. | |
5176 | 2) Many of these entries refer to traffic that is NOT | |
5177 | directed to or received from a location that is using | |
5178 | IPsec. So there is no peer IPsec implementation with | |
5179 | which to coordinate via any means. | |
5180 | ||
5181 | However, this document should provide guidance here, consistent with | |
5182 | our goal of offering a well-defined, access control function for all | |
5183 | traffic, relative to the IPsec boundary. To that end, this document | |
5184 | says that implementations MUST support fragment reassembly for | |
5185 | BYPASS/DISCARD traffic when port fields are specified. An | |
5186 | implementation also MUST permit a user or administrator to accept | |
5187 | such traffic or reject such traffic using the SPD conventions | |
5188 | described in Section 4.4.1. The concern is that BYPASS of a | |
5189 | cleartext, non-initial fragment arriving at an IPsec implementation | |
5190 | could undermine the security afforded IPsec-protected traffic | |
5191 | directed to the same destination. For example, consider an IPsec | |
5192 | implementation configured with an SPD entry that calls for | |
5193 | IPsec-protection of traffic between a specific source/destination | |
5194 | address pair, and for a specific protocol and destination port, e.g., | |
5195 | TCP traffic on port 23 (Telnet). Assume that the implementation also | |
5196 | allows BYPASS of traffic from the same source/destination address | |
5197 | pair and protocol, but for a different destination port, e.g., port | |
5198 | 119 (NNTP). An attacker could send a non-initial fragment (with a | |
5199 | forged source address) that, if bypassed, could overlap with | |
5200 | IPsec-protected traffic from the same source and thus violate the | |
5201 | integrity of the IPsec-protected traffic. Requiring stateful | |
5202 | fragment checking for BYPASS entries with non-trivial port ranges | |
5203 | prevents attacks of this sort. | |
5204 | ||
5205 | ||
5206 | ||
5207 | ||
5208 | ||
5209 | ||
5210 | Kent & Seo Standards Track [Page 93] | |
5211 | \f | |
5212 | RFC 4301 Security Architecture for IP December 2005 | |
5213 | ||
5214 | ||
5215 | D.5. Just say no to ports? | |
5216 | ||
5217 | It has been suggested that we could avoid the problems described | |
5218 | above by not allowing port field selectors to be used in tunnel mode. | |
5219 | But the discussion above shows this to be an unnecessarily stringent | |
5220 | approach, i.e., since no problems arise for the native OS and BITS | |
5221 | implementations. Moreover, some WG members have described scenarios | |
5222 | where use of tunnel mode SAs with (non-trivial) port field selectors | |
5223 | is appropriate. So the challenge is defining a strategy that can | |
5224 | deal with this problem in BITW and SG contexts. Also note that | |
5225 | BYPASS/DISCARD entries in the SPD that make use of ports pose the | |
5226 | same problems, irrespective of tunnel vs. transport mode notions. | |
5227 | ||
5228 | Some folks have suggested that a firewall behind an SG or BITW should | |
5229 | be left to enforce port-level access controls and the effects of | |
5230 | fragmentation. However, this seems to be an incongruous suggestion | |
5231 | in that elsewhere in IPsec (e.g., in IKE payloads) we are concerned | |
5232 | about firewalls that always discard fragments. If many firewalls | |
5233 | don't pass fragments in general, why should we expect them to deal | |
5234 | with fragments in this case? So, this analysis rejects the suggestion | |
5235 | of disallowing use of port field selectors with tunnel mode SAs. | |
5236 | ||
5237 | D.6. Other Suggested Solutions | |
5238 | ||
5239 | One suggestion is to reassemble fragments at the sending IPsec | |
5240 | implementation, and thus avoid the problem entirely. This approach | |
5241 | is invisible to a receiver and thus could be adopted as a purely | |
5242 | local implementation option. | |
5243 | ||
5244 | A more sophisticated version of this suggestion calls for | |
5245 | establishing and maintaining minimal state from each initial fragment | |
5246 | encountered, to allow non-initial fragments to be matched to the | |
5247 | right SAs or SPD/cache entries. This implies an extension to the | |
5248 | current processing model (and the old one). The IPsec implementation | |
5249 | would intercept all fragments; capture Source/Destination IP | |
5250 | addresses, protocol, packet ID, and port fields from initial | |
5251 | fragments; and then use this data to map non-initial fragments to SAs | |
5252 | that require port fields. If this approach is employed, the receiver | |
5253 | needs to employ an equivalent scheme, as it too must verify that | |
5254 | received fragments are consistent with SA selector values. A | |
5255 | non-initial fragment that arrives prior to an initial fragment could | |
5256 | be cached or discarded, awaiting arrival of the corresponding initial | |
5257 | fragment. | |
5258 | ||
5259 | A downside of both approaches noted above is that they will not | |
5260 | always work. When a BITW device or SG is configured in a topology | |
5261 | that might allow some fragments for a packet to be processed at | |
5262 | different SGs or BITW devices, then there is no guarantee that all | |
5263 | ||
5264 | ||
5265 | ||
5266 | Kent & Seo Standards Track [Page 94] | |
5267 | \f | |
5268 | RFC 4301 Security Architecture for IP December 2005 | |
5269 | ||
5270 | ||
5271 | fragments will ever arrive at the same IPsec device. This approach | |
5272 | also raises possible processing problems. If the sender caches | |
5273 | non-initial fragments until the corresponding initial fragment | |
5274 | arrives, buffering problems might arise, especially at high speeds. | |
5275 | If the non-initial fragments are discarded rather than cached, there | |
5276 | is no guarantee that traffic will ever pass, e.g., retransmission | |
5277 | will result in different packet IDs that cannot be matched with prior | |
5278 | transmissions. In any case, housekeeping procedures will be needed | |
5279 | to decide when to delete the fragment state data, adding some | |
5280 | complexity to the system. Nonetheless, this is a viable solution in | |
5281 | some topologies, and these are likely to be common topologies. | |
5282 | ||
5283 | The Working Group rejected an earlier version of the convention of | |
5284 | creating an SA to carry only non-initial fragments, something that | |
5285 | was supported implicitly under the RFC 2401 model via use of OPAQUE | |
5286 | port fields, but never clearly articulated in RFC 2401. The | |
5287 | (rejected) text called for each non-initial fragment to be treated as | |
5288 | protocol 44 (the IPv6 fragment header protocol ID) by the sender and | |
5289 | receiver. This approach has the potential to make IPv4 and IPv6 | |
5290 | fragment handling more uniform, but it does not fundamentally change | |
5291 | the problem, nor does it address the issue of fragment handling for | |
5292 | BYPASS/DISCARD traffic. Given the fragment overlap attack problem | |
5293 | that IPv6 poses, it does not seem that it is worth the effort to | |
5294 | adopt this strategy. | |
5295 | ||
5296 | D.7. Consistency | |
5297 | ||
5298 | Earlier, the WG agreed to allow an IPsec BITS, BITW, or SG to perform | |
5299 | fragmentation prior to IPsec processing. If this fragmentation is | |
5300 | performed after SA lookup at the sender, there is no "mapping to the | |
5301 | right SA" problem. But, the receiver still needs to be able to | |
5302 | verify that the non-initial fragments are consistent with the SA via | |
5303 | which they are received. Since the initial fragment might be lost en | |
5304 | route, the receiver encounters all of the potential problems noted | |
5305 | above. Thus, if we are to be consistent in our decisions, we need to | |
5306 | say how a receiver will deal with the non-initial fragments that | |
5307 | arrive. | |
5308 | ||
5309 | D.8. Conclusions | |
5310 | ||
5311 | There is no simple, uniform way to handle fragments in all contexts. | |
5312 | Different approaches work better in different contexts. Thus, this | |
5313 | document offers 3 choices -- one MUST and two MAYs. At some point in | |
5314 | the future, if the community gains experience with the two MAYs, they | |
5315 | may become SHOULDs or MUSTs or other approaches may be proposed. | |
5316 | ||
5317 | ||
5318 | ||
5319 | ||
5320 | ||
5321 | ||
5322 | Kent & Seo Standards Track [Page 95] | |
5323 | \f | |
5324 | RFC 4301 Security Architecture for IP December 2005 | |
5325 | ||
5326 | ||
5327 | Appendix E: Example of Supporting Nested SAs via SPD and Forwarding | |
5328 | Table Entries | |
5329 | ||
5330 | This appendix provides an example of how to configure the SPD and | |
5331 | forwarding tables to support a nested pair of SAs, consistent with | |
5332 | the new processing model. For simplicity, this example assumes just | |
5333 | one SPD-I. | |
5334 | ||
5335 | The goal in this example is to support a transport mode SA from A to | |
5336 | C, carried over a tunnel mode SA from A to B. For example, A might | |
5337 | be a laptop connected to the public Internet, B might be a firewall | |
5338 | that protects a corporate network, and C might be a server on the | |
5339 | corporate network that demands end-to-end authentication of A's | |
5340 | traffic. | |
5341 | ||
5342 | +---+ +---+ +---+ | |
5343 | | A |=====| B | | C | | |
5344 | | |------------| | | |
5345 | | |=====| | | | | |
5346 | +---+ +---+ +---+ | |
5347 | ||
5348 | A's SPD contains entries of the form: | |
5349 | ||
5350 | Next Layer | |
5351 | Rule Local Remote Protocol Action | |
5352 | ---- ----- ------ ---------- ----------------------- | |
5353 | 1 C A ESP BYPASS | |
5354 | 2 A C ICMP,ESP PROTECT(ESP,tunnel,integr+conf) | |
5355 | 3 A C ANY PROTECT(ESP,transport,integr-only) | |
5356 | 4 A B ICMP,IKE BYPASS | |
5357 | ||
5358 | A's unprotected-side forwarding table is set so that outbound packets | |
5359 | destined for C are looped back to the protected side. A's | |
5360 | protected-side forwarding table is set so that inbound ESP packets | |
5361 | are looped back to the unprotected side. A's forwarding tables | |
5362 | contain entries of the form: | |
5363 | ||
5364 | Unprotected-side forwarding table | |
5365 | ||
5366 | Rule Local Remote Protocol Action | |
5367 | ---- ----- ------ -------- --------------------------- | |
5368 | 1 A C ANY loop back to protected side | |
5369 | 2 A B ANY forward to B | |
5370 | ||
5371 | ||
5372 | ||
5373 | ||
5374 | ||
5375 | ||
5376 | ||
5377 | ||
5378 | Kent & Seo Standards Track [Page 96] | |
5379 | \f | |
5380 | RFC 4301 Security Architecture for IP December 2005 | |
5381 | ||
5382 | ||
5383 | Protected-side forwarding table | |
5384 | ||
5385 | Rule Local Remote Protocol Action | |
5386 | ---- ----- ------ -------- ----------------------------- | |
5387 | 1 A C ESP loop back to unprotected side | |
5388 | ||
5389 | An outbound TCP packet from A to C would match SPD rule 3 and have | |
5390 | transport mode ESP applied to it. The unprotected-side forwarding | |
5391 | table would then loop back the packet. The packet is compared | |
5392 | against SPD-I (see Figure 2), matches SPD rule 1, and so it is | |
5393 | BYPASSed. The packet is treated as an outbound packet and compared | |
5394 | against the SPD for a third time. This time it matches SPD rule 2, | |
5395 | so ESP is applied in tunnel mode. This time the forwarding table | |
5396 | doesn't loop back the packet, because the outer destination address | |
5397 | is B, so the packet goes out onto the wire. | |
5398 | ||
5399 | An inbound TCP packet from C to A is wrapped in two ESP headers; the | |
5400 | outer header (ESP in tunnel mode) shows B as the source, whereas the | |
5401 | inner header (ESP transport mode) shows C as the source. Upon | |
5402 | arrival at A, the packet would be mapped to an SA based on the SPI, | |
5403 | have the outer header removed, and be decrypted and | |
5404 | integrity-checked. Then it would be matched against the SAD | |
5405 | selectors for this SA, which would specify C as the source and A as | |
5406 | the destination, derived from SPD rule 2. The protected-side | |
5407 | forwarding function would then send it back to the unprotected side | |
5408 | based on the addresses and the next layer protocol (ESP), indicative | |
5409 | of nesting. It is compared against SPD-O (see Figure 3) and found to | |
5410 | match SPD rule 1, so it is BYPASSed. The packet is mapped to an SA | |
5411 | based on the SPI, integrity-checked, and compared against the SAD | |
5412 | selectors derived from SPD rule 3. The forwarding function then | |
5413 | passes it up to the next layer, because it isn't an ESP packet. | |
5414 | ||
5415 | ||
5416 | ||
5417 | ||
5418 | ||
5419 | ||
5420 | ||
5421 | ||
5422 | ||
5423 | ||
5424 | ||
5425 | ||
5426 | ||
5427 | ||
5428 | ||
5429 | ||
5430 | ||
5431 | ||
5432 | ||
5433 | ||
5434 | Kent & Seo Standards Track [Page 97] | |
5435 | \f | |
5436 | RFC 4301 Security Architecture for IP December 2005 | |
5437 | ||
5438 | ||
5439 | References | |
5440 | ||
5441 | Normative References | |
5442 | ||
5443 | [BBCDWW98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, | |
5444 | Z., and W. Weiss, "An Architecture for Differentiated | |
5445 | Service", RFC 2475, December 1998. | |
5446 | ||
5447 | [Bra97] Bradner, S., "Key words for use in RFCs to Indicate | |
5448 | Requirement Level", BCP 14, RFC 2119, March 1997. | |
5449 | ||
5450 | [CD98] Conta, A. and S. Deering, "Internet Control Message | |
5451 | Protocol (ICMPv6) for the Internet Protocol Version 6 | |
5452 | (IPv6) Specification", RFC 2463, December 1998. | |
5453 | ||
5454 | [DH98] Deering, S., and R. Hinden, "Internet Protocol, | |
5455 | Version 6 (IPv6) Specification", RFC 2460, December | |
5456 | 1998. | |
5457 | ||
5458 | [Eas05] 3rd Eastlake, D., "Cryptographic Algorithm | |
5459 | Implementation Requirements For Encapsulating Security | |
5460 | Payload (ESP) and Authentication Header (AH)", RFC | |
5461 | 4305, December 2005. | |
5462 | ||
5463 | [HarCar98] Harkins, D. and D. Carrel, "The Internet Key Exchange | |
5464 | (IKE)", RFC 2409, November 1998. | |
5465 | ||
5466 | [Kau05] Kaufman, C., Ed., "The Internet Key Exchange (IKEv2) | |
5467 | Protocol", RFC 4306, December 2005. | |
5468 | ||
5469 | [Ken05a] Kent, S., "IP Encapsulating Security Payload (ESP)", | |
5470 | RFC 4303, December 2005. | |
5471 | ||
5472 | [Ken05b] Kent, S., "IP Authentication Header", RFC 4302, | |
5473 | December 2005. | |
5474 | ||
5475 | [MD90] Mogul, J. and S. Deering, "Path MTU discovery", RFC | |
5476 | 1191, November 1990. | |
5477 | ||
5478 | [Mobip] Johnson, D., Perkins, C., and J. Arkko, "Mobility | |
5479 | Support in IPv6", RFC 3775, June 2004. | |
5480 | ||
5481 | [Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, | |
5482 | September 1981. | |
5483 | ||
5484 | [Pos81b] Postel, J., "Internet Control Message Protocol", RFC | |
5485 | 792, September 1981. | |
5486 | ||
5487 | ||
5488 | ||
5489 | ||
5490 | Kent & Seo Standards Track [Page 98] | |
5491 | \f | |
5492 | RFC 4301 Security Architecture for IP December 2005 | |
5493 | ||
5494 | ||
5495 | [Sch05] Schiller, J., "Cryptographic Algorithms for use in the | |
5496 | Internet Key Exchange Version 2 (IKEv2)", RFC 4307, | |
5497 | December 2005. | |
5498 | ||
5499 | [WaKiHo97] Wahl, M., Kille, S., and T. Howes, "Lightweight | |
5500 | Directory Access Protocol (v3): UTF-8 String | |
5501 | Representation of Distinguished Names", RFC 2253, | |
5502 | December 1997. | |
5503 | ||
5504 | Informative References | |
5505 | ||
5506 | [CoSa04] Condell, M., and L. Sanchez, "On the Deterministic | |
5507 | Enforcement of Un-ordered Security Policies", BBN | |
5508 | Technical Memo 1346, March 2004. | |
5509 | ||
5510 | [FaLiHaMeTr00] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. | |
5511 | Traina, "Generic Routing Encapsulation (GRE)", RFC | |
5512 | 2784, March 2000. | |
5513 | ||
5514 | [Gro02] Grossman, D., "New Terminology and Clarifications for | |
5515 | Diffserv", RFC 3260, April 2002. | |
5516 | [HC03] Holbrook, H. and B. Cain, "Source Specific Multicast | |
5517 | for IP", Work in Progress, November 3, 2002. | |
5518 | ||
5519 | [HA94] Haller, N. and R. Atkinson, "On Internet | |
5520 | Authentication", RFC 1704, October 1994. | |
5521 | ||
5522 | [NiBlBaBL98] Nichols, K., Blake, S., Baker, F., and D. Black, | |
5523 | "Definition of the Differentiated Services Field (DS | |
5524 | Field) in the IPv4 and IPv6 Headers", RFC 2474, | |
5525 | December 1998. | |
5526 | ||
5527 | [Per96] Perkins, C., "IP Encapsulation within IP", RFC 2003, | |
5528 | October 1996. | |
5529 | ||
5530 | [RaFlBl01] Ramakrishnan, K., Floyd, S., and D. Black, "The | |
5531 | Addition of Explicit Congestion Notification (ECN) to | |
5532 | IP", RFC 3168, September 2001. | |
5533 | ||
5534 | [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for | |
5535 | the Internet Protocol", RFC 2401, November 1998. | |
5536 | ||
5537 | [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC | |
5538 | 2983, October 2000. | |
5539 | ||
5540 | [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, | |
5541 | "The Group Domain of Interpretation", RFC 3547, July | |
5542 | 2003. | |
5543 | ||
5544 | ||
5545 | ||
5546 | Kent & Seo Standards Track [Page 99] | |
5547 | \f | |
5548 | RFC 4301 Security Architecture for IP December 2005 | |
5549 | ||
5550 | ||
5551 | [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group | |
5552 | Security Architecture", RFC 3740, March 2004. | |
5553 | ||
5554 | [RaCoCaDe04] Rajahalme, J., Conta, A., Carpenter, B., and S. | |
5555 | Deering, "IPv6 Flow Label Specification", RFC 3697, | |
5556 | March 2004. | |
5557 | ||
5558 | [Sch94] Schneier, B., Applied Cryptography, Section 8.6, John | |
5559 | Wiley & Sons, New York, NY, 1994. | |
5560 | ||
5561 | [Shi00] Shirey, R., "Internet Security Glossary", RFC 2828, | |
5562 | May 2000. | |
5563 | ||
5564 | [SMPT01] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, | |
5565 | "IP Payload Compression Protocol (IPComp)", RFC 3173, | |
5566 | September 2001. | |
5567 | ||
5568 | [ToEgWa04] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec | |
5569 | Transport Mode for Dynamic Routing", RFC 3884, | |
5570 | September 2004. | |
5571 | ||
5572 | [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in | |
5573 | High-level Networks", ACM Computing Surveys, Vol. 15, | |
5574 | No. 2, June 1983. | |
5575 | ||
5576 | Authors' Addresses | |
5577 | ||
5578 | Stephen Kent | |
5579 | BBN Technologies | |
5580 | 10 Moulton Street | |
5581 | Cambridge, MA 02138 | |
5582 | USA | |
5583 | ||
5584 | Phone: +1 (617) 873-3988 | |
5585 | EMail: kent@bbn.com | |
5586 | ||
5587 | ||
5588 | Karen Seo | |
5589 | BBN Technologies | |
5590 | 10 Moulton Street | |
5591 | Cambridge, MA 02138 | |
5592 | USA | |
5593 | ||
5594 | Phone: +1 (617) 873-3152 | |
5595 | EMail: kseo@bbn.com | |
5596 | ||
5597 | ||
5598 | ||
5599 | ||
5600 | ||
5601 | ||
5602 | Kent & Seo Standards Track [Page 100] | |
5603 | \f | |
5604 | RFC 4301 Security Architecture for IP December 2005 | |
5605 | ||
5606 | ||
5607 | Full Copyright Statement | |
5608 | ||
5609 | Copyright (C) The Internet Society (2005). | |
5610 | ||
5611 | This document is subject to the rights, licenses and restrictions | |
5612 | contained in BCP 78, and except as set forth therein, the authors | |
5613 | retain all their rights. | |
5614 | ||
5615 | This document and the information contained herein are provided on an | |
5616 | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |
5617 | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | |
5618 | ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | |
5619 | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | |
5620 | INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |
5621 | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
5622 | ||
5623 | Intellectual Property | |
5624 | ||
5625 | The IETF takes no position regarding the validity or scope of any | |
5626 | Intellectual Property Rights or other rights that might be claimed to | |
5627 | pertain to the implementation or use of the technology described in | |
5628 | this document or the extent to which any license under such rights | |
5629 | might or might not be available; nor does it represent that it has | |
5630 | made any independent effort to identify any such rights. Information | |
5631 | on the procedures with respect to rights in RFC documents can be | |
5632 | found in BCP 78 and BCP 79. | |
5633 | ||
5634 | Copies of IPR disclosures made to the IETF Secretariat and any | |
5635 | assurances of licenses to be made available, or the result of an | |
5636 | attempt made to obtain a general license or permission for the use of | |
5637 | such proprietary rights by implementers or users of this | |
5638 | specification can be obtained from the IETF on-line IPR repository at | |
5639 | http://www.ietf.org/ipr. | |
5640 | ||
5641 | The IETF invites any interested party to bring to its attention any | |
5642 | copyrights, patents or patent applications, or other proprietary | |
5643 | rights that may cover technology that may be required to implement | |
5644 | this standard. Please address the information to the IETF at ietf- | |
5645 | ipr@ietf.org. | |
5646 | ||
5647 | Acknowledgement | |
5648 | ||
5649 | Funding for the RFC Editor function is currently provided by the | |
5650 | Internet Society. | |
5651 | ||
5652 | ||
5653 | ||
5654 | ||
5655 | ||
5656 | ||
5657 | ||
5658 | Kent & Seo Standards Track [Page 101] | |
5659 | \f |