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