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]