IPng Working Group Richard Draves Internet Draft Microsoft Research Document: draft-draves-ipngwg-ingress-filtering-00.txt May 18, 2001 Ingress Filtering, Site Multihoming, and Source Address Selection Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [1]. 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. Abstract This draft discusses some issues surrounding ingress filtering by IPs, site multihoming, and source address selection. The problem is that in a site which has prefixes from multiple ISPs, the source address selected by a host might be inconsistent with the egress ISP for a particular destination address. If the ISP deploys source- address-based ingress filtering, the host will be unable to communicate with the destination. The draft proposes some possible approaches towards a solution. 1. Introduction Site multihoming occurs when a site is attached to multiple ISPs. In one model for site multihoming, the site acquires a site prefix for each ISP. The multiple site prefixes are all advertised within the site, so each host in the site acquires multiple addresses. Some ISPs perform source-address-based ingress filtering. Their access routers drop packets arriving from a customer, if the source address in the packet does not match the site prefix that the ISP has allocated to the customer. The routing within a site is based on destination address and does not consider source address. Some destination addresses may be Draves Expires December 2001 1 draft-draves-ipngwg-ingress-filtering-00 May 18, 2001 routed to one ISP, and other destination addresses routed towards another ISP. Putting this all together creates a problem for source address selection on the hosts. If the host chooses the wrong source address for a destination, its packets will be dropped when they arrive at the ISP. 2. Possible Approaches to a Solution 2.1. Sites with One Link If the site has one link then the problem is simplified. Suppose that each ISP router attached to the link advertises its own prefix. The host can remember which router advertised which prefix. When the host selects a router for a particular destination address, the host can also be careful to select a source address from a prefix advertised by that router. More generally, this works if each router interface forwards all received packets towards a single ISP. Then that router interface puts in its RAs just the prefix associated with the ISP to which it forwards. However, this doesn't work in many common situations. For example, suppose the site contains a leaf link, attached to the site by a single router. The hosts on the leaf link have a single default router and they will acquire prefixes from multiple ISPs from the single router. 2.2. Prefix Policy Configuration The default source address selection algorithm [2] provides for administrative configuration via a prefix policy table. The prefix policy table allows the administrator to specify source address prefixes which should preferentially be used when communicating with given destination address prefixes. The intra-site routing partitions the space of destination addresses into prefixes that are routed towards each ISP. This information, assuming it is available to the administrator, may be used to configure the prefix policy table on each host and hence avoid having packets dropped due to incorrect choice of source address. One complicating factor is that the partition may not be constant across the site. In other words, when host A in the site sends to destination D, the packet may be routed towards ISP X and when host B in the site sends to destination D, the packet may be routed towards ISP Y. This means host A and host B would need different prefix policy configuration. Conceivably, the prefix policy configuration could be automatically determined by the intra-site routers, since they have knowledge of Draves Expires December 2001 2 draft-draves-ipngwg-ingress-filtering-00 May 18, 2001 the routing, and distributed to the hosts via a new Router Advertisement option. 2.3. New ICMP Error Suppose that when an ISP's access router drops a packet because it fails a source-address-based ingress check, that the access router generates a new type of ICMP error. The ICMP error would contain (in option data) the allowed source prefix (or list of prefixes?) for the destination address. When a host receives this new ICMP error, it can remember the allowed source address prefix(es) in its Destination Cache Entry for the destination address. This would influence source address selection for that destination. This is analogous to maintaining the Path MTU in the Destination Cache Entry. One problem with this approach is that the ICMP error will take an awkward path to reach the host. If ISP A is generating the error, then that means the offending packet's source address belongs to another ISP B's prefix. Hence the ICMP error, which is sent to that source address, will travel back to the site via ISP B instead of directly from ISP A's access router back to the site. Besides being inefficient, it may be that the path via ISP B to the site is not working and hence the ICMP error won't make it to the site. After all, one reason for site multihoming is to be robust to such ISP failures. Possibly an exception could be made to the usual method of generating the ICMP error in ISP A's access router, so that this particular ICMP error is forced back out the same interface (towards the site) by which the offending packet arrived. Or perhaps a more principled way to achieve this effect: use a routing header (or encapsulation?) in the ICMP error to route the error to an anycast address based on the site prefix. For example, when ISP A's access router generates the error because the packet's source address A doesn't match the prefix P that ISP A allocated to the site, then it uses a routing header to first send the error to an anycast address equal to prefix P (this anycast address being assigned to all routers within the site) and from there to the normal destination, address A. Then the usual routing within ISP A will take the packet directly back to the site without transitting any other ISP. There are a couple fairly reasonable assumptions in this idea. First, the prefix P would be a /48. So the assumption is that the subnet-router anycast address idea (for /64 prefixes) would be extended to other prefix lengths. Second, it assumes "convex" routing within the site. That is, it assumes that once the ICMP error packet made it to any router in the site (via the anycast address P), then the path back to the originating host (address A) would lie entirely within the site. If this assumption is false (for Draves Expires December 2001 3 draft-draves-ipngwg-ingress-filtering-00 May 18, 2001 example if the site border router directly connected to ISP A has a default route pointing to ISP A and does not have a more-specific route for address A), then the ICMP error would leave the site, transit ISP B, and reenter the site. References 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 R. Draves, "Default Address Selection for IPv6", draft-ietf- ipngwg-default-addr-select-04.txt, May 2001. Acknowledgments This draft derives from discussions with Christian Huitema, Dave Thaler, and Brian Zill. Author's Address Richard Draves Microsoft Research One Microsoft Way Redmond, WA 98052 Phone: 1-425-936-2268 Email: richdr@microsoft.com Draves Expires December 2001 4 draft-draves-ipngwg-ingress-filtering-00 May 18, 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Draves Expires December 2001 5