One document matched: draft-bagnulo-savi-analysis-00.txt
Network Working Group M. Bagnulo
Internet-Draft UC3M
Intended status: Informational March 1, 2010
Expires: September 2, 2010
Analysis of data-triggered binding creation in SAVI
draft-bagnulo-savi-analysis-00
Abstract
The goal of this document is to serve as input to the design of the
Source Address Validation architecture being defined in the SAVI WG.
In particular, it analyses the different ways to handle data packets
for which no binding exists, and the impact of the different
approaches in the overall performance of the network.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 2, 2010.
Copyright Notice
Copyright (c) 2010 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
Bagnulo Expires September 2, 2010 [Page 1]
Internet-Draft SAVI Analisys March 2010
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Neighbour Discovery case . . . . . . . . . . . . . . . . . 3
2.1. Arguments against option 1: treat packets as non
compliant packets . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Lack of binding state due to packet loss . . . . . . . 4
2.1.2. Lack of binding state due to state loss . . . . . . . . 5
2.2. Arguments against option 2: trigger the process of
binding creation . . . . . . . . . . . . . . . . . . . . . 7
3. The DHCP case . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Informative References . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Bagnulo Expires September 2, 2010 [Page 2]
Internet-Draft SAVI Analisys March 2010
1. Introduction
The SAVI WG is chartered to produce a solution for address validation
with local scope. The basic idea in SAVI is to include some SAVI
devices in the topology that would enforce the proper usage of the
source IP addresses contained in the packets. A major constraint in
SAVI design is that SAVI must not require any changes to end hosts.
This basically implies that the SAVI enforcers need to be able to
determine which host is authorized to use which IP address. The
proposed approaches for SAVI all concur that the SAVI device should
sniff the control packets that are related to address assignment, in
particular, DHCP and ND. By sniffing those packets the SAVI device
can discover which host is legitimately using which address and
create a binding for that address. The existence of a binding in a
SAVI device implies that the SAVI device has information of which
node is authorized to use the address contained in the binding, and
any packet contained that address that is coming from a different
point of the topology will be treated as a non-compliant packet (e.g.
discarded). One aspect where there is still ongoing debate is how to
handle data packets for which there is no binding. The main question
here is whether to treat as a compliant packet or a non-compliant
one. There are many tradeoffs involved in that design choice. The
goal of this note is to explore the tradeoffs and serve as input to
the ongoing debate.
2. The Neighbour Discovery case
In the case of Neighbour Discovery (ND), the messages that are used
to create bindings in the SAVI device are the Neighbour Solicitation
(NSOL) and potentially the Neighbour Advertisement (NADV) that are
exchanged during the Duplicate Address Detection (DAD) procedure.
Each node that configures an IP address performs the DAD procedure by
sending a NSOL for the address it is about to configure in its
interface. If no NADV is received, the address is assumed to be
unused and it is configured in the interface. In terms of SAVI, we
have mentioned that the SAVI device will create a binding when it
observes a successful DAD procedure for a given address, binding the
address for the DAD procedure was executed to the lower layer anchor
used by the node performing the DAD.
The question that we need to address is: what does the SAVI device
should do with data packets for which is has no binding information
i.e. addresses for which the SAVI device has not observed a DAD NSOL
message? The possible options are:
1. Treat the packet as a non compliant packet (which in most of the
cases means to discard it)
Bagnulo Expires September 2, 2010 [Page 3]
Internet-Draft SAVI Analisys March 2010
2. Trigger the process of creating a binding (whatever that is).
Eventually, if the binding is successfully created, data packets
coming from that lower layer anchor will be compliant and hence
forwarded.
We will next consider the impact of the above options in the design
of a SAVI solution.
2.1. Arguments against option 1: treat packets as non compliant packets
The main argument against this approach is the overall robustness of
the resulting network. The main concern that has been stated is that
a network running SAVI that implements this option 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 two different causes that resulted in the
lack of state in the binding device for a legitimate address, namely,
packet loss or state loss. We will next perform an analysis for each
of them.
2.1.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
Bagnulo Expires September 2, 2010 [Page 4]
Internet-Draft SAVI Analisys March 2010
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.
Special cases
o Networks where the first few packets are systematically lost
(DNA?)
o Optimistic DAD
2.1.2. 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 explanation of 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.
The case of a host directly connected to the SAVI device.
The considered scenario is depicted in the following picture:
Bagnulo Expires September 2, 2010 [Page 5]
Internet-Draft SAVI Analisys March 2010
+------+ +-----------+ +---------------+
| 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. In our case, 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 device and that the SAVI link does not
goes down. In this case, the host would not redo the DAD procedure.
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|
+------+ +-------------+ +-----------+ +---------------+
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
Bagnulo Expires September 2, 2010 [Page 6]
Internet-Draft SAVI Analisys March 2010
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. Some people have
argued that enforcing the direct connectivity between the SAVI device
and the end host is actually a feature. That may well be the case in
some scenarios, but it is certainly not the case in most scenarios.
Moreover, the resulting behaviour 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.
2.2. Arguments against option 2: trigger the process of binding
creation
The main argument against the option of using data packets for which
there is no binding to trigger the binding creation process is as
follows:
OIt has been stated that some switch architectures would not be
able to implement a SAVI solution that triggers complex actions
based on data packets. The argument is that some architectures
may be able to perform simple actions such as forward or discard,
but they wouldn't be able to do more complex actions, such as
triggering the binding creation process, that would likely imply
sending some packets and creating the binding internally. It has
been accepted though, that some switch architectures would be able
to trigger the binding creation procedure upon the reception of a
data packet. So, if a solution would rely on triggering the
binding creation as the result of receiving a data packet, it
seems to be the case that some implementations would not be able
to comply with the resulting RFC while some other implementations
would.
NOTE:Is there any other argument against this option?
3. The DHCP case
TBD
Bagnulo Expires September 2, 2010 [Page 7]
Internet-Draft SAVI Analisys March 2010
4. Acknowledgments
Marcelo Bagnulo is partly funded by Trilogy, a research project
supported by the European Commission under its Seventh Framework
Program and by the Telefonica Chair at University Carlos III of
Madrid..
5. Informative References
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996.
Author's Address
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
Bagnulo Expires September 2, 2010 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 09:36:51 |