diff options
Diffstat (limited to 'doc/rfc/rfc6620.txt')
| -rw-r--r-- | doc/rfc/rfc6620.txt | 1963 |
1 files changed, 1963 insertions, 0 deletions
diff --git a/doc/rfc/rfc6620.txt b/doc/rfc/rfc6620.txt new file mode 100644 index 0000000..b68de00 --- /dev/null +++ b/doc/rfc/rfc6620.txt @@ -0,0 +1,1963 @@ + + + + + + +Internet Engineering Task Force (IETF) E. Nordmark +Request for Comments: 6620 Cisco Systems +Category: Standards Track M. Bagnulo +ISSN: 2070-1721 UC3M + E. Levy-Abegnoli + Cisco Systems + May 2012 + + + FCFS SAVI: First-Come, First-Served Source Address Validation + Improvement for Locally Assigned IPv6 Addresses + +Abstract + + This memo describes First-Come, First-Served Source Address + Validation Improvement (FCFS SAVI), a mechanism that provides source + address validation for IPv6 networks using the FCFS principle. The + proposed mechanism is intended to complement ingress filtering + techniques to help detect and prevent source address spoofing. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6620. + + + + + + + + + + + + + + + + + + +Nordmark, et al. Standards Track [Page 1] + +RFC 6620 FCFS SAVI May 2012 + + +Copyright Notice + + Copyright (c) 2012 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 + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Nordmark, et al. Standards Track [Page 2] + +RFC 6620 FCFS SAVI May 2012 + + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Terminology ................................................4 + 2. Background to FCFS SAVI .........................................4 + 2.1. Scope of FCFS SAVI .........................................4 + 2.2. Constraints for FCFS SAVI Design ...........................5 + 2.3. Address Ownership Proof ....................................5 + 2.4. Binding Anchor Considerations ..............................6 + 2.5. FCFS SAVI Protection Perimeter .............................6 + 2.6. Special Cases .............................................10 + 3. FCFS SAVI Specification ........................................11 + 3.1. FCFS SAVI Data Structures .................................12 + 3.2. FCFS SAVI Algorithm .......................................12 + 3.2.1. Discovering On-Link Prefixes .......................12 + 3.2.2. Processing of Transit Traffic ......................13 + 3.2.3. Processing of Local Traffic ........................13 + 3.2.4. FCFS SAVI Port Configuration Guidelines ............21 + 3.2.5. VLAN Support .......................................22 + 3.3. Default Protocol Values ...................................22 + 4. Security Considerations ........................................22 + 4.1. Denial-of-Service Attacks .................................22 + 4.2. Residual Threats ..........................................23 + 4.3. Privacy Considerations ....................................24 + 4.4. Interaction with Secure Neighbor Discovery ................25 + 5. Contributors ...................................................25 + 6. Acknowledgments ................................................25 + 7. References .....................................................26 + 7.1. Normative References ......................................26 + 7.2. Informative References ....................................26 + Appendix A. Implications of Not Following the Recommended + Behavior .............................................28 + A.1. Implications of Not Generating DAD_NS Packets upon the + Reception of Non-Compliant Data Packets ...................28 + A.1.1. Lack of Binding State due to Packet Loss...............28 + A.1.2. Lack of Binding State due to a Change in the + Topology ..............................................31 + A.1.3. Lack of Binding State due to State Loss ...............31 + A.2. Implications of Not Discarding Non-Compliant Data + Packets ...................................................35 + + + + + + + + + + + +Nordmark, et al. Standards Track [Page 3] + +RFC 6620 FCFS SAVI May 2012 + + +1. Introduction + + This memo describes FCFS SAVI, a mechanism that provides source + address validation for IPv6 networks using the FCFS principle. The + proposed mechanism is intended to complement ingress filtering + techniques to help detect and prevent source address spoofing. + Section 2 gives the background and description of FCFS SAVI, and + Section 3 specifies the FCFS SAVI protocol. + +1.1. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. Background to FCFS SAVI + +2.1. Scope of FCFS SAVI + + The application scenario for FCFS SAVI is limited to the local link. + Hence, the goal of FCFS SAVI is to verify that the source address of + the packets generated by the hosts attached to the local link have + not been spoofed. + + In a link, hosts and routers are usually attached. Hosts generate + packets with their own address as the source address. This is called + "local traffic". Routers send packets containing a source IP address + other than their own, since they are forwarding packets generated by + other hosts (usually located in a different link). This is 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 it 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 + IPv6 addresses, in particular with IPv6 addresses configured through + Stateless Address Autoconfiguration (SLAAC) [RFC4862]. Manually + configured IPv6 addresses can be supported by FCFS SAVI, but manual + configuration of the binding on the FCFS SAVI device provides higher + security and seems compatible with manual address management. FCFS + + + +Nordmark, et al. Standards Track [Page 4] + +RFC 6620 FCFS SAVI May 2012 + + + SAVI can also be used with IPv6 addresses assigned via DHCPv6, since + they ought to perform the Duplicate Address Detection (DAD) + procedure, but there is a specific mechanism tailored for dealing + with DHCP-assigned addresses defined in [SAVI-DHCP]. Additional + considerations about how to use FCFS SAVI depending on the type of + address management used and the nature of the addresses are discussed + in the framework document [SAVI-FRAMEWORK]. + +2.2. Constraints for FCFS SAVI Design + + 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 host whose source address is to be verified. Any + verification solely relies on the usage of already available + protocols. That is, FCFS SAVI does not define a new protocol, define + any new message on existing protocols, or require that a host use an + existent protocol message in a different way. In other words, no + host changes are required. + + FCFS SAVI validation is performed by the FCFS SAVI function. The + function can be placed in different types of devices, including a + router or a Layer 2 (L2) 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 the 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 the FCFS SAVI scope is limited to the local link, + the originator of the packet is attached to the local link. In order + to define a source address validation solution, we need to define the + meaning of "address ownership", i.e., what it means that a given host + owns a given address in the sense that the host is entitled to send + packets with that source address. With that definition, we can + define how a device can confirm that the source address in a datagram + is owned by the originator of the datagram. + + In FCFS SAVI, proof of address ownership is based on the First-Come, + First-Served principle. The first host that claims a given source + address is the owner of the address until further notice. Since no + host changes are acceptable, we need to find the means to confirm + address ownership without requiring a new protocol. So, 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 a binding anchor that consists of Layer 2 information that + the FCFS SAVI box has available (e.g., the port in a switched LAN). + + + +Nordmark, et al. Standards Track [Page 5] + +RFC 6620 FCFS SAVI May 2012 + + + Subsequent data packets containing that IP source address can be + checked against the same binding anchor to confirm that the + originator owns the source IP address. + + 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 + keeps the same IP address. In this case, the host is still the owner + of the IP address, but the associated binding anchor may have + changed. In order to cope with this case, the defined FCFS SAVI + behavior implies verification of whether or not the host is still + reachable using the previous binding anchor. In order to do that, + FCFS SAVI uses the Neighbor Discovery (ND) protocol. If the host is + no longer reachable at the previously recorded binding anchor, FCFS + SAVI assumes that the new location is valid and creates a new binding + using the new binding anchor. In case the host is still reachable + using the previously recorded binding anchor, the packets coming from + the new binding anchor 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. FCFS 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. Binding Anchor Considerations + + Any SAVI solution is not stronger than the binding anchor it uses. + If the binding anchor is easily spoofable (e.g., a Media Access + Control (MAC) address), then the resulting solution will be weak. + The treatment of non-compliant packets needs to be tuned accordingly. + In particular, if the binding anchor is easily spoofable and the FCFS + SAVI device is configured to drop non-compliant packets, then the + usage of FCFS SAVI may open a new vector of Denial-of-Service (DoS) + attacks, based on spoofed binding anchors. For that reason, in this + specification, only switch ports MUST be used as binding anchors. + Other forms of binding anchors are out of the scope of this + specification, and proper analysis of the implications of using them, + should be performed before their usage. + +2.5. FCFS SAVI Protection Perimeter + + FCFS SAVI provides perimetrical security. FCFS SAVI devices form + what can be called an FCFS SAVI protection perimeter, and they verify + that any packet that crosses the perimeter is compliant (i.e., the + source address is validated). Once the packet is inside the + perimeter, no further validations are performed on the packet. This + + + + +Nordmark, et al. Standards Track [Page 6] + +RFC 6620 FCFS SAVI May 2012 + + + model has implications both on how FCFS SAVI devices are deployed in + the topology and on the configuration of the FCFS 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. So, while packets coming + from interfaces connected to the external part of the topology need + to be validated by the FCFS SAVI device, packets coming from + interfaces connected to the internal part of the topology do not need + to be validated. This significantly reduces the processing + requirements of the FCFS SAVI device. It also implies that each FCFS + 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 FCFS + SAVI device binds the source address to a binding anchor. + + One possible approach would be for every FCFS SAVI device to store + binding information about every source address in the subnetwork. In + this case, every FCFS SAVI device would store a binding for each + source address of the local link. The problem with this approach is + that it imposes a significant memory burden on the FCFS SAVI devices. + In order to reduce the memory requirements imposed on each device, + the FCFS SAVI solution described in this specification distributes + the storage of FCFS SAVI binding information among the multiple FCFS + SAVI devices of a subnetwork. The FCFS SAVI binding state is + distributed across the FCFS SAVI devices according to the following + criterion: each FCFS SAVI device only stores binding information + about the source addresses bound to anchors corresponding to the + interfaces that connect to the part of the topology that is outside + of the FCFS SAVI protection perimeter. Since all the untrusted + packet sources are by definition in the external part of the + perimeter, packets generated by each of the untrusted sources will + reach the perimeter through an interface of an FCFS SAVI device. The + binding information for that particular source address will be stored + in the first FCFS SAVI device the packet reaches. + + The result is that the FCFS 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 different FCFS SAVI devices be coherent. In + particular, it is important to avoid having the same source address + bound to different binding anchors in different FCFS 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 FCFS SAVI is + trying to prevent. In order to preserve the coherency of the FCFS + SAVI bindings distributed among the FCFS SAVI devices within a realm, + the Neighbor Discovery (ND) protocol [RFC4861] is used, in particular + the Neighbor Solicitation (NS) and Neighbor Advertisement (NA) + + + +Nordmark, et al. Standards Track [Page 7] + +RFC 6620 FCFS SAVI May 2012 + + + messages. Following is a simplified example of how this might work. + Before creating an FCFS SAVI binding in the local FCFS SAVI database, + the FCFS SAVI device will send an NS message querying for the address + involved. Should any host reply to that message with an NA message, + the FCFS SAVI device that sent the NS will infer that a binding for + that address exists in another FCFS SAVI device and will not create a + local binding for it. If no NA message is received as a reply to the + NS, then the local FCFS SAVI device will infer that no binding for + that address exists in other FCFS SAVI device and will create the + local FCFS SAVI binding for that address. + + To summarize, the proposed FCFS SAVI approach relies on the following + design choices: + + o An FCFS SAVI provides perimetrical security, so some interfaces of + an FCFS 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 An FCFS SAVI device only verifies packets coming through an + interface connected to the untrusted part of the topology. + + o An FCFS SAVI device only stores binding information for the source + addresses that are bound to binding anchors that correspond to + interfaces that connect to the untrusted part of the topology. + + o An FCFS SAVI uses NS and NA messages to preserve the coherency of + the FCFS SAVI binding state distributed among the FCFS SAVI + devices within a realm. + + + + + + + + + + + + + + + + + + + + + + +Nordmark, et al. Standards Track [Page 8] + +RFC 6620 FCFS SAVI May 2012 + + + So, in a link that is constituted of multiple L2 devices, some of + which are FCFS SAVI capable and some of which are not, the FCFS-SAVI- + capable devices MUST be deployed forming a connected perimeter (i.e., + no data packet can get inside the perimeter without passing through + an FCFS SAVI device). Packets that cross the perimeter will be + validated while packets that do not cross the perimeter are not + validated (hence, FCFS SAVI protection is not provided for these + packets). Consider the deployment of FCFS SAVI in the topology + depicted in the following figure: + + +--------+ + +--+ +--+ +--+ | +--+ | + |H1| |H2| |H3| | |R1| | + +--+ +--+ +--+ | +--+ | + | | | | | | + +-------------SAVI-PROTECTION-PERIMETER------+ | | + | | | | | | + | +-1-----2-+ +-1-----2-+ | + | | SAVI1 | | SAVI2 | | + | +-3--4----+ +--3------+ | + | | | +--------------+ | | + | | +----------| |--------+ | + | | | SWITCH-A | | + | | +----------| |--------+ | + | | | +--------------+ | | + | +-1--2----+ +--1------+ | + | | SAVI3 | | SAVI4 | | + | +-3-----4-+ +----4----+ | + | | | | | + | +------SAVI-PROTECTION-PERIMETER---------------+ + | | | | | + | +--+| +--+ +---------+ + | |R2|| |H4| |SWITCH-B | + | +--+| +--+ +---------+ + +------+ | | + +--+ +--+ + |H5| |H6| + +--+ +--+ + + Figure 1: SAVI Protection Perimeter + + In Figure 1, the FCFS SAVI protection perimeter is provided by four + FCFS SAVI devices, namely SAVI1, SAVI2, SAVI3, and SAVI4. These + devices verify the source address and filter packets accordingly. + + FCFS SAVI devices then have two types of ports: Trusted Ports and + Validating Ports. + + + + +Nordmark, et al. Standards Track [Page 9] + +RFC 6620 FCFS SAVI May 2012 + + + o Validating Ports (VPs) are those in which FCFS SAVI processing is + performed. When a packet is received through one of the + Validating Ports, FCFS SAVI processing and filtering will be + executed. + + o Trusted Ports (TPs) are those in which FCFS SAVI processing is not + performed. So, packets received through Trusted Ports are not + validated, and no FCFS SAVI processing is performed on them. + + Trusted Ports are used for connections with trusted infrastructure, + including the communication between FCFS SAVI devices, the + communication with routers, and the communication of other switches + that, while not FCFS SAVI devices, only connect to trusted + infrastructure (i.e., other FCFS SAVI devices, routers, or other + trusted nodes). So, in Figure 1, Port 3 of SAVI1 and Port 1 of SAVI3 + are trusted because they connect two FCFS SAVI devices. Port 4 of + SAVI1, Port 3 of SAVI2, Port 2 of SAVI3, and Port 1 of SAVI4 are + trusted because they connect to SWITCH-A, to which only trusted nodes + are connected. In Figure 1, 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 FCFS + SAVI protection perimeter also are connected through Validating + Ports. 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 Figure 1, + Ports 1 and 2 of SAVI1, Port 1 of SAVI2, and 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 that is connected to hosts H5 and H6. + +2.6. Special Cases + + Multi-subnet links: In some cases, a given subnet may have several + prefixes. This is directly supported by SAVI as any port can support + multiple prefixes. Forwarding of packets between different prefixes + involving a router is even supported, as long as the router is + connected to a Trusted Port, as recommended for all the routers. + + Multihomed hosts: A multihomed host is a host with multiple + interfaces. The interaction between SAVI and multihomed hosts is as + follows. If the different interfaces of the host are assigned + different IP addresses and packets sent from each interface always + carry the address assigned to that interface as the source address, + then from the perspective of a SAVI device, this is equivalent to two + hosts with a single interface, each with an IP address. This is + + + +Nordmark, et al. Standards Track [Page 10] + +RFC 6620 FCFS SAVI May 2012 + + + supported by SAVI without the need for additional considerations. If + the different interfaces share the same IP address or if the + interfaces have different addresses but the host sends packets using + the address of one of the interfaces through any of the interfaces, + then SAVI does not directly support it. It would require either + connecting at least one interface of the multihomed host to a Trusted + Port or manually configuring the SAVI bindings to allow binding the + address of the multihomed host to multiple anchors simultaneously. + + Untrusted routers: One can envision scenarios where routers are + dynamically attached to an FCFS SAVI network. A typical example + would be a mobile phone connecting to an FCFS SAVI switch where the + mobile phone is acting as a router for other personal devices that + are accessing the network through it. In this case, the router does + not seem to directly fall in the category of trusted infrastructure + (if this was the case, it is likely that all devices would be + trusted); hence, it cannot be connected to a Trusted Port and if it + is connected to a Validating Port, the FCFS SAVI switch would discard + all the packets containing an off-link source address coming from + that device. As a result, the default recommendation specified in + this specification does not support such a scenario. + +3. FCFS SAVI Specification + +3.1. FCFS SAVI Data Structures + + The FCFS SAVI function relies on state information binding the source + address used in data packets to the binding anchor that contained the + first packet that used that source IP address. Such information is + stored in an FCFS SAVI database (DB). The FCFS SAVI DB will contain + a set of entries about the currently used IP source addresses. Each + entry will contain the following information: + + o IP source address + + o Binding anchor: port through which the packet was received + + o Lifetime + + o Status: either TENTATIVE, VALID, TESTING_VP, or TESTING_TP-LT + + o Creation time: the value of the local clock when the entry was + firstly created + + In addition, FCFS SAVI needs to know what prefixes are directly + connected, so it maintains a data structure called the FCFS SAVI + Prefix List, which contains: + + + + +Nordmark, et al. Standards Track [Page 11] + +RFC 6620 FCFS SAVI May 2012 + + + o Prefix + + o Interface where prefix is directly connected + +3.2. FCFS SAVI Algorithm + +3.2.1. Discovering On-Link Prefixes + + In order to distinguish local traffic from transit traffic, the FCFS + SAVI device relies on the FCFS SAVI Prefix List, which contains the + set of on-link IPv6 prefixes. An FCFS SAVI device MUST support the + following two methods for populating the Prefix List: manual + configuration and Router Advertisement, as detailed next. + + Manual configuration: An FCFS SAVI device MUST support manual + configuration of the on-link prefixes included in the Prefix List. + For example, this can be used when there are no prefixes being + advertised on the link. + + Router Advertisement: An FCFS SAVI device MUST support discovery of + on-link prefixes through Router Advertisement messages in Trusted + Ports. For Trusted Ports, the FCFS SAVI device will learn the on- + link prefixes following the procedure defined for a host to process + the Prefix Information options described in Section 6.3.4 of + [RFC4861] with the difference that the prefixes will be configured in + the FCFS SAVI Prefix List rather than in the ND Prefix List. In + addition, when the FCFS SAVI device boots, it MUST send a Router + Solicitation message as described in Section 6.3.7 of [RFC4861], + using the unspecified source address. + +3.2.2. Processing of Transit Traffic + + The FCFS SAVI function is located in a forwarding device, such as a + router or a Layer 2 switch. The following processing is performed + depending on the type of port through which the packet has been + received: + + o If the data packet is received through a Trusted Port, the data + packet is forwarded, and no SAVI processing performed on the + packet. + + o If the data packet is received through a Validating Port, then the + FCFS 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. + + + + +Nordmark, et al. Standards Track [Page 12] + +RFC 6620 FCFS SAVI May 2012 + + + * If the IP source address does not belong to one of the on-link + prefixes of the receiving interface, the data packet is transit + traffic, and the packet SHOULD be discarded. (If for some + reason, discarding the packets is not acceptable, logging or + triggering of alarms MAY be used). The FCFS SAVI function MAY + send an ICMP Destination Unreachable Error back to the source + address of the data packet, and 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 receiving port, then the FCFS SAVI + local traffic validation process is executed as described + below. + + * If the source address of the packet is an unspecified address, + the packet is forwarded, and no SAVI processing is performed + except for the case of the Neighbor Solicitation messages + involved in the Duplicate Address Detection, which are treated + as described in Section 3.2.3. + +3.2.3. Processing of Local Traffic + + We next describe how local traffic, including both control and data + packets, is processed by the FCFS SAVI device using a state machine + approach. + + The state machine described is for the binding of a given source IP + address (called IPAddr) in a given FCFS SAVI device. This means that + all the packets described as inputs in the state machine above refer + to that given IP address. In the case of data packets, the source + address of the packet is IPAddr. In the case of the DAD_NS packets, + the Target Address is IPAddr. The key attribute is the IP address. + The full state information is as follows: + + o IP ADDRESS: IPAddr + + o BINDING ANCHOR: P + + o LIFETIME: LT + + The possible states are as follows: + + o NO_BIND + + o TENTATIVE + + o VALID + + + + +Nordmark, et al. Standards Track [Page 13] + +RFC 6620 FCFS SAVI May 2012 + + + o TESTING_TP-LT + + o TESTING_VP + + We will use VP for Validating Port and TP for Trusted Port. + + After bootstrapping (when no binding exists), the state for all + source IP addresses is NO-BIND, i.e., there is no binding for the IP + address to any binding anchor. + + NO_BIND: The binding for a source IP address entry is in this state + when it does not have any binding to an anchor. All addresses are in + this state by default after bootstrapping, unless bindings were + created for them. + + TENTATIVE: The binding for a source address for which a data packet + or an NS generated by the Duplicate Address Detection (DAD) procedure + has been received is in this state during the waiting period during + which the DAD procedure is being executed (either by the host itself + or the FCFS SAVI device on its behalf). + + VALID: The binding for the source address is in this state after it + has been verified. It means that it is valid and usable for + filtering traffic. + + TESTING_TP-LT: A binding for a source address enters this state due + to one of two reasons: + + o When a Duplicate Address Detection Neighbor Solicitation has been + received through a Trusted Port. This implies that a host is + performing the DAD procedure for that source address in another + switch. This may be 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. + + o The lifetime of the binding entry is about to expire. This is due + to the fact that no packets have been seen by the FCFS 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 to determine if + the binding information should be discarded. + + TESTING_VP: A binding for a source address enters this state when a + Duplicate Address Detection Neighbor Solicitation or a data packet + has been received through a Validating Port other than the one + address to which it is currently bound. This implies that a host is + performing the DAD procedure for that source address through a + different port. This may be due to an attack, the fact that the host + + + +Nordmark, et al. Standards Track [Page 14] + +RFC 6620 FCFS SAVI May 2012 + + + may have moved, or just because another host tries to configure an + address already used. The binding in this state is then being tested + to determine which is the situation. + + Next, we describe how the different inputs are processed depending on + the state of the binding of the IP address (IPAddr). + + A simplified figure of the state machine is included in Figure 2 + below. + + NO_BIND + + o Upon the reception through a Validating Port (VP) of a Neighbor + Solicitation (NS) generated by the Duplicate Address Detection + (DAD) procedure (hereafter named DAD_NS) containing Target Address + IPAddr, the FCFS SAVI device MUST forward the NS, and T_WAIT + milliseconds later, it MUST send a copy of the same message. + These DAD_NS messages are not sent through any of the ports + configured as Validating Ports. The DAD_NS messages are sent + through the Trusted Ports (but, of course, subject to usual switch + behavior and possible Multicast Listener Discovery (MLD) snooping + optimizations). The state is moved to TENTATIVE. The LIFETIME is + set to TENT_LT (i.e., LT:=TENT_LT), the BINDING ANCHOR is set to + VP (i.e., P:=VP), and the Creation time is set to the current + value of the local clock. + + o Upon the reception through a Validating Port (VP) of a DATA packet + containing IPAddr as the source address, the SAVI device SHOULD + execute the process of sending Neighbor Solicitation 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 Neighbor + Solicitation messages for that address will be sent by the SAVI + device) and RetransTimer set to T_WAIT milliseconds (i.e., the + time between two Neighbor Solicitation messages is T_WAIT + milliseconds). The implications of not following the recommended + behavior are described in Appendix A. The DAD_NS messages are not + sent through any of the ports configured as Validating Ports. The + DAD_NSOL messages are sent through Trusted Ports (but, of course, + subject to usual switch behavior and possible MLD snooping + optimizations). The SAVI device MAY discard the data packets + while the DAD procedure is being executed, or it MAY store them + until the binding is created. In any case, it MUST NOT forward + the data packets until the binding has been verified. The state + is moved to TENTATIVE. The LIFETIME is set to TENT_LT (i.e., LT: + =TENT_LT), the BINDING ANCHOR is set to VP (i.e., P:=VP), and the + Creation time is set to the current value of the local clock. + + + + +Nordmark, et al. Standards Track [Page 15] + +RFC 6620 FCFS SAVI May 2012 + + + 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_NS packets containing IPAddr as the Target Address that are + received through a Trusted Port MUST NOT be forwarded through any + of the Validating Ports, but they are sent through the Trusted + Ports (but, of course, subject to usual switch behavior and + possible MLD snooping optimizations). + + o Neighbor Advertisement packets sent to all nodes as a reply to the + DAD_NS (hereafter called DAD_NA) 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 (if any) are forwarded. + + o If a Neighbor Advertisement (NA) is received through a Trusted + Port with the Target Address set to IPAddr, then the message is + forwarded through port P, the state is set to NO_BIND, and the + BINDING ANCHOR and the LIFETIME are cleared. Data packets stored + corresponding to this binding are discarded. + + o If an NA is received through a Validating Port with the Target + Address set to IPAddr, the NA packet is discarded + + o If a data packet with source address IPAddr is received with + binding anchor equal to P, then the packet is either stored or + discarded. + + o If a data packet with source address IPAddr is received through a + Trusted Port, the data packet is forwarded. The state is + unchanged. + + o If a data packet with source address IPAddr is received through a + Validating Port other than P, the data packet is discarded. + + o If a DAD_NS is received from a Trusted Port, with the Target + Address set to IPAddr, then the message is forwarded to the + Validating Port P, the state is set to NO_BIND, and the BINDING + ANCHOR and LIFETIME are cleared. Data packets stored + corresponding to this binding are discarded. + + + +Nordmark, et al. Standards Track [Page 16] + +RFC 6620 FCFS SAVI May 2012 + + + o If a DAD_NS with the Target Address set to IPAddr is received from + a Validating Port P' other than P, the message is forwarded to the + Validating Port P and to the Trusted Ports, and the state remains + in TENTATIVE; however, the BINDING ANCHOR is changed from P to P', + and LIFETIME is set to TENT_LT. Data packets stored corresponding + to the binding with P are discarded. + + o Other signaling packets are processed and forwarded as usual + (i.e., no SAVI processing). + + VALID + + o If a data packet containing IPAddr as the source address arrives + from Validating Port P, then the LIFETIME is set to DEFAULT_LT and + the packet is forwarded as usual. + + o If a DAD_NS is received from a Trusted Port, then the DAD_NS + message is forwarded to port P and is also forwarded to the + Trusted Ports (but, of course, subject to usual switch behavior + and possible MLD snooping optimizations). The state is changed to + TESTING_TP-LT. The LIFETIME is set to TENT_LT. + + o If a data packet containing source address IPAddr or a DAD_NA + packet with the 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_NS messages as described in Section + 5.4.2 of [RFC4862] for the IPAddr using the following default + parameters: DupAddrDetectTransmits set to 2 (i.e., two NS messages + for that address will be sent by the SAVI device) and RetransTimer + set to T_WAIT milliseconds (i.e., the time between two NS messages + is T_WAIT milliseconds). The DAD_NS message will be forwarded to + the port P. The state is moved to TESTING_VP. The LIFETIME is + set to TENT_LT. The SAVI device MAY discard the data packet while + the DAD procedure is being executed, or it MAY store them until + the binding is created. In any case, it MUST NOT forward the data + packets until the binding has been verified. + + o If a DAD_NS packet with the Target Address set to IPAddr is + received through a Validating Port P' other than P, then the SAVI + device will forward the DAD_NS packet, and T_WAIT milliseconds + later, it will execute the process of sending DAD_NS messages as + described in Section 5.4.2 of [RFC4862] for the IPAddr using the + following default parameters: DupAddrDetectTransmits set to 1 and + RetransTimer set to T_WAIT milliseconds. The DAD_NS messages will + be forwarded to the port P. The state is moved to TESTING_VP. + The LIFETIME is set to TENT_LT. The SAVI device MAY discard the + data packets while the DAD procedure is being executed, or it MAY + + + + +Nordmark, et al. Standards Track [Page 17] + +RFC 6620 FCFS SAVI May 2012 + + + store them until the binding is created. In any case, it MUST NOT + forward the data packets until the binding has been verified. + + o If the LIFETIME expires, then the SAVI device will execute the + process of sending DAD_NS messages as described in Section 5.4.2 + of [RFC4862] for the IPAddr using the following default + parameters: DupAddrDetectTransmits set to 2 (i.e., two NS messages + for that address will be sent by the SAVI device) and RetransTimer + set to T_WAIT milliseconds (i.e., the time between two NS messages + is T_WAIT milliseconds). The DAD_NS messages will be forwarded to + the port P. The state is changed to TESTING_TP-LT, 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 MAY be discarded. The event MAY be + logged. + + o Other signaling packets are processed and forwarded as usual + (i.e., no SAVI processing). In particular, a DAD_NA coming from + port P and containing IPAddr as the Target Address is forwarded as + usual. + + TESTING_TP-LT + + o If the LIFETIME expires, the BINDING ANCHOR is cleared, and the + state is changed to NO_BIND. + + o If an NA message containing the IPAddr as the Target Address is + received through the Validating Port P as a reply to the DAD_NS + message, then the NA 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. + + o If a DAD_NS is received from a Trusted Port, the DAD_NS is + forwarded as usual. + + o If a DAD_NS is received from a Validating Port P' other than P, + the DAD_NS is forwarded as usual, and the state is moved to + TESTING_VP. + + o If a data packet is received through a Validating Port P' that is + other than port P, then the packet is discarded. + + o If a data packet is received through a Trusted Port, then the + packet MAY be discarded. The event MAY be logged. + + + +Nordmark, et al. Standards Track [Page 18] + +RFC 6620 FCFS SAVI May 2012 + + + TESTING_VP + + o If the LIFETIME expires, the BINDING ANCHOR is modified from P to + P', the LIFETIME is set to DEFAULT_LT, and the state is changed to + VALID. Stored data packet coming from P' are forwarded. + + o If an NA message containing the IPAddr as the Target Address is + received through the Validating Port P as a reply to the DAD_NS + message, then the NA 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. + + o If a data packet containing IPAddr as the source address is + received through a Validating Port P'' that is other than port P + or P', then the packet is discarded. + + o If a data packet containing IPAddr as the source address is + received through a Trusted Port (i.e., other than port P), the + state is moved to TESTING_TP-LT, and the packet MAY be discarded. + + o If a DAD_NS is received through a Trusted Port, the packet is + forwarded as usual, and the state is moved to TESTING_TP-LT. + + o If a DAD_NS is received through Validating Port P'' other than P + or P', the packet is forwarded as usual, and P'' is stored as the + tentative port, i.e., P':=P''. The state remains the same. + + + + + + + + + + + + + + + + + + + + + + + +Nordmark, et al. Standards Track [Page 19] + +RFC 6620 FCFS SAVI May 2012 + + + +---------+ VP_NS, VP_DATA/2xNS +-----------+ + | |---------------------------------------->| | + | NO_BIND | | TENTATIVE | + | |<----------------------------------------| | + +---------+ TP_NA, TP_NS/- +-----------+ + ^ | + | | TimeOut + Timeout| | + | v + +---------+ VP_NA/- +-----------+ + | |---------------------------------------->| | + | TESTING | TP_NS/- | | + | TP-LT |<----------------------------------------| VALID | + | | TimeOut/2xNS | | + | |<----------------------------------------| | + +---------+ +-----------+ + ^ | ^ | + | | | | + | +--------------------- ---------------------+ | + | VP_NS/- | | NP_NA, TimeOut/- | + | v | | + | +-----------+ | + | | | | + +---------------------| TESTING |<----------------------+ + VP_NS, VP_DATA/- | VP | VP_DATA, VP_NS, + +-----------+ VP_NA/2xNS + + Figure 2: Simplified State Machine + + MLD Considerations + + The FCFS SAVI device MUST join the solicited node multicast group for + all the addresses with a state other than NO_BIND. This is needed to + make sure that the FCFS SAVI device will receive the DAD_NS for those + addresses. Please note that it may not be enough to rely on the host + behind the Validating Port to do 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 FCFS SAVI device. + Therefore, the FCFS SAVI device MUST join the solicited node + multicast groups for all the addresses that are in a state other than + NO_BIND. + + + + + + + + + + +Nordmark, et al. Standards Track [Page 20] + +RFC 6620 FCFS SAVI May 2012 + + +3.2.4. FCFS SAVI Port Configuration Guidelines + + The guidelines for port configuration in FCFS SAVI devices are as + follows: + + o The FCFS SAVI realm (i.e., the realm that is inside the FCFS SAVI + protection perimeter) MUST be connected. If this is not the case, + legitimate transit traffic may be dropped. + + o Ports that are connected to another FCFS SAVI device MUST be + configured as Trusted Ports. Not doing so will significantly + increase the memory consumption in the FCFS SAVI devices and may + result in legitimate transit traffic being dropped. + + 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 addresses. A valid exception is the + case of a trusted host (e.g., a server) that could be connected to + a Trusted Port, but untrusted hosts MUST be connected to + Validating Ports. + + o Ports connected to routers MUST be configured as Trusted Ports. + Configuring them as Validating Ports should result in transit + traffic being dropped. + + 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 addresses. A valid + exception is the case where the legacy switch only has trusted + hosts attached, in which case it could be connected to a Trusted + Port, but if there is at least one untrusted hosts connected to + the legacy switch, then it MUST be connected to Validating Ports. + + o Ports connected to a chain of one or more legacy switches that + have other FCFS SAVI devices and/or routers connected but had no + hosts attached to them MUST be configured as Trusted Ports. Not + doing so will at least significantly increase the memory + consumption in the FCFS SAVI devices, increase the signaling + traffic due to FCFS SAVI validation, and may result in legitimate + transit traffic being dropped. + + + + + + + + + + +Nordmark, et al. Standards Track [Page 21] + +RFC 6620 FCFS SAVI May 2012 + + +3.2.5. VLAN Support + + If the FCFS SAVI device is a switch that supports customer VLANs + [IEEE.802-1Q.2005], the FCFS SAVI implementation MUST behave as if + there was one FCFS SAVI process per customer VLAN. The FCFS SAVI + process of each customer VLAN will store the binding information + corresponding to the nodes attached to that particular customer VLAN. + +3.3. Default Protocol Values + + Following are the default values used in the FCFS SAVI specification. + + TENT_LT is 500 milliseconds + + DEFAULT_LT is 5 minutes + + T_WAIT is 250 milliseconds + + An implementation MAY allow these values to be modified, but tuning + them precisely is considered out of the scope of this document. + +4. Security Considerations + +4.1. Denial-of-Service Attacks + + There are two types of Denial-of-Service (DoS) attacks [RFC4732] that + can be envisaged in an FCFS SAVI environment. On one hand, we can + envision attacks against the FCFS SAVI device resources. On the + other hand, we can envision DoS attacks against the hosts connected + to the network where FCFS SAVI is running. + + The attacks against the FCFS SAVI device basically consist of making + the FCFS SAVI device consume its resources until it runs out of them. + For instance, a possible attack would be to send packets with + different source addresses, making the FCFS SAVI device create state + for each of the addresses and waste memory. At some point, the FCFS + SAVI device runs out of memory and needs to decide how to react. The + result is that some form of garbage collection is needed to prune the + entries. When the FCFS SAVI device runs out of the memory allocated + for the FCFS SAVI DB, it is RECOMMENDED that it create new entries by + deleting the entries with a higher Creation time. 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 addresses, 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 FCFS SAVI DB + + + +Nordmark, et al. Standards Track [Page 22] + +RFC 6620 FCFS SAVI May 2012 + + + with false source addresses, it needs to continuously send data + packets for all the different source addresses so that the entries + grow old and compete with the legitimate entries. The result is that + the cost of the attack is highly increased for the attacker. + + In addition, it is RECOMMENDED that an FCFS SAVI device reserves a + minimum amount of memory for each available port (in the case where + the port is used as part of the L2 anchor). The recommended minimum + is the memory needed to store four bindings associated with the port. + The motivation for this recommendation is as follows. An attacker + attached to a given port of an FCFS SAVI device may attempt to launch + a DoS attack towards the FCFS SAVI device by creating many bindings + for different addresses. It can do so by sending DAD_NS for + different addresses. The result is that the attack will consume all + the memory available in the FCFS SAVI device. The above + recommendation aims to reserve a minimum amount of memory per port, + so that hosts located in different ports can make use of the reserved + memory for their port even if a DoS attack is occurring in a + different port. + + As the FCFS SAVI device may store data packets while the address is + being verified, the memory for data packet storage may also be a + target of DoS attacks. The effects of such attacks may be limited to + the lack of capacity to store new data packets. The effect of such + attacks will be that data packets will be dropped during the + verification period. An FCFS SAVI device MUST limit the amount of + memory used to store data packets, allowing the other functions to + have available memory even in the case of attacks such those + described above. + + The FCFS SAVI device generates two DAD_NS packets upon the reception + of a DAD_NS or a data packet. As such, the FCFS SAVI device can be + used as an amplifier by attackers. In order to limit this type of + attack, the FCFS SAVI device MUST perform rate limiting of the + messages it generates. Rate limiting is performed on a per-port + basis, since having an attack on a given port should not prevent the + FCFS SAVI device from functioning normally in the rest of the ports. + +4.2. Residual Threats + + FCFS SAVI performs its function by binding an IP source address to a + binding anchor. If the attacker manages to send packets using the + binding anchor associated to a given IP address, FCFS SAVI validation + will be successful, and the FCFS SAVI device will allow the packet + through. This can be achieved by spoofing the binding anchor or by + sharing of the binding anchor between the legitimate owner of the + address and the attacker. An example of the latter is the case where + the binding anchor is a port of a switched network and a legacy + + + +Nordmark, et al. Standards Track [Page 23] + +RFC 6620 FCFS SAVI May 2012 + + + switch (i.e., not a SAVI-capable switch) is connected to that port. + All the source addresses of the hosts connected to the legacy switch + will share the same binding anchor (i.e., the switch port). This + means that hosts connected to the legacy switch can spoof each + other's IP address and will not be detected by the FCFS SAVI device. + This can be prevented by not sharing binding anchors among hosts. + + FCFS SAVI assumes that a host will be able to defend its address when + the DAD procedure is executed for its addresses. This is needed, + among other things, to support mobility within a link (i.e., to allow + a host to detach and reconnect to a different Layer 2 anchor of the + same IP subnetwork without changing its IP address). So, when a + DAD_NS is issued for a given IP address for which a binding exists in + an FCFS SAVI device, the FCFS SAVI device expects to see a DAD_NA + coming from the binding anchor associated to that IP address in order + to preserve the binding. If the FCFS SAVI device does not see the + DAD_NA, it may grant the binding to a different binding anchor. This + means that if an attacker manages to prevent a host from defending + its source address, it will be able to destroy the existing binding + and create a new one, with a different binding anchor. An attacker + may do so, for example, by intercepting the DAD_NA or launching a DoS + attack to the host that will prevent it from issuing proper DAD + replies. + + Even if routers are considered trusted, nothing can prevent a router + from being compromised and sending traffic with spoofed IP source + addresses. Such traffic would be allowed with the present FCFS SAVI + specification. A way to mitigate this issue could be to specify a + new port type (e.g., Router Port (RP)) that would act as Trusted Port + for the transit traffic and as Validating Port for the local traffic. + A detailed solution about this issue is outside the scope of this + document. + +4.3. Privacy Considerations + + Personally identifying information MUST NOT be included in the FCFS + SAVI DB with the MAC address as the canonical example, except when + there is an attack attempt involved. Moreover, compliant + implementations MUST NOT log binding anchor information except where + there is an identified reason why that information is likely to be + involved in detection, prevention, or tracing of actual source + address spoofing. Information that is not logged MUST be deleted as + soon as possible (i.e., as soon as the state for a given address is + back to NO_BIND). Information about the majority of hosts that never + spoof SHOULD NOT be logged. + + + + + + +Nordmark, et al. Standards Track [Page 24] + +RFC 6620 FCFS SAVI May 2012 + + +4.4. Interaction with Secure Neighbor Discovery + + Even if the FCFS SAVI could get information from ND messages secured + with Secure Neighbor Discovery (SEND) [RFC3971], in some case, the + FCFS SAVI device must spoof DAD_NS messages but doesn't know the + security credentials associated with the IPAddr (i.e., the private + key used to sign the DAD_NS messages). So, when SEND is deployed, it + is recommended to use SEND SAVI [SAVI-SEND] rather than FCFS SAVI. + +5. 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 + 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 + +6. Acknowledgments + + This document benefited from the input of the following individuals: + Joel Halpern, Christian Vogt, Dong Zhang, Frank Xia, Jean-Michel + Combes, Jari Arkko, Stephen Farrel, Dan Romascanu, Russ Housley, Pete + Resnick, Ralph Droms, Wesley Eddy, Dave Harrington, and Lin Tao. + + Marcelo Bagnulo is partly funded by Trilogy, a research project + supported by the European Commission under its Seventh Framework + Program. + + + + + + + + +Nordmark, et al. Standards Track [Page 25] + +RFC 6620 FCFS SAVI May 2012 + + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [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. + +7.2. Informative References + + [SAVI-FRAMEWORK] + Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, + "Source Address Validation Improvement Framework", Work + in Progress, December 2011. + + [SAVI-DHCP] Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for + DHCP", Work in Progress, February 2012. + + [SAVI-SEND] Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source- + Address Validation Implementation", Work in Progress, + March 2012. + + [RFC1958] Carpenter, B., "Architectural Principles of the + Internet", RFC 1958, June 1996. + + [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure + Neighbor Discovery (SEND)", RFC 3971, March 2005. + + [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- + Service Considerations", RFC 4732, December 2006. + + [IEEE.802-1D.1998] + Institute of Electrical and Electronics Engineers, "IEEE + Standard for Local and Metropolitan Area Networks Media + Access Control (MAC) Bridges", IEEE Standard 802.1D, + 1998. + + + + + +Nordmark, et al. Standards Track [Page 26] + +RFC 6620 FCFS SAVI May 2012 + + + [IEEE.802-1D.2004] + Institute of Electrical and Electronics Engineers, "IEEE + Standard for Local and Metropolitan Area Networks Media + Access Control (MAC) Bridges", IEEE Standard 802.1D, + 2004. + + [IEEE.802-1Q.2005] + Institute of Electrical and Electronics Engineers, "IEEE + Standard for Local and metropolitan area networks - + Virtual Bridged Local Area Networks", IEEE Standard + 802.1Q, May 2005. + + [IEEE.802-1X.2004] + Institute of Electrical and Electronics Engineers, "IEEE + Standard for Local and metropolitan area networks - Port- + Based Network Access Control", IEEE Standard 802.1X, + 2004. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Nordmark, et al. Standards Track [Page 27] + +RFC 6620 FCFS SAVI May 2012 + + +Appendix A. Implications of Not Following the Recommended Behavior + + This section qualifies some of the SHOULDs that are included in this + specification by explaining the implications of not following the + recommended behavior. We start by describing the implication of not + following the recommendation of generating DAD_NS upon the reception + of a data packet for which there is no binding, and then we describe + the implications of not discarding the non-compliant packets. + +A.1. Implications of Not Generating DAD_NS Packets upon the Reception + of Non-Compliant Data Packets + + This specification recommends that SAVI implementations generate a + DAD_NS message upon the reception of a data packet for which they + have no binding. In this section, we describe the implications of + not doing so and simply discarding the data packet instead. + + The main argument against discarding the data packet is the overall + robustness of the resulting network. The main concern that has been + stated is that a network running SAVI that discards data packets in + this case may end up disconnecting legitimate users from the network, + by filtering packets coming from them. The net result would be a + degraded robustness of the network as a whole, since legitimate users + would perceive this as a network failure. There are three different + causes that resulted in the lack of state in the binding device for a + legitimate address, namely, packet loss, state loss, and topology + change. We will next perform an analysis for each of them. + +A.1.1. Lack of Binding State due to Packet Loss + + The DAD procedure is inherently unreliable. It consists of sending + an NS packet, and if no NA packet is received back, success is + assumed, and the host starts using the address. In general, the lack + of response is because no other host has that particular address + configured in its interface, but it may also be the case that the NS + packet or the NA packet has been lost. From the perspective of the + sending host, there is no difference, and the host assumes that it + can use the address. In other words, the default action is to allow + the host to obtain network connectivity. + + It should be noted that the loss of a DAD packet has little impact on + the network performance, since address collision is very rare, and + the host assumes success in that case. By designing a SAVI solution + that would discard packets for which there is no binding, we are + diametrically changing the default behavior in this respect, since + the default would be that if the DAD packets are lost, then the node + is disconnected from the network (as its packets are filtered). What + is worse, the node has little clue of what is going wrong, since it + + + +Nordmark, et al. Standards Track [Page 28] + +RFC 6620 FCFS SAVI May 2012 + + + has successfully configured an address, but it has no connectivity. + The net result is that the overall reliability of the network has + significantly decreased as the loss of a single packet would imply + that a host is disconnected from the network. + + The only mechanism that the DAD has to improve its reliability is + sending multiple NSs. However, [RFC4862] defines a default value of + 1 NS message for the DAD procedure, so requiring any higher value + would imply manual configuration of all the hosts connected to the + SAVI domain. + +A.1.1.1. Why Initial Packets May Be (Frequently) Lost + + The Case of LANs + + Devices connecting to a network may experience periods of packet loss + after the link-layer becomes available for two reasons: Invalid + Authentication state and incomplete topology assessment. In both + cases, physical-layer connection occurs initially and presents a + medium where packets are transmissible, but frame forwarding is not + available across the LAN. + + For the authentication system, devices on a controlled port are + forced to complete 802.1X authentication, which may take multiple + round trips and many milliseconds to complete (see + [IEEE.802-1X.2004]). In this time, initial DHCP, IPv6 Neighbor + Discovery, Multicast Listener, or Duplicate Address Detection + messages may be transmitted. However, it has also been noted that + some devices have the ability for the IP stack to not see the port as + up until 802.1X has completed. Hence, that issue needs investigation + to determine how common it is now. + + Additionally, any system that requires user input at this stage can + extend the authentication time and thus the outage. This is + problematic where hosts relying upon DHCP for address configuration + time out. + + Upon completion of authentication, it is feasible to signal upper- + layer protocols as to LAN forwarding availability. This is not + typical today, so it is necessary to assume that protocols are not + aware of the preceding loss period. + + For environments that do not require authentication, addition of a + new link can cause loops where LAN frames are forwarded continually. + In order to prevent loops, all LANs today run a spanning tree + protocol, which selectively disables redundant ports. Devices that + perform spanning tree calculations are either traditional Spanning + Tree Protocol (STP) (see [IEEE.802-1D.1998]) or rapidly converging + + + +Nordmark, et al. Standards Track [Page 29] + +RFC 6620 FCFS SAVI May 2012 + + + versions of the same (Rapid Spanning Tree Protocol (RSTP) / Multiple + Spanning Tree Protocol (RSTP)) (see [IEEE.802-1D.2004] and + [IEEE.802-1Q.2005]). + + Until a port is determined to be an edge port (RSTP/MSTP), the rapid + protocol speaker has identified its position within the spanning tree + (RSTP/MSTP) or completed a Listening phase (STP), its packets are + discarded. + + For ports that are not connected to rapid protocol switches, it takes + a minimum of three seconds to perform edge port determination (see + [IEEE.802-1D.2004]). Alternatively, completion of the Listening + phase takes 15 seconds (see [IEEE.802-1D.1998]). During this period, + the link-layer appears available, but initial packet transmissions + into and out of this port will fail. + + It is possible to pre-assess ports as edge ports using manual + configuration of all the involved devices and thus make them + immediately transmissible. This is never default behavior though. + + The Case of Fixed Access Networks + + In fixed access networks such as DSL and cable, the end hosts are + usually connected to the access network through a residential gateway + (RG). If the host interface is initialized prior to the RG getting + authenticated and connected to the access network, the access network + is not aware of the DAD packets that the host sent out. As an + example, in DSL networks, the Access Node (Digital Subscriber Link + Access Multiplexer (DSLAM)) that needs to create and maintain binding + state will never see the DAD message that is required to create such + a state. + +A.1.1.1.1. Special Sub-Case: SAVI Device Rate-Limiting Packets + + A particular sub-case is the one where the SAVI device itself "drops" + ND packets. In order to protect itself against DoS attacks and + flash-crowds, the SAVI device will have to rate limit the processing + of packets triggering the state-creation process (which requires + processing from the SAVI device). This implies that the SAVI device + may not process all the ND packets if it is under heavy conditions. + The result is that the SAVI device will fail to create a binding for + a given DAD_NS packet, which implies that the data packets coming + from the host that sent the DAD_NS packet will be filtered if this + approach is adopted. The problem is that the host will assume that + the DAD procedure was successful and will not perform the DAD + procedure again, which in turn will imply that the host will be + disconnected from the network. While it is true that the SAVI device + will also have to rate limit the processing of the data packets, the + + + +Nordmark, et al. Standards Track [Page 30] + +RFC 6620 FCFS SAVI May 2012 + + + host will keep on sending data packets, so it is possible to recover + from the alternative approach where data packets trigger the binding- + creation procedure. + +A.1.2. Lack of Binding State due to a Change in the Topology + + If SAVI is deployed in a switched Ethernet network, topology changes + may result in a SAVI device receiving packets from a legitimate user + for which the SAVI device does not have a binding. Consider the + following example: + + +------+ +--------+ +---------------+ + |SAVI I|-------------|SWITCH I|-------|rest of the net| + +------+ +--------+ +---------------+ + | | + | +--------+ + | | SAVI II| + | +--------+ + | +----------+ | + +---|SWITCH II |-----+ + +----------+ + | + +-----+ + | Host| + +-----+ + + Figure 3: Topology Example + + Suppose that after bootstrapping, all the elements are working + properly and the spanning tree is rooted in the router and includes + one branch that follows the path SWITCH I - SAVI I - SWITCH II, and + another branch that follows SWITCH I-SAVI II. + + Suppose that the host boots at this moment and sends the DAD_NS. The + message is propagated through the spanning tree and is received by + SAVI I but not by SAVI II. SAVI I creates the binding. + + Suppose that SAVI I fails and the spanning tree reconverges to SWITCH + I - SAVI II - SWITCH II. Now, data packets coming from the host will + be coursed through SAVI II, which does not have binding state and + will drop the packets. + +A.1.3. Lack of Binding State due to State Loss + + The other reason a SAVI device may not have state for a legitimate + address is simply because it lost it. State can be lost due to a + reboot of the SAVI device or other reasons such as memory corruption. + So, the situation would be as follows. The host performs the DAD + + + +Nordmark, et al. Standards Track [Page 31] + +RFC 6620 FCFS SAVI May 2012 + + + procedure, and the SAVI device creates a binding for the host's + address. The host successfully communicates for a while. The SAVI + device reboots and loses the binding state. The packets coming from + the host are now discarded as there is no binding state for that + address. It should be noted that in this case, the host has been + able to use the address successfully for a certain period of time. + + Architecturally, the degradation of the network robustness in this + case can be easily explained by observing that this approach to SAVI + implementation breaks the fate-sharing principle. [RFC1958] reads: + + An end-to-end protocol design should not rely on the maintenance + of state (i.e. information about the state of the end-to-end + communication) inside the network. Such state should be + maintained only in the endpoints, in such a way that the state can + only be destroyed when the endpoint itself breaks (known as fate- + sharing). + + By binding the fate of the host's connectivity to the state in the + SAVI device, we are breaking this principle, and the result is + degraded network resilience. + + Moving on to more practical matters, we can dig deeper into the + actual behavior by considering two scenarios, namely, the case where + the host is directly connected to the SAVI device and the case where + there is an intermediate device between the two. + +A.1.3.1. The Case of a Host Directly Connected to the SAVI Device + + The considered scenario is depicted in the following diagram: + + +------+ +-----------+ +---------------+ + | Host |-------------|SAVI device|-------|rest of the net| + +------+ +-----------+ +---------------+ + + Figure 4: Host Attached Directly to SAVI Device + + The key distinguishing element of this scenario is that the host is + directly connected to the SAVI device. As a result, if the SAVI + device reboots, the host will see the carrier disappear and appear + again. + + + + + + + + + + +Nordmark, et al. Standards Track [Page 32] + +RFC 6620 FCFS SAVI May 2012 + + + [RFC4862] requires that the DAD procedure is performed when the IP + address is assigned to the interface (see [RFC4862], Section 5.4): + + Duplicate Address Detection: + + Duplicate Address Detection MUST be performed on all unicast + addresses prior to assigning them to an interface, regardless of + whether they are obtained through stateless autoconfiguration, + DHCPv6, or manual configuration, with the following exceptions: + ... + + However, it has been stated that some of the widely used OSs actually + do perform DAD each time the link is up, but further data would be + required for this to be taken for granted. Assuming that behavior, + this implies that if the loss of state in the SAVI device also + results in the link to the host going down, then the host using the + tested OSs would redo the DAD procedure allowing the recreation of + the binding state in the SAVI device and preserving the connectivity + of the host. This would be the case if the SAVI device reboots. It + should be noted, however, that it is also possible that the binding + state is lost because of an error in the SAVI process and that the + SAVI link does not goes down. In this case, the host would not redo + the DAD procedure. However, it has been pointed out that it would be + possible to require the SAVI process to flap the links of the device + it is running, in order to make sure that the link goes down each + time the SAVI process restarts and to improve the chances the host + will redo the DAD procedure when the SAVI process is rebooted. + +A.1.3.2. The Case of a Host Connected to the SAVI Device through One or + More Legacy Devices + + The considered scenario is depicted in the following diagram: + + +------+ +-------------+ +-----------+ +---------------+ + | Host |----|Legacy device|-----|SAVI device|----|rest of the net| + +------+ +-------------+ +-----------+ +---------------+ + + Figure 5: Host Attached to a Legacy Device + + The key distinguishing element of this scenario is that the host is + not directly connected to the SAVI device. As a result, if the SAVI + device reboots, the host will not see any changes. + + In this case, the host would get disconnected from the rest of the + network since the SAVI device would filter all its packets once the + state has gone. As the node will not perform the DAD procedure + again, it will remain disconnected until it reboots. + + + + +Nordmark, et al. Standards Track [Page 33] + +RFC 6620 FCFS SAVI May 2012 + + + As a final comment, it should be noted that it may not be obvious to + the network admin which scenario its network is running. Consider + the case of a campus network where all the switches in the network + are SAVI capable. A small hub connected in the office would turn + this into the scenario where the host is not directly connected to + the SAVI device. Moreover, consider the case of a host running + multiple virtual machines connected through a virtual hub. Depending + on the implementation of such a virtual hub, this may turn a directly + connected host scenario to the scenario where the multiple (virtual) + hosts are connected through a legacy (virtual) hub. + +A.1.3.2.1. Enforcing Direct Connectivity between the SAVI Device and + the Host + + It has been argued that enforcing direct connectivity between the + SAVI device and the end host is actually a benefit. There are + several comments that can be made in this respect: + + o First, it may well be the case in some scenarios that this is + desirable, but it is certainly not the case in most scenarios. + Because of that, the issue of enforcing direct connectivity must + be treated as orthogonal to how data packets for which there is no + binding are treated, since a general solution must support + directly connected nodes and nodes connected through legacy + switches. + + o Second, as a matter of fact, the resulting behavior described + above would not actually enforce direct connectivity between the + end host and the SAVI device as it would work as long as the SAVI + device does not reboot. So, the argument being made is that this + approach is not good enough to provide a robust network service, + but it is not bad enough to enforce the direct connectivity of the + host to the SAVI switch. + + o Third, it should be noted that topology enforcement is not part of + the SAVI problem space and that the SAVI problem by itself is + complex enough without adding additional requirements. + +A.2. Implications of Not Discarding Non-Compliant Data Packets + + The FCFS SAVI mechanism is composed of two main functions, namely, + the mechanisms for tracking compliant and non-compliant data packets + and the actions to be performed upon the detection of a non-compliant + packet. Throughout this specification, we recommend discarding non- + compliant data packets. This is because forwarding non-compliant + data packets is essentially allowing packets with spoofed source + addresses to flow throughout the network. However, there are + alternative actions that can be taken with respect to these packets. + + + +Nordmark, et al. Standards Track [Page 34] + +RFC 6620 FCFS SAVI May 2012 + + + For instance, it would be possible to forward the packets and trigger + an alarm to network administrators to make them aware of the + situation. Similarly, it would be possible to log these events and + allow the tracking down cases where packets with spoofed addresses + were used for malicious purposes. The reason a site deploying SAVI + may not want to take milder actions like the ones mentioned above + instead of discarding packets is because there may be cases where the + non-compliant packets may be legitimate packets (for example, in the + case that the SAVI device is malfunctioning and has failed to create + the appropriate bindings upon the reception of a DAD packet). + +Authors' Addresses + + Erik Nordmark + Cisco Systems + 510 McCarthy Blvd. + Milpitas, CA 95035 + United States + + EMail: nordmark@acm.org + + + 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. Standards Track [Page 35] + |