Internet DRAFT - draft-draves-ipngwg-ingress-filtering
draft-draves-ipngwg-ingress-filtering
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
