idnits 2.17.1 draft-ietf-savi-mix-11.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 date (May 21, 2016) is 2896 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 7039 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SAVI J. Bi 3 Internet-Draft Tsinghua Univ. 4 Intended status: Standards Track G. Yao 5 Expires: November 22, 2016 Baidu 6 J. Halpern 7 Newbridge 8 E. Levy-Abegnoli, Ed. 9 Cisco 10 May 21, 2016 12 SAVI for Mixed Address Assignment Methods Scenario 13 draft-ietf-savi-mix-11 15 Abstract 17 In networks that use multiple techniques for address assignment, the 18 appropriate Source Address Validation Improvement (SAVI) methods must 19 be used to prevent spoofing of addresses assigned by each such 20 technique. This document reviews how multiple SAVI methods can 21 coexist in a single SAVI device and collisions are resolved when the 22 same binding entry is discovered by two or more methods. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 22, 2016. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 60 3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Recommendations for preventing collisions . . . . . . . . . . 5 63 6. Resolving binding collisions . . . . . . . . . . . . . . . . 6 64 6.1. Same Address on Different Binding Anchors . . . . . . . . 6 65 6.1.1. Basic preference . . . . . . . . . . . . . . . . . . 6 66 6.1.2. Overwritten preference . . . . . . . . . . . . . . . 7 67 6.1.3. Multiple SAVI Device Scenario . . . . . . . . . . . . 8 68 6.2. Same Address on the Same Binding Anchor . . . . . . . . . 8 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 9 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 10.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 There are currently several Source Address Validaiton Improvement 80 (SAVI) documents ([RFC6620], [RFC7513] and [RFC7219]) that describe 81 the different methods by which a switch can discover and record 82 bindings between a node's IP address and a binding anchor and use 83 that binding to perform source address validation. Each of these 84 documents specifies how to learn on-link addresses, based on the 85 technique used for their assignment, respectively: StateLess 86 Autoconfiguration (SLAAC), Dynamic Host Control Protocol (DHCP) and 87 Secure Neighbor Discovery (SeND). Each of these documents describes 88 separately how one particular SAVI method deals with address 89 collisions (same address, different binding anchor). 91 While multiple IP assignment techniques can be used in the same 92 layer-2 domain, this means that a single SAVI device might have to 93 deal with a combination or mix of SAVI methods. The purpose of this 94 document is to provide recommendations to avoid collisions and to 95 review collisions handling when two or more such methods come up with 96 competing bindings. 98 2. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 3. Problem Scope 106 Three different IP address assignment techniques have been analyzed 107 for SAVI: 109 1. StateLess Address AutoConfiguration (SLAAC) - analyzed in SAVI- 110 FCFS[RFC6620] 112 2. Dynamic Host Control Protocol address assignment (DHCP) - 113 analyzed in SAVI-DHCP[RFC7513] 115 3. Secure Neighbor Discovery (SeND) address assignment, analyzed in 116 SAVI-SEND[RFC7219] 118 In addition, there is a fourth technique for managing (i.e., 119 creation, management, deletion) a binding on the switch, referred to 120 as "manual". It is based on manual binding configuration and is 121 analyzed in [RFC6620] and [RFC7039]. 123 All combinations of address assignment techniques can coexist within 124 a layer-2 domain. A SAVI device MUST implement the corresponding 125 binding setup methods (referred to as a "SAVI method") for each such 126 technique that is in use if it is to provide Source Address 127 Validation. If more than one SAVI method is enabled on a SAVI 128 device, the method is referred to as "mix address assignment method" 129 in this document. 131 SAVI methods are normally viewed as independent from each other, each 132 one handling its own entries. If multiple methods are used in the 133 same device without coordination, each method will attempt to reject 134 packets sourced with any addresses that method did not discover. To 135 prevent addresses discovered by one SAVI method from being filtered 136 out by another method, the SAVI binding table should be shared by all 137 the SAVI methods in use in the device. This in turn could create 138 some conflict when the same entry is discovered by two different 139 methods. The purpose of this document is of two folds: provide 140 recommendations and methods to avoid conflicts, and to resolve 141 conflicts when they happen. Collisions happening within a given 142 method are outside the scope of this document. 144 4. Architecture 146 A SAVI device may implement ant use multiple SAVI methods. This 147 mechanism, called SAVI-MIX, is proposed as a arbiter of the binding 148 generation algorithms from these multiple methods, generating the 149 final binding entries as illustrated in Figure 1. Once a SAVI method 150 generates a candidate binding, it will request SAVI-MIX to set up a 151 corresponding entry in the binding table. Then SAVI-MIX will check 152 if there is any conflict in the binding table. A new binding will be 153 generated if there is no conflict. If there is a conflict, SAVI-MIX 154 will determine whether to replace the existing binding or reject the 155 candidate binding based on the policies specified in Section 6. 157 As a result of this, the packet filtering in the SAVI device will not 158 be performed by each SAVI method separately. Instead, the table 159 resulting from applying SAVI-MIX will be used to perform filtering. 160 Thus the filtering is based on the combined results of the differents 161 SAVI mechanisms. 163 +--------------------------------------------------------+ 164 | | 165 | SAVI Device | 166 | | 167 | | 168 | +------+ +------+ +------+ | 169 | | SAVI | | SAVI | | SAVI | | 170 | | | | | | | | 171 | | FCFS | | DHCP | | SEND | | 172 | +------+ +------+ +------+ | 173 | | | | Binding | 174 | | | | setup | 175 | v v v requests | 176 | +------------------------------+ | 177 | | | | 178 | | SAVI-MIX | | 179 | | | | 180 | +------------------------------+ | 181 | | | 182 | v Final Binding | 183 | +--------------+ | 184 | | Binding | | 185 | | | | 186 | | Table | | 187 | +--------------+ | 188 | | 189 +--------------------------------------------------------+ 191 Figure 1: SAVI-Mix Architecture 193 Each entry in the binding table will contain the following fields: 195 1. IP source address 197 2. Binding anchor 199 3. Lifetime 201 4. Creation time 203 5. Binding methods: the SAVI method used for this entry. 205 5. Recommendations for preventing collisions 207 If each address assignment technique uses a separate portion of the 208 IP address space, collisions won't happen. Using non overlapping 209 address space across address assignment techniques, and thus across 210 SAVI methods is therefore recommended. To that end, one should: 212 1. DHCP/SLAAC: use non-overlapping prefix for DHCP and SLAAC. Set 213 the A bit in Prefix information option of Router Advertisement 214 for SLAAC prefix, and set the M bit in Router Advertisement for 215 DHCP prefix. For detail explanations on these bits, refer to 216 [RFC4861][RFC4862]. 218 2. SeND/non-SeND: avoid mixed environment (where SeND and non-SeND 219 nodes are deployed) or separate the prefixes announced to SeND 220 and non-SenD nodes. One way to separate the prefixes is to have 221 the router(s) announcing different (non-overlapping) prefixes to 222 SeND and to non-SeND nodes, using unicast Router 223 Advertisements[RFC6085], in response to SeND/non-SeND Router 224 Solicit. 226 6. Resolving binding collisions 228 In situations where collisions can not be avoided by assignment 229 separation, two cases should be considered: 231 1. The same address is bound on two different binding anchors by 232 different SAVI methods. 234 2. The same address is bound on the same binding anchor by different 235 SAVI methods. 237 6.1. Same Address on Different Binding Anchors 239 This would typically occur in case assignment address spaces could 240 not be separated. For instance, an address is assigned by SLAAC on 241 node X, installed in the binding table using SAVI-FCFS, anchored to 242 "anchor-X". Later, the same address is assigned by DHCP to node Y, 243 and SAVI-DHCP will generate a candidate binding entry, anchored to 244 "anchor-Y". 246 6.1.1. Basic preference 248 The SAVI device must decide to whom the address should be bound 249 (anchor-X or anchor-Y in this example). Current standard documents 250 of address assignment methods have implied the prioritization 251 relationship based on order in time, i.e., first-come first-served. 253 1. SLAAC: s5.4.5 of [RFC4862] 255 2. DHCPv4: s3.1-p5 of [RFC2131] 256 3. DHCPv6: s18.1.8 of [RFC3315] 258 4. SeND: s8 of [RFC3971] 260 In the absence of any configuration or protocol hint (see 261 Section 6.1.2) the SAVI device should choose the first-come binding 262 anchor, whether it was learnt from SLAAC, SeND or DHCP. 264 6.1.2. Overwritten preference 266 There are two identified exceptions to the general prioritization 267 model, one of them being CGA addresses, another one controlled by the 268 configuration of the switch. 270 6.1.2.1. CGA preference 272 When CGA addresses are used, and a collision is detected, preference 273 should be given to the anchor that carries the CGA credentials once 274 they are verified, in particular the CGA parameters and the RSA 275 options. Note that if an attacker was trying to replay CGA 276 credentials, he would then compete on the base of "First-Come, First- 277 Served" (FCFS) principle. 279 6.1.2.2. configuration preference 281 For configuration driven exceptions, the SAVI device may allow the 282 configuration of a triplet ("prefix", "anchor", "method") or 283 ("address", "anchor", "method"). The "prefix" or "address" 284 represents the address or address prefix to which this preference 285 entry applies. The "anchor" is the value of a know binding anchor 286 that this device expects to see using this address or addresses from 287 this prefix. The "method" is the SAVI method that this device 288 expects to use in validating address binding entries from the address 289 or prefix. At least one of "anchor" and "method" MUST be specified. 290 Later, if a DAD message is received with the following conditions 291 verified: 293 1. The target in the DAD message does not exist in the binding table 295 2. The target is within configured "prefix" (or equal to "address") 297 3. The anchor bound to target is different from the configured 298 anchor, when specified 300 4. The configured method, if any, is different from SAVI-FCFS 302 The switch should defend the address by responding to the DAD 303 message, with a NA message, on behalf of the target node. SeND nodes 304 in the network MUST disable the option to ignore unsecured 305 advertisements (see s8 of [RFC3971]). If the option is enabled, the 306 case is outside the scope of this document. 308 It should not install the entry into the binding table. It will 309 simply prevent the node to assign the address, and will de-facto 310 prioritize the configured anchor. This is especially useful to 311 protect well known bindings such as a static address of a server over 312 anybody, even when the server is down. It is also a way to give 313 priority to a binding learnt from SAVI-DHCP over a binding for the 314 same address, learnt from SAVI-FCFS. 316 6.1.3. Multiple SAVI Device Scenario 318 A single SAVI device doesn't have the information of all bound 319 addresses on the perimeter. Therefore it is not enough to lookup 320 local bindings to identify a collision. However, assuming DAD is 321 performed throughout the security perimeter for all addresses 322 regardless of the assignment method, then DAD response will inform 323 all SAVI devices about any collision. In that case, FCFS will apply 324 the same way as in a single switch scenario. If the admin configured 325 on one the switches a prefix (or a single static binding) to defend, 326 the DAD response generated by this switch will also prevent the 327 binding to be installed on other switches of the perimeter. 329 6.2. Same Address on the Same Binding Anchor 331 A binding may be set up on the same binding anchor by multiple 332 methods, typically SAVI-FCFS and SAVI-DHCP. If the binding lifetimes 333 obtained from the two methods are different, priority should be given 334 to 1) Manual configuration 2) SAVI-DHCP 3) SAVI-FCFS as the least 335 authoritative. The binding will be removed when the prioritized 336 lifetime expires, even if a less authoritative method had a longer 337 lifetime. 339 7. Security Considerations 341 SAVI MIX does not eliminate the security problems of each SAVI 342 method. Thus, the potential attacks, e.g., the DoS attack against 343 the SAVI device resource, can still happen. In deployment, the 344 security threats from each enabled SAVI methods should be prevented 345 by the corresponding proposed solutions in each document. 347 SAVI MIX is only a binding setup/removal arbitration mechanism. It 348 does not introduce additional security threats if the principle of 349 decision is reasonable. However, there is a slight problem. SAVI 350 MIX is more tolerant about binding establishment than each SAVI 351 method alone. As long as one of the enabled SAVI methods generates a 352 binding, the binding will be applied. As a result, the allowed 353 number of SAVI bindings or allowed SAVI binding setup rate will be 354 the sum of that of all the enabled SAVI methods. In deployment, 355 whether a SAVI device is capable of supporting the resulting resource 356 requirements should be evaluated. 358 8. IANA Considerations 360 This memo asks the IANA for no new parameters. 362 9. Acknowledgment 364 Thanks to Christian Vogt, Eric Nordmark, Marcelo Bagnulo Braun and 365 Jari Arkko for their valuable contributions. 367 10. References 369 10.1. Normative References 371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 372 Requirement Levels", BCP 14, RFC 2119, 373 DOI 10.17487/RFC2119, March 1997, 374 . 376 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 377 RFC 2131, DOI 10.17487/RFC2131, March 1997, 378 . 380 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 381 C., and M. Carney, "Dynamic Host Configuration Protocol 382 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 383 2003, . 385 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 386 "SEcure Neighbor Discovery (SEND)", RFC 3971, 387 DOI 10.17487/RFC3971, March 2005, 388 . 390 [RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec, 391 "Address Mapping of IPv6 Multicast Packets on Ethernet", 392 RFC 6085, DOI 10.17487/RFC6085, January 2011, 393 . 395 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 396 SAVI: First-Come, First-Served Source Address Validation 397 Improvement for Locally Assigned IPv6 Addresses", 398 RFC 6620, DOI 10.17487/RFC6620, May 2012, 399 . 401 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 402 "Source Address Validation Improvement (SAVI) Framework", 403 RFC 7039, DOI 10.17487/RFC7039, October 2013, 404 . 406 [RFC7219] Bagnulo, M. and A. Garcia-Martinez, "SEcure Neighbor 407 Discovery (SEND) Source Address Validation Improvement 408 (SAVI)", RFC 7219, DOI 10.17487/RFC7219, May 2014, 409 . 411 [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address 412 Validation Improvement (SAVI) Solution for DHCP", 413 RFC 7513, DOI 10.17487/RFC7513, May 2015, 414 . 416 10.2. Informative References 418 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 419 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 420 DOI 10.17487/RFC4861, September 2007, 421 . 423 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 424 Address Autoconfiguration", RFC 4862, 425 DOI 10.17487/RFC4862, September 2007, 426 . 428 Authors' Addresses 430 Jun Bi 431 Tsinghua University 432 Network Research Center, Tsinghua University 433 Beijing 100084 434 China 436 EMail: junbi@tsinghua.edu.cn 438 Guang Yao 439 Baidu 440 Baidu Science and Technology Park, Building 1 441 Beijing 100193 442 China 444 EMail: yaoguang.china@gmail.com 445 Joel M. Halpern 446 Newbridge Networks Inc 448 EMail: jmh@joelhalpern.com 450 Eric Levy-Abegnoli (editor) 451 Cisco Systems 452 Village d'Entreprises Green Side - 400, Avenue Roumanille 453 Biot-Sophia Antipolis 06410 454 France 456 EMail: elevyabe@cisco.com