Network Working Group M. Bagnulo Internet-Draft UC3M Intended status: Informational J. Halpern Expires: September 9, 2010 Ericsson March 8, 2010 Analysis of data-triggered binding creation in SAVI draft-bagnulo-savi-analysis-01 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 9, 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 Bagnulo & Halpern Expires September 9, 2010 [Page 1] Internet-Draft SAVI Analisys March 2010 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the 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 . . . . . . . . . . . . . . . . . . . . . 8 3. The DHCP case . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Potential issues with an approach that treats packets as non compliant packets . . . . . . . . . . . . . . . . . 9 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 5. Informative References . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Bagnulo & Halpern Expires September 9, 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 & Halpern Expires September 9, 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 & Halpern Expires September 9, 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.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. 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: Bagnulo & Halpern Expires September 9, 2010 [Page 5] Internet-Draft SAVI Analisys March 2010 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. 2.1.2.1. The case of a host directly connected to the SAVI device The considered scenario is depicted in the following picture: +------+ +-----------+ +---------------+ | 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 Bagnulo & Halpern Expires September 9, 2010 [Page 6] Internet-Draft SAVI Analisys March 2010 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. 2.1.2.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| +------+ +-------------+ +-----------+ +---------------+ 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. 2.1.2.2.1. Enforcing direct connectivty between the SAVI device and the host Some people have 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: Bagnulo & Halpern Expires September 9, 2010 [Page 7] Internet-Draft SAVI Analisys March 2010 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. 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: It 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. Another argument against this option has to do with the added complexity. It is obvious that since this approach is a superset of the previous one it is more complex. In particular, since the SAVI device needs to react upon data packets, it would require more processing power than the alternative approach. (this requires more elaboration) Bagnulo & Halpern Expires September 9, 2010 [Page 8] Internet-Draft SAVI Analisys March 2010 NOTE:Is there any other argument against this option? 3. The DHCP case Similar to the ND case, the DHCP based SAVI will create a binding state after observing the message exchange that results in a successful IP address assignment from the DHCP server tot he host. The question is what to do with data packets for which there is no binding state. Similar to the ND case, the options are either to treat it as a non compliant packet (i.e. drop) or to trigger the binding creation procedure. However, at the time of this writing, only the details of a solution that treat these packets as non compliant have been fleshed out and it is not clear how a solution that triggers the binding creation would work. So, in this section, we mostly point out some issues that may require some thought when considering a solution that treats data packets for which there is no binding as non compliant packets and the impact that such solution could have on the overall performance of the network. The DHCP case is different than the ND case, for two main reasons: o The DHCP exchange is reliable and in case of failure the node does not acquire an address (as opposed to the ND case, which is unreliable and that in case of DAD packet getting lost, the host does acquire the address). o Some of the address assignment information is stored in the DHCP server, so in case of failure, there is a central repository to retrieve some of the information. 3.1. Potential issues with an approach that treats packets as non compliant packets Since the DHCP exchange is reliable, the arguments based on packet loss do not apply to the DHCP case. We then only need to consider the arguments based on state loss. We need to distinguish the two topologies analyzed in the ND case, namely, the case of the host directly connected to the SAVI device and the case of the host connected to a legacy device. In the case the host is directly connected to the SAVI device, the DHCP specification (RFC3315) reads: Whenever a client may have moved to a new link, the prefixes from the addresses assigned to the interfaces on that link may no longer be appropriate for the link to which the client is attached. Examples of times when a client may have moved to a new link include: Bagnulo & Halpern Expires September 9, 2010 [Page 9] Internet-Draft SAVI Analisys March 2010 * The client reboots. * The client is physically connected to a wired connection. * The client returns from sleep mode. * The client using a wireless technology changes access points. In any situation when a client may have moved to a new link, the client MUST initiate a Confirm/Reply message exchange. It is not clear what should a host do when for instance the AP that it is directly connected to reboots. In this case, the access point is still the same, so there is not clear guidance on RFC3315. there are claims that some OSes do redo the Confirm/Reply exchange when the link flaps, but further data would be required to take this for granted. Assuming that behviour, we could rely on the same trick described earlier, about requiring the SAVI process to flap all the links of the device it is running on, in order to deal with SAVI process failure modes that do not imply a reboot of the whole device. In the case the host is connected to a legacy device, the rebooting of the SAVI device would not result in the host performing a Confirm/ Reply exchange. In this case, it is not clear (to us at least) how the SAVI device could restore the lost SAVI binding state. One option could be to try to retrieve it from the DHCP server. One potential problem with that is that it is not obvious that the DHCP server knows the lower layer anchor information. In addition, that would require a protocol between the SAVI device and the DHCP server. Another possible option would be that the SAVI device forces the host to perform a Confirm/Reply exchange, but since they are not directly connected, it is not obvious how this could be done. 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. Bagnulo & Halpern Expires September 9, 2010 [Page 10] Internet-Draft SAVI Analisys March 2010 Authors' Addresses Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6248814 Email: marcelo@it.uc3m.es URI: http://www.it.uc3m.es Joel M. Halpern Ericsson Phone: 1 703 371 3043 Email: joel.halpern@ericsson.com Bagnulo & Halpern Expires September 9, 2010 [Page 11]