idnits 2.17.1 draft-bi-savi-mix-04.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 (March 14, 2011) is 4792 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 322, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'RFC3972' is defined on line 359, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-savi-dhcp-07 == 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-03 == 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 (~~), 9 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: September 15, 2011 Tsinghua University 6 J. Halpern 7 Newbridge Networks Inc 8 E. Levy-Abegnoli, Ed. 9 Cisco Systems 10 March 14, 2011 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 September 15, 2011. 38 Copyright Notice 40 Copyright (c) 2011 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. Mixed Address Assignment Methods Scenario . . . . . . . . . . . 3 57 3. Problem Scope, Statement and Solution . . . . . . . . . . . . . 4 58 3.1. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Recommendations for preventing collisions . . . . . . . . . 4 60 3.3. Binding on the Same Address . . . . . . . . . . . . . . . . 4 61 3.3.1. Same Address on Different Binding Anchors . . . . . . . 5 62 3.3.1.1. Basic preference . . . . . . . . . . . . . . . . . 5 63 3.3.1.2. Multiple SAVI Device Scenario . . . . . . . . . . . 7 64 3.3.1.3. Conflict Announcement . . . . . . . . . . . . . . . 7 65 3.3.2. Same Address on the Same Binding Anchor . . . . . . . . 7 66 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.1. Normative References . . . . . . . . . . . . . . . . . . . 8 68 4.2. Informative References . . . . . . . . . . . . . . . . . . 8 69 Appendix A. Contributors and Acknowledgments . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 There are currently several documents [I-D.ietf-savi-fcfs], 75 [I-D.ietf-savi-dhcp], [I-D.ietf-savi-send] that describe the 76 different methods by which a switch can discover and record bindings 77 between a node's layer3 address and a binding anchor and use that 78 binding to perform Source Address Validation. 80 The method used by nodes to assign the address drove the break down 81 into these multiple documents, whether StateLess Autoconfiguration 82 (SLAAC), Dynamic Host Control Protocol (DHCP), Secure Neighbor 83 Discovery (SeND) or manual. Each of these documents describes 84 separately how one particular discovery method deals with address 85 collisions. 87 While multiple assignment methods can be used in the same layer2 88 domain, a savi-switch might have to deal with a mix of binding 89 discovery methods. The purpose of this document is to provide 90 recommendations to avoid collisions and to review collisions handling 91 when two or more such methods come up with competing bindings. 93 2. Mixed Address Assignment Methods Scenario 95 There are four address assignment methods identified and reviewed in 96 one of the SAVI document: 97 1. StateLess Address AutoConfiguration (SLAAC) - reviewed in 98 [I-D.ietf-savi-fcfs] 99 2. Dynamic Host Control Protocol address assignment (DHCP) - 100 reviewed in [I-D.ietf-savi-dhcp] 101 3. Secure Neighbor Discovery (SeND) address assignment, reviewed in 102 [I-D.ietf-savi-send] 103 4. Manually address configuration - reviewed in [I-D.ietf-savi-fcfs] 104 and [I-D.ietf-savi-framework] 106 Each address assignment method corresponds to a binding discovery 107 method: SAVI-FCFS, SAVI-DHCP and SAVI-SeND. 109 Any combination of address assignment methods can be potentially 110 mixed within a layer2 domain, and a savi device will have to 111 implement the corresponding savi discovery method (referred to as a 112 "savi solution") to enable Source Address Validation. 114 If more than one SAVI solution is enabled on a SAVI device, the 115 method is referred to as "mix address assignment method" in this 116 document. 118 3. Problem Scope, Statement and Solution 120 3.1. Problem Scope 122 Different savi solutions are independent from each other, each one 123 handling its own entries. In the absence of a reconciliation, each 124 solution will reject packets sourced with an address it did not 125 discovered. To prevent addresses discovered by one solution to be 126 filtered out by another, the binding table should be shared by all 127 the solutions. However this could create some conflict when the same 128 entry is discovered by two different methods: the purpose of this 129 document is of two folds: provide recommendations to avoid conflicts, 130 and resolve conflicts if and when they happen. Collisions happening 131 within a given solution is outside the scope of this document. 133 3.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 3.3. Binding on the Same Address 156 In situations 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 3.3.1. Same Address on Different Binding Anchors 165 This is the very case of collision that could not be prevented by 166 separating the assignment address spaces. For instance, an address 167 is assigned by SLAAC on node X, installed in the binding table using 168 SAVI-FCFS, anchored to "anchor-X". Later, the same address is 169 assigned by DHCP to node Y, as a potential candidate in the same 170 binding table, anchored to "anchor-Y". 172 3.3.1.1. Basic preference 174 Within the SAVI perimeter, one address bound to a binding anchor by 175 one SAVI solution could also be bound by another SAVI solution to a 176 different binding anchor. If the DAD procedure is not performed, the 177 same address will also be bound to the new binding anchor. Both 178 bindings are legitimate within the corresponding solution. 180 Though it is possible that the hosts and network can still work in 181 such scenario, the uniqueness of address is not assured. The SAVI 182 device must decide whom the address should be bound with. A binding 183 preference level based solution is proposed here. 185 To determine a proper preference level, following evidences are used: 186 1. "Duplicate Address Detection MUST be performed on all unicast 187 addresses prior to assigning them to an interface, regardless of 188 whether they are obtained through stateless autoconfiguration, 189 DHCPv6, or manual configuration,..." [RFC4862] 190 2. "A tentative address that is determined to be a duplicate as 191 described above MUST NOT be assigned to an interface,..." 192 [RFC4862] 193 3. "The client SHOULD perform duplicate address detection on each of 194 the addresses in any IAs it receives in the Reply message before 195 using that address for traffic." [RFC3315] 196 4. A SEND node that uses the CGA authorization method to protect 197 Neighbor Solicitations SHOULD perform Duplicate Address Detection 198 as follows. If Duplicate Address Detection indicates that the 199 tentative address is already in use, the node generates a new 200 tentative CGA. If after three consecutive attempts no non-unique 201 address is generated, it logs a system error and gives up 202 attempting to generate an address for that interface. 204 When performing Duplicate Address Detection for the first 205 tentative address, the node accepts both secured and unsecured 206 Neighbor Advertisements and Solicitations received in response to 207 the Neighbor Solicitations. When performing Duplicate Address 208 Detection for the second or third tentative address, it ignores 209 unsecured Neighbor Advertisements and Solicitations." [RFC3971] 211 5. "The node MAY have a configuration option whereby it ignores 212 unsecured advertisements, even when performing Duplicate Address 213 Detection for the first tentative address. This configuration 214 option SHOULD be disabled by default. This is a recovery 215 mechanism for cases in which attacks against the first address 216 become common." [RFC3971] 218 From the above materials, "First-Come First-Serve" should be the 219 default behavior for choosing between two competing bindings. There 220 can however be some exceptions, one of them being CGA addresses, 221 another one controlled by the configuration of the switch: 223 1. When CGA addresses are used, and a collision is detected, 224 preference should be given to the anchor that carries the CGA 225 credentials once they are verified, in particular the CGA 226 parameters and the RSA options. 228 2. The switch configuration should allow an address range (including 229 a single address) to be configured together with a given anchor 230 or constrained to be discovered by a particular savi-solution. 231 If a DAD message for a target within that range is received on 232 the savi-switch from an anchor, or via a discovery method 233 different from the one configured, the switch should defend the 234 address by responding to the DAD message. This is especially 235 useful to protect well known bindings such as a static address of 236 a server over anybody, even when the server is down. It is also 237 a way to give priority to a binding learnt from SAVI-DHCP over a 238 binding for the same address, learnt from SAVI-FCFS. 240 Note that no binding shall be created in the binding table until 241 an "acceptable" address owner shows up, either from the 242 configured anchor or using the savi solution associated with that 243 address. 245 The following preference level can be inferred from listed materials 246 and above analysis: 247 1. By default, SLAAC, DHCP and manually configured address by user 248 have the same priority. 249 2. SEND can have higher priority because it may configure an address 250 bound by non-SEND node. 251 3. Static binding configured on the switch (admin) will have the 252 highest priority 253 4. Address range configured on the switch (admin) constrained to 254 DHCP discovery will de-facto be given a higher priority over 255 FCFS, by defending the address until it is is effectively learnt 256 from DHCP 258 Combined solution preference with binding sequence, there will be 16 259 scenarios (Denote solutions by FCFS, DHCP, SEND, and Admin 260 correspondingly): 262 Existing Candidate Default PREFERENCE 263 FCFS FCFS In the scope of SAVI-SLAAC 264 FCFS DHCP FCFS 265 FCFS SEND SEND 266 FCFS Admin Admin 267 DHCP FCFS DHCP 268 DHCP DHCP In the scope of SAVI-DHCP 269 DHCP SEND SEND 270 DHCP Admin Admin 271 SEND FCFS SEND 272 SEND DHCP SEND 273 SEND SEND In the scope of SAVI-SEND 274 SEND Admin Admin 275 Admin FCFS Admin 276 Admin DHCP Admin 277 Admin SEND Admin 278 Admin Admin Candidate binding 280 3.3.1.2. Multiple SAVI Device Scenario 282 A single SAVI device doesn't have the information of all bound 283 addresses on the perimeter. Therefore it is not enough to lookup 284 local bindings to identify a collision. However, assuming DAD is 285 performed throughout the security perimeter for all addresses 286 regardless of the assignment method, then DAD response will inform 287 all SAVI switches about any collision. In that case, FCFS will apply 288 the same way as in a single switch scenario. If the admin configured 289 on one the switches a range of addresses (or a single static binding) 290 to defend, the DAD response generated by this switch will also 291 prevent the binding to be installed on other switches of the 292 perimeter. 294 3.3.1.3. Conflict Announcement 296 If a host is prohibited from using a bound address, the violation 297 MUST be announced to it, through delivering one (or more) Neighbor 298 Advertisement message to the host. 300 3.3.2. Same Address on the Same Binding Anchor 302 A binding may be set up on the same binding anchor by multiple 303 solutions. Generally, the binding lifetimes of different solutions 304 are different. Potentially, if one solution requires to remove the 305 binding, the node using the address may be taken the use right. 307 For example, a node performs DAD procedure after being assigned an 308 address from DHCP, then the address will also be bound by SAVI-FCFS. 309 If the SAVI-FCFS lifetime is shorter than DHCP lifetime, when the 310 SAVI-FCFS lifetime expires, it will request to remove the binding. 311 If the binding is removed, the node will not be able to use the 312 address even the DHCP lease time doesn't expire. 314 The solution proposed is to keep a binding as long as possible. A 315 binding is kept until it has been required to be removed by all the 316 solutions that ever set up it. 318 4. References 320 4.1. Normative References 322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, March 1997. 325 4.2. Informative References 327 [I-D.ietf-savi-dhcp] 328 Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for 329 DHCP", draft-ietf-savi-dhcp-07 (work in progress), 330 November 2010. 332 [I-D.ietf-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-05 (work 336 in progress), October 2010. 338 [I-D.ietf-savi-framework] 339 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 340 "Source Address Validation Improvement Framework", 341 draft-ietf-savi-framework-03 (work in progress), 342 March 2011. 344 [I-D.ietf-savi-send] 345 Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source- 346 Address Validation Implementation", 347 draft-ietf-savi-send-04 (work in progress), October 2010. 349 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 350 (IPv6) Specification", RFC 2460, December 1998. 352 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 353 and M. Carney, "Dynamic Host Configuration Protocol for 354 IPv6 (DHCPv6)", RFC 3315, July 2003. 356 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 357 Neighbor Discovery (SEND)", RFC 3971, March 2005. 359 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 360 RFC 3972, March 2005. 362 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 363 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 364 September 2007. 366 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 367 Address Autoconfiguration", RFC 4862, September 2007. 369 Appendix A. Contributors and Acknowledgments 371 Thanks to Christian Vogt, Eric Nordmark, Marcelo Bagnulo Braun and 372 Jari Arkko for their valuable contributions. 374 Authors' Addresses 376 Jun Bi 377 CERNET 378 Network Research Center, Tsinghua University 379 Beijing 100084 380 China 382 Email: junbi@cernet.edu.cn 384 Guang Yao 385 Tsinghua University 386 Network Research Center, Tsinghua University 387 Beijing 100084 388 China 390 Email: yaoguang.china@gmail.com 392 Joel M. Halpern 393 Newbridge Networks Inc 395 Email: jmh@joelhalpern.com 396 Eric Levy-Abegnoli (editor) 397 Cisco Systems 398 Village d'Entreprises Green Side - 400, Avenue Roumanille 399 Biot-Sophia Antipolis - 06410 400 France 402 Email: elevyabe@cisco.com