idnits 2.17.1 draft-bagnulo-savi-fcfs-01.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 241: '...c. The FCFS SAVI SHOULD verify if the...' RFC 2119 keyword, line 248: '... then the packet SHOULD be discarded. ...' RFC 2119 keyword, line 249: '... function MAY send an ICMP Destin...' RFC 2119 keyword, line 289: '...he FCFS SAVI function MAY send an ICMP...' RFC 2119 keyword, line 322: '...dress, FCFS SAVI MAY as well create en...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 22, 2009) is 5567 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: July 26, 2009 UC3M 6 January 22, 2009 8 First-Come First-Serve Source-Address Validation Implementation 9 draft-bagnulo-savi-fcfs-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 26, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 This memo describes FCFS SAVI a mechanism to provide source address 49 validation for IPv4 and IPv6 networks using the First-Come First- 50 Serve approach. The proposed mechanism is intended to complement 51 ingress filtering techniques to provide a higher granularity on the 52 control of the source addresses used. 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 . . . . . . . . . . . . . . . . 3 60 2.3. Address ownership proof . . . . . . . . . . . . . . . . . 4 61 2.4. Special cases . . . . . . . . . . . . . . . . . . . . . . 5 62 3. FCFS SAVI specification . . . . . . . . . . . . . . . . . . . 5 63 3.1. FCFS SAVI Data structures . . . . . . . . . . . . . . . . 5 64 3.2. FCFS SAVI algorithm . . . . . . . . . . . . . . . . . . . 6 65 3.2.1. Processing of data packets . . . . . . . . . . . . . . 6 66 3.2.2. Processing of control packets . . . . . . . . . . . . 7 67 3.3. IPv4 Neighbor Unreachability Detection Procedure . . . . . 9 68 3.3.1. ARP-based Neighbor Unreachability Detection 69 procedure . . . . . . . . . . . . . . . . . . . . . . 9 70 3.3.2. ICMP-based Neighbor Unreachability Detection 71 procedure . . . . . . . . . . . . . . . . . . . . . . 10 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 74 6. Normative References . . . . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 This memo describes FCFS SAVI, a mechanism to provide source address 80 validation for IPv4 and IPv6 networks using the First-Come First- 81 Serve approach. The proposed mechanism is intended to complement 82 ingress filtering techniques to provide a higher granularity on the 83 control of the source addresses used. 85 2. Design considerations 87 2.1. Scope of FCFS SAVI 89 The application scenario for FCFS SAVI is limited to the local-link. 90 This means that the goal of FCFS SAVI is verify that the source 91 address of the packets generated by the hosts attached to the local 92 link have not been spoofed. FCFS SAVI can be used in IPv4 and in 93 IPv6 networks. 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 2.2. Constraints for FCFS SAVI 115 FCFS SAVI is designed to be susceptible of deployment in existing 116 networks requiring a minimum set of changes. For that reason, FCFS 117 SAVI does not require any changes in the hosts which source address 118 is to be verified. Any verification must solely rely in the usage of 119 already available protocols. This means that FCFS SAVI cannot define 120 a new protocol nor to define any new message on existing protocols 121 nor to require that a host uses an existent protocol message in a 122 different way. In other words, the requirement is no host changes. 124 FCFS SAVI validation is performed by the FSFC SAVI function. Such 125 function can be placed in different type of devices, including a 126 router or a layer-2 bridge. The basic idea is that the FCFS SAVI 127 function is located in the points of the topology that can enforce 128 the correct usage of source address by dropping the non-compliant 129 packets. 131 2.3. Address ownership proof 133 The main function performed by FCFS SAVI is to verify that the source 134 address used in data packets actually belongs to the originator of 135 the packet. Since FCFS SAVI scope is limited to the local-link, the 136 originator of the packet is attached to the local-link. In order to 137 to define any source address validation solution, we need to define 138 some address ownership proof concept i.e. what it means to be able to 139 proof that a given host owns a given address in the sense that the 140 host is entitled to send packet with that source address. 142 Since no hast changes are acceptable, we need to find the means to 143 proof address ownership without requiring a new protocol. In FCFS 144 SAVI the address ownership proof is based in the First-Come first 145 Serve approach. This means that the first host that uses a given 146 source address is the owner of the address until further notice. 147 More precisely, whenever a source address is used for the first time, 148 a state is created in the device that is performing the FCFS SAVI 149 function binding the source address to the layer-2 information that 150 the FCFS SAVI box has available (e.g. the MAC address in a LAN, or 151 the port in a switched LAN). Following data packets containing that 152 IP source address must use the same layer-2 information in order to 153 be compliant. 155 There are however additional considerations to be taken into account. 156 For instance, consider the case of a host that moves from one segment 157 of a LAN to another segment of the same subnetwork and it keeps the 158 same IP address. In this case, the host is still the owner of the IP 159 address, but the associated layer-2 information has changed. In 160 order to cope with this case, FCFS SAVI performs an active check to 161 verify if the host is still reachable using the previous layer-2 162 information. In order to do that FCFS SAVI uses ARP protocol in IPv4 163 and ND in IPv6. If the host is no longer reachable at the previously 164 recorded layer-2 information, FCFS SAVI assumes that the new location 165 is valid and creates a new binding using the new LAyer-2 information. 166 In case the host is still reachable using the previously recorded 167 information, the packets coming from the new layer-2 information are 168 dropped (see some caveats described in the following section). 170 Note that this only applies to local traffic. Transit traffic 171 generated by a router would be verified using alternative techniques, 172 such as ingress filtering. ARP or ND checks would not be fulfilled 173 by the transit traffic, since the router is not the owner of the 174 source address contained in the packets. 176 Layer-2 considerations:TBD 178 2.4. Special cases 180 The following special cases that need to be considered 181 o Hosts with multiple physical interfaces, potentially connected to 182 different networks. 183 o Anycast i.e. multiple hosts using the same source address to send 184 packets. 185 o Proxy ARP/ND i.e. host sending packets on behalf of other, in a 186 layer-3 transparent manner. 188 3. FCFS SAVI specification 190 3.1. FCFS SAVI Data structures 192 FCFS SAVI function relies on state information binding the source 193 address used in data packets to the layer-2 information that 194 contained the first packet that used that source IP address. Such 195 information is stored in FCFS SAVI Data Base (DB). The FCFS SAVI DB 196 will contain a set of entries about the currently used IP source 197 addresses. So each entry will contain the following information: 198 o IP source address 199 o Layer-2 information, such as Layer-2 address, port through which 200 the packet was received, etc 201 o Lifetime 202 o Status:either tentative or valid 203 o Creation time: the value of the local clock when the entry was 204 firstly created 206 In addition to this, FCFS SAVI need to know what are the prefixes 207 that are directly connected, so it maintains a data structure called 208 the the FCFS SAVI prefix list, which contains: 209 o Prefix 210 o Interface where prefix is directly connected 212 Finally, FCFS SAVI keep a list of the routers that are directly 213 connected, since the FCFS SAVI checks will not directly apply to 214 them. In the FCFS SAVI Router List, the following information is 215 stored: 216 o Router IP address (of the directly connected interface) 217 o Router Layer-2 information such as layer-2 address or port which 218 the router is connected to 220 3.2. FCFS SAVI algorithm 222 3.2.1. Processing of data packets 224 The FCFS SAVI function is located in a forwarding device, such as a 225 router or a layer-2 bridge. Upon the reception of a data packet, the 226 packet will be passed to the FCFS SAVI function which will perform 227 the processing detailed in this section. The outcome of such 228 processing can be that the packet is discarded or that is forwarded 229 as usual. 231 After a data packet is received, the FCFS SAVI function checks 232 whether the received data packet is local traffic or transit traffic. 233 It does so by verifying if the source address of the packet belongs 234 to one of the directly connected prefixes available in the receiving 235 interface. It does so by searching the FCFS SAVI Prefix List. 236 o If the IP source address belongs to one of the local prefixes of 237 the receiving interface, the data packet is local traffic and the 238 FCFS SAVI algorithm is executed as described next. 239 o If the IP source address does not belong to one of the local 240 prefixes of the receiving interface, this means that the dat 241 packet is transit traffic. The FCFS SAVI SHOULD verify if the 242 layer-2 information of the packet corresponds to one of the 243 routers available in the receiving interface, by using the 244 information available in the FCFS SAVI router list. If the packet 245 comes from one of the know routers for that interface, then the 246 packet is passed so additional checks such as ingress filtering 247 can be performed. If the packet does not comes from one of the 248 known routers, then the packet SHOULD be discarded. The FCFS SAVI 249 function MAY send an ICMP Destination Unreachable Error back to 250 the source address of the data packet. (In ICMPv4, code 0 (net 251 unreachable) should be used and in ICMPv6, code 5 (Source address 252 failed ingress/egress policy) should be used) (Note; we could skip 253 this verification altogether and simply pass it to the ingress 254 filters, but it think this could be useful, especially if used 255 along with SeND) 257 After checking that the data packet is local traffic, the FCFS SAVI 258 function will verify the source address used in the packet. In order 259 to do so, it searches the FCFS SAVI DB using the IP source address as 260 a key. 261 o If no valid entry is found, then a new entry is created, using the 262 information of the data packet, including all the related layer-2 263 information of where the packet was received from and the lifetime 264 of the entry is set to LIFETIME. The status is set to valid. The 265 packet is forwarded as usual. (NOTE: AS defined FCFS SAVI treats 266 tentative entries as if they did not existed i.e. a data packet 267 preempts the DAD procedure, this probably requires more 268 discussion) 269 o If a valid entry is found and the layer-2 information of the 270 received data packet matches to the information contained in the 271 existing entry, then the lifetime is set of LIFETIME and the 272 packet is forwarded as usual. 273 o If a valid entry is found and the layer-2 information of the 274 received data packet does not match the information contained in 275 the existing matching entry, then the FCFS SAVI performs a 276 Neighbor Unreachability Detection procedure as described in 277 [RFC4861] for IPv6 and in Section 3.3 for IPv4. It uses the IP 278 source address and Layer-2 information available in the FCFS SAVI 279 DB entry. 280 * If the procedure determines that the neighbor is no longer 281 reachable using the information available in the FCFS SAVI DB 282 entry, then the entry information is modified to include the 283 new information about the data packet received (in particular 284 the new layer-2 information) and lifetime of the entry is 285 updated to LIFETIME. The packet is forwarded as usual. 286 * If the procedure determines that the neighbor is still 287 reachable using the information available in the FCFS SAVI DB, 288 then the data packet is discarded and the lifetime of the entry 289 is set to LIFETIME. The FCFS SAVI function MAY send an ICMP 290 Destination Unreachable Error back to the source address of the 291 data packet. (In ICMPv4, code 0 (net unreachable) should be 292 used and in ICMPv6, code 5 (Source address failed ingress/ 293 egress policy) should be used) 295 3.2.2. Processing of control packets 297 Processing of IPv6 ND packets 299 The FCFS SAVI function will also create state based on control 300 packets. In particular, in IPv6, when a host configures an address, 301 it performs the Duplicate Address Detection (DAD) procedure, to 302 verify that the address is unique in the link. FCFS SAVI keeps track 303 of the DAD procedure and creates modify the FCFS SAVI DB state 304 accordingly. 306 Upon the reception of a Neighbor Solicitation message containing the 307 unspecified source address FCFS SAVI retrieves the address contained 308 in the Target Address filed of the NSOL message and performs the 309 following actions: 310 o If no valid entry is found in the FCFS SAVI DB for that address, 311 then it creates a new entry, includes the Target Address and the 312 link layer information contained in the NSOL message and sets the 313 status to tentative. At that point FCFS SAVI will keep track of 314 the Neighbor Advertisement messages. 315 * If a NADV message containing the address in the NADV Target 316 Address field is received before DADTimeout then the entry is 317 deleted. 318 * If no NADV message for that Target Address is received in 319 DADTimeout, then the status of the entry is change to valid and 320 the lifetime of the entry is set to LIFETIME. In addition, if 321 the address contained in the newly created entry is a link 322 local address, FCFS SAVI MAY as well create entries for the 323 global addresses resulting from concatenating the Interface 324 Identifier of the link local address and the global prefixes 325 contained in the Prefix List for the Interface through which 326 the NSOL message was received. 327 o If a valid entry is found in the FCFS SAVI DB for that address, no 328 additional processing is performed. (Note: there is no point of 329 tracking the NADV at this point. Either the SAVI DB is updated 330 and there is no new information or it is not, which we will find 331 out when we receive a data packet. Moreover, tracking NADV 332 messages could enable an attacker to overwrite an existing entry.) 334 Processing of IPv4 ARP packets 336 IPv4 Address Conflict Detection (ACD) is defined in [RFC5227] and 337 provides the means to verify if there is an address conflict in IPv4. 338 The FCFS SAVI function will also create state based on IPv4 ACD 339 control packets. In IPv4, when a host configures an address, it 340 performs the Address Conflict Detection (ACD) procedure, to verify 341 that the address is unique in the link. FCFS SAVI keeps track of the 342 ACD procedure and creates modify the FCFS SAVI DB state accordingly. 344 Upon the reception of a ARP Probe (defined as an ARP Request message, 345 broadcast on the local link, with an all-zero 'sender IP address'), 346 FCFS SAVI retrieves the address contained in the 'target IP address' 347 field of the ARP Request message and performs the following actions: 348 o If no valid entry is found in the FCFS SAVI DB for that address, 349 then it creates a new entry, includes the 'target IP address' and 350 the link layer information contained in the ARP Request message 351 and sets the status to tentative. At that point FCFS SAVI will 352 keep track of ARP Announcement messages. ARP Announcement 353 messages are defined as an ARP Request message, broadcast on the 354 local link, with a non all-zero 'sender IP address') 355 * If an ARP Announcement message containing the tentative address 356 in both the 'sender IP address' and the 'target IP address' and 357 it contains the same link-layer information stored in the 358 tentative entry in the SAVI DB is received before 3*ACDTimeout. 359 (default value of 3*2 secs) then the entry status is set to 360 valid and the lifetime of the entry is set to LIFETIME. 362 * If no such message is received for that Target Address in 363 3*ACDTimeout (default value of 3*2 secs), then the entry is 364 deleted. 365 o If a valid entry is found in the FCFS SAVI DB for that address, no 366 additional processing is performed. 368 3.3. IPv4 Neighbor Unreachability Detection Procedure 370 As opposed to IPv6, there is no general Neighbor Unreachability 371 Detection procedure defined for IPv4. Since this is needed in order 372 to verify if the original node is still using the IP address it once 373 used, in this section, we define the procedure to perform such 374 verification. However, unlike IPv6 Neighbor discovery, the IPv4 ARP 375 protocol [RFC0826] cannot be assumed to be available in all link 376 layers. So, we will define a ARP based procedure to be used in 377 layers 2 that the ARP protocol is available and an ICMP based 378 [RFC0792] procedure for the cases where the ARP protocols is not 379 available. The ARP based procedure is used whenever it is possible 380 and when ARP is not available, the ICMP based procedure is used. 382 3.3.1. ARP-based Neighbor Unreachability Detection procedure 384 Consider two nodes, S and T, directly connected through a layer 2 385 where the ARP protocol is available. Node S has with IP address IPS 386 and layer 2 address MACS and Node T has IP address IPT and layer 2 387 address MACT. 389 Node S wants to perform the ARP based Neighbor Unreachability 390 Detection Procedure for node T. Node S has both IPT and MACT 391 available. So, node S generates an ARP REQUEST packet, containing 392 the following information: 393 Ethernet transmission layer: 394 Ethernet address of destination: MACT 395 Ethernet address of sender: MACS 396 Protocol type = ether_type$ADDRESS_RESOLUTION 397 Ethernet packet data: 398 (ar$hrd) Hardware address space (e.g., Ethernet, Packet Radio 399 Net.) 400 (ar$pro) Protocol address space:0x0800 Internet Protocol 401 Version 4 (IPv4) 402 (ar$hln) byte length of each hardware address 403 (ar$pln) byte length of each protocol address: 4 404 (ar$op) opcode (ares_op$REQUEST) 405 (ar$sha) Hardware address of sender of this packet: MACS 406 (ar$spa) Protocol address of sender of this packet: IPS 407 (ar$tha) Hardware address of target of this packet: MACT 408 (ar$tpa) Protocol address of target: IPT 410 Upon the reception of the ARP REQUEST, if node T follows current ARP 411 specification [RFC0826], it will reply with an ARP REPLY packet with 412 the following information: 413 Ethernet transmission layer: 414 Ethernet address of destination: MACS 415 Ethernet address of sender: MACT 416 Protocol type = ether_type$ADDRESS_RESOLUTION 417 Ethernet packet data: 418 (ar$hrd) Hardware address space (e.g., Ethernet, Packet Radio 419 Net.) 420 (ar$pro) Protocol address space:0x0800 Internet Protocol 421 Version 4 (IPv4) 422 (ar$hln) byte length of each hardware address 423 (ar$pln) byte length of each protocol address: 4 424 (ar$op) opcode (ares_op$REPLY) 425 (ar$sha) Hardware address of sender of this packet: MACT 426 (ar$spa) Protocol address of sender of this packet: IPT 427 (ar$tha) Hardware address of target of this packet: MACS 428 (ar$tpa) Protocol address of target: IPS 430 If node S receives the ARP REPLY message, the Neighbor Unreachability 431 procedure was successful and the neighbor T is still reachable with 432 the available information. If node S does not receives the ARP REPLY 433 message after ARPTIMEOUT, then the Neighbor Unreachability procedure 434 has failed and the neighbor T is no longer reachable with the current 435 information. 437 3.3.2. ICMP-based Neighbor Unreachability Detection procedure 439 Consider two nodes, S and T, directly connected through a layer 2. 440 Node S has with IP address IPS and layer 2 address LLAS and Node T 441 has IP address IPT and layer 2 address LLAT. 443 Node S wants to perform the ICMP based Neighbor Unreachability 444 Detection Procedure for node T. Node S has both IPT and LLAT 445 available. So, node S generates an ICMP ECHO packet [RFC0792] , 446 containing the following information: 447 Link Layer fields: 448 Source address: LLAS 449 Destination address: LLAT 450 IP header fields: 451 IP Source Address: IPS 452 IP Destination Address: IPT 453 ICMP fields 454 Type: 8 455 Identifier: set to random number by S 457 Upon the reception of the ICMP ECHO message, if node T follows 458 current ICMP specification [RFC0792], it will reply with an ECHO 459 REPLY packet with the following information: 460 Link Layer fields: 461 Source address: LLAT 462 Destination address: LLAS 463 IP header fields: 464 IP Source Address: IPT 465 IP Destination Address: IPS 466 ICMP fields 467 Type: 0 468 Identifier: copied from the ECHO message received 470 If node S receives a ECHO REPLY message, it will verify that the 471 source IP address and the source link layer address match to the 472 original ones used in the ECHO message. Besides, it will check that 473 the identifier matches to the one contained in the original ECHO 474 message. If these checks are successful the Neighbor Unreachability 475 procedure was successful and the neighbor T is still reachable with 476 the available information. If node S does not receives the ECHO 477 REPLY message after ICMPTIMEOUT, then the Neighbor Unreachability 478 procedure has failed and the neighbor T is no longer reachable with 479 the current information. 481 4. Security Considerations 483 First of all, it should be noted that any SAVI solution will be as 484 strong as the lower layer anchor that it uses. In particular, if the 485 lower layer anchor is forgeable, then the resulting SAVI solution 486 will be weak. For example, if the lower layer anchor is a MAC 487 address that can be easily spoofed, then the resulting SAVI will not 488 be stronger than that. On the other hand, if we use switch ports as 489 lower layer anchors (and there is only one host connected to each 490 port) it is likely that the resulting SAVI solution will be 491 considerably more secure. 493 Denial of service attacks 495 There are two types of DoS attacks that can be envisaged in a SAVI 496 environment. On one hand, we can envision attacks against the SAVI 497 device resources. On the other hand, we can envision DoS attacks 498 against the hosts connected to the network where SAVI is running. 500 The attacks against the SAVI device basically consist on making the 501 SAVI device to consume its resource until it runs out of them. For 502 instance, a possible attack would be to send packets with different 503 source addresses, making the SAVI device to create state for each of 504 the addresses and waste memory. At some point the SAVI device runs 505 out of memory and it needs to decide how to react in this situation. 506 The result is that some form of garbage collection is needed to prune 507 the entries. It is recommended that when the SAVI device runs out of 508 the memory allocated for the SAVI DB, it creates new entries by 509 deleting the entries which Creation Time is higher. This implies 510 that older entries are preserved and newer entries overwrite each 511 other. In an attack scenario where the attacker sends a batch of 512 data packets with different source address, each new source address 513 is likely to rewrite another source address created by the attack 514 itself. It should be noted that entries are also garbage collected 515 using the LIFETIME, which is updated using data packets. The result 516 is that in order for an attacker to actually fill the SAVI DB with 517 false source addresses, it needs to continuously send data packets 518 for all the different source addresses, in order for the entries to 519 grow old and compete with the legitimate entries. The result is that 520 the cost of the attack for the attacker is highly increased. 522 The other type of attack is when an attacker manages to create state 523 in the SAVI device that will result in blocking the data packets sent 524 by the legitimate owner of the address. In the IPv4 case, the 525 simplest way of doing this is for the attacker to claim the ownership 526 of all the addresses available in the prefix assigned to the 527 subnetwork. That is, if an attacker sends data packets with all the 528 source addresses of the on-link prefix, it will claim address 529 ownership for all the available addresses and SAVI will block packets 530 sent by any other host. This is a very severe attack. The proposed 531 solution for this attack is to limit the number of IP addresses bound 532 to a give lower layer anchor. In this way, any host, including the 533 attacker, can only claim the address ownership of a limited number of 534 addresses. Of course, this is only effective if the attacker cannot 535 spoof the lower layer anchor. For instance, in the case where the 536 MAC address is used as lower layer anchor, this measure is hardly 537 sufficient, since the attacker can spoof the source address and still 538 perform the attack. As a result, it is recommended that when the 539 lower layer anchors are spoofable, SAVI should not discard non- 540 compliant packet, but rather log them, to enable proper 541 administrative action. Enabling SAVI in that case could expose the 542 network to the aforementioned DoS attack. If the lower layer anchor 543 is not easily spoofable, the proposed mechanism provides considerable 544 protection, since it limits the impact of the attack. In IPv6 these 545 attacks are not an issue thanks to the 2^64 addresses available in 546 each link. 548 Compare with Threat analysis and identify residual threats: TBD 550 5. Acknowledgments 552 This draft benefited from the input from: Christian Vogt, Fred Baker, 553 Guang Yao, Dong Zhang, Frank Xia and Lin Tao. In particular the usage 554 of ARP and ND packet to create SAVI DB state was suggested by Guang 555 Yao in response to an attack described by Fred Baker. 557 Marcelo Bagnulo is partly funded by Trilogy, a research project 558 supported by the European Commission under its Seventh Framework 559 Program. 561 6. Normative References 563 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 564 Defeating Denial of Service Attacks which employ IP Source 565 Address Spoofing", BCP 38, RFC 2827, May 2000. 567 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 568 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 569 September 2007. 571 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 572 converting network protocol addresses to 48.bit Ethernet 573 address for transmission on Ethernet hardware", STD 37, 574 RFC 826, November 1982. 576 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 577 RFC 792, September 1981. 579 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 580 July 2008. 582 Authors' Addresses 584 Erik Nordmark 585 Sun Microsystems, Inc. 586 17 Network Circle 587 Menlo Park, CA 94025 588 USA 590 Phone: +1 650 786 2921 591 Email: Erik.Nordmark@Sun.COM 592 Marcelo Bagnulo 593 Universidad Carlos III de Madrid 594 Av. Universidad 30 595 Leganes, Madrid 28911 596 SPAIN 598 Phone: 34 91 6248814 599 Email: marcelo@it.uc3m.es 600 URI: http://www.it.uc3m.es