diff options
Diffstat (limited to 'doc/rfc/rfc7219.txt')
| -rw-r--r-- | doc/rfc/rfc7219.txt | 2131 |
1 files changed, 2131 insertions, 0 deletions
diff --git a/doc/rfc/rfc7219.txt b/doc/rfc/rfc7219.txt new file mode 100644 index 0000000..7a19e94 --- /dev/null +++ b/doc/rfc/rfc7219.txt @@ -0,0 +1,2131 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Bagnulo +Request for Comments: 7219 A. Garcia-Martinez +Category: Standards Track UC3M +ISSN: 2070-1721 May 2014 + + + SEcure Neighbor Discovery (SEND) + Source Address Validation Improvement (SAVI) + +Abstract + + This memo specifies SEcure Neighbor Discovery (SEND) Source Address + Validation Improvement (SAVI), a mechanism to provide source address + validation using the SEND protocol. The proposed mechanism + complements ingress filtering techniques to provide a finer + granularity on the control of IPv6 source addresses. + +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/rfc7219. + +Copyright Notice + + Copyright (c) 2014 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. + + + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 1] + +RFC 7219 SEND SAVI May 2014 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 2. Background on SEND SAVI . . . . . . . . . . . . . . . . . . . 4 + 2.1. Address Validation Scope . . . . . . . . . . . . . . . . 4 + 2.2. Binding Creation for SEND SAVI . . . . . . . . . . . . . 4 + 2.3. SEND SAVI Protection Perimeter . . . . . . . . . . . . . 7 + 2.4. Special Cases . . . . . . . . . . . . . . . . . . . . . . 9 + 3. SEND SAVI Specification . . . . . . . . . . . . . . . . . . . 11 + 3.1. SEND SAVI Data Structures . . . . . . . . . . . . . . . . 11 + 3.2. SEND SAVI Device Configuration . . . . . . . . . . . . . 12 + 3.3. Traffic Processing . . . . . . . . . . . . . . . . . . . 13 + 3.3.1. Transit Traffic Processing . . . . . . . . . . . . . 13 + 3.3.2. Local Traffic Processing . . . . . . . . . . . . . . 13 + 3.4. SEND SAVI Port Configuration Guidelines . . . . . . . . . 27 + 3.5. VLAN Support . . . . . . . . . . . . . . . . . . . . . . 28 + 3.6. Protocol Constants . . . . . . . . . . . . . . . . . . . 28 + 4. Protocol Walk-Through . . . . . . . . . . . . . . . . . . . . 29 + 4.1. Change of the Attachment Point of a Host . . . . . . . . 29 + 4.1.1. Moving to a Port of the Same Switch . . . . . . . . . 29 + 4.1.2. Moving to a Port of a Different Switch . . . . . . . 30 + 4.2. Attack of a Malicious Host . . . . . . . . . . . . . . . 31 + 4.2.1. M Attaches to the Same Switch as the Victim's Switch 31 + 4.2.2. M Attaches to a Different Switch to the Victim's + Switch . . . . . . . . . . . . . . . . . . . . . . . 32 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 33 + 5.1. Protection against Replay Attacks . . . . . . . . . . . . 33 + 5.2. Protection against Denial-of-Service Attacks . . . . . . 34 + 5.3. Considerations on the Deployment Model for Trust Anchors 36 + 5.4. Residual Threats . . . . . . . . . . . . . . . . . . . . 36 + 5.5. Privacy Considerations . . . . . . . . . . . . . . . . . 37 + 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 37 + 7.2. Informative References . . . . . . . . . . . . . . . . . 38 + + + + + + + + + + + + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 2] + +RFC 7219 SEND SAVI May 2014 + + +1. Introduction + + This memo specifies SEND SAVI, a mechanism to provide source address + validation for IPv6 networks using the SEND protocol [RFC3971]. The + proposed mechanism complements ingress filtering techniques to + provide a finer granularity on the control of the source addresses + used. + + SEND SAVI uses the DAD_NSOL (Duplicate Address Detection Neighbor + SOLicitation) and the DAD_NADV (DAD Neighbor ADVertisement) messages + defined in [RFC4862] and the NUD_NSOL (Neighbor Unreachability + Detection Neighbor SOLicitation) and NUD_NADV (NUD Neighbor + ADVertisement) messages defined in [RFC4861] to validate the address + ownership claim of a node. Using the information contained in these + messages, host IPv6 addresses are associated to switch ports, so that + data packets will be validated by checking for consistency in this + binding, as described in [RFC7039]. In addition, SEND SAVI prevents + hosts from generating packets containing off-link IPv6 source + addresses. + + Scalability of a distributed SAVI system comprising multiple SEND + SAVI devices is preserved by means of a deployment scenario in which + SEND SAVI devices form a "protection perimeter". In this deployment + scenario, the distributed SAVI system only validates the packets when + they ingress to the protection perimeter, not in every SEND SAVI + device traversed. + + The SEND SAVI specification, as defined in this document, is limited + to links and prefixes in which every IPv6 host and every IPv6 router + uses the SEND protocol [RFC3971] to protect the exchange of Neighbor + Discovery information. If the SEND protocol is not used, we can + deploy other SAVI solutions relying on monitoring different address + configuration mechanisms to prove address ownership. For example, + FCFS (First-Come, First-Served) SAVI [RFC6620] can be used by nodes + locally configuring IPv6 addresses by means of the Stateless Address + Autoconfiguration mechanism [RFC4862]. + + SEND SAVI is designed to be deployed in SEND networks with as few + changes to the deployed implementations as possible. In particular, + SEND SAVI does not require any changes in the nodes whose source + address is to be verified. This is because verification solely + relies in the usage of already available protocols. Therefore, SEND + SAVI neither defines a new protocol nor defines any new message on + existing protocols, nor does it require that a host or router use an + existing protocol message in a different way. + + An overview of the general framework about Source Address Validation + Improvement is presented in [RFC7039]. + + + +Bagnulo & Garcia-Martinez Standards Track [Page 3] + +RFC 7219 SEND SAVI May 2014 + + +1.1. Requirements Language + + 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 [RFC2119]. + +2. Background on SEND SAVI + +2.1. Address Validation Scope + + The application scenario of SEND SAVI is limited to the local link. + This means that the goal of SEND SAVI is to verify that the source + addresses of the packets generated by the nodes attached to the local + link have not been spoofed and that only legitimate routers generate + packets with off-link IPv6 source addresses. + + In a link, there usually are hosts and routers attached. Hosts + generate packets with their own addresses as the source address. + This is called "local traffic". Routers may send packets containing + a source address other than their own, since they can forward packets + generated by other hosts (usually located in a different link). This + is the so-called transit traffic. + + SEND SAVI allows the validation of the source address of the local + traffic, i.e., it allows verification that the source addresses of + the packets generated by the nodes attached to the local link have + not been spoofed. SEND SAVI also provides means to prevent hosts + from generating packets with source addresses derived from off-link + prefixes. However, SEND SAVI does not provide the means to verify if + a given router is actually authorized to forward packets containing a + particular off-link source address. Other techniques, like ingress + filtering [RFC2827], are recommended to validate transit traffic. + +2.2. Binding Creation for SEND SAVI + + SEND SAVI devices filter packets according to bindings between a + layer-2 anchor (the binding anchor) and an IPv6 address. These + bindings should allow legitimate nodes to use the bounded IPv6 + address as source address and prevent illegitimate nodes from doing + so. + + 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 SEND + SAVI device is configured to drop non-compliant packets, then the + usage of SEND SAVI may open a new vector of Denial-of-Service (DoS) + + + +Bagnulo & Garcia-Martinez Standards Track [Page 4] + +RFC 7219 SEND SAVI May 2014 + + + attacks, based on spoofed binding anchors. For that reason, + implementations of this specification use switch ports as their + 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. + + SEND [RFC3971] provides tools to assure that a Neighbor Discovery + (ND) message containing a Cryptographically Generated Address (CGA) + [RFC3972] option and signed by an RSA option has been generated by + the legitimate owner of the CGA IPv6 address. + + SEND SAVI uses SEND-validated messages to create bindings between the + CGA and the port of the SEND SAVI device from which it is reasonable + to receive packets with the CGA as the source address. The events + that trigger the binding creation process in a SEND SAVI device are: + + o The reception of a DAD_NSOL message, indicating the attempt of a + node to configure an address. This may occur when a node + configures an address for the first time or after being idle for + some time or when the node has changed the physical attachment + point to the layer-2 infrastructure. + + o The reception of any other packet (including data packets) with a + source address for which no binding exists. This may occur if + DAD_NSOL messages were lost, a node has changed the physical + attachment point to the layer-2 infrastructure without issuing a + DAD_NSOL message, a SAVI device loses a binding (for example, due + to a restart), or the link topology changed. + + When the binding creation process is triggered, the SEND SAVI device + has to assure that the node for which the binding is to be created is + the legitimate owner of the address. For the case in which the + binding creation process is initiated by a DAD_NSOL exchange, the + SEND SAVI device waits for the reception of a validated DAD_NADV + message, indicating that the other node has configured the address + before, or validated DAD_NSOL messages arriving from other locations, + indicating that another node is trying to configure the same address + at the same time. For the case in which packets other than a + DAD_NSOL initiate the creation of the binding, the SEND SAVI device + explicitly requires the node sending those packets to prove address + ownership by issuing a secured NUD_NSOL, which has to be answered + with a secured NUD_NADV by the probed node. + + SEND SAVI devices issue secured NUD_NSOL messages periodically in + order to refresh bindings, which have to be answered with a valid + NUD_NADV message by the node for which the binding exists. + + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 5] + +RFC 7219 SEND SAVI May 2014 + + + SEND SAVI devices only forward packets with off-link source addresses + if they are received from a port manually configured to connect to a + router. + + SEND SAVI needs to be protected against replay attacks, i.e., attacks + in which a secured SEND message is replayed by another node. As + discussed before, the SEND SAVI specification uses SEND messages to + create a binding between the address contained in the message (that + must be signed by a node possessing the private key associated to the + address) and the port through which the message is received. If an + attacker manages to obtain such a message from another node, for + example, because the message was sent to the all-nodes multicast + address or because the attacker has subscribed to the Solicited Node + multicast address associated to a remote node, it could replay it + preserving the original signature. This may create an illegitimate + binding in the SEND SAVI device or could be used to abort address + configuration at the other node. While SEND provides some means to + limit the impact of the replay of ND messages, the emphasis for SEND + anti-replay protection is to limit to a short period of time the + validity of the ND information transmitted in the message, for + example, the relationship between an IPv6 address and a layer-2 + address. Note that the period must be long enough to assure that the + information sent by the legitimate sender is considered valid despite + the possible differences in clock synchronization between the sender + and receiver(s). For example, with the values recommended by + [RFC3971] for TIMESTAMP_FUZZ and TIMESTAMP_DRIFT, a node receiving a + DAD_NSOL message would not discard replays of this message being + received within a period of approximately 2 seconds (more precisely, + 2/0.99 seconds). The underlying assumption for SEND security is that + even if the message is replayed by another node during this period of + time, the information disseminated by ND is still the same. However, + allowing a node to replay a SEND message does have an impact on the + SEND SAVI operation, regardless of the time elapsed since it was + generated, since the node can create a new binding in a SEND SAVI + device for the port to which an illegitimate node attaches. As can + be concluded, the protection provided by SEND is not enough in all + cases for SEND SAVI. + + SEND SAVI increases the protection against the replay attacks + compared to SEND. First, each node is required to connect to the + SEND SAVI topology through a different port to prevent eavesdropping + before entering the SAVI protection perimeter. Then, SEND SAVI + bindings are updated only according to messages whose dissemination + can be restricted in the SEND SAVI topology without interfering with + the normal SEND operation. The messages used by SEND SAVI to create + bindings are DAD_NSOL messages, for which SEND SAVI limits its + propagation to the ports through which a previous binding for the + same IPv6 address existed (see Section 3.3.2), and NUD_NADV messages + + + +Bagnulo & Garcia-Martinez Standards Track [Page 6] + +RFC 7219 SEND SAVI May 2014 + + + in response to a secured NUD_NSOL sent by the SEND SAVI device only + through the tested port. Finally, SEND SAVI filtering rules prevent + nodes from replaying messages generated by the SEND SAVI devices + themselves. Section 5.1 discusses in more detail the protection + provided by SEND SAVI against replay attacks. + +2.3. SEND SAVI Protection Perimeter + + In order to reduce computing and state requirements in SEND SAVI + devices, SEND SAVI devices can be deployed to form a "protection + perimeter" [RFC7039]. With this deployment strategy, SEND SAVI + devices perform source-address validation only when packets enter in + the protected realm defined through the protection perimeter. The + perimeter is defined by appropriate configuration of the roles of + each port, which can be 'Validating' or 'Trusted': + + o Validating ports (VPs) are ports in which SEND SAVI filtering and + binding creation are performed. + + o Trusted ports (TPs) are ports in which limited processing is + performed. Only SEND messages related with certificates, prefix + information, and DAD operation are processed in order to update + the state of the SEND SAVI device or the state related with any of + the Validating ports of the switch. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 7] + +RFC 7219 SEND SAVI May 2014 + + + Figure 1 shows a typical topology involving trusted and untrusted + infrastructure. + + +--+ +--+ +--+ +--+ + |H1| |H2| |H3| |R1| + +--+ +--+ +--+ +--+ + | | | | + +------------SEND SAVI PROTECTION PERIMETER-----------+ + | | | | | | + | +-1-----2-+ +-1-----2-+ | + | | SEND- | | SEND- | | + | | SAVI1 | | SAVI2 | | + | +-3--4----+ +--3--4---+ | + | | | +--------------+ | | | + | | +----------| |--------+ | | + | | | SWITCH-A | | | + | | +----------| | | | + | | | +--------------+ | | + | +-1--2----+ +-----1---+ | + | | SEND- | | SEND- | | + | | SAVI3 | | SAVI4 | | + | +-3-----4-+ +----4----+ | + | | | | | + +------------SEND SAVI PROTECTION PERIMETER-----------+ + | | | + +--+ +--+ +--+ + |R2| |H4| |H5| + +--+ +--+ +--+ + + + + Figure 1: SAVI Protection Perimeter + + Trusted ports are used for connections with trusted infrastructures, + such as routers and other SEND SAVI devices. Port 2 of SEND-SAVI2 + and port 3 of SEND-SAVI3 are Validating ports because they connect to + routers. Port 3 of SEND-SAVI1 and port 1 of SEND-SAVI3 as well as + port 4 of SEND-SAVI2 and port 1 of SEND-SAVI4 are trusted because + they connect two SAVI devices. Finally, port 4 of SEND-SAVI1, port 3 + of SEND-SAVI2, and port 2 of SEND-SAVI3 are trusted because they + connect to SWITCH-A to which only trusted nodes are connected. + + Validating ports are used for connection with non-trusted + infrastructures; therefore, hosts connect normally to Validating + ports. So, in Figure 1 above, ports 1 and 2 of SEND-SAVI1, port 1 of + SEND-SAVI2, and port 4 of SEND-SAVI3 are Validating ports because + they connect to hosts. Port 4 of SEND-SAVI4 is also a Validating + port because it is connected to host H5. + + + +Bagnulo & Garcia-Martinez Standards Track [Page 8] + +RFC 7219 SEND SAVI May 2014 + + + For a more detailed discussion on this, see Section 3.4. + +2.4. Special Cases + + Multi-subnet links: In some cases, a given subnet may have several + prefixes. This is supported by SEND SAVI as any port can support + multiple prefixes. + + Multihomed hosts: A multihomed host is a host with multiple + interfaces. The interaction between SEND 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 and always carry the address assigned to that interface + as the source address, then from the perspective of a SEND SAVI + device, this is equivalent to two hosts with a single interface, + each with an IP address. SEND SAVI supports this without + 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 SEND 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 SEND SAVI bindings to allow binding the address of + the multihomed host to multiple anchors simultaneously. + + Virtual switches: A hypervisor or a host operating system may + perform bridging functions between virtual hosts running on the + same machine. The hypervisor or host OS may in turn connect to a + SEND SAVI system. This scenario is depicted in Figure 2, with two + virtual machines, VM1 and VM2, connected through a virtual switch, + VS1, to SEND SAVI device SEND-SAVI1. The attachment points of VS1 + to VM1 and VM2 are configured as Validating. + + + + + + + + + + + + + + + + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 9] + +RFC 7219 SEND SAVI May 2014 + + + Host1 + +----------------+ + | +---+ +---+ | + | |VM1| |VM2| | + | +---+ +---+ | + | | | | + | +-1-----2--+ | + | | VS1 | | + | +--3-------+ | + | | | + +----|-----------+ + | + | + +--1-----2--+ + | SEND- | + | SAVI1 | + +--3---4----+ + | | + + Figure 2: Virtual Switches Connected to the SEND SAVI Device + + In order to provide proper security against replay attacks, + performing SEND SAVI filtering as close to untrusted hosts as + possible (see Sections 3.4 and 5.1) is recommended. In this + scenario, this objective can be achieved by enabling SEND SAVI + validation in VS1. Ideally, VS1 could be integrated into the SEND + SAVI protection perimeter if the hypervisor or host OS at Host1 can + be trusted (even though VM1 and VM2 could not be trusted). To do so, + both the attachment to SEND-SAVI1 at VS1, and port 1 at SEND-SAVI1, + are configured as Trusted. + + If the administrator of the network does not trust VS1, port 1 of + SEND-SAVI1 is configured as Validating, so that every address being + used at Host1 is validated at SEND-SAVI1 by SEND SAVI. The + attachment point to the physical network at VS1 should be configured + as Trusted if the host administrator knows that it is connected to a + SEND SAVI device; in this case, VS1 relies on the infrastructure + comprised by the physical SEND SAVI devices but not vice versa. + Packets egressing from VM1 are validated twice: first at VS1 and then + at SEND-SAVI1. Packets going in the reverse direction (from an + external host to VM1) are validated once: when they first reach a + SEND SAVI device. If the administrator of VS1 does not trust the + physical switch to which it attaches, it can configure the attachment + to SEND-SAVI1 as Validating. In Figure 2 above, this means that a + packet going from another host to VM1 would be validated twice: once + when entering the SEND SAVI perimeter formed by the physical devices + and again when entering at VS1. + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 10] + +RFC 7219 SEND SAVI May 2014 + + + Untrusted routers: One can envision scenarios where routers are + dynamically attached to a SEND SAVI network. A typical example would + be a mobile phone connecting to a SEND SAVI switch where the mobile + phone is acting as a router for other personal devices that are + accessing the network through it. Regarding the validation of the + source address performed in a SEND SAVI device, such an untrusted + 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 SEND SAVI switch + would discard all the packets containing an off-link source address + coming from that device. Although the SEND SAVI device to which this + router attaches could be configured to permit the transit of packets + with source addresses belonging to the set of prefixes reachable + through the untrusted router, such a mechanism is out of the scope of + this document. As a result, the default mechanism described in this + specification cannot be applied in such a scenario. + +3. SEND SAVI Specification + +3.1. SEND SAVI Data Structures + + The following three data structures are defined for SEND SAVI + operations. + + SEND SAVI Database: The SEND SAVI function relies on state + information binding the source IPv6 address used in data packets to + the port through which the legitimate node connects. Such + information is stored in the SEND SAVI Database. The SEND SAVI + Database is populated with the contents of validated SEND messages. + Each entry contains the following information: + + o IPv6 source address + + o Binding anchor: the port through which the packet was received + + o Lifetime + + o Status: TENTATIVE_DAD, TENTATIVE_NUD, VALID, TESTING_VP, + TESTING_VP' + + o Alternative binding anchor: the port from which a DAD_NSOL message + or any data packet has been received while a different port was + stored in the binding anchor for the address. + + o Creation time: the value of the local clock when the entry was + first created + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 11] + +RFC 7219 SEND SAVI May 2014 + + + SEND SAVI Prefix List: SEND SAVI devices need to know which ones are + the link prefixes in order to identify local and off-link traffic. A + SEND SAVI device MUST support discovering this information from the + Prefix Information option [RFC4861] with the L bit set of Router + Advertisement (RADV) messages coming from Trusted ports, as described + in Section 3.3.2. The list of prefixes MAY also be configured + manually. This information is not specific to a given port. The + SEND SAVI Prefix List contains one entry per prefix in use, as + follows: + + o Prefix: the prefix included in a Prefix Information option. + + o Prefix lifetime: time in seconds that the prefix is valid. + Initially set to the Valid Lifetime value of the Prefix + Information option of a valid RADV message or set to a value of + all 1 bits (0xffffffff), which represents infinity, if configured + manually. + + When the SEND SAVI device boots, it MUST send a Router Solicitation + (RSOL) message, which does not need to be secured if the unspecified + address is used (see [RFC3971], Sections 5.1.1 and 5.2.1). The SAVI + device SHOULD issue a RSOL message in case the prefix entry is about + to expire. + +3.2. SEND SAVI Device Configuration + + In order to perform the SEND SAVI operation, some basic parameters of + the SEND SAVI device have to be configured. Since a SEND SAVI device + operates as a SEND node to generate NUD_NSOL, RSOL, or Certification + Path Solicitation (CPS) messages: + + o The SEND SAVI device MUST be configured with a valid CGA address. + When the SEND SAVI device configures this address, it MUST behave + as a regular SEND node, i.e., using secured NSOL messages to + perform DAD, etc., in addition to fulfilling the requirements + stated for regular IPv6 nodes [RFC6434]. + + o The SEND SAVI device MAY be configured with at least one trust + anchor if it is configured to validate RADV messages (see + Section 3.3.2). In this case, the SEND SAVI device MAY be + configured with certification paths. The alternative is obtaining + them by means of issuing Certification Path Solicitation messages, + as detailed in the SEND specification [RFC3971]. + + In addition, the port role for each port of the SEND SAVI device MUST + be configured. The guidelines for this configuration are specified + in Section 3.4. + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 12] + +RFC 7219 SEND SAVI May 2014 + + +3.3. Traffic Processing + + In this section, we describe how packets are processed by a SEND SAVI + device. Behavior varies depending on if the packet belongs to local + or transit traffic. This is determined by checking if the prefix of + the source address is included in the SEND SAVI Prefix List or in the + unspecified address (local traffic) or not included in the SEND SAVI + Prefix List (transit traffic). + +3.3.1. Transit Traffic Processing + + Transit traffic processing occurs as follows: + + o If the SEND SAVI device receives a transit traffic packet through + a Trusted port, it forwards it without any SAVI processing. + + o If the SEND SAVI device receives a transit traffic packet through + a Validating port, it discards the packet. + +3.3.2. Local Traffic Processing + + If the verification of the source address of a packet shows that it + belongs to local traffic, this packet is processed using the state + machine described in this section. + + For the rest of the section, the following assumptions hold: + + o When it is stated that a secured NUD_NSOL message is issued by a + SEND SAVI device through a port P, it means that the SEND SAVI + device generates a NUD_NSOL message, according to the Neighbor + Unreachability Detection procedure described in [RFC4861], + addressed to the IPv6 target address, which is the source address + of the packet triggering the procedure. This message is secured + by SEND as defined in [RFC3971]. The source address used for + issuing the NUD_NSOL message is the source address of the SEND + SAVI device. The message is sent only through port P. + + o When it is stated that a validated NUD_NADV message is received by + a SEND SAVI device, it means that a SEND secured NUD_NADV message + has been received by the same port P through which the + corresponding NUD_NSOL message was issued, and the NUD_NADV + message has been validated according to [RFC3971] to prove + ownership for the IPv6 address under consideration and to prove + that it is a response for the previous NUD_NSOL message issued by + the SEND SAVI device (containing the same nonce value as the + NUD_NSOL message to which it answers). + + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 13] + +RFC 7219 SEND SAVI May 2014 + + + We use VP to refer to a Validating port and TP to refer to a Trusted + port. + + The state machine is defined for a binding of a given source IPv6 + address in a given SEND SAVI device. In the transitions considered, + packets described as inputs refer to the IPaddr IPv6 address + associated to the state machine. + + The possible states for a given IPaddr are NO_BIND, TENTATIVE_DAD, + TENTATIVE_NUD, VALID, TESTING_VP, and TESTING_VP'. The NO_BIND state + represents that no binding exists for IPaddr; this is the state for + all addresses unless a binding is explicitly created. + + The states can be classified into 'forwarding' states, i.e., states + in which packets received from the port associated to the IPv6 + address are forwarded, and 'non-forwarding' states, i.e., states in + which packets different to the ones used for signaling are not + forwarded. VALID, TENTATIVE_DAD, TESTING_VP, and TESTING_VP' are + forwarding states, and NO_BIND and TENTATIVE_NUD are non-forwarding + states. + + The SEND SAVI device MUST join the Solicited Node Multicast group for + all the addresses whose state is other than NO_BIND. This is needed + to make sure that the SEND SAVI device receives DAD_NSOL messages + issued for those addresses. Note that it may not be enough to relay + on the Multicast Listener Discovery (MLD) messages being sent by the + node attached to a Validating port for which a binding for the + corresponding address exists, since the node may move and packets + sent to that particular Solicited Node Multicast group may no longer + be forwarded to the SEND SAVI device. + + In order to determine which traffic is on-link and off-link, the SEND + SAVI device MUST support discovery of this information from the + Prefix Information option with the L bit set of RADV messages. In + this case, at least one router SHOULD be configured to advertise RADV + messages containing a Prefix Information option with the prefixes + that the untrusted nodes can use as source addresses, and the bit L + set. An alternative to this is to manually configure the SEND SAVI + Prefix List or restrict the use of link-local addresses. + + SEND SAVI devices MUST discard RADV messages received from Validating + ports. RADV messages are only accepted and processed when received + through Trusted ports. + + SEND SAVI devices SHOULD NOT validate RADV messages to update the + SEND SAVI Prefix List and forward them to other nodes. These + messages can only be received from Trusted ports, and we assume that + routers are trusted. Validating RADV messages would be required in + + + +Bagnulo & Garcia-Martinez Standards Track [Page 14] + +RFC 7219 SEND SAVI May 2014 + + + any SEND SAVI device the node is traversing. Besides, hosts will + validate this message before using the information it contains. + + In case SEND SAVI devices are configured to validate RADV messages, + SEND SAVI devices SHOULD support the processing of validated + Certification Path Advertisement (CPA) messages, sent in reply to CPS + messages, to acquire certificates used to validate router messages; + alternatively, it SHOULD be configured with a certification path. + + The state machine defined for the SEND SAVI operation adheres to the + following design guidelines: + + o The only events that trigger state changes from forwarding to non- + forwarding states, and vice versa, are the reception of DAD_NSOL, + DAD_NADV, and NUD_NADV or the expiration of a timer. The other + possible input to consider is 'any other packet', which could + generate changes to states belonging to the same forwarding or + non-forwarding class as the original state. In other words, when + 'any other packet' is received, the state cannot move from + forwarding to non-forwarding, and vice versa. The reduced set of + messages being able to trigger a change simplifies the processing + at SEND SAVI devices. + + o DAD_NADV and NUD_NADV are only processed when they are a response + to a DAD_NSOL or a NUD_NSOL message. + + o SEND SAVI devices MUST only use ND messages received through + Validating ports if they are valid; otherwise, they discard them. + SEND SAVI devices SHOULD assume that such messages received from + Trusted ports have been validated by other SEND SAVI devices, or + come from a trusted device such a router, so they SHOULD NOT + attempt to validate them in order to reduce the processing load at + the SEND SAVI device. + + o The only messages the SEND SAVI device is required to generate + specifically per each source IP address are MLD and NUD_NSOL + messages. This also keeps the state machine simple. + + o Well-behaved nodes are expected to initiate communication by + sending secured DAD_NSOL messages. The SEND SAVI state machine is + tailored to efficiently process these events. The reception of + other packet types without receiving previously validated DAD_NSOL + messages is assumed to be a consequence of bad-behaving nodes or + infrequent events (such as packet loss, a change in the topology + connecting the switches, etc.). While a binding will ultimately + be created for nodes affected by such events, simplicity of the + state machine is prioritized over any possible optimization for + these cases. + + + +Bagnulo & Garcia-Martinez Standards Track [Page 15] + +RFC 7219 SEND SAVI May 2014 + + + o If a node has a configured address, and it can prove that it owns + this address, the binding is preserved regardless of any + indication that a binding for the same source address could be + configured in other SEND SAVI devices. Bindings for the same + source address in two or more SEND SAVI devices may occur due to + several reasons, for example, when a host moves (the two bindings + exist just for a short period of time) or when many nodes generate + the same address and the DAD procedure has failed. In these + infrequent cases, SEND SAVI preserves connectivity for the + resulting bindings. + + Next, we describe how different inputs are processed, depending on + the state of the binding of the IP address 'IPaddr'. Note that every + ND message is assumed to be validated according to the SEND + specification. + + To facilitate the reader's understanding of the most relevant + transitions of the SEND SAVI state machine, a simplified version, + which does not contain every possible transition, is depicted in + Figure 3: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 16] + +RFC 7219 SEND SAVI May 2014 + + + +-------------+ + | | + | TESTING_VP' | + | | + +-------------+ + Timeout/VP=VP' | ^ + | | + VP_NUD_NADV/- | | VP'_DAD_NSOL/ + | | VP_NUD_NSOL + | | + v | + VP_DAD_NSOL/- +--------+ + +------------- | | + | | VALID |< -------------------+ + | +-------- >| | | + | | +--------+ | + | | ^ | | + | | VP_NUD_ | | Timeout, | + | | NADV/- | | TP_DAD_NSOL/VP_NUD_NSOL| + | | | v | + | | +------------+ | + | | | | | + | | | TESTING_VP | | + | | | | | + | | +------------+ | + | | | | + | | | Timeout/- | + | | VP*, | | + | | Timeout/- | VP_NUD_NADV/- | + v | | | + +---------------+ | +---------------+ + | | | | | + | TENTATIVE_DAD | | | TENTATIVE_NUD | + | | | | | + +---------------+ | +---------------+ + ^ | | | ^ + | | | Timeout/- | | + | | TP_DAD_NSOL, | | | + | | TP_DAD_NADV/- | | | + | | v | | + | | +---------+ | | + | +--------- >| |< -----+ | + | | NO_BIND | | + +--------------| |-----------------+ + VP_DAD_NSOL/- +---------+ VP*/VP_NUD_NSOL + + Figure 3: Simplified SEND SAVI State Machine + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 17] + +RFC 7219 SEND SAVI May 2014 + + + Each state transition is characterized by any of the events that may + trigger the change and the message(s) generated as a result of this + change. The meaning of some terms are referred next: + + o VP_DAD_NSOL as a triggering event means that a validated DAD_NSOL + message has been received from the current BINDING_ANCHOR port VP. + + o VP* means any packet (data packet) received from the current + BINDING_ANCHOR port VP. + + o TP_DAD_NSOL as a triggering event means that a DAD_NSOL message + was received from a Trusted port. + + o - means that no message is sent. VP=VP' means that the + BINDING_ANCHOR is set to VP'. + + The notation + + Timeout, TP_DAD_NSOL/VP_NUD_NSOL + + means that the transition is triggered by either a timeout expiration + or the reception of a DAD_NSOL message from a Trusted port, and in + addition to the transition, a NUD_NSOL message is sent through port + VP. + + For the rest of the description, we assume the following: + + o When a validated message is required (i.e., a 'validated + DAD_NSOL'), messages are check for validity in the considered + switch according to [RFC3971], and messages not fulfilling these + conditions are discarded. + + o When any SEND message is received from a validated port, the SEND + SAVI SHOULD assume that the message has been validated by the SEND + SAVI device through which the message accessed the SEND SAVI + protection perimeter (unless the SEND SAVI perimeter has been + breached), or the device generating it is trusted. In this case, + the SAVI device does not perform any further validation. + Performing validation for SEND messages received through a Trusted + port may affect performance negatively. + + + + + + + + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 18] + +RFC 7219 SEND SAVI May 2014 + + + NO_BIND + + When the node is in this state, there are no unresolved NUD_NSOL + messages generated by SEND SAVI or DAD_NSOL propagated to any + Validating port, so the only relevant inputs are DAD_NSOL messages + coming either from a Validating port (VP) or Trusted port (TP), or + any packet other than DAD_NSOL coming from a VP or TP. There are no + timers configured for this state. + + Messages received from a Validating port: + + o If a validated DAD_NSOL message is received from a Validating port + VP, the SEND SAVI device forwards this message to all appropriate + Trusted ports (the subset of Trusted ports that belong to the + forwarding layer-2 topology, with the restrictions imposed by the + MLD snooping mechanism, if applied). DAD_NSOL messages are not + sent through any of the ports configured as Validating ports. The + SEND SAVI device sets the LIFETIME to TENT_LT, stores all the + information required for future validation of the corresponding + DAD_NADV message (such as the nonce of the message), creates a new + entry in the SEND SAVI Database for IPaddr, sets BINDING_ANCHOR to + VP, and changes the state to TENTATIVE_DAD. Creation time is set + to the current value of the local clock. + + Note that in this case, it is not possible to check address + ownership by sending a NUD_NSOL because while the node is waiting + for a possible DAD_NADV, its address is in tentative state and the + node cannot respond to NSOL messages [RFC4862]. + + o If any packet other than a DAD_NSOL is received through a + Validating port VP, the SEND SAVI device issues a secured NUD_NSOL + through port VP. The SEND SAVI device sets the LIFETIME to + TENT_LT. The SEND SAVI device creates a new entry in the SEND + SAVI Database for IPaddr, sets BINDING_ANCHOR to VP, and the state + is changed to TENTATIVE_NUD. Creation time is set to the current + value of the local clock. The SAVI device MAY discard the packet + while the NUD procedure is being executed or MAY store it in order + to send it if the next transitions are (strictly) TENTATIVE_NUD + and then VALID. + + Messages received from a Trusted port: + + o If a DAD_NSOL message containing IPaddr as the target address is + received through a Trusted port, it MUST NOT be forwarded through + any of the Validating ports: it is sent through the proper Trusted + ports. The state is not changed. + + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 19] + +RFC 7219 SEND SAVI May 2014 + + + o Any packet other than a DAD_NSOL received from a Trusted port is + forwarded to its destination. This packet is assumed to come from + a SEND SAVI device that has securely validated the binding, + according to the SEND SAVI rules (unless the SEND SAVI perimeter + has been breached). The state is not changed. + + TENTATIVE_DAD + + To arrive at this state, the SEND SAVI device has received a + validated DAD_NSOL coming from the BINDING_ANCHOR port, and it has + forwarded it to the appropriate TPs. The relevant events occurring + in this state are the reception of a DAD_NADV message from a TP, a + DAD_NSOL message from the BINDING_ANCHOR port, other Validating port + or TP, a data packet from the BINDING_ANCHOR port, and the expiration + of the LIFETIME timer initiated when the DAD_NSOL was received at the + BINDING_ANCHOR port. + + Messages received from a Trusted port: + + o The reception of a valid DAD_NADV message from a Trusted port + indicates that the binding cannot be configured for the + BINDING_ANCHOR port. The state is changed to NO_BIND, and the + LIFETIME is cleared. + + o The reception of a valid DAD_NSOL from a Trusted port indicates + that a node connected to another SEND SAVI device may be trying to + configure the same address at the same time. The DAD_NSOL message + is forwarded to the BINDING_ANCHOR port, so that the node at this + port will not configure the address, as stated in [RFC4862]. The + DAD_NSOL message is also forwarded to all appropriate Trusted + ports. Then, the LIFETIME is cleared, and the state is changed to + NO_BIND. + + o Any packet other than a validated DAD_NSOL or DAD_NADV received + from a Trusted port is forwarded to its destination. This packet + is assumed to come from a SEND SAVI device that has securely + validated the binding, according to the SEND SAVI rules (unless + the SEND SAVI perimeter has been breached). The state is not + changed. + + + + + + + + + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 20] + +RFC 7219 SEND SAVI May 2014 + + + Messages received from a Validating port different from the + BINDING_ANCHOR: + + o A validated DAD_NSOL is received from a Validating port VP' + different from the BINDING_ANCHOR port. The reception of a valid + DAD_NSOL from port VP' indicates that a node connected to VP' may + be trying to configure the same address at the same time. The + DAD_NSOL message is forwarded to the BINDING_ANCHOR port, so that + the node at this port will not configure the address, as stated in + [RFC4862]. The DAD_NSOL message is also forwarded to all + appropriate Trusted ports. Then, the BINDING_ANCHOR is set to VP' + (through which the DAD_NSOL message was received), the LIFETIME is + set to TENT_LT, and the state remains in TENTATIVE_DAD. + + o Any packet other than a validated DAD_NSOL received from a + Validating port VP' different from the BINDING_ANCHOR port is + discarded. The state is not changed. + + Messages received from the BINDING_ANCHOR port: + + o If a validated DAD_NSOL is received from the BINDING_ANCHOR port, + the LIFETIME is set to TENT_LT, and the state remains in + TENTATIVE_DAD. + + o If any packet other than a DAD_NSOL is received from the + BINDING_ANCHOR port, it is assumed that the node has configured + its address, although it has done it in less time than expected by + the SEND SAVI device (less than TENT_LT). Since the node proved + address ownership by means of the validated DAD_NSOL message, the + LIFETIME is set to DEFAULT_LT, and the state is changed to VALID. + + LIFETIME expires: + + o If LIFETIME expires, it is assumed that no other node has + configured this address. Therefore, the Validating port VP + (currently stored in the BINDING_ANCHOR) could be bound to this + IPv6 address. The LIFETIME is set to DEFAULT_LT, and the state is + changed to VALID. + + VALID + + To arrive at this state, the SEND SAVI device has successfully + validated address ownership and has created a binding for IPaddr. + Relevant transitions for this state are triggered by the reception of + DAD_NSOL from the BINDING_ANCHOR port, other Validating port or a TP, + and any packet other than DAD_NSOL from a Validating port other than + + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 21] + +RFC 7219 SEND SAVI May 2014 + + + the BINDING_ANCHOR or a TP. The expiration of LIFETIME is also + relevant to trigger a check for address ownership for the node at the + BINDING_ANCHOR port. + + Messages received from the BINDING_ANCHOR port: + + o If a validated DAD_NSOL with IPaddr as a source address is + received through the BINDING_ANCHOR port, it is forwarded to the + appropriate Trusted ports. The LIFETIME is set to TENT_LT, and + the state is changed to TENTATIVE_DAD. + + o Any packet other than a DAD_NSOL containing IPaddr as a source + address arriving from the BINDING_ANCHOR port is forwarded + appropriately. The state is not changed. + + Messages received from a Trusted port: + + o If a DAD_NSOL with IPaddr as a source address is received through + a Trusted port, the message is forwarded to VP. The LIFETIME is + set to TENT_LT, a secured NUD_NSOL message is sent to IPaddr + through VP, and the state is changed to TESTING_VP. + + o If any packet other than a DAD_NSOL with IPaddr as a source + address is received through a Trusted port, the packet is + forwarded to VP and to other appropriate Trusted ports. A secured + NUD_NSOL is sent to the BINDING_ANCHOR port, the LIFETIME is set + to TENT_LT, and the state is changed to TESTING_VP. + + Messages received from a Validating port different from the + BINDING_ANCHOR: + + o If a validated DAD_NSOL packet with IPaddr as a source address is + received through a Validating port VP' (a VP' different from the + current BINDING ANCHOR), the message is forwarded to the + BINDING_ANCHOR port. In addition, a secured NUD_NSOL is sent to + the BINDING_ANCHOR port, the ALTERNATIVE BINDING ANCHOR is set to + port VP' (for future use if the node at VP' is finally selected), + the LIFETIME is set to TENT_LT, and the state is changed to + TESTING_VP'. + + o If any packet other than a DAD_NSOL with IPaddr as a source + address is received from a Validating port VP', different from the + current BINDING_ANCHOR for this binding, VP, the packet is + discarded. The SEND SAVI device MAY issue a secured NUD_NSOL + through the BINDING_ANCHOR port, store VP' in the ALTERNATIVE + BINDING ANCHOR for possible future use, set the LIFETIME to + TENT_LT, and change the state to TESTING_VP'. An alternative to + this behavior is that the SEND SAVI device MAY not do anything (in + + + +Bagnulo & Garcia-Martinez Standards Track [Page 22] + +RFC 7219 SEND SAVI May 2014 + + + this case, the state would eventually change after a maximum + DEFAULT_LT time; if the node at VP does not respond to a NUD_NSOL + at TESTING_VP, the state is moved to NO_BIND). Then, a packet + arriving from VP' would trigger a process that may end up with + binding for the node connecting to VP'. + + LIFETIME expires: + + o If LIFETIME expires, a secured NUD_NSOL message is sent through + the BINDING_ANCHOR port to IPaddr, the LIFETIME is set to TENT_LT, + and the state is changed to TESTING_VP. In the TESTING_VP state, + packets are still being forwarded until the timer expires without + receiving a NUD_NADV. + + TESTING_VP + + When the SEND SAVI device enters the TESTING_VP state, the current + Validating port is under check through a secured NUD_NSOL message + generated by the SEND SAVI device. While testing, packets from the + current Validating port are forwarded. Packets coming from Trusted + ports are also forwarded. The relevant events for this state are the + reception of a NUD_NADV message from VP; the reception of a DAD_NSOL + message from VP, VP', or TP; the reception of any packet other than + the previous cases from VP, VP', or TP; and the expiration of the + timer associated to the reception of NUD_NADV. + + Messages received from the BINDING_ANCHOR port: + + o If a validated NUD_NADV is received from VP, the LIFETIME is + changed to DEFAULT_LT, and the state is changed to VALID. The + message is not forwarded to any other port. + + o If a validated DAD_NSOL message is received from VP, it is + forwarded to the appropriate Trusted ports, the LIFETIME is set to + DEFAULT_LT, and the state is changed to TENTATIVE_DAD. + + o Any packet other than DAD_NSOL or NUD_NADV containing IPaddr as a + source address arriving from the BINDING_ANCHOR port is forwarded. + Neither the LIFETIME nor the state are changed. + + Messages received from a Trusted port: + + o If a DAD_NSOL packet is received from a Trusted port, the message + is forwarded to VP and the appropriate Trusted ports. Neither the + LIFETIME nor the state are changed. The node at the + BINDING_ANCHOR port is under check; if it still is at this port, + it should answer with a NUD_NADV and also with a DAD_NADV. If it + is not there, neither the NUD_NADV nor the DAD_NADV will be + + + +Bagnulo & Garcia-Martinez Standards Track [Page 23] + +RFC 7219 SEND SAVI May 2014 + + + received, the timer will expire, and the local state will move to + NO_BIND. + + o If a packet other than a DAD_NSOL arrives from a Trusted port, the + packet is forwarded. Neither the LIFETIME nor the state are + changed. + + Messages received from a Validating port different from the + BINDING_ANCHOR: + + o If a valid DAD_NSOL is received from a Validating port VP' other + than the current BINDING_ANCHOR port, the message is forwarded to + the BINDING_ANCHOR port and to the appropriate Trusted ports. In + addition, a secured NUD_NSOL is sent to the BINDING_ANCHOR port, + the ALTERNATIVE BINDING ANCHOR is set to VP' (for future use if + the node at VP' is finally selected), the LIFETIME is set to + TENT_LT, and the state is changed to TESTING_VP'. + + o Any other packet received from a Validating port VP' other than + the BINDING_ANCHOR port is discarded. This may occur because the + node has moved but has not issued a DAD_NSOL or the DAD_NSOL + message has been lost. The state will eventually move to NO_BIND, + and then the packets sent from VP' will trigger the creation of + the binding for VP'. + + LIFETIME expires: + + o If the LIFETIME expires, the LIFETIME is cleared and the state is + changed to NO_BIND. + + TESTING_VP' + + To arrive at this state, the SEND SAVI device has received an + indication that a node at VP' different from the BINDING_ANCHOR port + wants to send data with IPaddr as a source address and has occurred + while a binding existed for VP. The port VP' that triggered the + change of the state to TESTING_VP' was stored at the + ALTERNATIVE_BINDING_ANCHOR, so that it can be retrieved if the node + at VP' is determined as the legitimate owner of IPaddr. The SEND + SAVI device has issued a NUD_NSOL to IPaddr through the + BINDING_ANCHOR port. The relevant events that may occur in this case + are the reception of a NUD_NADV from port VP (the BINDING_ANCHOR + port); the reception of a DAD_NSOL from VP, VP', TP, and VP" (VP" + different from VP and VP'); the reception of any other packet from + VP, VP', TP, or VP"; and the expiration of the timer. + + + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 24] + +RFC 7219 SEND SAVI May 2014 + + + Messages received from the BINDING_ANCHOR port: + + o A validated NUD_NADV is received from the BINDING_ANCHOR port. + The reception of a valid NUD_NADV indicates that the node at VP is + defending its address. The BINDING_ANCHOR in use is kept, the + LIFETIME is set to DEFAULT_LT, and the state is changed to VALID. + + o If a valid DAD_NSOL is received from the BINDING_ANCHOR port, it + is forwarded to VP' (the port stored in the + ALTERNATIVE_BINDING_ANCHOR). The BINDING_ANCHOR in use is kept, + the LIFETIME is set to TENT_LT, and the state is changed to + TENTATIVE_DAD. When the DAD_NSOL message is received by the node + at VP', the address will not be configured. + + o Any packet other than a validated DAD_NSOL, or a validated + NUD_NADV coming from the BINDING_ANCHOR port, is forwarded, and + the state is not changed. + + Messages received from the ALTERNATIVE_BINDING_ANCHOR Validating + port: + + o If a valid DAD_NSOL is received from the port stored in the + ALTERNATIVE_BINDING_ANCHOR, it is forwarded to the BINDING_ANCHOR + port. The BINDING_ANCHOR and the ALTERNATIVE BINDING ANCHOR are + kept, the LIFETIME is set to DEFAULT_LT, and the state is not + changed. + + o Any packet other than a validated DAD_NSOL coming from the + ALTERNATIVE_BINDING_ANCHOR port is discarded, and the state is not + changed. + + Messages received from a Validating port different from the + BINDING_ANCHOR and the ALTERNATIVE_BINDING_ANCHOR ports: + + o If a validated DAD_NSOL is received from port VP", different from + BINDING_ANCHOR and the ALTERNATIVE_BINDING_ANCHOR ports, it is + forwarded to the BINDING_ANCHOR and the ALTERNATIVE_BINDING_ANCHOR + ports. The node at the ALTERNATIVE BINDING ANCHOR port is + expected to unconfigure its address if the message triggering the + transition to this state was a DAD_NSOL message received from the + ALTERNATIVE_BINDING_ANCHOR port (and not any other packet). The + state remains in TESTING_VP', although VP" is stored in the + ALTERNATIVE_BINDING_ANCHOR for future use if the node at VP" is + finally selected. The LIFETIME is not changed. + + o Any packet other than a validated DAD_NSOL received from port VP" + is discarded and does not affect the state. + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 25] + +RFC 7219 SEND SAVI May 2014 + + + Messages received from a Trusted port: + + o If a DAD_NSOL is received from a Trusted port, the message is + forwarded to the BINDING_ANCHOR, ALTERNATIVE_BINDING_ANCHOR ports, + and other appropriate Trusted ports. The LIFETIME is left + unchanged, and the state is changed to TESTING_VP. The node at + the ALTERNATIVE_BINDING_ANCHOR port is expected to unconfigure its + address if the packet triggering the transition to this state was + a DAD_NSOL message received from the ALTERNATIVE_BINDING_ANCHOR + port. + + o Any packet other than a DAD_NSOL coming from a Trusted port is + forwarded appropriately, but the state is not changed. + + LIFETIME expires: + + o If LIFETIME expires, it is assumed that the node for which the + binding existed is no longer connected through the BINDING_ANCHOR + port. Therefore, the BINDING_ANCHOR is set to the + ALTERNATIVE_BINDING_ANCHOR port value. The LIFETIME is set to + DEFAULT_LT, and the state is changed to VALID. + + TENTATIVE_NUD + + To arrive at this state, a data packet has been received through the + BINDING_ANCHOR port without any existing binding in the SEND SAVI + device. The SEND SAVI device has sent a NUD_NSOL message to the + BINDING_ANCHOR port. The relevant events for this case are the + reception of a NUD_NADV from the BINDING_ANCHOR port; the reception + of a DAD_NSOL from the BINDING_ANCHOR port, other VP different from + the BINDING_ANCHOR port, or a TP; and the reception of any packet + other than a DAD_NSOL and a NUD_NADV from the BINDING_ANCHOR port and + a DAD_NSOL for other VP different from the BINDING_ANCHOR port, or + TP. In addition, the LIFETIME may expire. + + Messages received from the BINDING_ANCHOR port: + + o If a validated NUD_NADV message is received through the + BINDING_ANCHOR port, the LIFETIME is set to TENT_LT, and the state + is changed to VALID. The message is not forwarded to any port. + + o If a validated DAD_NSOL message is received through the + BINDING_ANCHOR port, it is forwarded to the appropriate Trusted + ports, the LIFETIME is set to TENT_LT, and the state is changed to + TENTATIVE_DAD. + + o Any packet other than NUD_NADV or DAD_NSOL received through the + BINDING_ANCHOR port is discarded. + + + +Bagnulo & Garcia-Martinez Standards Track [Page 26] + +RFC 7219 SEND SAVI May 2014 + + + Messages received from a Validating port different from the + BINDING_ANCHOR: + + o If a validated DAD_NSOL message is received through port VP' + different from the BINDING_ANCHOR port, it is forwarded to the + appropriate Trusted ports, the LIFETIME is set to TENT_LT, the + BINDING_ANCHOR is set to VP', and the state is changed to + TENTATIVE_DAD. + + o Any packet other than validated DAD_NSOL received through port VP' + MUST NOT be forwarded unless the next state for the binding is + VALID. The packets received MAY be discarded or MAY be stored to + be sent if the state changes later to VALID. The state is left + unchanged. + + Messages received from a Trusted port: + + o If a DAD_NSOL message is received through a Trusted port, it is + forwarded to the BINDING_ANCHOR port, and the state is left + unchanged. + + o Any other packet received from a Trusted port is forwarded + appropriately. This packet may come from a SEND SAVI device that + has securely validated the attachment of the node to its + Validating port, according to SEND SAVI rules. The state is left + unchanged. + + LIFETIME expires: + + o If LIFETIME expires, the LIFETIME is cleared and the state is + changed to NO_BIND. + +3.4. SEND SAVI Port Configuration Guidelines + + The detailed guidelines for port configuration in SEND SAVI devices + are: + + o Ports connected to another SEND SAVI device MUST be configured as + Trusted ports. Not doing so will prevent off-link traffic from + being forwarded, along with the following effects for on-link + traffic: significantly increase the CPU time, memory consumption, + and signaling traffic due to SEND SAVI validation, in both the + SEND SAVI devices and the node whose address is being validated. + + 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 a spoofed source address. + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 27] + +RFC 7219 SEND SAVI May 2014 + + + o No more than one host SHOULD be connected to each port. + Connecting more than one host to a port will allow hosts to + generate packets with the same source address as the other hosts + connected to the same port, and will allow replaying attacks to be + performed as described in Section 5.1. + + o Ports connected to routers MUST be configured as Trusted ports. + Not doing so results in SEND SAVI devices discarding off-link + traffic. Note that this means that since routers are connected + through Trusted ports, they can generate traffic with any source + address, even those belonging to the link. + + o Ports connected to a chain of one or more legacy switches that + have other SEND SAVI devices but have no routers or hosts attached + to them SHOULD be configured as Trusted ports. Not doing so will + significantly increase the memory consumption in the SEND SAVI + devices and increase the signaling traffic due to SEND SAVI + validation. + +3.5. VLAN Support + + In the case where the SEND SAVI device is a switch that supports + customer VLANs [IEEE.802-1Q.2005], the SEND SAVI specification MUST + behave as if there was one SEND SAVI process per customer VLAN. The + SEND SAVI process of each customer VLAN will store the binding + information corresponding to the nodes attached to that particular + customer VLAN. + +3.6. Protocol Constants + + TENT_LT is 500 milliseconds. + + DEFAULT_LT is 5 minutes. + + + + + + + + + + + + + + + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 28] + +RFC 7219 SEND SAVI May 2014 + + +4. Protocol Walk-Through + + In this section, we include two cases that illustrate the behavior of + SEND SAVI, the change of the attachment port of a host, and the + attack of a malicious host. We use the topology depicted in + Figure 4. + +---+ + | H | + +---+ + | + | + +-1-----2-+ +-1-----2-+ + | | | | + | SAVI1 | | SAVI2 | + | | | | + +-3-----4-+ +-3-----4-+ + | | + ------------------- + + Figure 4: Reference SEND SAVI Topology for Protocol Walk-Through + +4.1. Change of the Attachment Point of a Host + + There are two cases, depending on whether the host H moves to a + different port on the same switch or to a different switch. + +4.1.1. Moving to a Port of the Same Switch + + Host H is connected to port 1 of SAVI1 and moves to port 2 of the + same switch. Before moving, the SEND SAVI state associated to IPH, + the IP address of H, is: + + SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND + + In the general case, H issues a DAD_NSOL message for IPH when it is + connected to a different port. When SAVI1 receives this message, it + validates it and changes its state to: + + SAVI1=TESTING_VP', BINDING_ANCHOR=1, ALTERNATIVE_BINDING_ANCHOR=2, + TIMER=TENT_LT / SAVI2=NO_BIND + + The DAD_NSOL message is propagated to port 1, because it is the + current BINDING_ANCHOR, and the Trusted port 3; it is not propagated + to Validating port 4. SAVI1 configures a timer for TENT_LT seconds. + In addition, SAVI1 generates a NUD_NSOL and sends it through port 1. + When SAVI2 receives this message through its Trusted port, it + discards it and remains in the NO_BIND state. + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 29] + +RFC 7219 SEND SAVI May 2014 + + + SAVI1 waits for a NUD_NADV message to be received from port 1. Since + there is no node attached to 1, there is no response for either of + these messages. When TENT_LT expires at SAVI1, the state changes to: + + SAVI1=VALID, BINDING_ANCHOR=2 / SAVI2=NO_BIND + + If the node moving does not issue a DAD_NSOL when it attaches to port + 2, then SAVI1 will receive a data packet through this port. The data + packet is discarded, SAVI1 issues a secured NUD_NSOL through port 1, + and the state changes to TESTING_VP'. + + SAVI1=TESTING_VP', BINDING_ANCHOR=1, ALTERNATIVE_BINDING_ANCHOR=2 + TIMER=TENT_LT / SAVI2=NO_BIND + + SAVI1 waits for a NUD_NADV message to be received from port 1. Since + there is no node attached to 1, there is no response for neither of + these messages. When TENT_LT expires at SAVI1, the state changes to: + + SAVI1=VALID, BINDING_ANCHOR=2 / SAVI2=NO_BIND + + An alternative behavior allowed by the specification for the case in + which the host does not issue a DAD_NSOL is that SAVI1 does nothing. + In this case, after some time (bounded by DEFAULT_LT), the switch + will change the state for IPH to TESTING_VP, check if H is still at + port 1 (which it is not), and move the state to NO_BIND. Then, a + packet arriving from port 2 would trigger a process that finishes + with a VALID stated with BINDING_ANCHOR=2. + +4.1.2. Moving to a Port of a Different Switch + + Host H, connected to port 1 of SAVI1, moves to port 4 of SAVI2. + Before moving, the SEND SAVI state associated to IPH, the IP address + of H, is: + + SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND + + If H issues a DAD_NSOL message for IPH when it connects to port 4 of + SAVI2, the state is changed to: + + SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=TENTATIVE_DAD, + BINDING_ANCHOR=4, TIMER=TENT_LT + + The DAD_NSOL message is propagated only through the Trusted port of + SAVI2. Then, SAVI1 changes its state as follows: + + SAVI1=TESTING_VP, BINDING_ANCHOR=1, TIMER=TENT_LT / + SAVI2=TENTATIVE_DAD, BINDING_ANCHOR=4, TIMER=TENT_LT + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 30] + +RFC 7219 SEND SAVI May 2014 + + + SAVI1 propagates the DAD_NSOL message to port 1. Since the only node + that can answer with a secured DAD_NUD has moved, the timer at SAVI2 + expires, and SAVI2 changes its state to VALID: + + SAVI1=TESTING_VP, BINDING_ANCHOR=1, TIMER=TENT_LT / SAVI2=VALID, + BINDING_ANCHOR=4 + + Just a very short time after, the timer at SAVI1 expires, and the + state changes to NO_BIND: + + SAVI1=NO_BIND / SAVI2=VALID, BINDING_ANCHOR=4 + + If host H does not send a DAD_NSOL when it moves to SAVI2 but instead + sends a data packet, SAVI2 changes its state to TENTATIVE_NUD: + + SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=TENTATIVE_NUD, + BINDING_ANCHOR=4, TIMER=TENT_LT + + SAVI2 issues a secured NUD_NSOL through port 4. H is assumed to have + the address configured (otherwise, it should not have generated a + data packet), so it can respond with a NUD_NADV. When SAVI1 receives + the NUD_NADV and validates it, the state is changed to VALID: + + SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=VALID, BINDING_ANCHOR=4 + + After some time (bounded by DEFAULT_LT), the state in SAVI1 will + expire, and SAVI1 will perform a check for host H: + + SAVI1=TESTING_VP, BINDING_ANCHOR=1, TIMER=TENT_LT / SAVI2=VALID, + BINDING_ANCHOR=4 + + SAVI1 issues a NUD_NSOL through port 1 for IPH. No response is + received in this case, so SAVI1 changes its state to NO_BIND: + + SAVI1=NO_BIND / SAVI2=VALID, BINDING_ANCHOR=4 + +4.2. Attack of a Malicious Host + + Host H is attached to the SEND SAVI infrastructure through port 1 of + SAVI1. We consider that host M starts sending data packets using IPH + (the IP address of H) as the source address, without issuing a + DAD_NSOL (a similar analysis can be done for this case). + +4.2.1. M Attaches to the Same Switch as the Victim's Switch + + The initial state before the attack of M is: + + SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND + + + +Bagnulo & Garcia-Martinez Standards Track [Page 31] + +RFC 7219 SEND SAVI May 2014 + + + M attaches to port 2 of SAVI1 and starts sending data packets. When + SAVI1 receives the data packet, the packet is discarded. SEND SAVI + may issue a secured NUD_NSOL through port 1 and changes the state to: + + SAVI1=TESTING_VP', BINDING_ANCHOR=1, ALTERNATIVE_BINDING_ANCHOR=2, + TIMER=TENT_LT / SAVI2=NO_BIND + + Host H is still attached to port 1, so it receives the NUD_NSOL and + responds with a secured NUD_NADV. SAVI1 receives this message, + validates it, and changes its state again to: + + SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND + + To prevent the drain of CPU resources in SAVI1, the processing of + further packets received from port 2 may be rate-limited, as + discussed in Section 5.2. + + An alternative to the previous behavior is that SAVI1 does nothing + when node M starts sending packets from port 2. In this case, when + the timer to renew the state triggers (this time it's bounded by + DEFAULT_LT), SAVI1 moves the state to TESTING_VP, sends a NUD_NSOL + through port 1, host H responds, and the state remains in VALID for + BINDING_ANCHOR=1. In this way, communication of host H is also + defended. + +4.2.2. M Attaches to a Different Switch to the Victim's Switch + + The initial state before the attack of M is: + + SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND + + M attaches to port 2 of SAVI2 and starts sending data packets. When + SAVI2 receives the data packet, it changes the state to: + + SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=TENTATIVE_DAD, + BINDING_ANCHOR=2, TIMER=TENT_LT + + SAVI2 issues a secured NUD_NSOL through port 2. Since M does not own + the IPH CGA, it cannot respond to the message. When the timer + expires, the state is moved back to: + + SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND + + To prevent the drain of CPU resources in SAVI2, the processing of + further packets received from port 2 may be rate-limited, as + discussed in Section 5.2. + + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 32] + +RFC 7219 SEND SAVI May 2014 + + +5. Security Considerations + + SEND SAVI operates only with validated SEND messages to create + bindings. Note that IPv6 packets generated by non-SEND nodes will be + discarded by the first SEND SAVI device receiving it. Therefore, + attackers cannot obtain any benefit by not using SEND. In order to + perform address validation in a mixed scenario comprising SEND and + non-SEND devices, a different solution is required, which should be + addressed in another document. + + Nodes MUST NOT assume that all SEND messages received from a SEND + SAVI device are validated, since these devices only validate the + messages strictly required for SEND SAVI operation. Among the number + of messages that are not validated by SEND SAVI, we can name NUD_NSOL + messages generated by other nodes and its corresponding NUD_NADV + responses, or RSOL messages. + + SEND SAVI improves protection compared to conventional SAVI as a + result of the increased ability of SEND nodes to prove address + ownership. + + A critical security consideration regarding SEND SAVI deals with the + need of proper configuration of the roles of the ports in a SEND SAVI + deployment scenario. Regarding security, the main requirement is + that ports defining the protected perimeter SHOULD be configured as + Validating ports. Not doing so will allow an attacker to send + packets using any source address, regardless of the bindings + established in other SEND SAVI devices. + +5.1. Protection against Replay Attacks + + One possible concern about SEND SAVI is its behavior when an attacker + tries to forge the identity of a legitimate node by replaying SEND + messages used by the SEND SAVI specification. An attacker could + replay any of these messages to interfere with the SEND SAVI + operation. For example, it could replay a DAD_NSOL message to abort + the configuration of an address for a legitimate node and to gain the + right to use the address for DEFAULT_LT seconds. + + We can analyze two different cases when considering SEND SAVI replay + attacks: + + o When the SEND message replayed is used to create or update binding + information for SEND SAVI, since the port through which this + message is received is key to the SEND SAVI operation. SEND SAVI + creates and maintains bindings as a result of the reception of + DAD_NSOL messages and of the exchange of NUD_NSOL/NUD_NADV + messages. + + + +Bagnulo & Garcia-Martinez Standards Track [Page 33] + +RFC 7219 SEND SAVI May 2014 + + + o When the SEND message replayed does not result in the update of + binding information for SEND SAVI and, thus, is not related to the + specific port through which it was received. Such situations are + the reception of CPA messages containing certificates, and the + processing of an RADV message coming from a Trusted port, which + can be used in SEND SAVI to populate the SEND SAVI Prefix List. + In these two cases, the security risks are equivalent to those of + the SEND operation, i.e., we can consider that the information + will not be changed by its legitimate sender for the time during + which the SEND specification allows replaying (which depends on + the values of TIMESTAMP_FUZZ and TIMESTAMP_DRIFT [RFC3971]). + + For replay of messages belonging to the second case, i.e., messages + that do not result in changes in the SEND SAVI binding information, + the security provided by SEND is sufficient. For the replay of + messages belonging to the first case, DAD_NSOL and NUD_NSOL/NUD_NADV + messages, protection results from the behavior of SEND SAVI, as + specified in Section 3.3.2, which restricts the ports to which the + messages involved in SEND SAVI binding updates are disseminated. + SEND SAVI devices only forward these messages to ports for which a + binding to the address being tested by the DAD_NSOL message existed. + Therefore, it is not enough for an attacker to subscribe to a + Solicited Node address to receive DAD_NSOL messages sent to that + address, but the attacker needs to generate a valid DAD_NSOL message + associated to the address for which the binding is being tested, + which is deemed unfeasible [RFC3971]. + +5.2. Protection against Denial-of-Service Attacks + + The attacks against the SEND SAVI device basically consist of making + the SEND 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 SEND SAVI device create state + for each of the addresses and waste memory. At some point, the SEND + 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 SEND SAVI device runs out of the memory allocated + for the SEND SAVI Database, it is RECOMMENDED that it creates 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 DEFAULT_LT, which is updated by NUD_NSOL/NUD_NADV + exchanges. The result is that in order for an attacker to actually + fill the SEND SAVI Database with false source addresses, it needs to + continuously answer to NUD_NSOL for all the different source + + + +Bagnulo & Garcia-Martinez Standards Track [Page 34] + +RFC 7219 SEND SAVI May 2014 + + + 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 also RECOMMENDED that a SEND 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 REQUIRED minimum is + the memory needed to store four bindings associated to the port, + although it SHOULD be raised if the ratio between the maximum number + of bindings allowed in the device and the number of ports is high. + The motivation for setting a minimum number of bindings per port is + as follows. An attacker attached to a given port of a SEND SAVI + device may attempt to launch a DoS attack towards the SEND SAVI + device by creating many bindings for different addresses. It can do + so by sending DAD_NSOL for different addresses. The result is that + the attack will consume all the memory available in the SEND SAVI + device. The above recommendation aims to reserve a minimum amount of + memory per port, so that nodes 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. + + The SEND SAVI device may store data packets while the address is + being verified, for example, when a DAD_NSOL is lost before arriving + to the SEND SAVI device to which the host attaches; when the host + sends data packets, these data packets may be stored until the SEND + SAVI device verifies the binding by means of a NUD packet exchange. + In this case, the memory for data packet storage may also be a target + of DoS attacks. A SEND SAVI device MUST limit the amount of memory + used to store data packets, allowing the other functions (such as + being able to store new bindings) to have available memory even in + the case of an attack, such as those described above. + + It is worth noting that the potential of DoS attacks against the SEND + SAVI network is increased due to the use of costly cryptographic + operations in order to validate the address of the nodes. An + attacker could generate packets using new source addresses in order + to make the closest SEND SAVI device spend CPU time to validate + DAD_NSOL messages or to generate a secure NUD_NSOL. This attack can + be used to drain CPU resources of SEND SAVI devices with a very low + cost for the attacker. In order to solve this problem, rate-limiting + the processing of packets that trigger SEND SAVI events SHOULD be + enforced on a per-port basis. + + + + + + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 35] + +RFC 7219 SEND SAVI May 2014 + + +5.3. Considerations on the Deployment Model for Trust Anchors + + The SEND specification [RFC3971] proposes two deployment models for + trust anchors: either a centralized model relaying on a globally + rooted public key infrastructure or a more local, decentralized + deployment model in which end hosts are configured with a collection + of public keys that are trusted only on a domain. + + The appeal of a centralized model is the possibility for hosts to use + SEND to validate routers as they move through links belonging to + different organizations without additional configuration. However, + without any further protection, it also enables routers authorized + with a certificate path rooted on a global trust anchor to appear as + legitimate routers in a link in which they were not intended to act + as such. This threat already existed for SEND deployments, for which + links configured to accept centralized trust anchors may send + outgoing traffic and use prefix information from alien routers. In a + SEND SAVI deployment, such routers may be able to deliver off-link + traffic to any node of the link. + + In order to cope with this threat, SEND SAVI specifies that nodes are + only allowed to behave as routers if they connect through Trusted + ports. In particular, RADV messages and traffic with off-link source + addresses are discarded when received through Validating ports, which + are the ports intended for non-trusted infrastructure, as moving + nodes. The protection provided by filtering RADV messages prevents + SEND nodes from identifying alien routers as legitimate routers, even + though the trust anchor of these routers is valid. + + Besides, it is worth to say that SEND SAVI supports a decentralized + deployment model. + +5.4. Residual Threats + + SEND SAVI assumes that a host will be able to defend its address when + the DAD procedure is executed for its addresses, and that it will + answer to a NUD_NSOL with a NUD_NADV when required. 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). If the SEND + SAVI device does not see the DAD_NADV or the NUD_NADV, 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 launching a DoS attack to the host that will prevent it to issue + proper replies. + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 36] + +RFC 7219 SEND SAVI May 2014 + + +5.5. Privacy Considerations + + A SEND SAVI device MUST delete binding anchor information as soon as + possible (i.e., as soon as the state for a given address is back to + NO_BIND), except where there is an identified reason why that + information is likely to be involved in the detection, prevention, or + tracing of actual source address spoofing. Information about the + majority of hosts that never spoof SHOULD NOT be logged. + +6. Acknowledgments + + Thanks to Jean-Michel Combes, Ana Kukec, Ted Lemon, Adrian Farrel, + Barry Leiba, Brian Haberman, Vicent Roca, and Benoit Claise for their + reviews and comments on this document. The text has also benefited + from feedback provided by Tony Cheneau and Greg Daley. + + Marcelo Bagnulo is partly funded by Trilogy 2, a research project + supported by the European Commission under its Seventh Framework + Program. Alberto Garcia-Martinez was supported, in part, by project + TEC2012-38362-C03-01, granted by the Spanish Economy and + Competitiveness Ministry. + +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. + + [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure + Neighbor Discovery (SEND)", RFC 3971, March 2005. + + [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", + RFC 3972, March 2005. + + [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. + + + + + + + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 37] + +RFC 7219 SEND SAVI May 2014 + + +7.2. Informative References + + [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. + + [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. + + [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node + Requirements", RFC 6434, December 2011. + + [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS + SAVI: First-Come, First-Served Source Address Validation + Improvement for Locally Assigned IPv6 Addresses", RFC + 6620, May 2012. + + [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, + "Source Address Validation Improvement (SAVI) Framework", + RFC 7039, October 2013. + +Authors' Addresses + + 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 + + + Alberto Garcia-Martinez + Universidad Carlos III de Madrid + Av. Universidad 30 + Leganes, Madrid 28911 + Spain + + Phone: 34 91 6248782 + EMail: alberto@it.uc3m.es + URI: http://www.it.uc3m.es + + + + + +Bagnulo & Garcia-Martinez Standards Track [Page 38] + |