idnits 2.17.1 draft-ietf-savi-framework-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 12, 2011) is 4787 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Wu 3 Internet-Draft J. Bi 4 Intended status: Informational Tsinghua Univ. 5 Expires: September 13, 2011 M. Bagnulo 6 UC3M 7 F. Baker 8 Cisco 9 C. Vogt, Ed. 10 Ericsson 11 March 12, 2011 13 Source Address Validation Improvement Framework 14 draft-ietf-savi-framework-03 16 Abstract 18 The Source Address Validation Improvement method was developed to 19 complement ingress filtering with finer-grained, standardized IP 20 source address validation. This document describes and motivates the 21 design of the SAVI method. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 13, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 6 72 4. Scalability Optimizations . . . . . . . . . . . . . . . . . . 8 73 5. Reliability Optimizations . . . . . . . . . . . . . . . . . . 10 74 6. Mix Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 11 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 10.1. Informative References . . . . . . . . . . . . . . . . . 12 80 10.2. Normative References . . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 Since IP source addresses are used by hosts and network entities to 86 determine the origin of a packet and as a destination for return 87 data, spoofing of IP source addresses can enable impersonation, 88 concealment, and malicious traffic redirection. Unfortunately, the 89 Internet architecture does not prevent IP source address spoofing 90 [draft-ietf-savi-threat-scope]. Since the IP source address of a 91 packet generally takes no role in forwarding the packet, it can be 92 selected arbitrarily by the sending host without jeopardizing packet 93 delivery. Extra methods are necessary for IP source address 94 validation, to augment packet forwarding with an explicit check of 95 whether a given packet's IP source address is legitimate. 97 IP source address validation can happen at different granularity: 98 Ingress filtering [BCP38], a widely deployed standard for IP source 99 address validation, functions at the coarse granularity of networks. 100 It verifies that the prefix of an IP source address routes to the 101 network from which the packet was received. An advantage of ingress 102 filtering is simplicity: the decision of whether to accept or to 103 reject an IP source address can be made solely based on the 104 information available from routing protocols. However, the 105 simplicity comes at the cost of not being able to validate IP source 106 addresses at a finer granularity, due to the aggregated nature of the 107 information available from routing protocols. Finer-grained IP 108 source address validation would be helpful to enable IP-source- 109 address-based authentication, authorization, and host localization, 110 as well as to efficiently identify misbehaving hosts. Partial 111 solutions [BA2007] exist for finer-grained IP source address 112 validation, but are proprietary and hence often unsuitable for 113 corporate procurement. 115 The Source Address Validation Improvement method was developed to 116 complement ingress filtering with standardized IP source address 117 validation at the maximally fine granularity of individual IP 118 addresses: It prevents hosts attached to the same link from spoofing 119 each other's IP addresses. To facilitate deployment in networks of 120 various kinds, the SAVI method was designed to be modular and 121 extensible. This document describes and motivates the design of the 122 SAVI method. 124 2. Model 126 To enable network operators to deploy fine-grained IP source address 127 validation without a dependency on supportive functionality on hosts, 128 the SAVI method was designed to be purely network-based. A SAVI 129 instance is located on the path of hosts' packets, enforcing the 130 hosts' use of legitimate IP source addresses according to the 131 following three-step model: 133 1. Identify which IP source addresses are legitimate for a host, 134 based on monitoring packets exchanged by the host. 136 2. Bind a legitimate IP address to a link layer property of the 137 host's network attachment. This property, called a "binding 138 anchor", must be verifiable in every packet that the host sends, 139 and harder to spoof than the host's IP source address itself. 141 3. Enforce that the IP source addresses in packets match the binding 142 anchors to which they were bound. 144 This model allows a SAVI instance to be located anywhere on the link 145 to which the hosts attach, hence enabling different locations for a 146 SAVI instance. One way to locate a SAVI instance is in the hosts' 147 default router. IP source addresses are then validated in packets 148 traversing the default router, yet the IP source addresses in packets 149 exchanged locally on the link may bypass validation. Another way to 150 locate a SAVI instance is in a switch between the hosts and their 151 default router. Thus, packets may undergo IP source address 152 validation even if exchanged locally on the link. 154 The closer a SAVI instance is located to the hosts, the more 155 effective the SAVI method is. This is because each of the three 156 steps of the SAVI model can best be accomplished in a position close 157 to the host: 159 o Identifying a host's legitimate IP source addresses is most 160 efficient close to the host, because the likelihood that the 161 host's packets bypass a SAVI instance, and hence cannot be 162 monitored, increases with the distance between the SAVI instance 163 and the host. 165 o Selecting a binding anchor for a host's IP source address is 166 easiest close to the host, because many link layer properties are 167 unique for a given host only on a link segment directly attaching 168 to the host. 170 o Enforcing a host's use of a legitimate IP source address is most 171 reliable when pursued close to the host, because the likelihood 172 that the host's packets bypass a SAVI instance, and hence do not 173 undergo IP source address validation, increases with the distance 174 between the SAVI instance and the host. 176 The preferred location of SAVI instances is therefore close to hosts, 177 such as in switches that directly attach to the hosts whose IP source 178 addresses are being validated. 180 To make SAVI of better applicability, to handle the scenarios in 181 which hosts are not directly attached is of value. For example, a 182 SAVI instance is attached by a legacy switch which is attached by 183 hosts. However, to take such scenario into consideration requires 184 support in the bind-and-identify model. Considering two scenarios: 186 o A legacy switch to which hosts are attaching uses two trunked 187 ports to connect to SAVI switch. 189 o STP runs among switches, and a link failure happens. 191 Both scenarios require more specified design to build correct 192 binding. Thus, for each SAVI solution, the applicability must be 193 specified explicitly. 195 Besides, in the case of legacy switches, the security level is lower, 196 as there is no full protection for the hosts connected to the legacy 197 server. 199 3. Deployment Options 201 The model of the SAVI method, as explained in Section 2, is 202 deployment-specific in two ways: 204 o The identification of legitimate IP source addresses is dependent 205 on the IP address assignment method in use on a link, since it is 206 through assignment that a host becomes the legitimate user of an 207 IP source address. 209 o Binding anchors are dependent on the technology used to build the 210 link on which they are used, as binding anchors are link layer 211 properties of a host's network attachment. 213 To facilitate the deployment of the SAVI method in networks of 214 various kinds, the SAVI method is designed to support different IP 215 address assignment methods, and to function with different binding 216 anchors. Naturally, both the IP address assignment methods in use on 217 a link and the available binding anchors have an impact on the 218 functioning and the strength of IP source address validation. The 219 following two sub-sections explain this impact, and describe how the 220 SAVI method accommodates this. 222 3.1. IP Address Assignment Methods 224 Since the SAVI method traces IP address assignment packets, it 225 necessarily needs to incorporate logic that is specific to particular 226 IP address assignment methods. However, developing SAVI method 227 variants for each IP address assignment method is alone not 228 sufficient, since multiple IP address assignment methods may co-exist 229 on a given link. The SAVI method hence comes in multiple variants: 230 for links with Stateless Address Autoconfiguration [rfc4862], for 231 links with DHCP [rfc2131][rfc3315], for links with Secure Neighbor 232 Discovery [rfc3971], for links with IKEv2 [rfc5996] [rfc5739] 233 [rfc5026] and for links that use any combination of IP address 234 assignment methods. 236 The reason to develop SAVI method variants for each single IP address 237 configuration method, in addition to the variant that handles all IP 238 address assignment methods, is to minimize the complexity of the 239 common case: many link deployments today either are constrained to a 240 single IP address assignment methods or, equivalently from the 241 perspective of the SAVI method, separate IP address assignment 242 methods into different IP address prefixes. The SAVI method for such 243 links can be simpler than the SAVI method for links with multiple IP 244 address assignment methods per IP address prefix. 246 3.2. Binding Anchors 248 The SAVI method supports a range of binding anchors: 250 o The IEEE extended unique identifier, EUI-48 or EUI-64, of a host's 251 interface. 253 o The port on an Ethernet switch to which a host attaches. 255 o The security association between a host and the base station on 256 wireless links. 258 o The combination of a host interface's link-layer address and a 259 customer relationship in cable modem networks. 261 o An ATM virtual channel, a PPPoE session identifier, or an L2TP 262 session identifier in a DSL network. 264 o A tunnel that connects to a single host, such as an IP-in-IP 265 tunnel, a GRE tunnel, or an MPLS label-switched path. 267 The various binding anchors differ significantly in the security they 268 provide. IEEE extended unique identifiers, for example, fail to 269 render a secure binding anchor because they can be spoofed with 270 little effort. And switch ports alone may be insufficient because 271 they may connect to more than a single host, such as in the case of 272 concatenated switches. 274 Given this diversity in the security provided, one could define a set 275 of possible binding anchors, and leave it up to the administrator to 276 choose one or more of them. Such a selection of binding anchors 277 would, of course, have to be accompanied by an explanation of the 278 pros and cons of the different binding anchors. In addition, SAVI 279 devices may have a default binding anchor depending on the lower 280 layers. Such a default could be to use switch ports when available, 281 and MAC addresses otherwise. Or to use MAC addresses, and switch 282 ports in addition if available. 284 4. Scalability Optimizations 286 The preference to locate a SAVI instance close to hosts implies that 287 multiple SAVI instances must be able to co-exist in order to support 288 large links. Although the model of the SAVI method is independent of 289 the number of SAVI instances per link, co-existence of multiple SAVI 290 instances without further measures can lead to higher-than-necessary 291 memory requirements: since a SAVI instance creates bindings for the 292 IP source addresses of all hosts on a link, bindings are replicated 293 if multiple SAVI instances co-exist on the link. High memory 294 requirements, in turn, increase the cost of a SAVI instance. This is 295 problematic in particular for SAVI instances that are located on a 296 switch, since it may significantly increase the cost of such a 297 switch. 299 To reduce memory requirements for SAVI instances that are located on 300 a switch, the SAVI method enables the suppression of binding 301 replication on links with multiple SAVI instances. This requires 302 manual disabling of IP source address validation on switch ports that 303 connect to other switches running a SAVI instance. Each SAVI 304 instance is then responsible for validating IP source addresses only 305 on those ports to which hosts attach either directly, or via switches 306 without a SAVI instance. On ports towards other switches running a 307 SAVI instance, IP source addresses are not validated. The switches 308 running SAVI instances thus form a "protection perimeter". The IP 309 source addresses in packets passing the protection perimeter are 310 validated by the ingress SAVI instance, but no further validation 311 takes place as long as the packets remain within, or leave the 312 protection perimeter. 314 .............. 315 protection perimeter --> : +--------+ : 316 +---+ +---+ : | SAVI | : 317 | A | | B | <-- hosts : | switch | : 318 +---+ +---+ : +--------+ : 319 ...|......|.............................: | : 320 : +--------+ +--------+ +--------+ : 321 : | SAVI |----------| legacy | | SAVI | : 322 : | switch | | switch |----------| switch | : 323 : +--------+ +--------+ +--------+ : 324 : | ...............................|........: 325 : +--------+ : +--------+ 326 : | SAVI | : | legacy | 327 : | switch | : | switch | 328 : +--------+ : +--------+ 329 :............: | | 330 +---+ +---+ 331 hosts --> | C | | D | 332 +---+ +---+ 334 Figure 1: Protection perimeter concept 336 Figure 1 illustrates the concept of the protection perimeter. The 337 figure shows a link with six switches, of which four, denoted "SAVI 338 switch", run a SAVI instance. The protection perimeter created by 339 the four SAVI instances is shown as a dotted line in the figure. IP 340 source address validation is enabled on all switch ports on the 341 protection perimeter, and it is disabled on all other switch ports. 342 Four hosts, denoted A through D in the figure, attach to the 343 protection perimeter. 345 In the example of figure Figure 1, the protection perimeter 346 encompasses one of the legacy switches, located in the middle of the 347 depicted link topology. This enables a single, unpartitioned 348 protection perimeter. A single protection perimeter minimizes memory 349 requirements for the SAVI instances because every binding is kept 350 only once, namely, by the SAVI instance that attaches to the host 351 being validated. Excluding the legacy switch from the protection 352 perimeter would result in two smaller protection perimeters to the 353 left and to the right of the depicted link topology. The memory 354 requirements for the SAVI instances would then be higher: since IP 355 source address validation would be activated on the two ports 356 connecting to the legacy switch, the SAVI instances adjacent to the 357 legacy switch would replicate all bindings from the respectively 358 other protection perimeter. The reason why it is possible to include 359 the legacy switch in the protection perimeter is because the depicted 360 link topology guarantees that packets cannot enter the protection 361 perimeter via this legacy switch. Without this guarantee, the legacy 362 switch would have to be excluded from the protection perimeter in 363 order to ensure that packets entering the protection perimeter 364 undergo IP source address validation. 366 5. Reliability Optimizations 368 The explicit storage of legitimate IP addresses in the form of 369 bindings implies that failure to create a binding, or the premature 370 removal of bindings, can lead to loss of legitimate packets. There 371 are three situations in which this can happen: 373 o Legitimate IP address configuration packets, which should trigger 374 the creation of a binding in a SAVI instance, are lost before 375 reaching the SAVI instance. 377 o A SAVI instance loses a binding, for example, due to a restart. 379 o The link topology changes, resulting in hosts to communicate 380 through SAVI instances that do not have a binding for those hosts' 381 IP addresses. 383 To limit the disruption that missing bindings for legitimate IP 384 addresses can have, the SAVI method includes a mechanism for reactive 385 binding creation based on regular packets. This mechanism 386 supplements the proactive binding creation based on IP address 387 configuration packets. Reactive binding creation occurs when a SAVI 388 instances recognizes excessive drops of regular packets originating 389 from the same IP address. The SAVI instance then verifies whether 390 said IP address is unique on the link. How the verification is 391 carried out depends on the IP address configuration method that the 392 SAVI instance supports: the SAVI method variant for Stateless 393 Address Autoconfiguration and for Secure Neighbor Discovery verifies 394 an IP address through the Duplicate Address Detection procedure. The 395 SAVI method variant for DHCP verifies an IP address through a DHCP 396 Lease Query message exchange with the DHCP server. If verification 397 indicates that the IP address is unique on the link, the SAVI 398 instance creates a binding for the IP address. Otherwise, no binding 399 is created, and packets sent from the IP address continue to be 400 dropped. 402 6. Mix Scenario 404 While multiple assignment methods can be used on the same link, the 405 SAVI device may have to deal with a mix of binding discovery methods. 406 If the address prefix used for each assignment method is different, 407 mix scenario can handle the same as scenario with only one assignment 408 method. If different address assignment methods are used to assign 409 addresses from the same prefix, additional considerations are needed 410 because one binding mechanism may create a binding violating an 411 existing binding from another binding mechanism, e.g., binding from 412 SAVI-FCFS [savi-fcfs] may violate binding from SAVI-DHCP [savi-dhcp]. 413 Thus, the collision between different SAVI mechanisms in mix scenario 414 must be handled in case more than one address assignment method is 415 used to assign addresses from the same prefix. 417 Prioritization relationship between different address assignment 418 methods is used as the basis to solve possible collisions. Current 419 standard documents of address assignment methods have implied the 420 prioritization relationship in general cases. However, considering 421 in some scenarios, default prioritization level may not be quite 422 suitable. Configurable prioritization level should be supported in a 423 document of SAVI solution for the mix scenario. 425 7. Acknowledgment 427 The author would like to thank the SAVI working group for a thorough 428 technical discussion on the design and the framework of the SAVI 429 method, as captured in this document, in particular Erik Nordmark, 430 Guang Yao, Eric Levy-Abegnoli, and Alberto Garcia. Thanks also to 431 Torben Melsen for reviewing this document. 433 This document was generated using the xml2rfc tool. 435 8. IANA Considerations 437 This memo asks the IANA for no new parameters. 439 Note to RFC Editor: This section will have served its purpose if it 440 correctly tells IANA that no new assignments or registries are 441 required, or if those assignments or registries are created during 442 the RFC publication process. From the authors' perspective, it may 443 therefore be removed upon publication as an RFC at the RFC Editor's 444 discretion. 446 9. Security Considerations 448 This document only discusses the possible methods to mitigrate the 449 usage of forged IP address, but doesn't propose a mechanism that 450 provides strong security for IP address. If binding anchor is not 451 exclusive for each user, or is without strong security, addresses can 452 still be forged. Besides, the binding may not accord with the 453 address management requirement, which can be more specified for each 454 client. However, given no new protocol is introduced, the 455 improvements are still acceptable. If there is requirement the usage 456 of IP address must be of strong security, the only way is using 457 cryptographic based authentication. 459 10. References 461 10.1. Informative References 463 [BA2007] Baker, F., "Cisco IP Version 4 Source Guard", IETF 464 Internet draft (work in progress), November 2007. 466 [BCP38] Paul, P. and D. Senie, "Network Ingress Filtering: 467 Defeating Denial of Service Attacks which employ IP Source 468 Address Spoofing", RFC 2827, BCP 38, May 2000. 470 10.2. Normative References 472 [draft-ietf-savi-threat-scope] 473 McPherson, D., Baker, F., and J. Halpern, "SAVI Threat 474 Scope", draft-ietf-savi-threat-scope-04 (work in 475 progress), March 2011. 477 [rfc2131] Droms, R., "Dynamic Host Configuration Protocol", 478 RFC 2131, March 1997. 480 [rfc3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 481 and M. Carney, "Dynamic Host Configuration Protocol for 482 IPv6 (DHCPv6)", RFC 3315, July 2003. 484 [rfc3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 485 Neighbor Discovery (SEND)", RFC 3971, March 2005. 487 [rfc4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 488 Address Autoconfiguration", RFC 4862, September 2007. 490 [rfc5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 491 Bootstrapping in Split Scenario", RFC 5026, October 2007. 493 [rfc5739] Eronen, P., Laganier, J., and C. Madson, "IPv6 494 Configuration in Internet Key Exchange Protocol Version 2 495 (IKEv2)", RFC 5739, February 2010. 497 [rfc5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 498 "Internet Key Exchange Protocol Version 2 (IKEv2)", 499 RFC 5996, September 2010. 501 [savi-dhcp] 502 Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for 503 DHCP", draft-ietf-savi-dhcp-07 (work in progress), 504 November 2010. 506 [savi-fcfs] 507 Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS- 508 SAVI: First-Come First-Serve Source-Address Validation for 509 Locally Assigned Addresses", draft-ietf-savi-fcfs-05 (work 510 in progress), October 2010. 512 Authors' Addresses 514 Jianping Wu 515 Tsinghua University 516 Computer Science, Tsinghua University 517 Beijing 100084 518 China 520 Email: jianping@cernet.edu.cn 522 Jun Bi 523 Tsinghua University 524 Network Research Center, Tsinghua University 525 Beijing 100084 526 China 528 Email: junbi@tsinghua.edu.cn 530 Marcelo Bagnulo 531 Universidad Carlos III de Madrid 532 Avenida de la Universidad 30 533 Leganes, Madrid 28911 534 Spain 536 Email: marcelo@it.uc3m.es 537 Fred Baker 538 Cisco Systems 539 Santa Barbara, CA 93117 540 United States 542 Email: fred@cisco.com 544 Christian Vogt (editor) 545 Ericsson 546 200 Holger Way 547 San Jose, CA 95134 548 United States 550 Email: christian.vogt@ericsson.com