idnits 2.17.1 draft-ietf-savi-fcfs-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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.) ** 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 198: '... the SAVI device MAY be configured to ...' RFC 2119 keyword, line 201: '...ses), logging is RECOMMENDED instead o...' RFC 2119 keyword, line 307: '... devices SHOULD be deployed forming ...' RFC 2119 keyword, line 384: '...ected to another SAVI device SHOULD be...' RFC 2119 keyword, line 387: '...nnected to hosts SHOULD be configured ...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2009) is 5295 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: 'RFC4861' is defined on line 810, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Nordmark 3 Internet-Draft Sun 4 Intended status: Standards Track M. Bagnulo 5 Expires: April 29, 2010 UC3M 6 E. Levy-Abegnoli 7 Cisco Systems 8 October 26, 2009 10 FCFS-SAVI: First-Come First-Serve Source-Address Validation for Locally 11 Assigned Addresses 12 draft-ietf-savi-fcfs-02 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 29, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 This memo describes FCFS SAVI a mechanism to provide source address 51 validation for IPv6 networks using the First-Come First-Serve 52 approach. The proposed mechanism is intended to complement ingress 53 filtering techniques to provide a higher granularity on the control 54 of the source addresses used. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Design considerations . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Scope of FCFS SAVI . . . . . . . . . . . . . . . . . . . . 3 61 2.2. Constraints for FCFS SAVI . . . . . . . . . . . . . . . . 4 62 2.3. Address ownership proof . . . . . . . . . . . . . . . . . 4 63 2.4. Layer-2 Anchor considerations . . . . . . . . . . . . . . 5 64 2.5. Special cases . . . . . . . . . . . . . . . . . . . . . . 5 65 3. SAVI topology and port configuration . . . . . . . . . . . . . 5 66 3.1. SAVI enforcement perimeter . . . . . . . . . . . . . . . . 6 67 3.2. SAVI port configuration guidelines . . . . . . . . . . . . 9 68 3.3. VLAN support . . . . . . . . . . . . . . . . . . . . . . . 10 69 4. FCFS SAVI specification . . . . . . . . . . . . . . . . . . . 10 70 4.1. FCFS SAVI Data structures . . . . . . . . . . . . . . . . 10 71 4.2. FCFS SAVI algorithm . . . . . . . . . . . . . . . . . . . 10 72 4.2.1. Processing of transit traffic . . . . . . . . . . . . 10 73 4.2.2. Processing of local traffic. . . . . . . . . . . . . . 11 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 77 8. Normative References . . . . . . . . . . . . . . . . . . . . . 18 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 80 1. Introduction 82 This memo describes FCFS SAVI, a mechanism to provide source address 83 validation for IPv6 networks using the First-Come First-Serve 84 approach. The proposed mechanism is intended to complement ingress 85 filtering techniques to provide a higher granularity on the control 86 of the source addresses used. 88 2. Design considerations 90 2.1. Scope of FCFS SAVI 92 The application scenario for FCFS SAVI is limited to the local-link. 93 This means that the goal of FCFS SAVI is verify that the source 94 address of the packets generated by the hosts attached to the local 95 link have not been spoofed. 97 In any link there usually are hosts and routers attached. Hosts 98 generate packets with their own address as the source address. This 99 is the so-called local traffic. while routers send packets containing 100 a source address other than their own, since they are forwarding 101 packets generated by other hosts (usually located in a different 102 link). This what the so-called transit traffic. 104 The applicability of FCFS SAVI is limited to the local traffic i.e. 105 to verify if the traffic generated by the hosts attached to the local 106 link contains a valid source address. The verification of the source 107 address of the transit traffic is out of the scope of FCFS SAVI. 108 Other techniques, like ingress filtering [RFC2827], are recommended 109 to validate transit traffic. In that sense, FCFS SAVI complements 110 ingress filtering, since it relies on ingress filtering to validate 111 transit traffic but is provides validation of local traffic, which is 112 not provided by ingress filtering. Hence, the security level is 113 increased by using these two techniques. 115 In addition, FCFS SAVI is designed to be used with locally assigned 116 addresses, in particular with address configured through stateless 117 address autoconfiguration [RFC4862]. Manually configured addresses 118 can be supported by FCFS SAVI, but manual configuration of the 119 binding on the SAVI device provides higher security and seems 120 compatible with manual address management. Additional considerations 121 about how to use FCFS SAVI depending on the type of address 122 management used and the nature of the addresses is discussed in the 123 framework document (add reference when available). 125 2.2. Constraints for FCFS SAVI 127 FCFS SAVI is designed to be deployed in existing networks requiring a 128 minimum set of changes. For that reason, FCFS SAVI does not require 129 any changes in the hosts which source address is to be verified. Any 130 verification must solely rely in the usage of already available 131 protocols. This means that FCFS SAVI cannot define a new protocol 132 nor define any new message on existing protocols nor require that a 133 host uses an existent protocol message in a different way. In other 134 words, the requirement is no host changes. 136 FCFS SAVI validation is performed by the FSFC SAVI function. Such 137 function can be placed in different type of devices, including a 138 router or a layer-2 bridge. The basic idea is that the FCFS SAVI 139 function is located in the points of the topology that can enforce 140 the correct usage of source address by dropping the non-compliant 141 packets. 143 2.3. Address ownership proof 145 The main function performed by FCFS SAVI is to verify that the source 146 address used in data packets actually belongs to the originator of 147 the packet. Since FCFS SAVI scope is limited to the local link, the 148 originator of the packet is attached to the local link. In order to 149 define any source address validation solution, we need to define some 150 address ownership proof concept i.e. what it means to be able to 151 proof that a given host owns a given address in the sense that the 152 host is entitled to send packet with that source address. 154 Since no host changes are acceptable, we need to find the means to 155 proof address ownership without requiring a new protocol. In FCFS 156 SAVI the address ownership proof is based in the First-Come first 157 Serve approach. This means that the first host that claims a given 158 source address is the owner of the address until further notice. 159 More precisely, whenever a source address is used for the first time, 160 a state is created in the device that is performing the FCFS SAVI 161 function binding the source address to the layer-2 information that 162 the FCFS SAVI box has available (e.g. the port in a switched LAN). 163 Following data packets containing that IP source address must use the 164 same layer-2 information in order to be compliant. 166 There are however additional considerations to be taken into account. 167 For instance, consider the case of a host that moves from one segment 168 of a LAN to another segment of the same subnetwork and it keeps the 169 same IP address. In this case, the host is still the owner of the IP 170 address, but the associated layer-2 information has changed. In 171 order to cope with this case, the defined FCFS SAVI behaviour implies 172 the verification whether the host is still reachable using the 173 previous layer-2 information. In order to do that FCFS SAVI uses ND 174 protocol. If the host is no longer reachable at the previously 175 recorded layer-2 information, FCFS SAVI assumes that the new location 176 is valid and creates a new binding using the new layer-2 information. 177 In case the host is still reachable using the previously recorded 178 information, the packets coming from the new layer-2 information are 179 dropped. 181 Note that this only applies to local traffic. Transit traffic 182 generated by a router would be verified using alternative techniques, 183 such as ingress filtering. SAVI checks would not be fulfilled by the 184 transit traffic, since the router is not the owner of the source 185 address contained in the packets. 187 2.4. Layer-2 Anchor considerations 189 Any SAVI solution is not stronger than the Layer-2 anchor it uses. 190 If the Layer-2 anchor is easily spoofable (e.g. a MAC address), then 191 the resulting solution will be weak. The treatment of non-compliant 192 packets needs to be tuned accordingly. In particular, if the Layer-2 193 anchor is easily spoofable and the SAVI device is configured to drop 194 no compliant packets, then the usage of SAVI may open a new vector of 195 Denial of Service attacks, based on spoofed Layer-2 anchors. For 196 that reason, in this document, we assume that the Layer-2 anchors 197 used by the SAVI solution are not easily spoofable (e.g. ports of a 198 switched network) and that the SAVI device MAY be configured to drop 199 non- compliant packets. If the SAVI solution proposed in this 200 document is to be used with weaker Layer-2 anchors (such as MAC 201 addresses), logging is RECOMMENDED instead of dropping non-compliant 202 packets. For the rest of the document, we will assume that the 203 Layer-2 anchors are ports of a switched network. 205 2.5. Special cases 207 The following special cases that need to be considered 208 o Hosts with multiple physical interfaces connected to the same 209 link. 210 o Anycast i.e. multiple hosts using the same source address to send 211 packets. 212 o Proxy ND i.e. host sending packets on behalf of other, in a 213 layer-3 transparent manner. 215 3. SAVI topology and port configuration 216 3.1. SAVI enforcement perimeter 218 SAVI provides perimetrical security. This means that the SAVI 219 devices form what can be called a SAVI enforcement perimeter and they 220 verify that any packet that crosses the perimeter is compliant (i.e. 221 the source address related information is validated). Once the 222 packet is inside the perimeter, no further validations are performed 223 to the packet. This model has implications both on how SAVI devices 224 are deployed in the topology and on the configuration of the SAVI 225 boxes. 227 The implication of this perimetrical security approach, is that there 228 is part of the topology that is inside the perimeter and part of the 229 topology that is outside the perimeter. This means that while 230 packets coming from interfaces connected to the external part of the 231 topology need to be validated by the SAVI device, packets coming from 232 interfaces connected to the the internal part of the topology do not 233 need to be validated. This significantly reduces the processing 234 requirements of the SAVI device. It also implies that each SAVI 235 device that is part of the perimeter, must be able to verify the 236 source addresses of the packets coming from the interfaces connected 237 to the external part of the perimeter. In order to do so, the SAVI 238 device binds the source address to a layer-2 anchor. 240 One possible approach would be for every SAVI device to store binding 241 information about every source addresses in the subnetwork This means 242 that every SAVI device would store binding for each source address to 243 the local layer-2 anchor through packets with that source address can 244 be received through. The problem with this approach is that it 245 imposes significant memory burden on the SAVI devices. In order to 246 reduce the memory requirements imposed to each device, the SAVI 247 solution described in this specification distributes the storage of 248 SAVI binding information among the multiple SAVI devices of a 249 subnetwork. The SAVI binding state is distributed across the SAVI 250 devices according to the following criteria: each SAVI device will 251 store binding information about the source addresses bound to layer-2 252 anchors corresponding to the interfaces that connect to the part of 253 the topology that is outside of the SAVI enforcement perimeter. 254 Since all the untrusted packet sources are by definition in the 255 external part of the perimeter, this means that the packets generated 256 by each of the untrusted sources will reach the perimeter through one 257 interface of a SAVI device. The binding information for that 258 particular source address will be stored in this first SAVI device 259 the packet reaches to. 261 This means the SAVI binding information will be distributed across 262 multiple devices. In order to provide proper source address 263 validation, it is critical that the information distributed among the 264 different SAVI devices is coherent. In particular, it is important 265 to avoid that the same source address is bound to different layer-2 266 anchors in different SAVI devices. Should that occur, then it would 267 mean that two hosts are allowed to send packets with the same source 268 address, which is what we are trying to prevent. In order to 269 preserve the coherency of the SAVI bindings distributed among the 270 SAVI devices within a realm, the Neighbour Discovery (ND) protocol is 271 used, in particular the Neighbour Solicitation (NSOL) and Neighbour 272 Advertisement (NADV) messages. Before creating a SAVI binding in the 273 local SAVI database, the SAVI device will send a NSOL message 274 querying for the address involved. Should any host reply to that 275 message with a NADV message, the SAVI device that sent the NADV will 276 infer that a binding for that address exists in another SAVI device 277 and will not create a local binding for it. If no NADV message is 278 received as a reply to the NSOL, then the local SAVI device will 279 infer that no binding for that address exists in other SAVI device 280 and will create the local SAVI binding for that address. (NOTE that 281 the description included here is overly simplified to illustrate the 282 mechanism used to preserve the coherency of the binding databases of 283 the different SAVI devices. The actual SAVI mechanism as described 284 below varies in the fact that in some cases it is the SAVI device 285 that generates the NSOL while in other cases it simply forwards the 286 NSOL generated by the end host, and that the SAVI device will send 287 multiple copies of the NSOL in order to improve the reliability of 288 the message exchange). 290 So, summarizing, the proposed SAVI approach relies on the following 291 design choices: 292 o SAVI provides perimetrical security, so some interfaces of a SAVI 293 device will connect to the internal (trusted) part of the topology 294 and other interfaces will connect to the external (untrusted) part 295 of the topology. 296 o A SAVI device only verifies packets coming though one interface 297 connected to the untrusted part of the topology. 298 o A SAVI device only stores binding information for the source 299 addresses that are bound to layer-2 anchors that correspond to 300 interfaces that connect to the untrusted part of the topology. 301 o SAVI uses the NSOL and NADV messages to preserve the coherency of 302 the SAVI binding state distributed among the SAVI devices within a 303 realm. 305 So, in a link that is constituted of multiple L2 devices, some of 306 which are SAVI capable and some of which are not, the SAVI capable 307 devices SHOULD be deployed forming a connected perimeter (i.e. that 308 no data packet can get inside the perimeter without passing through a 309 SAVI device). Packets that cross the perimeter will be validated 310 while packets that do no cross the perimeter are not validated (hence 311 SAVI protection is not provided for these packets). Consider the 312 deployment of SAVI in the topology depicted in the following picture: 314 +--+ +--+ +--+ +--+ 315 |H1| |H2| |H3| |R1| 316 +--+ +--+ +--+ +--+ 317 | | | | 318 +-------------SAVI-ENFORCEMENT-PERIMETER--------------+ 319 | | | | | | 320 | +-1-----2-+ +-1-----2-+ | 321 | | SAVI1 | | SAVI2 | | 322 | +-3--4----+ +--3------+ | 323 | | | +--------------+ | | 324 | | +----------| |--------+ | 325 | | | SWITCH-A | | 326 | | +----------| |--------+ | 327 | | | +--------------+ | | 328 | +-1--2----+ +--1------+ | 329 | | SAVI3 | | SAVI4 | | 330 | +-3---4---+ +----4----+ | 331 | | | | | 332 +-------------SAVI-ENFORCEMENT-PERIMETER--------------+ 333 | | | 334 +--+ +--+ +---------+ 335 |R2| |H4| |SWICTH-B | 336 +--+ +--+ +---------+ 337 | | 338 +--+ +--+ 339 |H5| |H6| 340 +--+ +--+ 342 In the figure above, the SAVI enforcement perimeter is provided by 4 343 SAVI devices, namely SAVI1, SAVI2, SAVI3 and SAVI4. These devices 344 verify information related to the source address both in data and in 345 ND packets and filter packets accordingly. 347 SAVI devices then have two types of ports: trusted ports and 348 validating ports. 349 o Validating ports (VPs) are those in which SAVI processing is 350 performed. This means that when a packet is received through one 351 of the validating ports, the SAVI processing and filtering will be 352 executed. 353 o Trusted ports (TPs) are those in which SAVI processing is not 354 performed. So, packets received through trusted ports are not 355 validated and no SAVI processing is performed in them. 357 Trusted ports are used for connections with trusted infrastructure, 358 including the communication between SAVI devices, the communication 359 with routers and the communication of other switches that while they 360 are not SAVI devices, they only connect to trusted infrastructure 361 (i.e. other SAVI devices, routers or other trusted nodes). So, in 362 the figure above, Port 3 of SAVI1 and port 1 of SAVI3 are trusted 363 because the connect two SAVI devices. Port 4 of SAVI1, port 3 of 364 SAVI2, port 2 of SAVI3 and port 1 of SAVI4 are trusted because the 365 connect to SWITCH-A to which only trusted nodes are connected. In 366 the figure above, port 2 of SAVI2 and port 3 of SAVI3 are trusted 367 ports because they connect to routers. 369 Validating ports are used for connection with non-trusted 370 infrastructure. In particular, hosts are normally connected to 371 validating ports. Non-SAVI switches that are outside of the SAVI 372 enforcement perimeter also are connected through validating port. In 373 particular, non-SAVI devices that connect directly to hosts or that 374 have no SAVI capable device between themselves and the hosts are 375 connected through a validating port. So, in the figure above, ports 376 1 and 2 of SAVI1, port 1 of SAVI2, port 4 of SAVI 3 are validating 377 ports because they connect to hosts. Port 4 of SAVI4 is also a 378 validating port because it is connected to SWITCH-B which is a non- 379 SAVI capable switch which is connected to hosts H5 and H6. 381 3.2. SAVI port configuration guidelines 383 The guidelines for port configuration in SAVI devices are: 384 o Ports that are connected to another SAVI device SHOULD be 385 configured as Trusted ports. Not doing so will at least 386 significantly increase the memory consumption in the SAVI devices. 387 o Ports connected to hosts SHOULD be configured as Validating ports. 388 Not doing so will allow the host connected to that port to send 389 packets with spoofed source address. 390 o Ports connected to routers SHOULD be configured as Trusted ports. 391 Configuring them as Validating ports would increase the signaling 392 due to SAVI. The implication is that a router can generate 393 traffic with any source address as they are assumed to be part of 394 the trusted infrastructure. 395 o Ports connected to a chain of one or more legacy switches that 396 have hosts connected SHOULD be configured as Validating ports. 397 Not doing so will allow the host connected to any of these 398 switches to send packets with spoofed source address. 399 o Ports connected to a chain of one or more legacy switches that 400 have other SAVI devices and/or routers connected but had no hosts 401 attached to them SHOULD be configured as Trusted ports. Not doing 402 so will at least significantly increase the memory consumption in 403 the SAVI devices and increase the signaling traffic due to SAVI 404 validation. 406 o Ports connected to a chain of one or more legacy switches that 407 have a mix of SAVI devices and/or routers with hosts, SHOULD be 408 configured as Validating ports. Not doing so will allow the host 409 connected to that port to send packets with spoofed source 410 address. Nevertheless, this topology will result in increased 411 SAVI signaling and memory consumption compared to a topology where 412 SAVI-hosts communications and inter SAVI communications are kept 413 through different legacy switches. 415 3.3. VLAN support 417 In the case the SAVI device is a switch that supports VLANs, the SAVI 418 implementation will behave as if there was one SAVI process per VLAN. 419 The SAVI process of each VLAN will store the binding information 420 corresponding the the nodes attached to that particular VLAN. 422 4. FCFS SAVI specification 424 4.1. FCFS SAVI Data structures 426 FCFS SAVI function relies on state information binding the source 427 address used in data packets to the layer-2 information that 428 contained the first packet that used that source IP address. Such 429 information is stored in FCFS SAVI Data Base (DB). The FCFS SAVI DB 430 will contain a set of entries about the currently used IP source 431 addresses. So each entry will contain the following information: 432 o IP source address 433 o Layer-2 information, such as Layer-2 address, port through which 434 the packet was received, etc 435 o Lifetime 436 o Status:either tentative or valid 437 o Creation time: the value of the local clock when the entry was 438 firstly created 440 In addition to this, FCFS SAVI need to know what are the prefixes 441 that are directly connected, so it maintains a data structure called 442 the the FCFS SAVI prefix list, which contains: 443 o Prefix 444 o Interface where prefix is directly connected 446 4.2. FCFS SAVI algorithm 448 4.2.1. Processing of transit traffic 450 The FCFS SAVI function is located in a forwarding device, such as a 451 router or a layer-2 bridge. The following processing is performed 452 depending on the type of port the packet has been received through: 454 o If the data packet is received through a Trusted port, the data 455 packet is forwarded and no SAVI processing performed to the 456 packet. 457 o If the data packet is received through a Validating port, then the 458 SAVI function checks whether the received data packet is local 459 traffic or transit traffic. It does so by verifying if the source 460 address of the packet belongs to one of the directly connected 461 prefixes available in the receiving interface. It does so by 462 searching the FCFS SAVI Prefix List. 463 * If the IP source address does not belong to one of the local 464 prefixes of the receiving interface, this means that the dat 465 packet is transit traffic and the packet SHOULD be discarded. 466 The FCFS SAVI function MAY send an ICMP Destination Unreachable 467 Error back to the source address of the data packet. (ICMPv6, 468 code 5 (Source address failed ingress/egress policy) should be 469 used). 470 * If the source address of the packet does belong to one of the 471 prefixes available in the the receiving port, then the SAVI 472 local traffic validation processes is executed as described 473 below. 475 4.2.2. Processing of local traffic. 477 We describe next how the local traffic, including both control and 478 data packets are processed by the SAVI device using a state machine 479 approach. 481 The state machine described is for the binding of a given source IP 482 address in a given SAVI device. So this means that all the packets 483 described as inputs in the state machine above refer to that given IP 484 address. The key attribute is the IP address. The full state 485 information is: 486 o IP ADDRESS: IPAddr 487 o LAYER_2 ANCHOR: P 488 o LIFETIME: LT 490 The possible states are: 491 o NO_BIND 492 o TENTATIVE 493 o VALID 494 o TESTING_TP 495 o TESTING_VP 496 o TESTING_LIFETIME 498 We will use VP for Validating Port and TP for Trusted Port. 500 After bootstrapping (when no binding exists), the state for all 501 source IP address is NO-BIND i.e. there is no binding for the IP 502 address to any Layer-2 anchor. 504 NO_BIND: The binding for a source IP address entry is in this state 505 when it does not have any binding to a Layer 2 anchor. All addresses 506 are in this state by default after bootstrapping, unless bindings 507 were created for it. 509 TENTATIVE: The binding for a source address is in this state during 510 the waiting period during which the DAD procedure is being executed 511 (either directly by the host itself or by the SAVI device on its 512 behalf). 514 VALID: The binding for the source address has been verified, it is 515 valid and usable for filtering traffic. 517 TESTING_TP: A binding for a source address enters in this sate when a 518 DAD_NSOL has been received through a Trusted port. this implies that 519 another host is performing the DAD procedure for that source address 520 in another switch. this may due to an attack or to the fact that the 521 host may have moved. The binding in this state is then being tested 522 to determine which is the situation. 524 TESTING_TP: A binding for a source address enters in this sate when a 525 DAD_NSOL or a data packet has been received through a Validating 526 port. this implies that another host is performing the DAD procedure 527 for that source address in another switch. this may due to an attack 528 or to the fact that the host may have moved. The binding in this 529 state is then being tested to determine which is the situation. 531 TESTING_LIFETIME: A binding for a source address is in this state 532 cause the lifetime of the entry is about to expire. this is due to 533 the fact that no packets has been seen by the SAVI device for the 534 LIFETIME period. this may be due to the host simply being silent or 535 because the host has left the location. In order to determine which 536 is the case, a test is performed, in order to determine if the 537 binding information should be discarded. 539 We describe next how the different inputs are processed depending on 540 the state of the binding of the IP address. 542 A simplified figure of the state machine can be found at 543 http://www.it.uc3m.es/~marcelo/SAVI_state_machine.pdf 545 NO_BIND 547 o Upon the reception through a Validating Port (VP) of a Neighbour 548 Solicitation (NSOL) generated by the Duplicate Address Detection 549 (DAD) procedure (hereafter named DAD_NSOL) containing Target 550 Address IPAddr, or after the reception of a DATA packet containing 551 IPAddr as the source address, the SAVI device will execute the 552 process of sending Neighbour Solicitation (NSOL) messages of the 553 Duplicate Address Detection process as described in section 5.4.2 554 of [RFC4862] for the IPAddr using the following default 555 parameters: DupAddrDetectTransmits set to 2 (i.e. 2 Neighbour 556 Solicitation messages for that address will be sent by the SAVI 557 device) and RetransTimer set to 500 milliseconds (i.e. the time 558 between two Neighbour Solicitation messages is 500 millisecs and 559 also the wait time for replies in the form of Neighbour 560 Advertisement for the queried address). The NSOL messages are not 561 sent through any of the ports configured as Validating Ports. The 562 NSOL messages are sent through the proper Trusted Ports (as 563 defined by the switch behaviour that will depend on whether it 564 performs MLD snooping or not) The SAVI device MAY discard the data 565 packet while the DAD procedure is being executed. 566 * EDITOR NOTE: We need to rate limit the emission of NSOL of the 567 SAVI device as a whole. 568 * EDITOR NOTE 2: should we send the NSOL through the port the 569 packet was received through? 570 The state is moved to TENTATIVE. The LIFETIME is set to TENT_LT 571 (i.e. LT==TENT_LT) and the LAYER_2 ANCHOR is set to VP (i.e. 572 P==VP) 573 o Data packets containing IPAddr as the source address received 574 through Trusted ports are processed and forwarded as usual (i.e. 575 no special SAVI processing) 576 o DAD_NSOL packets containing IPAddr as the target address received 577 through a Trusted port are NOT forwarded through any of the 578 Validating ports but they are sent through the proper Trusted 579 Ports (as defined by the switch behaviour that will depend on 580 whether it performs MLD snooping or not) 581 o Neighbor Advertisement packets sent to all nodes as a reply to the 582 DAD_NSOL (hereafter called DAD_NADV) containing IPAddr as the 583 target address coming through a Validating port are discarded. 584 o Other signaling packets are processed and forwarded as usual (i.e. 585 no SAVI processing) 587 TENTATIVE 589 o If the LIFETIME times out, the state is moved to VALID. The 590 LIFETIME is set to DEFAULT_LT (i.e. LT== DEFAULT_LT). Stored 591 data packets are forwarded (if any). 592 o If a Neighbour Advertisement (NADV) is received through a Trusted 593 Port with Target Address set to IPAddr, then state is set to 594 NO_BIND and the LAYER_2 ANCHOR and the LIFETIME are cleared. Data 595 packets stored corresponding to this binding are discarded. 597 o If a NADV is received through a Validating Port with Target 598 Address set to IPAddr, the NADV packet is discarded 599 o If a data packet with source address IPAddr is received with 600 Layer_2 anchor equal to P, then the packet is either stored or 601 discarded. 602 * EDITOR NOTE: we need to define a maximum storage space for the 603 data packets. Having a single default value may be hard since 604 it will heavily depend on the capability of the device. Maybe 605 it would be enough that the device has a maximum and that the 606 value can be configured? 607 o If a data packet with source address IPAddr is received through a 608 Trusted port, the data packet is forwarded. the state is 609 unchanged. ( waiting for the NADV?) 610 o If a data packet with source address IPAddr is received through a 611 Validating port other than P, the data packet is discarded. 612 o Other signaling packets are processed and forwarded as usual (i.e. 613 no SAVI processing) 614 * EDITOR NOTE: this may need more thought 616 VALID 618 o If a data packet containing IPAddr as a source address arrives 619 from Validating port P, then the LIFETIME is set to DEFAULT_LT and 620 the packet is forwarded as usual. 621 * EDITOR NOTE: Is this feasible? i.e. to reset a timer each time 622 a data packet arrives? We could just have a long lifetime and 623 actively check for the host when the lifetime is about to 624 expire. 625 o If a DAD_NSOL is received from a Trusted port, then the DAD_NSOL 626 message is forwarded to port P and it is also forwarded to the 627 proper Trusted Ports (as defined by the switch behaviour that will 628 depend on whether it performs MLD snooping or not). The state is 629 changed to TESTING_TP. The LIFETIME is set to TENT_LT. 630 o If a data packet containing source address IPAddr or a DAD_NSOL 631 packet with target address set to IPAddr is received through a 632 Validating port P' other than P, then the SAVI device will execute 633 the process of sending DAD_NSOL messages as described in section 634 5.4.2 of [RFC4862] for the IPAddr using the following default 635 parameters: DupAddrDetectTransmits set to 2 (i.e. 2 NSOL messages 636 for that address will be sent by the SAVI device) and RetransTimer 637 set to 500 milliseconds (i.e. the time between two NSOL messages 638 is 500 millisecs and also the wait time for replies in the form of 639 Neighbour Advertisement for the queried address). The DAD_NSOL 640 message will be forwarded to the port P. 641 * EDITOR NOTE: should we also forward it though the TP? 642 Theoretically, there shouldn't be another binding in any other 643 SAVI device, so there should not be a need for this. 644 The state is moved to TESTING_VP. The LIFETIME is set to TENT_LT. 646 The SAVI device MAY discard the data packet while the DAD 647 procedure is being executed. 648 o If the LIFETIME expires, then the SAVI device will execute the 649 process of sending DAD_NSOL messages as described in section 5.4.2 650 of [RFC4862] for the IPAddr using the following default 651 parameters: DupAddrDetectTransmits set to 2 (i.e. 2 NSOL messages 652 for that address will be sent by the SAVI device) and RetransTimer 653 set to 500 milliseconds (i.e. the time between two NSOL messages 654 is 500 millisecs and also the wait time for replies in the form of 655 Neighbour Advertisement for the queried address). The DAD_NSOL 656 messages will be forwarded to the port P. The state is changed to 657 TESTING_LIFETIME and the LIFETIME is set to TENT_LT. 658 o If a data packet containing IPAddr as a source address arrives 659 from Trusted port, the packet is discarded. 660 * EDITOR NOTE: receiving such a packet means that another SAVI 661 device has created a binding for this address, or that the 662 perimeter has been breached. This should be logged? 663 o Other signaling packets are processed and forwarded as usual (i.e. 664 no SAVI processing). In particular DAD_NADV containing IPAddr as 665 the target address are forwarded as usual. 667 TESTING_TP 669 o If the LIFETIME expires, the LAYER_2 ANCHOR is cleared and the 670 state is changed to NO_BIND 671 o If a NADV message containing the IPAddr as target address is 672 received through the Validating port P as a reply to the DAD_NSOL 673 message, then the NADV is forwarded as usual and the state is 674 changed to VALID. The LIFETIME is set to DEFAULT_LT 675 o If a data packet containing IPAddr as the source address is 676 received through port P, then the packet is forwarded. 677 * EDITOR NOTE: should we move back to VALID? 678 o If a data packet is received through a port that is other than 679 port P, then the packet is discarded. 681 TESTING_VP 683 o If the LIFETIME expires, the LAYER_2 ANCHOR set to P' (i.e. 684 P==P'), the LIFETIME is set to DEFAULT_LT and the state is changed 685 to VALID. Data packet stored coming from P' are forwarded. 686 o If a NADV message containing the IPAddr as target address is 687 received through the Validating port P as a reply to the DAD_NSOL 688 message, then the NADV is forwarded as usual and the state is 689 changed to VALID. The LIFETIME is set to DEFAULT_LT 690 o If a data packet containing IPAddr as the source address is 691 received through port P, then the packet is forwarded. 693 * EDITOR NOTE: should we move back to VALID? 694 o If a data packet is received through a port that is other than 695 port P, then the packet is discarded. 697 TESTING_LIFETIME 699 o If the LIFETIME expires, the LAYER_2 ANCHOR is cleared and the 700 state is changed to NO_BIND 701 o If a NADV message containing the IPAddr as target address is 702 received through the Validating port P as a reply to the DAD_NSOL 703 message, then the NADV is forwarded as usual and the state is 704 changed to VALID. The LIFETIME is set to DEFAULT_LT 705 o If a data packet containing IPAddr as the source address is 706 received through port P, then the packet is forwarded and the 707 state is changed to VALID. The LIFETIME is set to DEFAULT_LT 709 Rate limiting of messages: TBD 711 MLD considerations 713 The SAVI device must join the Solicited Node Multicast group for all 714 the addresses which state is other than NO_BIND. this is needed to 715 make sure that the SAVI device will receive the DAD_NSOL for those 716 addresses. Please note that it may not be enough to relay on the 717 host behind the Validating port doing so, since the node may move and 718 after a while, the packets for that particular solicited node 719 multicast group will no longer be forwarded to the SAVI device. So, 720 the SAVI device SHOULD join the solicited node multicast groups for 721 all the addresses that are in a state other than NO_BIND 723 5. Security Considerations 725 First of all, it should be noted that any SAVI solution will be as 726 strong as the lower layer anchor that it uses. In particular, if the 727 lower layer anchor is forgeable, then the resulting SAVI solution 728 will be weak. For example, if the lower layer anchor is a MAC 729 address that can be easily spoofed, then the resulting SAVI will not 730 be stronger than that. On the other hand, if we use switch ports as 731 lower layer anchors (and there is only one host connected to each 732 port) it is likely that the resulting SAVI solution will be 733 considerably more secure. 735 Denial of service attacks 737 There are two types of DoS attacks that can be envisaged in a SAVI 738 environment. On one hand, we can envision attacks against the SAVI 739 device resources. On the other hand, we can envision DoS attacks 740 against the hosts connected to the network where SAVI is running. 742 The attacks against the SAVI device basically consist on making the 743 SAVI device to consume its resource until it runs out of them. For 744 instance, a possible attack would be to send packets with different 745 source addresses, making the SAVI device to create state for each of 746 the addresses and waste memory. At some point the SAVI device runs 747 out of memory and it needs to decide how to react in this situation. 748 The result is that some form of garbage collection is needed to prune 749 the entries. It is recommended that when the SAVI device runs out of 750 the memory allocated for the SAVI DB, it creates new entries by 751 deleting the entries which Creation Time is higher. This implies 752 that older entries are preserved and newer entries overwrite each 753 other. In an attack scenario where the attacker sends a batch of 754 data packets with different source address, each new source address 755 is likely to rewrite another source address created by the attack 756 itself. It should be noted that entries are also garbage collected 757 using the LIFETIME, which is updated using data packets. The result 758 is that in order for an attacker to actually fill the SAVI DB with 759 false source addresses, it needs to continuously send data packets 760 for all the different source addresses, in order for the entries to 761 grow old and compete with the legitimate entries. The result is that 762 the cost of the attack for the attacker is highly increased. 764 The other type of attack is when an attacker manages to create state 765 in the SAVI device that will result in blocking the data packets sent 766 by the legitimate owner of the address. In IPv6 these attacks are 767 not an issue thanks to the 2^64 addresses available in each link. 769 Compare with Threat analysis and identify residual threats: TBD 771 6. Contributors 773 Jun Bi 774 CERNET 775 Network Research Center, Tsinghua University 776 Beijing 100084 777 China 778 Email: junbi@cernet.edu.cn 780 Guang Yao 781 CERNET 782 Network Research Center, Tsinghua University 783 Beijing 100084 784 China 785 Email: yaog@netarchlab.tsinghua.edu.cn 787 Fred Baker 788 Cisco Systems 789 Email: fred@cisco.com 791 Alberto Garcia Martinez 792 University Carlos III of Madrid 793 Email: alberto@it.uc3m.es 795 7. Acknowledgments 797 This draft benefited from the input from: Christian Vogt, Dong Zhang, 798 Frank Xia and Lin Tao. 800 Marcelo Bagnulo is partly funded by Trilogy, a research project 801 supported by the European Commission under its Seventh Framework 802 Program. 804 8. Normative References 806 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 807 Defeating Denial of Service Attacks which employ IP Source 808 Address Spoofing", BCP 38, RFC 2827, May 2000. 810 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 811 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 812 September 2007. 814 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 815 Address Autoconfiguration", RFC 4862, September 2007. 817 Authors' Addresses 819 Erik Nordmark 820 Sun Microsystems, Inc. 821 17 Network Circle 822 Menlo Park, CA 94025 823 USA 825 Phone: +1 650 786 2921 826 Email: Erik.Nordmark@Sun.COM 827 Marcelo Bagnulo 828 Universidad Carlos III de Madrid 829 Av. Universidad 30 830 Leganes, Madrid 28911 831 SPAIN 833 Phone: 34 91 6248814 834 Email: marcelo@it.uc3m.es 835 URI: http://www.it.uc3m.es 837 Eric Levy-Abegnoli 838 Cisco Systems 839 Village d'Entreprises Green Side - 400, Avenue Roumanille 840 Biot-Sophia Antipolis - 06410 841 France 843 Email: elevyabe@cisco.com