idnits 2.17.1 draft-bi-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 16, 2010) is 4909 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) == Unused Reference: 'RFC2119' is defined on line 326, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-savi-framework' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 353, but no explicit reference was found in the text == Unused Reference: 'RFC3972' is defined on line 363, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-savi-dhcp-06 == Outdated reference: A later version (-14) exists of draft-ietf-savi-fcfs-05 == Outdated reference: A later version (-06) exists of draft-ietf-savi-framework-01 == Outdated reference: A later version (-11) exists of draft-ietf-savi-send-04 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Bi 3 Internet-Draft CERNET 4 Intended status: Standards Track G. Yao 5 Expires: May 20, 2011 Tsinghua University 6 J. Halpern 7 Newbridge Networks Inc 8 E. Levy-Abegnoli 9 Cisco Systems 10 November 16, 2010 12 SAVI for Mixed Address Assignment Methods Scenario 13 15 Abstract 17 This document reviews how multiple address discovery methods can 18 coexist in a single savi device and collisions are resolved when the 19 same binding entry is discovered by two or more methods. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 20, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Mixed Address Assignment Methods Scenario . . . . . . . . . . . 3 58 4. Basic Structure . . . . . . . . . . . . . . . . . . . . . . . . 3 59 5. Problem Scope, Statement and Solution . . . . . . . . . . . . . 4 60 5.1. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . 4 61 5.2. Recommendations for preventing collisions . . . . . . . . . 4 62 5.3. Binding on the Same Address . . . . . . . . . . . . . . . . 4 63 5.3.1. Same Address on Different Binding Anchors . . . . . . . 5 64 5.3.1.1. Basic preference . . . . . . . . . . . . . . . . . 5 65 5.3.1.2. Issues in Multiple SAVI Device Scenario . . . . . . 6 66 5.3.1.3. Conflict Announcement . . . . . . . . . . . . . . . 7 67 5.3.2. Same Address on the Same Binding Anchor . . . . . . . . 8 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 70 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 71 Appendix A. Contributors and Acknowledgments . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 There are currently several documents [I-D.ietf-savi-fcfs], 77 [I-D.ietf-savi-dhcp], [I-D.ietf-savi-send] that describe the 78 different methods by which a switch can discover and record bindings 79 between a node's layer3 address and a binding anchor and use that 80 binding to perform Source Address Validation. 82 The method used by nodes to assign the address drove the break down 83 into these multiple documents, whether StateLess Autoconfiguration 84 (SLACC), Dynamic Host Control Protocol (DHCP), Secure Neighbor 85 Discovery (SeND) or manual. Each of these documents describes 86 separately how one particular discovery method deals with address 87 collisions. 89 While multiple assignment methods can be used in the same layer2 90 domain, a savi-switch might have to deal with a mix of binding 91 discovery methods. The purpose of this document is to provide 92 recommendations to avoid collisions and to review collisions handling 93 when two or more such methods come up with competing bindings. 95 2. Terminology 97 3. Mixed Address Assignment Methods Scenario 99 Currently, there are four SAVI solutions which cover different types 100 of address assignment methods: 101 1. SAVI-FCFS: SLAAC 102 2. SAVI-DHCP: stateful DHCP, static DHCP 103 3. SAVI-SeND: CGA with certificate, CGA without certificate 104 4. Manually configuration: static address manually configured by 105 administrator on SAVI device. 107 Any combination of address assignment methods can be potentially 108 found within a layer2 domain, and a savi device will have to 109 implement the corresponding savi discovery methods (savi solutions) 110 to prevent packets from valid sources to be filtered out. If more 111 than one SAVI solution is enabled on a SAVI device, the method is 112 referred to as "mix address assignment method" in this document. 114 4. Basic Structure 116 Different savi solutions are independent from each other, each one 117 handling its own entries. In the absence of a reconciliation, each 118 solution will reject packets sourced with an address it did not 119 discovered. To prevent addresses discovered by one solution to be 120 filtered out by another, the binding table should be shared by all 121 the solutions. However this could create some conflict when the same 122 entry is discovered by two different methods: the main purpose of 123 this document is to resolve such conflicts if and when they happen. 125 5. Problem Scope, Statement and Solution 127 5.1. Problem Scope 129 This document reviews the case of collisions between different SAVI 130 solutions. Collision happening within a given solution is not in the 131 scope of this document. 133 5.2. Recommendations for preventing collisions 135 If each solution has a dedicated address space, collisions won't 136 happen. Thus, it is recommended to avoid overlap in the address 137 space across SAVI solutions enabled on any particular savi switch. 138 More specifically: 140 1. DHCP/Static: exclude the static address from the DHCP pool. 141 2. DHCP/SLAAC: separate the prefix scope of DHCP and SLAAC. Set the 142 A bit in Prefix information option of Router Advertisement for 143 SLAAC prefix. And set the M bit in Router Advertisement for DHCP 144 prefix. [RFC4861] [RFC4862]. 145 3. SLAAC/Static: separate the prefix scope of SLAAC and Static. It 146 may be impossible in practice. SAVI device can perform DAD proxy 147 for static address to hold the address from SLAAC node. 148 4. SEND/non-SEND: In an environment where SeND is deployed, the only 149 way to avoid collisions in the SAVI devices is to have SeND-only 150 nodes. In a mixed environment, two nodes, SeND and non-SeND, 151 could configure the same address and the SAVI-device will have to 152 deal with a collision. 154 5.3. Binding on the Same Address 156 In situation where collisions could not be avoided, two cases should 157 be considered: 158 1. The same address is bound on two different binding anchors by 159 different SAVI solutions. 160 2. The same address is bound on the same binding anchor by different 161 SAVI solutions. 163 5.3.1. Same Address on Different Binding Anchors 165 5.3.1.1. Basic preference 167 Within the SAVI perimeter, one address bound to a binding anchor by 168 one SAVI solution could also be bound by another SAVI solution to a 169 different binding anchor. For example an address could be initially 170 bound to a binding anchor by SAVI-FCFS solution. If another host is 171 assigned the same address from DHCP and the DAD procedure is not 172 performed, the same address will also be bound to the new binding 173 anchor. Both bindings are legitimate in the corresponding solution. 175 Though it is possible that the hosts and network can still work in 176 such scenario, the uniqueness of address is not assured. The SAVI 177 device must decide whom the address should be bound with. A binding 178 preference level based solution is proposed here. 180 To determine a proper preference level, following evidences are used: 181 1. "Duplicate Address Detection MUST be performed on all unicast 182 addresses prior to assigning them to an interface, regardless of 183 whether they are obtained through stateless autoconfiguration, 184 DHCPv6, or manual configuration,..." [RFC4862] 185 2. "A tentative address that is determined to be a duplicate as 186 described above MUST NOT be assigned to an interface,..." 187 [RFC4862] 188 3. "The client SHOULD perform duplicate address detection on each of 189 the addresses in any IAs it receives in the Reply message before 190 using that address for traffic." [RFC3315] 191 4. "A SEND node that uses the CGA authorization method to protect 192 Neighbor Solicitations SHOULD perform Duplicate Address Detection 193 as follows. If Duplicate Address Detection indicates that the 194 tentative address is already in use, the node generates a new 195 tentative CGA. If after three consecutive attempts no non-unique 196 address is generated, it logs a system error and gives up 197 attempting to generate an address for that interface. 199 When performing Duplicate Address Detection for the first 200 tentative address, the node accepts both secured and unsecured 201 Neighbor Advertisements and Solicitations received in response to 202 the Neighbor Solicitations. When performing Duplicate Address 203 Detection for the second or third tentative address, it ignores 204 unsecured Neighbor Advertisements and Solicitations." [RFC3971] 205 5. "The node MAY have a configuration option whereby it ignores 206 unsecured advertisements, even when performing Duplicate Address 207 Detection for the first tentative address. This configuration 208 option SHOULD be disabled by default. This is a recovery 209 mechanism for cases in which attacks against the first address 210 become common." [RFC3971] 212 From the above materials, FCFS is found to be a universal principle 213 with only one exception: SEND node may use a duplicate address if the 214 DAD NA is only from non-SEND node. And Duplicate Address Detection 215 is enforced to detect the uniqueness of address (though in [RFC3315], 216 "SHOULD" is used but not "MUST"). The static address is not covered 217 in any document, as we believe the "manual configuration" in 218 [RFC4862] means address configured on host by user, but not static 219 address must be protected for servers and special purpose. 221 The following preference level can be inferred from listed materials 222 and above analysis: 223 1. SLAAC, DHCP and manually configured address by user have the same 224 priority. 225 2. SEND can have higher priority because it may configure an address 226 bound by non-SEND node. 227 3. Static address should have the highest priority to ensure 228 administrator having the right to manage the usage of address. 230 Combined solution preference with binding sequence, there will be 16 231 scenarios (Denote solutions by FCFS, DHCP, SEND, and Admin 232 correspondingly): 234 Existing Candidate PREFERENCE 235 FCFS FCFS In the scope of SAVI-SLAAC 236 FCFS DHCP FCFS 237 FCFS SEND SEND 238 FCFS Admin Admin 239 DHCP FCFS DHCP 240 DHCP DHCP In the scope of SAVI-DHCP 241 DHCP SEND SEND 242 DHCP Admin Admin 243 SEND FCFS SEND 244 SEND DHCP SEND 245 SEND SEND In the scope of SAVI-SEND 246 SEND Admin Admin 247 Admin FCFS Admin 248 Admin DHCP Admin 249 Admin SEND Admin 250 Admin Admin Candidate binding 252 5.3.1.2. Issues in Multiple SAVI Device Scenario 254 A single SAVI device doesn't have the information of all bound 255 addresses on the perimeter. Therefore a collision may not be 256 explicit based only on local bindings. To make the perimeter-scope 257 collision explicit to each SAVI device requires: 259 1. A SAVI device must have the ability to know whether a local 260 binding setup request violate a binding on other SAVI devices or 261 not. 262 2. A SAVI device must have the ability to know whether a local 263 binding should be removed because the address is bound on another 264 SAVI device by solution with higher priority. 266 The first requirement is relatively easy to meet, as DAD must have 267 been performed on address bound by SAVI-SLAAC and SAVI-SEND, and 268 there is no need to check if a static address violates an existing 269 binding. However DAD is not required by SAVI-DHCP, and static 270 addresses must be prevented from being grabbed by other solutions. 271 Thus, following mechanisms MUST be enforced: 273 1. SAVI device MUST perform DAD procedure on DHCP address or track 274 if DAD performed by DHCP client itself is successful before 275 binding a DHCP address. Only if the DAD succeeds, the DHCP 276 address can be bound. 277 2. SAVI device MUST perform DAD proxy for static address. Or all 278 the other SAVI devices MUST be configured to deny static address 279 bound on other SAVI devices, in condition that SAVI-SEND is 280 enabled and it may bind a static address. 281 3. The second requirement is relatively hard to satisfy. Whenever 282 SAVI-SEND decides to bind an address even it is used by a non- 283 SEND node, and a bound address is bound manually to another 284 binding anchor, the SAVI device with the existing binding must 285 get noticed and delete the binding. Following mechanisms MUST be 286 enforced: 287 1. If the SAVI-SEND solution decides to bind an address despite 288 that the binding collides with an existing FCFS/DHCP address, 289 a SEND NA MUST be sent by the SAVI device. 290 2. If a SAVI device receives a SEND NA targeting at a local 291 bound address by FCFS and DHCP, it MUST remove the binding, 292 and announce the conflict to the host with the binding. 293 3. If a static address bound manually collides with any exiting 294 binding, the existing binding MUST be removed manually by 295 administrator, and the conflict MUST be announced to the host 296 with existing binding. 298 5.3.1.3. Conflict Announcement 300 If a host is prohibited from using a bound address, the violation 301 MUST be announced to it, through delivering one (or more) Neighbor 302 Advertisement message to the host. 304 5.3.2. Same Address on the Same Binding Anchor 306 A binding may be set up on the same binding anchor by multiple 307 solutions. Generally, the binding lifetimes of different solutions 308 are different. Potentially, if one solution requires to remove the 309 binding, the node using the address may be taken the use right. 311 For example, a node performs DAD procedure after being assigned an 312 address from DHCP, then the address will also be bound by SAVI-FCFS. 313 If the SAVI-FCFS lifetime is shorter than DHCP lifetime, when the 314 SAVI-FCFS lifetime expires, it will request to remove the binding. 315 If the binding is removed, the node will not be able to use the 316 address even the DHCP lease time doesn't expire. 318 The solution proposed is to keep a binding as long as possible. A 319 binding is kept until it has been required to be removed by all the 320 solutions that ever set up it. 322 6. References 324 6.1. Normative References 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, March 1997. 329 6.2. Informative References 331 [I-D.ietf-savi-dhcp] 332 Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for 333 DHCP", draft-ietf-savi-dhcp-06 (work in progress), 334 September 2010. 336 [I-D.ietf-savi-fcfs] 337 Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS- 338 SAVI: First-Come First-Serve Source-Address Validation for 339 Locally Assigned Addresses", draft-ietf-savi-fcfs-05 (work 340 in progress), October 2010. 342 [I-D.ietf-savi-framework] 343 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 344 "Source Address Validation Improvement Framework", 345 draft-ietf-savi-framework-01 (work in progress), 346 October 2010. 348 [I-D.ietf-savi-send] 349 Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source- 350 Address Validation Implementation", 351 draft-ietf-savi-send-04 (work in progress), October 2010. 353 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 354 (IPv6) Specification", RFC 2460, December 1998. 356 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 357 and M. Carney, "Dynamic Host Configuration Protocol for 358 IPv6 (DHCPv6)", RFC 3315, July 2003. 360 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 361 Neighbor Discovery (SEND)", RFC 3971, March 2005. 363 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 364 RFC 3972, March 2005. 366 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 367 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 368 September 2007. 370 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 371 Address Autoconfiguration", RFC 4862, September 2007. 373 Appendix A. Contributors and Acknowledgments 375 Thanks to Christian Vogt, Eric Nordmark, Marcelo Bagnulo Braun and 376 Jari Arkko for their valuable contributions. 378 Authors' Addresses 380 Jun Bi 381 CERNET 382 Network Research Center, Tsinghua University 383 Beijing 100084 384 China 386 Email: junbi@cernet.edu.cn 388 Guang Yao 389 Tsinghua University 390 Network Research Center, Tsinghua University 391 Beijing 100084 392 China 394 Email: yaog@netarchlab.tsinghua.edu.cn 395 Joel M. Halpern 396 Newbridge Networks Inc 398 Email: jmh@joelhalpern.com 400 Eric Levy-Abegnoli 401 Cisco Systems 402 Village d'Entreprises Green Side - 400, Avenue Roumanille 403 Biot-Sophia Antipolis - 06410 404 France 406 Email: elevyabe@cisco.com