idnits 2.17.1 draft-ribiere-savi-prefix-guard-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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 354: '... SHOULD query the DHCP server with a...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 26, 2012) is 4315 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'I-D.ietf-savi-framework' on line 385 looks like a reference -- Missing reference section? 'RFC3704' on line 408 looks like a reference -- Missing reference section? 'I-D.kaippallimalil-savi-dhcp-pd' on line 391 looks like a reference -- Missing reference section? 'RFC3633' on line 404 looks like a reference -- Missing reference section? 'RFC6620' on line 430 looks like a reference -- Missing reference section? 'I-D.ietf-savi-dhcp' on line 380 looks like a reference -- Missing reference section? 'RFC5460' on line 427 looks like a reference -- Missing reference section? 'RFC5007' on line 424 looks like a reference -- Missing reference section? 'RFC2119' on line 375 looks like a reference -- Missing reference section? 'RFC2460' on line 397 looks like a reference -- Missing reference section? 'RFC3315' on line 400 looks like a reference -- Missing reference section? 'RFC3971' on line 411 looks like a reference -- Missing reference section? 'RFC3972' on line 414 looks like a reference -- Missing reference section? 'RFC4861' on line 417 looks like a reference -- Missing reference section? 'RFC4862' on line 421 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SAVI J. Kaippallimalil 3 Internet-Draft F. Xia 4 Intended status: Standards Track Huawei USA 5 Expires: December 28, 2012 J. Bi 6 CERNET 7 V. Ribiere, Ed. 8 Cisco Systems 9 June 26, 2012 11 Source Prefix Validation 12 draft-ribiere-savi-prefix-guard-00 14 Abstract 16 This document describes how SAVI concepts can be extended to provide 17 Source Prefix Validation in enterprise and SP scenarios 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 28, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Architecture context . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Service Provider Scenarios . . . . . . . . . . . . . . . . 4 57 3.1.1. SAVI switch is Access Switch . . . . . . . . . . . . . 5 58 3.1.2. SAVI switch is not the Access Switch . . . . . . . . . 5 59 3.2. Enterprise Scenario . . . . . . . . . . . . . . . . . . . 6 60 4. Conceptual Data Structures . . . . . . . . . . . . . . . . . . 7 61 4.1. Binding State Table (BST) . . . . . . . . . . . . . . . . 7 62 4.2. Filtering Table (FT) . . . . . . . . . . . . . . . . . . . 7 63 4.3. Binding State Description . . . . . . . . . . . . . . . . 8 64 5. Anchor Attributes . . . . . . . . . . . . . . . . . . . . . . 8 65 5.1. SAVI-Validation Attribute . . . . . . . . . . . . . . . . 8 66 5.2. SAVI-DHCP Trust Attribute . . . . . . . . . . . . . . . . 8 67 6. Recovery scenarios . . . . . . . . . . . . . . . . . . . . . . 8 68 6.1. DHCP-PD assigned prefixes . . . . . . . . . . . . . . . . 9 69 6.2. Router assigned prefixes . . . . . . . . . . . . . . . . . 9 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 72 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 73 Appendix A. Contributors and Acknowledgments . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Problem statement 78 There are currently several documents [I-D.ietf-savi-framework] that 79 describe the different methods by which a switch can discover and 80 record bindings between a node's layer3 address and a binding anchor 81 and use that binding to perform Source Address Validation. 83 However SAVI existing solutions can not work when addresses can not 84 be learned on the link. This is the case for example in Service 85 Provider environments when prefixes are allocated to CPEs typically 86 using DHCP prefix delegation. In this case the switch is connected 87 to the home router not to home nodes and the source of the traffic is 88 off-link. 90 Even when addresses can be learned on the link and Savi existing 91 solutions can be used there are limitations: 92 o When the deployment model allows hosts to auto-configure any 93 address the Savi device will be learning the addresses without 94 validating them against the prefixes assigned by the router. 95 o HW resources are limited. In that case it is very unefficient to 96 have one filter for each host on the link when a single prefix 97 range can be used. 99 Source Prefix validation (or "Prefix Guard") can be used to overcome 100 the above SAVI limitations. It finds out authorized prefixes and 101 blocks any traffic that would be sourced with an address outside this 102 range. In order to determine which prefixes should be allowed (and 103 which ones that should be blocked) the switch has several "tools": 104 1. Snoop prefixes in Router Advertisements 105 2. Snoop prefixes in DHCP prefix delegation 106 3. Manual configuration 108 Whenever a prefix is to be allowed, it will be downloaded to the 109 hardware Filtering Table (FT). Whenever a packet is switched, the 110 hardware will best match the source of the packet against this table 111 and drop the packet if no match is found. This functionality is very 112 close to Source Address Validation as far as filtering out data 113 traffic as well as for discovering prefixes in control traffic. 115 Reverse Path Forwarding as described in [RFC3704] can be used as an 116 alternative to Source Prefix Validation but not in all scenarios. 117 o RPF operates on a router or a switch with routing capabilities 118 whereas Source Prefix validation can be done on a plain layer2 119 switch. 120 o In a shared VLAN model where the Savi switch is not the access 121 switch all CPEs are "seen" on the same interface: RPF will not be 122 able to detect attacks where CPE1 is sourcing traffic from an 123 address stolen from CPE2 allocated prefix range. 125 We foresee two deployment scenarios where Source Prefix Validation is 126 useful: 127 o Service Provider scenarios where prefixes are assigned through 128 DHCP-PD 129 o Enterprise scenarios where prefixes are assigned by the local 130 Router though Router Advertisements 132 The purpose of this document is to describe how Source Prefix 133 Validation can be used in those scenarios. 135 2. Terminology 137 Host: A network device that connects to the service provider 138 network through a residential gateway. 139 User: An entity that attaches to the network using one or more 140 hosts. The user is usually the subscriber that owns the CPE- 141 Router. 142 CPE-Router: Customer Premise Equipment Router. Gateway device 143 located at the edge of the customer network and is an IP router. 144 For a user within the customer network, the CPE-R is a gateway to 145 the service provider network. 146 Home Router: Same as CPE-Router network, the CPE-R is a gateway to 147 the service provider network. 148 DHCP: Dynamic Host Configuration Protocol 149 MAC: Medium Access Control 150 RPF: Reverse Path Forwarding. Ingress Filtering Technique where 151 the source address is looked up in the Forwarding Information Base 152 (FIB) - and if the packet is received on the interface which would 153 be used to forward the traffic to the source of the packet, it 154 passes the check. 155 SAVI: Source Address Validation Improvements 156 TID: Transaction Identity 157 More definitions are described in [I-D.ietf-savi-framework]. 159 3. Architecture context 161 3.1. Service Provider Scenarios 163 This scenario was described originally in 164 [I-D.kaippallimalil-savi-dhcp-pd]. Prefixes are "allocated" to CPEs, 165 typically using DHCP prefix delegation (as described in [RFC3633]) , 166 but can also be manually provisioned. The SAVI switch is connected 167 to the CPEs not to home nodes; hence Source Address Validation 168 operating at the address level has very limited value. It knows the 169 router addresses, but the nodes that source most of the traffic are 170 the hosts behind the CPEs, and their addresses are assigned using 171 Stateless Address Autoconfiguration. However, the switch can know 172 (by snooping DHCP prefix delegation traffic or by provisioning) which 173 prefixes were assigned to the CPEs and can bind the prefixes to the 174 anchor. 176 It is key to identify the deployment model in order to determine the 177 right binding anchor to be bound with the snooped prefixes. 179 3.1.1. SAVI switch is Access Switch 181 In this scenario the anchor is the port facing the CPE since the SAVI 182 switch is able to associate each CPE with a different port and 183 installing a [prefix, port] filter in the filtering table is 184 sufficient. 186 Customer Network Service Provider Network 188 +---+ +-------+ 189 | H |------| CPE-1 |--- 190 +---+ +-------+ \ 192 \ 193 +---+ +-------+ \+----------+ +---------+ 194 | H |------| CPE-2 |------| SAVI |-----| DHCP | 195 +---+ +-------+ | Switch | | Server | 196 /+----------+ +---------+ 197 +---+ +-------+ / 198 | H |------| CPE-3 |---/ 199 +---+ +-------+ 201 Service Provider Network 203 3.1.2. SAVI switch is not the Access Switch 205 In this scenario the port can not be the anchor because there is a 206 layer 2 device (switch, DSLAM) between the CPE and the layer 3 switch 207 and all data traffic is coming from this port. If each CPE is behind 208 a dedicated vlan then the vlan can be used as the anchor and 209 installing a [prefix, vlan, port] filter is sufficient. However most 210 commonly all CPEs are within the same vlan (shared VLAN model). In 211 this case the MAC address of the CPEs has to be used as an anchor and 212 installing a [prefix, vlan, port, mac] filter in the filtering table 213 is required. 215 Customer Network Service Provider Network 217 +---+ +-------+ 218 | H |------| CPE-1 |--- 219 +---+ +-------+ \ 220 \ 221 +---+ +-------+ \+----------+ +---------+ +---------+ 222 | H |------| CPE-2 |------| Access |-----| SAVI |----| DHCP | 223 +---+ +-------+ | Switch | | Switch | | Server | 224 /+----------+ +---------+ +---------+ 225 +---+ +-------+ / 226 | H |------| CPE-3 |---/ 227 +---+ +-------+ 229 3.2. Enterprise Scenario 231 In this scenario, the source of the traffic is on-link, as shown in 232 the figure below: 234 Enterprise Network Internet 236 +------+ 237 | Host | 238 +------+ 239 \ 240 \ 241 +------+ +--------+ +-------------+ 242 | Host |-----| Switch |--------| Router |---- 243 +------+ /+--------+ +-------------+ 244 / 245 +------+ 246 | Host | 247 +------+ 249 The goal is to block traffic sourced from an address within an 250 unknown prefix. There are two situations where this might be useful: 251 The deployment setup makes no or limited usage of DHCP, and in 252 particular allow hosts to auto configure and use global addresses. 253 In this model, a node could allocate itself any address, including 254 non-topologically correct, using a forged prefix. Classical Source 255 Address Validation will learn these addresses via Neighbor Discovery 256 "snooping", install them into the Hardware Filtering Table and won't 257 be able to block traffic sourced from these addresses at the switch. 258 The router might be able to do so using Reverse Path Forwarding 259 check, but at the higher cost than the switch. Note that in this 260 scenario a [prefix, vlan] filter is sufficient. 262 The other scenario where the prefix-guard feature may be useful in an 263 enterprise deployment is when the switch is running out of filtering 264 entries to filter out individual addresses. In that case filtering 265 at the prefix level, while less efficient, has some value. 267 4. Conceptual Data Structures 269 This section describes a set of conceptual data structures that are 270 necessary for this mechanism. 272 Two key data structures are used to record bindings and their states. 273 The Binding State Table (BST) contains enties populated based on 274 snooping the RFC3633 or RFC4861 protocol. The Filtering Table (FT) 275 contains bindings used to filter data plane traffic. 277 4.1. Binding State Table (BST) 279 This table contains the state of bindings between source IPv6 prefix 280 and anchor. Entries are keyed on anchor and source IPv6 prefix. 281 Each entry has length of prefix, lifetime field containing the 282 lifetime of the entry, a field recording the state of the binding, 283 the default Router interface MAC address and a field for other 284 information. 286 +--------+--------+--------+-------+----------+--------+ 287 | Anchor | Prefix | Length | State | Lifetime | Other | 288 +--------+--------+--------+-------+----------+--------+ 289 | A | IP_1 | 56 | Bound | 65535 | | 290 +--------+--------+--------+-------+----------+--------+ 291 | A | IP_2 | 56 | Bound | 10000 | | 292 +--------+--------+--------+-------+----------+--------+ 293 | B | IP_3 | 60 |_Start | 1 | | 294 +--------+--------+--------+-------+----------+--------+ 296 Instance of BST 298 4.2. Filtering Table (FT) 300 This table contains the bindings between anchor and prefix/length, 301 keyed on anchor. This table does not contain any state of the 302 binding. It is used to filter packet. 304 +---------+--------+--------+ 305 |Anchor |Prefix | Length | 306 +---------+--------+--------+ 307 |A |IP_1 | 56 | 308 +---------+--------+--------+ 309 |A |IP_2 | 56 | 310 +---------+--------+--------+ 312 Instance of FT 314 4.3. Binding State Description 316 This section describes the binding states of this mechanism. 318 START A DHCPv6 request with IA_PD is received from customer router. 320 BOUND The prefix is assigned to the customer and bound to the anchor. 322 Note that states are only needed if the binding is created. The 323 specific procedures to set binding state to BOUND is internal to a 324 switch and is not specified further. 326 5. Anchor Attributes 328 This section specifies the anchor attributes involved in this 329 mechanism. 331 5.1. SAVI-Validation Attribute 333 The SAVI-Validation attribute should be set if and only if source 334 prefix validation must be performed on traffic from this anchor. 336 5.2. SAVI-DHCP Trust Attribute 338 The SAVI-DHCP Trust attribute must be set if and only if an anchor is 339 associated with a trustable DHCP server relay. 341 6. Recovery scenarios 343 [RFC6620] and [I-D.ietf-savi-dhcp] describe scenarios where the SAVI 344 device may not have a node binding and provide mechanisms to recover 345 upon receiving a data packet from an unknown source. It may also 346 happen that the switch looses the prefix information - the most 347 simple example being if the switch reboots. This will result in data 348 packets being dropped. 350 6.1. DHCP-PD assigned prefixes 352 The preferred mechanism is a proactive DHCPv6 Bulk Leasequery as 353 described in [RFC5460]. In the event of a reboot the SAVI device 354 SHOULD query the DHCP server with a LEASEQUERY message. In return 355 DHCP server will provide the prefix(es) information along with the 356 CPE(s) MAC and port. 358 Alternatively the same mechanism used for individually assigned 359 DHCPv6 addresses COULD be used for assigned prefixes as described in 360 [RFC5007]. Upon receiving a data packet for which no filter in FT 361 matches a LEASEQUERY message is sent to 362 All_DHCP_Relay_Agents_and_Servers multicast address. A query by IPv6 363 address allows the DHCP server to return the matching prefix 364 information along with the CPE MAC and port. 366 6.2. Router assigned prefixes 368 Upon reboot the SAVI device COULD proactively generate a RS message 369 on interfaces facing a router. 371 7. References 373 7.1. Normative References 375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 376 Requirement Levels", BCP 14, RFC 2119, March 1997. 378 7.2. Informative References 380 [I-D.ietf-savi-dhcp] 381 Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for 382 DHCP", draft-ietf-savi-dhcp-12 (work in progress), 383 February 2012. 385 [I-D.ietf-savi-framework] 386 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 387 "Source Address Validation Improvement Framework", 388 draft-ietf-savi-framework-06 (work in progress), 389 January 2012. 391 [I-D.kaippallimalil-savi-dhcp-pd] 392 Kaippallimalil, J., Xia, F., and J. Bi, "SAVI Solution for 393 Delegated IPv6 Prefixes", 394 draft-kaippallimalil-savi-dhcp-pd-01 (work in progress), 395 February 2010. 397 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 398 (IPv6) Specification", RFC 2460, December 1998. 400 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 401 and M. Carney, "Dynamic Host Configuration Protocol for 402 IPv6 (DHCPv6)", RFC 3315, July 2003. 404 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 405 Host Configuration Protocol (DHCP) version 6", RFC 3633, 406 December 2003. 408 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 409 Networks", BCP 84, RFC 3704, March 2004. 411 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 412 Neighbor Discovery (SEND)", RFC 3971, March 2005. 414 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 415 RFC 3972, March 2005. 417 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 418 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 419 September 2007. 421 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 422 Address Autoconfiguration", RFC 4862, September 2007. 424 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 425 "DHCPv6 Leasequery", RFC 5007, September 2007. 427 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 428 February 2009. 430 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 431 SAVI: First-Come, First-Served Source Address Validation 432 Improvement for Locally Assigned IPv6 Addresses", 433 RFC 6620, May 2012. 435 Appendix A. Contributors and Acknowledgments 437 Thanks to Eric Levy-Abegnoli for his valuable contributions. 439 Authors' Addresses 441 John Kaippallimalil 442 Huawei USA 443 1700 Alma Dr. Suite 500 444 Plano, TX 75075 445 USA 447 Email: john.kaippallimalil@huawei.com 449 Frank Xia 450 Huawei USA 451 1700 Alma Dr. Suite 500 452 Plano, TX 75075 453 USA 455 Email: xiayangsong@huawei.com 457 Jun bi 458 CERNET 459 Network Research Center, Tsinghua University 460 Beijing, 100084 461 China 463 Email: junbi@cernet.edu.cn 465 Vincent Ribiere (editor) 466 Cisco Systems 467 Village d'Entreprises Green Side - 400, Avenue Roumanille 468 Biot-Sophia Antipolis - 06410 469 France 471 Email: ribiere@cisco.com