idnits 2.17.1 draft-vogt-savi-framework-02.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 (September 7, 2010) is 4951 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: March 11, 2011 Marcelo Bagnulo 6 UC3M 7 Fred Baker 8 Cisco 9 Christian Vogt, Ed. 10 Ericsson 11 September 7, 2010 13 Source Address Validation Improvement Protocol Framework 14 draft-vogt-savi-framework-02 16 Abstract 18 The Source Address Validation Improvement protocol 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 protocol. 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 March 11, 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. Protocol 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 protocol 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 protocol was designed to be modular and 122 extensible. This document describes and motivates the design of the 123 SAVI protocol. 125 2. Protocol 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 protocol was designed to be purely network-based. A SAVI 130 protocol instance is located on the path of hosts' packets, enforcing 131 the 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 protocol instance to be located anywhere on 146 the link to which the hosts attach, hence enabling different 147 locations for a protocol instance. One way to locate a SAVI protocol 148 instance is in the hosts' default router. IP source addresses are 149 then validated in packets traversing the default router, yet the IP 150 source addresses in packets exchanged locally on the link may bypass 151 validation. Another way to locate a SAVI protocol instance is in a 152 switch between the hosts and their default router. Thus, packets may 153 undergo IP source address validation even if exchanged locally on the 154 link. 156 The closer a SAVI protocol instance is located to the hosts, the more 157 effective the SAVI protocol is. This is because each of the three 158 steps of the SAVI protocol model can best be accomplished in a 159 position close to the host: 161 o Identifying a host's legitimate IP source addresses is most 162 efficient close to the host, because the likelihood that the 163 host's packets bypass a SAVI protocol instance, and hence cannot 164 be monitored, increases with the distance between the SAVI 165 protocol instance and the host. 167 o Selecting a binding anchor for a host's IP source address is 168 easiest close to the host, because many link layer properties are 169 unique for a given host only on a link segment directly attaching 170 to the host. 172 o Enforcing a host's use of a legitimate IP source address is most 173 reliable when pursued close to the host, because the likelihood 174 that the host's packets bypass a SAVI protocol instance, and hence 175 do not undergo IP source address validation, increases with the 176 distance between the protocol instance and the host. 178 The preferred location of SAVI protocol instances is therefore close 179 to hosts, such as in switches that directly attach to the hosts whose 180 IP source addresses are being validated. 182 3. Deployment Options 184 The model of the SAVI protocol, as explained in Section 2, is 185 deployment-specific in two ways: 187 o The identification of legitimate IP source addresses is dependent 188 on the IP address assignment method in use on a link, since it is 189 through assignment that a host becomes the legitimate user of an 190 IP source address. 192 o Binding anchors are dependent on the technology used to build the 193 link on which they are used, as binding anchors are link layer 194 properties of a host's network attachment. 196 To facilitate the deployment of the SAVI protocol in networks of 197 various kinds, the SAVI protocol is designed to support different IP 198 address assignment methods, and to function with different binding 199 anchors. Naturally, both the IP address assignment methods in use on 200 a link and the available binding anchors have an impact on the 201 functioning and the strength of IP source address validation. The 202 following two sub-sections explain this impact, and describe how the 203 SAVI protocol accommodates this. 205 3.1. IP Address Assignment Methods 207 Since the SAVI protocol traces IP address assignment packets, it 208 necessarily needs to incorporate logic that is specific to particular 209 IP address assignment methods. However, developing SAVI protocol 210 variants for each IP address assignment method is alone not 211 sufficient, since multiple IP address assignment methods may co-exist 212 on a given link. The SAVI protocol hence comes in multiple variants: 213 for links with Stateless Address Autoconfiguration, for links with 214 DHCP, for links with Secure Neighbor Discovery, and for links that 215 use any combination of IP address assignment methods. 217 The reason to develop SAVI protocol variants for each single IP 218 address configuration method, in addition to the variant that handles 219 all IP address assignment methods, is to minimize the complexity of 220 the common case: Many link deployments today either are constrained 221 to a single IP address assignment methods or, equivalently from the 222 perspective of the SAVI protocol, separate IP address assignment 223 methods into different IP address prefixes. The SAVI protocol for 224 such links can be simpler than the SAVI protocol for links with 225 multiple IP address assignment methods per IP address prefix. 227 3.2. Binding Anchors 229 The SAVI protocol supports a range of binding anchors: 231 o The IEEE extended unique identifier, EUI-48 or EUI-64, of a host's 232 interface. 234 o The port on an Ethernet switch to which a host attaches. 236 o The security association between a host and the base station on 237 wireless links. 239 o The combination of a host interface's link-layer address and a 240 customer relationship in cable modem networks. 242 o An ATM virtual channel, a PPPoE session identifier, or an L2TP 243 session identifier in a DSL network. 245 o A tunnel that connects to a single host, such as an IP-in-IP 246 tunnel, a GRE tunnel, or an MPLS label-switched path. 248 The various binding anchors differ significantly in the security they 249 provide. IEEE extended unique identifiers, for example, fail to 250 render a secure binding anchor because they can be spoofed with 251 little effort. And switch ports alone may be insufficient because 252 they may connect to more than a single host, such as in the case of 253 concatenated switches. 255 Given this diversity in the security provided, one could define a set 256 of possible binding anchors, and leave it up to the administrator to 257 choose one or more of them. Such a selection of binding anchors 258 would, of course, have to be accompanied by an explanation of the 259 pros and cons of the different binding anchors. In addition, SAVI 260 devices may have a default binding anchor depending on the lower 261 layers. Such a default could be to use switch ports when available, 262 and MAC addresses otherwise. Or to use MAC addresses, and switch 263 ports in addition if available. 265 4. Scalability Optimizations 267 The preference to locate a SAVI protocol instance close to hosts 268 implies that multiple SAVI protocol instances must be able to co- 269 exist in order to support large links. Although the SAVI protocol 270 model is independent of the number of protocol instances per link, 271 co-existence of multiple protocol instances without further measures 272 can lead to higher-than-necessary memory requirements: Since a SAVI 273 protocol instance creates bindings for the IP source addresses of all 274 hosts on a link, bindings are replicated if multiple protocol 275 instances co-exist on the link. High memory requirements, in turn, 276 increase the cost of a SAVI protocol instance. This is problematic 277 in particular for SAVI protocol instances that are located on a 278 switch, since it may significantly increase the cost of such a 279 switch. 281 To reduce memory requirements for SAVI protocol instances that are 282 located on a switch, the SAVI protocol enables the suppression of 283 binding replication on links with multiple protocol instances. This 284 requires manual disabling of IP source address validation on switch 285 ports that connect to other switches running a SAVI protocol 286 instance. Each SAVI protocol instance is then responsible for 287 validating IP source addresses only on those ports to which hosts 288 attach either directly, or via switches without a SAVI protocol 289 instance. On ports towards other switches running a SAVI protocol 290 instance, IP source addresses are not validated. The switches 291 running SAVI protocol instances thus form a "protection perimeter". 292 The IP source addresses in packets passing the protection perimeter 293 are validated by the ingress SAVI protocol instance, but no further 294 validation takes place as long as the packets remain within, or leave 295 the protection perimeter. 297 .............. 298 protection perimeter --> : +--------+ : 299 +---+ +---+ : | SAVI | : 300 | A | | B | <-- hosts : | switch | : 301 +---+ +---+ : +--------+ : 302 ...|......|.............................: | : 303 : +--------+ +--------+ +--------+ : 304 : | SAVI |----------| legacy | | SAVI | : 305 : | switch | | switch |----------| switch | : 306 : +--------+ +--------+ +--------+ : 307 : | ...............................|........: 308 : +--------+ : +--------+ 309 : | SAVI | : | legacy | 310 : | switch | : | switch | 311 : +--------+ : +--------+ 312 :............: | | 313 +---+ +---+ 314 hosts --> | C | | D | 315 +---+ +---+ 317 Figure 1: Protection perimeter concept 319 Figure 1 illustrates the concept of the protection perimeter. The 320 figure shows a link with six switches, of which four, denoted "SAVI 321 switch", run a SAVI protocol instance. The protection perimeter 322 created by the four SAVI protocol instances is shown as a dotted line 323 in the figure. IP source address validation is enabled on all switch 324 ports on the protection perimeter, and it is disabled on all other 325 switch ports. Four hosts, denoted A through D in the figure, attach 326 to the protection perimeter. 328 In the example of figure Figure 1, the protection perimeter 329 encompasses one of the legacy switches, located in the middle of the 330 depicted link topology. This enables a single, unpartitioned 331 protection perimeter. A single protection perimeter minimizes memory 332 requirements for the SAVI protocol instances because every binding is 333 kept only once, namely, by the SAVI protocol instance that attaches 334 to the host being validated. Excluding the legacy switch from the 335 protection perimeter would result in two smaller protection 336 perimeters to the left and to the right of the depicted link 337 topology. The memory requirements for the SAVI protocol instances 338 would then be higher: Since IP source address validation would be 339 activated on the two ports connecting to the legacy switch, the SAVI 340 protocol instances adjacent to the legacy switch would replicate all 341 bindings from the respectively other protection perimeter. The 342 reason why it is possible to include the legacy switch in the 343 protection perimeter is because the depicted link topology guarantees 344 that packets cannot enter the protection perimeter via this legacy 345 switch. Without this guarantee, the legacy switch would have to be 346 excluded from the protection perimeter in order to ensure that 347 packets entering the protection perimeter undergo IP source address 348 validation. 350 5. Reliability Optimizations 352 The explicit storage of legitimate IP addresses in the form of 353 bindings implies that failure to create a binding, or the premature 354 removal of bindings, can lead to loss of legitimate packets. There 355 are three situations in which this can happen: 357 o Legitimate IP address configuration packets, which should trigger 358 the creation of a binding in a SAVI protocol instance, are lost 359 before reaching the SAVI protocol instance. 361 o A SAVI protocol instance loses a binding, for example, due to a 362 restart. 364 o The link topology changes, resulting in hosts to communicate 365 through SAVI protocol instances that do not have a binding for 366 those hosts' IP addresses. 368 To limit the disruption that missing bindings for legitimate IP 369 addresses can have, the SAVI protocol includes a mechanism for 370 reactive binding creation based on regular packets. This mechanism 371 supplements the proactive binding creation based on IP address 372 configuration packets. Reactive binding creation occurs when a SAVI 373 protocol instances recognizes excessive drops of regular packets 374 originating from the same IP address. The SAVI protocol instance 375 then verifies whether said IP address is unique on the link. How the 376 verification is carried out depends on the IP address configuration 377 method that the SAVI protocol instance supports: The SAVI protocol 378 variant for Stateless Address Autoconfiguration and for Secure 379 Neighbor Discovery verifies an IP address through the Duplicate 380 Address Detection procedure. The SAVI protocol variant for DHCP 381 verifies an IP address through a DHCP Lease Query message exchange 382 with the DHCP server. If verification indicates that the IP address 383 is unique on the link, the SAVI protocol instance creates a binding 384 for the IP address. Otherwise, no binding is created, and packets 385 sent from the IP address continue to be dropped. 387 6. Acknowledgment 389 The author would like to thank the SAVI working group for a thorough 390 technical discussion on the design and the framework of the SAVI 391 protocol, as captured in this document, in particular Erik Nordmark, 392 Guang Yao, Eric Levy-Abegnoli, and Alberto Garcia. Thanks also to 393 Torben Melsen for reviewing this document. 395 This document was generated using the xml2rfc tool. 397 7. References 399 [BA2007] Fred, F., "Cisco IP Version 4 Source Guard", IETF Internet 400 draft (work in progress), November 2007. 402 [BCP38] Paul, P. and D. Senie, "Network Ingress Filtering: 403 Defeating Denial of Service Attacks which employ IP Source 404 Address Spoofing", RFC 2827, BCP 38, May 2000. 406 Authors' Addresses 408 Jianping Wu 409 CERNET 410 Computer Science, Tsinghua University 411 Beijing 100084 412 China 414 Email: jianping@cernet.edu.cn 416 Jun Bi 417 CERNET 418 Network Research Center, Tsinghua University 419 Beijing 100084 420 China 422 Email: junbi@cernet.edu.cn 424 Marcelo Bagnulo 425 Universidad Carlos III de Madrid 426 Avenida de la Universidad 30 427 Leganes, Madrid 28911 428 Spain 430 Email: marcelo@it.uc3m.es 432 Fred Baker 433 Cisco Systems 434 Santa Barbara, CA 93117 435 United States 437 Email: fred@cisco.com 439 Christian Vogt (editor) 440 Ericsson 441 200 Holger Way 442 San Jose, CA 95134 443 United States 445 Email: christian.vogt@ericsson.com