idnits 2.17.1 draft-ietf-savi-fcfs-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2012) is 4450 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) == Outdated reference: A later version (-34) exists of draft-ietf-savi-dhcp-12 == Outdated reference: A later version (-11) exists of draft-ietf-savi-send-06 Summary: 0 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 Cisco 4 Intended status: Standards Track M. Bagnulo 5 Expires: August 21, 2012 UC3M 6 E. Levy-Abegnoli 7 Cisco Systems 8 February 18, 2012 10 FCFS SAVI: First-Come First-Serve Source-Address Validation for Locally 11 Assigned IPv6 Addresses 12 draft-ietf-savi-fcfs-14 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 help detect and prevent source address 20 spoofing. 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 August 21, 2012. 39 Copyright Notice 41 Copyright (c) 2012 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. 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. FCFS SAVI protection perimeter . . . . . . . . . . . . . . 6 75 2.6. Special cases . . . . . . . . . . . . . . . . . . . . . . 10 76 3. FCFS SAVI specification . . . . . . . . . . . . . . . . . . . 11 77 3.1. FCFS SAVI Data structures . . . . . . . . . . . . . . . . 11 78 3.2. FCFS SAVI algorithm . . . . . . . . . . . . . . . . . . . 11 79 3.2.1. Discovering on-link prefixes . . . . . . . . . . . . . 11 80 3.2.2. Processing of transit traffic . . . . . . . . . . . . 12 81 3.2.3. Processing of local traffic. . . . . . . . . . . . . . 13 82 3.2.4. FCFS SAVI port configuration guidelines . . . . . . . 19 83 3.2.5. VLAN support . . . . . . . . . . . . . . . . . . . . . 20 84 3.3. Default Protocol Values . . . . . . . . . . . . . . . . . 20 85 4. Security Considerations . . . . . . . . . . . . . . . . . . . 20 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 87 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 90 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 91 8.2. Informative References . . . . . . . . . . . . . . . . . . 24 92 Appendix A. Implications of not following the recommended 93 behaviour . . . . . . . . . . . . . . . . . . . . . . 25 94 A.1. Implications of not generating DAD-NS packets upon the 95 reception of non compliant data packets . . . . . . . . . 25 96 A.1.1. Lack of binding state due to packet loss . . . . . . . 25 97 A.1.2. Lack of binding state due to a change in the 98 topology . . . . . . . . . . . . . . . . . . . . . . . 28 99 A.1.3. Lack of binding state due to state loss . . . . . . . 29 100 A.2. Implications of not diacarding non compliant data 101 packets . . . . . . . . . . . . . . . . . . . . . . . . . 31 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 104 1. Introduction 106 This memo describes FCFS SAVI, a mechanism to provide source address 107 validation for IPv6 networks using the First-Come First-Serve 108 principle. The proposed mechanism is intended to complement ingress 109 filtering techniques to help detect and prevent source address 110 spoofing. Section 2 gives the background and description of FCFS 111 SAVI, and Section 3 specifies the FCFS SAVI protocol. 113 2. Background to FCFS SAVI 115 2.1. Scope of FCFS SAVI 117 The application scenario for FCFS SAVI is limited to the local link. 118 Hence, the goal of FCFS SAVI is to verify that the source address of 119 the packets generated by the hosts attached to the local link have 120 not been spoofed. 122 In a link there usually are hosts and routers attached. Hosts 123 generate packets with their own address as the source address. This 124 is called the local traffic. Routers send packets containing a 125 source IP address other than their own, since they are forwarding 126 packets generated by other hosts (usually located in a different 127 link). This is called the transit traffic. 129 The applicability of FCFS SAVI is limited to the local traffic i.e. 130 to verify if the traffic generated by the hosts attached to the local 131 link contains a valid source address. The verification of the source 132 address of the transit traffic is out of the scope of FCFS SAVI. 133 Other techniques, like ingress filtering [RFC2827], are recommended 134 to validate transit traffic. In that sense, FCFS SAVI complements 135 ingress filtering, since it relies on ingress filtering to validate 136 transit traffic but it provides validation of local traffic, which is 137 not provided by ingress filtering. Hence, the security level is 138 increased by using these two techniques. 140 In addition, FCFS SAVI is designed to be used with locally assigned 141 IPv6 addresses, in particular with IPv6 addresses configured through 142 Stateless Address Autoconfiguration (SLAAC) [RFC4862]. Manually 143 configured IPv6 addresses can be supported by FCFS SAVI, but manual 144 configuration of the binding on the FCFS SAVI device provides higher 145 security and seems compatible with manual address management. FCFS 146 SAVI can also be used with IPv6 addresses assigned via DHCPv6, since 147 they ought to perform the Duplicate Address Detection procedure, but 148 there is a specific mechanism tailored for dealing with DHCP assigned 149 addresses defined in [I-D.ietf-savi-dhcp]. Additional considerations 150 about how to use FCFS SAVI depending on the type of address 151 management used and the nature of the addresses is discussed in the 152 framework document [I-D.ietf-savi-framework]. 154 2.2. Constraints for FCFS SAVI design 156 FCFS SAVI is designed to be deployed in existing networks requiring a 157 minimum set of changes. For that reason, FCFS SAVI does not require 158 any changes in the hosts which source address is to be verified. Any 159 verification solely relies in the usage of already available 160 protocols. In other words, FCFS SAVI does not define a new protocol 161 nor define any new message on existing protocols nor require that a 162 host uses an existent protocol message in a different way. In other 163 words, the requirement is no host changes. 165 FCFS SAVI validation is performed by the FCFS SAVI function. Such 166 function can be placed in different type of devices, including a 167 router or a layer-2 bridge. The basic idea is that the FCFS SAVI 168 function is located in the points of the topology that can enforce 169 the correct usage of source address by dropping the non-compliant 170 packets. 172 2.3. Address ownership proof 174 The main function performed by FCFS SAVI is to verify that the source 175 address used in data packets actually belongs to the originator of 176 the packet. Since FCFS SAVI scope is limited to the local link, the 177 originator of the packet is attached to the local link. In order to 178 define a source address validation solution, we need to define the 179 meaning of "address ownership"; i.e., what it means that a given host 180 owns a given address in the sense that the host is entitled to send 181 packets with that source address. With that definition, we can 182 define how a device can confirm that the source address in a datagram 183 is owned by the originator of the datagram. 185 In FCFS SAVI the address ownership proof is based in the First-Come 186 First- Serve principle. The first host that claims a given source 187 address is the owner of the address until further notice. Since no 188 host changes are acceptable, we need to find the means to confirm 189 address ownership without requiring a new protocol. So, whenever a 190 source address is used for the first time, a state is created in the 191 device that is performing the FCFS SAVI function binding the source 192 address to a binding anchor which consists on layer-2 information 193 that the FCFS SAVI box has available (e.g. the port in a switched 194 LAN). Subsequent data packets containing that IP source address can 195 be checked against the same binding anchor to confirm that the 196 originator owns the source IP address. 198 There are however additional considerations to be taken into account. 200 For instance, consider the case of a host that moves from one segment 201 of a LAN to another segment of the same subnetwork and it keeps the 202 same IP address. In this case, the host is still the owner of the IP 203 address, but the associated binding anchor may have changed. In 204 order to cope with this case, the defined FCFS SAVI behaviour implies 205 the verification whether the host is still reachable using the 206 previous binding anchor. In order to do that FCFS SAVI uses the 207 Neighbour Discovery (ND) protocol. If the host is no longer 208 reachable at the previously recorded binding anchor, FCFS SAVI 209 assumes that the new location is valid and creates a new binding 210 using the new binding anchor. In case the host is still reachable 211 using the previously recorded binding anchor, the packets coming from 212 the new binding anchor are dropped. 214 Note that this only applies to local traffic. Transit traffic 215 generated by a router would be verified using alternative techniques, 216 such as ingress filtering. FCFS SAVI checks would not be fulfilled 217 by the transit traffic, since the router is not the owner of the 218 source address contained in the packets. 220 2.4. Binding Anchor considerations 222 Any SAVI solution is not stronger than the binding anchor it uses. 223 If the binding anchor is easily spoofable (e.g. a MAC address), then 224 the resulting solution will be weak. The treatment of non-compliant 225 packets needs to be tuned accordingly. In particular, if the binding 226 anchor is easily spoofable and the FCFS SAVI device is configured to 227 drop non-compliant packets, then the usage of FCFS SAVI may open a 228 new vector of Denial of Service (DoS) attacks, based on spoofed 229 binding anchors. For that reason, in this specification only switch 230 ports MUST be used as binding anchors. Other forms of binding 231 anchors are out of the scope of this specification and proper 232 analysis of the implications of using them should be performed before 233 their usage. 235 2.5. FCFS SAVI protection perimeter 237 FCFS SAVI provides perimetrical security. FCFS SAVI devices form 238 what can be called a FCFS SAVI protection perimeter and they verify 239 that any packet that crosses the perimeter is compliant (i.e. the 240 source address is validated). Once the packet is inside the 241 perimeter, no further validations are performed to the packet. This 242 model has implications both on how FCFS SAVI devices are deployed in 243 the topology and on the configuration of the FCFS SAVI boxes. 245 The implication of this perimetrical security approach, is that there 246 is part of the topology that is inside the perimeter and part of the 247 topology that is outside the perimeter. So, while packets coming 248 from interfaces connected to the external part of the topology need 249 to be validated by the FCFS SAVI device, packets coming from 250 interfaces connected to the internal part of the topology do not need 251 to be validated. This significantly reduces the processing 252 requirements of the FCFS SAVI device. It also implies that each FCFS 253 SAVI device that is part of the perimeter, must be able to verify the 254 source addresses of the packets coming from the interfaces connected 255 to the external part of the perimeter. In order to do so, the FCFS 256 SAVI device binds the source address to a binding anchor. 258 One possible approach would be for every FCFS SAVI device to store 259 binding information about every source addresses in the subnetwork. 260 In this case, every FCFS SAVI device would store a binding for each 261 source address of the local link. The problem with this approach is 262 that it imposes significant memory burden on the FCFS SAVI devices. 263 In order to reduce the memory requirements imposed to each device, 264 the FCFS SAVI solution described in this specification distributes 265 the storage of FCFS SAVI binding information among the multiple FCFS 266 SAVI devices of a subnetwork. The FCFS SAVI binding state is 267 distributed across the FCFS SAVI devices according to the following 268 criteria: each FCFS SAVI device only stores binding information about 269 the source addresses bound to anchors corresponding to the interfaces 270 that connect to the part of the topology that is outside of the FCFS 271 SAVI protection perimeter. Since all the untrusted packet sources 272 are by definition in the external part of the perimeter, packets 273 generated by each of the untrusted sources will reach the perimeter 274 through an interface of a FCFS SAVI device. The binding information 275 for that particular source address will be stored in this first FCFS 276 SAVI device the packet reaches to. 278 The result is that the FCFS SAVI binding information will be 279 distributed across multiple devices. In order to provide proper 280 source address validation, it is critical that the information 281 distributed among the different FCFS SAVI devices is coherent. In 282 particular, it is important to avoid that the same source address is 283 bound to different binding anchors in different FCFS SAVI devices. 284 Should that occur, then it would mean that two hosts are allowed to 285 send packets with the same source address, which is what FCFS SAVI is 286 trying to prevent. In order to preserve the coherency of the FCFS 287 SAVI bindings distributed among the FCFS SAVI devices within a realm, 288 the Neighbour Discovery (ND) protocol [RFC4861] is used, in 289 particular the Neighbour Solicitation (NS) and Neighbour 290 Advertisement (NA) messages. As a simplified example of how this 291 might work: before creating a FCFS SAVI binding in the local FCFS 292 SAVI database, the FCFS SAVI device will send a NS message querying 293 for the address involved. Should any host reply to that message with 294 a NA message, the FCFS SAVI device that sent the NS will infer that a 295 binding for that address exists in another FCFS SAVI device and will 296 not create a local binding for it. If no NA message is received as a 297 reply to the NS, then the local FCFS SAVI device will infer that no 298 binding for that address exists in other FCFS SAVI device and will 299 create the local FCFS SAVI binding for that address. 301 So, summarizing, the proposed FCFS SAVI approach relies on the 302 following design choices: 303 o FCFS SAVI provides perimetrical security, so some interfaces of a 304 FCFS SAVI device will connect to the internal (trusted) part of 305 the topology and other interfaces will connect to the external 306 (untrusted) part of the topology. 307 o A FCFS SAVI device only verifies packets coming through an 308 interface connected to the untrusted part of the topology. 309 o A FCFS SAVI device only stores binding information for the source 310 addresses that are bound to binding anchors that correspond to 311 interfaces that connect to the untrusted part of the topology. 312 o FCFS SAVI uses the NS and NA messages to preserve the coherency of 313 the FCFS SAVI binding state distributed among the FCFS SAVI 314 devices within a realm. 316 So, in a link that is constituted of multiple L2 devices, some of 317 which are FCFS SAVI capable and some of which are not, the FCFS SAVI 318 capable devices MUST be deployed forming a connected perimeter (i.e. 319 that no data packet can get inside the perimeter without passing 320 through a FCFS SAVI device). Packets that cross the perimeter will 321 be validated while packets that do no cross the perimeter are not 322 validated (hence FCFS SAVI protection is not provided for these 323 packets). Consider the deployment of FCFS SAVI in the topology 324 depicted in the following picture: 326 +--------+ 327 +--+ +--+ +--+ | +--+ | 328 |H1| |H2| |H3| | |R1| | 329 +--+ +--+ +--+ | +--+ | 330 | | | | | | 331 +-------------SAVI-PROTECTION-PERIMETER------+ | | 332 | | | | | | 333 | +-1-----2-+ +-1-----2-+ | 334 | | SAVI1 | | SAVI2 | | 335 | +-3--4----+ +--3------+ | 336 | | | +--------------+ | | 337 | | +----------| |--------+ | 338 | | | SWITCH-A | | 339 | | +----------| |--------+ | 340 | | | +--------------+ | | 341 | +-1--2----+ +--1------+ | 342 | | SAVI3 | | SAVI4 | | 343 | +-3-----4-+ +----4----+ | 344 | | | | | 345 | +------SAVI-PROTECTION-PERIMETER---------------+ 346 | | | | | 347 | +--+| +--+ +---------+ 348 | |R2|| |H4| |SWICTH-B | 349 | +--+| +--+ +---------+ 350 +------+ | | 351 +--+ +--+ 352 |H5| |H6| 353 +--+ +--+ 355 In the figure above, the FCFS SAVI protection perimeter is provided 356 by 4 FCFS SAVI devices, namely SAVI1, SAVI2, SAVI3 and SAVI4. These 357 devices verify the source address and filter packets accordingly. 359 FCFS SAVI devices then have two types of ports: trusted ports and 360 validating ports. 361 o Validating ports (VPs) are those in which FCFS SAVI processing is 362 performed. When a packet is received through one of the 363 validating ports, the FCFS SAVI processing and filtering will be 364 executed. 365 o Trusted ports (TPs) are those in which FCFS SAVI processing is not 366 performed. So, packets received through trusted ports are not 367 validated and no FCFS SAVI processing is performed in them. 369 Trusted ports are used for connections with the trusted 370 infrastructure, including the communication between FCFS SAVI 371 devices, the communication with routers and the communication of 372 other switches that while they are not FCFS SAVI devices, they only 373 connect to trusted infrastructure (i.e. other FCFS SAVI devices, 374 routers or other trusted nodes). So, in the figure above, Port 3 of 375 SAVI1 and port 1 of SAVI3 are trusted because they connect two FCFS 376 SAVI devices. Port 4 of SAVI1, port 3 of SAVI2, port 2 of SAVI3 and 377 port 1 of SAVI4 are trusted because the connect to SWITCH-A to which 378 only trusted nodes are connected. In the figure above, port 2 of 379 SAVI2 and port 3 of SAVI3 are trusted ports because they connect to 380 routers. 382 Validating ports are used for connection with non-trusted 383 infrastructure. In particular, hosts are normally connected to 384 validating ports. Non-SAVI switches that are outside of the FCFS 385 SAVI protection perimeter also are connected through validating 386 ports. In particular, non-SAVI devices that connect directly to 387 hosts or that have no SAVI capable device between themselves and the 388 hosts are connected through a validating port. So, in the figure 389 above, ports 1 and 2 of SAVI1, port 1 of SAVI2, port 4 of SAVI 3 are 390 validating ports because they connect to hosts. Port 4 of SAVI4 is 391 also a validating port because it is connected to SWITCH-B which is a 392 non-SAVI capable switch which is connected to hosts H5 and H6. 394 2.6. Special cases 396 Multi-subnet links: In some cases, a given subnet may have several 397 prefixes. This is directly supported by SAVI as any port can support 398 multiple prefixes. Even the case where the forwarding of packets 399 between different prefixes involve a router is supported, as long as 400 the router is connected to a Trusted port, as recommended for all the 401 routers. 403 Multihomed hosts: A multihomed host is a host with multiple 404 interfaces. The interaction between SAVI and multihomed hosts is as 405 follows. If the different interfaces of the host are assigned 406 different IP addresses and packets sent from each interface always 407 carry the address assigned to that interface as source address, then, 408 from the SAVI device perspective this is equivalent to two hosts with 409 a single interface each with an IP address each. This is supported 410 by SAVI without need for additional considerations. If the different 411 interfaces share the same IP address or if the interfaces have 412 different addresses but the host sends packets using the address of 413 one of the interfaces through any of the interfaces, then SAVI does 414 not directly support it. It would require either connecting at least 415 one interface of the multihomed host to a Trusted port, or manually 416 configure the SAVI bindings to allow binding the address of the 417 multihomed host to multiple anchors simultaneously. 419 Untrusted routers: One can envision scenarios where routers are 420 dynamically attached to a FCFS SAVI network. A typical example would 421 be a mobile phone connecting to a FCFS SAVI switch where the mobile 422 phone is acting as a router for other personal devices that are 423 accessing the network through it. In this case, the router does not 424 seem to directly fall in the category of Trusted infrastructure (as 425 if this was the case, it is likely that all devices would be 426 trusted), hence it cannot be connected to a trusted port and if it is 427 connected to a Validating port, the FCFS SAVI switch would discard 428 all the packets containing an off link source address coming from 429 that device. As a result, the default recommendation specified in 430 this specification does not support such scenario. 432 3. FCFS SAVI specification 434 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 435 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 436 document are to be interpreted as described in RFC 2119 [RFC2119]. 438 3.1. FCFS SAVI Data structures 440 FCFS SAVI function relies on state information binding the source 441 address used in data packets to the binding anchor that contained the 442 first packet that used that source IP address. Such information is 443 stored in FCFS SAVI Data Base (DB). The FCFS SAVI DB will contain a 444 set of entries about the currently used IP source addresses. So each 445 entry will contain the following information: 446 o IP source address 447 o Binding anchor: port through which the packet was received 448 o Lifetime 449 o Status: either TENTATIVE, VALID, TESTING_VP or TESTING_TP-LT 450 o Creation time: the value of the local clock when the entry was 451 firstly created 453 In addition to this, FCFS SAVI needs to know what are the prefixes 454 that are directly connected, so it maintains a data structure called 455 the FCFS SAVI prefix list, which contains: 456 o Prefix 457 o Interface where prefix is directly connected 459 3.2. FCFS SAVI algorithm 461 3.2.1. Discovering on-link prefixes 463 In order to distinguish local traffic from transit traffic, the FCFS 464 SAVI device relies on the FCFS SAVI Prefix list, which contains the 465 set of on-link IPv6 prefixes. A FCFS SAVI device MUST support the 466 following two methods for populating the Prefix List: Manual 467 configuration and Router Advertisement, as detailed next. 469 Manual configuration: A FCFS SAVI device MUST support manual 470 configuration of the on-link prefixes included in the Prefix List. 471 For example, this can be used when there are no prefixes being 472 advertised on the link. 474 Router Advertisement: A FCFS SAVI device MUST support discovery of 475 on-link prefixes through Router Advertisement messages in Trusted 476 Ports. For the Trusted Ports, the FCFS SAVI device will learn the 477 on-link prefixes following the procedure defined for a host to 478 process the Prefix Information options described in section 6.3.4 of 479 [RFC4861] with the difference that the prefixes will be configured in 480 the FCFS SAVI Prefix List rather than in the ND Prefix List. In 481 addition, when the FCFS SAVI device boots, it MUST send a Router 482 Solicitation message as described in section 6.3.7 of [RFC4861], 483 using the unspecified source address. 485 3.2.2. Processing of transit traffic 487 The FCFS SAVI function is located in a forwarding device, such as a 488 router or a layer-2 switch. The following processing is performed 489 depending on the type of port the packet has been received through: 490 o If the data packet is received through a Trusted port, the data 491 packet is forwarded and no SAVI processing performed to the 492 packet. 493 o If the data packet is received through a Validating port, then the 494 FCFS SAVI function checks whether the received data packet is 495 local traffic or transit traffic. It does so by verifying if the 496 source address of the packet belongs to one of the directly 497 connected prefixes available in the receiving interface. It does 498 so by searching the FCFS SAVI Prefix List. 499 * If the IP source address does not belong to one of the on-link 500 prefixes of the receiving interface, the data packet is transit 501 traffic and the packet SHOULD be discarded. (If for some 502 reason, discarding the packets is not acceptable, logging or 503 triggering of alarms MAY be used). The FCFS SAVI function MAY 504 send an ICMP Destination Unreachable Error back to the source 505 address of the data packet and ICMPv6, code 5 (Source address 506 failed ingress/egress policy), should be used. 507 * If the source address of the packet does belong to one of the 508 prefixes available in the receiving port, then the FCFS SAVI 509 local traffic validation process is executed as described 510 below. 511 * If the source address of the packet is the unspecified address, 512 the packet is forwarded and no SAVI processing is performed 513 except for the case of the Neighbor Solicitation messages 514 involved in the Duplicate Address Detection which are treated 515 as described in Section 3.2.3. 517 3.2.3. Processing of local traffic. 519 We describe next how the local traffic, including both control and 520 data packets are processed by the FCFS SAVI device using a state 521 machine approach. 523 The state machine described is for the binding of a given source IP 524 address (called IPAddr) in a given FCFS SAVI device. So this means 525 that all the packets described as inputs in the state machine above 526 refer to that given IP address. In the case of data packets, the 527 source address of the packet is IPAddr. In the case of the DAD_NS 528 packets, the Target address is IPAddr. The key attribute is the IP 529 address. The full state information is: 530 o IP ADDRESS: IPAddr 531 o BINDING ANCHOR: P 532 o LIFETIME: LT 534 The possible states are: 535 o NO_BIND 536 o TENTATIVE 537 o VALID 538 o TESTING_TP-LT 539 o TESTING_VP 541 We will use VP for Validating Port and TP for Trusted Port. 543 After bootstrapping (when no binding exists), the state for all 544 source IP address is NO-BIND i.e. there is no binding for the IP 545 address to any binding anchor. 547 NO_BIND: The binding for a source IP address entry is in this state 548 when it does not have any binding to an anchor. All addresses are in 549 this state by default after bootstrapping, unless bindings were 550 created for it. 552 TENTATIVE: The binding for a source address for which a data packet 553 or a NS generated by the Duplicate Address Detection (DAD) procedure 554 has been received is in this state during the waiting period during 555 which the DAD procedure is being executed (either by the host itself 556 or the FCFS SAVI device on its behalf). 558 VALID: The binding for the source address is in this state after it 559 has been verified. It means that it is valid and usable for 560 filtering traffic. 562 TESTING_TP-LT: A binding for a source address enters in this state 563 due to one of two reasons: 565 When a Duplicate Address Detection Neighbour Solicitation has been 566 received through a Trusted port. This implies that a host is 567 performing the DAD procedure for that source address in another 568 switch. This may be due to an attack or to the fact that the host 569 may have moved. The binding in this state is then being tested to 570 determine which is the situation. 571 The lifetime of the binding entry is about to expire. This is due 572 to the fact that no packets have been seen by the FCFS SAVI device 573 for the LIFETIME period. This may be due to the host simply being 574 silent or because the host has left the location. In order to 575 determine which is the case, a test is performed, in order to 576 determine if the binding information should be discarded. 578 TESTING_VP: A binding for a source address enters in this state when 579 a Duplicate Address Detection Neighbour Solicitation or a data packet 580 has been received through a Validating port other than the one 581 address is currently bound to. This implies that a host is 582 performing the DAD procedure for that source address through a 583 different port. This may due to an attack or to the fact that the 584 host may have moved or just because another host tries to configure 585 an address already used. The binding in this state is then being 586 tested to determine which is the situation. 588 We describe next how the different inputs are processed depending on 589 the state of the binding of the IP address (IPAddr). 591 A simplified figure of the state machine is included below. 593 NO_BIND 595 o Upon the reception through a Validating Port (VP) of a Neighbour 596 Solicitation (NS) generated by the Duplicate Address Detection 597 (DAD) procedure (hereafter named DAD_NS) containing Target Address 598 IPAddr, the FCFS SAVI device MUST forward the NS and T_WAIT 599 millisconds later it MUST send a copy of the same message. These 600 DAD_NS messages are not sent through any of the ports configured 601 as Validating Ports. The DAD_NS messages are sent through the 602 Trusted Ports (but of course subject to usual switch behavior and 603 possible Multicast Listener Discovery (MLD) snooping 604 optimizations). The state is moved to TENTATIVE. The LIFETIME is 605 set to TENT_LT (i.e. LT:=TENT_LT), the BINDING ANCHOR is set to 606 VP (i.e. P:=VP) and the Creation time is set to the current value 607 of the local clock. 608 o Upon the reception through a Validating Port (VP) of a DATA packet 609 containing IPAddr as the source address, the SAVI device SHOULD 610 execute the process of sending Neighbour Solicitation messages of 611 the Duplicate Address Detection process as described in section 612 5.4.2 of [RFC4862] for the IPAddr using the following default 613 parameters: DupAddrDetectTransmits set to 2 (i.e. 2 Neighbour 614 Solicitation messages for that address will be sent by the SAVI 615 device) and RetransTimer set to T_WAIT Milliseconds (i.e. the time 616 between two Neighbour Solicitation messages is T_WAIT 617 Milliseconds). The implications of not following the recommended 618 behaviour are described in Appendix A. The DAD_NS messages are 619 not sent through any of the ports configured as Validating Ports. 620 The DAD_NSOL messages are sent through Trusted Ports (but of 621 course subject to usual switch behavior and possible MLD snooping 622 optimizations). The SAVI device MAY discard the data packet while 623 the DAD procedure is being executed or it MAY store them until the 624 binding is created. In any case, it MUST NOT forward the data 625 packets until the binding has been verified. The state is moved 626 to TENTATIVE. The LIFETIME is set to TENT_LT (i.e. LT:=TENT_LT), 627 the BINDING ANCHOR is set to VP (i.e. P:=VP) and the Creation 628 time is set to the current value of the local clock. 629 o Data packets containing IPAddr as the source address received 630 through Trusted ports are processed and forwarded as usual (i.e. 631 no special SAVI processing) 632 o DAD_NS packets containing IPAddr as the target address received 633 through a Trusted port MUST NOT forwarded through any of the 634 Validating ports but they are sent through the Trusted Ports (but 635 of course subject to usual switch behavior and possible MLD 636 snooping optimizations). 637 o Neighbor Advertisement packets sent to all nodes as a reply to the 638 DAD_NS (hereafter called DAD_NA) containing IPAddr as the target 639 address coming through a Validating port are discarded. 640 o Other signaling packets are processed and forwarded as usual (i.e. 641 no SAVI processing) 643 TENTATIVE 645 o If the LIFETIME times out, the state is moved to VALID. The 646 LIFETIME is set to DEFAULT_LT (i.e. LT:= DEFAULT_LT). Stored 647 data packets are forwarded (if any). 648 o If a Neighbour Advertisement (NA) is received through a Trusted 649 Port with Target Address set to IPAddr, then message is forwarded 650 through port P, the state is set to NO_BIND and the BINDING ANCHOR 651 and the LIFETIME are cleared. Data packets stored corresponding 652 to this binding are discarded. 653 o If a NA is received through a Validating Port with Target Address 654 set to IPAddr, the NA packet is discarded 655 o If a data packet with source address IPAddr is received with 656 binding anchor equal to P, then the packet is either stored or 657 discarded. 658 o If a data packet with source address IPAddr is received through a 659 Trusted port, the data packet is forwarded. The state is 660 unchanged . 662 o If a data packet with source address IPAddr is received through a 663 Validating port other than P, the data packet is discarded. 664 o If a DAD_NS is received from a Trusted port, with target address 665 set to IPAddr, then the message is forwarded to the Validating 666 port P, the state is set to NO_BIND and the BINDING ANCHOR and 667 LIFETIME are cleared. Data packets stored corresponding to this 668 binding are discarded. 669 o If a DAD_NS with target address set to IPAddr is received from a 670 validating port P' other than P, the message is forwarded to the 671 Validating port P and to the Trusted ports, the state remains in 672 TENTATIVE, but the BINDING ANCHOR is changed from P to P' and 673 LIFETIME is set to TENT_LT. Data packets stored corresponding to 674 the binding with P are discarded. 675 o Other signaling packets are processed and forwarded as usual (i.e. 676 no SAVI processing) 678 VALID 680 o If a data packet containing IPAddr as a source address arrives 681 from Validating port P, then the LIFETIME is set to DEFAULT_LT and 682 the packet is forwarded as usual. 683 o If a DAD_NS is received from a Trusted port, then the DAD_NS 684 message is forwarded to port P and it is also forwarded to the 685 Trusted Ports (but of course subject to usual switch behavior and 686 possible MLD snooping optimizations). The state is changed to 687 TESTING_TP-LT. The LIFETIME is set to TENT_LT. 688 o If a data packet containing source address IPAddr or a DAD_NA 689 packet with target address set to IPAddr is received through a 690 Validating port P' other than P, then the SAVI device will execute 691 the process of sending DAD_NS messages as described in section 692 5.4.2 of [RFC4862] for the IPAddr using the following default 693 parameters: DupAddrDetectTransmits set to 2 (i.e. 2 NS messages 694 for that address will be sent by the SAVI device) and RetransTimer 695 set to T_WAIT Milliseconds (i.e. the time between two NS messages 696 is T_WAIT Milliseconds). The DAD_NS message will be forwarded to 697 the port P. The state is moved to TESTING_VP. The LIFETIME is set 698 to TENT_LT. The SAVI device MAY discard the data packet while the 699 DAD procedure is being executed or it MAY store them until the 700 binding is created. In any case, it MUST NOT forward the data 701 packets until the binding has been verified. 702 o If a DAD_NS packet with target address set to IPAddr is received 703 through a Validating port P' other than P, then the SAVI device 704 will forward the DAD_NS packet and T_WAIT Milliseconds later it 705 will execute the process of sending DAD_NS messages as described 706 in section 5.4.2 of [RFC4862] for the IPAddr using the following 707 default parameters: DupAddrDetectTransmits set to 1 and 708 RetransTimer set to T_WAIT Milliseconds. The DAD_NS messages will 709 be forwarded to the port P. The state is moved to TESTING_VP. The 710 LIFETIME is set to TENT_LT. The SAVI device MAY discard the data 711 packet while the DAD procedure is being executed or it MAY store 712 them until the binding is created. In any case, it MUST NOT 713 forward the data packets until the binding has been verified. 714 o If the LIFETIME expires, then the SAVI device will execute the 715 process of sending DAD_NS messages as described in section 5.4.2 716 of [RFC4862] for the IPAddr using the following default 717 parameters: DupAddrDetectTransmits set to 2 (i.e. 2 NS messages 718 for that address will be sent by the SAVI device) and RetransTimer 719 set to T_WAIT Milliseconds (i.e. the time between two NS messages 720 is T_WAIT Milliseconds). The DAD_NS messages will be forwarded to 721 the port P. The state is changed to TESTING_TP-LT and the LIFETIME 722 is set to TENT_LT. 723 o If a data packet containing IPAddr as a source address arrives 724 from Trusted port, the packet MAY be discarded. The event MAY be 725 logged. 726 o Other signaling packets are processed and forwarded as usual (i.e. 727 no SAVI processing). In particular DAD_NA coming from port P and 728 containing IPAddr as the target address are forwarded as usual. 730 TESTING_TP-LT 732 o If the LIFETIME expires, the BINDING ANCHOR is cleared and the 733 state is changed to NO_BIND 734 o If a NA message containing the IPAddr as target address is 735 received through the Validating port P as a reply to the DAD_NS 736 message, then the NA is forwarded as usual and the state is 737 changed to VALID. The LIFETIME is set to DEFAULT_LT 738 o If a data packet containing IPAddr as the source address is 739 received through port P, then the packet is forwarded and the 740 state is changed to VALID. The LIFETIME is set to DEFAULT_LT. 741 o If a DAD_NS is received from a Trusted port, the DAD_NS is 742 forwarded as usual. 743 o If a DAD_NS is received from a Validating Port P' other than P, 744 the DAD_NS is forwarded as usual, the state is moved to 745 TESTING_VP. 746 o If a data packet is received through a Validating Port port P' 747 that is other than port P, then the packet is discarded. 748 o If a data packet is received through a Trusted Port port, then the 749 packet MAY be discarded. The event MAY be logged. 751 TESTING_VP 753 o If the LIFETIME expires, the BINDING ANCHOR is modified from P to 754 P', the LIFETIME is set to DEFAULT_LT and the state is changed to 755 VALID. Data packet stored coming from P' are forwarded. 757 o If a NA message containing the IPAddr as target address is 758 received through the Validating port P as a reply to the DAD_NS 759 message, then the NA is forwarded as usual and the state is 760 changed to VALID. The LIFETIME is set to DEFAULT_LT 761 o If a data packet containing IPAddr as the source address is 762 received through port P, then the packet is forwarded. 763 o If a data packet containing IPAddr as the source address is 764 received through a Validating Port P'' that is other than port P 765 or P', then the packet is discarded. 766 o If a data packet containing IPAddr as the source address is 767 received through a Trusted Port port (i.e. other than port P), the 768 state is moved to TESTING_TP-LT, and the packet MAY is discarded. 769 o If a DAD_NS is received through Trusted Port, the packet is 770 forwarded as usual and the state is moved to TESTING_TP-LT. 771 o If a DAD_NS is received through Validating Port P'' other than P 772 or P', the packet is forwarded as usual and P'' is stored as the 773 tentative port i.e. P':=P''. The state remains the same. 775 Simplified state machine figure 777 +---------+ VP_NS, VP_DATA/2xNS +-----------+ 778 | |---------------------------------------->| | 779 | NO_BIND | | TENTATIVE | 780 | |<----------------------------------------| | 781 +---------+ TP_NA, TP_NS/- +-----------+ 782 ^ | 783 | | TimeOut 784 Timeout| | 785 | v 786 +---------+ VP_NA/- +-----------+ 787 | |---------------------------------------->| | 788 | TESTING | TP_NS/- | | 789 | TP-LT |<----------------------------------------| VALID | 790 | | TimeOut/2xNS | | 791 | |<----------------------------------------| | 792 +---------+ +-----------+ 793 ^ | ^ | 794 | | | | 795 | +--------------------- ---------------------+ | 796 | VP_NS/- | | NP_NA, TimeOut/- | 797 | v | | 798 | +-----------+ | 799 | | | | 800 +---------------------| TESTING |<----------------------+ 801 VP_NS, VP_DATA/- | VP | VP_DATA, VP_NS, 802 +-----------+ VP_NA/2xNS 804 MLD considerations 805 The FCFS SAVI device MUST join the Solicited Node Multicast group for 806 all the addresses which state is other than NO_BIND. This is needed 807 to make sure that the FCFS SAVI device will receive the DAD_NS for 808 those addresses. Please note that it may not be enough to rely on 809 the host behind the Validating port doing so, since the node may move 810 and after a while, the packets for that particular solicited node 811 multicast group will no longer be forwarded to the FCFS SAVI device. 812 So, the FCFS SAVI device MUST join the solicited node multicast 813 groups for all the addresses that are in a state other than NO_BIND 815 3.2.4. FCFS SAVI port configuration guidelines 817 The guidelines for port configuration in FCFS SAVI devices are: 818 o The FCFS SAVI realm (i.e. the realm that is inside the FCFS SAVI 819 protection perimeter) MUST be connected. If this is not the case, 820 legitimate transit traffic may be dropped. 821 o Ports that are connected to another FCFS SAVI device MUST be 822 configured as Trusted ports. Not doing so will significantly 823 increase the memory consumption in the FCFS SAVI devices and may 824 result in legitimate transit traffic being dropped. 825 o Ports connected to hosts SHOULD be configured as Validating ports. 826 Not doing so will allow the host connected to that port to send 827 packets with spoofed source address. A valid exception is the 828 case of a trusted host (e.g. a server) which could be connected to 829 a Trusted port, but untrusted hosts MUST be connected to 830 Validating ports. 831 o Ports connected to routers MUST be configured as Trusted ports. 832 Configuring them as Validating ports should result in transit 833 traffic being dropped. 834 o Ports connected to a chain of one or more legacy switches that 835 have hosts connected SHOULD be configured as Validating ports. 836 Not doing so will allow the host connected to any of these 837 switches to send packets with spoofed source address. A valid 838 exception is the case where the legacy switch only has trusted 839 hosts attached, in which case it could be connected to a Trusted 840 port, but if there is at least one untrusted hosts connected to 841 the legacy switch, then it MUST be connected to Validating ports. 842 o Ports connected to a chain of one or more legacy switches that 843 have other FCFS SAVI devices and/or routers connected but had no 844 hosts attached to them MUST be configured as Trusted ports. Not 845 doing so will at least significantly increase the memory 846 consumption in the FCFS SAVI devices and increase the signaling 847 traffic due to FCFS SAVI validation and may results in legitimate 848 transit traffic being dropped. 850 3.2.5. VLAN support 852 In the case the FCFS SAVI device is a switch that supports customer 853 VLANs [IEEE.802-1Q.2005], the FCFS SAVI implementation MUST behave as 854 if there was one FCFS SAVI process per customer VLAN. The FCFS SAVI 855 process of each customer VLAN will store the binding information 856 corresponding the nodes attached to that particular customer VLAN. 858 3.3. Default Protocol Values 860 The following are the default values used in the FCFS SAVI 861 specification. 863 TENT_LT is 500 Milliseconds 865 DEFAULT_LT is 5 minutes 867 T_WAIT is 250 Milliseconds 869 An implementation MAY allow these values to be modified, but that 870 tuning them precisely is considered out of scope of this document. 872 4. Security Considerations 874 Denial of service attacks 876 There are two types of Denial of Service (DoS) attacks [RFC4732] that 877 can be envisaged in a FCFS SAVI environment. On one hand, we can 878 envision attacks against the FCFS SAVI device resources. On the 879 other hand, we can envision DoS attacks against the hosts connected 880 to the network where FCFS SAVI is running. 882 The attacks against the FCFS SAVI device basically consist on making 883 the FCFS SAVI device to consume its resources until it runs out of 884 them. For instance, a possible attack would be to send packets with 885 different source addresses, making the FCFS SAVI device to create 886 state for each of the addresses and waste memory. At some point the 887 FCFS SAVI device runs out of memory and it needs to decide how to 888 react in this situation. The result is that some form of garbage 889 collection is needed to prune the entries. It is RECOMMENDED that 890 when the FCFS SAVI device runs out of the memory allocated for the 891 FCFS SAVI DB, it creates new entries by deleting the entries which 892 Creation Time is higher. This implies that older entries are 893 preserved and newer entries overwrite each other. In an attack 894 scenario where the attacker sends a batch of data packets with 895 different source address, each new source address is likely to 896 rewrite another source address created by the attack itself. It 897 should be noted that entries are also garbage collected using the 898 LIFETIME, which is updated using data packets. The result is that in 899 order for an attacker to actually fill the FCFS SAVI DB with false 900 source addresses, it needs to continuously send data packets for all 901 the different source addresses, in order for the entries to grow old 902 and compete with the legitimate entries. The result is that the cost 903 of the attack for the attacker is highly increased. 905 In addition, it is also RECOMMENDED that a FCFS SAVI device reserves 906 a minimum amount of memory for each available port (in the case where 907 the port is used as part of the L2 anchor). The recommended minimum 908 is the memory needed to store 4 bindings associated to the port. The 909 motivation for this recommendation is as follows: an attacker 910 attached to a given port of a FCFS SAVI device may attempt to launch 911 a DoS attack towards the FCFS SAVI device by creating many bindings 912 for different addresses. It can do so, by sending DAD_NS for 913 different addresses. The result is that the attack will consume all 914 the memory available in the FCFS SAVI device. The above 915 recommendation aims to reserve a minimum amount of memory per port, 916 so that hosts located in different ports can make use of the reserved 917 memory for their port even if a DoS attack is occurring in a 918 different port. 920 As the FCFS SAVI device may store data packets while the address is 921 being verified, the memory for data packet storage may also be a 922 target of DoS attacks. The effects of such attacks may be limited to 923 the lack of capacity to store new data packets. The effect of such 924 attack will be then that data packets will be dropped during the 925 verification period. A FCFS SAVI device MUST limit the amount of 926 memory used to store data packets, allowing the other functions to 927 have available memory even in the case of attacks as the above 928 described. 930 The FCFS SAVI device generates 2 DAD_NS packets upon the reception of 931 a DAD_NS or a data packet. As such, the FCFS SAVI device can be used 932 as an amplifier by attackers. In order to limit this type of attack, 933 the FCFS SAVI device MUST performs rate limiting of the messages it 934 generates. The rate limiting is performed on a per port basis, since 935 having an attack on a given port should not prevent the FCFS SAVI 936 device to function normally in the rest of the ports. 938 Residual threats. 940 FCFS SAVI perform its function by binding an IP source address to a 941 binding anchor. If the attacker manages to send packets using the 942 binding anchor associated to a given IP address, FCFS SAVI validation 943 will be successful and the FCFS SAVI device will allow the packet 944 through. This can be achieved by spoofing the binding anchor or 945 because the binding anchor is shared among the legitimate owner of 946 the address and the attacker. An example of the latter is the case 947 where the binding anchor is a port of a switched network and a legacy 948 switch (i.e. no SAVI capable switch) is connected to that port. All 949 the source addresses of the hosts connected to the legacy switch will 950 share the same binding anchor (i.e. the switch port). This means 951 that hosts connected to the legacy switch can spoof each other's IP 952 address and this will not be detected by the FCFS SAVI device. This 953 can be prevented by not sharing binding anchors among hosts. 955 FCFS SAVI assumes that a host will be able to defend its address when 956 the DAD procedure is executed for its addresses. This is needed, 957 among other things, to support mobility within a link (i.e. to allow 958 a host to detach and reconnect to a different Layer_2 anchor of the 959 same IP subnetwork, without changing its IP address). So, when a 960 DAD_NS is issued for a given IP address for which a binding exists in 961 a FCFS SAVI device, the FCFS SAVI device expects to see a DAD_NA 962 coming from the binding anchor associated to that IP address in order 963 to preserve the binding. If the FCFS SAVI device does not see the 964 DAD_NA, it may grant the binding to a different binding anchor. This 965 means that if an attacker manages to prevent a host from defending 966 its source address, it will be able to destroy the existing binding 967 and create a new one, with a different binding anchor. An attacker 968 may do so for example by intercepting the DAD_NA or launching a DoS 969 attack to the host that will prevent it to issue proper DAD replies. 971 Even if routers are considered as trusted, nothing can prevent that a 972 router could be compromised and send traffic with spoofed IP source 973 addresses. Such a traffic would be allowed with the present FCFS 974 SAVI specification. A way to mitigate this issue could be to specify 975 a new port type (e.g. Router Port, RP) that would act as Trusted 976 Port for the transit traffic and as Validating Port for the local 977 traffic. A detailed solution about this issue is outside the scope 978 of this document. 980 Privacy considerations 982 Personally identifying information MUST NOT be included in the FCFS 983 SAVI DB with the MAC address as the canonical example, except when 984 there is an attempt of attack involved. Moreover, compliant 985 implementation MUST NOT log binding anchor information except where 986 there is an identified reason why that information is likely to be 987 involved in detection, prevention or tracing of actual source address 988 spoofing. Information that is not logged MUST be deleted as soon as 989 possible (i.e. as soon as the the state for a given address is back 990 to NO_BIND). Information about the majority of hosts that never 991 spoof SHOULD NOT be logged. 993 Interaction with Secure Neighbour Discovery 995 Even if FCFS SAVI could get information from ND messages secured with 996 SEND [RFC3971], in some case, the FCFS SAVI device must spoof DAD_NS 997 messages but doesn't know the security credentials associated with 998 the IPAddr (i.e. the private key used to sign the DAD_NS messages). 999 So, when SEND is deployed, it is recommended to use SEND SAVI 1000 [I-D.ietf-savi-send] rather than FCFS SAVI." 1002 5. IANA Considerations 1004 This document has no actions for IANA. 1006 6. Contributors 1008 Jun Bi 1009 CERNET 1010 Network Research Center, Tsinghua University 1011 Beijing 100084 1012 China 1013 Email: junbi@cernet.edu.cn 1015 Guang Yao 1016 CERNET 1017 Network Research Center, Tsinghua University 1018 Beijing 100084 1019 China 1020 Email: yaog@netarchlab.tsinghua.edu.cn 1022 Fred Baker 1023 Cisco Systems 1024 Email: fred@cisco.com 1026 Alberto Garcia Martinez 1027 University Carlos III of Madrid 1028 Email: alberto@it.uc3m.es 1030 7. Acknowledgments 1032 This draft benefited from the input from: Joel Halpern, Christian 1033 Vogt, Dong Zhang, Frank Xia, Jean-Michel Combes, Jari Arkko, Stephen 1034 Farrel, Dan Romascanu, Russ Housley, Pete Resnick, Ralph Droms, 1035 Wesley Eddy, Dave Harrington and Lin Tao. 1037 Marcelo Bagnulo is partly funded by Trilogy, a research project 1038 supported by the European Commission under its Seventh Framework 1039 Program. 1041 8. References 1043 8.1. Normative References 1045 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1046 Requirement Levels", BCP 14, RFC 2119, March 1997. 1048 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1049 Defeating Denial of Service Attacks which employ IP Source 1050 Address Spoofing", BCP 38, RFC 2827, May 2000. 1052 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1053 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1054 September 2007. 1056 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1057 Address Autoconfiguration", RFC 4862, September 2007. 1059 8.2. Informative References 1061 [I-D.ietf-savi-framework] 1062 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 1063 "Source Address Validation Improvement Framework", 1064 draft-ietf-savi-framework-06 (work in progress), 1065 December 2011. 1067 [I-D.ietf-savi-dhcp] 1068 Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for 1069 DHCP", draft-ietf-savi-dhcp-12 (work in progress), 1070 February 2012. 1072 [I-D.ietf-savi-send] 1073 Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source- 1074 Address Validation Implementation", 1075 draft-ietf-savi-send-06 (work in progress), October 2011. 1077 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1078 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1080 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 1081 Service Considerations", RFC 4732, December 2006. 1083 [IEEE.802-1Q.2005] 1084 Institute of Electrical and Electronics Engineers, "IEEE 1085 Standard for Local and metropolitan area networks / 1086 Virtual Bridged Local Area Networks", IEEE Standard 1087 802.1Q, May 2005. 1089 Appendix A. Implications of not following the recommended behaviour 1091 This section qualifies some of the SHOULDs that are included in this 1092 specification, by explaining the implications of not following the 1093 recommended behaviour. We start by describing the implication of not 1094 following the recommendation of generating DAD-NS upon the reception 1095 of a data packet for which the there is no binding and then we 1096 describe the implications of not discarding the non compliant 1097 packets. 1099 A.1. Implications of not generating DAD-NS packets upon the reception 1100 of non compliant data packets 1102 This specification recommends SAVI implementations to generate a 1103 DAD_NS message upon the reception of a data packet for which they 1104 have no binding for. In this section we describe the implications of 1105 not doing so and simply discarding the data packet instead. 1107 The main argument against discarding the data packet is the overall 1108 robustness of the resulting network. The main concern that has been 1109 stated is that a network running SAVI that discard data packets in 1110 this case may end up disconnecting legitimate users from the network, 1111 by filtering packets coming from them. The net result would a 1112 degraded robustness of the network as a whole, since legitimate users 1113 would perceive this as a network failure. There are three different 1114 causes that resulted in the lack of state in the binding device for a 1115 legitimate address, namely, packet loss, state loss and topology 1116 change. We will next perform an analysis for each of them. 1118 A.1.1. Lack of binding state due to packet loss 1120 The DAD procedure is inherently unreliable. It consists on sending a 1121 NS packet and if no NA packet is received back, success is assumed 1122 and the host starts using the address. In general, the lack of 1123 response is because no other host has that particular address 1124 configured in their interface, but it may also be the case that the 1125 NS packet or the NA packet has been lost. From the sending host 1126 perspective there is no difference and the host assumes that it can 1127 use the address. In other words, the default action is to allow the 1128 host to obtain network connectivity. 1130 It should be noted that the loss of a DAD packet has little impact on 1131 the network performance, since address collision is very rare and the 1132 host assumes success in that case. By designing a SAVI solution that 1133 would discard packets for which there is no binding, we are 1134 diametrically changing the default behavior in this respect, since 1135 the default would be that if the DAD packets are lost, then the node 1136 is disconnected from the network (as its packets are filtered). What 1137 is worse, the node has little clue of what is going wrong, since it 1138 has successfully configured an address but it has no connectivity. 1139 The net result is that the overall reliability of the network has 1140 significantly decreased as the loss of a single packet would imply 1141 that a host is disconnected from the network. 1143 The only mechanism that the DAD has to improve its reliability is to 1144 send multiple NS. However, current RFC4862 defines a default value 1145 of 1 NS message for the DAD procedure, so requiring any higher value 1146 would imply manual configuration of all the hosts connected to the 1147 SAVI domain. 1149 A.1.1.1. Why initial packets may be (frequently) lost 1151 The case of LANs 1153 Devices connecting to a network may experience periods of packet loss 1154 after the link-layer becomes available for two reasons: Invalid 1155 Authentication state and incomplete topology assessment. In both 1156 cases, physical-layer connection occurs initially and presents a 1157 medium where packets are transmissible, but frame forwarding is not 1158 available across the LAN. 1160 For the authentication system, devices on a controlled port are 1161 forced to complete 802.1X authentication which may take multiple 1162 round trips and many Milliseconds to complete (see IEEE 802.1X-2004). 1163 In this time, initial DHCP, IPv6 Neighbour Discovery, Multicast 1164 Listener or Duplicate Address Detection messages may be transmitted. 1165 However, it has also been noted that some devices have the ability 1166 for the IP stack to not see the port as up until 802.1x has 1167 completed. Hence, that issue needs investigation to determine how 1168 common it is now. 1170 Additionally, any system which requires user input at this stage can 1171 extend the authentication time, and thus the outage. This is 1172 problematic where hosts relying upon DHCP for address configuration 1173 time out. 1175 Upon completion of authentication, it is feasible to signal upper 1176 layer protocols as to LAN forwarding availability. This is not 1177 typical today, so it is necessary to assume that protocols are not 1178 aware of the preceding loss period. 1180 For environments which do not require authentication, addition of a 1181 new link can cause loops where LAN frames are forwarded continually. 1182 In order to prevent loops, all LANs today run a spanning-tree 1183 protocol, which selectively disables redundant ports. Devices which 1184 perform spanning-tree calculations are either traditional Spanning- 1185 Tree Protocol (STP) (see IEEE802.1D-1998) or rapidly converging 1186 versions of the same (RSTP/MSTP) (see IEEE 802.1D-2004 and IEEE 1187 802.1Q-2005). 1189 Until a port is determined to be an edge port (RSTP/MSTP), the rapid 1190 protocol speaker has identified its position within the spanning-tree 1191 (RSTP/MSTP) or completed a Listening phase (STP), its packets are 1192 discarded. 1194 For ports which are not connected to rapid protocol switches, it 1195 takes a minimum three seconds to perform edge port determination (see 1196 IEEE 802.1D-2004). Alternatively completion of Listening phase takes 1197 15 seconds (see IEEE 802.1D-1998). During this period, the link- 1198 layer appears available, but initial packet transmissions into and 1199 out of this port will fail. 1201 It is possible to pre-assess ports as edge ports using manual 1202 configuration of all the involved devices and thus make them 1203 immediately transmissible. This is never default behaviour though. 1205 The case of fixed access networks 1207 In fixed access networks such as DSL and Cable the end hosts are 1208 usually connected to the access network through a residential gateway 1209 (RG). If the host interface is initialized prior to the residential 1210 gateway getting authenticated and connected to the access network, 1211 the access network is not aware of the DAD packets that the host sent 1212 out. As an example, in DSL networks the Access Node(DSLAM) that 1213 needs to create and maintain binding state will never see the DAD 1214 message that is required to create such state. 1216 A.1.1.1.1. Special sub-case:SAVI device rate-limiting packets 1218 A particular sub-case is the one where the SAVI device itself "drops" 1219 ND packets. In order to protect itself against DoS attacks and 1220 flash-crowds, the SAVI device will have to rate-limit the processing 1221 of packets triggering the state creation process (which require 1222 processing from the SAVI device). This implies that the SAVI device 1223 may not process all the ND packets in case it is under heavy 1224 conditions. The result is that the SAVI device will fail to create a 1225 binding for a given DAD_NS packet, which implies that the data 1226 packets coming from the host that sent the DAD_NS packet will be 1227 filtered if this approach is adopted. The problem is that the host 1228 will assume that the DAD procedure was successful and will not 1229 perform the DAD procedure again which in turn will imply that the 1230 host will be disconnected from the network. While it is true that 1231 the SAVI device will also have to rate limit the processing of the 1232 data packets, the host will keep on sending data packets, so it is 1233 possible to recover from the alternative approach where data packets 1234 trigger the binding creation procedure. 1236 A.1.2. Lack of binding state due to a change in the topology 1238 In the case SAVI is being deployed in a switched Ethernet network, 1239 topology changes may result in a SAVI device receiving packets from a 1240 legitimate user for which the SAVI device does not have a binding 1241 for. Consider the following example: 1243 +------+ +--------+ +---------------+ 1244 |SAVI I|-------------|SWITCH I|-------|rest of the net| 1245 +------+ +--------+ +---------------+ 1246 | | 1247 | +--------+ 1248 | | SAVI II| 1249 | +--------+ 1250 | +----------+ | 1251 +---|SWITCH II |-----+ 1252 +----------+ 1253 | 1254 +-----+ 1255 | Host| 1256 +-----+ 1258 Suppose that after bootstrapping all the elements are working 1259 properly and the spanning tree is rooted in the router and it 1260 includes one branch that goes SWITCH I-SAVI I- SWITCH II and another 1261 branch that goes SWITCH I-SAVI II. 1263 Suppose that the Host boots at this moment and sends the DAD_NS. The 1264 message is propagated through the spanning tree and it received by 1265 SAVI I but not by SAVI II. SAVI I creates the binding. 1267 Suppose that SAVI I fails and the spanning tree reconverges to SWITCH 1268 I- SAVI II- SWITCH II. Now data packets coming from the Host will be 1269 coursed through SAVI II which does not have binding state and will 1270 drop the packets. 1272 A.1.3. Lack of binding state due to state loss 1274 The other reason why a SAVI device may not have state for a 1275 legitimate address is simply because it lost it. State can be lost 1276 due to a reboot of the SAVI device or other reasons such as memory 1277 corruption. So, the situation would be as follows: the host performs 1278 the DAD procedure and the SAVI device creates a binding for the 1279 host's address. The host successfully communicate for a while. The 1280 SAVI device reboots and lost the binding state. The packets coming 1281 from the host are now discarded as there is no binding state for that 1282 address. It should be noted that in this case, the host has been 1283 able to use the address successfully for a certain period of time. 1285 Architecturally, the degradation of the network robustness in this 1286 case can be easily explained by observing that this approach to SAVI 1287 implementation breaks the fate-sharing principle. RFC 1958 reads: 1288 An end-to-end protocol design should not rely on the maintenance 1289 of state (i.e. information about the state of the end-to-end 1290 communication) inside the network. Such state should be 1291 maintained only in the endpoints, in such a way that the state can 1292 only be destroyed when the endpoint itself breaks (known as fate- 1293 sharing). 1294 By binding the fate of the host's connectivity to the state in the 1295 SAVI device, we are breaking this principle and the result is 1296 degraded network resilience. 1298 Moving on to more practical matters, we can dig deeper into the 1299 actual behaviour by considering two scenarios, namely, the case where 1300 the host is directly connected to the SAVI device and the case where 1301 there is an intermediate device between the two. 1303 A.1.3.1. The case of a host directly connected to the SAVI device 1305 The considered scenario is depicted in the following picture: 1307 +------+ +-----------+ +---------------+ 1308 | Host |-------------|SAVI device|-------|rest of the net| 1309 +------+ +-----------+ +---------------+ 1311 The key distinguishing element of this scenario is that the host is 1312 directly connected to the SAVI device. As a result, if the SAVI 1313 device reboots, the host will see the carrier disappear and appear 1314 again. 1316 RFC4862 requires that the DAD procedure is performed when the IP 1317 address is assigned to the interface, quoting RFC4862 section 5.4. 1318 Duplicate Address Detection: 1319 Duplicate Address Detection MUST be performed on all unicast 1320 addresses prior to assigning them to an interface, regardless of 1321 whether they are obtained through stateless autoconfiguration, 1322 DHCPv6, or manual configuration, with the following exceptions:... 1324 However, it has been stated that some of the widely used OSes 1325 actually do perform DAD each time the link is up, but further data 1326 would be required to take this for granted. Assuming that behaviour, 1327 that implies that if the lost of state in the SAVI device also 1328 results in the link to the host going down, then the host using the 1329 tested OSes would redo the DAD procedure allowing the recreation of 1330 the binding state in the SAVI device and preserving the connectivity 1331 of the host. This would be the case if the SAVI device reboots. It 1332 should be noted though, that it is also possible that the binding 1333 state is lost for whatever error in the SAVI process and that the 1334 SAVI link does not goes down. In this case, the host would not redo 1335 the DAD procedure. However, it has been pointed out that it would be 1336 possible to require the SAVI process to flap the links of the device 1337 it is running, in order to make sure that the links goes down each 1338 time the SAVI process restarts and improving the chances the host 1339 will redo the DAD procedure when the SAVI process is rebooted. 1341 A.1.3.2. The case of a host connected to the SAVI device through one or 1342 more legacy devices. 1344 The considered scenario is depicted in the following picture: 1346 +------+ +-------------+ +-----------+ +---------------+ 1347 | Host |----|Legacy device|-----|SAVI device|----|rest of the net| 1348 +------+ +-------------+ +-----------+ +---------------+ 1350 The key distinguishing element of this scenario is that the host is 1351 not directly connected to the SAVI device. As a result, if the SAVI 1352 device reboots, the host will not see any changes. 1354 In this case, the host would get get disconnected from the rest of 1355 the network since the SAVI device would filter all its packets once 1356 the state has gone. As the node will not perform the DAD procedure 1357 again, it will remain disconnected until it reboots. 1359 As a final comment, it should be noted that it may not be obvious to 1360 the network admin which scenario its network is running. Consider 1361 the case of a campus network where all the switches in the network 1362 are SAVI capable. A small hub connected in the office would turn 1363 this into the scenario where the host is not directly connected to 1364 the SAVI device. Moreover, consider the case of a host running 1365 multiple virtual machines connected through a virtual hub, depending 1366 on the implementation of such a virtual hub, may turn a directly 1367 connected host scenario to the scenario where the multiple (virtual) 1368 hosts are connected through a legacy (virtual) hub. 1370 A.1.3.2.1. Enforcing direct connectivity between the SAVI device and 1371 the host 1373 It has been argued that enforcing the direct connectivity between the 1374 SAVI device and the end host is actually a feature. There are 1375 several comments that can be made in this respect: 1376 First, it may well be the case in some scenarios this is 1377 desirable, but it is certainly not the case in most scenarios. 1378 Because of that, the issue of enforcing direct connectivity must 1379 be treated as orthogonal to how data packets for which there is no 1380 binding are treated, since a general solution must support 1381 directly connected nodes and nodes connected through legacy 1382 switches. 1383 Second, as a matter of fact, the resulting behaviour described 1384 above would not actually enforce direct connectivity between the 1385 end host and the SAVI device as it would work as long as the SAVI 1386 device would not reboot. So, the argument being made is that this 1387 approach is not good enough to provide a robust network service, 1388 but it is not bad enough to enforce the direct connectivity of 1389 host to the SAVI switch. 1390 Third, it should be noted that topology enforcement is not part of 1391 the SAVI problem space and that the SAVI problem by itself is hard 1392 enough to add additional requirements. 1394 A.2. Implications of not diacarding non compliant data packets 1396 The FCFS SAVI mechanism is composed of two main functions, namely, 1397 the mechanisms for tracking compliant and non compliant data packets 1398 and the actions to be performed upon the detection of a non compliant 1399 packet. Throughout this specification, we recommend to discard non 1400 compliant data packets. This is so because forwarding non compliant 1401 data packets is essentially allowing packets with spoofed source 1402 address to flow throughout the network. However, there are 1403 alternative actions that can be taken with respect to this packets. 1404 For instance, it would be possible to forward the packets and trigger 1405 an alarm to the network administrator to make him aware of the 1406 situation. Similarly, it would be possible to log these events and 1407 allow to track down the cases where the packets with spoofed 1408 addresses were used for malicious purposes. The reason why a site 1409 deploying SAVI may not want to take milder action like the ones 1410 mentioned above instead of discarding packets is because there may be 1411 cases where the non compliant packets may be legitimate packets (for 1412 example in the case that the SAVI device is malfunctioning and it has 1413 failed to create the appropriate bindings upon the reception of a DAD 1414 packets). 1416 Authors' Addresses 1418 Erik Nordmark 1419 Cisco 1420 510 McCarthy Blvd. 1421 Milpitas, California 95035 1422 UNITED STATES 1424 Email: nordmark@acm.org 1426 Marcelo Bagnulo 1427 Universidad Carlos III de Madrid 1428 Av. Universidad 30 1429 Leganes, Madrid 28911 1430 SPAIN 1432 Phone: 34 91 6248814 1433 Email: marcelo@it.uc3m.es 1434 URI: http://www.it.uc3m.es 1436 Eric Levy-Abegnoli 1437 Cisco Systems 1438 Village d'Entreprises Green Side - 400, Avenue Roumanille 1439 Biot-Sophia Antipolis - 06410 1440 France 1442 Email: elevyabe@cisco.com