idnits 2.17.1 draft-lamparter-rtgwg-dst-src-routing-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2460]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 27, 2015) is 3225 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-07) exists of draft-baker-ipv6-isis-dst-src-routing-01 == Outdated reference: A later version (-12) exists of draft-sarikaya-6man-sadr-overview-01 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 rtgwg D. Lamparter 3 Internet-Draft NetDEF 4 Intended status: Standards Track June 27, 2015 5 Expires: December 29, 2015 7 Destination/Source Routing 8 draft-lamparter-rtgwg-dst-src-routing-01 10 Abstract 12 This note specifies using packets' source addresses in route lookups 13 as additional qualifier to be used in route lookup. This applies to 14 IPv6 [RFC2460] in general with specific considerations for routing 15 protocol left for separate documents. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 29, 2015. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 53 2. Principle of operation . . . . . . . . . . . . . . . . . . . 3 54 2.1. Lookup ordering and disambiguation . . . . . . . . . . . 3 55 2.2. Ordering Rationale . . . . . . . . . . . . . . . . . . . 4 56 3. Applicability To Specific Situations . . . . . . . . . . . . 4 57 3.1. Recursive Route Lookups . . . . . . . . . . . . . . . . . 4 58 3.2. Unicast Reverse Path Filtering . . . . . . . . . . . . . 5 59 3.3. Multicast Reverse Path Forwarding . . . . . . . . . . . . 5 60 4. Interoperability . . . . . . . . . . . . . . . . . . . . . . 5 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 65 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 10.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 Since connectivity providers generally secure their ingress along the 74 lines of BCP 38 [RFC2827], small multihomed networks have a need to 75 ensure their traffic leaves their network with a correct combination 76 of source address and exit taken. This applies to networks of a 77 particular pattern where the provider's default (dynamic) address 78 provisioning methods are used and no fixed IP space is allocated, 79 e.g. home networks, small business users and mobile ad-hoc setups. 81 While IPv4 networks would conventionally use NAT or policy routing to 82 produce correct behaviour, this not desirable to carry over to IPv6. 83 Instead, assigning addresses from multiple prefixes in parallel 84 shifts the choice of uplink to the host. However, now for finding 85 the proper exit the source address of packets must be taken into 86 account. 88 For a general introduction and aspects of interfacing routers to 89 hosts, refer to [I-D.sarikaya-6man-sadr-overview]. 91 1.1. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 2. Principle of operation 99 The mechanism in this document is such that a source prefix is added 100 to all route entries. This document assumes all entries have a 101 source prefix, with ::/0 as default value for entries installed 102 without a specified source prefix. This need not be implemented in 103 this particular way, however the system MUST behave exactly as if it 104 were. In particular, a difference in behaviour between routes with a 105 source prefix of ::/0 and routes without source prefix MUST NOT be 106 visible. 108 For uniqueness considerations, the source prefix factors MUST be 109 taken into account for comparisons. Two routes with identical 110 information except the source prefix MAY exist and MUST be installed 111 and matched. 113 2.1. Lookup ordering and disambiguation 115 Adding further criteria to be looked up when forwarding packets on a 116 hop-by-hop basis has the very fundamental requirement that all 117 routers behave the same way in choosing the most specific route when 118 there are multiple eligible routes. 120 For longest-match lookups, the source prefix is matched after the 121 destination prefix. This is to say, first the longest matching 122 destination prefix is found, then the table is searched for the route 123 with the longest source prefix match, while only considering routes 124 with exactly the destination prefix previously found. If and only if 125 no such route exists (because none of the source prefixes match), the 126 lookup moves to the next less specific destination prefix. 128 A router MUST continue to a less specific destination prefix if no 129 route matches on the source prefix. It MUST NOT terminate lookup on 130 such an event. 132 Using A < B to mean "A is more specific than B", this is represented 133 as: 135 A < B := Adst < Bdst 136 || (Adst == Bdst && Asrc < Bsrc) 138 2.2. Ordering Rationale 140 The ordering described by this document (destination before source) 141 could as well be reversed, which would lead to semantically different 142 behavior. 144 Choosing destination to be evaluated first caters to the assumption 145 that local networks should have full, contiguous connectivity to each 146 other. This implies that those specific local routes always match 147 first based on destination, and use a zero ("all sources") source 148 prefix. 150 If the source prefix were to be matched first, this would result in a 151 less specific (e.g. default) route with a source prefix to match 152 before those local routes. In other terms, this would essentially 153 divide local connectivity into zones based on source prefix, which is 154 not the intention of this document. 156 Hence, this document describes destination-first lookup. 158 3. Applicability To Specific Situations 160 3.1. Recursive Route Lookups 162 TBD, multiple possible approaches: 164 variant 1: ignore dst-src routes, only use routes with src ::/0 166 variant 2: exact-match src prefixes from resolvee to resolvent 167 (will not work for a lot of cases) 169 variant 3: longer-match src prefixes from resolvee to resolvent 170 (nexthop src may be superset of looked-up route) 172 variant 4: create multiple instances of the route whose nexthop is 173 resolved, with different source prefixes 175 (Variant 4:) 177 When doing recursive nexthop resolution, the route that is being 178 resolved is installed in potentially multiple copies, inheriting all 179 possible more-specific routes that match the nexthop as destination. 180 The algorithm to do this is: 182 1. form the set of attributes for lookup by using the (unresolved, 183 recursive) nexthop as destination (with full host prefix length, 184 i.e. /128), copy all other attributes from the original route 186 2. find all routes that overlap with this set of attributes 187 (including both more-specific and less-specific routes) 189 3. order the result from most to less specific 191 4. for each route, install a route using the original route's 192 destination and the "logical and" overlap of each extra match 193 attribute with same attribute from the set. Copy nexthop data 194 from the route under iteration. Then, reduce the set of extra 195 attributes by what was covered by the route just installed 196 ("logical AND NOT"). 198 Example recursive route resolution 200 route to be resolved: 201 2001:db8:1234::/48, source 2001:db8:3456::/48, 202 recursive nexthop via 2001:db8:abcd::1 204 routes considered for recursive nexthop: 205 ::/0, via fe80::1 206 2001:db8:abcd::/48, via fe80::2 207 2001:db8:abcd::/48, source 2001:db8:3456:3::/64, via fe80::3 208 2001:db8:abcd::1/128, source 2001:db8:3456:4::/64, via fe80::4 210 recursive resolution result: 211 2001:db8:1234::/48, source 2001:db8:3456::/48, via fe80::2 212 2001:db8:1234::/48, source 2001:db8:3456:3::/64, via fe80::3 213 2001:db8:1234::/48, source 2001:db8:3456:4::/64, via fe80::4 215 3.2. Unicast Reverse Path Filtering 217 Unicast reverse path filtering MUST use dst-src routes analog to its 218 usage of destination-only routes. However, the system MAY match 219 either only incoming source against routes' destinations, or it MAY 220 match source and destination against routes' destination and source. 221 It MUST NOT ignore dst-src routes on uRPF checks. 223 3.3. Multicast Reverse Path Forwarding 225 Multicast Reverse Path Lookups are used to find paths towards the 226 (known) sender of multicast packets. Since the destination of these 227 packets is the multicast group, it cannot be matched against the 228 source part of a dst-src route. Therefore, dst-src routes MUST be 229 ignored for Multicast RPF lookups. 231 4. Interoperability 232 Since a router implementing source/destination routing can have 233 additional, more specific routes than one that doesn't implement 234 source/destination routing, persistent loops can form between these 235 systems. To prevent this from happening, a simple rule must be 236 followed: 238 The set of qualifiers used to route a particular packet MUST be a 239 subset of the qualifiers supported by the next hop. 241 This means in particular that a router using the source address as 242 extra qualifier MUST NOT route packets based on a source/destination 243 route to a system that doesn't support source/destination routes (and 244 hence doesn't understand the route). 246 There are 3 possible approaches to avoid such a condition: 248 1. discard the packet (treat as destination unreachable) 250 2. calculate an alternate topology including only routers that 251 support qualifier A 253 3. if the lookup returns the same nexthop without using qualifier A, 254 use that result (i.e., the nexthop is known to correctly route 255 the packet) 257 Above considerations require under all circumstances a knowledge of 258 the next router's capabilities. For routing protocols based on hop- 259 by-hop flooding (RIP [RFC2080], BGP [RFC4271]), knowing the peer's 260 capabilities - or simply relying on systems to only flood what they 261 understand - is sufficient. Protocols building a link-state database 262 (OSPF [RFC5340], IS-IS [RFC5308]) have the additional opportunity to 263 calculate alternate paths based on knowledge of the entire domain, 264 but cannot rely on routers flooding only link state they support 265 themselves. 267 5. IANA Considerations 269 This document makes no requests to IANA. 271 6. Security Considerations 273 Systems operating under the principles of this document can have 274 routes that are more specific than the previously most specific, i.e. 275 host routes. This can be a security concern if an operator was 276 relying on the impossibility of hijacking such a route. 278 While source/destination routing could be used as part of a security 279 solution, it is not really intended for the purpose. The approach 280 limits routing, in the sense that it routes traffic to an appropriate 281 egress, or gives a way to prevent communication between systems not 282 included in a source/destination route, and in that sense could be 283 considered similar to an access list that is managed by and scales 284 with routing. 286 7. Privacy Considerations 288 If a host's addresses are known, injecting a dst-src route allows 289 isolation of traffic from that host, which may compromise privacy. 290 However, this requires access to the routing system. As with similar 291 problems with the destination only, defending against it is left to 292 general mechanisms protecting the routing infrastructure. 294 8. Acknowledgements 296 The base underlying this document was first outlaid by Ole Troan and 297 Lorenzo Colitti in [I-D.troan-homenet-sadr] for application in the 298 homenet area. 300 This document is largely the result of discussions with Fred Baker 301 and derives from [I-D.baker-ipv6-isis-dst-src-routing]. 303 9. Change Log 305 Initial Version: April 2015: merged routing-extra-qualifiers draft, 306 new ordering rationale section 308 Initial Version: October 2014 310 10. References 312 10.1. Normative References 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, March 1997. 317 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 318 6 (IPv6) Specification", RFC 2460, December 1998. 320 10.2. Informative References 322 [I-D.baker-ipv6-isis-dst-src-routing] 323 Baker, F., "IPv6 Source/Destination Routing using IS-IS", 324 draft-baker-ipv6-isis-dst-src-routing-01 (work in 325 progress), August 2013. 327 [I-D.sarikaya-6man-sadr-overview] 328 Sarikaya, B., "Overview of Source Address Dependent 329 Routing", draft-sarikaya-6man-sadr-overview-01 (work in 330 progress), September 2014. 332 [I-D.troan-homenet-sadr] 333 Troan, O. and L. Colitti, "IPv6 Multihoming with Source 334 Address Dependent Routing (SADR)", draft-troan-homenet- 335 sadr-01 (work in progress), September 2013. 337 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 338 January 1997. 340 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 341 Defeating Denial of Service Attacks which employ IP Source 342 Address Spoofing", BCP 38, RFC 2827, May 2000. 344 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 345 Protocol 4 (BGP-4)", RFC 4271, January 2006. 347 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 348 2008. 350 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 351 for IPv6", RFC 5340, July 2008. 353 Author's Address 355 David Lamparter 356 NetDEF 357 Leipzig 04103 358 Germany 360 Email: david@opensourcerouting.org