Network Working Group E. Nordmark Internet-Draft Sun Intended status: Standards Track M. Bagnulo Expires: April 29, 2010 UC3M E. Levy-Abegnoli Cisco Systems October 26, 2009 FCFS-SAVI: First-Come First-Serve Source-Address Validation for Locally Assigned Addresses draft-ietf-savi-fcfs-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 29, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Nordmark, et al. Expires April 29, 2010 [Page 1] Internet-Draft FCFS SAVI October 2009 Abstract This memo describes FCFS SAVI a mechanism to provide source address validation for IPv6 networks using the First-Come First-Serve approach. The proposed mechanism is intended to complement ingress filtering techniques to provide a higher granularity on the control of the source addresses used. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Design considerations . . . . . . . . . . . . . . . . . . . . 3 2.1. Scope of FCFS SAVI . . . . . . . . . . . . . . . . . . . . 3 2.2. Constraints for FCFS SAVI . . . . . . . . . . . . . . . . 4 2.3. Address ownership proof . . . . . . . . . . . . . . . . . 4 2.4. Layer-2 Anchor considerations . . . . . . . . . . . . . . 5 2.5. Special cases . . . . . . . . . . . . . . . . . . . . . . 5 3. SAVI topology and port configuration . . . . . . . . . . . . . 5 3.1. SAVI enforcement perimeter . . . . . . . . . . . . . . . . 6 3.2. SAVI port configuration guidelines . . . . . . . . . . . . 9 3.3. VLAN support . . . . . . . . . . . . . . . . . . . . . . . 10 4. FCFS SAVI specification . . . . . . . . . . . . . . . . . . . 10 4.1. FCFS SAVI Data structures . . . . . . . . . . . . . . . . 10 4.2. FCFS SAVI algorithm . . . . . . . . . . . . . . . . . . . 10 4.2.1. Processing of transit traffic . . . . . . . . . . . . 10 4.2.2. Processing of local traffic. . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. Normative References . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Nordmark, et al. Expires April 29, 2010 [Page 2] Internet-Draft FCFS SAVI October 2009 1. Introduction This memo describes FCFS SAVI, a mechanism to provide source address validation for IPv6 networks using the First-Come First-Serve approach. The proposed mechanism is intended to complement ingress filtering techniques to provide a higher granularity on the control of the source addresses used. 2. Design considerations 2.1. Scope of FCFS SAVI The application scenario for FCFS SAVI is limited to the local-link. This means that the goal of FCFS SAVI is verify that the source address of the packets generated by the hosts attached to the local link have not been spoofed. In any link there usually are hosts and routers attached. Hosts generate packets with their own address as the source address. This is the so-called local traffic. while routers send packets containing a source address other than their own, since they are forwarding packets generated by other hosts (usually located in a different link). This what the so-called transit traffic. The applicability of FCFS SAVI is limited to the local traffic i.e. to verify if the traffic generated by the hosts attached to the local link contains a valid source address. The verification of the source address of the transit traffic is out of the scope of FCFS SAVI. Other techniques, like ingress filtering [RFC2827], are recommended to validate transit traffic. In that sense, FCFS SAVI complements ingress filtering, since it relies on ingress filtering to validate transit traffic but is provides validation of local traffic, which is not provided by ingress filtering. Hence, the security level is increased by using these two techniques. In addition, FCFS SAVI is designed to be used with locally assigned addresses, in particular with address configured through stateless address autoconfiguration [RFC4862]. Manually configured addresses can be supported by FCFS SAVI, but manual configuration of the binding on the SAVI device provides higher security and seems compatible with manual address management. Additional considerations about how to use FCFS SAVI depending on the type of address management used and the nature of the addresses is discussed in the framework document (add reference when available). Nordmark, et al. Expires April 29, 2010 [Page 3] Internet-Draft FCFS SAVI October 2009 2.2. Constraints for FCFS SAVI FCFS SAVI is designed to be deployed in existing networks requiring a minimum set of changes. For that reason, FCFS SAVI does not require any changes in the hosts which source address is to be verified. Any verification must solely rely in the usage of already available protocols. This means that FCFS SAVI cannot define a new protocol nor define any new message on existing protocols nor require that a host uses an existent protocol message in a different way. In other words, the requirement is no host changes. FCFS SAVI validation is performed by the FSFC SAVI function. Such function can be placed in different type of devices, including a router or a layer-2 bridge. The basic idea is that the FCFS SAVI function is located in the points of the topology that can enforce the correct usage of source address by dropping the non-compliant packets. 2.3. Address ownership proof The main function performed by FCFS SAVI is to verify that the source address used in data packets actually belongs to the originator of the packet. Since FCFS SAVI scope is limited to the local link, the originator of the packet is attached to the local link. In order to define any source address validation solution, we need to define some address ownership proof concept i.e. what it means to be able to proof that a given host owns a given address in the sense that the host is entitled to send packet with that source address. Since no host changes are acceptable, we need to find the means to proof address ownership without requiring a new protocol. In FCFS SAVI the address ownership proof is based in the First-Come first Serve approach. This means that the first host that claims a given source address is the owner of the address until further notice. More precisely, whenever a source address is used for the first time, a state is created in the device that is performing the FCFS SAVI function binding the source address to the layer-2 information that the FCFS SAVI box has available (e.g. the port in a switched LAN). Following data packets containing that IP source address must use the same layer-2 information in order to be compliant. There are however additional considerations to be taken into account. For instance, consider the case of a host that moves from one segment of a LAN to another segment of the same subnetwork and it keeps the same IP address. In this case, the host is still the owner of the IP address, but the associated layer-2 information has changed. In order to cope with this case, the defined FCFS SAVI behaviour implies the verification whether the host is still reachable using the Nordmark, et al. Expires April 29, 2010 [Page 4] Internet-Draft FCFS SAVI October 2009 previous layer-2 information. In order to do that FCFS SAVI uses ND protocol. If the host is no longer reachable at the previously recorded layer-2 information, FCFS SAVI assumes that the new location is valid and creates a new binding using the new layer-2 information. In case the host is still reachable using the previously recorded information, the packets coming from the new layer-2 information are dropped. Note that this only applies to local traffic. Transit traffic generated by a router would be verified using alternative techniques, such as ingress filtering. SAVI checks would not be fulfilled by the transit traffic, since the router is not the owner of the source address contained in the packets. 2.4. Layer-2 Anchor considerations Any SAVI solution is not stronger than the Layer-2 anchor it uses. If the Layer-2 anchor is easily spoofable (e.g. a MAC address), then the resulting solution will be weak. The treatment of non-compliant packets needs to be tuned accordingly. In particular, if the Layer-2 anchor is easily spoofable and the SAVI device is configured to drop no compliant packets, then the usage of SAVI may open a new vector of Denial of Service attacks, based on spoofed Layer-2 anchors. For that reason, in this document, we assume that the Layer-2 anchors used by the SAVI solution are not easily spoofable (e.g. ports of a switched network) and that the SAVI device MAY be configured to drop non- compliant packets. If the SAVI solution proposed in this document is to be used with weaker Layer-2 anchors (such as MAC addresses), logging is RECOMMENDED instead of dropping non-compliant packets. For the rest of the document, we will assume that the Layer-2 anchors are ports of a switched network. 2.5. Special cases The following special cases that need to be considered o Hosts with multiple physical interfaces connected to the same link. o Anycast i.e. multiple hosts using the same source address to send packets. o Proxy ND i.e. host sending packets on behalf of other, in a layer-3 transparent manner. 3. SAVI topology and port configuration Nordmark, et al. Expires April 29, 2010 [Page 5] Internet-Draft FCFS SAVI October 2009 3.1. SAVI enforcement perimeter SAVI provides perimetrical security. This means that the SAVI devices form what can be called a SAVI enforcement perimeter and they verify that any packet that crosses the perimeter is compliant (i.e. the source address related information is validated). Once the packet is inside the perimeter, no further validations are performed to the packet. This model has implications both on how SAVI devices are deployed in the topology and on the configuration of the SAVI boxes. The implication of this perimetrical security approach, is that there is part of the topology that is inside the perimeter and part of the topology that is outside the perimeter. This means that while packets coming from interfaces connected to the external part of the topology need to be validated by the SAVI device, packets coming from interfaces connected to the the internal part of the topology do not need to be validated. This significantly reduces the processing requirements of the SAVI device. It also implies that each SAVI device that is part of the perimeter, must be able to verify the source addresses of the packets coming from the interfaces connected to the external part of the perimeter. In order to do so, the SAVI device binds the source address to a layer-2 anchor. One possible approach would be for every SAVI device to store binding information about every source addresses in the subnetwork This means that every SAVI device would store binding for each source address to the local layer-2 anchor through packets with that source address can be received through. The problem with this approach is that it imposes significant memory burden on the SAVI devices. In order to reduce the memory requirements imposed to each device, the SAVI solution described in this specification distributes the storage of SAVI binding information among the multiple SAVI devices of a subnetwork. The SAVI binding state is distributed across the SAVI devices according to the following criteria: each SAVI device will store binding information about the source addresses bound to layer-2 anchors corresponding to the interfaces that connect to the part of the topology that is outside of the SAVI enforcement perimeter. Since all the untrusted packet sources are by definition in the external part of the perimeter, this means that the packets generated by each of the untrusted sources will reach the perimeter through one interface of a SAVI device. The binding information for that particular source address will be stored in this first SAVI device the packet reaches to. This means the SAVI binding information will be distributed across multiple devices. In order to provide proper source address validation, it is critical that the information distributed among the Nordmark, et al. Expires April 29, 2010 [Page 6] Internet-Draft FCFS SAVI October 2009 different SAVI devices is coherent. In particular, it is important to avoid that the same source address is bound to different layer-2 anchors in different SAVI devices. Should that occur, then it would mean that two hosts are allowed to send packets with the same source address, which is what we are trying to prevent. In order to preserve the coherency of the SAVI bindings distributed among the SAVI devices within a realm, the Neighbour Discovery (ND) protocol is used, in particular the Neighbour Solicitation (NSOL) and Neighbour Advertisement (NADV) messages. Before creating a SAVI binding in the local SAVI database, the SAVI device will send a NSOL message querying for the address involved. Should any host reply to that message with a NADV message, the SAVI device that sent the NADV will infer that a binding for that address exists in another SAVI device and will not create a local binding for it. If no NADV message is received as a reply to the NSOL, then the local SAVI device will infer that no binding for that address exists in other SAVI device and will create the local SAVI binding for that address. (NOTE that the description included here is overly simplified to illustrate the mechanism used to preserve the coherency of the binding databases of the different SAVI devices. The actual SAVI mechanism as described below varies in the fact that in some cases it is the SAVI device that generates the NSOL while in other cases it simply forwards the NSOL generated by the end host, and that the SAVI device will send multiple copies of the NSOL in order to improve the reliability of the message exchange). So, summarizing, the proposed SAVI approach relies on the following design choices: o SAVI provides perimetrical security, so some interfaces of a SAVI device will connect to the internal (trusted) part of the topology and other interfaces will connect to the external (untrusted) part of the topology. o A SAVI device only verifies packets coming though one interface connected to the untrusted part of the topology. o A SAVI device only stores binding information for the source addresses that are bound to layer-2 anchors that correspond to interfaces that connect to the untrusted part of the topology. o SAVI uses the NSOL and NADV messages to preserve the coherency of the SAVI binding state distributed among the SAVI devices within a realm. So, in a link that is constituted of multiple L2 devices, some of which are SAVI capable and some of which are not, the SAVI capable devices SHOULD be deployed forming a connected perimeter (i.e. that no data packet can get inside the perimeter without passing through a SAVI device). Packets that cross the perimeter will be validated while packets that do no cross the perimeter are not validated (hence SAVI protection is not provided for these packets). Consider the Nordmark, et al. Expires April 29, 2010 [Page 7] Internet-Draft FCFS SAVI October 2009 deployment of SAVI in the topology depicted in the following picture: +--+ +--+ +--+ +--+ |H1| |H2| |H3| |R1| +--+ +--+ +--+ +--+ | | | | +-------------SAVI-ENFORCEMENT-PERIMETER--------------+ | | | | | | | +-1-----2-+ +-1-----2-+ | | | SAVI1 | | SAVI2 | | | +-3--4----+ +--3------+ | | | | +--------------+ | | | | +----------| |--------+ | | | | SWITCH-A | | | | +----------| |--------+ | | | | +--------------+ | | | +-1--2----+ +--1------+ | | | SAVI3 | | SAVI4 | | | +-3---4---+ +----4----+ | | | | | | +-------------SAVI-ENFORCEMENT-PERIMETER--------------+ | | | +--+ +--+ +---------+ |R2| |H4| |SWICTH-B | +--+ +--+ +---------+ | | +--+ +--+ |H5| |H6| +--+ +--+ In the figure above, the SAVI enforcement perimeter is provided by 4 SAVI devices, namely SAVI1, SAVI2, SAVI3 and SAVI4. These devices verify information related to the source address both in data and in ND packets and filter packets accordingly. SAVI devices then have two types of ports: trusted ports and validating ports. o Validating ports (VPs) are those in which SAVI processing is performed. This means that when a packet is received through one of the validating ports, the SAVI processing and filtering will be executed. o Trusted ports (TPs) are those in which SAVI processing is not performed. So, packets received through trusted ports are not validated and no SAVI processing is performed in them. Trusted ports are used for connections with trusted infrastructure, including the communication between SAVI devices, the communication Nordmark, et al. Expires April 29, 2010 [Page 8] Internet-Draft FCFS SAVI October 2009 with routers and the communication of other switches that while they are not SAVI devices, they only connect to trusted infrastructure (i.e. other SAVI devices, routers or other trusted nodes). So, in the figure above, Port 3 of SAVI1 and port 1 of SAVI3 are trusted because the connect two SAVI devices. Port 4 of SAVI1, port 3 of SAVI2, port 2 of SAVI3 and port 1 of SAVI4 are trusted because the connect to SWITCH-A to which only trusted nodes are connected. In the figure above, port 2 of SAVI2 and port 3 of SAVI3 are trusted ports because they connect to routers. Validating ports are used for connection with non-trusted infrastructure. In particular, hosts are normally connected to validating ports. Non-SAVI switches that are outside of the SAVI enforcement perimeter also are connected through validating port. In particular, non-SAVI devices that connect directly to hosts or that have no SAVI capable device between themselves and the hosts are connected through a validating port. So, in the figure above, ports 1 and 2 of SAVI1, port 1 of SAVI2, port 4 of SAVI 3 are validating ports because they connect to hosts. Port 4 of SAVI4 is also a validating port because it is connected to SWITCH-B which is a non- SAVI capable switch which is connected to hosts H5 and H6. 3.2. SAVI port configuration guidelines The guidelines for port configuration in SAVI devices are: o Ports that are connected to another SAVI device SHOULD be configured as Trusted ports. Not doing so will at least significantly increase the memory consumption in the SAVI devices. o Ports connected to hosts SHOULD be configured as Validating ports. Not doing so will allow the host connected to that port to send packets with spoofed source address. o Ports connected to routers SHOULD be configured as Trusted ports. Configuring them as Validating ports would increase the signaling due to SAVI. The implication is that a router can generate traffic with any source address as they are assumed to be part of the trusted infrastructure. o Ports connected to a chain of one or more legacy switches that have hosts connected SHOULD be configured as Validating ports. Not doing so will allow the host connected to any of these switches to send packets with spoofed source address. o Ports connected to a chain of one or more legacy switches that have other SAVI devices and/or routers connected but had no hosts attached to them SHOULD be configured as Trusted ports. Not doing so will at least significantly increase the memory consumption in the SAVI devices and increase the signaling traffic due to SAVI validation. Nordmark, et al. Expires April 29, 2010 [Page 9] Internet-Draft FCFS SAVI October 2009 o Ports connected to a chain of one or more legacy switches that have a mix of SAVI devices and/or routers with hosts, SHOULD be configured as Validating ports. Not doing so will allow the host connected to that port to send packets with spoofed source address. Nevertheless, this topology will result in increased SAVI signaling and memory consumption compared to a topology where SAVI-hosts communications and inter SAVI communications are kept through different legacy switches. 3.3. VLAN support In the case the SAVI device is a switch that supports VLANs, the SAVI implementation will behave as if there was one SAVI process per VLAN. The SAVI process of each VLAN will store the binding information corresponding the the nodes attached to that particular VLAN. 4. FCFS SAVI specification 4.1. FCFS SAVI Data structures FCFS SAVI function relies on state information binding the source address used in data packets to the layer-2 information that contained the first packet that used that source IP address. Such information is stored in FCFS SAVI Data Base (DB). The FCFS SAVI DB will contain a set of entries about the currently used IP source addresses. So each entry will contain the following information: o IP source address o Layer-2 information, such as Layer-2 address, port through which the packet was received, etc o Lifetime o Status:either tentative or valid o Creation time: the value of the local clock when the entry was firstly created In addition to this, FCFS SAVI need to know what are the prefixes that are directly connected, so it maintains a data structure called the the FCFS SAVI prefix list, which contains: o Prefix o Interface where prefix is directly connected 4.2. FCFS SAVI algorithm 4.2.1. Processing of transit traffic The FCFS SAVI function is located in a forwarding device, such as a router or a layer-2 bridge. The following processing is performed depending on the type of port the packet has been received through: Nordmark, et al. Expires April 29, 2010 [Page 10] Internet-Draft FCFS SAVI October 2009 o If the data packet is received through a Trusted port, the data packet is forwarded and no SAVI processing performed to the packet. o If the data packet is received through a Validating port, then the SAVI function checks whether the received data packet is local traffic or transit traffic. It does so by verifying if the source address of the packet belongs to one of the directly connected prefixes available in the receiving interface. It does so by searching the FCFS SAVI Prefix List. * If the IP source address does not belong to one of the local prefixes of the receiving interface, this means that the dat packet is transit traffic and the packet SHOULD be discarded. The FCFS SAVI function MAY send an ICMP Destination Unreachable Error back to the source address of the data packet. (ICMPv6, code 5 (Source address failed ingress/egress policy) should be used). * If the source address of the packet does belong to one of the prefixes available in the the receiving port, then the SAVI local traffic validation processes is executed as described below. 4.2.2. Processing of local traffic. We describe next how the local traffic, including both control and data packets are processed by the SAVI device using a state machine approach. The state machine described is for the binding of a given source IP address in a given SAVI device. So this means that all the packets described as inputs in the state machine above refer to that given IP address. The key attribute is the IP address. The full state information is: o IP ADDRESS: IPAddr o LAYER_2 ANCHOR: P o LIFETIME: LT The possible states are: o NO_BIND o TENTATIVE o VALID o TESTING_TP o TESTING_VP o TESTING_LIFETIME We will use VP for Validating Port and TP for Trusted Port. After bootstrapping (when no binding exists), the state for all source IP address is NO-BIND i.e. there is no binding for the IP Nordmark, et al. Expires April 29, 2010 [Page 11] Internet-Draft FCFS SAVI October 2009 address to any Layer-2 anchor. NO_BIND: The binding for a source IP address entry is in this state when it does not have any binding to a Layer 2 anchor. All addresses are in this state by default after bootstrapping, unless bindings were created for it. TENTATIVE: The binding for a source address is in this state during the waiting period during which the DAD procedure is being executed (either directly by the host itself or by the SAVI device on its behalf). VALID: The binding for the source address has been verified, it is valid and usable for filtering traffic. TESTING_TP: A binding for a source address enters in this sate when a DAD_NSOL has been received through a Trusted port. this implies that another host is performing the DAD procedure for that source address in another switch. this may due to an attack or to the fact that the host may have moved. The binding in this state is then being tested to determine which is the situation. TESTING_TP: A binding for a source address enters in this sate when a DAD_NSOL or a data packet has been received through a Validating port. this implies that another host is performing the DAD procedure for that source address in another switch. this may due to an attack or to the fact that the host may have moved. The binding in this state is then being tested to determine which is the situation. TESTING_LIFETIME: A binding for a source address is in this state cause the lifetime of the entry is about to expire. this is due to the fact that no packets has been seen by the SAVI device for the LIFETIME period. this may be due to the host simply being silent or because the host has left the location. In order to determine which is the case, a test is performed, in order to determine if the binding information should be discarded. We describe next how the different inputs are processed depending on the state of the binding of the IP address. A simplified figure of the state machine can be found at http://www.it.uc3m.es/~marcelo/SAVI_state_machine.pdf NO_BIND o Upon the reception through a Validating Port (VP) of a Neighbour Solicitation (NSOL) generated by the Duplicate Address Detection (DAD) procedure (hereafter named DAD_NSOL) containing Target Nordmark, et al. Expires April 29, 2010 [Page 12] Internet-Draft FCFS SAVI October 2009 Address IPAddr, or after the reception of a DATA packet containing IPAddr as the source address, the SAVI device will execute the process of sending Neighbour Solicitation (NSOL) messages of the Duplicate Address Detection process as described in section 5.4.2 of [RFC4862] for the IPAddr using the following default parameters: DupAddrDetectTransmits set to 2 (i.e. 2 Neighbour Solicitation messages for that address will be sent by the SAVI device) and RetransTimer set to 500 milliseconds (i.e. the time between two Neighbour Solicitation messages is 500 millisecs and also the wait time for replies in the form of Neighbour Advertisement for the queried address). The NSOL messages are not sent through any of the ports configured as Validating Ports. The NSOL messages are sent through the proper Trusted Ports (as defined by the switch behaviour that will depend on whether it performs MLD snooping or not) The SAVI device MAY discard the data packet while the DAD procedure is being executed. * EDITOR NOTE: We need to rate limit the emission of NSOL of the SAVI device as a whole. * EDITOR NOTE 2: should we send the NSOL through the port the packet was received through? The state is moved to TENTATIVE. The LIFETIME is set to TENT_LT (i.e. LT==TENT_LT) and the LAYER_2 ANCHOR is set to VP (i.e. P==VP) o Data packets containing IPAddr as the source address received through Trusted ports are processed and forwarded as usual (i.e. no special SAVI processing) o DAD_NSOL packets containing IPAddr as the target address received through a Trusted port are NOT forwarded through any of the Validating ports but they are sent through the proper Trusted Ports (as defined by the switch behaviour that will depend on whether it performs MLD snooping or not) o Neighbor Advertisement packets sent to all nodes as a reply to the DAD_NSOL (hereafter called DAD_NADV) containing IPAddr as the target address coming through a Validating port are discarded. o Other signaling packets are processed and forwarded as usual (i.e. no SAVI processing) TENTATIVE o If the LIFETIME times out, the state is moved to VALID. The LIFETIME is set to DEFAULT_LT (i.e. LT== DEFAULT_LT). Stored data packets are forwarded (if any). o If a Neighbour Advertisement (NADV) is received through a Trusted Port with Target Address set to IPAddr, then state is set to NO_BIND and the LAYER_2 ANCHOR and the LIFETIME are cleared. Data packets stored corresponding to this binding are discarded. Nordmark, et al. Expires April 29, 2010 [Page 13] Internet-Draft FCFS SAVI October 2009 o If a NADV is received through a Validating Port with Target Address set to IPAddr, the NADV packet is discarded o If a data packet with source address IPAddr is received with Layer_2 anchor equal to P, then the packet is either stored or discarded. * EDITOR NOTE: we need to define a maximum storage space for the data packets. Having a single default value may be hard since it will heavily depend on the capability of the device. Maybe it would be enough that the device has a maximum and that the value can be configured? o If a data packet with source address IPAddr is received through a Trusted port, the data packet is forwarded. the state is unchanged. ( waiting for the NADV?) o If a data packet with source address IPAddr is received through a Validating port other than P, the data packet is discarded. o Other signaling packets are processed and forwarded as usual (i.e. no SAVI processing) * EDITOR NOTE: this may need more thought VALID o If a data packet containing IPAddr as a source address arrives from Validating port P, then the LIFETIME is set to DEFAULT_LT and the packet is forwarded as usual. * EDITOR NOTE: Is this feasible? i.e. to reset a timer each time a data packet arrives? We could just have a long lifetime and actively check for the host when the lifetime is about to expire. o If a DAD_NSOL is received from a Trusted port, then the DAD_NSOL message is forwarded to port P and it is also forwarded to the proper Trusted Ports (as defined by the switch behaviour that will depend on whether it performs MLD snooping or not). The state is changed to TESTING_TP. The LIFETIME is set to TENT_LT. o If a data packet containing source address IPAddr or a DAD_NSOL packet with target address set to IPAddr is received through a Validating port P' other than P, then the SAVI device will execute the process of sending DAD_NSOL messages as described in section 5.4.2 of [RFC4862] for the IPAddr using the following default parameters: DupAddrDetectTransmits set to 2 (i.e. 2 NSOL messages for that address will be sent by the SAVI device) and RetransTimer set to 500 milliseconds (i.e. the time between two NSOL messages is 500 millisecs and also the wait time for replies in the form of Neighbour Advertisement for the queried address). The DAD_NSOL message will be forwarded to the port P. * EDITOR NOTE: should we also forward it though the TP? Theoretically, there shouldn't be another binding in any other SAVI device, so there should not be a need for this. The state is moved to TESTING_VP. The LIFETIME is set to TENT_LT. Nordmark, et al. Expires April 29, 2010 [Page 14] Internet-Draft FCFS SAVI October 2009 The SAVI device MAY discard the data packet while the DAD procedure is being executed. o If the LIFETIME expires, then the SAVI device will execute the process of sending DAD_NSOL messages as described in section 5.4.2 of [RFC4862] for the IPAddr using the following default parameters: DupAddrDetectTransmits set to 2 (i.e. 2 NSOL messages for that address will be sent by the SAVI device) and RetransTimer set to 500 milliseconds (i.e. the time between two NSOL messages is 500 millisecs and also the wait time for replies in the form of Neighbour Advertisement for the queried address). The DAD_NSOL messages will be forwarded to the port P. The state is changed to TESTING_LIFETIME and the LIFETIME is set to TENT_LT. o If a data packet containing IPAddr as a source address arrives from Trusted port, the packet is discarded. * EDITOR NOTE: receiving such a packet means that another SAVI device has created a binding for this address, or that the perimeter has been breached. This should be logged? o Other signaling packets are processed and forwarded as usual (i.e. no SAVI processing). In particular DAD_NADV containing IPAddr as the target address are forwarded as usual. TESTING_TP o If the LIFETIME expires, the LAYER_2 ANCHOR is cleared and the state is changed to NO_BIND o If a NADV message containing the IPAddr as target address is received through the Validating port P as a reply to the DAD_NSOL message, then the NADV is forwarded as usual and the state is changed to VALID. The LIFETIME is set to DEFAULT_LT o If a data packet containing IPAddr as the source address is received through port P, then the packet is forwarded. * EDITOR NOTE: should we move back to VALID? o If a data packet is received through a port that is other than port P, then the packet is discarded. TESTING_VP o If the LIFETIME expires, the LAYER_2 ANCHOR set to P' (i.e. P==P'), the LIFETIME is set to DEFAULT_LT and the state is changed to VALID. Data packet stored coming from P' are forwarded. o If a NADV message containing the IPAddr as target address is received through the Validating port P as a reply to the DAD_NSOL message, then the NADV is forwarded as usual and the state is changed to VALID. The LIFETIME is set to DEFAULT_LT o If a data packet containing IPAddr as the source address is received through port P, then the packet is forwarded. Nordmark, et al. Expires April 29, 2010 [Page 15] Internet-Draft FCFS SAVI October 2009 * EDITOR NOTE: should we move back to VALID? o If a data packet is received through a port that is other than port P, then the packet is discarded. TESTING_LIFETIME o If the LIFETIME expires, the LAYER_2 ANCHOR is cleared and the state is changed to NO_BIND o If a NADV message containing the IPAddr as target address is received through the Validating port P as a reply to the DAD_NSOL message, then the NADV is forwarded as usual and the state is changed to VALID. The LIFETIME is set to DEFAULT_LT o If a data packet containing IPAddr as the source address is received through port P, then the packet is forwarded and the state is changed to VALID. The LIFETIME is set to DEFAULT_LT Rate limiting of messages: TBD MLD considerations The SAVI device must join the Solicited Node Multicast group for all the addresses which state is other than NO_BIND. this is needed to make sure that the SAVI device will receive the DAD_NSOL for those addresses. Please note that it may not be enough to relay on the host behind the Validating port doing so, since the node may move and after a while, the packets for that particular solicited node multicast group will no longer be forwarded to the SAVI device. So, the SAVI device SHOULD join the solicited node multicast groups for all the addresses that are in a state other than NO_BIND 5. Security Considerations First of all, it should be noted that any SAVI solution will be as strong as the lower layer anchor that it uses. In particular, if the lower layer anchor is forgeable, then the resulting SAVI solution will be weak. For example, if the lower layer anchor is a MAC address that can be easily spoofed, then the resulting SAVI will not be stronger than that. On the other hand, if we use switch ports as lower layer anchors (and there is only one host connected to each port) it is likely that the resulting SAVI solution will be considerably more secure. Denial of service attacks There are two types of DoS attacks that can be envisaged in a SAVI environment. On one hand, we can envision attacks against the SAVI device resources. On the other hand, we can envision DoS attacks Nordmark, et al. Expires April 29, 2010 [Page 16] Internet-Draft FCFS SAVI October 2009 against the hosts connected to the network where SAVI is running. The attacks against the SAVI device basically consist on making the SAVI device to consume its resource until it runs out of them. For instance, a possible attack would be to send packets with different source addresses, making the SAVI device to create state for each of the addresses and waste memory. At some point the SAVI device runs out of memory and it needs to decide how to react in this situation. The result is that some form of garbage collection is needed to prune the entries. It is recommended that when the SAVI device runs out of the memory allocated for the SAVI DB, it creates new entries by deleting the entries which Creation Time is higher. This implies that older entries are preserved and newer entries overwrite each other. In an attack scenario where the attacker sends a batch of data packets with different source address, each new source address is likely to rewrite another source address created by the attack itself. It should be noted that entries are also garbage collected using the LIFETIME, which is updated using data packets. The result is that in order for an attacker to actually fill the SAVI DB with false source addresses, it needs to continuously send data packets for all the different source addresses, in order for the entries to grow old and compete with the legitimate entries. The result is that the cost of the attack for the attacker is highly increased. The other type of attack is when an attacker manages to create state in the SAVI device that will result in blocking the data packets sent by the legitimate owner of the address. In IPv6 these attacks are not an issue thanks to the 2^64 addresses available in each link. Compare with Threat analysis and identify residual threats: TBD 6. Contributors Jun Bi CERNET Network Research Center, Tsinghua University Beijing 100084 China Email: junbi@cernet.edu.cn Guang Yao CERNET Network Research Center, Tsinghua University Beijing 100084 China Nordmark, et al. Expires April 29, 2010 [Page 17] Internet-Draft FCFS SAVI October 2009 Email: yaog@netarchlab.tsinghua.edu.cn Fred Baker Cisco Systems Email: fred@cisco.com Alberto Garcia Martinez University Carlos III of Madrid Email: alberto@it.uc3m.es 7. Acknowledgments This draft benefited from the input from: Christian Vogt, Dong Zhang, Frank Xia and Lin Tao. Marcelo Bagnulo is partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program. 8. Normative References [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. Authors' Addresses Erik Nordmark Sun Microsystems, Inc. 17 Network Circle Menlo Park, CA 94025 USA Phone: +1 650 786 2921 Email: Erik.Nordmark@Sun.COM Nordmark, et al. Expires April 29, 2010 [Page 18] Internet-Draft FCFS SAVI October 2009 Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6248814 Email: marcelo@it.uc3m.es URI: http://www.it.uc3m.es Eric Levy-Abegnoli Cisco Systems Village d'Entreprises Green Side - 400, Avenue Roumanille Biot-Sophia Antipolis - 06410 France Email: elevyabe@cisco.com Nordmark, et al. Expires April 29, 2010 [Page 19]