idnits 2.17.1 draft-ietf-savi-fcfs-00.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? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 279: '...he FCFS SAVI function MAY send an ICMP...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 22, 2009) is 5571 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 (==), 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-ietf-savi-fcfs-00 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.3. IPv4 Neighbor Unreachability Detection Procedure . . . . . 7 66 3.3.1. ARP-based Neighbor Unreachability Detection 67 procedure . . . . . . . . . . . . . . . . . . . . . . 7 68 3.3.2. ICMP-based Neighbor Unreachability Detection 69 procedure . . . . . . . . . . . . . . . . . . . . . . 8 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 72 6. Normative References . . . . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 This memo describes FCFS SAVI, a mechanism to provide source address 78 validation for IPv4 and IPv6 networks using the First-Come First- 79 Serve approach. The proposed mechanism is intended to complement 80 ingress filtering techniques to provide a higher granularity on the 81 control of the source addresses used. 83 2. Design considerations 85 2.1. Scope of FCFS SAVI 87 The application scenario for FCFS SAVI is limited to the local-link. 88 This means that the goal of FCFS SAVI is verify that the source 89 address of the packets generated by the hosts attached to the local 90 link have not been spoofed. FCFS SAVI can be used in IPv4 and in 91 IPv6 networks. 93 In any link there usually are hosts and routers attached. Hosts 94 generate packets with their own address as the source address. This 95 is the so-called local traffic. while routers send packets containing 96 a source address other than their own, since they are forwarding 97 packets generated by other hosts (usually located in a different 98 link). This what the so-called transit traffic. 100 The applicability of FCFS SAVI is limited to the local traffic i.e. 101 to verify if the traffic generated by the hosts attached to the local 102 link contains a valid source address. The verification of the source 103 address of the transit traffic is out of the scope of FCFS SAVI. 104 Other techniques, like ingress filtering [RFC2827], are recommended 105 to validate transit traffic. In that sense, FCFS SAVI complements 106 ingress filtering, since it relies on ingress filtering to validate 107 transit traffic but is provides validation of local traffic, which is 108 not provided by ingress filtering. Hence, the security level is 109 increased by using these two techniques. 111 2.2. Constraints for FCFS SAVI 113 FCFS SAVI is designed to be susceptible of deployment in existing 114 networks requiring a minimum set of changes. For that reason, FCFS 115 SAVI does not require any changes in the hosts which source address 116 is to be verified. Any verification must solely rely in the usage of 117 already available protocols. This means that FCFS SAVI cannot define 118 a new protocol nor to define any new message on existing protocols 119 nor to require that a host uses an existent protocol message in a 120 different way. In other words, the requirement is no host changes. 122 FCFS SAVI validation is performed by the FSFC SAVI function. Such 123 function can be placed in different type of devices, including a 124 router or a layer-2 bridge. the basic idea is that the FCFS SAVI 125 function is located in the points of the topology that can enforce 126 the correct usage of source address by dropping the non-compliant 127 packets. 129 2.3. Address ownership proof 131 The main function performed by FCFS SAVI is to verify that the source 132 address used in data packets actually belongs to the originator of 133 the packet. Since FCFS SAVI scope is limited to the local-link, the 134 originator of the packet is attached to the local-link. In order to 135 to define any source address validation solution, we need to define 136 some address ownership proof concept i.e. what it means to be able to 137 proof that a given host owns a given address in the sense that the 138 host is entitled to send packet with that source address. 140 Since no hast changes are acceptable, we need to find the means to 141 proof address ownership without requiring a new protocol. In FCFS 142 SAVI the address ownership proof is based in the First-Come first 143 Serve approach. This means that the first host that sends a packet 144 with a given source address is the owner of the address until further 145 notice. More precisely, whenever a source address is used for the 146 first time, a state is created in the device that is performing the 147 FCFS SAVI function binding the source address to the layer-2 148 information that the FCFS SAVI box has available (e.g. the MAC 149 address in a LAN, or the port in a switched LAN). Following data 150 packets containing that IP source address must use the same layer-2 151 information in order to be compliant. 153 There are however additional consideration to be taken into account. 154 For instance, consider the case of a host that moves from one segment 155 of a LAN to another segment of the same subnetwork and it keeps the 156 same IP address. In this case, the host is still the owner of the IP 157 address, but the associated layer-2 information has changed. In 158 order to cope with this case, FCFS SAVI performs an active check to 159 verify if the host is still reachable using the previous layer-2 160 information. In order to do that FCFS SAVI uses ARP protocol in IPv4 161 and ND in IPv6. If the host is no longer reachable at the previously 162 recorded layer-2 information, FCFS SAVI assumes that the new location 163 is valid and creates a new binding using the new LAyer-2 information. 164 In case the host is still reachable using the previously recorded 165 information, the packets coming from the new layer-2 information are 166 dropped (see some caveats described in the following section). 168 Note that this only applies to local traffic. Transit traffic 169 generated by a router would be verified using alternative techniques, 170 such as ingress filtering. ARP or ND checks would not be fulfilled 171 by the transit traffic, since the router is not the owner of the 172 source address contained in the packets. 174 Layer-2 considerations:TBD 176 2.4. Special cases 178 The following special cases that need to be considered 179 o Hosts with multiple physical interfaces, potentially connected to 180 different networks. 181 o Anycast i.e. multiple hosts using the same source address to send 182 packets. 183 o Proxy ARP/ND i.e. host sending packets on behalf of other, in a 184 layer-3 transparent manner. 186 3. FCFS SAVI specification 188 3.1. FCFS SAVI Data structures 190 FCFS SAVI function relies on state information binding the source 191 address used in data packets to the layer-2 information that 192 contained the first packet that used that source IP address. Such 193 information is stored in FCFS SAVI Data Base (DB). The FCFS SAVI DB 194 will contain a set of entries about the currently used IP source 195 addresses. So each entry will contain the following information: 196 o IP source address 197 o Layer-2 information, such as Layer-2 address, port through which 198 the packet was received, etc 199 o Lifetime 201 In addition to this, FCFS SAVI need to know what are the prefixes 202 that are directly connected, so it maintains a data structure called 203 the the FCFS SAVI prefix list, which contains: 204 o Prefix 205 o Interface where prefix is directly connected 207 Finally, FCFS SAVI keep a list of the routers that are directly 208 connected, since the FCFS SAVI checks will not directly apply to 209 them. In the FCFS SAVI Router List, the following information is 210 stored: 211 o Router IP address (of the directly connected interface) 212 o Router Layer-2 information such as layer-2 address or port which 213 the router is connected to 215 3.2. FCFS SAVI algorithm 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. (In ICMPv4, code 0 (net 244 unreachable) should be used and in ICMPv6, code 5 (Source address 245 failed ingress/egress policy) should be used) (Note; we could skip 246 this verification altogether and simply pass it to the ingress 247 filters, but it think this could be useful, especially if used 248 along with SeND) 250 After checking that the data packet is local traffic, the FCFS SAVI 251 function will verify the source address used in the packet. In order 252 to do so, it searches the FCFS SAVI DB using the IP source address as 253 a key. 254 o If no entry is found, then a new entry is created, using the 255 information of the data packet, including all the related layer-2 256 information of where the packet was received from and the lifetime 257 of the entry is set to LIFETIME. The packet is forwarded as 258 usual. 259 o If an entry is found and the layer-2 information of the received 260 data packet matches to the information contained in the existing 261 entry, then the lifetime is set of LIFETIME and the packet is 262 forwarded as usual. 264 o If an entry is found and the layer-2 information of the received 265 data packet does not match the information contained in the 266 existing matching entry, then the FCFS SAVI performs a Neighbor 267 Unreachability Detection procedure as described in [RFC4861] for 268 IPv4 and in Section 3.3 for IPv4. It uses the IP source address 269 and Layer-2 information available in the FCFS SAVI DB entry. 270 * If the procedure determines that the neighbor is no longer 271 reachable using the information available in the FCFS SAVI DB 272 entry, then the entry information is modified to include the 273 new information about the data packet received (in particular 274 the new layer-2 information) and lifetime of the entry is 275 updated to LIFETIME. The packet is forwarded as usual. 276 * If the procedure determines that the neighbor is still 277 reachable using the information available in the FCFS SAVI DB, 278 then the data packet is discarded and the lifetime of the entry 279 is set to LIFETIME. The FCFS SAVI function MAY send an ICMP 280 Destination Unreachable Error back to the source address of the 281 data packet. (In ICMPv4, code 0 (net unreachable) should be 282 used and in ICMPv6, code 5 (Source address failed ingress/ 283 egress policy) should be used) 285 3.3. IPv4 Neighbor Unreachability Detection Procedure 287 As opposed to IPv6, there is no general Neighbor Unreachability 288 Detection procedure defined for IPv4. Since this is needed in order 289 to verify if the original node is still using the IP address it once 290 used, in this section, we define the procedure to perform such 291 verification. However, unlike IPv6 Neighbor discovery, the IPv4 ARP 292 protocol [RFC0826] cannot be assumed to be available in all link 293 layers. So, we will define a ARP based procedure to be used in 294 layers 2 that the ARP protocol is available and an ICMP based 295 [RFC0792] procedure for the cases where the ARP protocols is not 296 available. The ARP based procedure is used whenever it is possible 297 and when ARP is not available, the ICMP based procedure is used. 299 3.3.1. ARP-based Neighbor Unreachability Detection procedure 301 Consider two nodes, S and T, directly connected through a layer 2 302 where the ARP protocol is available. Node S has with IP address IPS 303 and layer 2 address MACS and Node T has IP address IPT and layer 2 304 address MACT. 306 Node S wants to perform the ARP based Neighbor Unreachability 307 Detection Procedure for node T. Node S has both IPT and MACT 308 available. So, node S generates an ARP REQUEST packet, containing 309 the following information: 311 Ethernet transmission layer: 312 Ethernet address of destination: MACT 313 Ethernet address of sender: MACS 314 Protocol type = ether_type$ADDRESS_RESOLUTION 315 Ethernet packet data: 316 (ar$hrd) Hardware address space (e.g., Ethernet, Packet Radio 317 Net.) 318 (ar$pro) Protocol address space:0x0800 Internet Protocol 319 Version 4 (IPv4) 320 (ar$hln) byte length of each hardware address 321 (ar$pln) byte length of each protocol address: 4 322 (ar$op) opcode (ares_op$REQUEST) 323 (ar$sha) Hardware address of sender of this packet: MACS 324 (ar$spa) Protocol address of sender of this packet: IPS 325 (ar$tha) Hardware address of target of this packet: MACT 326 (ar$tpa) Protocol address of target: IPT 328 Upon the reception of the ARP REQUEST, if node T follows current ARP 329 specification [RFC0826], it will reply with an ARP REPLY packet with 330 the following information: 331 Ethernet transmission layer: 332 Ethernet address of destination: MACS 333 Ethernet address of sender: MACT 334 Protocol type = ether_type$ADDRESS_RESOLUTION 335 Ethernet packet data: 336 (ar$hrd) Hardware address space (e.g., Ethernet, Packet Radio 337 Net.) 338 (ar$pro) Protocol address space:0x0800 Internet Protocol 339 Version 4 (IPv4) 340 (ar$hln) byte length of each hardware address 341 (ar$pln) byte length of each protocol address: 4 342 (ar$op) opcode (ares_op$REPLY) 343 (ar$sha) Hardware address of sender of this packet: MACT 344 (ar$spa) Protocol address of sender of this packet: IPT 345 (ar$tha) Hardware address of target of this packet: MACS 346 (ar$tpa) Protocol address of target: IPS 348 If node S receives the ARP REPLY message, the Neighbor Unreachability 349 procedure was successful and the neighbor T is still reachable with 350 the available information. If node S does not receives the ARP REPLY 351 message after ARPTIMEOUT, then the Neighbor Unreachability procedure 352 has failed and the neighbor T is no longer reachable with the current 353 information. 355 3.3.2. ICMP-based Neighbor Unreachability Detection procedure 357 Consider two nodes, S and T, directly connected through a layer 2. 358 Node S has with IP address IPS and layer 2 address LLAS and Node T 359 has IP address IPT and layer 2 address LLAT. 361 Node S wants to perform the ICMP based Neighbor Unreachability 362 Detection Procedure for node T. Node S has both IPT and LLAT 363 available. So, node S generates an ICMP ECHO packet [RFC0792] , 364 containing the following information: 365 Link Layer fields: 366 Source address: LLAS 367 Destination address: LLAT 368 IP header fields: 369 IP Source Address: IPS 370 IP Destination Address: IPT 371 ICMP fields 372 Type: 8 373 Identifier: set to random number by S 375 Upon the reception of the ICMP ECHO message, if node T follows 376 current ICMP specification [RFC0792], it will reply with an ECHO 377 REPLY packet with the following information: 378 Link Layer fields: 379 Source address: LLAT 380 Destination address: LLAS 381 IP header fields: 382 IP Source Address: IPT 383 IP Destination Address: IPS 384 ICMP fields 385 Type: 0 386 Identifier: copied from the ECHO message received 388 If node S receives a ECHO REPLY message, it will verify that the 389 source IP address and the source link layer address match to the 390 original ones used in the ECHO message. Besides, it will check that 391 the identifier matches to the one contained in the original ECHO 392 message. If these checks are successful the Neighbor Unreachability 393 procedure was successful and the neighbor T is still reachable with 394 the available information. If node S does not receives the ECHO 395 REPLY message after ICMPTIMEOUT, then the Neighbor Unreachability 396 procedure has failed and the neighbor T is no longer reachable with 397 the current information. 399 4. Security Considerations 401 Compare with Threat analysis and identify residual threats: TBD 403 5. Acknowledgments 405 Marcelo Bagnulo is partly funded by Trilogy, a research project 406 supported by the European Commission under its Seventh Framework 407 Program. 409 6. Normative References 411 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 412 Defeating Denial of Service Attacks which employ IP Source 413 Address Spoofing", BCP 38, RFC 2827, May 2000. 415 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 416 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 417 September 2007. 419 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 420 converting network protocol addresses to 48.bit Ethernet 421 address for transmission on Ethernet hardware", STD 37, 422 RFC 826, November 1982. 424 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 425 RFC 792, September 1981. 427 Authors' Addresses 429 Erik Nordmark 430 Sun Microsystems, Inc. 431 17 Network Circle 432 Menlo Park, CA 94025 433 USA 435 Phone: +1 650 786 2921 436 Email: Erik.Nordmark@Sun.COM 438 Marcelo Bagnulo 439 Universidad Carlos III de Madrid 440 Av. Universidad 30 441 Leganes, Madrid 28911 442 SPAIN 444 Phone: 34 91 6248814 445 Email: marcelo@it.uc3m.es 446 URI: http://www.it.uc3m.es