idnits 2.17.1 draft-ietf-savi-mix-02.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 27, 2012) is 4375 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) No issues found here. Summary: 0 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: October 29, 2012 J. Halpern 6 Newbridge 7 E. Levy-Abegnoli, Ed. 8 Cisco 9 April 27, 2012 11 SAVI for Mixed Address Assignment Methods Scenario 12 draft-ietf-savi-mix-02 14 Abstract 16 This document reviews how multiple address discovery methods can 17 coexist in a single SAVI device and collisions are resolved when the 18 same binding entry is discovered by two or more methods. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 29, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 68 3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 4. Recommendations for preventing collisions . . . . . . . . . . . 4 70 5. Handing binding collisions . . . . . . . . . . . . . . . . . . 4 71 5.1. Same Address on Different Binding Anchors . . . . . . . . . 5 72 5.1.1. Basic preference . . . . . . . . . . . . . . . . . . . 5 73 5.1.2. Overwritten preference . . . . . . . . . . . . . . . . 5 74 5.1.3. Multiple SAVI Device Scenario . . . . . . . . . . . . . 6 75 5.2. Same Address on the Same Binding Anchor . . . . . . . . . . 6 76 6. Disscusion on Assumption Conflict . . . . . . . . . . . . . . . 6 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 79 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 7 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 10.1. Informative References . . . . . . . . . . . . . . . . . . 8 82 10.2. Normative References . . . . . . . . . . . . . . . . . . . 8 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 85 1. Introduction 87 There are currently several documents [savi-fcfs], [savi-dhcp] and 88 [savi-send] that describe the different methods by which a switch can 89 discover and record bindings between a node's layer3 address and a 90 binding anchor and use that binding to perform Source Address 91 Validation. Each of these documents specifies how to learn on-link 92 addresses, based on the method used for their assignment, 93 respectively: StateLess Autoconfiguration (SLAAC), Dynamic Host 94 Control Protocol (DHCP) and Secure Neighbor Discovery (SeND). Each 95 of these documents describes separately how one particular discovery 96 method deals with address collisions (same address, different 97 anchor). 99 While multiple assignment methods can be used in the same layer2 100 domain, a SAVI device might have to deal with a mix of binding 101 discovery methods. The purpose of this document is to provide 102 recommendations to avoid collisions and to review collisions handling 103 when two or more such methods come up with competing bindings. 105 2. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [rfc2119]. 111 3. Problem Scope 113 There are three address assignment methods identified and reviewed in 114 one of the SAVI document: 116 1. StateLess Address AutoConfiguration (SLAAC) - reviewed in 117 [savi-fcfs] 119 2. Dynamic Host Control Protocol address assignment (DHCP) - 120 reviewed in [savi-dhcp] 122 3. Secure Neighbor Discovery (SeND) address assignment, reviewed in 123 [savi-send] 125 Each address assignment method corresponds to a binding discovery 126 method: SAVI-FCFS, SAVI-DHCP and SAVI-SeND. In addition, there is a 127 fourth method for installing a bindings on the switch, referred to as 128 "manual". It is based on manual (address or prefix) binding 129 configuration and is reviewed in [savi-fcfs] and [savi-framework]. 131 All combinations of address assignment methods can coexist within a 132 layer2 domain. A SAVI device will have to implement the 133 corresponding SAVI discovery methods (referred to as a "SAVI 134 solution") to enable Source Address Validation. If more than one 135 SAVI solution is enabled on a SAVI device, the method is referred to 136 as "mix address assignment method" in this document. 138 SAVI solutions are independent from each other, each one handling its 139 own entries. In the absence of reconciliation, each solution will 140 reject packets sourced with an address it did not discovered. To 141 prevent addresses discovered by one solution to be filtered out by 142 another, the binding table should be shared by all the solutions. 143 However this could create some conflict when the same entry is 144 discovered by two different methods: the purpose of this document is 145 of two folds: provide recommendations and method to avoid conflicts, 146 and resolve conflicts if and when they happen. Collisions happening 147 within a given solution are outside the scope of this document. 149 4. Recommendations for preventing collisions 151 If each solution has a dedicated address space, collisions won't 152 happen. Using non overlapping address space across SAVI solutions is 153 therefore recommended. To that end, one should: 155 1. DHCP/SLAAC: use non-overlapping prefix for DHCP and SLAAC. Set 156 the A bit in Prefix information option of Router Advertisement 157 for SLAAC prefix. And set the M bit in Router Advertisement for 158 DHCP prefix. For detail explanations on these bits, refer to 159 [rfc4861][rfc4862]. 161 2. SeND/non-SeND: avoid mixed environment (where SeND and non-SeND 162 nodes are deployed) or separate the prefixes announced to SeND 163 and non-SenD nodes. One way to separate the prefixes is to have 164 the router(s) announcing different (non-overlapping) prefixes to 165 SeND and to non-SeND nodes, using unicast Router Advertisements, 166 in response to SeND/non-SeND Router Solicit. 168 5. Handing binding collisions 170 In situations where collisions could not be avoided, two cases should 171 be considered: 173 1. The same address is bound on two different binding anchors by 174 different SAVI solutions. 176 2. The same address is bound on the same binding anchor by different 177 SAVI solutions. 179 5.1. Same Address on Different Binding Anchors 181 This would typically occur in case assignment address spaces could 182 not be separated. For instance,overl an address is assigned by SLAAC 183 on node X, installed in the binding table using SAVI-FCFS, anchored 184 to "anchor-X". Later, the same address is assigned by DHCP to node 185 Y, as a potential candidate in the same binding table, anchored to 186 "anchor-Y". 188 5.1.1. Basic preference 190 The SAVI device must decide whom the address should be bound with 191 (anchor-X or anchor-Y in this example). Current standard documents 192 of address assignment methods have implied the prioritization 193 relationship (first-come). In the absence of any configuration or 194 protocol hint (see Section 5.1.2) the SAVI device should choose the 195 first-come entry, whether it was learnt from SLACC, SeND or DHCP. 197 5.1.2. Overwritten preference 199 There are two identified exceptions to the general prioritization 200 model, one of them being CGA addresses, another one controlled by the 201 configuration of the switch: 203 1. When CGA addresses are used, and a collision is detected, 204 preference should be given to the anchor that carries the CGA 205 credentials once they are verified, in particular the CGA 206 parameters and the RSA options. Note that if an attacker was 207 trying to replay CGA credentials, he would then compete on the 208 base of fcfs (first-come, first-serve). 210 2. The SAVI device should allow the configuration of a triplet 211 ("prefix", "anchor", "method") or ("address", "anchor", 212 "method"). Later, if a DAD message is received for a target 213 within "prefix" (or equal "address") bound to "anchor1" 214 (different from "anchor"), or via a discovery method different 215 from "method", the switch should defend the address by responding 216 to the DAD message. It should not at this point install the 217 entry into the binding table. It will simply prevent the node to 218 assign the address, and will de-facto prioritize the configured 219 anchor or configured assignment method for that address. This is 220 especially useful to protect well known bindings such as a static 221 address of a server over anybody, even when the server is down. 222 It is also a way to give priority to a binding learnt from SAVI- 223 DHCP over a binding for the same address, learnt from SAVI-FCFS. 225 5.1.3. Multiple SAVI Device Scenario 227 A single SAVI device doesn't have the information of all bound 228 addresses on the perimeter. Therefore it is not enough to lookup 229 local bindings to identify a collision. However, assuming DAD is 230 performed throughout the security perimeter for all addresses 231 regardless of the assignment method, then DAD response will inform 232 all SAVI devices about any collision. In that case, FCFS will apply 233 the same way as in a single switch scenario. If the admin configured 234 on one the switches a prefix (or a single static binding) to defend, 235 the DAD response generated by this switch will also prevent the 236 binding to be installed on other switches of the perimeter. 238 5.2. Same Address on the Same Binding Anchor 240 A binding may be set up on the same binding anchor by multiple 241 solutions. For example, if SAVI-FCFS and SAVI-DHCP are both enabled 242 on one SAVI device, a DHCP address be bound by both SAVI instances. 244 There is no conflict if the binding is valid in all the solutions. 245 However, the binding lifetimes of different solutions can be 246 different. If one SAVI instance changes the state of a binding to 247 invalid on lifetime expires, conflict will happen. 249 The solution proposed is to keep a binding as long as possible. A 250 binding is kept until it has been required to be removed by all the 251 solutions that ever set up it. 253 6. Disscusion on Assumption Conflict 255 Different assumptions are made as the basis of solutions. The 256 assumptions of each solution specified which entity is the origin of 257 the trust. Indeed, the binding between address and binding anchor is 258 actually the derivative of the assumptions based on the principles of 259 binding set up. The conflict in identifier field of address is 260 specified in the above sections. This section specifies the conflict 261 in prefix field from different assumptions. 263 SAVI FCFS and SAVI DHCP trust routers to get the legitimate prefixes 264 for local link; however, only RADV validated by SEND is trusted by 265 SAVI SEND. In this solution, if any SAVI solution regards a prefix 266 to be valid, the prefix is valid for the whole mechanism. 268 7. Security Considerations 270 As described in [savi-framework], this solution cannot strictly 271 prevent spoofing. There are two scenarios in which spoofing can 272 still happen: 274 1. The binding anchor is spoofable. if the binding anchor is 275 spoofable, e.g., plain MAC address, an attacker can use forged 276 binding anchor to send packet which will not be regarded as 277 spoofing by SAVI device. Indeed, using binding anchor that can 278 be easily spoofed is dangerous. An attacker can use the binding 279 anchor of another host to perform a lot of DHCP procedures, and 280 the SAVI device will refuse to set up new binding for the host 281 whenever the binding number limitation has been reached. Thus, 282 it is RECOMMENDED to use strong enough binding anchor, e.g., 283 switch port, secure association in 802.11ae/af and 802.11i. 285 2. The binding anchor is shared by more than one host. If the 286 binding anchor is shared by more than one host, they can spoof 287 the addresses of each other. For example, a number of hosts can 288 attach to the same switch port of a SAVI device through a hub. 289 The SAVI device cannot distinguish packets from different hosts 290 and thus the spoofing between them will not be detected. This 291 problem can be solved through not sharing binding anchor between 292 hosts. 294 8. IANA Considerations 296 This memo asks the IANA for no new parameters. 298 Note to RFC Editor: This section will have served its purpose if it 299 correctly tells IANA that no new assignments or registries are 300 required, or if those assignments or registries are created during 301 the RFC publication process. From the authors' perspective, it may 302 therefore be removed upon publication as an RFC at the RFC Editor's 303 discretion. 305 9. Acknowledgment 307 Thanks to Christian Vogt, Eric Nordmark, Marcelo Bagnulo Braun and 308 Jari Arkko for their valuable contributions. 310 This document was generated using the xml2rfc tool. 312 10. References 313 10.1. Informative References 315 [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", RFC 2119, BCP 14, Match 1997. 318 10.2. Normative References 320 [rfc4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 321 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 322 September 2007. 324 [rfc4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 325 Address Autoconfiguration", RFC 4862, September 2007. 327 [savi-dhcp] 328 Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for 329 DHCP", draft-ietf-savi-dhcp-12 (work in progress), 330 February 2012. 332 [savi-fcfs] 333 Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS- 334 SAVI: First-Come First-Serve Source-Address Validation for 335 Locally Assigned Addresses", draft-ietf-savi-fcfs-14 (work 336 in progress), February 2012. 338 [savi-framework] 339 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 340 "Source Address Validation Improvement Framework", 341 draft-ietf-savi-framework-06 (work in progress), 342 December 2011. 344 [savi-send] 345 Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source- 346 Address Validation Implementation", 347 draft-ietf-savi-send-06 (work in progress), October 2011. 349 Authors' Addresses 351 Jun Bi 352 Tsinghua University 353 Network Research Center, Tsinghua University 354 Beijing 100084 355 China 357 Email: junbi@tsinghua.edu.cn 358 Guang Yao 359 Tsinghua University 360 Network Research Center, Tsinghua University 361 Beijing 100084 362 China 364 Email: yaoguang@cernet.edu.cn 366 Joel M. Halpern 367 Newbridge Networks Inc 369 Email: jmh@joelhalpern.com 371 Eric Levy-Abegnoli (editor) 372 Cisco Systems 373 Village d'Entreprises Green Side - 400, Avenue Roumanille 374 Biot-Sophia Antipolis 06410 375 France 377 Email: elevyabe@cisco.com