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