idnits 2.17.1 draft-ietf-savi-mix-08.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 13, 2015) is 3271 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) ** Downref: Normative reference to an Informational RFC: RFC 7039 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SAVI J. Bi 2 Internet-Draft G. Yao 3 Intended status: Standards Track Tsinghua Univ. 4 Expires: November 14, 2015 J. Halpern 5 Newbridge 6 E. Levy-Abegnoli, Ed. 7 Cisco 8 May 13, 2015 10 SAVI for Mixed Address Assignment Methods Scenario 11 draft-ietf-savi-mix-08 13 Abstract 15 In case that multiple IP address assignment methods are allowed in a 16 network, the corresponding SAVI methods should be enabled to prevent 17 spoofing in the network. This document reviews how multiple SAVI 18 methods can coexist in a single SAVI device and collisions are 19 resolved when the same binding entry is discovered by two or more 20 methods. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 14, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 60 5. Recommendations for preventing collisions . . . . . . . . . . 5 61 6. Resolving binding collisions . . . . . . . . . . . . . . . . 5 62 6.1. Same Address on Different Binding Anchors . . . . . . . . 5 63 6.1.1. Basic preference . . . . . . . . . . . . . . . . . . 6 64 6.1.2. Overwritten preference . . . . . . . . . . . . . . . 6 65 6.1.3. Multiple SAVI Device Scenario . . . . . . . . . . . . 7 66 6.2. Same Address on the Same Binding Anchor . . . . . . . . . 7 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 8 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 10.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 There are currently several SAVI documents ([RFC6620], [savi-dhcp] 78 and [RFC7219]) that describe the different methods by which a switch 79 can discover and record bindings between a node's IP address and a 80 binding anchor and use that binding to perform source address 81 validation. Each of these documents specifies how to learn on-link 82 addresses, based on the method used for their assignment, 83 respectively: StateLess Autoconfiguration (SLAAC), Dynamic Host 84 Control Protocol (DHCP) and Secure Neighbor Discovery (SeND). Each 85 of these documents describes separately how one particular method 86 deals with address collisions (same address, different binding 87 anchor). 89 While multiple IP assignment methods can be used in the same layer-2 90 domain, a SAVI device might have to deal with a mix of SAVI methods. 91 The purpose of this document is to provide recommendations to avoid 92 collisions and to review collisions handling when two or more such 93 methods come up with competing bindings. 95 2. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 3. Problem Scope 103 There are three IP address assignment methods identified and reviewed 104 in one of the SAVI document: 106 1. StateLess Address AutoConfiguration (SLAAC) - reviewed in SAVI- 107 FCFS[RFC6620] 109 2. Dynamic Host Control Protocol address assignment (DHCP) - 110 reviewed in SAVI-DHCP[savi-dhcp] 112 3. Secure Neighbor Discovery (SeND) address assignment, reviewed in 113 SAVI-SEND[RFC7219] 115 In addition, there is a fourth method for installing a bindings on 116 the switch, referred to as "manual". It is based on manual (address 117 or prefix) binding configuration and is reviewed in [RFC6620] and 118 [RFC7039]. 120 All combinations of address assignment methods can coexist within a 121 layer-2 domain. A SAVI device will have to implement the 122 corresponding binding setup methods (referred to as a "SAVI method") 123 to enable Source Address Validation. If more than one SAVI method is 124 enabled on a SAVI device, the method is referred to as "mix address 125 assignment method" in this document. 127 SAVI methods are independent from each other, each one handling its 128 own entries. In the absence of reconciliation, each method will 129 reject packets sourced with an address it did not discovered. To 130 prevent addresses discovered by one method to be filtered out by 131 another, the binding table should be shared by all the solutions. 132 However this could create some conflict when the same entry is 133 discovered by two different methods: the purpose of this document is 134 of two folds: provide recommendations and method to avoid conflicts, 135 and resolve conflicts if and when they happen. Collisions happening 136 within a given method are outside the scope of this document. 138 4. Architecture 140 A SAVI device may enable multiple SAVI methods. This mechanism, 141 called SAVI-MIX, is proposed as a arbiter of the binding generation 142 algorithms, generating the final working binding entries Figure 1. 144 Once a SAVI method generates a candidate binding, it will request 145 SAVI-MIX to set up a corresponding entry in the binding table. Then 146 SAVI-MIX will check if there is any conflict in the binding table. A 147 new binding will be generated if there is no conflict. If there is a 148 conflict, SAVI-MIX will determine whether to replace the existing 149 binding or reject the candidate binding based on the policies 150 specified in Section 6. 152 The packet filtering will not be performed by each SAVI method 153 separately. Instead, SAVI-MIX will perform filtering based on the 154 entries in the binding table. 156 +--------------------------------------------------------+ 157 | | 158 | SAVI Device | 159 | | 160 | | 161 | +------+ +------+ +------+ | 162 | | SAVI | | SAVI | | SAVI | | 163 | | | | | | | | 164 | | FCFS | | DHCP | | SEND | | 165 | +------+ +------+ +------+ | 166 | | | | Binding | 167 | | | | setup | 168 | v v v requests | 169 | +------------------------------+ | 170 | | | | 171 | | SAVI-MIX | | 172 | | | | 173 | +------------------------------+ | 174 | | | 175 | v Final Binding | 176 | +--------------+ | 177 | | Binding | | 178 | | | | 179 | | Table | | 180 | +--------------+ | 181 | | 182 +--------------------------------------------------------+ 184 Figure 1: SAVI-Mix Architecture 186 Each entry in the binding table will contain the following fields: 188 1. IP source address 189 2. Binding anchor 191 3. Lifetime 193 4. Creation time 195 5. Binding methods: the methods which request the binding setup. 197 5. Recommendations for preventing collisions 199 If each solution has a dedicated address space, collisions won't 200 happen. Using non overlapping address space across SAVI solutions is 201 therefore recommended. To that end, one should: 203 1. DHCP/SLAAC: use non-overlapping prefix for DHCP and SLAAC. Set 204 the A bit in Prefix information option of Router Advertisement 205 for SLAAC prefix, and set the M bit in Router Advertisement for 206 DHCP prefix. For detail explanations on these bits, refer to 207 [RFC4861][RFC4862]. 209 2. SeND/non-SeND: avoid mixed environment (where SeND and non-SeND 210 nodes are deployed) or separate the prefixes announced to SeND 211 and non-SenD nodes. One way to separate the prefixes is to have 212 the router(s) announcing different (non-overlapping) prefixes to 213 SeND and to non-SeND nodes, using unicast Router Advertisements, 214 in response to SeND/non-SeND Router Solicit. 216 6. Resolving binding collisions 218 In situations where collisions could not be avoided, two cases should 219 be considered: 221 1. The same address is bound on two different binding anchors by 222 different SAVI methods. 224 2. The same address is bound on the same binding anchor by different 225 SAVI methods. 227 6.1. Same Address on Different Binding Anchors 229 This would typically occur in case assignment address spaces could 230 not be separated. For instance, an address is assigned by SLAAC on 231 node X, installed in the binding table using SAVI-FCFS, anchored to 232 "anchor-X". Later, the same address is assigned by DHCP to node Y, 233 and SAVI-DHCP will generate a candidate binding entry, anchored to 234 "anchor-Y". 236 6.1.1. Basic preference 238 The SAVI device must decide whom the address should be bound with 239 (anchor-X or anchor-Y in this example). Current standard documents 240 of address assignment methods have implied the prioritization 241 relationship (first-come). In the absence of any configuration or 242 protocol hint (see Section 6.1.2) the SAVI device should choose the 243 first-come binding anchor, whether it was learnt from SLACC, SeND or 244 DHCP. 246 6.1.2. Overwritten preference 248 There are two identified exceptions to the general prioritization 249 model, one of them being CGA addresses, another one controlled by the 250 configuration of the switch. 252 6.1.2.1. CGA preference 254 When CGA addresses are used, and a collision is detected, preference 255 should be given to the anchor that carries the CGA credentials once 256 they are verified, in particular the CGA parameters and the RSA 257 options. Note that if an attacker was trying to replay CGA 258 credentials, he would then compete on the base of fcfs (first-come, 259 first-serve). 261 6.1.2.2. configuration preference 263 For configuration driven exceptions, the SAVI device may allow the 264 configuration of a triplet ("prefix", "anchor", "method") or 265 ("address", "anchor", "method"), where at least one of ("anchor", 266 "method") should be specified. Later, if a DAD message is received 267 with the following conditions verified: 269 1. The target in the DAD message does not exist in the binding table 271 2. The target is within configured "prefix" (or equal to "address") 273 3. The anchor bound to target is different from the configured 274 anchor, when specified 276 4. The configured method, if any, is different from SAVI-FCFS 278 the switch should defend the address by responding to the DAD 279 message. It should not at this point install the entry into the 280 binding table. It will simply prevent the node to assign the 281 address, and will de-facto prioritize the configured anchor. This is 282 especially useful to protect well known bindings such as a static 283 address of a server over anybody, even when the server is down. It 284 is also a way to give priority to a binding learnt from SAVI-DHCP 285 over a binding for the same address, learnt from SAVI-FCFS. 287 6.1.3. Multiple SAVI Device Scenario 289 A single SAVI device doesn't have the information of all bound 290 addresses on the perimeter. Therefore it is not enough to lookup 291 local bindings to identify a collision. However, assuming DAD is 292 performed throughout the security perimeter for all addresses 293 regardless of the assignment method, then DAD response will inform 294 all SAVI devices about any collision. In that case, FCFS will apply 295 the same way as in a single switch scenario. If the admin configured 296 on one the switches a prefix (or a single static binding) to defend, 297 the DAD response generated by this switch will also prevent the 298 binding to be installed on other switches of the perimeter. 300 6.2. Same Address on the Same Binding Anchor 302 A binding may be set up on the same binding anchor by multiple 303 methods, typically SAVI-FCFS and SAVI-DHCP. If the binding lifetimes 304 obtained from the two methods are different, priority should be given 305 to 1) Manual configuration 2) SAVI-DHCP 3) SAVI-FCFS as the least 306 authoritative. The binding will be removed when the prioritized 307 lifetime expires, even if a less authoritative method had a longer 308 lifetime. 310 7. Security Considerations 312 SAVI MIX does not eliminate the security problems of each SAVI 313 method. Thus, the potential attacks, e.g., the DoS attack against 314 the SAVI device resource, can still happen. In deployment, the 315 security threats from each enabled SAVI methods should be prevented 316 by the corresponding proposed solutions in each document. 318 SAVI MIX is only a binding setup/removal arbitration mechanism. It 319 does not introduce additional security threats only if the principle 320 of decision is reasonable. However, there is a slight problem. SAVI 321 MIX is more tolerant about binding establish than each SAVI method 322 alone. As long as one of the enabled SAVI method generates a 323 binding, the binding will be applied. As a result, the allowed 324 binding number limitation or allowed binding setup rate limitation 325 will be the sum of all the enabled SAVI methods. In deployment, 326 whether a SAVI device is capable to support that resource requirement 327 should be evaluated. 329 8. IANA Considerations 331 This memo asks the IANA for no new parameters. 333 9. Acknowledgment 335 Thanks to Christian Vogt, Eric Nordmark, Marcelo Bagnulo Braun and 336 Jari Arkko for their valuable contributions. 338 10. References 340 10.1. Normative References 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, March 1997. 345 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 346 "Source Address Validation Improvement (SAVI) Framework", 347 RFC 7039, October 2013. 349 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 350 SAVI: First-Come, First-Served Source Address Validation 351 Improvement for Locally Assigned IPv6 Addresses", RFC 352 6620, May 2012. 354 [RFC7219] Bagnulo, M. and A. Garcia-Martinez, "SEcure Neighbor 355 Discovery (SEND) Source Address Validation Improvement 356 (SAVI)", RFC 7219, May 2014. 358 [savi-dhcp] 359 Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for 360 DHCP", draft-ietf-savi-dhcp-34 (work in progress), Feb 361 2015. 363 10.2. Informative References 365 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 366 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 367 September 2007. 369 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 370 Address Autoconfiguration", RFC 4862, September 2007. 372 Authors' Addresses 373 Jun Bi 374 Tsinghua University 375 Network Research Center, Tsinghua University 376 Beijing 100084 377 China 379 EMail: junbi@tsinghua.edu.cn 381 Guang Yao 382 Tsinghua University 383 Network Research Center, Tsinghua University 384 Beijing 100084 385 China 387 EMail: yaoguang.china@gmail.com 389 Joel M. Halpern 390 Newbridge Networks Inc 392 EMail: jmh@joelhalpern.com 394 Eric Levy-Abegnoli (editor) 395 Cisco Systems 396 Village d'Entreprises Green Side - 400, Avenue Roumanille 397 Biot-Sophia Antipolis 06410 398 France 400 EMail: elevyabe@cisco.com