idnits 2.17.1 draft-ietf-savi-mix-07.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 a Security Considerations section. 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 (March 8, 2015) is 3330 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: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SAVI J. Bi 3 Internet-Draft G. Yao 4 Intended status: Standards Track Tsinghua Univ. 5 Expires: September 9, 2015 J. Halpern 6 Newbridge 7 E. Levy-Abegnoli, Ed. 8 Cisco 9 March 8, 2015 11 SAVI for Mixed Address Assignment Methods Scenario 12 draft-ietf-savi-mix-07 14 Abstract 16 In case that multiple IP address assignment methods are allowed in a 17 network, the corresponding SAVI methods should be enabled to prevent 18 spoofing in the network. This document reviews how multiple SAVI 19 methods can coexist in a single SAVI device and collisions are 20 resolved when the same binding entry is discovered by two or more 21 methods. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 9, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 61 5. Recommendations for preventing collisions . . . . . . . . . . 5 62 6. Resolving binding collisions . . . . . . . . . . . . . . . . 5 63 6.1. Same Address on Different Binding Anchors . . . . . . . . 5 64 6.1.1. Basic preference . . . . . . . . . . . . . . . . . . 6 65 6.1.2. Overwritten preference . . . . . . . . . . . . . . . 6 66 6.1.3. Multiple SAVI Device Scenario . . . . . . . . . . . . 7 67 6.2. Same Address on the Same Binding Anchor . . . . . . . . . 7 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 7 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 9.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. IANA Considerations 312 This memo asks the IANA for no new parameters. 314 8. Acknowledgment 316 Thanks to Christian Vogt, Eric Nordmark, Marcelo Bagnulo Braun and 317 Jari Arkko for their valuable contributions. 319 This document was generated using the xml2rfc tool. 321 9. References 323 9.1. Normative References 325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 326 Requirement Levels", BCP 14, RFC 2119, March 1997. 328 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 329 "Source Address Validation Improvement (SAVI) Framework", 330 RFC 7039, October 2013. 332 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 333 SAVI: First-Come, First-Served Source Address Validation 334 Improvement for Locally Assigned IPv6 Addresses", RFC 335 6620, May 2012. 337 [RFC7219] Bagnulo, M. and A. Garcia-Martinez, "SEcure Neighbor 338 Discovery (SEND) Source Address Validation Improvement 339 (SAVI)", RFC 7219, May 2014. 341 [savi-dhcp] 342 Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for 343 DHCP", draft-ietf-savi-dhcp-34 (work in progress), Feb 344 2015. 346 9.2. Informative References 348 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 349 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 350 September 2007. 352 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 353 Address Autoconfiguration", RFC 4862, September 2007. 355 Authors' Addresses 357 Jun Bi 358 Tsinghua University 359 Network Research Center, Tsinghua University 360 Beijing 100084 361 China 363 EMail: junbi@tsinghua.edu.cn 365 Guang Yao 366 Tsinghua University 367 Network Research Center, Tsinghua University 368 Beijing 100084 369 China 371 EMail: yaoguang.china@gmail.com 373 Joel M. Halpern 374 Newbridge Networks Inc 376 EMail: jmh@joelhalpern.com 377 Eric Levy-Abegnoli (editor) 378 Cisco Systems 379 Village d'Entreprises Green Side - 400, Avenue Roumanille 380 Biot-Sophia Antipolis 06410 381 France 383 EMail: elevyabe@cisco.com