Network Working Group E. Nordmark
Internet-Draft Cisco
Intended status: Standards Track M. Bagnulo
Expires: October 15, 2011 UC3M
E. Levy-Abegnoli
Cisco Systems
April 13, 2011
FCFS-SAVI: First-Come First-Serve Source-Address Validation for Locally
Assigned IPv6 Addresses
draft-ietf-savi-fcfs-07
Abstract
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 provide a finer granularity on the control of
the source addresses used.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 15, 2011.
Copyright Notice
Copyright (c) 2011 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
Nordmark, et al. Expires October 15, 2011 [Page 1]
Internet-Draft FCFS SAVI April 2011
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Nordmark, et al. Expires October 15, 2011 [Page 2]
Internet-Draft FCFS SAVI April 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Non-normative background to FCFS SAVI . . . . . . . . . . . . 4
2.1. Scope of FCFS SAVI . . . . . . . . . . . . . . . . . . . . 4
2.2. Constraints for FCFS SAVI design . . . . . . . . . . . . . 5
2.3. Address ownership proof . . . . . . . . . . . . . . . . . 5
2.4. Binding Anchor considerations . . . . . . . . . . . . . . 6
2.5. SAVI Logging . . . . . . . . . . . . . . . . . . . . . . . 6
2.6. SAVI protection perimeter . . . . . . . . . . . . . . . . 6
3. FCFS SAVI normative specification . . . . . . . . . . . . . . 10
3.1. FCFS SAVI Data structures . . . . . . . . . . . . . . . . 10
3.2. FCFS SAVI algorithm . . . . . . . . . . . . . . . . . . . 11
3.2.1. Discovering on-link prefixes . . . . . . . . . . . . . 11
3.2.2. Processing of transit traffic . . . . . . . . . . . . 11
3.2.3. Processing of local traffic. . . . . . . . . . . . . . 12
3.2.4. SAVI port configuration guidelines . . . . . . . . . . 17
3.2.5. VLAN support . . . . . . . . . . . . . . . . . . . . . 18
3.3. Protocol Constants . . . . . . . . . . . . . . . . . . . . 18
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Implications of not following the reccommended
behaviour . . . . . . . . . . . . . . . . . . . . . . 22
A.1. Lack of binding state due to packet loss . . . . . . . . . 23
A.1.1. Why initial packets may be (frequently) lost . . . . . 23
A.2. Lack of binding state due to a change in the topology . . 25
A.3. Lack of binding state due to state loss . . . . . . . . . 26
A.3.1. The case of a host directly connected to the SAVI
device . . . . . . . . . . . . . . . . . . . . . . . . 26
A.3.2. The case of a host connected to the SAVI device
through one or more legacy devices. . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Nordmark, et al. Expires October 15, 2011 [Page 3]
Internet-Draft FCFS SAVI April 2011
1. Introduction
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 provide a finer granularity on the control of
the source addresses used.
2. Non-normative background to FCFS SAVI
2.1. Scope of FCFS SAVI
The application scenario for FCFS SAVI is limited to the local link.
This means that the goal of FCFS SAVI is to verify that the source
address of the packets generated by the hosts attached to the local
link have not been spoofed.
In a link 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 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.
The applicability of FCFS SAVI is limited to the local traffic i.e.
to verify if the traffic generated by the hosts attached to the local
link contains a valid source address. The verification of the source
address of the transit traffic is out of the scope of FCFS SAVI.
Other techniques, like ingress filtering [RFC2827], are recommended
to validate transit traffic. In that sense, FCFS SAVI complements
ingress filtering, since it relies on ingress filtering to validate
transit traffic but is provides validation of local traffic, which is
not provided by ingress filtering. Hence, the security level is
increased by using these two techniques.
In addition, FCFS SAVI is designed to be used with locally assigned
IPv6 addresses, in particular with IPv6 addresses configured through
Stateless Address Auto-Configuration (SLAAC) [RFC4862]. Manually
configured IPv6 addresses can be supported by FCFS SAVI, but manual
configuration of the binding on the SAVI device provides higher
security and seems compatible with manual address management.
Additional considerations about how to use FCFS SAVI depending on the
type of address management used and the nature of the addresses is
discussed in the framework document [I-D.ietf-savi-framework].
Nordmark, et al. Expires October 15, 2011 [Page 4]
Internet-Draft FCFS SAVI April 2011
2.2. Constraints for FCFS SAVI design
FCFS SAVI is designed to be deployed in existing networks requiring a
minimum set of changes. For that reason, FCFS SAVI does not require
any changes in the hosts which source address is to be verified. Any
verification solely relies in the usage of already available
protocols. This means that 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.
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.
2.3. Address ownership proof
The main function performed by FCFS SAVI is to verify that the source
address used in data packets actually belongs to the originator of
the packet. Since FCFS SAVI scope is limited to the local link, the
originator of the packet is attached to the local link. In order to
define a source address validation solution, we need to define some
address ownership proof concept 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.
Since no host changes are acceptable, we need to find the means to
proof address ownership without requiring a new protocol. In FCFS
SAVI the address ownership proof is based in the First-Come First-
Serve principle. This means that the first host that claims a given
source address is the owner of the address until further notice.
More precisely, whenever a source address is used for the first time,
a state is created in the device that is performing the FCFS SAVI
function binding the source address to 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 must use the same binding anchor in
order to be compliant.
There are however additional considerations to be taken into account.
For instance, consider the case of a host that moves from one segment
of a LAN to another segment of the same subnetwork and it keeps the
same IP address. In this case, the host is still the owner of the IP
address, but the associated binding anchor may have changed. In
order to cope with this case, the defined FCFS SAVI behaviour implies
Nordmark, et al. Expires October 15, 2011 [Page 5]
Internet-Draft FCFS SAVI April 2011
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.
Note that this only applies to local traffic. Transit traffic
generated by a router would be verified using alternative techniques,
such as ingress filtering. SAVI checks would not be fulfilled by the
transit traffic, since the router is not the owner of the source
address contained in the packets.
2.4. Binding Anchor considerations
Any SAVI solution is not stronger than the binding anchor it uses.
If the binding anchor is easily spoofable (e.g. a 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 SAVI device is configured to drop
non-compliant packets, then the usage of SAVI may open a new vector
of Denial of Service attacks, based on spoofed binding anchors. For
that reason, in this document, we assume that the binding anchors
used by the SAVI solution are not easily spoofable (e.g. ports of a
switched network) and that the SAVI device can be configured to drop
non- compliant packets. For the rest of the document, we will assume
that the binding anchors are ports of a switched network.
2.5. SAVI Logging
While the primary goal of SAVI is simply to prevent improper use of
IP addresses, a secondary goal is to assist in traceability for
determining who an imp-roper actor is. For example, if a remote site
reports that a DoS (or component of a DDoS) is coming from the SAVI
site, SAVI enforcement can be a useful component in a response.
In order to support these and other similar activities, it is a good
idea if SAVI devices perform logging of the creation, modification,
or removal of address bindings. Any protocol support, such as SYSLOG
support for sending those logs to a common server, would be a topic
for a future separate document.
2.6. SAVI protection perimeter
SAVI provides perimetrical security. This means that the SAVI
devices form what can be called a SAVI protection perimeter and they
Nordmark, et al. Expires October 15, 2011 [Page 6]
Internet-Draft FCFS SAVI April 2011
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 SAVI devices are deployed in the
topology and on the configuration of the SAVI boxes.
The implication of this perimetrical security approach, is that there
is part of the topology that is inside the perimeter and part of the
topology that is outside the perimeter. This means that while
packets coming from interfaces connected to the external part of the
topology need to be validated by the SAVI device, packets coming from
interfaces connected to the the internal part of the topology do not
need to be validated. This significantly reduces the processing
requirements of the SAVI device. It also implies that each SAVI
device that is part of the perimeter, must be able to verify the
source addresses of the packets coming from the interfaces connected
to the external part of the perimeter. In order to do so, the SAVI
device binds the source address to a binding anchor.
One possible approach would be for every SAVI device to store binding
information about every source addresses in the subnetwork. This
means that every SAVI device would store a binding for each source
address of the local link. The problem with this approach is that it
imposes significant memory burden on the SAVI devices. In order to
reduce the memory requirements imposed to each device, the SAVI
solution described in this specification distributes the storage of
SAVI binding information among the multiple SAVI devices of a
subnetwork. The SAVI binding state is distributed across the SAVI
devices according to the following criteria: each SAVI device 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 SAVI protection perimeter. Since
all the untrusted packet sources are by definition in the external
part of the perimeter, this means that the packets generated by each
of the untrusted sources will reach the perimeter through one
interface of a SAVI device. The binding information for that
particular source address will be stored in this first SAVI device
the packet reaches to.
This means the SAVI binding information will be distributed across
multiple devices. In order to provide proper source address
validation, it is critical that the information distributed among the
different SAVI devices is coherent. In particular, it is important
to avoid that the same source address is bound to different binding
anchors in different SAVI devices. Should that occur, then it would
mean that two hosts are allowed to send packets with the same source
address, which is what SAVI is trying to prevent. In order to
preserve the coherency of the SAVI bindings distributed among the
Nordmark, et al. Expires October 15, 2011 [Page 7]
Internet-Draft FCFS SAVI April 2011
SAVI devices within a realm, the Neighbour Discovery (ND) protocol is
used, in particular the Neighbour Solicitation (NSOL) and Neighbour
Advertisement (NADV) messages. Before creating a SAVI binding in the
local SAVI database, the SAVI device will send a NSOL message
querying for the address involved. Should any host reply to that
message with a NADV message, the SAVI device that sent the NADV will
infer that a binding for that address exists in another SAVI device
and will not create a local binding for it. If no NADV message is
received as a reply to the NSOL, then the local SAVI device will
infer that no binding for that address exists in other SAVI device
and will create the local SAVI binding for that address. (NOTE that
the description included here is overly simplified to illustrate the
mechanism used to preserve the coherency of the binding databases of
the different SAVI devices. The actual SAVI mechanism normative
specification as described in Section 3 varies in the fact that in
some cases it is the SAVI device that generates the NSOL while in
other cases it simply forwards the NSOL generated by the end host,
and that the SAVI device will send multiple copies of the NSOL in
order to improve the reliability of the message exchange, among other
things).
So, summarizing, the proposed SAVI approach relies on the following
design choices:
o SAVI provides perimetrical security, so some interfaces of a SAVI
device will connect to the internal (trusted) part of the topology
and other interfaces will connect to the external (untrusted) part
of the topology.
o A SAVI device only verifies packets coming through one interface
connected to the untrusted part of the topology.
o A SAVI device only stores binding information for the source
addresses that are bound to binding anchors that correspond to
interfaces that connect to the untrusted part of the topology.
o SAVI uses the NSOL and NADV messages to preserve the coherency of
the SAVI binding state distributed among the SAVI devices within a
realm.
So, in a link that is constituted of multiple L2 devices, some of
which are SAVI capable and some of which are not, the SAVI capable
devices should be deployed forming a connected perimeter (i.e. that
no data packet can get inside the perimeter without passing through a
SAVI device). Packets that cross the perimeter will be validated
while packets that do no cross the perimeter are not validated (hence
SAVI protection is not provided for these packets). Consider the
deployment of SAVI in the topology depicted in the following picture:
Nordmark, et al. Expires October 15, 2011 [Page 8]
Internet-Draft FCFS SAVI April 2011
+--------+
+--+ +--+ +--+ | +--+ |
|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|
+--+ +--+
In the figure above, the SAVI protection perimeter is provided by 4
SAVI devices, namely SAVI1, SAVI2, SAVI3 and SAVI4. These devices
verify the source address and filter packets accordingly.
SAVI devices then have two types of ports: trusted ports and
validating ports.
o Validating ports (VPs) are those in which SAVI processing is
performed. This means that when a packet is received through one
of the validating ports, the SAVI processing and filtering will be
executed.
o Trusted ports (TPs) are those in which SAVI processing is not
performed. So, packets received through trusted ports are not
validated and no SAVI processing is performed in them.
Trusted ports are used for connections with the trusted
infrastructure, including the communication between SAVI devices, the
communication with routers and the communication of other switches
that while they are not SAVI devices, they only connect to trusted
Nordmark, et al. Expires October 15, 2011 [Page 9]
Internet-Draft FCFS SAVI April 2011
infrastructure (i.e. other SAVI devices, routers or other trusted
nodes). So, in the figure above, Port 3 of SAVI1 and port 1 of SAVI3
are trusted because the connect two SAVI devices. Port 4 of SAVI1,
port 3 of SAVI2, port 2 of SAVI3 and port 1 of SAVI4 are trusted
because the connect to SWITCH-A to which only trusted nodes are
connected. In the figure above, port 2 of SAVI2 and port 3 of SAVI3
are trusted ports because they connect to routers.
Validating ports are used for connection with non-trusted
infrastructure. In particular, hosts are normally connected to
validating ports. Non-SAVI switches that are outside of the SAVI
protection perimeter also are connected through validating port. In
particular, non-SAVI devices that connect directly to hosts or that
have no SAVI capable device between themselves and the hosts are
connected through a validating port. So, in the figure above, ports
1 and 2 of SAVI1, port 1 of SAVI2, port 4 of SAVI 3 are validating
ports because they connect to hosts. Port 4 of SAVI4 is also a
validating port because it is connected to SWITCH-B which is a non-
SAVI capable switch which is connected to hosts H5 and H6.
3. FCFS SAVI normative specification
3.1. FCFS SAVI Data structures
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:
o IP source address
o Binding anchor, such as Layer-2 address, port through which the
packet was received, etc
o Lifetime
o Status:either tentative, valid or testing
o Creation time: the value of the local clock when the entry was
firstly created
In addition to this, FCFS SAVI need to know what are the prefixes
that are directly connected, so it maintains a data structure called
the the FCFS SAVI prefix list, which contains:
o Prefix
o Interface where prefix is directly connected
Nordmark, et al. Expires October 15, 2011 [Page 10]
Internet-Draft FCFS SAVI April 2011
3.2. FCFS SAVI algorithm
3.2.1. Discovering on-link prefixes
In order to distinguish local traffic form transit traffic, the SAVI
device relies on the FCFS SAVI Prefix list, which contains the set of
on-link prefixes. A SAVI device MUST support the following two
methods for populating the Prefix List: Manual configuration and
Router Advertisement, as detailed next.
Manual configuration: A SAVI device MUST support manual configuration
of the on-link prefixes included in the Prefix List.
Router Advertisement: A SAVI device MUST support discovery of on-link
prefixes through Router Advertisement messages. The SAVI device will
learn the on-link prefixes following the procedure defined for a host
to process the Prefix Information options described in section 6.3.4
of [RFC4861] with the difference that the prefixes will be configured
in the FCFS SAVI Prefix List instead than in the ND Prefix List. In
addition, when the SAVI device boots, it MUST send a Router
Solicitation message as described in section 6.3.7 of [RFC4861],
using the unspecified source address.
3.2.2. Processing of transit traffic
The FCFS SAVI function is located in a forwarding device, such as a
router or a layer-2 switch. The following processing is performed
depending on the type of port the packet has been received through:
o If the data packet is received through a Trusted port, the data
packet is forwarded and no SAVI processing performed to the
packet.
o If the data packet is received through a Validating port, then the
SAVI function checks whether the received data packet is local
traffic or transit traffic. It does so by verifying if the source
address of the packet belongs to one of the directly connected
prefixes available in the receiving interface. It does so by
searching the FCFS SAVI Prefix List.
* If the IP source address does not belong to one of the local
prefixes of the receiving interface, this means that the data
packet is transit traffic and the packet SHOULD be discarded.
The FCFS SAVI function MAY send an ICMP Destination Unreachable
Error back to the source address of the data packet. (ICMPv6,
code 5 (Source address failed ingress/egress policy) should be
used).
* If the source address of the packet does belong to one of the
prefixes available in the the receiving port, then the SAVI
local traffic validation processes is executed as described
below.
Nordmark, et al. Expires October 15, 2011 [Page 11]
Internet-Draft FCFS SAVI April 2011
3.2.3. Processing of local traffic.
We describe next how the local traffic, including both control and
data packets are processed by the SAVI device using a state machine
approach.
The state machine described is for the binding of a given source IP
address in a given SAVI device. So this means that all the packets
described as inputs in the state machine above refer to that given IP
address. The key attribute is the IP address. The full state
information is:
o IP ADDRESS: IPAddr
o BINDING ANCHOR: P
o LIFETIME: LT
The possible states are:
o NO_BIND
o TENTATIVE
o VALID
o TESTING_TP
o TESTING_VP
o TESTING_LIFETIME
We will use VP for Validating Port and TP for Trusted Port.
After bootstrapping (when no binding exists), the state for all
source IP address is NO-BIND i.e. there is no binding for the IP
address to any binding anchor.
NO_BIND: The binding for a source IP address entry is in this state
when it does not have any binding to an anchor. All addresses are in
this state by default after bootstrapping, unless bindings were
created for it.
TENTATIVE: The binding for a source address for which a data packet
or a DAD_NSOL has been received is in this state during the waiting
period during which the DAD procedure is being executed (either by
the host itself the SAVI device on its behalf).
VALID: The binding for the source address is in this state after it
has been verified. It means that it is valid and usable for
filtering traffic.
TESTING_TP-LT: A binding for a source address enters in this state
due to one of two reasons:
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
Nordmark, et al. Expires October 15, 2011 [Page 12]
Internet-Draft FCFS SAVI April 2011
switch. This may due to an attack or to the fact that the host
may have moved. The binding in this state is then being tested to
determine which is the situation.
The lifetime of the binding 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.
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.
We describe next how the different inputs are processed depending on
the state of the binding of the IP address (IPAddr).
A simplified figure of the state machine is included below.
NO_BIND
o Upon the reception through a Validating Port (VP) of a Neighbour
Solicitation (NSOL) generated by the Duplicate Address Detection
(DAD) procedure (hereafter named DAD_NSOL) containing Target
Address IPAddr, the SAVI device MUST execute the process of
sending Neighbour Solicitation messages of the Duplicate Address
Detection process as described in section 5.4.2 of [RFC4862] for
the IPAddr using the following default parameters:
DupAddrDetectTransmits set to 2 (i.e. 2 Neighbour Solicitation
messages for that address will be sent by the SAVI device) and
RetransTimer set to 250 milliseconds (i.e. the time between two
Neighbour Solicitation messages is 250 millisecs). This is
equivalent to sending the received DAD_NSOL message twice. The
DAD_NSOL messages are not sent through any of the ports configured
as Validating Ports. The NSOL messages are sent through the
proper Trusted Ports (as defined by the switch behaviour that will
depend on whether it performs MLD snooping or not). The state is
moved to TENTATIVE. The LIFETIME is set to TENT_LT (i.e.
LT==TENT_LT), the LAYER_2 ANCHOR is set to VP (i.e. P==VP) and
the Creation time is set to the current value of the local clock.
Nordmark, et al. Expires October 15, 2011 [Page 13]
Internet-Draft FCFS SAVI April 2011
o Upon the reception through a Validating Port (VP) of a DATA packet
containing IPAddr as the source address, the SAVI device SHOULD
execute the process of sending Neighbour Solicitation messages of
the Duplicate Address Detection process as described in section
5.4.2 of [RFC4862] for the IPAddr using the following default
parameters: DupAddrDetectTransmits set to 2 (i.e. 2 Neighbour
Solicitation messages for that address will be sent by the SAVI
device) and RetransTimer set to 250 milliseconds (i.e. the time
between two Neighbour Solicitation messages is 250 millisecs).
The implications of not following the recommended behaviour are
described in Appendix A The DAD_NSOL messages are not sent through
any of the ports configured as Validating Ports. The NSOL
messages are sent through the proper Trusted Ports (as defined by
the switch behaviour that will depend on whether it performs MLD
snooping or not). The SAVI device MAY discard the data packet
while the DAD procedure is being executed. The state is moved to
TENTATIVE. The LIFETIME is set to TENT_LT (i.e. LT==TENT_LT),
the LAYER_2 ANCHOR is set to VP (i.e. P==VP) and the Creation
time is set to the current value of the local clock.
o Data packets containing IPAddr as the source address received
through Trusted ports are processed and forwarded as usual (i.e.
no special SAVI processing)
o DAD_NSOL packets containing IPAddr as the target address received
through a Trusted port are NOT forwarded through any of the
Validating ports but they are sent through the proper Trusted
Ports (as defined by the switch behaviour that will depend on
whether it performs MLD snooping or not)
o Neighbor Advertisement packets sent to all nodes as a reply to the
DAD_NSOL (hereafter called DAD_NADV) containing IPAddr as the
target address coming through a Validating port are discarded.
o Other signaling packets are processed and forwarded as usual (i.e.
no SAVI processing)
TENTATIVE
o If the LIFETIME times out, the state is moved to VALID. The
LIFETIME is set to DEFAULT_LT (i.e. LT== DEFAULT_LT). Stored
data packets are forwarded (if any).
o If a Neighbour Advertisement (NADV) is received through a Trusted
Port with Target Address set to IPAddr, then message is forwarded
through port P, the state is set to NO_BIND and the BINDING ANCHOR
and the LIFETIME are cleared. Data packets stored corresponding
to this binding are discarded.
o If a NADV is received through a Validating Port with Target
Address set to IPAddr, the NADV packet is discarded
o If a data packet with source address IPAddr is received with
binding anchor equal to P, then the packet is either stored or
discarded.
Nordmark, et al. Expires October 15, 2011 [Page 14]
Internet-Draft FCFS SAVI April 2011
o If a data packet with source address IPAddr is received through a
Trusted port, the data packet is forwarded. The state is
unchanged (waiting for the NADV).
o If a data packet with source address IPAddr is received through a
Validating port other than P, the data packet is discarded.
o If a DAD NSOL 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.
o If a DAD NSOL 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_DAD_NSOL, 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.
o Other signaling packets are processed and forwarded as usual (i.e.
no SAVI processing)
VALID
o If a data packet containing IPAddr as a source address arrives
from Validating port P, then the LIFETIME is set to DEFAULT_LT and
the packet is forwarded as usual.
o If a DAD_NSOL is received from a Trusted port, then the DAD_NSOL
message is forwarded to port P and it is also forwarded to the
proper Trusted Ports (as defined by the switch behaviour that will
depend on whether it performs MLD snooping or not). The state is
changed to TESTING_TP-LT. The LIFETIME is set to TENT_LT.
o If a data packet containing source address IPAddr or a DAD_NSOL or
DAD_NADV packet with target address set to IPAddr is received
through a Validating port P' other than P, then the SAVI device
will execute the process of sending DAD_NSOL messages as described
in section 5.4.2 of [RFC4862] for the IPAddr using the following
default parameters: DupAddrDetectTransmits set to 2 (i.e. 2 NSOL
messages for that address will be sent by the SAVI device) and
RetransTimer set to 250 milliseconds (i.e. the time between two
NSOL messages is 250 millisecs). The DAD_NSOL 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.
o If the LIFETIME expires, then the SAVI device will execute the
process of sending DAD_NSOL messages as described in section 5.4.2
of [RFC4862] for the IPAddr using the following default
parameters: DupAddrDetectTransmits set to 2 (i.e. 2 NSOL messages
for that address will be sent by the SAVI device) and RetransTimer
set to 250 milliseconds (i.e. the time between two NSOL messages
is 250 millisecs). The DAD_NSOL messages will be forwarded to the
Nordmark, et al. Expires October 15, 2011 [Page 15]
Internet-Draft FCFS SAVI April 2011
port P. The state is changed to TESTING_TP-LT and the LIFETIME is
set to TENT_LT.
o If a data packet containing IPAddr as a source address arrives
from Trusted port, the packet MAY be discarded. The event MAY be
logged.
o Other signaling packets are processed and forwarded as usual (i.e.
no SAVI processing). In particular DAD_NADV coming from port P
and containing IPAddr as the target address are forwarded as
usual.
TESTING_TP-LT
o If the LIFETIME expires, the BINDING ANCHOR is cleared and the
state is changed to NO_BIND
o If a NADV message containing the IPAddr as target address is
received through the Validating port P as a reply to the DAD_NSOL
message, then the NADV is forwarded as usual and the state is
changed to VALID. The LIFETIME is set to DEFAULT_LT
o If a data packet containing IPAddr as the source address is
received through port P, then the packet is forwarded and the
state is changed to VALID. The LIFETIME is set to DEFAULT_LT.
o If a DAD_NSOL is received from a Trusted port, the DAD NSOL is
forwarded as usual.
o If a DAD_NSOL is received from a Validating Port P' other than P,
the DAD_NSOL is forwarded as usual, the state is moved to
TESTING_VP.
o If a data packet is received through a Validating Port port P'
that is other than port P, then the packet is discarded.
o If a data packet is received through a Trusted Port port, then the
packet MAY be discarded. The event MAY be logged.
TESTING_VP
o If the LIFETIME expires, the BINDING ANCHOR is modified from P to
P', the LIFETIME is set to DEFAULT_LT and the state is changed to
VALID. Data packet stored coming from P' are forwarded.
o If a NADV message containing the IPAddr as target address is
received through the Validating port P as a reply to the DAD_NSOL
message, then the NADV is forwarded as usual and the state is
changed to VALID. The LIFETIME is set to DEFAULT_LT
o If a data packet containing IPAddr as the source address is
received through port P, then the packet is forwarded.
o If a data packet is received through a Validating Port P'' that is
other than port P or P', then the packet is discarded.
o If a data packet is received through a Trusted Port port that is
other than port P, the state is moved to TESTING_TP-LT, and the
packet MAY is discarded.
Nordmark, et al. Expires October 15, 2011 [Page 16]
Internet-Draft FCFS SAVI April 2011
o If a DAD_NSOL is received through Trusted Port, the packet is
forwarded as usual and the state is moved to TESTING_TP-LT.
o If a DAD_NSOL is received through Validating Port P'' other than P
or P', the packet is forwarded as usual and P'==P''
Simplified state machine figure
+---------+ VP_NSOL, VP_DATA/2xNSOL +-----------+
| |---------------------------------------->| |
| NO_BIND | | TENTATIVE |
| |<----------------------------------------| |
+---------+ TP_NADV, TP_NSOL/- +-----------+
^ |
| | T.O.
T.O.| |
| v
+---------+ VP_NADV/- +-----------+
| |---------------------------------------->| |
| TESTING | | VALID |
| TP-LT |<----------------------------------------| |
+---------+ TP_NSOL/- +-----------+
^ | ^ |
| | | |
| +--------------------- ---------------------+ |
| VP_NSOL/- | | NP_NADV, T.O./- |
| v | |
| +-----------+ |
| | | |
+---------------------| TESTING |<----------------------+
VP_NSOL, VP_DATA/- | VP | T.O., VP_DATA, VP_NSOL,
+-----------+ VP_NADV/2xNSOL
MLD considerations
The SAVI device must join the Solicited Node Multicast group for all
the addresses which state is other than NO_BIND. This is needed to
make sure that the SAVI device will receive the DAD_NSOL for those
addresses. Please note that it may not be enough to relay on the
host behind the Validating port doing so, since the node may move and
after a while, the packets for that particular solicited node
multicast group will no longer be forwarded to the SAVI device. So,
the SAVI device SHOULD join the solicited node multicast groups for
all the addresses that are in a state other than NO_BIND
3.2.4. SAVI port configuration guidelines
The guidelines for port configuration in SAVI devices are:
Nordmark, et al. Expires October 15, 2011 [Page 17]
Internet-Draft FCFS SAVI April 2011
o The SAVI realm (i.e. the realm that is inside the SAVI protection
perimeter) SHOULD be connected. If this is not the case,
legitimate transit traffic may be dropped.
o Ports that are connected to another SAVI device SHOULD be
configured as Trusted ports. Not doing so will significantly
increase the memory consumption in the SAVI devices and may result
in legitimate transit traffic being dropped.
o Ports connected to hosts SHOULD be configured as Validating ports.
Not doing so will allow the host connected to that port to send
packets with spoofed source address.
o Ports connected to routers MUST be configured as Trusted ports.
Configuring them as Validating ports should result in transit
traffic being dropped.
o Ports connected to a chain of one or more legacy switches that
have hosts connected SHOULD be configured as Validating ports.
Not doing so will allow the host connected to any of these
switches to send packets with spoofed source address.
o Ports connected to a chain of one or more legacy switches that
have other SAVI devices and/or routers connected but had no hosts
attached to them SHOULD be configured as Trusted ports. Not doing
so will at least significantly increase the memory consumption in
the SAVI devices and increase the signaling traffic due to SAVI
validation and may results in legitimate transit traffic being
dropped.
3.2.5. VLAN support
In the case the SAVI device is a switch that supports VLANs, the SAVI
implementation will behave as if there was one SAVI process per VLAN.
The SAVI process of each VLAN will store the binding information
corresponding the the nodes attached to that particular VLAN.
3.3. Protocol Constants
TENT_LT is 500 miliseconds
DEFAULT_LT is 5 minutes
4. Security Considerations
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 the binding anchor is a MAC address that can
be easily spoofed, then the resulting SAVI will not be stronger than
that. On the other hand, if we use switch ports as binding anchors
(and there is only one host connected to each port) it is likely that
Nordmark, et al. Expires October 15, 2011 [Page 18]
Internet-Draft FCFS SAVI April 2011
the resulting SAVI solution will be considerably more secure.
Denial of service attacks
There are two types of DoS attacks that can be envisaged in a SAVI
environment. On one hand, we can envision attacks against the SAVI
device resources. On the other hand, we can envision DoS attacks
against the hosts connected to the network where SAVI is running.
The attacks against the SAVI device basically consist on making the
SAVI device to consume its resource until it runs out of them. For
instance, a possible attack would be to send packets with different
source addresses, making the SAVI device to create state for each of
the addresses and waste memory. At some point the SAVI device runs
out of memory and it needs to decide how to react in this situation.
The result is that some form of garbage collection is needed to prune
the entries. It is RECOMMENDED that when the SAVI device runs out of
the memory allocated for the SAVI DB, it creates new entries by
deleting the entries which Creation Time is higher. This implies
that older entries are preserved and newer entries overwrite each
other. In an attack scenario where the attacker sends a batch of
data packets with different source address, each new source address
is likely to rewrite another source address created by the attack
itself. It should be noted that entries are also garbage collected
using the LIFETIME, which is updated using data packets. The result
is that in order for an attacker to actually fill the SAVI DB with
false source addresses, it needs to continuously send data packets
for all the different source addresses, in order for the entries to
grow old and compete with the legitimate entries. The result is that
the cost of the attack for the attacker is highly increased.
In addition, it is also RECOMMENDED that a 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 SAVI device may attempt to launch a DoS
attack towards the 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 SAVI device. The above recommendation aims to
reserve a minimum amount of memory per port, so that hosts located in
different ports can make use of the reserved memory for their port
even if a DoS attack is occurring in a different port.
As the 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
Nordmark, et al. Expires October 15, 2011 [Page 19]
Internet-Draft FCFS SAVI April 2011
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 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 an attacks as the above
described.
The other type of attack is when an attacker manages to create state
in the SAVI device that will result in blocking the data packets sent
by the legitimate owner of the address. In IPv6 these attacks are
not an issue thanks to the 2^64 addresses available in each link.
The SAVI device generates 2 DAD_NSOL packets upon the reception of a
DAD_NSOL or a data packet. As such, the SAVI device can be used as
an amplifier by attackers. In order to limit this type of attack, it
is RECOMMENDED that the SAVI device 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
SAVI device to function normally in the rest of the ports.
Residual threats.
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, SAVI validation will
be successful and the 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 others IP
address and this will not be detected by the SAVI device. This can
be prevented by not sharing binding anchors among hosts.
FCFS SAVI assumes that a host will be able to defend its address when
the DAD procedure is executed for its addresses. This is needed,
among other things, to support mobility within a link (i.e. to allow
a host to detach and reconnect to a different Layer_2 anchor of the
same IP subnetwork, without changing its IP address). This means
that when a DAD_NSOL is issued for a given IP address for which a
binding exists in a SAVI device, the SAVI device expects to see a
DAD_NADV coming from the binding anchor associated to that IP address
in order to preserve the binding. If the SAVI device does not sees
the DAD_NADV, it may grant the binding to a different binding anchor.
This means that if an attacker manages to prevent a host from
Nordmark, et al. Expires October 15, 2011 [Page 20]
Internet-Draft FCFS SAVI April 2011
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_NADV or
launching a DoS attack to the host that will prevent it to issue
proper DAD replies.
Security Logging
In order to improve the integration of SAVI into an overall security
environment, and enable response to additional indirect security
issues which SAVI can help ameliorate, it is helpful if SAVI systems
log the creation, modification, and deletion of binding entries.
5. Contributors
Jun Bi
CERNET
Network Research Center, Tsinghua University
Beijing 100084
China
Email: junbi@cernet.edu.cn
Guang Yao
CERNET
Network Research Center, Tsinghua University
Beijing 100084
China
Email: yaog@netarchlab.tsinghua.edu.cn
Fred Baker
Cisco Systems
Email: fred@cisco.com
Alberto Garcia Martinez
University Carlos III of Madrid
Email: alberto@it.uc3m.es
6. Acknowledgments
This draft benefited from the input from: Joel Halpern, Christian
Vogt, Dong Zhang, Frank Xia, Jean-Michel Combes and Lin Tao.
Marcelo Bagnulo is partly funded by Trilogy, a research project
supported by the European Commission under its Seventh Framework
Program.
Nordmark, et al. Expires October 15, 2011 [Page 21]
Internet-Draft FCFS SAVI April 2011
7. References
7.1. Normative References
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
7.2. Informative References
[I-D.ietf-savi-framework]
Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt,
"Source Address Validation Improvement Framework",
draft-ietf-savi-framework-04 (work in progress),
March 2011.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, April 2006.
Appendix A. Implications of not following the reccommended behaviour
This specification recommends SAVI implementations to generate a
DAD_NSOL 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.
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 w 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.
Nordmark, et al. Expires October 15, 2011 [Page 22]
Internet-Draft FCFS SAVI April 2011
A.1. Lack of binding state due to packet loss
The DAD procedure is inherently unreliable. It consists on sending a
NSOL packet and if no NADV 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
NSOL packet or the NADV 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.
It should be noted that the loss of a DAD packet has little impact on
the network performance, since address coalition 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 lost of a single packet would imply
that a host is disconnected from the network.
The only mechanism that the DAD has to improve its reliability is to
send multiple NSOL. However, current RFC4862 defines a default value
of 1 NSOL message for the DAD procedure, so requiring any higher
value would imply manual configuration of all the hosts connected to
the SAVI domain.
A.1.1. Why initial packets may be (frequently) lost
The case of LANs
Devices connecting to a network may experience periods of packet loss
after the link-layer becomes available for two reasons: Invalid
Authentication state and incomplete topology assessment. In both
cases, physical-layer connection occurs initially and presents a
medium where packeted are transmissible, but frame forwarding is not
available across the LAN.
For the authentication system, devices on a controlled port are
forced to complete 802.1X authentication which may take multiple
round trips and many milliseconds to complete (see IEEE 802.1X-2004).
In this time, initial DHCP, IPv6 Neighbour Discovery, Multicast
Listener or Duplicate Address Detection messages may be transmitted.
However, it has also been noted that some devices have the ability
Nordmark, et al. Expires October 15, 2011 [Page 23]
Internet-Draft FCFS SAVI April 2011
for the IP stack to not see the port as up until 802.1x has
completed. Hence, that issue needs investigation to determine how
common it is now.
Additionally, any system 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.
Upon completion of authentication, it is feasible to signal upper
layer protocols as to LAN forwarding availability. This is not
typical today, so it is necessary to assume that protocols are not
aware of the preceding loss period.
For environments 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).
Until a port is determined to be an edge port (RSTP/MSTP), the rapid
protocol speaker has identified its position within the spanning-tree
(RSTP/MSTP) or completed a Listening phase (STP), its packets are
discarded.
For ports 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). This means that during this
period, the link-layer appears available, but initial packet
transmissions into and out of this port will fail.
It is possible to pre-assess ports as edge ports using manual
configuration of all the involved devices and thus make them
immediately transmissible. This is never default behaviour though.
The case fixed access networks
In fixed access networks such as DSL and Cable the end hosts are
usually connected to the access network through a residential gateway
(RG). If the host interface is initialized prior to the 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
Nordmark, et al. Expires October 15, 2011 [Page 24]
Internet-Draft FCFS SAVI April 2011
message that is required to create such state.
A.1.1.1. Special sub-case:SAVI device rate-limiting packets
A particular sub-case is the one where the SAVI device itself "drops"
ND packets. In order to protect itself against DoS attacks and
flash-crowds, the SAVI device will have to rate-limit the processing
of packets triggering the state creation process (which 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 NSOL packet, which implies that the data
packets coming from the host that sent the DAD NSOL 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.
A.2. Lack of binding state due to a change in the topology
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:
+------+ +--------+ +---------------+
|SAVI I|-------------|SWITCH I|-------|rest of the net|
+------+ +--------+ +---------------+
| |
| +--------+
| | SAVI II|
| +--------+
| +----------+ |
+---|SWITCH II |-----+
+----------+
|
+-----+
| Host|
+-----+
Suppose that after bootstrapping all the elements are working
Nordmark, et al. Expires October 15, 2011 [Page 25]
Internet-Draft FCFS SAVI April 2011
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.
Suppose that the Host boots at this moment and sends the DAD NSOL.
The message is propagated through the spanning tree and it received
by SAVI I but not by SAVI II. SAVI I creates the binding.
Suppose that SAVI I fails and the spanning tree reconverges to SWITCH
I- SAVI II- SWITCH II. Now data packets coming from the Host will be
coursed through SAVI II which does not have binding state and will
drop the packets.
A.3. Lack of binding state due to state loss
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.
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:
An end-to-end protocol design should not rely on the maintenance
of state (i.e. information about the state of the end-to-end
communication) inside the network. Such state should be
maintained only in the endpoints, in such a way that the state can
only be destroyed when the endpoint itself breaks (known as fate-
sharing).
By binding the fate of the host's connectivity to the state in the
SAVI device, we are breaking this principle and the result is
degraded network resilience.
Moving on to more practical matters, we can dig deeper into the
actual 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.
A.3.1. The case of a host directly connected to the SAVI device
The considered scenario is depicted in the following picture:
Nordmark, et al. Expires October 15, 2011 [Page 26]
Internet-Draft FCFS SAVI April 2011
+------+ +-----------+ +---------------+
| Host |-------------|SAVI device|-------|rest of the net|
+------+ +-----------+ +---------------+
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.
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:
Duplicate Address Detection MUST be performed on all unicast
addresses prior to assigning them to an interface, regardless of
whether they are obtained through stateless autoconfiguration,
DHCPv6, or manual configuration, with the following exceptions:...
However, it has been stated that some of the widely used 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.
A.3.2. The case of a host connected to the SAVI device through one or
more legacy devices.
The considered scenario is depicted in the following picture:
+------+ +-------------+ +-----------+ +---------------+
| Host |------|Legacy device|-------|SAVI device|-------|rest of the net|
+------+ +-------------+ +-----------+ +---------------+
Nordmark, et al. Expires October 15, 2011 [Page 27]
Internet-Draft FCFS SAVI April 2011
The key distinguishing element of this scenario is that the host is
not directly connected to the SAVI device. As a result, if the SAVI
device reboots, the host will not see any changes.
In this case, the host would get 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.
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.
A.3.2.1. Enforcing direct connectivty between the SAVI device and the
host
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:
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.
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 a robust network service,
but it is not bad enough to enforce the direct connectivity of
host to the SAVI switch.
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.
Nordmark, et al. Expires October 15, 2011 [Page 28]
Internet-Draft FCFS SAVI April 2011
Authors' Addresses
Erik Nordmark
Cisco
510 McCarthy Blvd.
Milpitas, California 95035
UNITED STATES
Email: nordmark@acm.org
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
SPAIN
Phone: 34 91 6248814
Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
Eric Levy-Abegnoli
Cisco Systems
Village d'Entreprises Green Side - 400, Avenue Roumanille
Biot-Sophia Antipolis - 06410
France
Email: elevyabe@cisco.com
Nordmark, et al. Expires October 15, 2011 [Page 29]
