idnits 2.17.1 draft-ietf-savi-fcfs-05.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 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.) ** There are 9 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 315: '... devices SHOULD be deployed forming ...' RFC 2119 keyword, line 420: '.... A SAVI device MUST support the foll...' RFC 2119 keyword, line 424: '...n: A SAVI device MUST support manual c...' RFC 2119 keyword, line 427: '...t: A SAVI device MUST support discover...' RFC 2119 keyword, line 433: '...VI device boots, it MUST send a Router...' (21 more instances...) 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 (October 25, 2010) is 4904 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: 'RFC4429' is defined on line 960, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-savi-framework-00 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Nordmark 3 Internet-Draft Sun 4 Intended status: Standards Track M. Bagnulo 5 Expires: April 28, 2011 UC3M 6 E. Levy-Abegnoli 7 Cisco Systems 8 October 25, 2010 10 FCFS-SAVI: First-Come First-Serve Source-Address Validation for Locally 11 Assigned Addresses 12 draft-ietf-savi-fcfs-05 14 Abstract 16 This memo describes FCFS SAVI a mechanism to provide source address 17 validation for IPv6 networks using the First-Come First-Serve 18 approach. The proposed mechanism is intended to complement ingress 19 filtering techniques to provide a higher granularity on the control 20 of the source addresses used. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 28, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Non-normative background to FCFS SAVI . . . . . . . . . . . . 4 70 2.1. Scope of FCFS SAVI . . . . . . . . . . . . . . . . . . . . 4 71 2.2. Constraints for FCFS SAVI design . . . . . . . . . . . . . 5 72 2.3. Address ownership proof . . . . . . . . . . . . . . . . . 5 73 2.4. Layer-2 Anchor considerations . . . . . . . . . . . . . . 6 74 2.5. SAVI enforcement perimeter . . . . . . . . . . . . . . . . 6 75 3. FCFS SAVI normative specification . . . . . . . . . . . . . . 10 76 3.1. FCFS SAVI Data structures . . . . . . . . . . . . . . . . 10 77 3.2. FCFS SAVI algorithm . . . . . . . . . . . . . . . . . . . 11 78 3.2.1. Discovering on-link prefixes . . . . . . . . . . . . . 11 79 3.2.2. Processing of transit traffic . . . . . . . . . . . . 11 80 3.2.3. Processing of local traffic. . . . . . . . . . . . . . 12 81 3.2.4. SAVI port configuration guidelines . . . . . . . . . . 17 82 3.2.5. VLAN support . . . . . . . . . . . . . . . . . . . . . 18 83 3.3. Protocol Constants . . . . . . . . . . . . . . . . . . . . 18 84 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 85 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 88 7.1. Normative References . . . . . . . . . . . . . . . . . . . 22 89 7.2. Informative References . . . . . . . . . . . . . . . . . . 22 90 Appendix A. Implications of not following the reccommended 91 behaviour . . . . . . . . . . . . . . . . . . . . . . 22 92 A.1. Lack of binding state due to packet loss . . . . . . . . . 22 93 A.1.1. Why initial packets may be (frequently) lost . . . . . 23 94 A.2. Lack of binding state due to a change in the topology . . 25 95 A.3. Lack of binding state due to state loss . . . . . . . . . 26 96 A.3.1. The case of a host directly connected to the SAVI 97 device . . . . . . . . . . . . . . . . . . . . . . . . 26 98 A.3.2. The case of a host connected to the SAVI device 99 through one or more legacy devices. . . . . . . . . . 27 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 102 1. Introduction 104 This memo describes FCFS SAVI, a mechanism to provide source address 105 validation for IPv6 networks using the First-Come First-Serve 106 approach. The proposed mechanism is intended to complement ingress 107 filtering techniques to provide a higher granularity on the control 108 of the source addresses used. 110 2. Non-normative background to FCFS SAVI 112 2.1. Scope of FCFS SAVI 114 The application scenario for FCFS SAVI is limited to the local link. 115 This means that the goal of FCFS SAVI is to verify that the source 116 address of the packets generated by the hosts attached to the local 117 link have not been spoofed. 119 In any link there usually are hosts and routers attached. Hosts 120 generate packets with their own address as the source address. This 121 is the so-called local traffic. While routers send packets 122 containing a source address other than their own, since they are 123 forwarding packets generated by other hosts (usually located in a 124 different link). This what the so-called transit traffic. 126 The applicability of FCFS SAVI is limited to the local traffic i.e. 127 to verify if the traffic generated by the hosts attached to the local 128 link contains a valid source address. The verification of the source 129 address of the transit traffic is out of the scope of FCFS SAVI. 130 Other techniques, like ingress filtering [RFC2827], are recommended 131 to validate transit traffic. In that sense, FCFS SAVI complements 132 ingress filtering, since it relies on ingress filtering to validate 133 transit traffic but is provides validation of local traffic, which is 134 not provided by ingress filtering. Hence, the security level is 135 increased by using these two techniques. 137 In addition, FCFS SAVI is designed to be used with locally assigned 138 addresses, in particular with address configured through Stateless 139 Address AutoConfiguration (SLAAC) [RFC4862]. Manually configured 140 addresses can be supported by FCFS SAVI, but manual configuration of 141 the binding on the SAVI device provides higher security and seems 142 compatible with manual address management. Additional considerations 143 about how to use FCFS SAVI depending on the type of address 144 management used and the nature of the addresses is discussed in the 145 framework document [I-D.ietf-savi-framework]. 147 2.2. Constraints for FCFS SAVI design 149 FCFS SAVI is designed to be deployed in existing networks requiring a 150 minimum set of changes. For that reason, FCFS SAVI does not require 151 any changes in the hosts which source address is to be verified. Any 152 verification must solely rely in the usage of already available 153 protocols. This means that FCFS SAVI cannot define a new protocol 154 nor define any new message on existing protocols nor require that a 155 host uses an existent protocol message in a different way. In other 156 words, the requirement is no host changes. 158 FCFS SAVI validation is performed by the FCFS SAVI function. Such 159 function can be placed in different type of devices, including a 160 router or a layer-2 bridge. The basic idea is that the FCFS SAVI 161 function is located in the points of the topology that can enforce 162 the correct usage of source address by dropping the non-compliant 163 packets. 165 2.3. Address ownership proof 167 The main function performed by FCFS SAVI is to verify that the source 168 address used in data packets actually belongs to the originator of 169 the packet. Since FCFS SAVI scope is limited to the local link, the 170 originator of the packet is attached to the local link. In order to 171 define any source address validation solution, we need to define some 172 address ownership proof concept i.e. what it means to be able to 173 proof that a given host owns a given address in the sense that the 174 host is entitled to send packets with that source address. 176 Since no host changes are acceptable, we need to find the means to 177 proof address ownership without requiring a new protocol. In FCFS 178 SAVI the address ownership proof is based in the First-Come First- 179 Serve approach. This means that the first host that claims a given 180 source address is the owner of the address until further notice. 181 More precisely, whenever a source address is used for the first time, 182 a state is created in the device that is performing the FCFS SAVI 183 function binding the source address to the layer-2 information that 184 the FCFS SAVI box has available (e.g. the port in a switched LAN). 185 Following data packets containing that IP source address must use the 186 same layer-2 information in order to be compliant. 188 There are however additional considerations to be taken into account. 189 For instance, consider the case of a host that moves from one segment 190 of a LAN to another segment of the same subnetwork and it keeps the 191 same IP address. In this case, the host is still the owner of the IP 192 address, but the associated layer-2 information has changed. In 193 order to cope with this case, the defined FCFS SAVI behaviour implies 194 the verification whether the host is still reachable using the 195 previous layer-2 information. In order to do that FCFS SAVI uses the 196 Neighbour Discovery (ND) protocol. If the host is no longer 197 reachable at the previously recorded layer-2 information, FCFS SAVI 198 assumes that the new location is valid and creates a new binding 199 using the new layer-2 information. In case the host is still 200 reachable using the previously recorded information, the packets 201 coming from the new layer-2 information are dropped. 203 Note that this only applies to local traffic. Transit traffic 204 generated by a router would be verified using alternative techniques, 205 such as ingress filtering. SAVI checks would not be fulfilled by the 206 transit traffic, since the router is not the owner of the source 207 address contained in the packets. 209 2.4. Layer-2 Anchor considerations 211 Any SAVI solution is not stronger than the Layer-2 anchor it uses. 212 If the Layer-2 anchor is easily spoofable (e.g. a MAC address), then 213 the resulting solution will be weak. The treatment of non-compliant 214 packets needs to be tuned accordingly. In particular, if the Layer-2 215 anchor is easily spoofable and the SAVI device is configured to drop 216 no compliant packets, then the usage of SAVI may open a new vector of 217 Denial of Service attacks, based on spoofed Layer-2 anchors. For 218 that reason, in this document, we assume that the Layer-2 anchors 219 used by the SAVI solution are not easily spoofable (e.g. ports of a 220 switched network) and that the SAVI device can be configured to drop 221 non- compliant packets. For the rest of the document, we will assume 222 that the Layer-2 anchors are ports of a switched network. 224 2.5. SAVI enforcement perimeter 226 SAVI provides perimetrical security. This means that the SAVI 227 devices form what can be called a SAVI enforcement perimeter and they 228 verify that any packet that crosses the perimeter is compliant (i.e. 229 the source address is validated). Once the packet is inside the 230 perimeter, no further validations are performed to the packet. This 231 model has implications both on how SAVI devices are deployed in the 232 topology and on the configuration of the SAVI boxes. 234 The implication of this perimetrical security approach, is that there 235 is part of the topology that is inside the perimeter and part of the 236 topology that is outside the perimeter. This means that while 237 packets coming from interfaces connected to the external part of the 238 topology need to be validated by the SAVI device, packets coming from 239 interfaces connected to the the internal part of the topology do not 240 need to be validated. This significantly reduces the processing 241 requirements of the SAVI device. It also implies that each SAVI 242 device that is part of the perimeter, must be able to verify the 243 source addresses of the packets coming from the interfaces connected 244 to the external part of the perimeter. In order to do so, the SAVI 245 device binds the source address to a layer-2 anchor. 247 One possible approach would be for every SAVI device to store binding 248 information about every source addresses in the subnetwork. This 249 means that every SAVI device would store binding for each source 250 address to the local layer-2 anchor through packets with that source 251 address can be received through. The problem with this approach is 252 that it imposes significant memory burden on the SAVI devices. In 253 order to reduce the memory requirements imposed to each device, the 254 SAVI solution described in this specification distributes the storage 255 of SAVI binding information among the multiple SAVI devices of a 256 subnetwork. The SAVI binding state is distributed across the SAVI 257 devices according to the following criteria: each SAVI device will 258 store binding information about the source addresses bound to layer-2 259 anchors corresponding to the interfaces that connect to the part of 260 the topology that is outside of the SAVI enforcement perimeter. 261 Since all the untrusted packet sources are by definition in the 262 external part of the perimeter, this means that the packets generated 263 by each of the untrusted sources will reach the perimeter through one 264 interface of a SAVI device. The binding information for that 265 particular source address will be stored in this first SAVI device 266 the packet reaches to. 268 This means the SAVI binding information will be distributed across 269 multiple devices. In order to provide proper source address 270 validation, it is critical that the information distributed among the 271 different SAVI devices is coherent. In particular, it is important 272 to avoid that the same source address is bound to different layer-2 273 anchors in different SAVI devices. Should that occur, then it would 274 mean that two hosts are allowed to send packets with the same source 275 address, which is what we are trying to prevent. In order to 276 preserve the coherency of the SAVI bindings distributed among the 277 SAVI devices within a realm, the Neighbour Discovery (ND) protocol is 278 used, in particular the Neighbour Solicitation (NSOL) and Neighbour 279 Advertisement (NADV) messages. Before creating a SAVI binding in the 280 local SAVI database, the SAVI device will send a NSOL message 281 querying for the address involved. Should any host reply to that 282 message with a NADV message, the SAVI device that sent the NADV will 283 infer that a binding for that address exists in another SAVI device 284 and will not create a local binding for it. If no NADV message is 285 received as a reply to the NSOL, then the local SAVI device will 286 infer that no binding for that address exists in other SAVI device 287 and will create the local SAVI binding for that address. (NOTE that 288 the description included here is overly simplified to illustrate the 289 mechanism used to preserve the coherency of the binding databases of 290 the different SAVI devices. The actual SAVI mechanism normative 291 specification as described in Section 3 varies in the fact that in 292 some cases it is the SAVI device that generates the NSOL while in 293 other cases it simply forwards the NSOL generated by the end host, 294 and that the SAVI device will send multiple copies of the NSOL in 295 order to improve the reliability of the message exchange, among other 296 things). 298 So, summarizing, the proposed SAVI approach relies on the following 299 design choices: 300 o SAVI provides perimetrical security, so some interfaces of a SAVI 301 device will connect to the internal (trusted) part of the topology 302 and other interfaces will connect to the external (untrusted) part 303 of the topology. 304 o A SAVI device only verifies packets coming through one interface 305 connected to the untrusted part of the topology. 306 o A SAVI device only stores binding information for the source 307 addresses that are bound to layer-2 anchors that correspond to 308 interfaces that connect to the untrusted part of the topology. 309 o SAVI uses the NSOL and NADV messages to preserve the coherency of 310 the SAVI binding state distributed among the SAVI devices within a 311 realm. 313 So, in a link that is constituted of multiple L2 devices, some of 314 which are SAVI capable and some of which are not, the SAVI capable 315 devices SHOULD be deployed forming a connected perimeter (i.e. that 316 no data packet can get inside the perimeter without passing through a 317 SAVI device). Packets that cross the perimeter will be validated 318 while packets that do no cross the perimeter are not validated (hence 319 SAVI protection is not provided for these packets). Consider the 320 deployment of SAVI in the topology depicted in the following picture: 322 +--------+ 323 +--+ +--+ +--+ | +--+ | 324 |H1| |H2| |H3| | |R1| | 325 +--+ +--+ +--+ | +--+ | 326 | | | | | | 327 +-------------SAVI-ENFORCEMENT-PERIMETER-----+ | | 328 | | | | | | 329 | +-1-----2-+ +-1-----2-+ | 330 | | SAVI1 | | SAVI2 | | 331 | +-3--4----+ +--3------+ | 332 | | | +--------------+ | | 333 | | +----------| |--------+ | 334 | | | SWITCH-A | | 335 | | +----------| |--------+ | 336 | | | +--------------+ | | 337 | +-1--2----+ +--1------+ | 338 | | SAVI3 | | SAVI4 | | 339 | +-3-----4-+ +----4----+ | 340 | | | | | 341 | +------SAVI-ENFORCEMENT-PERIMETER--------------+ 342 | | | | | 343 | +--+| +--+ +---------+ 344 | |R2|| |H4| |SWICTH-B | 345 | +--+| +--+ +---------+ 346 +------+ | | 347 +--+ +--+ 348 |H5| |H6| 349 +--+ +--+ 351 In the figure above, the SAVI enforcement perimeter is provided by 4 352 SAVI devices, namely SAVI1, SAVI2, SAVI3 and SAVI4. These devices 353 verify information related to the source address both in data and in 354 ND packets and filter packets accordingly. 356 SAVI devices then have two types of ports: trusted ports and 357 validating ports. 358 o Validating ports (VPs) are those in which SAVI processing is 359 performed. This means that when a packet is received through one 360 of the validating ports, the SAVI processing and filtering will be 361 executed. 362 o Trusted ports (TPs) are those in which SAVI processing is not 363 performed. So, packets received through trusted ports are not 364 validated and no SAVI processing is performed in them. 366 Trusted ports are used for connections with trusted infrastructure, 367 including the communication between SAVI devices, the communication 368 with routers and the communication of other switches that while they 369 are not SAVI devices, they only connect to trusted infrastructure 370 (i.e. other SAVI devices, routers or other trusted nodes). So, in 371 the figure above, Port 3 of SAVI1 and port 1 of SAVI3 are trusted 372 because the connect two SAVI devices. Port 4 of SAVI1, port 3 of 373 SAVI2, port 2 of SAVI3 and port 1 of SAVI4 are trusted because the 374 connect to SWITCH-A to which only trusted nodes are connected. In 375 the figure above, port 2 of SAVI2 and port 3 of SAVI3 are trusted 376 ports because they connect to routers. 378 Validating ports are used for connection with non-trusted 379 infrastructure. In particular, hosts are normally connected to 380 validating ports. Non-SAVI switches that are outside of the SAVI 381 enforcement perimeter also are connected through validating port. In 382 particular, non-SAVI devices that connect directly to hosts or that 383 have no SAVI capable device between themselves and the hosts are 384 connected through a validating port. So, in the figure above, ports 385 1 and 2 of SAVI1, port 1 of SAVI2, port 4 of SAVI 3 are validating 386 ports because they connect to hosts. Port 4 of SAVI4 is also a 387 validating port because it is connected to SWITCH-B which is a non- 388 SAVI capable switch which is connected to hosts H5 and H6. 390 3. FCFS SAVI normative specification 392 3.1. FCFS SAVI Data structures 394 FCFS SAVI function relies on state information binding the source 395 address used in data packets to the layer-2 information that 396 contained the first packet that used that source IP address. Such 397 information is stored in FCFS SAVI Data Base (DB). The FCFS SAVI DB 398 will contain a set of entries about the currently used IP source 399 addresses. So each entry will contain the following information: 400 o IP source address 401 o Layer-2 information, such as Layer-2 address, port through which 402 the packet was received, etc 403 o Lifetime 404 o Status:either tentative, valid or testing 405 o Creation time: the value of the local clock when the entry was 406 firstly created 408 In addition to this, FCFS SAVI need to know what are the prefixes 409 that are directly connected, so it maintains a data structure called 410 the the FCFS SAVI prefix list, which contains: 411 o Prefix 412 o Interface where prefix is directly connected 414 3.2. FCFS SAVI algorithm 416 3.2.1. Discovering on-link prefixes 418 In order to distinguish local traffic form transit traffic, the SAVI 419 device relies on the FCFS SAVI Prefix list, which contains the set of 420 on-link prefixes. A SAVI device MUST support the following two 421 methods for populating the Prefix List: Manual configuration and 422 Router Advertisement, as detailed next. 424 Manual configuration: A SAVI device MUST support manual configuration 425 of the on-link prefixes included in the Prefix List. 427 Router Advertisement: A SAVI device MUST support discovery of on-link 428 prefixes through Router Advertisement messages. The SAVI device will 429 learn the on-link prefixes following the procedure defined for a host 430 to process the Prefix Information options described in section 6.3.4 431 of [RFC4861] with the difference that the prefixes will be configured 432 in the FCFS SAVI Prefix List instead than in the ND Prefix List. In 433 addition, when the SAVI device boots, it MUST send a Router 434 Solicitation message as described in section 6.3.7 of [RFC4861], 435 using the unspecified source address. 437 3.2.2. Processing of transit traffic 439 The FCFS SAVI function is located in a forwarding device, such as a 440 router or a layer-2 bridge. The following processing is performed 441 depending on the type of port the packet has been received through: 442 o If the data packet is received through a Trusted port, the data 443 packet is forwarded and no SAVI processing performed to the 444 packet. 445 o If the data packet is received through a Validating port, then the 446 SAVI function checks whether the received data packet is local 447 traffic or transit traffic. It does so by verifying if the source 448 address of the packet belongs to one of the directly connected 449 prefixes available in the receiving interface. It does so by 450 searching the FCFS SAVI Prefix List. 451 * If the IP source address does not belong to one of the local 452 prefixes of the receiving interface, this means that the data 453 packet is transit traffic and the packet SHOULD be discarded. 454 The FCFS SAVI function MAY send an ICMP Destination Unreachable 455 Error back to the source address of the data packet. (ICMPv6, 456 code 5 (Source address failed ingress/egress policy) should be 457 used). 458 * If the source address of the packet does belong to one of the 459 prefixes available in the the receiving port, then the SAVI 460 local traffic validation processes is executed as described 461 below. 463 3.2.3. Processing of local traffic. 465 We describe next how the local traffic, including both control and 466 data packets are processed by the SAVI device using a state machine 467 approach. 469 The state machine described is for the binding of a given source IP 470 address in a given SAVI device. So this means that all the packets 471 described as inputs in the state machine above refer to that given IP 472 address. The key attribute is the IP address. The full state 473 information is: 474 o IP ADDRESS: IPAddr 475 o LAYER_2 ANCHOR: P 476 o LIFETIME: LT 478 The possible states are: 479 o NO_BIND 480 o TENTATIVE 481 o VALID 482 o TESTING_TP 483 o TESTING_VP 484 o TESTING_LIFETIME 486 We will use VP for Validating Port and TP for Trusted Port. 488 After bootstrapping (when no binding exists), the state for all 489 source IP address is NO-BIND i.e. there is no binding for the IP 490 address to any Layer-2 anchor. 492 NO_BIND: The binding for a source IP address entry is in this state 493 when it does not have any binding to a Layer 2 anchor. All addresses 494 are in this state by default after bootstrapping, unless bindings 495 were created for it. 497 TENTATIVE: The binding for a source address for which a data packet 498 or a DAD_NSOL has been received is in this state during the waiting 499 period during which the DAD procedure is being executed (either by 500 the host itself the SAVI device on its behalf). 502 VALID: The binding for the source address has been verified, it is 503 valid and usable for filtering traffic. 505 TESTING_TP-LT: A binding for a source address enters in this state 506 due to one of two reasons: 507 when a Duplicate Address Detection Neighbour Solicitation has been 508 received through a Trusted port. This implies that a host is 509 performing the DAD procedure for that source address in another 510 switch. This may due to an attack or to the fact that the host 511 may have moved. The binding in this state is then being tested to 512 determine which is the situation. 513 the lifetime of the entry is about to expire. This is due to the 514 fact that no packets has been seen by the SAVI device for the 515 LIFETIME period. This may be due to the host simply being silent 516 or because the host has left the location. In order to determine 517 which is the case, a test is performed, in order to determine if 518 the binding information should be discarded. 520 TESTING_VP: A binding for a source address enters in this state when 521 a Duplicate Address Detection Neighbour Solicitation or a data packet 522 has been received through a Validating port other than the one 523 address is currently bound to. This implies that a host is 524 performing the DAD procedure for that source address through a 525 different port. This may due to an attack or to the fact that the 526 host may have moved or just because another host tries to configure 527 an address already used. The binding in this state is then being 528 tested to determine which is the situation. 530 We describe next how the different inputs are processed depending on 531 the state of the binding of the IP address. 533 A simplified figure of the state machine is included below. 535 NO_BIND 537 o Upon the reception through a Validating Port (VP) of a Neighbour 538 Solicitation (NSOL) generated by the Duplicate Address Detection 539 (DAD) procedure (hereafter named DAD_NSOL) containing Target 540 Address IPAddr, the SAVI device MUST execute the process of 541 sending Neighbour Solicitation messages of the Duplicate Address 542 Detection process as described in section 5.4.2 of [RFC4862] for 543 the IPAddr using the following default parameters: 544 DupAddrDetectTransmits set to 2 (i.e. 2 Neighbour Solicitation 545 messages for that address will be sent by the SAVI device) and 546 RetransTimer set to 250 milliseconds (i.e. the time between two 547 Neighbour Solicitation messages is 250 millisecs). This is 548 equivalent to sending the received DAD_NSOL message twice. The 549 DAD_NSOL messages are not sent through any of the ports configured 550 as Validating Ports. The NSOL messages are sent through the 551 proper Trusted Ports (as defined by the switch behaviour that will 552 depend on whether it performs MLD snooping or not). The state is 553 moved to TENTATIVE. The LIFETIME is set to TENT_LT (i.e. 554 LT==TENT_LT), the LAYER_2 ANCHOR is set to VP (i.e. P==VP) and 555 the Creation time is set to the current value of the local clock. 556 o Upon the reception through a Validating Port (VP) of a DATA packet 557 containing IPAddr as the source address, the SAVI device SHOULD 558 execute the process of sending Neighbour Solicitation messages of 559 the Duplicate Address Detection process as described in section 560 5.4.2 of [RFC4862] for the IPAddr using the following default 561 parameters: DupAddrDetectTransmits set to 2 (i.e. 2 Neighbour 562 Solicitation messages for that address will be sent by the SAVI 563 device) and RetransTimer set to 250 milliseconds (i.e. the time 564 between two Neighbour Solicitation messages is 250 millisecs). 565 The implications of not following the reccomended behaviour are 566 described in Appendix A The DAD_NSOL messages are not sent through 567 any of the ports configured as Validating Ports. The NSOL 568 messages are sent through the proper Trusted Ports (as defined by 569 the switch behaviour that will depend on whether it performs MLD 570 snooping or not). The SAVI device MAY discard the data packet 571 while the DAD procedure is being executed. The state is moved to 572 TENTATIVE. The LIFETIME is set to TENT_LT (i.e. LT==TENT_LT), 573 the LAYER_2 ANCHOR is set to VP (i.e. P==VP) and the Creation 574 time is set to the current value of the local clock. 575 o Data packets containing IPAddr as the source address received 576 through Trusted ports are processed and forwarded as usual (i.e. 577 no special SAVI processing) 578 o DAD_NSOL packets containing IPAddr as the target address received 579 through a Trusted port are NOT forwarded through any of the 580 Validating ports but they are sent through the proper Trusted 581 Ports (as defined by the switch behaviour that will depend on 582 whether it performs MLD snooping or not) 583 o Neighbor Advertisement packets sent to all nodes as a reply to the 584 DAD_NSOL (hereafter called DAD_NADV) containing IPAddr as the 585 target address coming through a Validating port are discarded. 586 o Other signaling packets are processed and forwarded as usual (i.e. 587 no SAVI processing) 589 TENTATIVE 591 o If the LIFETIME times out, the state is moved to VALID. The 592 LIFETIME is set to DEFAULT_LT (i.e. LT== DEFAULT_LT). Stored 593 data packets are forwarded (if any). 594 o If a Neighbour Advertisement (NADV) is received through a Trusted 595 Port with Target Address set to IPAddr, then message is forwarded 596 through port P, the state is set to NO_BIND and the LAYER_2 ANCHOR 597 and the LIFETIME are cleared. Data packets stored corresponding 598 to this binding are discarded. 599 o If a NADV is received through a Validating Port with Target 600 Address set to IPAddr, the NADV packet is discarded 601 o If a data packet with source address IPAddr is received with 602 Layer_2 anchor equal to P, then the packet is either stored or 603 discarded. 604 o If a data packet with source address IPAddr is received through a 605 Trusted port, the data packet is forwarded. The state is 606 unchanged (waiting for the NADV). 608 o If a data packet with source address IPAddr is received through a 609 Validating port other than P, the data packet is discarded. 610 o If a DAD NSOL is received from a Trusted port, with target address 611 set to IPAddr, then the message is forwarded to the Validating 612 port P, the state is set to NO_BIND and the LAYER_2 ANCHOR and 613 LIFETIME are cleared. Data packets stored corresponding to this 614 binding are discarded. 615 o If a DAD NSOL with target address set to IPAddr is received from a 616 validating port P' other than P, the message is forwarded to the 617 Validating port P and to the Trusted ports, the state remains in 618 TENTATIVE_DAD_NSOL, but the LAYER_2_ANCHOR is changed from P to P' 619 and LIFETIME is set to TENT_LT. Data packets stored corresponding 620 to the binding with P are discarded. 621 o Other signaling packets are processed and forwarded as usual (i.e. 622 no SAVI processing) 624 VALID 626 o If a data packet containing IPAddr as a source address arrives 627 from Validating port P, then the LIFETIME is set to DEFAULT_LT and 628 the packet is forwarded as usual. 629 o If a DAD_NSOL is received from a Trusted port, then the DAD_NSOL 630 message is forwarded to port P and it is also forwarded to the 631 proper Trusted Ports (as defined by the switch behaviour that will 632 depend on whether it performs MLD snooping or not). The state is 633 changed to TESTING_TP-LT. The LIFETIME is set to TENT_LT. 634 o If a data packet containing source address IPAddr or a DAD_NSOL or 635 DAD_NADV packet with target address set to IPAddr is received 636 through a Validating port P' other than P, then the SAVI device 637 will execute the process of sending DAD_NSOL messages as described 638 in section 5.4.2 of [RFC4862] for the IPAddr using the following 639 default parameters: DupAddrDetectTransmits set to 2 (i.e. 2 NSOL 640 messages for that address will be sent by the SAVI device) and 641 RetransTimer set to 250 milliseconds (i.e. the time between two 642 NSOL messages is 250 millisecs). The DAD_NSOL message will be 643 forwarded to the port P. The state is moved to TESTING_VP. The 644 LIFETIME is set to TENT_LT. The SAVI device MAY discard the data 645 packet while the DAD procedure is being executed. 646 o If the LIFETIME expires, then the SAVI device will execute the 647 process of sending DAD_NSOL messages as described in section 5.4.2 648 of [RFC4862] for the IPAddr using the following default 649 parameters: DupAddrDetectTransmits set to 2 (i.e. 2 NSOL messages 650 for that address will be sent by the SAVI device) and RetransTimer 651 set to 250 milliseconds (i.e. the time between two NSOL messages 652 is 250 millisecs). The DAD_NSOL messages will be forwarded to the 653 port P. The state is changed to TESTING_TP-LT and the LIFETIME is 654 set to TENT_LT. 656 o If a data packet containing IPAddr as a source address arrives 657 from Trusted port, the packet MAY be discarded. The event MAY be 658 logged. 659 o Other signaling packets are processed and forwarded as usual (i.e. 660 no SAVI processing). In particular DAD_NADV coming from port P 661 and containing IPAddr as the target address are forwarded as 662 usual. 664 TESTING_TP-LT 666 o If the LIFETIME expires, the LAYER_2 ANCHOR is cleared and the 667 state is changed to NO_BIND 668 o If a NADV message containing the IPAddr as target address is 669 received through the Validating port P as a reply to the DAD_NSOL 670 message, then the NADV is forwarded as usual and the state is 671 changed to VALID. The LIFETIME is set to DEFAULT_LT 672 o If a data packet containing IPAddr as the source address is 673 received through port P, then the packet is forwarded and the 674 state is changed to VALID. The LIFETIME is set to DEFAULT_LT. 675 o If a DAD_NSOL is received from a Trusted port, the DAD NSOL is 676 forwarded as usual. 677 o If a DAD_NSOL is received from a Validating Port P' other than P, 678 the DAD_NSOL is forwarded as usual, the state is moved to 679 TESTING_VP. 680 o If a data packet is received through a Validating Port port P' 681 that is other than port P, then the packet is discarded. 682 o If a data packet is received through a Trusted Port port, then the 683 packet MAY be discarded. The event MAY be logged. 685 TESTING_VP 687 o If the LIFETIME expires, the LAYER_2 ANCHOR is modified from P to 688 P', the LIFETIME is set to DEFAULT_LT and the state is changed to 689 VALID. Data packet stored coming from P' are forwarded. 690 o If a NADV message containing the IPAddr as target address is 691 received through the Validating port P as a reply to the DAD_NSOL 692 message, then the NADV is forwarded as usual and the state is 693 changed to VALID. The LIFETIME is set to DEFAULT_LT 694 o If a data packet containing IPAddr as the source address is 695 received through port P, then the packet is forwarded. 696 o If a data packet is received through a Validating Port P'' that is 697 other than port P or P', then the packet is discarded. 698 o If a data packet is received through a Trusted Port port that is 699 other than port P, the state is moved to TESTING_TP-LT, and the 700 packet MAY is discarded. 701 o If a DAD_NSOL is received through Trusted Port, the packet is 702 forwarded as usual and the state is moved to TESTING_TP-LT. 704 o If a DAD_NSOL is received through Validating Port P'' other than P 705 or P', the packet is forwarded as usual and P'==P'' 707 Simplified state machine figure 709 +---------+ VP_NSOL, VP_DATA/2xNSOL +-----------+ 710 | |---------------------------------------->| | 711 | NO_BIND | | TENTATIVE | 712 | |<----------------------------------------| | 713 +---------+ TP_NADV, TP_NSOL/- +-----------+ 714 ^ | 715 | | T.O. 716 T.O.| | 717 | v 718 +---------+ VP_NADV/- +-----------+ 719 | |---------------------------------------->| | 720 | TESTING | | VALID | 721 | TP-LT |<----------------------------------------| | 722 +---------+ TP_NSOL/- +-----------+ 723 ^ | ^ | 724 | | | | 725 | +--------------------- ---------------------+ | 726 | VP_NSOL/- | | NP_NADV, T.O./- | 727 | v | | 728 | +-----------+ | 729 | | | | 730 +---------------------| TESTING |<----------------------+ 731 VP_NSOL, VP_DATA/- | VP | T.O., VP_DATA, VP_NSOL, 732 +-----------+ VP_NADV/2xNSOL 734 MLD considerations 736 The SAVI device must join the Solicited Node Multicast group for all 737 the addresses which state is other than NO_BIND. This is needed to 738 make sure that the SAVI device will receive the DAD_NSOL for those 739 addresses. Please note that it may not be enough to relay on the 740 host behind the Validating port doing so, since the node may move and 741 after a while, the packets for that particular solicited node 742 multicast group will no longer be forwarded to the SAVI device. So, 743 the SAVI device SHOULD join the solicited node multicast groups for 744 all the addresses that are in a state other than NO_BIND 746 3.2.4. SAVI port configuration guidelines 748 The guidelines for port configuration in SAVI devices are: 749 o Ports that are connected to another SAVI device SHOULD be 750 configured as Trusted ports. Not doing so will at least 751 significantly increase the memory consumption in the SAVI devices. 753 o Ports connected to hosts SHOULD be configured as Validating ports. 754 Not doing so will allow the host connected to that port to send 755 packets with spoofed source address. 756 o Ports connected to routers SHOULD be configured as Trusted ports. 757 Configuring them as Validating ports would increase the signaling 758 due to SAVI. The implication is that a router can generate 759 traffic with any source address as they are assumed to be part of 760 the trusted infrastructure. 761 o Ports connected to a chain of one or more legacy switches that 762 have hosts connected SHOULD be configured as Validating ports. 763 Not doing so will allow the host connected to any of these 764 switches to send packets with spoofed source address. 765 o Ports connected to a chain of one or more legacy switches that 766 have other SAVI devices and/or routers connected but had no hosts 767 attached to them SHOULD be configured as Trusted ports. Not doing 768 so will at least significantly increase the memory consumption in 769 the SAVI devices and increase the signaling traffic due to SAVI 770 validation. 771 o Ports connected to a chain of one or more legacy switches that 772 have a mix of SAVI devices and/or routers with hosts, SHOULD be 773 configured as Validating ports. Not doing so will allow the host 774 connected to that port to send packets with spoofed source 775 address. Nevertheless, this topology will result in increased 776 SAVI signaling and memory consumption compared to a topology where 777 SAVI-hosts communications and inter SAVI communications are kept 778 through different legacy switches. 780 3.2.5. VLAN support 782 In the case the SAVI device is a switch that supports VLANs, the SAVI 783 implementation will behave as if there was one SAVI process per VLAN. 784 The SAVI process of each VLAN will store the binding information 785 corresponding the the nodes attached to that particular VLAN. 787 3.3. Protocol Constants 789 TENT_LT is 500 miliseconds 791 DEFAULT_LT is 5 minutes 793 4. Security Considerations 795 First of all, it should be noted that any SAVI solution will be as 796 strong as the lower layer anchor that it uses. In particular, if the 797 lower layer anchor is forgeable, then the resulting SAVI solution 798 will be weak. For example, if the lower layer anchor is a MAC 799 address that can be easily spoofed, then the resulting SAVI will not 800 be stronger than that. On the other hand, if we use switch ports as 801 lower layer anchors (and there is only one host connected to each 802 port) it is likely that the resulting SAVI solution will be 803 considerably more secure. 805 Denial of service attacks 807 There are two types of DoS attacks that can be envisaged in a SAVI 808 environment. On one hand, we can envision attacks against the SAVI 809 device resources. On the other hand, we can envision DoS attacks 810 against the hosts connected to the network where SAVI is running. 812 The attacks against the SAVI device basically consist on making the 813 SAVI device to consume its resource until it runs out of them. For 814 instance, a possible attack would be to send packets with different 815 source addresses, making the SAVI device to create state for each of 816 the addresses and waste memory. At some point the SAVI device runs 817 out of memory and it needs to decide how to react in this situation. 818 The result is that some form of garbage collection is needed to prune 819 the entries. It is RECOMMENDED that when the SAVI device runs out of 820 the memory allocated for the SAVI DB, it creates new entries by 821 deleting the entries which Creation Time is higher. This implies 822 that older entries are preserved and newer entries overwrite each 823 other. In an attack scenario where the attacker sends a batch of 824 data packets with different source address, each new source address 825 is likely to rewrite another source address created by the attack 826 itself. It should be noted that entries are also garbage collected 827 using the LIFETIME, which is updated using data packets. The result 828 is that in order for an attacker to actually fill the SAVI DB with 829 false source addresses, it needs to continuously send data packets 830 for all the different source addresses, in order for the entries to 831 grow old and compete with the legitimate entries. The result is that 832 the cost of the attack for the attacker is highly increased. 834 In addition, it is also RECOMMENDED that a SAVI device reserves a 835 minimum amount of memory for each available port (in the case where 836 the port is used as part of the L2 anchor). The recommended minimum 837 is the memory needed to store 4 bindings associated to the port. The 838 motivation for this recommendation is as follows: an attacker 839 attached to a given port of a SAVI device may attempt to launch a DoS 840 attack towards the SAVI device by creating many bindings for 841 different addresses. It can do so, by sending DAD NSOL for different 842 addresses. The result is that the attack will consume all the memory 843 available in the SAVI device. The above recommendation aims to 844 reserve a minimum amount of memory per port, so that hosts located in 845 different ports can make use of the reserved memory for their port 846 even if a DoS attack is occurring in a different port. 848 As the SAVI device may store data packets while the address is being 849 verified, the memory for data packet storage may also be a target of 850 DoS attacks. The effects of such attacks may be limited to the lack 851 of capacity to store new data packets. The effect of such attack 852 will be then that data packets will be dropped during the 853 verification period. a SAVI device MUST limit the amount of memory 854 used to store data packets, allowing the other functions to have 855 available memory even in the case of an attacks as the above 856 described. 858 The other type of attack is when an attacker manages to create state 859 in the SAVI device that will result in blocking the data packets sent 860 by the legitimate owner of the address. In IPv6 these attacks are 861 not an issue thanks to the 2^64 addresses available in each link. 863 The SAVI device generates 2 DAD_NSOL packets upon the reception of a 864 DAD_NSOL or a data packet. As such, the SAVI device can be used as 865 an amplifier by attackers. In order to limit this type of attack, it 866 is RECOMMENDED that the SAVI device performs rate limiting of the 867 messages it generates. The rate limiting is performed on a per port 868 basis, since having an attack on a given port should not prevent the 869 SAVI device to function normally in the rest of the ports. 871 Residual threats. 873 SAVI perform its function by binding an IP source address to a 874 Layer_2 anchor. If the attacker manages to send packets using the 875 Layer_2 anchor associated to a given IP address, SAVI validation will 876 be successful and the SAVI device will allow the packet through. 877 This can be achieved by spoofing the Layer_2 anchor or because the 878 Layer_2 anchor is shared among the legitimate owner of the address 879 and the attacker. An example of the latter is the case where the 880 Layer_2 anchor is a port of a switched network and a legacy switch 881 (i.e. no SAVI capable switch) is connected to that port. All the 882 source addresses of the hosts connected tot he legacy switch will 883 share the same Layer_2 anchor (i.e. the switch port). This means 884 that hosts connected to the legacy switch can spoof each others IP 885 address and this will not be detected by the SAVI device. This can 886 be prevented by not sharing Layer_2 anchors among hosts. 888 FCFS SAVI assumes that a host will be able to defend its address when 889 the DAD procedure is executed for its addresses. This is needed, 890 among other things, to support mobility within a link (i.e. to allow 891 a host to detach and reconnect to a different Layer_2 anchor of the 892 same IP subnetwork, without changing its IP address). This means 893 that when a DAD_NSOL is issued for a given IP address for which a 894 binding exists in a SAVI device, the SAVI device expects to see a 895 DAD_NADV coming from the Layer_2 anchor associated to that IP address 896 in order to preserve the binding. If the SAVI device does not sees 897 the DAD_NADV, it may grant the binding to a different Layer_2 anchor. 898 This means that if an attacker manages to prevent a host from 899 defending its source address, it will be able to destroy the existing 900 binding and create a new one, with a different Layer_2 anchor. An 901 attacker may do so for example by intercepting the DAD_NADV or 902 launching a DoS attack to the host that will prevent it to issue 903 proper DAD replies. 905 5. Contributors 907 Jun Bi 908 CERNET 909 Network Research Center, Tsinghua University 910 Beijing 100084 911 China 912 Email: junbi@cernet.edu.cn 914 Guang Yao 915 CERNET 916 Network Research Center, Tsinghua University 917 Beijing 100084 918 China 919 Email: yaog@netarchlab.tsinghua.edu.cn 921 Fred Baker 922 Cisco Systems 923 Email: fred@cisco.com 925 Alberto Garcia Martinez 926 University Carlos III of Madrid 927 Email: alberto@it.uc3m.es 929 6. Acknowledgments 931 This draft benefited from the input from: Joel Halpern, Christian 932 Vogt, Dong Zhang, Frank Xia, Jean-Michel Combes and Lin Tao. 934 Marcelo Bagnulo is partly funded by Trilogy, a research project 935 supported by the European Commission under its Seventh Framework 936 Program. 938 7. References 939 7.1. Normative References 941 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 942 Defeating Denial of Service Attacks which employ IP Source 943 Address Spoofing", BCP 38, RFC 2827, May 2000. 945 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 946 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 947 September 2007. 949 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 950 Address Autoconfiguration", RFC 4862, September 2007. 952 7.2. Informative References 954 [I-D.ietf-savi-framework] 955 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 956 "Source Address Validation Improvement Protocol 957 Framework", draft-ietf-savi-framework-00 (work in 958 progress), September 2010. 960 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 961 for IPv6", RFC 4429, April 2006. 963 Appendix A. Implications of not following the reccommended behaviour 965 This specification recommends SAVI implementations to generate a 966 DAD_NSOL message upon the reception of a data packet for which they 967 have no binding for. In this section we describe the implications of 968 not doing so and simply discarding the data packet instead. 970 The main argument against discarding the data packet is the overall 971 robustness of the resulting network. The main concern that has been 972 stated is that a network running SAVI that discard data packets in 973 this case may end up disconnecting legitimate users from the network, 974 by filtering packets coming from them. The net result would a 975 degraded robustness of the network as w whole, since legitimate users 976 would perceive this as a network failure. There are three different 977 causes that resulted in the lack of state in the binding device for a 978 legitimate address, namely, packet loss, state loss and topology 979 change. We will next perform an analysis for each of them. 981 A.1. Lack of binding state due to packet loss 983 The DAD procedure is inherently unreliable. It consists on sending a 984 NSOL packet and if no NADV packet is received back, success is 985 assumed and the host starts using the address. In general, the lack 986 of response is because no other host has that particular address 987 configured in their interface, but it may also be the case that the 988 NSOL packet or the NADV packet has been lost. From the sending host 989 perspective there is no difference and the host assumes that it can 990 use the address. In other words, the default action is to allow the 991 host to obtain network connectivity. 993 It should be noted that the loss of a DAD packet has little impact on 994 the network performance, since address coalition is very rare and the 995 host assumes success in that case. By designing a SAVI solution that 996 would discard packets for which there is no binding, we are 997 diametrically changing the default behavior in this respect, since 998 the default would be that if the DAD packets are lost, then the node 999 is disconnected from the network (as its packets are filtered). What 1000 is worse, the node has little clue of what is going wrong, since it 1001 has successfully configured an address but it has no connectivity. 1002 The net result is that the overall reliability of the network has 1003 significantly decreased as the lost of a single packet would imply 1004 that a host is disconnected from the network. 1006 The only mechanism that the DAD has to improve its reliability is to 1007 send multiple NSOL. However, current RFC4862 defines a default value 1008 of 1 NSOL message for the DAD procedure, so requiring any higher 1009 value would imply manual configuration of all the hosts connected to 1010 the SAVI domain. 1012 A.1.1. Why initial packets may be (frequently) lost 1014 The case of LANs 1016 Devices connecting to a network may experience periods of packet loss 1017 after the link-layer becomes available for two reasons: Invalid 1018 Authentication state and incomplete topology assessment. In both 1019 cases, physical-layer connection occurs initially and presents a 1020 medium where packeted are transmissable, but frame forwarding is not 1021 available across the LAN. 1023 For the authentication system, devices on a controlled port are 1024 forced to complete 802.1X authentication which may take multiple 1025 round trips and many milliseconds to complete (see IEEE 802.1X-2004). 1026 In this time, initial DHCP, IPv6 Neighbour Discovery, Multicast 1027 Listener or Duplicate Address Detection messages may be transmitted. 1028 However, it has also been noted that some devices have the ability 1029 for the IP stack to not see the port as up until 802.1x has 1030 completed. Hence, that issue needs investigation to determine how 1031 common it is now. 1033 Additionally, any system which requires user input at this stage can 1034 extend the authentication time, and thus the outage. This is 1035 problematic where hosts relying upon DHCP for address configuration 1036 time out. 1038 Upon completion of authentication, it is feasible to signal upper 1039 layer protocols as to LAN forwarding availability. This is not 1040 typical today, so it is necessary to assume that protocols are not 1041 aware of the preceding loss period. 1043 For environments which do not require authentication, addition of a 1044 new link can cause loops where LAN frames are forwarded continually. 1045 In order to prevent loops, all LANs today run a spanning-tree 1046 protocol, which selectively disables redundant ports. Devices which 1047 perform spanning-tree calculations are either traditional Spanning- 1048 Tree Protocol (STP) (see IEEE802.1D-1998) or rapidly converging 1049 versions of the same (RSTP/MSTP) (see IEEE 802.1D-2004 and IEEE 1050 802.1Q-2005). 1052 Until a port is determined to be an edge port (RSTP/MSTP), the rapid 1053 protocol speaker has identified its position within the spanning-tree 1054 (RSTP/MSTP) or completed a Listening phase (STP), its packets are 1055 discarded. 1057 For ports which are not connected to rapid protocol switches, it 1058 takes a minimum three seconds to perform edge port determination (see 1059 IEEE 802.1D-2004). Alternatively completion of Listening phase takes 1060 15 seconds (see IEEE 802.1D-1998). This means that during this 1061 period, the link-layer appears available, but initial packet 1062 transmissions into and out of this port will fail. 1064 It is possible to pre-assess ports as edge ports using manual 1065 configuration of all the involved devices and thus make them 1066 immediately transmissible. This is never default behaviour though. 1068 The case fixed access networks 1070 In fixed access networks such as DSL and Cable the end hosts are 1071 usually connected to the access network through a residential gateway 1072 (RG). If the host interface is initialized prior to the residential 1073 gateway getting authenticated and connected to the access network, 1074 the access network is not aware of the DAD packets that the host sent 1075 out. As an example, in DSL networks the Access Node(DSLAM) that 1076 needs to create and maintain binding state will never see the DAD 1077 message that is required to create such state. 1079 A.1.1.1. Special sub-case:SAVI device rate-limiting packets 1081 A particular sub-case is the one where the SAVI device itself "drops" 1082 ND packets. In order to protect itself against DoS attacks and 1083 flash-crowds, the SAVI device will have to rate-limit the processing 1084 of packets triggering the state creation process (which require 1085 processing from the SAVI device). This implies that the SAVI device 1086 may not process all the ND packets in case it is under heavy 1087 conditions. The result is that the SAVI device will fail to create a 1088 binding for a given DAD NSOL packet, which implies that the data 1089 packets coming from the host that sent the DAD NSOL packet will be 1090 filtered if this approach is adopted. The problem is that the host 1091 will assume that the DAD procedure was successful and will not 1092 perform the DAD procedure again which in turn will imply that the 1093 host will be disconnected from the network. While it is true that 1094 the SAVI device will also have to rate limit the processing of the 1095 data packets, the host will keep on sending data packets, so it is 1096 possible to recover from the alternative approach where data packets 1097 trigger the binding creation procedure. 1099 A.2. Lack of binding state due to a change in the topology 1101 In the case SAVI is being deployed in a switched Ethernet network, 1102 topology changes may result in a SAVI device receiving packets from a 1103 legitimate user for which the SAVI device does not have a binding 1104 for. Consider the following example: 1106 +------+ +--------+ +---------------+ 1107 |SAVI I|-------------|SWITCH I|-------|rest of the net| 1108 +------+ +--------+ +---------------+ 1109 | | 1110 | +--------+ 1111 | | SAVI II| 1112 | +--------+ 1113 | +----------+ | 1114 +---|SWITCH II |-----+ 1115 +----------+ 1116 | 1117 +-----+ 1118 | Host| 1119 +-----+ 1121 Suppose that after bootstrapping all the elements are working 1122 properly and the spanning tree is rooted in the router and it 1123 includes one branch that goes SWITCH I-SAVI I- SWITCH II and another 1124 branch that goes SWITCH I-SAVI II. 1126 Suppose that the Host boots at this moment and sends the DAD NSOL. 1127 The message is propagated through the spanning tree and it received 1128 by SAVI I but not by SAVI II. SAVI I creates the binding. 1130 Suppose that SAVI I fails and the spanning tree reconverges to SWITCH 1131 I- SAVI II- SWITCH II. Now data packets coming from the Host will be 1132 coursed through SAVI II which does not have binding state and will 1133 drop the packets. 1135 A.3. Lack of binding state due to state loss 1137 The other reason why a SAVI device may not have state for a 1138 legitimate address is simply because it lost it. State can be lost 1139 due to a reboot of the SAVI device or other reasons such as memory 1140 corruption. So, the situation would be as follows: The host performs 1141 the DAD procedure and the SAVI device creates a binding for the 1142 host's address. The host successfully communicate for a while. The 1143 SAVI device reboots and lost the binding state. The packets coming 1144 from the host are now discarded as there is no binding state for that 1145 address. It should be noted that in this case, the host has been 1146 able to use the address successfully for a certain period of time. 1148 Architecturally, the degradation of the network robustness in this 1149 case can be easily explained by observing that this approach to SAVI 1150 implementation breaks the fate-sharing principle. RFC 1958 reads: 1151 An end-to-end protocol design should not rely on the maintenance 1152 of state (i.e. information about the state of the end-to-end 1153 communication) inside the network. Such state should be 1154 maintained only in the endpoints, in such a way that the state can 1155 only be destroyed when the endpoint itself breaks (known as fate- 1156 sharing). 1157 By binding the fate of the host's connectivity to the state in the 1158 SAVI device, we are breaking this principle and the result is 1159 degraded network resilience. 1161 Moving on to more practical matters, we can dig deeper into the 1162 actual behaviour by considering two scenarios, namely, the case where 1163 the host is directly connected to the SAVI device and the case where 1164 there is an intermediate device between the two. 1166 A.3.1. The case of a host directly connected to the SAVI device 1168 The considered scenario is depicted in the following picture: 1170 +------+ +-----------+ +---------------+ 1171 | Host |-------------|SAVI device|-------|rest of the net| 1172 +------+ +-----------+ +---------------+ 1174 The key distinguishing element of this scenario is that the host is 1175 directly connected to the SAVI device. As a result, if the SAVI 1176 device reboots, the host will see the carrier disappear and appear 1177 again. 1179 RFC4862 requires that the DAD procedure is performed when the IP 1180 address is assigned to the interface, quoting RFC4862 section 5.4. 1181 Duplicate Address Detection: 1182 Duplicate Address Detection MUST be performed on all unicast 1183 addresses prior to assigning them to an interface, regardless of 1184 whether they are obtained through stateless autoconfiguration, 1185 DHCPv6, or manual configuration, with the following exceptions:... 1187 However, it has been stated that some of the widely used OSes 1188 actually do perform DAD each time the link is up, but further data 1189 would be required to take this for granted. Assuming that behaviour, 1190 that implies that if the lost of state in the SAVI device also 1191 results in the link to the host going down, then the host using the 1192 tested OSes would redo the DAD procedure allowing the recreation of 1193 the binding state in the SAVI device and preserving the connectivity 1194 of the host. This would be the case if the SAVI device reboots. It 1195 should be noted though, that it is also possible that the binding 1196 state is lost for whatever error in the SAVI process and that the 1197 SAVI link does not goes down. In this case, the host would not redo 1198 the DAD procedure. However, it has been pointed out that it would be 1199 possible to require the SAVI process to flap the links of the device 1200 it is running, in order to make sure that the links goes down each 1201 time the SAVI process restarts and improving the chances the host 1202 will redo the DAD procedure when the SAVI process is rebooted. 1204 A.3.2. The case of a host connected to the SAVI device through one or 1205 more legacy devices. 1207 The considered scenario is depicted in the following picture: 1209 +------+ +-------------+ +-----------+ +---------------+ 1210 | Host |------|Legacy device|-------|SAVI device|-------|rest of the net| 1211 +------+ +-------------+ +-----------+ +---------------+ 1213 The key distinguishing element of this scenario is that the host is 1214 not directly connected to the SAVI device. As a result, if the SAVI 1215 device reboots, the host will not see any changes. 1217 In this case, the host would get get disconnected from the rest of 1218 the network since the SAVI device would filter all its packets once 1219 the state has gone. As the node will not perform the DAD procedure 1220 again, it will remain disconnected until it reboots. 1222 As a final comment, it should be noted that it may not be obvious to 1223 the network admin which scenario its network is running. Consider 1224 the case of a campus network where all the switches in the network 1225 are SAVI capable. A small hub connected in the office would turn 1226 this into the scenario where the host is not directly connected to 1227 the SAVI device. Moreover, consider the case of a host running 1228 multiple virtual machines connected through a virtual hub, depending 1229 on the implementation of such a virtual hub, may turn a directly 1230 connected host scenario to the scenario where the multiple (virtual) 1231 hosts are connected through a legacy (virtual) hub. 1233 A.3.2.1. Enforcing direct connectivty between the SAVI device and the 1234 host 1236 Some people have argued that enforcing the direct connectivity 1237 between the SAVI device and the end host is actually a feature. 1238 There are several comments that can be made in this respect: 1239 First, it may well be the case in some scenarios this is 1240 desirable, but it is certainly not the case in most scenarios. 1241 Because of that, the issue of enforcing direct connectivity must 1242 be treated as orthogonal to how data packets for which there is no 1243 binding are treated, since a general solution must support 1244 directly connected nodes and nodes connected through legacy 1245 switches. 1246 Second, as a matter of fact, the resulting behaviour described 1247 above would not actually enforce direct connectivity between the 1248 end host and the SAVI device as it would work as long as the SAVI 1249 device would not reboot. So, the argument being made is that this 1250 approach is not good enough to provide a a robust network service, 1251 but it is not bad enough to enforce the direct connectivity of 1252 host to the SAVI switch. 1253 Third, it should be noted that topology enforcement is not part of 1254 the SAVI problem space and that the SAVI problem by itself is hard 1255 enough to add additional requirements. 1257 Authors' Addresses 1259 Erik Nordmark 1260 Sun Microsystems, Inc. 1261 17 Network Circle 1262 Menlo Park, CA 94025 1263 USA 1265 Phone: +1 650 786 2921 1266 Email: Erik.Nordmark@Sun.COM 1268 Marcelo Bagnulo 1269 Universidad Carlos III de Madrid 1270 Av. Universidad 30 1271 Leganes, Madrid 28911 1272 SPAIN 1274 Phone: 34 91 6248814 1275 Email: marcelo@it.uc3m.es 1276 URI: http://www.it.uc3m.es 1278 Eric Levy-Abegnoli 1279 Cisco Systems 1280 Village d'Entreprises Green Side - 400, Avenue Roumanille 1281 Biot-Sophia Antipolis - 06410 1282 France 1284 Email: elevyabe@cisco.com