idnits 2.17.1 draft-ietf-savi-mix-09.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 (July 19, 2015) is 3194 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: January 20, 2016 Baidu 6 J. Halpern 7 Newbridge 8 E. Levy-Abegnoli, Ed. 9 Cisco 10 July 19, 2015 12 SAVI for Mixed Address Assignment Methods Scenario 13 draft-ietf-savi-mix-09 15 Abstract 17 In case that multiple IP address assignment methods are allowed in a 18 network, the corresponding SAVI methods should be enabled to prevent 19 spoofing in the network. This document reviews how multiple SAVI 20 methods can coexist in a single SAVI device and collisions are 21 resolved when the same binding entry is discovered by two or more 22 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 January 20, 2016. 41 Copyright Notice 43 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 62 5. Recommendations for preventing collisions . . . . . . . . . . 5 63 6. Resolving binding collisions . . . . . . . . . . . . . . . . 5 64 6.1. Same Address on Different Binding Anchors . . . . . . . . 5 65 6.1.1. Basic preference . . . . . . . . . . . . . . . . . . 6 66 6.1.2. Overwritten preference . . . . . . . . . . . . . . . 6 67 6.1.3. Multiple SAVI Device Scenario . . . . . . . . . . . . 7 68 6.2. Same Address on the Same Binding Anchor . . . . . . . . . 7 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 8 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 10.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 There are currently several SAVI documents ([RFC6620], [RFC7513] and 80 [RFC7219]) that describe the different methods by which a switch can 81 discover and record bindings between a node's IP address and a 82 binding anchor and use that binding to perform source address 83 validation. Each of these documents specifies how to learn on-link 84 addresses, based on the method used for their assignment, 85 respectively: StateLess Autoconfiguration (SLAAC), Dynamic Host 86 Control Protocol (DHCP) and Secure Neighbor Discovery (SeND). Each 87 of these documents describes separately how one particular method 88 deals with address collisions (same address, different binding 89 anchor). 91 While multiple IP assignment methods can be used in the same layer-2 92 domain, a SAVI device might have to deal with a mix of SAVI methods. 93 The purpose of this document is to provide recommendations to avoid 94 collisions and to review collisions handling when two or more such 95 methods come up with competing bindings. 97 2. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 3. Problem Scope 105 Three different IP address assignment methods have been analyzed for 106 SAVI: 108 1. StateLess Address AutoConfiguration (SLAAC) - analyzed in SAVI- 109 FCFS[RFC6620] 111 2. Dynamic Host Control Protocol address assignment (DHCP) - 112 analyzed in SAVI-DHCP[RFC7513] 114 3. Secure Neighbor Discovery (SeND) address assignment, analyzed in 115 SAVI-SEND[RFC7219] 117 In addition, there is a fourth method for managing (i.e., creation, 118 management, deletion) a binding on the switch, referred to as 119 "manual". It is based on manual binding configuration and is 120 analyzed in [RFC6620] and [RFC7039]. 122 All combinations of address assignment methods can coexist within a 123 layer-2 domain. A SAVI device MUST implement the corresponding 124 binding setup methods (referred to as a "SAVI method") to enable 125 Source Address Validation. If more than one SAVI method is enabled 126 on a SAVI device, the method is referred to as "mix address 127 assignment method" in this document. 129 SAVI methods are independent from each other, each one handling its 130 own entries. In the absence of reconciliation, each method will 131 reject packets sourced with an address it did not discovered. To 132 prevent addresses discovered by one method to be filtered out by 133 another, the binding table should be shared by all the solutions. 134 However this could create some conflict when the same entry is 135 discovered by two different methods. The purpose of this document is 136 of two folds: provide recommendations and methods to avoid conflicts, 137 and resolve conflicts if and when they happen. Collisions happening 138 within a given method are outside the scope of this document. 140 4. Architecture 142 A SAVI device may enable multiple SAVI methods. This mechanism, 143 called SAVI-MIX, is proposed as a arbiter of the binding generation 144 algorithms, generating the final binding entries as illustrated in 145 Figure 1. Once a SAVI method generates a candidate binding, it will 146 request SAVI-MIX to set up a corresponding entry in the binding 147 table. Then SAVI-MIX will check if there is any conflict in the 148 binding table. A new binding will be generated if there is no 149 conflict. If there is a conflict, SAVI-MIX will determine whether to 150 replace the existing binding or reject the candidate binding based on 151 the policies specified in Section 6. 153 The packet filtering will not be performed by each SAVI method 154 separately. Instead, SAVI-MIX will perform filtering based on the 155 entries in the binding table. 157 +--------------------------------------------------------+ 158 | | 159 | SAVI Device | 160 | | 161 | | 162 | +------+ +------+ +------+ | 163 | | SAVI | | SAVI | | SAVI | | 164 | | | | | | | | 165 | | FCFS | | DHCP | | SEND | | 166 | +------+ +------+ +------+ | 167 | | | | Binding | 168 | | | | setup | 169 | v v v requests | 170 | +------------------------------+ | 171 | | | | 172 | | SAVI-MIX | | 173 | | | | 174 | +------------------------------+ | 175 | | | 176 | v Final Binding | 177 | +--------------+ | 178 | | Binding | | 179 | | | | 180 | | Table | | 181 | +--------------+ | 182 | | 183 +--------------------------------------------------------+ 185 Figure 1: SAVI-Mix Architecture 187 Each entry in the binding table will contain the following fields: 189 1. IP source address 190 2. Binding anchor 192 3. Lifetime 194 4. Creation time 196 5. Binding methods: the methods which request the binding setup. 198 5. Recommendations for preventing collisions 200 If each solution has a dedicated address space, collisions won't 201 happen. Using non overlapping address space across SAVI solutions is 202 therefore recommended. To that end, one should: 204 1. DHCP/SLAAC: use non-overlapping prefix for DHCP and SLAAC. Set 205 the A bit in Prefix information option of Router Advertisement 206 for SLAAC prefix, and set the M bit in Router Advertisement for 207 DHCP prefix. For detail explanations on these bits, refer to 208 [RFC4861][RFC4862]. 210 2. SeND/non-SeND: avoid mixed environment (where SeND and non-SeND 211 nodes are deployed) or separate the prefixes announced to SeND 212 and non-SenD nodes. One way to separate the prefixes is to have 213 the router(s) announcing different (non-overlapping) prefixes to 214 SeND and to non-SeND nodes, using unicast Router 215 Advertisements[RFC6085], in response to SeND/non-SeND Router 216 Solicit. 218 6. Resolving binding collisions 220 In situations where collisions could not be avoided, two cases should 221 be considered: 223 1. The same address is bound on two different binding anchors by 224 different SAVI methods. 226 2. The same address is bound on the same binding anchor by different 227 SAVI methods. 229 6.1. Same Address on Different Binding Anchors 231 This would typically occur in case assignment address spaces could 232 not be separated. For instance, an address is assigned by SLAAC on 233 node X, installed in the binding table using SAVI-FCFS, anchored to 234 "anchor-X". Later, the same address is assigned by DHCP to node Y, 235 and SAVI-DHCP will generate a candidate binding entry, anchored to 236 "anchor-Y". 238 6.1.1. Basic preference 240 The SAVI device must decide whom the address should be bound with 241 (anchor-X or anchor-Y in this example). Current standard documents 242 of address assignment methods have implied the prioritization 243 relationship, i.e., first-come. 245 1. SLAAC: s5.4.5 of [RFC4862] 247 2. DHCPv4: s3.1-p5 of [RFC2131] 249 3. DHCPv6: s18.1.8 of [RFC3315] 251 4. SeND: s8 of [RFC3971] 253 In the absence of any configuration or protocol hint (see 254 Section 6.1.2) the SAVI device should choose the first-come binding 255 anchor, whether it was learnt from SLAAC, SeND or DHCP. 257 6.1.2. Overwritten preference 259 There are two identified exceptions to the general prioritization 260 model, one of them being CGA addresses, another one controlled by the 261 configuration of the switch. 263 6.1.2.1. CGA preference 265 When CGA addresses are used, and a collision is detected, preference 266 should be given to the anchor that carries the CGA credentials once 267 they are verified, in particular the CGA parameters and the RSA 268 options. Note that if an attacker was trying to replay CGA 269 credentials, he would then compete on the base of "First-Come, First- 270 Served" (FCFS) principle. 272 6.1.2.2. configuration preference 274 For configuration driven exceptions, the SAVI device may allow the 275 configuration of a triplet ("prefix", "anchor", "method") or 276 ("address", "anchor", "method"), where at least one of ("anchor", 277 "method") should be specified. Later, if a DAD message is received 278 with the following conditions verified: 280 1. The target in the DAD message does not exist in the binding table 282 2. The target is within configured "prefix" (or equal to "address") 284 3. The anchor bound to target is different from the configured 285 anchor, when specified 287 4. The configured method, if any, is different from SAVI-FCFS 289 the switch should defend the address by responding to the DAD 290 message, with a NA message or an ARP response, on behalf of the 291 target node. Plain NA will be replied to SeND DAD. SeND accepts 292 plain NA for the first time (see s8 of [RFC3971]). The probability 293 for a SeND node to generate a colliding address more than one time is 294 trivial in practice, thus the response can effectively protect an 295 existing binding. 297 It should not at this point install the entry into the binding table. 298 It will simply prevent the node to assign the address, and will de- 299 facto prioritize the configured anchor. This is especially useful to 300 protect well known bindings such as a static address of a server over 301 anybody, even when the server is down. It is also a way to give 302 priority to a binding learnt from SAVI-DHCP over a binding for the 303 same address, learnt from SAVI-FCFS. 305 6.1.3. Multiple SAVI Device Scenario 307 A single SAVI device doesn't have the information of all bound 308 addresses on the perimeter. Therefore it is not enough to lookup 309 local bindings to identify a collision. However, assuming DAD is 310 performed throughout the security perimeter for all addresses 311 regardless of the assignment method, then DAD response will inform 312 all SAVI devices about any collision. In that case, FCFS will apply 313 the same way as in a single switch scenario. If the admin configured 314 on one the switches a prefix (or a single static binding) to defend, 315 the DAD response generated by this switch will also prevent the 316 binding to be installed on other switches of the perimeter. 318 6.2. Same Address on the Same Binding Anchor 320 A binding may be set up on the same binding anchor by multiple 321 methods, typically SAVI-FCFS and SAVI-DHCP. If the binding lifetimes 322 obtained from the two methods are different, priority should be given 323 to 1) Manual configuration 2) SAVI-DHCP 3) SAVI-FCFS as the least 324 authoritative. The binding will be removed when the prioritized 325 lifetime expires, even if a less authoritative method had a longer 326 lifetime. 328 7. Security Considerations 330 SAVI MIX does not eliminate the security problems of each SAVI 331 method. Thus, the potential attacks, e.g., the DoS attack against 332 the SAVI device resource, can still happen. In deployment, the 333 security threats from each enabled SAVI methods should be prevented 334 by the corresponding proposed solutions in each document. 336 SAVI MIX is only a binding setup/removal arbitration mechanism. It 337 does not introduce additional security threats only if the principle 338 of decision is reasonable. However, there is a slight problem. SAVI 339 MIX is more tolerant about binding establish than each SAVI method 340 alone. As long as one of the enabled SAVI method generates a 341 binding, the binding will be applied. As a result, the allowed 342 binding number limitation or allowed binding setup rate limitation 343 will be the sum of all the enabled SAVI methods. In deployment, 344 whether a SAVI device is capable to support that resource requirement 345 should be evaluated. 347 8. IANA Considerations 349 This memo asks the IANA for no new parameters. 351 9. Acknowledgment 353 Thanks to Christian Vogt, Eric Nordmark, Marcelo Bagnulo Braun and 354 Jari Arkko for their valuable contributions. 356 10. References 358 10.1. Normative References 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, March 1997. 363 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 364 RFC 2131, DOI 10.17487/RFC2131, March 1997, 365 . 367 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 368 C., and M. Carney, "Dynamic Host Configuration Protocol 369 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 370 2003, . 372 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 373 "SEcure Neighbor Discovery (SEND)", RFC 3971, 374 DOI 10.17487/RFC3971, March 2005, 375 . 377 [RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec, 378 "Address Mapping of IPv6 Multicast Packets on Ethernet", 379 RFC 6085, DOI 10.17487/RFC6085, January 2011, 380 . 382 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 383 SAVI: First-Come, First-Served Source Address Validation 384 Improvement for Locally Assigned IPv6 Addresses", 385 RFC 6620, DOI 10.17487/RFC6620, May 2012, 386 . 388 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 389 "Source Address Validation Improvement (SAVI) Framework", 390 RFC 7039, DOI 10.17487/RFC7039, October 2013, 391 . 393 [RFC7219] Bagnulo, M. and A. Garcia-Martinez, "SEcure Neighbor 394 Discovery (SEND) Source Address Validation Improvement 395 (SAVI)", RFC 7219, DOI 10.17487/RFC7219, May 2014, 396 . 398 [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address 399 Validation Improvement (SAVI) Solution for DHCP", 400 RFC 7513, DOI 10.17487/RFC7513, May 2015, 401 . 403 10.2. Informative References 405 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 406 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 407 DOI 10.17487/RFC4861, September 2007, 408 . 410 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 411 Address Autoconfiguration", RFC 4862, 412 DOI 10.17487/RFC4862, September 2007, 413 . 415 Authors' Addresses 417 Jun Bi 418 Tsinghua University 419 Network Research Center, Tsinghua University 420 Beijing 100084 421 China 423 EMail: junbi@tsinghua.edu.cn 424 Guang Yao 425 Baidu 426 Baidu Science and Technology Park, Building 1 427 Beijing 100193 428 China 430 EMail: yaoguang.china@gmail.com 432 Joel M. Halpern 433 Newbridge Networks Inc 435 EMail: jmh@joelhalpern.com 437 Eric Levy-Abegnoli (editor) 438 Cisco Systems 439 Village d'Entreprises Green Side - 400, Avenue Roumanille 440 Biot-Sophia Antipolis 06410 441 France 443 EMail: elevyabe@cisco.com