One document matched: draft-ietf-savi-fcfs-10.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc compact='yes'?>
<rfc obsoletes="" updates="" category="std" ipr="pre5378Trust200902" docName="draft-ietf-savi-fcfs-10">
<front>
<title abbrev="FCFS SAVI">
FCFS SAVI: First-Come First-Serve Source-Address Validation for Locally Assigned IPv6 Addresses
</title>
<author initials="E." surname="Nordmark" fullname="Erik Nordmark">
<organization abbrev="Cisco">
Cisco
</organization>
<address>
<postal>
<street>510 McCarthy Blvd.</street>
<city>Milpitas</city>
<region>California</region>
<code>95035</code>
<country>UNITED STATES</country>
</postal>
<email>nordmark@acm.org</email>
</address>
</author>
<author initials="M." surname="Bagnulo" fullname="Marcelo Bagnulo">
<organization abbrev="UC3M">
Universidad Carlos III de Madrid
</organization>
<address>
<postal>
<street>Av. Universidad 30</street>
<city>Leganes</city>
<region>Madrid</region>
<code>28911</code>
<country>SPAIN</country>
</postal>
<phone>34 91 6248814</phone>
<email>marcelo@it.uc3m.es</email>
<uri>http://www.it.uc3m.es</uri>
</address>
</author>
<author fullname="Eric Levy-Abegnoli" initials="E.L.A."
surname="Levy-Abegnoli">
<organization> Cisco Systems</organization>
<address>
<postal>
<street>Village d'Entreprises Green Side -
400, Avenue Roumanille </street>
<city>Biot-Sophia Antipolis - 06410</city>
<country>France</country>
</postal>
<email>elevyabe@cisco.com</email>
</address>
</author>
<date year="2011"/>
<abstract>
<t>
This memo describes FCFS SAVI a mechanism to provide source
address validation for IPv6 networks using the First-Come First-Serve principle.
The proposed mechanism is intended to complement ingress filtering
techniques to help detect and prevent source
address spoofing.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This memo describes FCFS SAVI, a mechanism to provide source
address validation for IPv6 networks using the First-Come First-Serve 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.
</t>
</section>
<section title="Background to FCFS SAVI">
<section title="Scope of FCFS SAVI">
<t>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.</t>
<t>In a link there usually are hosts and routers attached. Hosts generate packets
with their own address as the source address. This is called the 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 the transit traffic. </t>
<t> 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 <xref target="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.</t>
<t>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) <xref target="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 SAVI
can also be used with IPv6 addresses assigned via DHCPv6, since they ought to perform the Duplicate Address
Detection procedure, but there is a specific mechanism tailored for dealing with DHCP assigned addresses
defined in <xref target="I-D.ietf-savi-dhcp" />. Additional
considerations about how to use FCFS SAVI depending on the type of address management used and the
nature of the addresses is discussed in the framework document <xref target="I-D.ietf-savi-framework" />.</t>
</section>
<section title="Constraints for FCFS SAVI design">
<t>FCFS SAVI is designed to be deployed in existing networks requiring a minimum set of changes.
For that reason, FCFS SAVI does not require any changes in the hosts which source address is to be verified.
Any verification solely relies in the usage of already available protocols. In other words, FCFS SAVI does not
define a new protocol nor define any new message on existing protocols nor require that a host
uses an existent protocol message in a different way. In other words, the requirement is no host changes.</t>
<t>FCFS SAVI validation is performed by the FCFS SAVI function. Such function can be placed in different type
of devices, including a router or a layer-2 bridge. The basic idea is that the FCFS SAVI function is located
in the points of the topology that can enforce the correct usage of source address by dropping the non-compliant
packets. </t>
</section>
<section title="Address ownership proof">
<t>The main function performed by FCFS SAVI is to verify that the
source address used in data packets actually belongs to the
originator of the packet. Since FCFS SAVI scope is limited to the
local link, the originator of the packet is attached to the local
link. In order to define 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.</t>
<t>In FCFS SAVI the address ownership proof is based in the First-Come
First- Serve 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 which
consists on layer-2 information that the FCFS SAVI box has
available (e.g. the port in a switched LAN). 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.</t>
<t>There are however additional considerations to be taken into account. For instance, consider the case of a host that
moves from one segment of a LAN to another segment of the same subnetwork and it keeps the same IP address.
In this case, the host is still the owner of the IP address, but the associated binding anchor may have changed.
In order to cope with this case, the defined FCFS SAVI behaviour implies the verification whether the host is still reachable
using the previous binding anchor. In order to do that FCFS SAVI uses the Neighbour 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. </t>
<t>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.</t>
</section>
<section title="Binding Anchor considerations">
<t>Any SAVI solution is not stronger than the binding anchor it uses. If the binding anchor is easily spoofable
(e.g. a MAC address), then the resulting solution will be weak. The treatment of non-compliant packets needs to be tuned
accordingly. In particular, if the 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.
</t>
</section>
<section title="FCFS SAVI protection perimeter">
<t>FCFS SAVI provides perimetrical security. FCFS SAVI devices form what can be called a 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 to the packet. This model has implications both on how FCFS SAVI devices are
deployed in the topology and on the configuration of the FCFS SAVI boxes.</t>
<t>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.</t>
<t>One possible approach would be for every FCFS SAVI device to store binding information about every source addresses 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
significant memory burden on the FCFS SAVI devices. In order to reduce the memory requirements imposed to 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 criteria: 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
a FCFS SAVI device. The binding information for that particular source address will be stored in this first FCFS SAVI device the packet reaches to.</t>
<t>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 is coherent. In particular, it is important to avoid
that the same source address is 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 Neighbour Discovery (ND) protocol <xref target="RFC4861" /> is
used, in particular
the Neighbour Solicitation (NS) and Neighbour Advertisement (NA) messages. As a simplified example of how this might work: before
creating a FCFS SAVI binding in the local FCFS SAVI
database, the FCFS SAVI device will send a NS message querying for the address involved. Should any host reply to that message with a
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.
<!--
(NOTE that the description
included here is overly simplified to illustrate the mechanism used to preserve the coherency of the binding databases of the different
SAVI devices. The actual SAVI mechanism normative specification as described in <xref target="normative"/>
varies in the fact that in some cases it is the SAVI device that generates
the NS while in other cases it simply forwards the NS generated by the end host, and that the SAVI device will send multiple
copies of the NS in order to improve the reliability of the message exchange, among other things).--></t>
<t>So, summarizing, the proposed FCFS SAVI approach relies on the following design choices:
<list style="symbols">
<t>FCFS SAVI provides perimetrical security, so some interfaces of a 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.</t>
<t>A FCFS SAVI device only verifies packets coming through an interface connected to the untrusted part of the topology.</t>
<t>A 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.</t>
<t>FCFS SAVI uses the NS and NA messages to preserve the coherency of the FCFS SAVI binding state distributed among the FCFS SAVI
devices within a realm.</t>
</list></t>
<t>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. that no data packet can get inside the perimeter without passing
through a FCFS SAVI device). Packets that cross the perimeter will be validated while packets
that do no 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 picture:</t>
<figure align="center">
<artwork align="left"><![CDATA[
+--------+
+--+ +--+ +--+ | +--+ |
|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| |SWICTH-B |
| +--+| +--+ +---------+
+------+ | |
+--+ +--+
|H5| |H6|
+--+ +--+
]]></artwork>
</figure>
<t>In the figure above, the FCFS SAVI protection perimeter is provided by 4 FCFS SAVI devices,
namely SAVI1, SAVI2, SAVI3 and SAVI4. These devices verify the
source address and filter packets accordingly.
</t>
<t>FCFS SAVI devices then have two types of ports: trusted ports and validating ports.
<list style="symbols">
<t>Validating ports (VPs) are those in which FCFS SAVI processing is performed.
When a packet is received through one of the validating ports, the FCFS SAVI processing and
filtering will be executed. </t>
<t> 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
in them.</t>
</list></t>
<t>Trusted ports are used for connections with the trusted infrastructure, including the communication between FCFS SAVI devices, the
communication with routers and the communication of other switches that while they are not FCFS SAVI devices, they only connect
to trusted infrastructure (i.e. other FCFS SAVI devices, routers or other trusted nodes). So, in the figure above, 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 the connect to SWITCH-A to which only trusted nodes are connected. In the figure above, port 2 of SAVI2 and port 3 of
SAVI3 are trusted ports because they connect to routers.</t>
<t>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 the figure above, ports 1 and 2 of SAVI1, port 1 of SAVI2, port 4 of SAVI 3 are validating ports because
they connect to hosts. Port 4 of SAVI4 is also a validating port because it is connected to SWITCH-B which is a non-SAVI capable switch
which is connected to hosts H5 and H6.</t>
</section>
<section title="Special cases">
<t> 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. Even the case where the forwarding of packets between different prefixes involve a router is supported, as long as the router is connected to a Trsuted port, as recommended for all the routers.</t>
<t>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 source address, then, from the SAVI device perspective this is equivalent to two hosts with a single interface each with an IP address each. This is supported by SAVI without 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 configure the SAVI bindings to allow binding the address of the multihomed host to multiple anchors simultaneously.</t>
<t>Untrusted routers: One can envision scenarios where routers are dynamically attached to a FCFS SAVI network. A typical example would be a mobile phone connecting to a 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 (as 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 scenario.</t>
</section>
</section>
<section anchor="normative" title="FCFS SAVI specification">
<t>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 <xref target="RFC2119" />.</t>
<section title="FCFS SAVI Data structures">
<t>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 FCFS SAVI Data Base (DB).
The FCFS SAVI DB will contain a set of entries about the currently used IP source addresses. So each entry will contain
the following information:</t>
<list style="symbols">
<t>IP source address</t>
<t>Binding anchor: port through which the packet was received</t>
<t>Lifetime</t>
<t>Status: either TENTATIVE, VALID, TESTING_VP or TESTING_TP-LT</t>
<t>Creation time: the value of the local clock when the entry was firstly created</t>
</list>
<t>In addition to this,
FCFS SAVI needs to know what are the prefixes that are directly
connected, so it maintains a data structure called the FCFS SAVI
prefix list, which contains:</t>
<list style="symbols">
<t>Prefix</t>
<t>Interface where prefix is directly connected</t>
</list>
</section>
<section title="FCFS SAVI algorithm">
<section title="Discovering on-link prefixes">
<t> 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. A FCFS SAVI device MUST support the following two methods for populating the Prefix List:
Manual configuration and Router Advertisement, as detailed next.</t>
<t>Manual configuration: A 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. </t>
<t>Router Advertisement: A FCFS SAVI device MUST support discovery of on-link prefixes through Router Advertisement messages in Trusted Ports.
For the 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
<xref target="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
<xref target="RFC4861" />, using the unspecified source address.</t>
</section>
<section title="Processing of transit traffic">
<t>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 the packet has been received through:
<list style="symbols">
<t>If the data packet is received through a Trusted port, the data packet is forwarded and no
SAVI processing performed to the packet.</t>
<t>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.
<list style="symbols">
<t>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.</t>
<t>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.</t>
<t>If the source address of the packet is the 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 <xref target="local" />.</t>
</list></t>
</list></t>
</section>
<section anchor="local" title="Processing of local traffic.">
<t>We describe next how the local traffic, including both control and data packets are processed by the FCFS SAVI
device using a state machine approach.</t>
<t>The state machine described is for the binding of a given source IP address (called IPAddr) in a given FCFS SAVI device.
So 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:
<list style="symbols">
<t>IP ADDRESS: IPAddr</t>
<t>BINDING ANCHOR: P</t>
<t>LIFETIME: LT</t>
</list></t>
<t>The possible states are:
<list style="symbols">
<t>NO_BIND</t>
<t>TENTATIVE</t>
<t>VALID</t>
<t>TESTING_TP-LT</t>
<t>TESTING_VP</t>
</list></t>
<t>We will use VP for Validating Port and TP for Trusted Port.</t>
<t>After bootstrapping (when no binding exists), the state for all source IP address is NO-BIND i.e. there is no binding for the
IP address to any binding anchor.</t>
<t>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 it.</t>
<t>TENTATIVE: The binding for
a source address for which a data packet or a 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).</t>
<t> 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.</t>
<t>TESTING_TP-LT: A binding for a source address enters in this state due to one of two reasons:
<list>
<t>When a Duplicate Address Detection Neighbour 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.</t>
<t>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, in order
to determine if the binding information should be discarded.</t>
</list></t>
<t>TESTING_VP: A binding for a source address enters in this state when a Duplicate Address Detection Neighbour Solicitation
or a data packet has been received through a Validating port
other than the one address is currently bound to.
This implies that a host is performing the DAD procedure for that source address through a different port. This may due
to an attack or to the fact that the host 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.</t>
<!-- <t>TESTING_LIFETIME: A binding for a source address is in this state cause the lifetime of the entry is about to expire. This
is due to the fact that no packets has been seen by the SAVI device for the LIFETIME period. This may be due to the host simply
being silent or because the host has left the location. In order to determine which is the case, a test is performed, in order
to determine if the binding information should be discarded.</t>
-->
<t>We describe next how the different inputs are processed depending on the state of the binding of the IP address (IPAddr).</t>
<t>A simplified figure of the state machine is included below.</t>
<t>NO_BIND</t>
<t><list style="symbols">
<t>Upon the reception through a Validating Port (VP) of a Neighbour 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 millisconds later it MUST
send a copy of the same message.
<!--
execute the process of sending Neighbour Solicitation messages of
the Duplicate Address Detection process as described in section 5.4.2 of <xref target="RFC4862" />
for the IPAddr using the following default parameters: DupAddrDetectTransmits set to 1 (i.e. 2 Neighbour Solicitation
messages for that address will be sent by the SAVI device) and RetransTimer set to T_WAIT Milliseconds
This is equivalent to sending the received DAD_NS message twice.-->
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.</t>
<t>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 Neighbour Solicitation messages of
the Duplicate Address Detection process as described in section 5.4.2 of <xref target="RFC4862" />
for the IPAddr using the following default parameters: DupAddrDetectTransmits set to 2 (i.e. 2 Neighbour Solicitation
messages for that address will be sent by the SAVI device) and RetransTimer set to T_WAIT Milliseconds (i.e. the time between two
Neighbour Solicitation messages is T_WAIT Milliseconds).
The implications of not following the recommended behaviour are described in <xref target="SHOULD-qualification" />.
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 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.
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.</t>
<t>Data packets containing IPAddr as the source address received through Trusted ports are processed and
forwarded as usual (i.e. no special SAVI processing)</t>
<t>DAD_NS packets containing IPAddr as the target address received through a Trusted port MUST NOT 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).</t>
<t>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.</t>
<t>Other signaling packets are processed and forwarded as usual (i.e. no SAVI processing)</t>
</list></t>
<t>TENTATIVE</t>
<t><list style="symbols">
<t>If the LIFETIME times out, the state is moved to VALID. The LIFETIME is set to DEFAULT_LT (i.e. LT== DEFAULT_LT). Stored
data packets are forwarded (if any).</t>
<t>If a Neighbour Advertisement (NA) is received through a Trusted Port with Target Address set to IPAddr, then 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.</t>
<t>If a NA is received through a Validating Port
with Target Address set to IPAddr, the NA packet is discarded</t> <!-- a host is trying to defend an address that doesn't belong to it -->
<t>If a data packet with source address IPAddr is received with binding anchor equal to P, then the packet is either stored or discarded.</t>
<t>If a data packet with source address IPAddr is received through a Trusted port,
the data packet is forwarded. The state is unchanged <!--(waiting for the NA)-->.</t>
<t>If a data packet with source address IPAddr is received through a Validating port other than P, the data packet is discarded.</t>
<t>If a DAD_NS is received from a Trusted port, with 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.</t>
<t> If a DAD_NS with 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, the state remains in TENTATIVE, but 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.</t>
<t>Other signaling packets are processed and forwarded as usual (i.e. no SAVI processing)
</t>
</list></t>
<t>VALID</t>
<t><list style="symbols">
<t>If a data packet containing IPAddr as a source address arrives from Validating port P, then the LIFETIME is set to DEFAULT_LT
and the packet is forwarded as usual.</t>
<t>If a DAD_NS is received from a Trusted port, then the DAD_NS message is forwarded to port P and it 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.</t>
<t>If a data packet containing source address IPAddr or a DAD_NA packet with target address set to IPAddr is received through
a Validating port P' other than P, then the SAVI device will execute the process of sending DAD_NS messages
as described in section 5.4.2 of <xref target="RFC4862" />
for the IPAddr using the following default parameters: DupAddrDetectTransmits set to 2 (i.e. 2 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.</t>
<t>If a DAD_NS packet with 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 <xref target="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 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.</t>
<t>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 <xref target="RFC4862" />
for the IPAddr using the following default parameters: DupAddrDetectTransmits set to 2 (i.e. 2 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.</t>
<t>If a data packet containing IPAddr as a source address arrives from Trusted port, the packet MAY be discarded. The event MAY be logged.</t>
<!-- alberto propuso o If a DAD_NS is received from the Validating port P, the LIFETIME is set to TENT_LT, and the state is changed to TENTATIVE_DATA_NS. (this may occur because the host is rebooting. The behavior defined here is as if a DAD_NS is being received while being in NO_BIND; don't know if you want to copy 2 times the message…). The message is forwarded to the proper Trust Ports, and will not be forwarded through any of the ports configured as Validating Ports.
decidimos no hacerlo porque un atacante que compare el puerto, puede enviar un NS para que otro atacante en otro purto robe el binding. La consequencia de esto es que en puede quedar el binding abierto en este caso, auqnue el host no use la direccion -->
<t>Other signaling packets are processed and forwarded as usual (i.e. no SAVI processing). In particular DAD_NA coming from port P and containing
IPAddr as the target address are forwarded as usual.</t>
</list></t>
<t>TESTING_TP-LT</t>
<t><list style="symbols">
<t>If the LIFETIME expires, the BINDING ANCHOR is cleared and the state is changed to NO_BIND</t>
<t>If a NA message containing the IPAddr as 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</t>
<t>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.</t>
<t>If a DAD_NS is received from a Trusted port, the DAD_NS is forwarded as usual.</t>
<t>If a DAD_NS is received from a Validating Port P' other than P, the DAD_NS is forwarded as usual, the state is moved to TESTING_VP.</t>
<t>If a data packet is received through a Validating Port port P' that is other than port P, then the packet is discarded.</t>
<t>If a data packet is received through a Trusted Port port, then the packet MAY be discarded. The event MAY be logged.</t>
</list></t>
<t>TESTING_VP</t>
<t><list style="symbols">
<t>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. Data packet stored coming from P' are forwarded.</t>
<t>If a NA message containing the IPAddr as 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</t>
<t>If a data packet containing IPAddr as the source address is received through port P, then the packet is forwarded.</t>
<t>If a data packet is received through a Validating Port P'' that is other than port P or P', then the packet is discarded.</t>
<t>If a data packet is received through a Trusted Port port (i.e. other than port P), the state is moved to TESTING_TP-LT,
and the packet MAY is discarded.</t>
<t>If a DAD_NS is received through Trusted Port, the packet is forwarded as usual and the state is moved to TESTING_TP-LT.</t>
<t>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.</t>
</list></t>
<!-- <t>TESTING_LIFETIME</t>
<t><list style="symbols">
<t>If the LIFETIME expires, the LAYER_2 ANCHOR is cleared and the state is changed to NO_BIND</t>
<t>If a NA message containing the IPAddr as 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.</t>
<t>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.</t>
</list></t>
-->
<figure align="center">
<preamble>Simplified state machine figure</preamble>
<artwork align="left"><![CDATA[
+---------+ 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
]]></artwork>
</figure>
<t>MLD considerations</t>
<t> The FCFS SAVI device MUST join the Solicited Node Multicast group for all the addresses which state is other than NO_BIND.
This is needed to make sure that the 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 doing so, since the node may move and after a while, the packets for that
particular solicited node multicast group will no longer be forwarded to the FCFS SAVI device. So, the FCFS SAVI device MUST join the solicited node
multicast groups for all the addresses that are in a state other than NO_BIND</t>
</section>
<section title="FCFS SAVI port configuration guidelines">
<t>The guidelines for port configuration in FCFS SAVI devices are:
<list style="symbols">
<t>The FCFS SAVI realm (i.e. the realm that is inside the FCFS SAVI protection perimeter) SHOULD be connected. If this is not the case, legitimate
transit traffic may be dropped.</t>
<t>Ports that are connected to another FCFS SAVI device SHOULD 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. </t>
<t>Ports connected to hosts SHOULD be configured as Validating ports. Not doing so will allow the host connected to that port to send
packets with spoofed source address. A valid exception is the case of a trusted host (e.g. a server) which could be connected to a Trusted port, but untrusted hosts MUST be connected to Validating ports. </t>
<t>Ports connected to routers MUST be configured as Trusted ports. Configuring them as Validating ports should result in transit traffic being dropped.</t>
<t>Ports connected to a chain of one or more legacy switches that have hosts connected SHOULD be configured as Validating ports.
Not doing so will allow the host connected to any of these switches to send packets with spoofed source address.</t>
<t>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 SHOULD be configured as Trusted ports. Not doing so will at least significantly increase
the memory consumption in the FCFS SAVI devices and increase the signaling traffic due to FCFS SAVI validation and may results in legitimate transit traffic being dropped. </t>
<!-- <t>Ports connected to a chain of one or more legacy switches that have a mix of SAVI devices and/or routers with hosts,
SHOULD be configured as Validating
ports. Not doing so will allow the host connected to that port to send packets with spoofed source address. Nevertheless, this
topology will result in increased SAVI signaling and memory consumption compared to a topology where SAVI-hosts communications
and inter SAVI communications are kept through different legacy switches.</t>-->
</list>
</t>
</section>
<section title="VLAN support">
<t>In the case the FCFS SAVI device is a switch that supports customer VLANs <xref target="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
the nodes attached to that particular customer VLAN.
</t>
</section>
</section>
<section title="Default Protocol Values">
<t>The following are the default values used in the FCFS SAVI specification.</t>
<t>TENT_LT is 500 Milliseconds</t>
<t> DEFAULT_LT is 5 minutes</t>
<t>T_WAIT is 250 Milliseconds</t>
<t> An implementation MAY allow these values to be modified, but
that tuning them precisely is considered out of scope of this document. </t>
</section>
</section>
<section title="Security Considerations">
<!-- <t>First of all, it should be noted that any SAVI solution will be as strong as the binding anchor that it uses.
In particular, if the binding anchor is forgeable, then the resulting SAVI solution will be weak. For example,
if we use switch ports as binding anchors and there is only one
host connected to each port it is likely that the resulting SAVI solution will be considerably more secure.</t>
-->
<t>Denial of service attacks</t>
<t>There are two types of Denial of Service (DoS) attacks <xref target="RFC4732" /> that can be envisaged in a
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. </t>
<t>The attacks against the FCFS SAVI device basically consist on making the FCFS SAVI device to
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 to create state for each of the addresses and waste memory. At some point the FCFS SAVI
device runs out of memory and it needs to decide how to react in this situation. The result is that some form of garbage collection
is needed to prune the entries. It is RECOMMENDED that when the FCFS SAVI device runs out of the memory allocated for the FCFS SAVI DB,
it creates new entries by deleting the entries which Creation Time is higher. This implies that older entries are preserved
and newer entries overwrite each other. In an attack scenario where the attacker sends a batch of data packets with
different source address, each new source address is likely to rewrite another source address created by the attack itself.
It should be noted that entries are also garbage collected using the LIFETIME, which is updated using data packets. The result
is that in order for an attacker to actually fill the FCFS SAVI DB with false source addresses, it needs to continuously send
data packets for all the different source addresses, in order for the entries to grow old and compete with the legitimate
entries. The result is that the cost of the attack for the attacker is highly increased.</t>
<t> In addition, it is also RECOMMENDED that a 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 4 bindings associated to the port.
The motivation for this recommendation is as follows: an attacker attached to a given port of a 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.</t>
<t>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 attack
will be then that data packets will be dropped during the verification period.
A 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
as the above described.</t>
<t>The FCFS SAVI device generates 2 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 performs rate limiting of the messages it
generates. The rate limiting is performed on a per port basis, since having an attack on a given port should not prevent the FCFS SAVI device to
function normally in the rest of the ports.</t>
<t>Residual threats.</t>
<t>FCFS SAVI perform 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 because the binding anchor
is shared among 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 switch (i.e. no 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 this will not be detected by the FCFS SAVI device. This
can be prevented by not sharing binding anchors among hosts.</t>
<t>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 a 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 to issue proper DAD replies.</t>
<t> Even if routers are considered as trusted, nothing can prevent that a
router could be compromised and send traffic with spoofed IP source
addresses. Such a 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.
</t>
<t>Privacy considerations</t>
<t>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 attempt of attack involved.
Moreover, compliant implementation 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 the state for a given address is back to NO_BIND).
Information about the majority of hosts that
never spoof SHOULD NOT be logged.</t>
<!--
<t>Logging information can be useful
to assist in traceability for determining who an improper actor is.
For example, if a remote site reports that a DoS (or component of a
Distributed DoS) is coming from the SAVI site, SAVI logging information
can help to determine which were the involved hosts.</t>
-->
<t>Interaction with Secure Neighbour Discovery</t>
<t> Even if FCFS SAVI could get information from ND messages secured with
SEND <xref target="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
<xref target="I-D.ietf-savi-send" /> rather than FCFS SAVI."
</t>
</section>
<section title="IANA Considerations">
<t> This document has no actions for IANA.</t>
</section>
<section title="Contributors">
<t><list>
<t>Jun Bi</t>
<t>CERNET</t>
<t>Network Research Center, Tsinghua University</t>
<t>Beijing 100084</t>
<t>China</t>
<t>Email: junbi@cernet.edu.cn</t>
</list></t>
<t><list>
<t>Guang Yao</t>
<t>CERNET</t>
<t>Network Research Center, Tsinghua University</t>
<t>Beijing 100084</t>
<t>China</t>
<t>Email: yaog@netarchlab.tsinghua.edu.cn</t>
</list></t>
<t><list>
<t>Fred Baker</t>
<t>Cisco Systems</t>
<t>Email: fred@cisco.com</t>
</list></t>
<t><list>
<t>Alberto Garcia Martinez</t>
<t>University Carlos III of Madrid</t>
<t>Email: alberto@it.uc3m.es</t>
</list></t>
</section>
<section title="Acknowledgments">
<t>This draft benefited from the input from: 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. </t>
<t>Marcelo Bagnulo is partly funded by Trilogy,
a research project supported by the European Commission under its Seventh
Framework Program.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.2827'?>
<?rfc include='reference.RFC.4861'?>
<?rfc include='reference.RFC.4862'?>
</references>
<references title='Informative References'>
<?rfc include='reference.I-D.ietf-savi-framework'?>
<?rfc include='reference.I-D.ietf-savi-dhcp'?>
<?rfc include='reference.I-D.ietf-savi-send'?>
<?rfc include='reference.RFC.3971'?>
<?rfc include='reference.RFC.4732'?>
<reference anchor="IEEE.802-1Q.2005">
<front>
<title> IEEE Standard for Local and metropolitan area networks /
Virtual Bridged Local Area Networks</title>
<author>
<organization>Institute of Electrical and Electronics Engineers</organization>
</author>
<date month="May" year="2005"/>
</front>
<seriesInfo name="IEEE" value="Standard 802.1Q"/>
</reference>
</references>
<section anchor="SHOULD-qualification" title="Implications of not following the recommended behaviour">
<t>This specification recommends SAVI implementations to generate a DAD_NS message upon the reception of
a data packet for which they have no binding for. In this section we describe the implications of not doing so and
simply discarding the data packet instead.</t>
<t>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 discard data packets in this case
may end up disconnecting legitimate users from the network, by filtering packets coming from them.
The net result would 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.
</t>
<section title="Lack of binding state due to packet loss">
<t>The DAD procedure is inherently unreliable. It consists on sending a 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 their interface, but it may also be the case that the NS packet or the NA packet has been lost.
From the sending host perspective 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.</t>
<t>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 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.
</t>
<t> The only mechanism that the DAD has to improve its reliability is to send multiple
NS. However, current 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.
</t>
<section title="Why initial packets may be (frequently) lost">
<t>The case of LANs</t>
<t>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.</t>
<t>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 Neighbour 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.</t>
<t>Additionally, any system which 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.</t>
<t>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.</t>
<t>For environments which 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 which perform spanning-tree calculations
are either traditional Spanning-Tree Protocol (STP) (see IEEE802.1D-1998) or rapidly converging versions of
the same (RSTP/MSTP) (see IEEE 802.1D-2004 and IEEE 802.1Q-2005).</t>
<t>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.</t>
<t>For ports which are not connected to rapid protocol switches, it takes a minimum three seconds to perform
edge port determination (see IEEE 802.1D-2004). Alternatively completion of 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.</t>
<t>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 behaviour though.</t>
<t>The case of fixed access networks</t>
<t>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 residential gateway 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(DSLAM) that needs to create and maintain binding state will never see the DAD message that is required to create such state.</t>
<section title="Special sub-case:SAVI device rate-limiting packets">
<t>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 require processing
from the SAVI device). This implies that the SAVI device may not process all the ND packets in case 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 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.</t>
</section>
</section>
</section>
<section title="Lack of binding state due to a change in the topology">
<t>In the case SAVI is being 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 for. Consider the following example:</t>
<figure>
<preamble></preamble>
<artwork align="center">
+------+ +--------+ +---------------+
|SAVI I|-------------|SWITCH I|-------|rest of the net|
+------+ +--------+ +---------------+
| |
| +--------+
| | SAVI II|
| +--------+
| +----------+ |
+---|SWITCH II |-----+
+----------+
|
+-----+
| Host|
+-----+
</artwork>
<postamble></postamble>
</figure>
<t>Suppose that after bootstrapping all the elements are working properly and the spanning tree is rooted in the router and it includes one branch that goes
SWITCH I-SAVI I- SWITCH II and another branch that goes SWITCH I-SAVI II.</t>
<t>Suppose that the Host boots at this moment and sends the DAD_NS. The message is propagated through the spanning tree and it received by SAVI I but not by
SAVI II. SAVI I creates the binding.</t>
<t>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.</t>
</section>
<section title="Lack of binding state due to state loss">
<t>The other reason why 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 procedure and the SAVI device creates a binding for the host's
address. The host successfully
communicate for a while. The SAVI device reboots and lost 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.</t>
<t>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. RFC 1958 reads:
<list>
<t>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).
</t>
</list> 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.</t>
<t>Moving on to more practical matters, we can dig deeper into the actual behaviour 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.</t>
<section title="The case of a host directly connected to the SAVI device">
<t>The considered scenario is depicted in the following picture:</t>
<figure>
<preamble></preamble>
<artwork align="center">
+------+ +-----------+ +---------------+
| Host |-------------|SAVI device|-------|rest of the net|
+------+ +-----------+ +---------------+
</artwork>
<postamble></postamble>
</figure>
<t>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.</t>
<t>RFC4862 requires that the DAD procedure is performed when the IP address is assigned to the
interface, quoting RFC4862 section 5.4. Duplicate Address Detection:
<list><t>
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:...
</t></list></t>
<t>However, it has been stated that some of the widely used OSes actually do perform DAD each time the link is up,
but further data would be required to take this for granted.
Assuming that behaviour, that implies that if the lost of state in the SAVI device also results in the link to the host
going down, then the host using the tested OSes 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 though, that it is also
possible that the binding state is lost for whatever 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 links goes down each time
the SAVI process restarts and improving the chances the host will redo the DAD procedure when the SAVI process is rebooted.</t>
</section>
<section title="The case of a host connected to the SAVI device through one or more legacy devices.">
<t>The considered scenario is depicted in the following picture:</t>
<figure>
<preamble></preamble>
<artwork align="center">
+------+ +-------------+ +-----------+ +---------------+
| Host |----|Legacy device|-----|SAVI device|----|rest of the net|
+------+ +-------------+ +-----------+ +---------------+
</artwork>
<postamble></postamble>
</figure>
<t>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.</t>
<t>In this case, the host would get 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. </t>
<t>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, may turn a directly connected host scenario to the scenario where the multiple (virtual) hosts
are connected through a legacy (virtual) hub.</t>
<section title="Enforcing direct connectivity between the SAVI device and the host">
<t>It has been argued that enforcing the direct connectivity between the SAVI device and the end host is actually a feature.
There are several comments that can be made in this respect:
<list>
<t>First, it may
well be the case in some scenarios 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.</t>
<t>Second, as a matter of fact, the resulting behaviour 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 would 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 host to the SAVI switch. </t>
<t>Third, it should be noted that topology enforcement is not part of
the SAVI problem space and that the SAVI problem by itself is hard enough to add additional requirements. </t>
</list></t>
</section>
</section>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:44:59 |