idnits 2.17.1 draft-dickson-sidr-route-leak-def-03.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 23, 2012) is 4203 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) == Missing Reference: 'RFC1771' is mentioned on line 139, but not defined ** Obsolete undefined reference: RFC 1771 (Obsoleted by RFC 4271) == Unused Reference: 'RFC1033' is defined on line 336, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'RFC2136' is defined on line 345, but no explicit reference was found in the text == Unused Reference: 'RFC2181' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'RFC2308' is defined on line 352, but no explicit reference was found in the text == Unused Reference: 'RFC4033' is defined on line 355, but no explicit reference was found in the text == Unused Reference: 'RFC4034' is defined on line 359, but no explicit reference was found in the text == Unused Reference: 'RFC5011' is defined on line 363, but no explicit reference was found in the text == Unused Reference: 'RFC5155' is defined on line 366, but no explicit reference was found in the text ** Downref: Normative reference to an Unknown state RFC: RFC 1033 Summary: 2 errors (**), 0 flaws (~~), 14 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: April 26, 2013 October 23, 2012 6 Route Leaks -- Definitions 7 draft-dickson-sidr-route-leak-def-03 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. Routes may be 14 announced to neighbors, contrary to the receiver's local peering 15 policy. If that occurs, those routes may then be propagated 16 indiscriminantly, once they have been accepted. 18 This document considers the situations that can lead to routes being 19 leaked, and tries to find acceptable definitions for describing these 20 scenarios. 22 The purpose of these definitions is to facilitate analysis of what a 23 route leak is, and what the scope of the problem space for route 24 leaks is. 26 This, in turn, is intended to inform a requirements document for 27 detection of (and prevention of) route leaks. And finally, the 28 definitions and requirements are intended to allow proposed solutions 29 which meet these criteria, and to facilitate evaluation of proposed 30 solutions. 32 The ultimate goal is to "solve the route leaks problem". 34 Author's Note 36 Intended Status: Informational. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on April 26, 2013. 55 Copyright Notice 57 Copyright (c) 2012 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Scope Limitations . . . . . . . . . . . . . . . . . . . . . . 5 78 3. Route Leak Definitions . . . . . . . . . . . . . . . . . . . . 6 79 4. Peer Links and Routes . . . . . . . . . . . . . . . . . . . . 7 80 5. Customer Links and Routes . . . . . . . . . . . . . . . . . . 7 81 5.1. Customer's Customer . . . . . . . . . . . . . . . . . . . 7 82 6. Non-Leak-Initiation Links . . . . . . . . . . . . . . . . . . 8 83 7. Route Leak Initiation . . . . . . . . . . . . . . . . . . . . 8 84 8. Route Leak . . . . . . . . . . . . . . . . . . . . . . . . . . 8 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 87 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 89 12.1. Normative References . . . . . . . . . . . . . . . . . . . 9 90 12.2. Informative References . . . . . . . . . . . . . . . . . . 10 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 93 1. Introduction 95 1.1. Assumptions 97 Much of this document assumes the observer has total knowledge of the 98 state of everything in the hypothetical examples presented. 100 It is understood that participants in the real world routing 101 scenarios will not have that knowledge. 103 The purpose of presuming that total knowledge here, is to illustrate 104 how little is needed to identify leaked routes. 106 In particular, it is hoped that this leads to a correspondingly 107 simple set of definitions with useful real-world meaning. 109 1.2. Rationale 111 Generally speaking, a route-leak occurs when a route goes somewhere 112 it should not. In other words, that somewhere along the path, a 113 route was sent that somehow violated the implicit or explicit policy 114 between two neighbors, without being blocked by the recipient. Route 115 leaks cause harm, in a variety of ways. They expose traffic to Man- 116 In-The-Middle (MITM) attacks. They may result in traffic congestion, 117 latency, or even black-holing of traffic. 119 It is a leak if any receiver in the propogation path did not want the 120 route, from a generic policy perspective. It does not matter which 121 party caused the situation - a leaks are in the eye of the receivers. 122 By their nature - unintentional, unwanted, and harmful - route leaks 123 are bad. 125 By first establishing a more precise definition of route leak, the 126 intent is to find requirements for mechanisms for stopping route 127 leaks, and then finding solutions that meet those requirements. 129 1.3. Requirements 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 1.4. Terminology 137 The reader is assumed to be familiar with BGP version 4, both from a 138 protocol perspective and from an operational perspective. BGP4 is 139 defined in [RFC1771], and updated or enhanced by a variety of other 140 RFCs. 142 The following additional terminology is used throughout this 143 document: 145 Route (or synonomously, prefix): an NLRI in BGP, including all its 146 attributes. (This term subject to change by GROW.) 148 Neighbor (or "peer", not capitalized): A toplogically adjacent 149 Autonomous System, with whom routes are exchanged. 151 Link: A BGP connection to a Neighbor. A Neighbor may be reached via 152 one or more links, where each link may have a different 153 classification, and/or local policy. 155 Link Classification: The "intent" of a given BGP peering session, 156 which addresses only the categories of route announced and accepted, 157 and which is further modified by Local Policy. 159 Local Policy: The set of rules, as applied on a single Neighbor Link, 160 specifying which routes are announced, which routes are accepted, and 161 what attributes are changed to affect choice of BGP Best Path per 162 prefix. 164 Path: Also known as AS_PATH (or optionally AS4_PATH), the sequence of 165 ASNs through which a route has passed from Originator to recipient. 167 Hijacked Route: A route which has been originated by a party other 168 than the owner of the prefix. This could be via a forged ASN, or 169 from another ASN. 171 Validated Origination: a route whose origination has been validated, 172 e.g. via cryptographic means, such as using an ROA. 174 2. Scope Limitations 176 The following issues are not in the scope of route leaks. Each item 177 in the list includes the rationale for excluding it. 178 o Hijacked Routes - Origin Validation (proposed work in the SIDR WG) 179 addresses the issue of Hijacked Routes. By limiting Route Leak 180 efforts to Validated Routes, we are able to presume the origin is 181 correct, and narrow the scope. 182 o Violations of Local Policy - issues between adjacent ASNs which do 183 not propogate any further, or which do not violate the Link 184 Classification. 185 o Other-ASN Relationship - The "correctness" of a given prefix 186 received over a Link, is determined only by the Link 187 Classifications of each Link in the Path. The existence of other 188 Links, to Neighbors with ASNs on a given Path (which may have 189 differing Link Classifications), is a classic "apples to oranges" 190 comparision. It is incorrect to compare ASNs outside the context 191 of the AS path, so we exclude those comparisons from this work. 192 Essentially, the only elements being considered are the Path, and 193 Link Classifications at each hop in the Path. 195 3. Route Leak Definitions 197 Route Leak Initiation: A Route announced over a Link by a Neighbor, 198 which does not match the Link Classification, where one of the 199 following is true: 200 o the Neighbor is the Originator 201 o the Neighbor received the Route, where the received Route was not 202 a Route Leak 203 In lay terms, this means that the Neighbor is the party that caused 204 the route leak, by announcing a route contrary to the Link 205 Classification (and consequently also violated the Local Policy). 207 Route Leak Propagation: A Route announced over a Link by a Neighbor, 208 where the Route that the Neighbor received was either a Route Leak 209 Initiation, or a Route Leak Propagation. 211 Once a Route has become a Route Leak Initiation, any further 212 announcement of that Route is a Route Leak Propagation. 214 NB: A Route Leak Propagation may appear to match the Link 215 Classification, since the Path appears similar to non-leaked routes 216 for the first two ASNs in the Path. 218 Link Classifications: a Link may be classified as: 219 o Customer 220 o Transit 221 o Peer 222 o Special (which includes Mutual Transit, Sibling, and other non- 223 trivial arrangements) 225 Special (e.g. Mutual Transit): a Link where the two parties agree to 226 provide full routes, and to advertise each others' customers routes 227 the same as they would advertise their own customers' routes. 228 Semantically, this behaves the same as having two parallel Links 229 between the same two Neighbors, where one Link Policy is Transit and 230 the other Link Policy is Customer. Recall, Link Classification is 231 the superset of Local Policy - the term "full routes" here means 232 simply that any route in addition to customers' routes, is permitted. 234 4. Peer Links and Routes 236 A Peer Classification is a Link over which the two parties send ONLY 237 their respective Customer Routes (and their Customer's Routes, and so 238 on). 240 A Link which is classified as a Peer, will see us as a Peer 241 Classification as well. The relationship is symmetric in nature. 243 5. Customer Links and Routes 245 A Customer Link Classification: The Customer sends us only their own 246 (locally originated) Routes, and the Customer's Customer's Routes 247 (and Customer^Nth Routes). The Customer relationship is transitive. 249 A Transit Link Classification: The Transit provider sends all Routes. 250 This include the Transit Provider's Customers, the Transit Provider's 251 Peers, and if there are any, the Transit Provider's Transit 252 Provider's Routes. The Transit Provider relationship is also 253 transitive. 255 Transit and Customer are the opposite ends of the same Link, by 256 definition. 258 The Transit Link Classification is a superset of the actual Local 259 Policy of a specific Customer. This means that while a Transit Link 260 Classification means "we send all routes", the actual Local Policy 261 for a specific Customer might differ, and the Customer might only 262 receive some Routes, or none at all. Similarly, the Classification 263 means that we are prepared to accept the Customer's own Routes, as 264 well as those of the Customer's Customers. However, the Local Policy 265 might be to accept only a specific subset of the Customer's Routes. 267 5.1. Customer's Customer 269 It is important to define when a Route is a Customer's Customer 270 Route. 272 A Customer's Customer Route: the Path to be from the Customer's 273 Customer, to the Customer, to us. Similarly, Customer^Nth Paths must 274 proceed directly from Customer^N to Customer^(N-1) to Customer to us. 275 It is not sufficient for the Origin of the Route to be the ASN of a 276 Customer's Customer. Each Link must be a Customer Classification (or 277 Special, e.g. Mutual Transit, which is a superset of Customer). 279 In particular, if the Path were to include any Link which were not a 280 Customer Link, the Route would NOT be a Customer^N. 282 NB: It is sufficient that the Customer's Customer relationship is 283 declared. The "Customer" relationship, in the context of route 284 leaks, is restrictive. Erroneous or inadvertent classification as 285 Customer cannot result in a route leak. 287 6. Non-Leak-Initiation Links 289 To help identify the exact conditions where a Route Leak Initiation 290 can occur, it is helpful to exclude Link Classifications where it is 291 axiomatically impossible to cause a Route Leak Initiation. 293 Since a Transit Classification, by definition, can receive all 294 routes, a Transit Link cannot be the source of a Route Leak 295 Initiation. By the same logic, a Special (e.g. Mutual Transit) 296 Classification cannot be the source of a Route Leak Initiation. 298 This leads to a more precise definition of a Route Leak Initiation. 300 7. Route Leak Initiation 302 Route Leak Initiation: A Non-Customer Route which is received over a 303 Peer or Customer Link. 305 8. Route Leak 307 Route Leak: any Route where, somewhere in the Path, a Non-Customer 308 Route was received over a Peer or Customer Link. (This is synomous 309 with "was sent over a Peer or Transit Link".) 311 It should be observed that a route which is not a route leak, has an 312 as-path that matches the following pattern: 314 {C|S}*P?{T|S}* 316 Where C is Customer, T is Transit, P is Peer, and S is Special, and 317 "{ | }" denotes either/or, "*" means zero or more occurrences of, and 318 "?" means zero or one occurrences of. 320 9. Security Considerations 322 None per se. 324 10. IANA Considerations 326 This document contains no IANA-specific material. 328 11. Acknowledgements 330 To be added later. 332 12. References 334 12.1. Normative References 336 [RFC1033] Lottor, M., "Domain administrators operations guide", 337 RFC 1033, November 1987. 339 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 340 STD 13, RFC 1034, November 1987. 342 [RFC1035] Mockapetris, P., "Domain names - implementation and 343 specification", STD 13, RFC 1035, November 1987. 345 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 346 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 347 RFC 2136, April 1997. 349 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 350 Specification", RFC 2181, July 1997. 352 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 353 NCACHE)", RFC 2308, March 1998. 355 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 356 Rose, "DNS Security Introduction and Requirements", 357 RFC 4033, March 2005. 359 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 360 Rose, "Resource Records for the DNS Security Extensions", 361 RFC 4034, March 2005. 363 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 364 Trust Anchors", RFC 5011, September 2007. 366 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 367 Security (DNSSEC) Hashed Authenticated Denial of 368 Existence", RFC 5155, March 2008. 370 12.2. Informative References 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, March 1997. 375 Author's Address 377 Brian Dickson 378 Brian Dickson 379 703 Palmer Drive, 380 Herndon, VA 20170 381 USA 383 Email: brian.peter.dickson@gmail.com