idnits 2.17.1 draft-ietf-savi-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (October 25, 2010) is 4926 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 4 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 Jianping Wu 3 Internet-Draft Jun Bi 4 Intended status: Informational CERNET 5 Expires: April 28, 2011 Marcelo Bagnulo 6 UC3M 7 Fred Baker 8 Cisco 9 Christian Vogt, Ed. 10 Ericsson 11 October 25, 2010 13 Source Address Validation Improvement Framework 14 draft-ietf-savi-framework-01 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 to IETF 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), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 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 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on April 28, 2011. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 77 3. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 5 78 4. Scalability Optimizations . . . . . . . . . . . . . . . . . . . 6 79 5. Reliability Optimizations . . . . . . . . . . . . . . . . . . . 8 80 6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 9 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 84 1. Introduction 86 Since IP source addresses are used by hosts and network entities to 87 determine the origin of a packet and as a destination for return 88 data, spoofing of IP source addresses can enable impersonation, 89 concealment, and malicious traffic redirection. Unfortunately, the 90 Internet architecture does not prevent IP source address spoofing. 91 Since the IP source address of a packet generally takes no role in 92 forwarding the packet, it can be selected arbitrarily by the sending 93 host without jeopardizing packet delivery. Extra methods are 94 necessary for IP source address validation, to augment packet 95 forwarding with an explicit check of whether a given packet's IP 96 source address is legitimate. 98 IP source address validation can happen at different granularity: 99 Ingress filtering [BCP38], a widely deployed standard for IP source 100 address validation, functions at the coarse granularity of networks. 101 It verifies that the prefix of an IP source address routes to the 102 network from which the packet was received. An advantage of ingress 103 filtering is simplicity: The decision of whether to accept or to 104 reject an IP source address can be made solely based on the 105 information available from routing protocols. However, the 106 simplicity comes at the cost of not being able to validate IP source 107 addresses at a finer granularity, due to the aggregated nature of the 108 information available from routing protocols. Finer-grained IP 109 source address validation would be helpful to enable IP-source- 110 address-based authentication, authorization, and host localization, 111 as well as to efficiently identify misbehaving hosts. Partial 112 solutions [BA2007] exist for finer-grained IP source address 113 validation, but are proprietary and hence often unsuitable for 114 corporate procurement. 116 The Source Address Validation Improvement method was developed to 117 complement ingress filtering with standardized IP source address 118 validation at the maximally fine granularity of individual IP 119 addresses: It prevents hosts attached to the same link from spoofing 120 each other's IP addresses. To facilitate deployment in networks of 121 various kinds, the SAVI method was designed to be modular and 122 extensible. This document describes and motivates the design of the 123 SAVI method. 125 2. Model 127 To enable network operators to deploy fine-grained IP source address 128 validation without a dependency on supportive functionality on hosts, 129 the SAVI method was designed to be purely network-based. A SAVI 130 instance is located on the path of hosts' packets, enforcing the 131 hosts' use of legitimate IP source addresses according to the 132 following three-step model: 134 1. Identify which IP source addresses are legitimate for a host, 135 based on monitoring packets exchanged by the host. 137 2. Bind a legitimate IP address to a link layer property of the 138 host's network attachment. This property, called a "binding 139 anchor", must be verifiable in every packet that the host sends, 140 and harder to spoof than the host's IP source address itself. 142 3. Enforce that the IP source addresses in packets match the binding 143 anchors to which they were bound. 145 This model allows a SAVI instance to be located anywhere on the link 146 to which the hosts attach, hence enabling different locations for a 147 SAVI instance. One way to locate a SAVI instance is in the hosts' 148 default router. IP source addresses are then validated in packets 149 traversing the default router, yet the IP source addresses in packets 150 exchanged locally on the link may bypass validation. Another way to 151 locate a SAVI instance is in a switch between the hosts and their 152 default router. Thus, packets may undergo IP source address 153 validation even if exchanged locally on the link. 155 The closer a SAVI instance is located to the hosts, the more 156 effective the SAVI method is. This is because each of the three 157 steps of the SAVI model can best be accomplished in a position close 158 to the host: 160 o Identifying a host's legitimate IP source addresses is most 161 efficient close to the host, because the likelihood that the 162 host's packets bypass a SAVI instance, and hence cannot be 163 monitored, increases with the distance between the SAVI instance 164 and the host. 166 o Selecting a binding anchor for a host's IP source address is 167 easiest close to the host, because many link layer properties are 168 unique for a given host only on a link segment directly attaching 169 to the host. 171 o Enforcing a host's use of a legitimate IP source address is most 172 reliable when pursued close to the host, because the likelihood 173 that the host's packets bypass a SAVI instance, and hence do not 174 undergo IP source address validation, increases with the distance 175 between the SAVI instance and the host. 177 The preferred location of SAVI instances is therefore close to hosts, 178 such as in switches that directly attach to the hosts whose IP source 179 addresses are being validated. 181 3. Deployment Options 183 The model of the SAVI method, as explained in Section 2, is 184 deployment-specific in two ways: 186 o The identification of legitimate IP source addresses is dependent 187 on the IP address assignment method in use on a link, since it is 188 through assignment that a host becomes the legitimate user of an 189 IP source address. 191 o Binding anchors are dependent on the technology used to build the 192 link on which they are used, as binding anchors are link layer 193 properties of a host's network attachment. 195 To facilitate the deployment of the SAVI method in networks of 196 various kinds, the SAVI method is designed to support different IP 197 address assignment methods, and to function with different binding 198 anchors. Naturally, both the IP address assignment methods in use on 199 a link and the available binding anchors have an impact on the 200 functioning and the strength of IP source address validation. The 201 following two sub-sections explain this impact, and describe how the 202 SAVI method accommodates this. 204 3.1. IP Address Assignment Methods 206 Since the SAVI method traces IP address assignment packets, it 207 necessarily needs to incorporate logic that is specific to particular 208 IP address assignment methods. However, developing SAVI method 209 variants for each IP address assignment method is alone not 210 sufficient, since multiple IP address assignment methods may co-exist 211 on a given link. The SAVI method hence comes in multiple variants: 212 for links with Stateless Address Autoconfiguration, for links with 213 DHCP, for links with Secure Neighbor Discovery, and for links that 214 use any combination of IP address assignment methods. 216 The reason to develop SAVI method variants for each single IP address 217 configuration method, in addition to the variant that handles all IP 218 address assignment methods, is to minimize the complexity of the 219 common case: Many link deployments today either are constrained to a 220 single IP address assignment methods or, equivalently from the 221 perspective of the SAVI method, separate IP address assignment 222 methods into different IP address prefixes. The SAVI method for such 223 links can be simpler than the SAVI method for links with multiple IP 224 address assignment methods per IP address prefix. 226 3.2. Binding Anchors 228 The SAVI method supports a range of binding anchors: 230 o The IEEE extended unique identifier, EUI-48 or EUI-64, of a host's 231 interface. 233 o The port on an Ethernet switch to which a host attaches. 235 o The security association between a host and the base station on 236 wireless links. 238 o The combination of a host interface's link-layer address and a 239 customer relationship in cable modem networks. 241 o An ATM virtual channel, a PPPoE session identifier, or an L2TP 242 session identifier in a DSL network. 244 o A tunnel that connects to a single host, such as an IP-in-IP 245 tunnel, a GRE tunnel, or an MPLS label-switched path. 247 The various binding anchors differ significantly in the security they 248 provide. IEEE extended unique identifiers, for example, fail to 249 render a secure binding anchor because they can be spoofed with 250 little effort. And switch ports alone may be insufficient because 251 they may connect to more than a single host, such as in the case of 252 concatenated switches. 254 Given this diversity in the security provided, one could define a set 255 of possible binding anchors, and leave it up to the administrator to 256 choose one or more of them. Such a selection of binding anchors 257 would, of course, have to be accompanied by an explanation of the 258 pros and cons of the different binding anchors. In addition, SAVI 259 devices may have a default binding anchor depending on the lower 260 layers. Such a default could be to use switch ports when available, 261 and MAC addresses otherwise. Or to use MAC addresses, and switch 262 ports in addition if available. 264 4. Scalability Optimizations 266 The preference to locate a SAVI instance close to hosts implies that 267 multiple SAVI instances must be able to co-exist in order to support 268 large links. Although the model of the SAVI method is independent of 269 the number of SAVI instances per link, co-existence of multiple SAVI 270 instances without further measures can lead to higher-than-necessary 271 memory requirements: Since a SAVI instance creates bindings for the 272 IP source addresses of all hosts on a link, bindings are replicated 273 if multiple SAVI instances co-exist on the link. High memory 274 requirements, in turn, increase the cost of a SAVI instance. This is 275 problematic in particular for SAVI instances that are located on a 276 switch, since it may significantly increase the cost of such a 277 switch. 279 To reduce memory requirements for SAVI instances that are located on 280 a switch, the SAVI method enables the suppression of binding 281 replication on links with multiple SAVI instances. This requires 282 manual disabling of IP source address validation on switch ports that 283 connect to other switches running a SAVI instance. Each SAVI 284 instance is then responsible for validating IP source addresses only 285 on those ports to which hosts attach either directly, or via switches 286 without a SAVI instance. On ports towards other switches running a 287 SAVI instance, IP source addresses are not validated. The switches 288 running SAVI instances thus form a "protection perimeter". The IP 289 source addresses in packets passing the protection perimeter are 290 validated by the ingress SAVI instance, but no further validation 291 takes place as long as the packets remain within, or leave the 292 protection perimeter. 294 .............. 295 protection perimeter --> : +--------+ : 296 +---+ +---+ : | SAVI | : 297 | A | | B | <-- hosts : | switch | : 298 +---+ +---+ : +--------+ : 299 ...|......|.............................: | : 300 : +--------+ +--------+ +--------+ : 301 : | SAVI |----------| legacy | | SAVI | : 302 : | switch | | switch |----------| switch | : 303 : +--------+ +--------+ +--------+ : 304 : | ...............................|........: 305 : +--------+ : +--------+ 306 : | SAVI | : | legacy | 307 : | switch | : | switch | 308 : +--------+ : +--------+ 309 :............: | | 310 +---+ +---+ 311 hosts --> | C | | D | 312 +---+ +---+ 314 Figure 1: Protection perimeter concept 316 Figure 1 illustrates the concept of the protection perimeter. The 317 figure shows a link with six switches, of which four, denoted "SAVI 318 switch", run a SAVI instance. The protection perimeter created by 319 the four SAVI instances is shown as a dotted line in the figure. IP 320 source address validation is enabled on all switch ports on the 321 protection perimeter, and it is disabled on all other switch ports. 322 Four hosts, denoted A through D in the figure, attach to the 323 protection perimeter. 325 In the example of figure Figure 1, the protection perimeter 326 encompasses one of the legacy switches, located in the middle of the 327 depicted link topology. This enables a single, unpartitioned 328 protection perimeter. A single protection perimeter minimizes memory 329 requirements for the SAVI instances because every binding is kept 330 only once, namely, by the SAVI instance that attaches to the host 331 being validated. Excluding the legacy switch from the protection 332 perimeter would result in two smaller protection perimeters to the 333 left and to the right of the depicted link topology. The memory 334 requirements for the SAVI instances would then be higher: Since IP 335 source address validation would be activated on the two ports 336 connecting to the legacy switch, the SAVI instances adjacent to the 337 legacy switch would replicate all bindings from the respectively 338 other protection perimeter. The reason why it is possible to include 339 the legacy switch in the protection perimeter is because the depicted 340 link topology guarantees that packets cannot enter the protection 341 perimeter via this legacy switch. Without this guarantee, the legacy 342 switch would have to be excluded from the protection perimeter in 343 order to ensure that packets entering the protection perimeter 344 undergo IP source address validation. 346 5. Reliability Optimizations 348 The explicit storage of legitimate IP addresses in the form of 349 bindings implies that failure to create a binding, or the premature 350 removal of bindings, can lead to loss of legitimate packets. There 351 are three situations in which this can happen: 353 o Legitimate IP address configuration packets, which should trigger 354 the creation of a binding in a SAVI instance, are lost before 355 reaching the SAVI instance. 357 o A SAVI instance loses a binding, for example, due to a restart. 359 o The link topology changes, resulting in hosts to communicate 360 through SAVI instances that do not have a binding for those hosts' 361 IP addresses. 363 To limit the disruption that missing bindings for legitimate IP 364 addresses can have, the SAVI method includes a mechanism for reactive 365 binding creation based on regular packets. This mechanism 366 supplements the proactive binding creation based on IP address 367 configuration packets. Reactive binding creation occurs when a SAVI 368 instances recognizes excessive drops of regular packets originating 369 from the same IP address. The SAVI instance then verifies whether 370 said IP address is unique on the link. How the verification is 371 carried out depends on the IP address configuration method that the 372 SAVI instance supports: The SAVI method variant for Stateless 373 Address Autoconfiguration and for Secure Neighbor Discovery verifies 374 an IP address through the Duplicate Address Detection procedure. The 375 SAVI method variant for DHCP verifies an IP address through a DHCP 376 Lease Query message exchange with the DHCP server. If verification 377 indicates that the IP address is unique on the link, the SAVI 378 instance creates a binding for the IP address. Otherwise, no binding 379 is created, and packets sent from the IP address continue to be 380 dropped. 382 6. Acknowledgment 384 The author would like to thank the SAVI working group for a thorough 385 technical discussion on the design and the framework of the SAVI 386 method, as captured in this document, in particular Erik Nordmark, 387 Guang Yao, Eric Levy-Abegnoli, and Alberto Garcia. Thanks also to 388 Torben Melsen for reviewing this document. 390 This document was generated using the xml2rfc tool. 392 7. References 394 [BA2007] Baker, F., "Cisco IP Version 4 Source Guard", IETF Internet 395 draft (work in progress), November 2007. 397 [BCP38] Paul, P. and D. Senie, "Network Ingress Filtering: 398 Defeating Denial of Service Attacks which employ IP Source 399 Address Spoofing", RFC 2827, BCP 38, May 2000. 401 Authors' Addresses 403 Jianping Wu 404 CERNET 405 Computer Science, Tsinghua University 406 Beijing 100084 407 China 409 Email: jianping@cernet.edu.cn 411 Jun Bi 412 CERNET 413 Network Research Center, Tsinghua University 414 Beijing 100084 415 China 417 Email: junbi@cernet.edu.cn 419 Marcelo Bagnulo 420 Universidad Carlos III de Madrid 421 Avenida de la Universidad 30 422 Leganes, Madrid 28911 423 Spain 425 Email: marcelo@it.uc3m.es 427 Fred Baker 428 Cisco Systems 429 Santa Barbara, CA 93117 430 United States 432 Email: fred@cisco.com 434 Christian Vogt (editor) 435 Ericsson 436 200 Holger Way 437 San Jose, CA 95134 438 United States 440 Email: christian.vogt@ericsson.com