idnits 2.17.1 draft-vogt-savi-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 20, 2009) is 5301 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 Christian Vogt, Ed. 3 Internet-Draft Ericsson 4 Intended status: Informational October 20, 2009 5 Expires: April 23, 2010 7 Source Address Validation Improvement Protocol Framework 8 draft-vogt-savi-framework-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on April 23, 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 The Source Address Validation Improvement protocol was developed to 57 complement ingress filtering with finer-grained, standardized IP 58 source address validation. To facilitate deployment in networks of 59 various kinds, the SAVI protocol was designed to be modular and 60 extensible. This document describes and motivates the design of the 61 SAVI protocol, explains how the protocol is composed of components, 62 and compares the properties of alternative protocol components. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Scalability Optimizations . . . . . . . . . . . . . . . . . . . 6 70 5. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 8 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 Since IP source addresses are used by hosts and network entities to 77 determine the origin of a packet and as a destination for return 78 data, spoofing of IP source addresses can enable impersonation, 79 concealment, and malicious traffic redirection. Unfortunately, the 80 Internet architecture alone fails to prevent IP source address 81 spoofing. Since the IP source address of a packet generally takes no 82 role in forwarding the packet, it can be selected arbitrarily by the 83 sending host without jeopardizing packet delivery. Extra methods are 84 necessary for IP source address validation, to augment packet 85 forwarding with an explicit check of whether a given packet's IP 86 source address is legitimate. 88 IP source address validation can happen at different granularity: 89 Ingress filtering [BCP38], a widely deployed standard for IP source 90 address validation, functions at the coarse granularity of networks. 91 It verifies that the prefix of an IP source address routes to the 92 network from which the packet was received. An advantage of ingress 93 filtering is simplicity: The decision of whether to accept or to 94 reject an IP source address can be made solely based on the 95 information available from routing protocols. Unfortunately, the 96 simplicity comes at the cost of not being able to validate IP source 97 addresses at a finer granularity, due to the aggregated nature of the 98 information available from routing protocols. Finer-grained IP 99 source address validation would be helpful to enable IP-source- 100 address-based authentication, authorization, and host localization, 101 as well as to efficiently identify misbehaving hosts and impose 102 protective measures. Partial solutions [BA2007] exist for finer- 103 grained IP source address validation, but are proprietary and hence 104 often unsuitable for corporate procurement. 106 The Source Address Validation Improvement protocol was developed to 107 complement ingress filtering with standardized IP source address 108 validation at the maximally fine granularity of individual IP 109 addresses: It prevents hosts attached to the same link from spoofing 110 each other's IP addresses. To facilitate deployment in networks of 111 various kinds, the SAVI protocol was designed to be modular and 112 extensible. This document describes and motivates the design of the 113 SAVI protocol, explains how protocol components fit together, and 114 compares the properties of alternative protocol components. 116 2. Protocol Model 118 To enable network operators to deploy fine-grained IP source address 119 validation without a dependency on supportive functionality on hosts, 120 the SAVI protocol was designed to be purely network-based. A SAVI 121 protocol instance is located on the path of hosts' packets, enforcing 122 the hosts' use of legitimate IP source addresses according to the 123 following three-step model: 125 1. Identify which IP source addresses are legitimate for a host, 126 based on monitoring packets exchanged by the host. 128 2. Bind a legitimate IP address to a link layer property of the 129 host's network attachment. This property, called a "binding 130 anchor", must be verifiable in every packet that the host sends, 131 and harder to spoof than the host's IP source address itself. 133 3. Enforce that the IP source addresses in packets match the binding 134 anchors to which they were bound. 136 This model allows a SAVI protocol instance to be located anywhere on 137 the link to which the hosts attach, hence enabling different 138 locations for a protocol instance. One way to locate a SAVI protocol 139 instance is in the hosts' default router. IP source addresses are 140 then validated in packets traversing the default router, yet the IP 141 source addresses in packets exchanged locally on the link may bypass 142 validation. Another way to locate a SAVI protocol instance is in a 143 switch between the hosts and their default router. Thus, packets may 144 undergo IP source address validation even if exchanged locally on the 145 link. 147 The closer a SAVI protocol instance is located to the hosts, the more 148 effective the SAVI protocol is. This is because each of the three 149 steps of the SAVI protocol model can best be accomplished in a 150 position close to the host: 152 o Identifying a host's legitimate IP source addresses is most 153 efficient close to the host, because the likelihood that the 154 host's packets bypass a SAVI protocol instance, and hence cannot 155 be monitored, increases with the distance between the protocol 156 instance and the host. 158 o Selecting a binding anchor for a host's IP source address is 159 easiest close to the host, because many link layer properties are 160 unique for a given host only on a link segment directly attaching 161 to the host. 163 o Enforcing a host's use of a legitimate IP source address is most 164 reliable when pursued close to the host, because the likelihood 165 that the host's packets bypass a SAVI protocol instance, and hence 166 do not undergo IP source address validation, increases with the 167 distance between the protocol instance and the host. 169 The preferred location of SAVI protocol instances is therefore close 170 to hosts, such as in switches that directly attach to the hosts whose 171 IP source addresses are being validated. 173 3. Deployment Options 175 The model of the SAVI protocol, as explained in Section 2, is 176 deployment-specific in two ways: 178 o The identification of legitimate IP source addresses is dependent 179 on the IP address assignment method in use on a link, since it is 180 through assignment that a host becomes the legitimate user of an 181 IP source address. 183 o Binding anchors are dependent on the technology used to build the 184 link on which they are used, as binding anchors are link layer 185 properties of a host's network attachment. 187 To facilitate the deployment of the SAVI protocol in networks of 188 various kinds, the SAVI protocol is designed to support different IP 189 address assignment methods, and to function with different binding 190 anchors. Naturally, both the IP address assignment methods in use on 191 a link and the available binding anchors have an impact on the 192 strength of IP source address validation. This impact further 193 motivates a prioritization of IP address assignment methods, to 194 resolve situations in which a single IP source address is attempted 195 to be bound to different binding anchors through different IP address 196 assignment methods. The following two sub-sections explain the 197 impact that IP address assignment methods and binding anchors have on 198 the strength of IP source address validation, as well as the 199 prioritization of IP address assignment methods defined for the SAVI 200 protocol. 202 3.1. IP Address Assignment Methods 204 To be added: Enumeration and prioritization of IP address assignment 205 methods. This is to include references to the SAVI specifications 206 for DHCP-assigned, SLAAC-assigned, and SEND-assigned IP addresses. 208 3.2. Binding Anchors 210 To be added: Enumeration of binding anchors, along with a discussion 211 of the security properties of those. 213 4. Scalability Optimizations 215 The preference to locate a SAVI protocol instance close to hosts 216 implies that multiple SAVI protocol instances must be able to co- 217 exist in order to support large links. Although the SAVI protocol 218 model is independent of the number of protocol instances per link, 219 co-existence of multiple protocol instances without further measures 220 can lead to higher-than-necessary memory requirements: Since a SAVI 221 protocol instance creates bindings for the IP source addresses of all 222 hosts on a link, bindings are replicated if multiple protocol 223 instances co-exist on the link. High memory requirements, in turn, 224 increase the cost of a SAVI protocol instance. This is problematic 225 in particular for SAVI protocol instances that are located on a 226 switch, since it may significantly increase the cost of such a 227 switch. 229 To reduce memory requirements for SAVI protocol instances that are 230 located on a switch, the SAVI protocol enables the suppression of 231 binding replication on links with multiple protocol instances. This 232 requires manual disabling of IP source address validation on switch 233 ports that connect to other switches running a SAVI protocol 234 instance. Each SAVI protocol instance is then responsible for 235 validating IP source addresses only on those ports to which hosts 236 attach either directly, or via switches without a SAVI protocol 237 instance. On ports towards other switches running a SAVI protocol 238 instance, IP source addresses are not validated. The switches 239 running SAVI protocol instances thus form a "protection perimeter". 240 The IP source addresses in packets passing the protection perimeter 241 are validated by the ingress SAVI protocol instance, but no further 242 validation takes place as long as the packets remain within, or leave 243 the protection perimeter. 245 .............. 246 protection perimeter --> : +--------+ : 247 +---+ +---+ : | SAVI | : 248 | A | | B | <-- hosts : | switch | : 249 +---+ +---+ : +--------+ : 250 ...|......|.............................: | : 251 : +--------+ +--------+ +--------+ : 252 : | SAVI |----------| legacy | | SAVI | : 253 : | switch | | switch |----------| switch | : 254 : +--------+ +--------+ +--------+ : 255 : | ...............................|........: 256 : +--------+ : +--------+ 257 : | SAVI | : | legacy | 258 : | switch | : | switch | 259 : +--------+ : +--------+ 260 :............: | | 261 +---+ +---+ 262 hosts --> | C | | D | 263 +---+ +---+ 265 Figure 1: Protection perimeter concept 267 Figure 1 illustrates the concept of the protection perimeter. The 268 figure shows a link with six switches, of which four, denoted "SAVI 269 switch", run a SAVI protocol instance. The protection perimeter 270 created by the four SAVI protocol instances is shown as a dotted line 271 in the figure. IP source address validation is enabled on all switch 272 ports on the protection perimeter, and it is disabled on all other 273 switch ports. Four hosts, denoted A through D in the figure, attach 274 to the protection perimeter. 276 In the example of figure Figure 1, the protection perimeter 277 encompasses one of the legacy switches, located in the middle of the 278 depicted link topology. This enables a single, unpartitioned 279 protection perimeter. A single protection perimeter minimizes memory 280 requirements for the SAVI protocol instances because every binding is 281 kept only once, namely, by the SAVI protocol instance that attaches 282 to the host being validated. Excluding the legacy switch from the 283 protection perimeter would result in two smaller protection 284 perimeters to the left and to the right of the depicted link 285 topology. The memory requirements for the SAVI protocol instances 286 would then be higher: Since IP source address validation would be 287 activated on the two ports connecting to the legacy switch, the SAVI 288 protocol instances adjacent to the legacy switch would replicate all 289 bindings from the respectively other protection perimeter. The 290 reason why it is possible to include the legacy switch in the 291 protection perimeter is because the depicted link topology guarantees 292 that packets cannot enter the protection perimeter via this legacy 293 switch. Without this guarantee, the legacy switch would have to be 294 excluded from the protection perimeter in order to ensure that 295 packets entering the protection perimeter undergo IP source address 296 validation. 298 5. Acknowledgment 300 The author would like to thank the SAVI working group for a thorough 301 technical discussion on the design and the framework of the SAVI 302 protocol, as captured in this document, in particular Jianping Wu, 303 Jun Bi, Fred Baker, Guang Yao, Marcelo Bagnulo, Erik Nordmark, Eric 304 Levy-Abegnoli, and Alberto Garcia. Thanks also to Torben Melsen for 305 reviewing this document. 307 This document was generated using the xml2rfc tool. 309 6. References 311 [BA2007] Fred, F., "Cisco IP Version 4 Source Guard", IETF Internet 312 draft (work in progress), November 2007. 314 [BCP38] Paul, P. and D. Senie, "Network Ingress Filtering: 315 Defeating Denial of Service Attacks which employ IP Source 316 Address Spoofing", RFC 2827, BCP 38, May 2000. 318 Author's Address 320 Christian Vogt (editor) 321 Ericsson 322 200 Holger Way 323 San Jose, CA 95134 324 United States 326 Email: christian.vogt@ericsson.com