idnits 2.17.1 draft-ietf-savi-mix-03.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 (November 6, 2012) is 4183 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: May 10, 2013 J. Halpern 6 Newbridge 7 E. Levy-Abegnoli, Ed. 8 Cisco 9 November 6, 2012 11 SAVI for Mixed Address Assignment Methods Scenario 12 draft-ietf-savi-mix-03 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 May 10, 2013. 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. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 5. Security Perimeter in SAVI MIX . . . . . . . . . . . . . . . . 5 71 6. Recommendations for preventing collisions . . . . . . . . . . 6 72 7. Handing binding collisions . . . . . . . . . . . . . . . . . . 7 73 7.1. Same Address on Different Binding Anchors . . . . . . . . 7 74 7.1.1. Basic preference . . . . . . . . . . . . . . . . . . . 7 75 7.1.2. Overwritten preference . . . . . . . . . . . . . . . . 7 76 7.1.3. Multiple SAVI Device Scenario . . . . . . . . . . . . 8 77 7.2. Same Address on the Same Binding Anchor . . . . . . . . . 8 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 9 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 11.1. Informative References . . . . . . . . . . . . . . . . . . 10 83 11.2. Normative References . . . . . . . . . . . . . . . . . . . 10 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 86 1. Introduction 88 There are currently several documents [savi-fcfs], [savi-dhcp] and 89 [savi-send] that describe the different methods by which a switch can 90 discover and record bindings between a node's layer3 address and a 91 binding anchor and use that binding to perform Source Address 92 Validation. Each of these documents specifies how to learn on-link 93 addresses, based on the method used for their assignment, 94 respectively: StateLess Autoconfiguration (SLAAC), Dynamic Host 95 Control Protocol (DHCP) and Secure Neighbor Discovery (SeND). Each 96 of these documents describes separately how one particular discovery 97 method deals with address collisions (same address, different 98 anchor). 100 While multiple assignment methods can be used in the same layer2 101 domain, a SAVI device might have to deal with a mix of binding 102 discovery methods. The purpose of this document is to provide 103 recommendations to avoid collisions and to review collisions handling 104 when two or more such methods come up with competing bindings. 106 2. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [rfc2119]. 112 3. Problem Scope 114 There are three address assignment methods identified and reviewed in 115 one of the SAVI document: 117 1. StateLess Address AutoConfiguration (SLAAC) - reviewed in 118 [savi-fcfs] 120 2. Dynamic Host Control Protocol address assignment (DHCP) - 121 reviewed in [savi-dhcp] 123 3. Secure Neighbor Discovery (SeND) address assignment, reviewed in 124 [savi-send] 126 Each address assignment method corresponds to a binding discovery 127 method: SAVI-FCFS, SAVI-DHCP and SAVI-SeND. In addition, there is a 128 fourth method for installing a bindings on the switch, referred to as 129 "manual". It is based on manual (address or prefix) binding 130 configuration and is reviewed in [savi-fcfs] and [savi-framework]. 132 All combinations of address assignment methods can coexist within a 133 layer2 domain. A SAVI device will have to implement the 134 corresponding SAVI discovery methods (referred to as a "SAVI 135 solution") to enable Source Address Validation. If more than one 136 SAVI solution is enabled on a SAVI device, the method is referred to 137 as "mix address assignment method" in this document. 139 SAVI solutions are independent from each other, each one handling its 140 own entries. In the absence of reconciliation, each solution will 141 reject packets sourced with an address it did not discovered. To 142 prevent addresses discovered by one solution to be filtered out by 143 another, the binding table should be shared by all the solutions. 144 However this could create some conflict when the same entry is 145 discovered by two different methods: the purpose of this document is 146 of two folds: provide recommendations and method to avoid conflicts, 147 and resolve conflicts if and when they happen. Collisions happening 148 within a given solution are outside the scope of this document. 150 4. Architecture 152 A SAVI device may enable multiple SAVI methods. This mechanism, 153 called SAVI-MIX, is proposed as a layer between the binding 154 generation algorithems and the binding database which contains the 155 working binding entries Figure 1. SAVI methods, i.e., SAVI-FCFS, 156 SAVI-DHCP, SAVI-SEND, do not have exclusive binding tables. Once a 157 SAVI method generates a candidate binding, it will request SAVI-MIX 158 to set up a corresponding entry in the shared binding database, named 159 Binding DB. Then SAVI-MIX will check if there is any conflict in the 160 Binding DB. A new binding will be generated if there is no conflict. 161 If there is a conflict, SAVI-MIX will determine whether replace the 162 existing binding or reject the candidate binding based on the 163 policies specified in Section 7. Whether the candidate binding can 164 be install in the Binding DB will not be returned to the requesting 165 SAVI method. 167 Correspondingly, the packet filtering will not be performed by each 168 SAVI method separately. Instead, SAVI-MIX will perform filtering 169 based on the entries in the Binding DB. 171 +--------------------------------------------------------+ 172 | | 173 | SAVI Device | 174 | | 175 | | 176 | +------+ +------+ +------+ | 177 | | SAVI | | SAVI | | SAVI | | 178 | | | | | | | | 179 | | FCFS | | DHCP | | SEND | | 180 | +------+ +------+ +------+ | 181 | | | | | 182 | | | | Candidate Binding | 183 | v v v | 184 | +------------------------------+ | 185 | | | | 186 | | SAVI-MIX | | 187 | | | | 188 | +------------------------------+ | 189 | | | 190 | v Final Binding | 191 | +--------------+ | 192 | | Binding | | 193 | | | | 194 | | Database | | 195 | +--------------+ | 196 | | 197 +--------------------------------------------------------+ 199 Figure 1: SAVI-Mix Architecture 201 5. Security Perimeter in SAVI MIX 203 The perimeter of SAVI MIX is the union of the perimeter of each SAVI 204 method, as illustrated in Figure 2. 206 +-----------------+ 207 | | 208 +----+ | +-----+ | 209 | | | | | | 210 | H1 | | |DHCP1| | 211 | | | | | | 212 | | | | | | 213 +----+ | +-----+ | 214 +-------|------------------------------+ | | 215 | | | | 216 | +---------+ +---------+ | 217 | | SAVI | | SAVI | | 218 | | |--------+ +--------| | | 219 | +---------+ | | +---------+ | 220 | | | | 221 | +-------------+ | 222 | | SWITCH-A | | 223 | | | | 224 | +-------------+ | 225 | | | | 226 | +---------+ | | +---------+ | 227 | | SAVI | | | | SAVI | | 228 | | |--------+ +--------| | | 229 | +---------+ +---------+ | 230 | | | | 231 | | +----------------------------|---------+ 232 | | | | 233 | +----+ | +----+ 234 | | | | | | 235 | | R1 | | | H2 | 236 | | | | | | 237 | | | | | | 238 | +----+ | +----+ 239 | | 240 +-----------------+ 242 Figure 2: SAVI-Mix Perimeter 244 6. Recommendations for preventing collisions 246 If each solution has a dedicated address space, collisions won't 247 happen. Using non overlapping address space across SAVI solutions is 248 therefore recommended. To that end, one should: 250 1. DHCP/SLAAC: use non-overlapping prefix for DHCP and SLAAC. Set 251 the A bit in Prefix information option of Router Advertisement 252 for SLAAC prefix. And set the M bit in Router Advertisement for 253 DHCP prefix. For detail explanations on these bits, refer to 254 [rfc4861][rfc4862]. 256 2. SeND/non-SeND: avoid mixed environment (where SeND and non-SeND 257 nodes are deployed) or separate the prefixes announced to SeND 258 and non-SenD nodes. One way to separate the prefixes is to have 259 the router(s) announcing different (non-overlapping) prefixes to 260 SeND and to non-SeND nodes, using unicast Router Advertisements, 261 in response to SeND/non-SeND Router Solicit. 263 7. Handing binding collisions 265 In situations where collisions could not be avoided, two cases should 266 be considered: 268 1. The same address is bound on two different binding anchors by 269 different SAVI solutions. 271 2. The same address is bound on the same binding anchor by different 272 SAVI solutions. 274 7.1. Same Address on Different Binding Anchors 276 This would typically occur in case assignment address spaces could 277 not be separated. For instance,overl an address is assigned by SLAAC 278 on node X, installed in the binding table using SAVI-FCFS, anchored 279 to "anchor-X". Later, the same address is assigned by DHCP to node 280 Y, as a potential candidate in the same binding table, anchored to 281 "anchor-Y". 283 7.1.1. Basic preference 285 The SAVI device must decide whom the address should be bound with 286 (anchor-X or anchor-Y in this example). Current standard documents 287 of address assignment methods have implied the prioritization 288 relationship (first-come). In the absence of any configuration or 289 protocol hint (see Section 7.1.2) the SAVI device should choose the 290 first-come entry, whether it was learnt from SLACC, SeND or DHCP. 292 7.1.2. Overwritten preference 294 There are two identified exceptions to the general prioritization 295 model, one of them being CGA addresses, another one controlled by the 296 configuration of the switch: 298 1. When CGA addresses are used, and a collision is detected, 299 preference should be given to the anchor that carries the CGA 300 credentials once they are verified, in particular the CGA 301 parameters and the RSA options. Note that if an attacker was 302 trying to replay CGA credentials, he would then compete on the 303 base of fcfs (first-come, first-serve). 305 2. The SAVI device should allow the configuration of a triplet 306 ("prefix", "anchor", "method") or ("address", "anchor", 307 "method"). Later, if a DAD message is received for a target 308 within "prefix" (or equal "address") bound to "anchor1" 309 (different from "anchor"), or via a discovery method different 310 from "method", the switch should defend the address by responding 311 to the DAD message. It should not at this point install the 312 entry into the binding table. It will simply prevent the node to 313 assign the address, and will de-facto prioritize the configured 314 anchor or configured assignment method for that address. This is 315 especially useful to protect well known bindings such as a static 316 address of a server over anybody, even when the server is down. 317 It is also a way to give priority to a binding learnt from SAVI- 318 DHCP over a binding for the same address, learnt from SAVI-FCFS. 320 7.1.3. Multiple SAVI Device Scenario 322 A single SAVI device doesn't have the information of all bound 323 addresses on the perimeter. Therefore it is not enough to lookup 324 local bindings to identify a collision. However, assuming DAD is 325 performed throughout the security perimeter for all addresses 326 regardless of the assignment method, then DAD response will inform 327 all SAVI devices about any collision. In that case, FCFS will apply 328 the same way as in a single switch scenario. If the admin configured 329 on one the switches a prefix (or a single static binding) to defend, 330 the DAD response generated by this switch will also prevent the 331 binding to be installed on other switches of the perimeter. 333 7.2. Same Address on the Same Binding Anchor 335 A binding may be set up on the same binding anchor by multiple 336 solutions. For example, if SAVI-FCFS and SAVI-DHCP are both enabled 337 on one SAVI device, a DHCP address be bound by both SAVI instances. 339 There is no conflict if the binding is valid in all the solutions. 340 However, the binding lifetimes of different solutions can be 341 different. If one SAVI instance changes the state of a binding to 342 invalid on lifetime expires, conflict will happen. 344 The solution proposed is to keep a binding as long as possible. A 345 binding is kept until it has been required to be removed by all the 346 solutions that ever set up it. 348 8. Security Considerations 350 As described in [savi-framework], this solution cannot strictly 351 prevent spoofing. There are two scenarios in which spoofing can 352 still happen: 354 1. The binding anchor is spoofable. if the binding anchor is 355 spoofable, e.g., plain MAC address, an attacker can use forged 356 binding anchor to send packet which will not be regarded as 357 spoofing by SAVI device. Indeed, using binding anchor that can 358 be easily spoofed is dangerous. An attacker can use the binding 359 anchor of another host to perform a lot of DHCP procedures, and 360 the SAVI device will refuse to set up new binding for the host 361 whenever the binding number limitation has been reached. Thus, 362 it is RECOMMENDED to use strong enough binding anchor, e.g., 363 switch port, secure association in 802.11ae/af and 802.11i. 365 2. The binding anchor is shared by more than one host. If the 366 binding anchor is shared by more than one host, they can spoof 367 the addresses of each other. For example, a number of hosts can 368 attach to the same switch port of a SAVI device through a hub. 369 The SAVI device cannot distinguish packets from different hosts 370 and thus the spoofing between them will not be detected. This 371 problem can be solved through not sharing binding anchor between 372 hosts. 374 9. IANA Considerations 376 This memo asks the IANA for no new parameters. 378 Note to RFC Editor: This section will have served its purpose if it 379 correctly tells IANA that no new assignments or registries are 380 required, or if those assignments or registries are created during 381 the RFC publication process. From the authors' perspective, it may 382 therefore be removed upon publication as an RFC at the RFC Editor's 383 discretion. 385 10. Acknowledgment 387 Thanks to Christian Vogt, Eric Nordmark, Marcelo Bagnulo Braun and 388 Jari Arkko for their valuable contributions. 390 This document was generated using the xml2rfc tool. 392 11. References 394 11.1. Informative References 396 [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", RFC 2119, BCP 14, Match 1997. 399 11.2. Normative References 401 [rfc4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 402 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 403 September 2007. 405 [rfc4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 406 Address Autoconfiguration", RFC 4862, September 2007. 408 [savi-dhcp] 409 Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for 410 DHCP", draft-ietf-savi-dhcp-12 (work in progress), 411 February 2012. 413 [savi-fcfs] 414 Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS- 415 SAVI: First-Come First-Serve Source-Address Validation for 416 Locally Assigned Addresses", draft-ietf-savi-fcfs-14 (work 417 in progress), February 2012. 419 [savi-framework] 420 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 421 "Source Address Validation Improvement Framework", 422 draft-ietf-savi-framework-06 (work in progress), 423 December 2011. 425 [savi-send] 426 Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source- 427 Address Validation Implementation", 428 draft-ietf-savi-send-06 (work in progress), October 2011. 430 Authors' Addresses 432 Jun Bi 433 Tsinghua University 434 Network Research Center, Tsinghua University 435 Beijing 100084 436 China 438 Email: junbi@tsinghua.edu.cn 440 Guang Yao 441 Tsinghua University 442 Network Research Center, Tsinghua University 443 Beijing 100084 444 China 446 Email: yaoguang@cernet.edu.cn 448 Joel M. Halpern 449 Newbridge Networks Inc 451 Email: jmh@joelhalpern.com 453 Eric Levy-Abegnoli (editor) 454 Cisco Systems 455 Village d'Entreprises Green Side - 400, Avenue Roumanille 456 Biot-Sophia Antipolis 06410 457 France 459 Email: elevyabe@cisco.com