idnits 2.17.1 draft-ietf-babel-source-specific-06.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 (October 10, 2020) is 1266 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) == Outdated reference: A later version (-20) exists of draft-ietf-babel-rfc6126bis-06 -- Obsolete informational reference (is this intentional?): RFC 6126 (Obsoleted by RFC 8966) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boutier 3 Internet-Draft J. Chroboczek 4 Intended status: Standards Track IRIF, University of Paris-Diderot 5 Expires: April 13, 2021 October 10, 2020 7 Source-Specific Routing in Babel 8 draft-ietf-babel-source-specific-06 10 Abstract 12 Source-specific routing (also known as Source-Address Dependent 13 Routing, SADR) is an extension to traditional next-hop routing where 14 packets are forwarded according to both their destination and their 15 source address. This document describes an extension for source- 16 specific routing to the Babel routing protocol. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 13, 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction and background . . . . . . . . . . . . . . . . . 2 53 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 54 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. The Source Table . . . . . . . . . . . . . . . . . . . . 3 56 3.2. The Route Table . . . . . . . . . . . . . . . . . . . . . 4 57 3.3. The Table of Pending Seqno Requests . . . . . . . . . . . 4 58 4. Data Forwarding . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5 60 5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 6 61 5.2. Wildcard Messages . . . . . . . . . . . . . . . . . . . . 6 62 6. Compatibility with the base protocol . . . . . . . . . . . . 7 63 6.1. Loop-avoidance . . . . . . . . . . . . . . . . . . . . . 7 64 6.2. Starvation and Blackholes . . . . . . . . . . . . . . . . 8 65 7. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 8 66 7.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 8 67 7.2. Source-specific Update . . . . . . . . . . . . . . . . . 9 68 7.3. Source-specific (Route) Request . . . . . . . . . . . . . 9 69 7.4. Source-Specific Seqno Request . . . . . . . . . . . . . . 9 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 9. Security considerations . . . . . . . . . . . . . . . . . . . 10 72 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 75 11.2. Informative References . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction and background 80 The Babel routing protocol [BABEL] is a distance vector routing 81 protocol for next-hop routing. In next-hop routing, each node 82 maintains a forwarding table which maps destination prefixes to next 83 hops. The forwarding decision is a per-packet operation which 84 depends on the destination address of the packets and on the entries 85 of the forwarding table. When a packet is about to be routed, its 86 destination address is compared to the prefixes of the routing table: 87 the entry with the most specific prefix containing the destination 88 address of the packet is chosen, and the packet is forwarded to the 89 associated next-hop. Next-hop routing is a simple, well understood 90 paradigm that works satisfactorily in a large number of cases. 92 Source-specific routing [SS-ROUTING], or Source Address Dependent 93 Routing (SADR), is a modest extension to next-hop routing where the 94 forwarding decision depends not only on the destination address but 95 also on the source address of the packet being routed, which makes it 96 possible for two packets with the same destination but different 97 source addresses to be routed following different paths. The 98 forwarding tables are extended to map pairs of prefixes (destination, 99 source) to next hops. When multiple entries match a given packet, 100 the one with the most specific destination prefix is chosen, and, in 101 the case of equally specific destination prefixes, the one with the 102 most specific source prefix. 104 The main application of source-specific routing is a form of 105 multihoming known as multihoming with multiple addresses. When using 106 this technique in a network connected to multiple providers, every 107 host is assigned multiple addresses, one per provider. When a host 108 sources a packet, it picks one of its addresses as the source 109 address, and source-specific routing is used to route the packet to 110 an edge router that is connected to the corresponding provider, which 111 is compatible with [BCP84]. Unlike classical multihoming, this 112 technique is applicable to small networks, as it does not require the 113 use of provider-independent addresses, or cause excessive growth of 114 the global routing table. More details are given in [SS-ROUTING]. 116 This document describes a source-specific routing extension for the 117 Babel routing protocol [BABEL]. This involves minor changes to the 118 data structures, which must include a source prefix in addition to 119 the destination prefix already present, and some changes to the 120 Update, Route Request and Seqno Request TLVs, which are extended with 121 a source prefix. The source prefix is encoded using a mandatory sub- 122 TLV ([BABEL] Section 4.4). 124 2. Specification of Requirements 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in 129 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 130 capitals, as shown here. 132 3. Data Structures 134 A number of the conceptual data structures described in Section 3.2 135 of [BABEL] contain a destination prefix. This specification extends 136 these data structures with a source prefix. Data from the original 137 protocol, which do not specify a source prefix, are stored with a 138 zero length source prefix, which matches exactly the same set of 139 packets as the original, non-source-specific data. 141 3.1. The Source Table 143 Every Babel node maintains a source table, as described in [BABEL] 144 Section 3.2.5. A source-specific Babel node extends this table with 145 the following field: 147 o The source prefix specifying the source address of packets to 148 which this entry applies. 150 The source table is now indexed by triples of the form (prefix, 151 source prefix, router-id). 153 Note that the route entry contains a source (see sections 2 and 3.2.5 154 of [BABEL]) which itself contains a source prefix. These are two 155 very different concepts that should not be confused. 157 3.2. The Route Table 159 Every Babel node maintains a route table, as described in [BABEL] 160 Section 3.2.6. Each route table entry contains, among other data, a 161 source, which this specification extends with a source prefix as 162 described above. The route table is now indexed by triples of the 163 form (prefix, source prefix, neighbour), where the prefix and source 164 prefix are obtained from the source. 166 3.3. The Table of Pending Seqno Requests 168 Every Babel node maintains a table of pending seqno requests, as 169 described in [BABEL], Section 3.2.7. A source-specific Babel node 170 extends this table with the following entry: 172 o The source prefix being requested. 174 The table of pending seqno requests is now indexed by triples of the 175 form (prefix, source prefix, router-id). 177 4. Data Forwarding 179 In next-hop routing, if two routing table entries overlap, then one 180 is necessarily more specific than the other; the "longest prefix 181 rule" specifies that the most specific applicable routing table entry 182 is chosen. 184 With source-specific routing, there might no longer be a most 185 specific applicable entry: two routing table entries might match a 186 given packet without one necessarily being more specific than the 187 other. Consider for example the following routing table: 189 destination source next-hop 190 2001:DB8:0:1::/64 ::/0 A 191 ::/0 2001:DB8:0:2::/64 B 193 This specifies that all packets with destination in 2001:DB8:0:1::/64 194 are to be routed through A, while all packets with source in 195 2001:DB8:0:2::/64 are to be routed through B. A packet with source 196 2001:DB8:0:2::42 and destination 2001:DB8:0:1::57 matches both 197 entries, although neither is more specific than the other. A choice 198 is necessary, and unless the choice being made is the same on all 199 routers in a routing domain, persistent routing loops may occur. 200 More details are given in Section IV.C of [SS-ROUTING]. 202 A Babel implementation MUST choose routing table entries by using the 203 so-called destination-first ordering, where a routing table entry R1 204 is preferred to a routing table entry R2 when either R1's destination 205 prefix is more specific than R2's, or the destination prefixes are 206 equal and R1's source prefix is more specific than R2's. (In other 207 words, routing table entries are compared using the lexicographic 208 product of the destination prefix ordering by the source prefix 209 ordering.) 211 In practice, this means that a source-specific Babel implementation 212 must take care that any lower layer that performs packet forwarding 213 obey this semantics. More precisely: 215 o If the lower layers implement the destination-first ordering, then 216 the Babel implementation SHOULD use them directly; 218 o If the lower layers can hold source-specific routes, but not with 219 the right semantics, then the Babel implementation MUST either 220 silently ignore any source-specific routes, or disambiguate the 221 routing table by using a suitable disambiguation algorithm (see 222 Section V.B of [SS-ROUTING] for such an algorithm); 224 o If the lower layers cannot hold source-specific routes, then a 225 Babel implementation MUST silently ignore any source-specific 226 routes. 228 5. Protocol Operation 230 This extension does not fundamentally change the operation of the 231 Babel protocol, and we therefore only describe differences between 232 the original protocol and the extended protocol. 234 In the original protocol, three TLVs carry a destination prefix: 235 Updates, Route Requests and Seqno Requests. This specification 236 extends these messages to optionally carry a Source Prefix sub-TLV, 237 as described in Section 7 below. The sub-TLV is marked as mandatory, 238 so that an unextended implementation will silently ignore the whole 239 enclosing TLV. A node obeying this specification MUST NOT send a TLV 240 with a zero-length source prefix: instead, it sends a TLV with no 241 Source Prefix sub-TLV. Conversely, an extended implementation MUST 242 interpret an unextended TLV as carrying a source prefix of zero 243 length. Taken together, these properties ensure interoperability 244 between the original and extended protocols (see Section 6 below). 246 5.1. Protocol Messages 248 This extension allows three TLVs of the original Babel protocol to 249 carry a source prefix: Update TLVs, Route Request TLVs and Seqno 250 Request TLVs. 252 In order to advertise a route with a non-zero length source prefix, a 253 node sends a source-specific Update, i.e., an Update with a Source 254 Prefix sub-TLV. When a node receives a source-specific Update 255 (prefix, source prefix, router-id, seqno, metric) from a neighbour 256 neigh, it behaves as described in [BABEL] Section 3.5.4, except that 257 the entry under consideration is indexed by (prefix, source prefix, 258 neigh) rather than just (prefix, neigh). 260 Similarly, when a node needs to send a Request of either kind that 261 applies to a route with a non-zero length source prefix, it sends a 262 source-specific Request, i.e., a Request with a Source Prefix sub- 263 TLV. When a node receives a source-specific Request, it behaves as 264 described in Section 3.8 of [BABEL], except that the request applies 265 to the Route Table entry carrying the source prefix indicated by the 266 Source Prefix sub-TLV. 268 5.2. Wildcard Messages 270 In the original protocol, the Address Encoding value 0 is used for 271 wildcard messages: messages that apply to all routes, of any address 272 family and with any destination prefix. Wildcard messages are 273 allowed in two places in the protocol: wildcard retractions are used 274 to retract all of the routes previously advertised by a node on a 275 given interface, and wildcard Route Requests are used to request a 276 full dump of the Route Table from a given node. Wildcard messages 277 are intended to apply to all routes, including routes decorated with 278 additional data and AE values to be defined by future extensions, and 279 hence this specification extends wildcard operations to apply to all 280 routes, whatever the value of the source prefix. 282 More precisely, a node receiving an Update with the AE field set to 0 283 and the Metric field set to infinity (a wildcard retraction) MUST 284 apply the route acquisition procedure described in Section 3.5.4 of 285 [BABEL] to all of the routes that it has learned from the sending 286 node, whatever the value of the source prefix. A node MUST NOT send 287 a wildcard retraction with an attached source prefix, and a node that 288 receives a wildcard retraction with a source prefix MUST ignore it. 290 Similarly, a node that receives a route request with the AE field set 291 to 0 (a wildcard route request) SHOULD send a full routing table 292 dump, including routes with a non-zero length source prefix. A node 293 MUST NOT send a wildcard request that carries a source prefix, and a 294 node receiving a wildcard request with a source prefix MUST ignore 295 it. 297 6. Compatibility with the base protocol 299 The protocol extension defined in this document is, to a great 300 extent, interoperable with the base protocol defined in [BABEL] (and 301 all previously standardised extensions). More precisely, if non- 302 source-specific routers and source-specific routers are mixed in a 303 single routing domain, Babel's loop-avoidance properties are 304 preserved, and, in particular, no persistent routing loops will 305 occur. 307 However, this extension is encoded using mandatory sub-TLVs, 308 introduced in [BABEL], and therefore is not compatible with the older 309 version of the Babel Routing Protocol [RFC6126] which does not 310 support such sub-TLVs. Consequently, this extension MUST NOT be used 311 with routers implementing RFC 6126, otherwise persistent routing 312 loops may occur. 314 6.1. Loop-avoidance 316 The extension defined in this protocol uses a new Mandatory sub-TLV 317 to carry the source prefix information. As discussed in Section 4.4 318 of [BABEL], this encoding ensures that non-source-specific routers 319 will silently ignore the whole TLV, which is necessary to avoid 320 persistent routing loops in hybrid networks. 322 Consider two nodes A and B, with A source-specific announcing a route 323 to (D, S). Suppose that B (non-source-specific) merely ignores the 324 source prefix information when it receives the update rather than 325 ignoring the whole TLV, and re-announces the route as D. This re- 326 announcement reaches A, which treats it as (D, ::/0). Packets 327 destined to D but not sourced in S will be forwarded by A to B, and 328 by B to A, causing a persistent routing loop: 330 (D,S) (D) 331 <-- <-- 332 ------ A ----------------- B 333 --> 334 (D,::/0) 336 6.2. Starvation and Blackholes 338 In general, the discarding of source-specific routes by non-source- 339 specific routers will cause route starvation. Intuitively, unless 340 there are enough non-source-specific routes in the network, non- 341 source-specific routers will suffer starvation, and discard packets 342 for destinations that are only announced by source-specific routers. 344 A simple yet sufficient condition for avoiding starvation is to build 345 a connected source-specific backbone that includes all of the edge 346 routers, and announce a (non-source-specific) default route towards 347 the backbone. 349 7. Protocol Encoding 351 This extension defines a new sub-TLV used to carry a source prefix: 352 the Source Prefix sub-TLV. It can be used within an Update, a Route 353 Request or a Seqno Request TLV to match a source-specific entry of 354 the Route Table, in conjunction with the destination prefix natively 355 carried by these TLVs. 357 Since a source-specific routing entry is characterized by a single 358 destination prefix and a single source prefix, a source-specific 359 message contains exactly one Source Prefix sub-TLV. A node MUST NOT 360 send more that one Source Prefix sub-TLV in a TLV, and a node 361 receiving more than one Source Prefix sub-TLV in a single TLV SHOULD 362 ignore this TLV. It MAY ignore the whole packet. 364 7.1. Source Prefix sub-TLV 366 0 1 2 3 367 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Type = 128 | Length | Source Plen | Source Prefix... 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 372 Fields: 374 Type Set to 128 to indicate a Source Prefix sub-TLV. 376 Length The length of the body, in octets, exclusive of the Type 377 and Length fields. 379 Source Plen The length of the advertised source prefix. This MUST 380 NOT be 0. 382 Source Prefix The source prefix being advertised. This field's size 383 is (Source Plen)/8 octets rounded upwards. 385 The contents of the Source Prefix sub-TLV are interpreted according 386 to the AE of the enclosing TLV. If a TLV with AE equal to 0 contains 387 a Source Prefix sub-TLV, then the whole TLV MUST be ignored. 388 Similarly, if a TLV contains multiple Source Prefix sub-TLVs, then 389 the whole TLV MUST be ignored. 391 Note that this sub-TLV is a mandatory sub-TLV. Therefore, as 392 described in Section 4.4 of [BABEL], the whole TLV MUST be ignored if 393 that sub-TLV is not understood (or malformed). Otherwise, routing 394 loops may occur (see Section 6.1). 396 7.2. Source-specific Update 398 The source-specific Update is an Update TLV with a Source Prefix sub- 399 TLV. It advertises or retracts source-specific routes in the same 400 manner as routes with non-source-specific Updates (see [BABEL]). A 401 wildcard retraction (Update with AE equal to 0) MUST NOT carry a 402 Source Prefix sub-TLV. 404 Babel uses a stateful compression scheme to reduce the size taken by 405 destination prefixes in update TLVs (see Section 4.5 of [BABEL]). 406 The source prefix defined by this extension is not compressed. On 407 the other hand, compression is allowed for the destination prefixes 408 carried by source-specific updates. As described in Section 4.5 of 409 [BABEL], unextended implementations will correctly update their 410 parser state while otherwise ignoring the whole TLV. 412 7.3. Source-specific (Route) Request 414 A source-specific Route Request is a Route Request TLV with a Source 415 Prefix sub-TLV. It prompts the receiver to send an update for a 416 given pair of destination and source prefixes, as described in 417 Section 3.8.1.1 of [BABEL]. A wildcard request (Route Request with 418 AE equals to 0) MUST NOT carry a Source Prefix sub-TLV; if a wildcard 419 request with a Source Prefix sub-TLV is received, then the request 420 MUST be ignored. 422 7.4. Source-Specific Seqno Request 424 A source-specific Seqno Request is a Seqno Request TLV with a Source 425 Prefix sub-TLV. It requests the receiving node to perform the 426 procedure described in Section 3.8.1.2 of [BABEL], but applied to a 427 pair of a destination and source prefix. 429 8. IANA Considerations 431 IANA has allocated sub-TLV number 128 for the Source Prefix sub-TLV 432 in the Babel sub-TLV types registry. 434 9. Security considerations 436 The extension defined in this document adds a new sub-TLV to three 437 TLVs already present in the original Babel protocol, and does not 438 change the security properties of the protocol itself. However, the 439 additional flexibility provided by source-specific routing might 440 invalidate the assumptions made by some network administrators, which 441 could conceivably lead to security issues. 443 For example, a network administrator might be tempted to abuse route 444 filtering (Appendix C of [BABEL]) as a security mechanism. Unless 445 the filtering rules are designed to take source-specific routing into 446 account, they might be bypassed by a source-specific route, which 447 might cause traffic to reach a portion of a network that was thought 448 to be protected. Similarly, a network administrator might assume 449 that no route is more specific than a host route, and use a host 450 route in order to direct traffic for a given destination through a 451 security device (e.g., a firewall); source-specific routing 452 invalidates this assumption, and in some topologies announcing a 453 source-specific route might conceivably be used to bypass the 454 security device. 456 10. Acknowledgments 458 The authors are grateful to Donald Eastlake and Joel Halpern for 459 their help with this document. 461 11. References 463 11.1. Normative References 465 [BABEL] Chroboczek, J., "The Babel Routing Protocol", Internet 466 Draft draft-ietf-babel-rfc6126bis-06, October 2018. 468 [BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 469 Networks", BCP 84, RFC 3704, March 2004. 471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", BCP 14, RFC 2119, 473 DOI 10.17487/RFC2119, March 1997. 475 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 476 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 477 May 2017. 479 11.2. Informative References 481 [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 482 DOI 10.17487/RFC6126, April 2011, 483 . 485 [SS-ROUTING] 486 Boutier, M. and J. Chroboczek, "Source-Specific Routing", 487 August 2014. 489 In Proc. IFIP Networking 2015. A slightly earlier 490 version is available online from http://arxiv.org/ 491 pdf/1403.0445. 493 Authors' Addresses 495 Matthieu Boutier 496 IRIF, University of Paris-Diderot 497 Case 7014 498 75205 Paris Cedex 13 499 France 501 Email: boutier@irif.fr 503 Juliusz Chroboczek 504 IRIF, University of Paris-Diderot 505 Case 7014 506 75205 Paris Cedex 13 507 France 509 Email: jch@irif.fr