Network Working Group C. Huitema Internet-Draft R. Draves Expires: April 4, 2006 Microsoft M. Bagnulo UC3M October 2005 Ingress filtering compatibility for IPv6 multihomed sites draft-huitema-shim6-ingress-filtering-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 April 4, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The note presents a set of mechanisms to provide ingress filtering compatibility for legacy hosts in IPv6 multihomed sites. Huitema, et al. Expires April 4, 2006 [Page 1]
Internet-Draft Ingress filtering and multihoming October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Reference topology . . . . . . . . . . . . . . . . . . . . . . 4 3. The problem: Ingress filtering incompatibility . . . . . . . . 5 4. Goals and non goals of the presented solution . . . . . . . . 6 4.1. Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Non-goals . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Relaxing the ingress filtering . . . . . . . . . . . . . . 7 5.2. Source Address Dependent (SAD) routing . . . . . . . . . . 8 5.2.1. Single site exit router . . . . . . . . . . . . . . . 8 5.2.2. DMZ . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2.3. General case . . . . . . . . . . . . . . . . . . . . . 10 6. Appendix A: Host based optimization . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Huitema, et al. Expires April 4, 2006 [Page 2]
Internet-Draft Ingress filtering and multihoming October 2005 1. Introduction A way to solve the issue of site multihoming is to have a separate site prefix for each connection of the site, and to derive as many addresses for each hosts. This approach to multi-homing has the advantage of minimal impact on the inter-domain routing fabric, since each site prefix can be aggregated within the larger prefix of a specific provider; however, it opens a number of issues, that have to be addressed in order to provide a multihoming solution compatible with such addressing scheme. In this memo we will present a set of mechanisms to deal with the problem created by the interaction between ingress filtering [3] and legacy hosts in multihomed sites. The remaining of this memo is structured as follows: we will first present the reference topology and then the problem created by the interaction of ingress filtering and multihoming. Then, we will state the goals and non goals of the mechanisms presented in this memo. Next the proposed mechanisms are described. The Appendix A include a possible optimization for the case that the host within the multihomed site involved in the communication has special multihoming support. Huitema, et al. Expires April 4, 2006 [Page 3]
Internet-Draft Ingress filtering and multihoming October 2005 2. Reference topology In the following discussion, we will use this reference topology: /-- ( A ) ---( ) --- ( C ) --\ X (site X) ( IPv6 ) (Site Y) Y \-- ( B ) ---( ) --- ( D ) --/ The topology features two hosts, X and Y, whose respective sites are both multi-homed. Host X has two global IPv6 addresses, which we will note "A:X" and "B:X", formed by combining the prefixes allocated by ISP A and B to "site X" with the host identifier of X. Similarly, Y has two addresses "C:Y" and "D:Y". We assume that X, when it starts engaging communication with Y, has learned the addresses C:Y and D:Y, for example because they were published in the DNS. We assume that Y, when it receives packets from X, has only access to information contained in the packet coming from X, e.g. the source address; we do not assume that Y can retrieve by external means the set of addresses associated to X. Huitema, et al. Expires April 4, 2006 [Page 4]
Internet-Draft Ingress filtering and multihoming October 2005 3. The problem: Ingress filtering incompatibility Ingress filtering refers to the verification of the source address of the IP packets at the periphery of the Internet, typically at the link between a customer and an ISP. This process, which is described in [3] is intended to thwart a class of denial of service attacks in which attackers hide their identity by using a "spoofed" source address. A special complication appears when the ISPs who serve the multihomed site perform ingress filtering. In the above configuration, X is served by ISP A and B, and thus can be reached by the addresses A:X and B:X. In addition Y is served by ISP C and D, and thus can be reached by the addresses C:Y and D:Y. To communicate with Y, X will choose the destination address that appears to be easier to reach, for example D:Y; then, it will choose the source address that provides the most efficient reverse path, say A:X. Suppose now that the ISP connections at Site X are managed by two different site exit routers, RXA and RXB, and that there is a similar configuration at Site Y, with routers RYC and RYD. /-- ( A ) ---( ) --- ( C ) --\ (RXA) ( ) (RYC) X (site X) ( IPv6 ) (Site Y) Y (RXB) ( ) (RYD) \-- ( B ) ---( ) --- ( D ) --/ Within Site X, the interior routing will decide which of RXA or RXB is the preferred exit router for the destination "D:Y"; similarly, within Site Y, the interior routing will decide which of RYC or RYD is the preferred exit for destination A:X. If the chosen exit router at Site X is RXA, the packet will flow freely to RYD; If the chosen exit router at Site Y is RYD, the response will also flow freely. However, if the exit routers are RXB or RYC, and if the ISPs perform ingress filtering, we have a problem: ISP B sees a packet coming from RXB, whose source address does not match the prefix assigned by B to X; ISP C, similarly, sees a packet whose source address does not match the prefix assigned by that ISP to Y. If either of these ISPs decides to drop the packet, the communication will be broken. Similar problems can also occur in communications between a host within a multihomed site and a host within a single-homed site. Huitema, et al. Expires April 4, 2006 [Page 5]
Internet-Draft Ingress filtering and multihoming October 2005 4. Goals and non goals of the presented solution 4.1. Goal The goal of the proposed solution is to provide ingress filtering compatibility for legacy hosts in multihomed environments, as described in RFC 3582 [2] . "The solution should not destroy IPv6 connectivity for a legacy host implementing RFC 3513 [4] , RFC 2460 [1] , RFC 3493 [5], and other basic IPv6 specifications current in April 2003. That is to say, if a host can work in a single-homed site, it should still be able to work in a multihomed site, even if it cannot benefit from site- multihoming. It would be compatible with this goal for such a host to lose connectivity if a site lost connectivity to one transit provider, despite the fact that other transit provider connections were still operational."[sic] So, the goal of the presented solution is to enable a communication of two legacy hosts when at least one of them is in multihomed site, as long as no outage has occurred in the connectivity. 4.2. Non-goals - It is not a goal of the presented solution to provide a complete multihoming solution. In particular, the presented solution does not provide fault tolerance capabilities (it does not preserve established communication through outages nor it enable hosts to initiate communications after an outage). So, the presented solution is a single component of a multihoming solution. Huitema, et al. Expires April 4, 2006 [Page 6]
Internet-Draft Ingress filtering and multihoming October 2005 5. Proposed solution In order to support legacy hosts, the addresses included in packets must be honored i.e. cannot be changed after that the host that is initiating the communication has selected them. So, there are two possible approaches to provide ingress filtering compatibility: to relax the ingress filtering or to perform some form of source address dependent routing. Both mechanisms will be presented next. 5.1. Relaxing the ingress filtering An obvious way to avoid failures due to ingress filtering is to simply make sure that all the addresses used by the hosts of a given site will be considered acceptable by each of the site's providers. In our site X example, that would mean that provider A would accept addresses of the form "B:X" as valid, and that provider B will in turn accept addresses of the form "A:X" as valid. One way to achieve this is simply to ask the service provider to turn off source address checks on the site connection. This requires a substantial amount of trust between the provider and the site, as source address checks are in effect delegated to the site routers. One possible way to achieve this trust is to make sure that the site routers, or possibly the site firewalls, meet a quality level specified by the provider. Another way to achieve this relaxed level of checking is to check source addresses against a list of "authorized prefixes" for the site connection, rather than simply the single prefix delegated by the provider. This solution requires that the site communicates the authorized prefixes to the provider, either through a management interface or through a routing protocol. This is obviously more complex than simply lifting the controls, and in fact ends up with a very similar requirement of trust: the provider has to be believe that the site will transmit the right prefixes. In conclusion, relaxing the source address checks requires some form of explicit trust between the site and its providers. There is no doubt that this level of trust will exist in many cases; there is also no doubt that there will be many cases in which the provider is unwilling to grant this trust, particularly in the case of small sites, such as for example home networks dual-homes to a DSL provider and a cable network provider. So, this solution is a perfectly reasonable solution for large sites, i.e. the sites that benefit of IPv4 multihoming today: it should not be more complex to convince a provider to relax address checks for a particular customer tomorrow, than to convince today a similar provider to advertise in its routing table the global IPv4 address of the site. If we choose this Huitema, et al. Expires April 4, 2006 [Page 7]
Internet-Draft Ingress filtering and multihoming October 2005 solution, we should choose its simplest implementation, i.e. one in which the provider completely delegates source address checks to the site's router or firewalls. This is however not a general solution, since we cannot expect all sites to convince every provider to relax their checks. 5.2. Source Address Dependent (SAD) routing In order to provide ingress filtering compatibility it is possible to perform some kind of Source Address Dependent (SAD) routing within the site, so that the site exit is effectively a function of the source address in the packet. It should be noted that SAD routing does not have to be supported by all the routers of the multihomed site, but its support is only required to a connected domain that includes all the site exit routers as in the next figure: Multiple site exits | | | | -----+-----+-----+-----+----- ( ) ( SAD routing domain ) ( ) ----+----+----+----+----+---- ( ) ( Generic routing domain ) ( ) ----------------------------- In this schema, all site exit routers are connected to a SAD routing domain. Packets initiated in the generic routing domain and bound to an "out of site" address are passed to the nearest access point to the SAD routing domain, using classic "hot potato" routing. The routers in the SAD routing domain maintain as many parallel routing tables as there are valid source prefixes, and would choose a route that is a function of both the source and the destination address; the packets exit the site through the "right" router. There are multiple possible implementations of this general concept, depending on the site topology and the amount of routers involved. We will next present different scenarios and how SAD routing can be adopted in each of them. 5.2.1. Single site exit router The simplest implementation is to have only one exit router for the site; in this case, the SAD routing domain is reduced to the exit router itself. This exit router chooses the exit link on the basis Huitema, et al. Expires April 4, 2006 [Page 8]
Internet-Draft Ingress filtering and multihoming October 2005 of the source address in the packet. Many of the commercial routers already support this functionality so the solution in this cases could be easily adopted. 5.2.2. DMZ A slightly less complex implementation is to connect all site exit routers to the same link, e.g. to what is often referred to as the "DMZ" for the site. This solution requires that all site exit routers connected to the DMZ support SAD routing. In this case, when a site exit router receives a packet, it verifies the source address; if the source address corresponds to its directly connected ISP, the site exit router forwards the packet through the ISP; if the source address of the packet does not corresponds to the directly connected ISP, the site exit router forwards the packet to the site exit router which ISP corresponds to the source address included in the packet. In the case that a DMZ is not naturally available in the site, it is possible to create a virtual DMZ by using a mesh of tunnels between the site exit routers. In this case, a site exit router that receives a packet bound for an out-of-site address would perform a source address check before forwarding the packet on one of its outgoing interfaces; if the source address check is positive, the packet will effectively be sent on the interface; if it is not, the packet would be "tunneled" to the appropriate router. The main requirement of the DMZ alternative is that site-exit routers be able to perform address checks, and that each site exit router be able to associate to each valid site prefix the address of a corresponding site exit router. An obvious possibility is to configure prefixes and corresponding addresses in each router; it would however be preferable to derive these addresses automatically. An assumption of the IPv6 architecture is that all prefixes of a site will have the same length; it is thus possible to derive a prefix from the source address of a "misdirected" packet, by combining this prefix with a conventional suffix. The suffix should be chosen to not collide with the subnet numbers used in the site; a null value will be inadequate, since it could be matched by any router with knowledge of the prefix, not just the site exit router; a value of "all ones" could be adequate. So, each router managing a site prefix will then inject a "host route" announcing the anycast address associated to its locally managed prefixes in the interior routing protocol. Site exit routers can then use the standard routing procedures to detect whether the anycast address corresponding to the prefix in use is reachable; they can automatically reject, rather than forward, packets whose source address does not correspond to a reachable anycast address. Huitema, et al. Expires April 4, 2006 [Page 9]
Internet-Draft Ingress filtering and multihoming October 2005 An inconvenience of this set-up is that some packet will follow a less than direct path; in the case of a natural DMZ, the additional path is probably negligible. However, in the case of a mesh of tunnels, the additional path may be significant, so this is not by itself a definitive solution. A possibility is to use this approach to support legacy hosts within the multihomed site and complement the solution by adopting the host based mechanism presented in Appendix A to allow upgraded host to select the optimal path. Another possibility is to use this approach as a way to "phase in" a full SAD routing solution described in the next section. 5.2.3. General case In the most general set up, SAD routing is supported in all the site exit routers and all the internal routers required to create a connected SAD routing domain. Each router of the SAD domain would maintain as many parallel routing tables as there are valid source prefixes, and would choose a route that is a function of both the source and the destination address. Depending on how routes to external destinations are configured in routers the amount of work required to support SAD routing varies considerably. 5.2.3.1. Manual configuration If routes to external destinations are manually configured, then the manual configuration of additional routes corresponding to each of the available prefixes is required. So, if within the multihomed site there are n prefixes and each router has m external routes configured, then (n-1)m additional routes need to be configured per router of the SAD routing domain. It should be noted than multiple commercial routers currently support manually configured SAD routing, so this solution is already available. It should also be noted that the usage of manually configured static routes does not preclude the fault tolerance capabilities of a multihoming solution, since fault tolerance is achieved by changing the prefix used for the communication, which is likely to be performed by the host itself, and not by the routing system. However, obtaining dynamic routing information may help the host to detect outages and enable faster response to outages. 5.2.3.2. Dynamic configuration Information about external routes can be propagated within the multihomed site using a routing protocol, whether a IGP or BGP. Huitema, et al. Expires April 4, 2006 [Page 10]
Internet-Draft Ingress filtering and multihoming October 2005 In order to support SAD routing in this scenario, routing protocols also have to convey information about the prefix associated with routing information that is being propagated. That is the prefix corresponding to the ISP through which the routing information was obtained. When BGP is used, it would be possible to use a private community attribute to encode such information. However, current commercial routers don't support updating the different routing tables required to support SAD routing based on a BGP attribute (as far as we know). In the general case, it is possible to run multiple instances of the routing protocol and associate each instance to a prefix, so that each instance of the routing protocol only carries information learned through the ISP corresponding to the prefix. However, our preliminary tests on this mechanisms seem to indicate that such mechanism wouldn't be currently supported by commercial routers. It should be noted that having dynamic routing information about external routes does not provide fault tolerance to the multihomed sites as it did in IPv4-style multihoming, since, in sites with multiple prefixes, fault tolerance requires changing the prefix used for the communication. However, having dynamic routing information available does provide a faster feedback about failures, enabling faster response to outages. Huitema, et al. Expires April 4, 2006 [Page 11]
Internet-Draft Ingress filtering and multihoming October 2005 6. Appendix A: Host based optimization In this Appendix we present a host based mechanism to provide ingress filtering compatibility. The mechanism, called "Exit router discovery", enables the host to discover the preferred exit router for a given source address so that the host can tunnel the packet directly to the adequate exit router, obtaining optimal site exit path. Exit router discovery is a natural complement of the tunneling mechanism between site exit routers. When an exit router tunnels a misdirected packet towards another exit, it may send an appropriate ICMP Destination Unreachable error message with code 5 which means source address failed ingress policy. If the host is a legacy host, the ICMP message will be ignored; further packets will continue using the same slightly sub-optimal path. On the other hand, if the host has been upgraded to take advantage of multi-homing, the packets will be tunneled to the appropriate exit router; they will follow a direct path to this router. So, according to this mechanisms presented in this memo, site exit routers are expected to perform necessary source address checks before forwarding any packet on a site exit link. The amount of checking will vary depending on the exit link. If the provider has agreed to relax source address checking, the router will be configured to not do any checking at all; if the provider is expected to enforce a source address check, the site exit router must do the check first, in order to avoid local packets being routed to a black hole. If the result of the check is positive, the packet will be forwarded. If the result is negative, the router will derive a "site exit anycast address" from the source address of the incoming packet. If the anycast address is unreachable, the incoming packet will have to be discarded. If the anycast address is reachable, the incoming packet will be tunneled towards that address, and the router may issue a ICMP Destination Unreachable error message with code 5 which means source address failed ingress policy. The reception of the ICMP packet is interpreted by the host implementing the exit discovery mechanism as an indication that the exit path being used is suboptimal. So, the host will first generate the site exit anycast address that corresponds to the source prefix of the packet that caused the generation of the ICMP packet (this is possible because the ICMP message payload contains enough information about the initial packet). Then, the host will associate this site exit anycast address to the source and destination address pair of the initial packet, and then tunnel packets directly to that exit router which will decapsulate these packets and send them over the appropriate exit link. Huitema, et al. Expires April 4, 2006 [Page 12]
Internet-Draft Ingress filtering and multihoming October 2005 This mechanism requires a change to the caches used in neighbor discovery, specifically the management of a "source exit cache" that associates a specific source address with an exit router, or maybe the combination of a destination address and a source address with an exit router. We should note that "exit router discovery" is not implemented in current hosts. We must meet the requirement expressed in RFC 3582 that hosts implementing the current version of IPv6 can continue to operate in a multi-homed site, even if they would not take advantage of multihoming; in consequence, these procedures can only be used as an optional optimization. It should also be noted that the presented mechanism does not requires any support from the host outside the multihomed site. Huitema, et al. Expires April 4, 2006 [Page 13]
Internet-Draft Ingress filtering and multihoming October 2005 7. Security Considerations There are elements presented in this draft that require further analysis from a security point of view: the usage of the anycast address of the site exit router associated to a given prefix and the usage of ICMP error messages to redirect following packets. The usage of the anycast address of the site exit router router associated to a given prefix may enable potential attacks where the attacker announces the anycast address associated with a certain perifx and sinks the traffic containing such prefix in the source address. However, this threat is similar to the case where an attacker simply injects a route in the interior routing system, for instance a default route, sinking the packets of those routers and hosts that preffer such route. An attacker could generate false ICMP errors to trigger the tunnelling of packets to the anycast address associated with the prefix of the source address. However, the result of such attack would simply be that packets are tunnelled through the appropriate site exit router. In the worst case, the packet would carry an extra tunnel header that would not be really required, causing additional overhead. In any case, these attack does not seem to cause cosniderable harm. Huitema, et al. Expires April 4, 2006 [Page 14]
Internet-Draft Ingress filtering and multihoming October 2005 8. Acknowledgments This memo contains parts of a previous work entitled "Host-Centric IPv6 Multihoming" that benefited from comments from Alberto Garcia Martinez, Cedric de Launois, Brian Carpenter, Dave Crocker, Xiaowei Yang and Erik Nordmark. 9. References [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [2] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- Multihoming Architectures", RFC 3582, August 2003. [3] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2267, January 1998. [4] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [5] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, March 2003. Huitema, et al. Expires April 4, 2006 [Page 15]
Internet-Draft Ingress filtering and multihoming October 2005 Authors' Addresses Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA Phone: Email: huitema@microsoft.com URI: Richard Draves Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA Phone: Email: richdr@microsoft.com URI: Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6249500 Email: marcelo@it.uc3m.es URI: http://www.it.uc3m.es Huitema, et al. Expires April 4, 2006 [Page 16]
Internet-Draft Ingress filtering and multihoming October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Huitema, et al. Expires April 4, 2006 [Page 17]