idnits 2.17.1 draft-baker-sava-implementation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 487. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 498. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 505. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 511. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 224: '...e NS/NA exchange SHOULD happen before ...' RFC 2119 keyword, line 234: '...tion on that matter. The receiver MAY...' RFC 2119 keyword, line 236: '... arrives, and it MAY discard it....' RFC 2119 keyword, line 247: '...ddress Detection SHOULD NOT then grant...' RFC 2119 keyword, line 255: '...dresses. A host or router MAY (eg, is...' (25 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 6, 2007) is 6017 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Baker 3 Internet-Draft Cisco Systems 4 Intended status: Best Current November 6, 2007 5 Practice 6 Expires: May 9, 2008 8 Source address validation in the local environment 9 draft-baker-sava-implementation-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 9, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This note describes how Source Address Validation might be applied in 43 an IPv6 environment. Local systems should be able to ensure that 44 their peers are using the IPv6 source addresses that the routing 45 system uses to deliver data to them. Remote systems should be able 46 to ensure that traffic they forward has reasonable source addresses. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Local Source Address Validation for IPv4 . . . . . . . . . 3 52 1.2. Local Source Address Validation for IPv6 . . . . . . . . . 4 53 1.3. Defense in depth . . . . . . . . . . . . . . . . . . . . . 4 54 2. Implementating Source Address Validation in the local 55 environment . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Trust anchors . . . . . . . . . . . . . . . . . . . . . . 5 57 2.2. Host and Router validation of the addresses of 58 neighboring systems . . . . . . . . . . . . . . . . . . . 6 59 2.3. Validation of the addresses of neighboring systems by 60 a switch . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3. Implementating Source Address Validation for remote systems . 8 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 67 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 68 Appendix A. Summary of recommendations . . . . . . . . . . . . . 10 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 Intellectual Property and Copyright Statements . . . . . . . . . . 12 72 1. Introduction 74 This note describes how Source Address Validation might be applied in 75 an IPv6 [RFC2460] environment by a an IP host or router, or lower 76 layer switch directly connected to the source system. Local systems, 77 the hosts and routers directly connected to a neighbor system, should 78 be able to ensure that their peers are using the IPv6 source 79 addresses that the routing system uses to deliver data to them. 80 Remote systems cannot ensure the exact matching of addresses, but can 81 determine whether the source address is reasonable. The 82 recommendations of this specification are based on experience with 83 such features that are currently available for IPv4 [RFC0791] from 84 multiple vendors. 86 This is in support of the requirements of [RFC2827], which recommends 87 that networks defend themselves from spoofed traffic by dropping 88 traffic that clearly has spoofed source addresses. The place this is 89 usually implemented, the ISP ingress router, is an excellent second 90 line of defense and very appropriate for defending the ISP. However, 91 the only system that can definitively stop traffic from errant hosts 92 is the systems they directly communicate with - their LAN switches, 93 hosts that they are the immediate neighbors of, and their first hop 94 routers. This note specifies that first line of defense. 96 The purpose of Source Address Validation is to ensure that a system 97 in the network sends only datagrams that can be replied to - 98 datagrams that the routing system will deliver to that host and which 99 the host will recognize as having been directed to it. This is the 100 first part is isolating a denial of service attack; the second step 101 is to identify systems sending attack traffic and remove their 102 traffic from the network. 104 1.1. Local Source Address Validation for IPv4 106 In IPv4, datagrams generally come from the address that has been 107 assigned to an interface, so it is sufficient to determine "the" 108 address and discard traffic that comes from other addresses. There 109 are some caveats: multi-LAN hosts may reply to a request using the 110 address of one interface but sending the datagram out another, and 111 routers forward traffic from a myriad of addresses. But such systems 112 can be treated as special cases and excluded from source address 113 validation. 115 As such, switch implementations of source address validation 116 technology observe DHCP [RFC2131] assignments of addresses to hosts 117 and drop host-originated datagrams using other source addresses. 118 Neighboring hosts or routers may similarly only store one associated 119 IP address for each MAC address, but this is more frequently a bug or 120 side-effect of implementation than something well thought through, 121 and may not operate as well as one would like. 123 1.2. Local Source Address Validation for IPv6 125 In an IPv6 network, the problem is somewhat more complicated than it 126 is in an IPv4 network. As with IPv4, there are some caveats: multi- 127 LAN hosts may reply to a request using the address of one interface 128 but sending the datagram out another, and routers forward traffic 129 from a myriad of addresses. But such systems can be treated as 130 special cases and excluded from source address validation. 132 The issue that complicates IPv6 is that each interface potentially 133 has many addresses, and a single prefix may straddle multiple 134 physical interfaces. It will generally have at least two: its link- 135 local address and its address in the local prefix. There may, 136 however, be multiple local prefixes, and with privacy addressing 137 [RFC4941] there may be multiple legitimate addresses within the same 138 prefix. So the mapping is not one-to-one, but rather one-to-many. 139 The system verifying the address usage must carry the interface 140 identification, in whatever form it may hold that, as an attribute of 141 the IPv6 address, and verify that a datagram using a given IPv6 142 source address comes from the appropriate source. 144 1.3. Defense in depth 146 There is also a place for ingress filtering by prefix, usually 147 accomplished via Unicast Reverse Path Forwarding or via filters. In 148 general, this is performed between administrations - at the interface 149 between peer ISPs, an ISP and its customer, or between two networks 150 of another type. In concept, however, it could be applied on every 151 router in a network. This will be discussed in Section 3. 153 2. Implementating Source Address Validation in the local environment 155 This section will describe in general terms a common approach to 156 source address validation between two directly connected systems. 158 Addresses are allocated to systems in two ways in IPv6: DHCP 159 [RFC3315], Stateless Address Autoconfiguration [RFC4862]. These 160 addresses are exchanged with a system's neighbors using either 161 Neighbor Discovery [RFC4861], or for Cryptographically Generated 162 Addresses [RFC3972], SEcure Neighbor Discovery [RFC3971]. Each of 163 these will be looked at. 165 2.1. Trust anchors 167 In short, the implementation approach requires neighboring devices to 168 associate a layer 3 entity addressed with an IPv6 address with a 169 layer 2 entity. The identification of the layer 2 entity may take a 170 number of forms: 172 o On a traditional Ethernet or for a host or router attached to a 173 switched Ethernet, the only real option is association with the 174 MAC Address. 176 o The switch, however, may be able to associate the IPv6 address 177 with a switch port if it knows that only one host is attached to 178 the port. 180 o In a wireless network, there are often layer 2 security 181 associations between neighboring devices, and the address can be 182 associated with that security association. 184 o In a Cable Modem network, the address may be associated with the 185 combination of a MAC address and a customer relationship. 187 o In a classical DSL network, it may be associated with an ATM 188 Virtual Channel, or a PPPoE or L2TP Session ID. 190 o In some cases, an IP/IP tunnel, an MPLS LSP, or similar tunneling 191 technology is taken to a single system. In such cases, local 192 address validation can be applied to the use of the tunnel. 194 The key is to have a solid understanding of 196 o what identifies a neighbor in the context: a MAC Address, a switch 197 port, an ATM VC, or whatever, 199 o what addresses one's neighbor is in fact using, and 201 o to limit what one accepts from the neighbor as so identified to 202 that which the neighbor is legitimately using. 204 One could argue that this runs counter to the Robustness Principle, 205 which is stated in RFC 793 as "be conservative in what you do, be 206 liberal in what you accept from others." In fact, it follows the 207 Robustness Principle, but adds the Russian proverb made famous in the 208 west by Ronald Reagan: "Trust, but verify". 210 2.2. Host and Router validation of the addresses of neighboring systems 212 Since a peer's neighbors are intended to learn its address using 213 Neighbor Discovery or Secure Neighbor Discovery, they should look 214 there. If one system sends a datagram to a host or router on the 215 same LAN or otherwise directly connected and the receiving system 216 does not know the address to have been associated with the system 217 that sent it, both of these protocols ask the receiver to query the 218 sender using a Neighbor Solicit. Generally, this is done when 219 sending the reply - the Neighbor Solicit and responding Neighbor 220 Advertisement must be exchanged to send the application reply. 222 This specification recommends that, to protect hosts from attack 223 traffic and prevent routers from forwarding datagrams with spoofed 224 addresses, the NS/NA exchange SHOULD happen before the received 225 datagram is operated on. 227 There are two schools of thought on the holding of the datagram; one 228 holds that the host or router should hold the datagram in a short 229 queue and release it on receipt of the NA, and one holds that the 230 receiver may force the sender to retransmit it. As either approach 231 may be viewed as an attack (a sender spewing datagrams with spoofed 232 addresses may clog its neighbors with traffic, and an application 233 being forced to retransmit experiences a user-observable delay), this 234 specification takes no position on that matter. The receiver MAY 235 hold the datagram in a short queue to be operated on when the NA 236 arrives, and it MAY discard it. 238 Given this model, there is a potential front-running attack on 239 Stateless Address Autoconfiguration. When one system enters the 240 Duplicate Address Detection phase, another system could see the 241 address being verified and immediately send a message (perhaps an 242 ICMP Echo Request sent as a link layer multicast) claiming the 243 address. The systems that receive it would respond with a Neighbor 244 Solicit, it would reply with a Neighbor Advertisement, and the 245 original system would be denied the use of the address. As such, 246 systems observing an address that they have no association for being 247 verified using Duplicate Address Detection SHOULD NOT then grant it 248 to another system. 250 As noted, in IPv6 networks hosts and routers usually have multiple 251 addresses on any given interface. There is a potential attack in 252 this as well: especially with privacy addressing, one could imagine a 253 host using a new address for each TCP or SCTP session it opens, and 254 one could imagine an attack that simulates this but simply fills its 255 neighbor's tables with addresses. A host or router MAY (eg, is 256 authorized to) limit the number of addresses for a neighbor that it 257 will simultaneously hold, and the number of addresses considered 258 reasonable is intentionally not specified. It SHOULD use memory 259 allocated to that function in a Least Recently Used fashion, 260 preserving recollection of addresses a neighbor is actually using and 261 reusing table entries that appear to be unused. 263 As noted in Section 1.2, caveats that make this difficult include any 264 system that might send a datagram from an address unknown in the 265 local environment. These include, but are not limited to, routers 266 and any middleware that behaves like a router, in that it forwards 267 datagrams originated by other systems using their source addresses, 268 and multi-LAN hosts. To simplify source address validation, this 269 specification declares that a host SHOULD send any datagram it 270 originates on an interface the source address is associated with. 271 Routers and router-like middleware such as firewalls must be exlcuded 272 from such analysis. 274 2.3. Validation of the addresses of neighboring systems by a switch 276 In this context, a "switch" refers to a system that switches messages 277 for any lower layer protocol. Examples include Ethernet, ATM, Cable 278 Modem, DSL, and so on. 280 As with IPv4, it is reasonable for a switch to simply observe the 281 Neighbor Advertisements issued by a host or router and note that the 282 host or router may be using them. There is a potential attack in 283 this, however, in that a host could simply spew Neighbor 284 Advertisements. For this reason, the protocol calls for a Neighbor 285 Advertisement to be in response to a Neighbor Solicit. Therefore, a 286 switch implementation that observes Neighbor Discovery or Secure 287 Neighbor Discovery SHOULD remember addresses from Neighbor 288 Advertisement only if it has seen a prior Neighbor Solicit. 290 A switch MAY observe DHCP assignments of addresses to hosts and drop 291 host-originated datagrams using other source addresses. If it does, 292 it SHOULD be prepared to accept multiple simultaneous assignments. 294 A switch or upstream router MAY also observe assignments of prefixes 295 to downstream routers using the DHCP Prefix Assignment Options 296 [RFC3633], and use that information to configure ingress prefix 297 filtering. 299 As with host implementations, a switch MAY limit the number of 300 addresses it will simultaneously store. If it does so, it SHOULD use 301 memory allocated to that function in a Least Recently Used fashion, 302 preserving recollection of addresses a neighbor is actually using and 303 reusing table entries that appear to be unused. 305 3. Implementating Source Address Validation for remote systems 307 As mentioned, it is often in an administration's interest to protect 308 itself from other administrations, which may have inadequate anti- 309 spoofing measures in place. This is the original thrust of BCP 38 310 [RFC2827]. Unfortunately, one step removed from the source system, 311 there is no anchor to verify that the address is exactly correct; 312 rather, one can only verify that it is reasonable - it is within the 313 prefix. 315 It has been argued that this is nonsensical, as anti-spoofing 316 procedures impose additional router processing and only protect other 317 networks. This is incorrect, however, for two reasons. Modern 318 routers often implement filtering or Unicast Reverse Path Forwarding 319 procedures in hardware, minimizing the processing burden, although 320 the differentiated tables may consume memory. In any event, attacks 321 perpetrated from a downstream network (obscured in some cases by 322 address spoofing) attack both the administration's network and the 323 administration's customers. Dealing with that problem is generally 324 the first step in side-stepping an attack. 326 To implement, a router MAY be configured to discard traffic that 327 routing believes is coming from an inappropriate direction. This 328 does not depend on the router's choice of routes, however; it depends 329 on the routing calculated by a router's neighbors. As such, if 330 router A validly advertises to router B that it can route traffic to 331 a prefix, the router B SHOULD accept traffic from that prefix via 332 router A. 334 The determination of when a routing advertisement is valid is beyond 335 the scope of this specification. 337 4. IANA Considerations 339 This memo adds no new IANA considerations. 341 Note to RFC Editor: This section will have served its purpose if it 342 correctly tells IANA that no new assignments or registries are 343 required, or if those assignments or registries are created during 344 the RFC publication process. From the author's perspective, it may 345 therefore be removed upon publication as an RFC at the RFC Editor's 346 discretion. 348 5. Security Considerations 350 This note describes a set of security considerations for the IPv6 351 Internet, specifically related to attack management in IPv6 [RFC2460] 352 and in the configuration and communication mechanisms of Stateless 353 Address Autoconfiguration [RFC4862], Neighbor Discovery [RFC4861], 354 and SEcure Neighbor Discovery [RFC3971]. It does not introduce new 355 attacks, but it identifies some existing ones and recommends 356 approaches to their mitigation. 358 6. Contributors 360 This document was developed in the SAVA context. Contributors 361 include the author, Christian Vogt, Gang Ren, Hannes Tschofenig, Jari 362 Arkko, Jianping Wu, Jun Bi, Ke Xu, and Pekka Savola. 364 7. References 366 7.1. Normative References 368 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 369 September 1981. 371 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 372 (IPv6) Specification", RFC 2460, December 1998. 374 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 375 Defeating Denial of Service Attacks which employ IP Source 376 Address Spoofing", BCP 38, RFC 2827, May 2000. 378 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 379 and M. Carney, "Dynamic Host Configuration Protocol for 380 IPv6 (DHCPv6)", RFC 3315, July 2003. 382 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 383 Neighbor Discovery (SEND)", RFC 3971, March 2005. 385 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 386 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 387 September 2007. 389 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 390 Address Autoconfiguration", RFC 4862, September 2007. 392 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 393 Extensions for Stateless Address Autoconfiguration in 394 IPv6", RFC 4941, September 2007. 396 7.2. Informative References 398 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 399 RFC 2131, March 1997. 401 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 402 Host Configuration Protocol (DHCP) version 6", RFC 3633, 403 December 2003. 405 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 406 RFC 3972, March 2005. 408 Appendix A. Summary of recommendations 410 1. The NS/NA exchange on a response to a received datagram SHOULD 411 happen before the received datagram is operated on. 413 2. The receiver MAY hold the triggering datagram in a short queue 414 to be operated on when the NA arrives, and it MAY discard it. 416 3. Systems observing an address that they have no association for 417 being verified using Duplicate Address Detection SHOULD NOT then 418 grant it to another system. 420 4. A host or router MAY (eg, is authorized to) limit the number of 421 addresses for a neighbor that it will simultaneously hold, and 422 the number of addresses considered. 424 5. It SHOULD use memory allocated to that function in a Least 425 Recently Used fashion, preserving recollection of addresses a 426 neighbor is actually using and reusing table entries that appear 427 to be unused. 429 6. To simplify source address validation, this specification 430 declares that a host SHOULD send any datagram it originates on 431 an interface the source address is associated with. 433 7. A switch that monitors Neighbor Discovery or Secure Neighbor 434 Discovery SHOULD remember addresses from Neighbor Advertisement 435 only if it has seen a prior Neighbor Solicit. 437 8. A switch MAY observe DHCP assignments of addresses to hosts and 438 drop host-originated datagrams using other source addresses. 440 9. If it does, it SHOULD be prepared to accept multiple 441 simultaneous assignments. 443 10. A switch or upstream router MAY also observe assignments of 444 prefixes to downstream routers using the DHCP Prefix Assignment 445 Options [RFC3633], and use that information to configure ingress 446 prefix filtering. 448 11. A switch MAY limit the number of addresses it will 449 simultaneously store. 451 12. If it does so, it SHOULD use memory allocated to that function 452 in a Least Recently Used fashion, preserving recollection of 453 addresses a neighbor is actually using and reusing table entries 454 that appear to be unused. 456 13. A router MAY discard traffic that routing believes is coming 457 from an inappropriate direction. 459 14. If router A validly advertises to router B that it can route 460 traffic to a prefix, the router B SHOULD accept traffic from 461 that prefix via router A. 463 Author's Address 465 Fred Baker 466 Cisco Systems 467 Santa Barbara, California 93117 468 USA 470 Phone: +1-408-526-4257 471 Email: fred@cisco.com 473 Full Copyright Statement 475 Copyright (C) The IETF Trust (2007). 477 This document is subject to the rights, licenses and restrictions 478 contained in BCP 78, and except as set forth therein, the authors 479 retain all their rights. 481 This document and the information contained herein are provided on an 482 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 483 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 484 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 485 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 486 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 487 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 489 Intellectual Property 491 The IETF takes no position regarding the validity or scope of any 492 Intellectual Property Rights or other rights that might be claimed to 493 pertain to the implementation or use of the technology described in 494 this document or the extent to which any license under such rights 495 might or might not be available; nor does it represent that it has 496 made any independent effort to identify any such rights. Information 497 on the procedures with respect to rights in RFC documents can be 498 found in BCP 78 and BCP 79. 500 Copies of IPR disclosures made to the IETF Secretariat and any 501 assurances of licenses to be made available, or the result of an 502 attempt made to obtain a general license or permission for the use of 503 such proprietary rights by implementers or users of this 504 specification can be obtained from the IETF on-line IPR repository at 505 http://www.ietf.org/ipr. 507 The IETF invites any interested party to bring to its attention any 508 copyrights, patents or patent applications, or other proprietary 509 rights that may cover technology that may be required to implement 510 this standard. Please address the information to the IETF at 511 ietf-ipr@ietf.org. 513 Acknowledgment 515 Funding for the RFC Editor function is provided by the IETF 516 Administrative Support Activity (IASA).