idnits 2.17.1 draft-baker-rtgwg-src-dst-routing-use-cases-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 13, 2013) is 3880 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.baker-fun-routing-class' is defined on line 373, but no explicit reference was found in the text == Unused Reference: 'I-D.baker-ipv6-isis-dst-src-routing' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'I-D.baker-ipv6-ospf-dst-src-routing' is defined on line 382, but no explicit reference was found in the text == Unused Reference: 'I-D.boutier-homenet-source-specific-routing' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'I-D.troan-homenet-sadr' is defined on line 392, but no explicit reference was found in the text == Unused Reference: 'I-D.xu-homenet-traffic-class' is defined on line 397, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-baker-ipv6-isis-dst-src-routing-00 == Outdated reference: A later version (-03) exists of draft-baker-ipv6-ospf-dst-src-routing-02 == Outdated reference: A later version (-01) exists of draft-troan-homenet-sadr-00 == Outdated reference: A later version (-02) exists of draft-xu-homenet-traffic-class-00 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F.J. Baker 3 Internet-Draft Cisco Systems 4 Intended status: Informational August 13, 2013 5 Expires: February 14, 2014 7 Requirements and Use Cases for Source/Destination Routing 8 draft-baker-rtgwg-src-dst-routing-use-cases-00 10 Abstract 12 This note attempts to capture important use cases for source/ 13 destination routing. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on February 14, 2014. 32 Copyright Notice 34 Copyright (c) 2013 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 50 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2.1. Simple Egress Routing . . . . . . . . . . . . . . . . . . 3 52 2.2. General Egress Routing . . . . . . . . . . . . . . . . . 4 53 2.3. Specialized Egress Routing . . . . . . . . . . . . . . . 5 54 2.4. Intra-domain access control . . . . . . . . . . . . . . . 7 55 3. Derived Requirements . . . . . . . . . . . . . . . . . . . . 8 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 58 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 62 8.2. Informative References . . . . . . . . . . . . . . . . . 8 63 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Introduction 68 Source/Destination routing has been proposed in the IPv6 community 69 and specifically in homenet as a means of dealing with multihomed 70 networks whose upstream networks give them provider-allocated 71 addresses. An initial approach was suggested in [RFC3704], which 72 assumed that a packet following a default route to an egress CPE 73 Router might arrive at the wrong one, and need to be redirected to 74 the right CPE Router. Subsequent approaches, including those listed 75 in the bibliography, have focused on using routing protocols or 76 routing procedures with extensions that make decisions based on both 77 the source and the destination address. 79 "Source/Destination Routing" is defined as routing in which both the 80 source and the destination address must be considered in selecting 81 the next hop. It might be thought of as routing "to a destination 82 with a constraint" - a router might have multiple routes to a given 83 destination, and follow the one that also obeys the constraint, or it 84 might have only one route to a destination but correctly fail to 85 forward a packet that doesn't meet the constraint. From that 86 perspective, the logic here extends to other cases in which a 87 constraint might be placed on the route. As with all routing, a 88 primary requirement is to follow the longest-match-first rule to the 89 destination; following a less specific route may well take traffic to 90 the wrong place. 92 As a side note, source address spoofing in this case will be limited 93 to addresses from the indicated source prefixes, obviating the need 94 for upstream ingress filtering. Ingress filtering within the domain 95 in LAN switches can prevent spoofing of addresses within those 96 prefixes. 98 This note attempts to capture common use cases. These will be in 99 terms of a general statement of intent coupled with a specific 100 example of the intent for clarity. The use cases are obviously not 101 limited to these, but these should be a reasonably complete set. 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 2. Use Cases 111 The use cases proposed here are not an exhaustive set, but are 112 representative of a set of possibilities. At least three are 113 presently-deployed use cases; the fourth is a possible use case 114 within an edge network. 116 2.1. Simple Egress Routing 118 One use case is as shown in Figure 1. A customer network has two or 119 more upstream networks, and a single CPE Router. Each upstream 120 network allocates a prefix for use in the customer network, and the 121 customer network configures a subnet from each of those ISP prefixes 122 on each of its LANs. The CPE Router advertises default routes into 123 the network that are "from" each PA prefix. Apart from prefix 124 itself, the services of the upstream ISPs are indistinguishable; they 125 each get the customer to the Internet. 127 ,-------. 128 ,-' `-. 129 ,---. ,-----. ,' `. 130 / \ ,' `. / \ 131 / \ ( ISP 1 --+--- \ 132 / \ / `. ,' ; : 133 ; Customer : +-+/ `-----' | The Internet | 134 | Network +-+R|\ ,-----. : ; 135 : ; +-+ \ ,' `. \ / 136 \ / ( ISP 2 ---+-- / 137 \ / `. ,' `. ,' 138 \ / `-----' '-. ,-' 139 `---' `-------' 141 Figure 1: Egress Routing in a Multihomed Environment with One CPE 142 Router 144 The big issue in this network is, of course, ingress filtering 145 [RFC2827] by the upstream ISP. If packets intended for a remote 146 destination pass through the wrong ISP, they will be blocked. In the 147 ideal case, traffic following default route gets to the upstream 148 network indicated by its source address. 150 The CPE Router could, at least in concept, advertise a single default 151 route into the network, as all traffic to an upstream ISP must pass 152 through that CPE Router. However, should another CPE Router be added 153 later, it would have to change its behavior to accomodate that CPE 154 Router (as in Section 2.2). Hence, the single CPE Router must 155 advertise two default routes into the network, one "from" each PA 156 prefix. 158 In this case, the destination prefix in routing is a default route, 159 ::/0. The source prefix is the prefix allocated by the ISP. In this 160 case, routing within the network is largely unchanged, as all traffic 161 to another network goes to the CPE Router, but the CPE Router must 162 send it to the correct ISP. 164 Note that in this use case, if there are other routers or internal 165 routes in the network, there is no need for them to specify source 166 prefixes on their routes, and if they do, the prefix specified is 167 likely to be :;/0. The reason is that traffic arriving from the ISPs 168 must be delivered to destinations within the network, so routing 169 cannot preclude them. 171 2.2. General Egress Routing 173 A more general use case is as shown in Figure 2. A customer network 174 has two or more upstream networks, with a separate CPE Router for 175 each one. Each upstream network allocates a prefix for use in the 176 customer network, and the customer network configures a subnet from 177 each of those ISP prefixes on each of its LANs. Each CPE Router 178 advertises a default route into the customer network. Apart from 179 prefix itself, the services of the upstream ISPs are 180 indistinguishable; they each get the customer to the Internet. 182 ,-------. 183 ,-' `-. 184 ,---. ,-----. ,' `. 185 / \ +-+ ,' `. / \ 186 / +---+R+-+ ISP 1 --+--- \ 187 / \ +-+ `. ,' ; : 188 ; Customer : `-----' | The Internet | 189 | Network | ,-----. : ; 190 : ; +-+ ,' `. \ / 191 \ +--+R+-+ ISP 2 ---+-- / 192 \ / +-+ `. ,' `. ,' 193 \ / `-----' '-. ,-' 194 `---' `-------' 196 Figure 2: Egress Routing in a Multihomed Environment 198 The big issue in this network is again ingress filtering [RFC2827] by 199 the upstream ISP. If packets intended for a remote destination pass 200 through the wrong ISP, they will be blocked. Traffic following 201 default route gets to the upstream network indicated by its source 202 address. 204 In this case, the destination prefix in routing is a default route, 205 ::/0. The source prefix is the prefix allocated by the ISP. We want 206 a routing algorithm that sends packets matching such a specification 207 to the CPE Router advertising that default route. 209 Note that in this use case, if there are other routers or internal 210 routes in the network, there is no need for them to specify source 211 prefixes on their routes, and if they do, the prefix specified is 212 likely to be :;/0. The reason is that traffic arriving from the ISPs 213 must be delivered to destinations within the network, so routing 214 cannot preclude them. 216 2.3. Specialized Egress Routing 218 A more specialized use case is as shown in Figure 3. A customer 219 network has two or more upstream networks, with one or more CPE 220 Routers; the example shows a separate CPE Router for each one. Each 221 upstream network allocates a prefix for use in the customer network, 222 and the customer network configures a subnet from each of those ISP 223 prefixes on each of its LANs. Some CPE Routers might advertise a 224 default route into the customer network; one or more of the other CPE 225 Routers, perhaps all of them, advertise a more-specific route. The 226 services offered by the upstream networks differ in some important 227 way. 229 ,-------. 230 ,-' `-. 231 ,---. ,-----. ,' `. 232 / \ +-+ ,' `. / \ 233 / +---+R+-+ ISP 1 --+--- \ 234 / \ +-+ `. ,' ; : 235 ; Customer : `-----' | The Internet | 236 | Network | ,-----. : ; 237 : ; +-+ ,' `. \ / 238 \ +--+R+-+ ISP 2 ) \ / 239 \ / +-+ `. ,' `. ,' 240 \ / `--+--' '-. ,-' 241 `---' | `-------' 242 Some specialized 243 Service 245 Figure 3: Egress Routing with a specialized upstream network 247 A specific example of such a service is the NTT B-FLETS video service 248 in Japan; however, the use case describes any use with one or more 249 walled gardens. In the B-FLETS case, a customer may purchase 250 services from a number of ISPs, providing general Internet access. 251 However, the video service requires customers accessing it to use its 252 allocated prefix, and other ISPs (following [RFC2827]) will not 253 accept that prefix as a source address. This is similar to the 254 previous use cases, but 256 o the only application at that "ISP" is the video service, 258 o packets using the video service MUST use the video service's 259 source and destination addresses, and 261 o no other service will accept a video service address as a source 262 address. 264 The big issue in this network is, once again, ingress filtering 265 [RFC2827] by the upstream ISP, with the additional caveat that the 266 upstream services are far from identical. If packets intended for a 267 remote destination pass through the wrong ISP, they will be blocked. 268 Additionally, while other ISPs advertise access to the general 269 Internet, they may not provide service to the specialized service in 270 question. Hence, egress routing in this case also ensures delivery 271 to the intended destination using the bandwidth it provides. In the 272 ideal case, traffic following default route gets to the upstream 273 network indicated by its source address. 275 In this case, one or more ISPs might offer a default route as a 276 destination prefix in routing, ::/0. The source prefix is the prefix 277 allocated by the ISP. In addition, the ISP offering the specialized 278 service advertises one or more specific prefixes for those services, 279 with appropriate source prefixes for their use. We want a routing 280 algorithm that sends packets matching such a specification to the CPE 281 Router advertising that indicated route, and dropping, perhaps with 282 an ICMPv6 response, packets for which it effectively has no route. 284 Note that in this use case, if there are other routers or internal 285 routes in the network, there is no need for them to specify source 286 prefixes on their routes, and if they do, the prefix specified is 287 likely to be :;/0. The reason is that traffic arriving from the ISPs 288 must be delivered to destinations within the network, so routing 289 cannot preclude them. 291 2.4. Intra-domain access control 293 A use case within the confines of a single network is as shown in 294 Figure 4. A network has one or more internal networks with differing 295 access permission sets; the financial servers might only be 296 accessible from a set of other prefixes that financial people are 297 located in, or university grade records is only reachable from the 298 offices of professors. This could be implemented using firewalls 299 between the domains, or using application layer filters; in this 300 case, the routing architecture replaces an exclusive firewall rule. 302 In this case, each domain advertises reachability to its prefix, 303 listing acceptable source prefixes. Domains that are willing to be 304 generally reached might advertise ::/0 as a source prefix, or the 305 prefix in use in the general domain. 307 _.--------------. 308 _.-'' `---. 309 ,-'' `--. 310 ,' `. 311 ,' ,---------. ,---------. `. 312 / ( Domain 1 ) ( Domain 2 ) \ 313 ; `---------' `---------' : 314 | Inter-domain | 315 : Backbone ; 316 \ ,---------. ,---------. / 317 `. ( Domain 3 ) ( Domain 4 ) ,' 318 `. `---------' `---------' ,' 319 `--. _.-' 320 `---. _.-'' 321 `--------------'' 323 Figure 4: Intradomain Access Control 325 The big issue in this network is a difference in policy. 327 3. Derived Requirements 329 The use cases in can each be met if: 331 o The routing protocol or mechanism includes a source prefix. It is 332 acceptable that a default source prefix of ::/0 (all addresses) 333 applies to routes that don't specify a prefix. 335 o The routing protocol or mechanism includes a destination prefix, 336 which may be a default route (::/0) or any more specific prefix up 337 to and including a host route (/128). 339 o The FIB lookup yields the route with the most specific (e.g. 340 longest-match) destination prefix that also matches the source 341 prefix constraint, or no match. 343 4. IANA Considerations 345 This memo asks the IANA for no new parameters. 347 5. Security Considerations 349 As a descriptive document, this note adds no new security risks to 350 the network. 352 6. Privacy Considerations 354 As a descriptive document, this note adds no new privacy risks to the 355 network. 357 7. Acknowledgements 359 This note was discussed with Acee Lindem, Jianping Wu, Juliusz 360 Chroboczek, Les Ginsberg Lorenzo Colitti, Mark Townsley, Markus 361 Stenberg, Matthieu Boutier, Ole Troan, Ray Bellis, Shu Yang, and Xia 362 Yin. 364 8. References 366 8.1. Normative References 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, March 1997. 371 8.2. Informative References 373 [I-D.baker-fun-routing-class] 374 Baker, F., "Routing a Traffic Class", draft-baker-fun- 375 routing-class-00 (work in progress), July 2011. 377 [I-D.baker-ipv6-isis-dst-src-routing] 378 Baker, F., "IPv6 Source/Destination Routing using IS-IS", 379 draft-baker-ipv6-isis-dst-src-routing-00 (work in 380 progress), February 2013. 382 [I-D.baker-ipv6-ospf-dst-src-routing] 383 Baker, F., "IPv6 Source/Destination Routing using OSPFv3", 384 draft-baker-ipv6-ospf-dst-src-routing-02 (work in 385 progress), May 2013. 387 [I-D.boutier-homenet-source-specific-routing] 388 Boutier, M. and J. Chroboczek, "Source-specific Routing", 389 draft-boutier-homenet-source-specific-routing-00 (work in 390 progress), July 2013. 392 [I-D.troan-homenet-sadr] 393 Troan, O. and L. Colitti, "IPv6 Multihoming with Source 394 Address Dependent Routing (SADR)", draft-troan-homenet- 395 sadr-00 (work in progress), February 2013. 397 [I-D.xu-homenet-traffic-class] 398 Xu, M., Yang, S., Wu, J., and F. Baker, "Traffic Class 399 Routing Protocol in Home Networks", draft-xu-homenet- 400 traffic-class-00 (work in progress), July 2013. 402 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 403 Defeating Denial of Service Attacks which employ IP Source 404 Address Spoofing", BCP 38, RFC 2827, May 2000. 406 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 407 Networks", BCP 84, RFC 3704, March 2004. 409 Appendix A. Change Log 411 Initial Version: August 2013 413 Author's Address 415 Fred Baker 416 Cisco Systems 417 Santa Barbara, California 93117 418 USA 420 Email: fred@cisco.com