| Network Working Group | F. Baker |
| Internet-Draft | Cisco Systems |
| Intended status: Informational | October 21, 2014 |
| Expires: April 24, 2015 |
Requirements and Use Cases for Source/Destination Routing
draft-baker-rtgwg-src-dst-routing-use-cases-01
This note attempts to capture important use cases for source/destination routing.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 24, 2015.
Copyright (c) 2014 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 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 Simplified BSD License.
Source/Destination routing has been proposed in the IPv6 community and specifically in homenet as a means of dealing with multihomed networks whose upstream networks give them provider-allocated addresses. An initial approach was suggested in [RFC3704], which assumed that a packet following a default route to an egress CPE Router might arrive at the wrong one, and need to be redirected to the right CPE Router. Subsequent approaches, including those listed in the bibliography, have focused on using routing protocols or routing procedures with extensions that make decisions based on both the source and the destination address.
"Source/Destination Routing" is defined as routing in which both the source and the destination address must be considered in selecting the next hop. It might be thought of as routing "to a destination with a constraint" - a router might have multiple routes to a given destination, and follow the one that also obeys the constraint, or it might have only one route to a destination but correctly fail to forward a packet that doesn't meet the constraint. From that perspective, the logic here extends to other cases in which a constraint might be placed on the route. As with all routing, a primary requirement is to follow the longest-match-first rule to the destination; following a less specific route may well take traffic to the wrong place.
As a side note, source address spoofing in this case will be limited to addresses from the indicated source prefixes, obviating the need for upstream ingress filtering. Ingress filtering within the domain in LAN switches can prevent spoofing of addresses within those prefixes.
This note attempts to capture common use cases. These will be in terms of a general statement of intent coupled with a specific example of the intent for clarity. The use cases are obviously not limited to these, but these should be a reasonably complete set.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
The use cases proposed here are not an exhaustive set, but are representative of a set of possibilities. At least three are presently-deployed use cases; the fourth is a possible use case within an edge network.
One use case is as shown in Figure 1. A customer network has two or more upstream networks, and a single CPE Router. Each upstream network allocates a prefix for use in the customer network, and the customer network configures a subnet from each of those ISP prefixes on each of its LANs. The CPE Router advertises default routes into the network that are "from" each PA prefix. Apart from prefix itself, the services of the upstream ISPs are indistinguishable; they each get the customer to the Internet.
,-------.
,-' `-.
,---. ,-----. ,' `.
/ \ ,' `. / \
/ \ ( ISP 1 --+--- \
/ \ / `. ,' ; :
; Customer : +-+/ `-----' | The Internet |
| Network +-+R|\ ,-----. : ;
: ; +-+ \ ,' `. \ /
\ / ( ISP 2 ---+-- /
\ / `. ,' `. ,'
\ / `-----' '-. ,-'
`---' `-------'
Figure 1: Egress Routing in a Multihomed Environment with One CPE Router
The big issue in this network is, of course, ingress filtering [RFC2827] by the upstream ISP. If packets intended for a remote destination pass through the wrong ISP, they will be blocked. In the ideal case, traffic following default route gets to the upstream network indicated by its source address.
The CPE Router could, at least in concept, advertise a single default route into the network, as all traffic to an upstream ISP must pass through that CPE Router. However, should another CPE Router be added later, it would have to change its behavior to accomodate that CPE Router (as in Section 2.2). Hence, the single CPE Router must advertise two default routes into the network, one "from" each PA prefix.
In this case, the destination prefix in routing is a default route, ::/0. The source prefix is the prefix allocated by the ISP. In this case, routing within the network is largely unchanged, as all traffic to another network goes to the CPE Router, but the CPE Router must send it to the correct ISP.
Note that in this use case, if there are other routers or internal routes in the network, there is no need for them to specify source prefixes on their routes, and if they do, the prefix specified is likely to be :;/0. The reason is that traffic arriving from the ISPs must be delivered to destinations within the network, so routing cannot preclude them.
A more general use case is as shown in Figure 2. A customer network has two or more upstream networks, with a separate CPE Router for each one. Each upstream network allocates a prefix for use in the customer network, and the customer network configures a subnet from each of those ISP prefixes on each of its LANs. Each CPE Router advertises a default route into the customer network. Apart from prefix itself, the services of the upstream ISPs are indistinguishable; they each get the customer to the Internet.
,-------.
,-' `-.
,---. ,-----. ,' `.
/ \ +-+ ,' `. / \
/ +---+R+-+ ISP 1 --+--- \
/ \ +-+ `. ,' ; :
; Customer : `-----' | The Internet |
| Network | ,-----. : ;
: ; +-+ ,' `. \ /
\ +--+R+-+ ISP 2 ---+-- /
\ / +-+ `. ,' `. ,'
\ / `-----' '-. ,-'
`---' `-------'
Figure 2: Egress Routing in a Multihomed Environment
The big issue in this network is again ingress filtering [RFC2827] by the upstream ISP. If packets intended for a remote destination pass through the wrong ISP, they will be blocked. Traffic following default route gets to the upstream network indicated by its source address.
In this case, the destination prefix in routing is a default route, ::/0. The source prefix is the prefix allocated by the ISP. We want a routing algorithm that sends packets matching such a specification to the CPE Router advertising that default route.
Note that in this use case, if there are other routers or internal routes in the network, there is no need for them to specify source prefixes on their routes, and if they do, the prefix specified is likely to be :;/0. The reason is that traffic arriving from the ISPs must be delivered to destinations within the network, so routing cannot preclude them.
A more specialized use case is as shown in Figure 3. A customer network has two or more upstream networks, with one or more CPE Routers; the example shows a separate CPE Router for each one. Each upstream network allocates a prefix for use in the customer network, and the customer network configures a subnet from each of those ISP prefixes on each of its LANs. Some CPE Routers might advertise a default route into the customer network; one or more of the other CPE Routers, perhaps all of them, advertise a more-specific route. The services offered by the upstream networks differ in some important way.
,-------.
,-' `-.
,---. ,-----. ,' `.
/ \ +-+ ,' `. / \
/ +---+R+-+ ISP 1 --+--- \
/ \ +-+ `. ,' ; :
; Customer : `-----' | The Internet |
| Network | ,-----. : ;
: ; +-+ ,' `. \ /
\ +--+R+-+ ISP 2 ) \ /
\ / +-+ `. ,' `. ,'
\ / `--+--' '-. ,-'
`---' | `-------'
Some specialized
Service
Figure 3: Egress Routing with a specialized upstream network
A specific example of such a service is the NTT B-FLETS video service in Japan; however, the use case describes any use with one or more walled gardens. In the B-FLETS case, a customer may purchase services from a number of ISPs, providing general Internet access. However, the video service requires customers accessing it to use its allocated prefix, and other ISPs (following [RFC2827]) will not accept that prefix as a source address. This is similar to the previous use cases, but
The big issue in this network is, once again, ingress filtering [RFC2827] by the upstream ISP, with the additional caveat that the upstream services are far from identical. If packets intended for a remote destination pass through the wrong ISP, they will be blocked. Additionally, while other ISPs advertise access to the general Internet, they may not provide service to the specialized service in question. Hence, egress routing in this case also ensures delivery to the intended destination using the bandwidth it provides. In the ideal case, traffic following default route gets to the upstream network indicated by its source address.
In this case, one or more ISPs might offer a default route as a destination prefix in routing, ::/0. The source prefix is the prefix allocated by the ISP. In addition, the ISP offering the specialized service advertises one or more specific prefixes for those services, with appropriate source prefixes for their use. We want a routing algorithm that sends packets matching such a specification to the CPE Router advertising that indicated route, and dropping, perhaps with an ICMPv6 response, packets for which it effectively has no route.
Note that in this use case, if there are other routers or internal routes in the network, there is no need for them to specify source prefixes on their routes, and if they do, the prefix specified is likely to be :;/0. The reason is that traffic arriving from the ISPs must be delivered to destinations within the network, so routing cannot preclude them.
A use case within the confines of a single network is as shown in Figure 4. A network has one or more internal networks with differing access permission sets; the financial servers might only be accessible from a set of other prefixes that financial people are located in, or university grade records is only reachable from the offices of professors. This could be implemented using firewalls between the domains, or using application layer filters; in this case, the routing architecture replaces an exclusive firewall rule.
In this case, each domain advertises reachability to its prefix, listing acceptable source prefixes. Domains that are willing to be generally reached might advertise ::/0 as a source prefix, or the prefix in use in the general domain.
_.--------------.
_.-'' `---.
,-'' `--.
,' `.
,' ,---------. ,---------. `.
/ ( Domain 1 ) ( Domain 2 ) \
; `---------' `---------' :
| Inter-domain |
: Backbone ;
\ ,---------. ,---------. /
`. ( Domain 3 ) ( Domain 4 ) ,'
`. `---------' `---------' ,'
`--. _.-'
`---. _.-''
`--------------''
Figure 4: Intradomain Access Control
The big issue in this network is a difference in policy.
The use cases in can each be met if:
This memo asks the IANA for no new parameters.
As a descriptive document, this note adds no new security risks to the network.
As a descriptive document, this note adds no new privacy risks to the network.
This note was discussed with Acee Lindem, Jianping Wu, Juliusz Chroboczek, Les Ginsberg Lorenzo Colitti, Mark Townsley, Markus Stenberg, Matthieu Boutier, Ole Troan, Ray Bellis, Shu Yang, and Xia Yin.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [I-D.baker-fun-routing-class] | Baker, F., "Routing a Traffic Class", Internet-Draft draft-baker-fun-routing-class-00, July 2011. |
| [I-D.baker-ipv6-isis-dst-src-routing] | Baker, F., "IPv6 Source/Destination Routing using IS-IS", Internet-Draft draft-baker-ipv6-isis-dst-src-routing-01, August 2013. |
| [I-D.baker-ipv6-ospf-dst-src-routing] | Baker, F., "IPv6 Source/Destination Routing using OSPFv3", Internet-Draft draft-baker-ipv6-ospf-dst-src-routing-03, August 2013. |
| [I-D.boutier-homenet-source-specific-routing] | Boutier, M. and J. Chroboczek, "Source-specific Routing", Internet-Draft draft-boutier-homenet-source-specific-routing-00, July 2013. |
| [I-D.troan-homenet-sadr] | Troan, O. and L. Colitti, "IPv6 Multihoming with Source Address Dependent Routing (SADR)", Internet-Draft draft-troan-homenet-sadr-01, September 2013. |
| [I-D.xu-homenet-traffic-class] | Xu, M., Yang, S., Wu, J. and F. Baker, "Traffic Class Routing Protocol in Home Networks", Internet-Draft draft-xu-homenet-traffic-class-02, April 2014. |
| [RFC2827] | Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. |
| [RFC3704] | Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. |