idnits 2.17.1 draft-dickson-sidr-route-leak-reqts-02.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 'Intended status' indicated for this document; assuming Proposed Standard 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 (March 6, 2012) is 4434 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) == Unused Reference: 'RFC1773' is defined on line 304, but no explicit reference was found in the text == Unused Reference: 'RFC1997' is defined on line 307, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 310, but no explicit reference was found in the text == Unused Reference: 'RFC4456' is defined on line 313, but no explicit reference was found in the text == Unused Reference: 'RFC4760' is defined on line 317, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1773 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 sidr B. Dickson 3 Internet-Draft Brian Dickson 4 Expires: September 7, 2012 March 6, 2012 6 Route Leaks -- Requirements for Detection and Prevention thereof 7 draft-dickson-sidr-route-leak-reqts-02 9 Abstract 11 The Border Gateway Protocol, version 4, (BGP4) provides the means to 12 advertise reachability for IP prefixes. This reachability 13 information is propagated in a peer-to-peer topology. Sometimes 14 routes are announced to peers for which the local peering policy does 15 not permit. And sometimes routes are propagated indiscriminantly, 16 once they have been accepted. 18 This document is a requirements document for detection of (and 19 prevention of) route leaks. 21 Together with the definitions document, it is intended to suggest 22 solutions which meet these criteria, and to facilitate evaluation of 23 proposed solutions. 25 The fundamental objective is to "solve the route leaks problem". 27 Author's Note 29 Intended Status: Informational. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 7, 2012. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Peering Terms and Symbols . . . . . . . . . . . . . . . . . . . 3 69 3. Local Non-Leak Prefix Advertisement Matrix & Rules . . . . . . 4 70 4. Route Leak Detection Requirements . . . . . . . . . . . . . . . 5 71 4.1. Coloring Rules . . . . . . . . . . . . . . . . . . . . . . 5 72 4.2. Route Modification Rules . . . . . . . . . . . . . . . . . 6 73 4.3. Single Party Rules . . . . . . . . . . . . . . . . . . . . 7 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 1.1. Rationale 86 This document analyzes the particulars of situations which introduce 87 route leaks, or propagates those leaks. 89 Using the definitions previously established, those conditions are 90 reduced to a minimum set of requirements for the identification of 91 route leaks. 93 Those conditions are validated at length, and all of the assumptions 94 stated, and consequential conditions enumerated. 96 The result is a set of criteria for solving the route leak problem, 97 preventing any single source of leakage regardless of intent or 98 nature (operator, implementor, bad actor). 100 1.2. Requirements 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 1.3. Terminology 108 The reader is assumed to be familiar with the IETF. 110 2. Peering Terms and Symbols 112 We can represent the per-link peering categorizations with the 113 following symbols: 115 Neighbor is: 117 a. Transit Provider - T 119 b. (Transit) Customer - C 121 c. Peer - P 123 d. Mutual Transit 125 In any neighbor relationship, the roles of the parties on either end 126 of the link would be: 128 T-C 130 C-T 132 P-P 134 Mc-Mtp 136 Mtp-Mc 138 (where the last two, Mc/Mtp are a semantic and/or coloring 139 distinction on routes, rather than two separate links.) 141 3. Local Non-Leak Prefix Advertisement Matrix & Rules 143 The following matrix shows what prefixes from a given source peering 144 relationship, may be advertised to a given neighbor peering 145 relationship without causing a route leak. 147 +------------+---+---+-----+----+---+ 148 | Src \ Dest | P | T | Mtp | Mc | C | 149 +------------+---+---+-----+----+---+ 150 | P | - | - | - | Y | Y | 151 | T | - | - | - | Y | Y | 152 | Mtp | - | - | - | Y | Y | 153 | Mc | Y | Y | Y | - | Y | 154 | C | Y | Y | Y | - | Y | 155 +------------+---+---+-----+----+---+ 157 Grouping the like items (by row and column) we get: 159 +------------+-------+---+----+---+ 160 | Src \ Dest | T/Mtp | P | Mc | C | 161 +------------+-------+---+----+---+ 162 | T/Mtp | - | - | Y | Y | 163 | P | - | - | Y | Y | 164 | C/Mc | Y | Y | - | Y | 165 +------------+-------+---+----+---+ 167 When a prefix is sent to any T neighbor, the receiving neighbor sees 168 it as C. Similarly, Mc is seen at Mtp. 169 The inverse of these is also true: C->T, Mtp->Mc. 170 And lastly, a prefix sent to a (P) will be received by the neighbor 171 as a (P). 173 This means that once a prefix has been sent to any of the two type 174 sets "P" or "C/Mc", it must only subsequently be sent to "C" or "Mc" 175 types. 177 This results in the regular expression for a valid (non-leaked) path: 179 Origin - (T - |Mtp - )*(P - )?(C - |Mc - )* Destination 181 Thus we have the basis for a simple set of rules, which would enable 182 detecting and preventing route leaks. 184 4. Route Leak Detection Requirements 186 Based on the advertisement rules, we now have enough information to 187 specify the main rules that a Route Leak Detector would need to 188 observe. 190 4.1. Coloring Rules 192 In no particular order, here are the requirements for coloring the 193 path of a route. 195 o Every BGP peering session (Link) MUST have a type associated with 196 it. 198 o Neighbors Agree - both sides of a BGP peering link must negotiate 199 and agree on the link type. 201 o Last Color Agrees with Link - the last color applied to the route 202 must be the consistent with the link type. 204 o If the Color used towards "Transit" is "Green", and the Color used 205 towards "Peer" or "Customer" is "Yellow", then: 207 * The entire Path must have a corresponding set of Colors, one 208 for each AS-Hop. 210 * The Path must be of the form (Green)*(Green|Yellow)(Yellow)*. 212 * Once a Path has switched to Yellow, it cannot switch back to 213 Green. 215 * Routes sent to T neighbors must mark the path Green. 217 * Only Green Routes may be sent to T or P neighbors. 219 * Routes sent to C or P neighbors must mark the path Yellow. 221 * A route learned via a P neighbor must be all Green followed by 222 a single Yellow. 224 * A route learned via a T neighbor must be zero or more Greens 225 followed by one or more Yellows. 227 * A route learned via a C neighbor must be one or more Greens 228 (and no Yellows). 230 * Mutual Transit links must preserve the current color. 232 * Colors may be explicitly marked, or may be inferred as long as 233 there is no room for ambiguity. 235 4.2. Route Modification Rules 237 In addressing accidental route leaks, the secondary goal is to also 238 prevent malicious route leaks. 240 The only additional rule for this is, that any additional BGP 241 attributes implementing this would need to be included in the set of 242 things cryptographically signed. This provides tamper evidence and 243 prevention of substitution of values (on received routes). 245 This means that the assigning of colors must be handed by 246 implementation based only on Link Type (and current Route color), 247 with no over-ride by the operator possible, with a single exception: 248 It should always be possible to "demote" a route from Green to 249 Yellow, locally before or while sending. 251 Similarly, route-leak filtering of routes on both the send and 252 receive direction, MUST be done based only on color vs link type. 253 There cannot be an operator-exposed over-ride. 255 For an operator who has a need to make a routing announcement that 256 violates the Link Type, the correct course of action would be to 257 change the Link type. This would need to be done cooperatively with 258 the party at the other end of the link. 260 4.3. Single Party Rules 262 One objective in preventing Route Leaks from being initiated or 263 propogated, is to examine the control points of the routing path 264 itself. 266 By treating this as a path where the goal is to avoid any single 267 point of failure, we can derive additional rules. 269 Here, the term "failure" is synonymous with "route leak". In other 270 words, are their any points where a single error or omission can 271 cause a route leak? 273 If there are any, the goal should be to replace those with equivalent 274 elements which would require two errors or actions, by independent 275 parties, to cause a route leak. 277 Here are some of the places where this is accomplished or needs to be 278 done by solutions: 280 o Sender/Receiver - both ends of a link need to agree on the type. 281 Unilateral error here must fail "safe" -> BGP does not establish, 282 with errors. 284 o Always Validate Color Rules - while the blocking of leaked routes 285 should occur automatically at the point of leak, failure to block 286 a leak SHOULD be detected and the route SHOULD be blocked by the 287 next recipient. 289 5. Security Considerations 291 None per se. 293 6. IANA Considerations 295 This document contains no IANA-specific material. 297 7. Acknowledgements 299 To be added later. 301 8. References 302 8.1. Normative References 304 [RFC1773] Traina, P., "Experience with the BGP-4 protocol", 305 RFC 1773, March 1995. 307 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 308 Communities Attribute", RFC 1997, August 1996. 310 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 311 Protocol 4 (BGP-4)", RFC 4271, January 2006. 313 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 314 Reflection: An Alternative to Full Mesh Internal BGP 315 (IBGP)", RFC 4456, April 2006. 317 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 318 "Multiprotocol Extensions for BGP-4", RFC 4760, 319 January 2007. 321 8.2. Informative References 323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 324 Requirement Levels", BCP 14, RFC 2119, March 1997. 326 Author's Address 328 Brian Dickson 329 Brian Dickson 330 703 Palmer Drive, 331 Herndon, VA 20170 332 USA 334 Email: brian.peter.dickson@gmail.com