idnits 2.17.1 draft-ietf-savi-fcfs-01.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 234: '...c. The FCFS SAVI SHOULD verify if the...' RFC 2119 keyword, line 241: '... then the packet SHOULD be discarded. ...' RFC 2119 keyword, line 242: '... function MAY send an ICMP Destin...' RFC 2119 keyword, line 281: '...he FCFS SAVI function MAY send an ICMP...' RFC 2119 keyword, line 313: '...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 date (March 4, 2009) is 5531 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: 3 errors (**), 0 flaws (~~), 1 warning (==), 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: September 5, 2009 UC3M 6 March 4, 2009 8 First-Come First-Serve Source-Address Validation Implementation 9 draft-ietf-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 September 5, 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 in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This memo describes FCFS SAVI a mechanism to provide source address 48 validation for IPv6 networks using the First-Come First-Serve 49 approach. The proposed mechanism is intended to complement ingress 50 filtering techniques to provide a higher granularity on the control 51 of the source addresses used. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Design considerations . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Scope of FCFS SAVI . . . . . . . . . . . . . . . . . . . . 3 58 2.2. Constraints for FCFS SAVI . . . . . . . . . . . . . . . . . 3 59 2.3. Address ownership proof . . . . . . . . . . . . . . . . . . 4 60 2.4. Special cases . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. FCFS SAVI specification . . . . . . . . . . . . . . . . . . . . 5 62 3.1. FCFS SAVI Data structures . . . . . . . . . . . . . . . . . 5 63 3.2. FCFS SAVI algorithm . . . . . . . . . . . . . . . . . . . . 6 64 3.2.1. Processing of data packets . . . . . . . . . . . . . . 6 65 3.2.2. Processing of control packets . . . . . . . . . . . . . 7 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 67 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9 68 6. Normative References . . . . . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 This memo describes FCFS SAVI, a mechanism to provide source address 74 validation for IPv6 networks using the First-Come First-Serve 75 approach. The proposed mechanism is intended to complement ingress 76 filtering techniques to provide a higher granularity on the control 77 of the source addresses used. 79 2. Design considerations 81 2.1. Scope of FCFS SAVI 83 The application scenario for FCFS SAVI is limited to the local-link. 84 This means that the goal of FCFS SAVI is verify that the source 85 address of the packets generated by the hosts attached to the local 86 link have not been spoofed. 88 In any link there usually are hosts and routers attached. Hosts 89 generate packets with their own address as the source address. This 90 is the so-called local traffic. while routers send packets containing 91 a source address other than their own, since they are forwarding 92 packets generated by other hosts (usually located in a different 93 link). This what the so-called transit traffic. 95 The applicability of FCFS SAVI is limited to the local traffic i.e. 96 to verify if the traffic generated by the hosts attached to the local 97 link contains a valid source address. The verification of the source 98 address of the transit traffic is out of the scope of FCFS SAVI. 99 Other techniques, like ingress filtering [RFC2827], are recommended 100 to validate transit traffic. In that sense, FCFS SAVI complements 101 ingress filtering, since it relies on ingress filtering to validate 102 transit traffic but is provides validation of local traffic, which is 103 not provided by ingress filtering. Hence, the security level is 104 increased by using these two techniques. 106 2.2. Constraints for FCFS SAVI 108 FCFS SAVI is designed to be susceptible of deployment in existing 109 networks requiring a minimum set of changes. For that reason, FCFS 110 SAVI does not require any changes in the hosts which source address 111 is to be verified. Any verification must solely rely in the usage of 112 already available protocols. This means that FCFS SAVI cannot define 113 a new protocol nor to define any new message on existing protocols 114 nor to require that a host uses an existent protocol message in a 115 different way. In other words, the requirement is no host changes. 117 FCFS SAVI validation is performed by the FSFC SAVI function. Such 118 function can be placed in different type of devices, including a 119 router or a layer-2 bridge. The basic idea is that the FCFS SAVI 120 function is located in the points of the topology that can enforce 121 the correct usage of source address by dropping the non-compliant 122 packets. 124 2.3. Address ownership proof 126 The main function performed by FCFS SAVI is to verify that the source 127 address used in data packets actually belongs to the originator of 128 the packet. Since FCFS SAVI scope is limited to the local-link, the 129 originator of the packet is attached to the local-link. In order to 130 to define any source address validation solution, we need to define 131 some address ownership proof concept i.e. what it means to be able to 132 proof that a given host owns a given address in the sense that the 133 host is entitled to send packet with that source address. 135 Since no hast changes are acceptable, we need to find the means to 136 proof address ownership without requiring a new protocol. In FCFS 137 SAVI the address ownership proof is based in the First-Come first 138 Serve approach. This means that the first host that uses a given 139 source address is the owner of the address until further notice. 140 More precisely, whenever a source address is used for the first time, 141 a state is created in the device that is performing the FCFS SAVI 142 function binding the source address to the layer-2 information that 143 the FCFS SAVI box has available (e.g. the MAC address in a LAN, or 144 the port in a switched LAN). Following data packets containing that 145 IP source address must use the same layer-2 information in order to 146 be compliant. 148 There are however additional considerations to be taken into account. 149 For instance, consider the case of a host that moves from one segment 150 of a LAN to another segment of the same subnetwork and it keeps the 151 same IP address. In this case, the host is still the owner of the IP 152 address, but the associated layer-2 information has changed. In 153 order to cope with this case, FCFS SAVI performs an active check to 154 verify if the host is still reachable using the previous layer-2 155 information. In order to do that FCFS SAVI uses ARP protocol in IPv4 156 and ND in IPv6. If the host is no longer reachable at the previously 157 recorded layer-2 information, FCFS SAVI assumes that the new location 158 is valid and creates a new binding using the new LAyer-2 information. 159 In case the host is still reachable using the previously recorded 160 information, the packets coming from the new layer-2 information are 161 dropped (see some caveats described in the following section). 163 Note that this only applies to local traffic. Transit traffic 164 generated by a router would be verified using alternative techniques, 165 such as ingress filtering. ND checks would not be fulfilled by the 166 transit traffic, since the router is not the owner of the source 167 address contained in the packets. 169 Layer-2 considerations:TBD 171 2.4. Special cases 173 The following special cases that need to be considered 174 o Hosts with multiple physical interfaces, potentially connected to 175 different networks. 176 o Anycast i.e. multiple hosts using the same source address to send 177 packets. 178 o Proxy ND i.e. host sending packets on behalf of other, in a 179 layer-3 transparent manner. 181 3. FCFS SAVI specification 183 3.1. FCFS SAVI Data structures 185 FCFS SAVI function relies on state information binding the source 186 address used in data packets to the layer-2 information that 187 contained the first packet that used that source IP address. Such 188 information is stored in FCFS SAVI Data Base (DB). The FCFS SAVI DB 189 will contain a set of entries about the currently used IP source 190 addresses. So each entry will contain the following information: 191 o IP source address 192 o Layer-2 information, such as Layer-2 address, port through which 193 the packet was received, etc 194 o Lifetime 195 o Status:either tentative or valid 196 o Creation time: the value of the local clock when the entry was 197 firstly created 199 In addition to this, FCFS SAVI need to know what are the prefixes 200 that are directly connected, so it maintains a data structure called 201 the the FCFS SAVI prefix list, which contains: 202 o Prefix 203 o Interface where prefix is directly connected 205 Finally, FCFS SAVI keep a list of the routers that are directly 206 connected, since the FCFS SAVI checks will not directly apply to 207 them. In the FCFS SAVI Router List, the following information is 208 stored: 209 o Router IP address (of the directly connected interface) 210 o Router Layer-2 information such as layer-2 address or port which 211 the router is connected to 213 3.2. FCFS SAVI algorithm 215 3.2.1. Processing of data packets 217 The FCFS SAVI function is located in a forwarding device, such as a 218 router or a layer-2 bridge. Upon the reception of a data packet, the 219 packet will be passed to the FCFS SAVI function which will perform 220 the processing detailed in this section. The outcome of such 221 processing can be that the packet is discarded or that is forwarded 222 as usual. 224 After a data packet is received, the FCFS SAVI function checks 225 whether the received data packet is local traffic or transit traffic. 226 It does so by verifying if the source address of the packet belongs 227 to one of the directly connected prefixes available in the receiving 228 interface. It does so by searching the FCFS SAVI Prefix List. 229 o If the IP source address belongs to one of the local prefixes of 230 the receiving interface, the data packet is local traffic and the 231 FCFS SAVI algorithm is executed as described next. 232 o If the IP source address does not belong to one of the local 233 prefixes of the receiving interface, this means that the dat 234 packet is transit traffic. The FCFS SAVI SHOULD verify if the 235 layer-2 information of the packet corresponds to one of the 236 routers available in the receiving interface, by using the 237 information available in the FCFS SAVI router list. If the packet 238 comes from one of the know routers for that interface, then the 239 packet is passed so additional checks such as ingress filtering 240 can be performed. If the packet does not comes from one of the 241 known routers, then the packet SHOULD be discarded. The FCFS SAVI 242 function MAY send an ICMP Destination Unreachable Error back to 243 the source address of the data packet. (ICMPv6, code 5 (Source 244 address failed ingress/egress policy) should be used) (Note; we 245 could skip this verification altogether and simply pass it to the 246 ingress filters, but it think this could be useful, especially if 247 used along with SeND) 249 After checking that the data packet is local traffic, the FCFS SAVI 250 function will verify the source address used in the packet. In order 251 to do so, it searches the FCFS SAVI DB using the IP source address as 252 a key. 253 o If no valid entry is found, then a new entry is created, using the 254 information of the data packet, including all the related layer-2 255 information of where the packet was received from and the lifetime 256 of the entry is set to LIFETIME. The status is set to valid. The 257 packet is forwarded as usual. (NOTE: AS defined FCFS SAVI treats 258 tentative entries as if they did not existed i.e. a data packet 259 preempts the DAD procedure, this probably requires more 260 discussion) 262 o If a valid entry is found and the layer-2 information of the 263 received data packet matches to the information contained in the 264 existing entry, then the lifetime is set of LIFETIME and the 265 packet is forwarded as usual. 266 o If a valid entry is found and the layer-2 information of the 267 received data packet does not match the information contained in 268 the existing matching entry, then the FCFS SAVI performs a 269 Neighbor Unreachability Detection procedure as described in 270 [RFC4861]. It uses the IP source address and Layer-2 information 271 available in the FCFS SAVI DB entry. 272 * If the procedure determines that the neighbor is no longer 273 reachable using the information available in the FCFS SAVI DB 274 entry, then the entry information is modified to include the 275 new information about the data packet received (in particular 276 the new layer-2 information) and lifetime of the entry is 277 updated to LIFETIME. The packet is forwarded as usual. 278 * If the procedure determines that the neighbor is still 279 reachable using the information available in the FCFS SAVI DB, 280 then the data packet is discarded and the lifetime of the entry 281 is set to LIFETIME. The FCFS SAVI function MAY send an ICMP 282 Destination Unreachable Error back to the source address of the 283 data packet. (ICMPv6, code 5 (Source address failed ingress/ 284 egress policy) should be used) 286 3.2.2. Processing of control packets 288 Processing of IPv6 ND packets 290 The FCFS SAVI function will also create state based on control 291 packets. In particular, when a host configures an address, it 292 performs the Duplicate Address Detection (DAD) procedure, to verify 293 that the address is unique in the link. FCFS SAVI keeps track of the 294 DAD procedure and creates modify the FCFS SAVI DB state accordingly. 296 Upon the reception of a Neighbor Solicitation message containing the 297 unspecified source address FCFS SAVI retrieves the address contained 298 in the Target Address filed of the NSOL message and performs the 299 following actions: 300 o If no valid entry is found in the FCFS SAVI DB for that address, 301 then it creates a new entry, includes the Target Address and the 302 link layer information contained in the NSOL message and sets the 303 status to tentative. At that point FCFS SAVI will keep track of 304 the Neighbor Advertisement messages. 305 * If a NADV message containing the address in the NADV Target 306 Address field is received before DADTimeout then the entry is 307 deleted. 309 * If no NADV message for that Target Address is received in 310 DADTimeout, then the status of the entry is change to valid and 311 the lifetime of the entry is set to LIFETIME. In addition, if 312 the address contained in the newly created entry is a link 313 local address, FCFS SAVI MAY as well create entries for the 314 global addresses resulting from concatenating the Interface 315 Identifier of the link local address and the global prefixes 316 contained in the Prefix List for the Interface through which 317 the NSOL message was received. 318 o If a valid entry is found in the FCFS SAVI DB for that address, no 319 additional processing is performed. (Note: there is no point of 320 tracking the NADV at this point. Either the SAVI DB is updated 321 and there is no new information or it is not, which we will find 322 out when we receive a data packet. Moreover, tracking NADV 323 messages could enable an attacker to overwrite an existing entry.) 325 4. Security Considerations 327 First of all, it should be noted that any SAVI solution will be as 328 strong as the lower layer anchor that it uses. In particular, if the 329 lower layer anchor is forgeable, then the resulting SAVI solution 330 will be weak. For example, if the lower layer anchor is a MAC 331 address that can be easily spoofed, then the resulting SAVI will not 332 be stronger than that. On the other hand, if we use switch ports as 333 lower layer anchors (and there is only one host connected to each 334 port) it is likely that the resulting SAVI solution will be 335 considerably more secure. 337 Denial of service attacks 339 There are two types of DoS attacks that can be envisaged in a SAVI 340 environment. On one hand, we can envision attacks against the SAVI 341 device resources. On the other hand, we can envision DoS attacks 342 against the hosts connected to the network where SAVI is running. 344 The attacks against the SAVI device basically consist on making the 345 SAVI device to consume its resource until it runs out of them. For 346 instance, a possible attack would be to send packets with different 347 source addresses, making the SAVI device to create state for each of 348 the addresses and waste memory. At some point the SAVI device runs 349 out of memory and it needs to decide how to react in this situation. 350 The result is that some form of garbage collection is needed to prune 351 the entries. It is recommended that when the SAVI device runs out of 352 the memory allocated for the SAVI DB, it creates new entries by 353 deleting the entries which Creation Time is higher. This implies 354 that older entries are preserved and newer entries overwrite each 355 other. In an attack scenario where the attacker sends a batch of 356 data packets with different source address, each new source address 357 is likely to rewrite another source address created by the attack 358 itself. It should be noted that entries are also garbage collected 359 using the LIFETIME, which is updated using data packets. The result 360 is that in order for an attacker to actually fill the SAVI DB with 361 false source addresses, it needs to continuously send data packets 362 for all the different source addresses, in order for the entries to 363 grow old and compete with the legitimate entries. The result is that 364 the cost of the attack for the attacker is highly increased. 366 The other type of attack is when an attacker manages to create state 367 in the SAVI device that will result in blocking the data packets sent 368 by the legitimate owner of the address. In IPv6 these attacks are 369 not an issue thanks to the 2^64 addresses available in each link. 371 Compare with Threat analysis and identify residual threats: TBD 373 5. Acknowledgments 375 This draft benefited from the input from: Christian Vogt, Fred Baker, 376 Guang Yao, Dong Zhang, Frank Xia and Lin Tao. In particular the usage 377 of ARP and ND packet to create SAVI DB state was suggested by Guang 378 Yao in response to an attack described by Fred Baker. 380 Marcelo Bagnulo is partly funded by Trilogy, a research project 381 supported by the European Commission under its Seventh Framework 382 Program. 384 6. Normative References 386 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 387 Defeating Denial of Service Attacks which employ IP Source 388 Address Spoofing", BCP 38, RFC 2827, May 2000. 390 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 391 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 392 September 2007. 394 Authors' Addresses 396 Erik Nordmark 397 Sun Microsystems, Inc. 398 17 Network Circle 399 Menlo Park, CA 94025 400 USA 402 Phone: +1 650 786 2921 403 Email: Erik.Nordmark@Sun.COM 405 Marcelo Bagnulo 406 Universidad Carlos III de Madrid 407 Av. Universidad 30 408 Leganes, Madrid 28911 409 SPAIN 411 Phone: 34 91 6248814 412 Email: marcelo@it.uc3m.es 413 URI: http://www.it.uc3m.es