idnits 2.17.1 draft-dickson-sidr-route-leak-solns-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 '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 (March 6, 2012) is 4431 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 226, but no explicit reference was found in the text == Unused Reference: 'RFC1997' is defined on line 229, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 232, but no explicit reference was found in the text == Unused Reference: 'RFC4456' is defined on line 235, but no explicit reference was found in the text == Unused Reference: 'RFC4760' is defined on line 239, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1773 Summary: 1 error (**), 0 flaws (~~), 8 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 -- Proposed Solutions 7 draft-dickson-sidr-route-leak-solns-01 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 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 discussion on what 23 a route leak is, and what the scope of the problem space for route 24 leaks is. This, in turn, is intended to inform a requirements 25 document for detection of (and prevention of) route leaks. And 26 finally, the definitions and requirements are intended to allow 27 proposed solutions which meet these criteria, and to facilitate 28 evaluation of proposed solutions. 30 The fundamental objective is to "solve the route leaks problem". 32 Author's Note 34 Intended Status: Standards track. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on September 7, 2012. 53 Copyright Notice 55 Copyright (c) 2012 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Prefix Attribute Possibilities . . . . . . . . . . . . . . . . 4 75 3. Encoding Color via Choice of Algorithm . . . . . . . . . . . . 5 76 4. Encoding Color via a Second Signature Block . . . . . . . . . . 5 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 85 1. Introduction 87 1.1. Rationale 89 This document describes two different schemes for implementing a 90 solution for route leaks. 92 They represent different trade-offs between simplicity of 93 implementation, versus embedding information. The information 94 embedded can be inferred currently from a variety of sources, so the 95 risk/cost of doing so is marginal. 97 Either solution would be adequate to solve the route leak problem. 99 Due to the requirement for mandatory establishment of peering link 100 types, and cryptographic protection, the ideal time and place to 101 implement this would be coincident with BGPSEC. 103 Including route leak protection with BGPSEC may be beneficial to the 104 latter. It is more compelling to deploy a solution to both sets of 105 problems, than to deploy a solution to one or the other alone. 107 1.2. Requirements 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 1.3. Terminology 115 The reader is assumed to be familiar with the IETF. 117 2. Prefix Attribute Possibilities 119 If we presume that there are two possible colors for a prefix, then 120 we have three ways to express those colors: 122 1. A single bit, with two possible values, always attached to a 123 prefix. 125 2. An attribute whose presence signals one of the colors, and whose 126 absence signals the other color. 128 3. The same as 2, but with the other color being signaled. 130 For sake of clarity, we will use a fairly universally understood pair 131 of colors, "green" (meaning "proceed"), and "yellow" (meaning 132 "caution"). 134 So, the three ways of marking the colors are: 136 Use a green/yellow bit (green if 1, yellow if 0) 138 Use a "green" attribute (green if present, yellow otherwise) 140 Use a "yellow" attribute (yellow if present, green otherwise). 142 Since information is leaked for both the "green/yellow bit" and 143 "yellow attribute", there is no reason to discuss the "yellow 144 attribute" option. It is inferior to both other methods. 146 3. Encoding Color via Choice of Algorithm 148 Here, we are presuming that BGPSEC is in use on prefixes, and that 149 BGPSEC includes an explicit algorithm identifier. Currently, the 150 identifier only specifies which algorithm to use to validate the 151 signature in the signature block. 153 This would be augmented so that for any given algorithm, two 154 identifiers would be assigned. One would be the identifier 155 signifying "Green", and the other would signify "Yellow". When 156 sending a "green" route, the current "green" algorithm would be used. 157 When sending a "yellow" route, the current "yellow" algorithm would 158 be used. Validation would work as usual, with the additional ability 159 to validate the color rules for preventing route leaks. 161 No additional changes to the structure of the BGPSEC protocol or wire 162 format are needed. 164 However, there is the leak of information about transit 165 relationships, which is unavoidable with this design. 167 Routes which violate the path coloring rules but otherwise validate, 168 would be blocked. (They should not occur, but should be checked 169 regardless.) Routes which do not validate under BGPSEC would be 170 blocked regardless, also preventing a potential source of route 171 leaks. 173 4. Encoding Color via a Second Signature Block 175 A signature block analogous to the AS-PATH signature block, would be 176 included on any announcement that is "green". The local sender would 177 add her signature to the signature block on these "green" 178 announcements. In addition, the new signature block would be sent 179 across the "green/yellow" boundary to any Peer. However, when 180 sending across the "green/yellow" boundary, would not add her 181 signature to the block. 183 The recipient would be able to validate all the "green" signatures up 184 to the sender, and if present, the sender's signature as well. If 185 the "green" signature does not include the sender, no more signatures 186 can be attached. When sending to a "yellow" peer, the "green 187 attribute" block is stripped (if present). The absence of a "green 188 block" means the prefix is considered "yellow". This mechanism is 189 not "free" in that more crypto calculations are needed, the structure 190 of the BGPSEC attributes change, and more data is needed on each 191 announcement within the "green" zone. 193 However, no information concerning relationships is leaked, beyond 194 what the recipient can already infer. A transit provider already 195 knows his/her customers, and their customers, etc. 197 From a scaling perspective, it should be noted that only customers' 198 prefixes require additional signatures, so the number of prefixes 199 with those signatures is proportionally smaller. Signature 200 validation is only done on the "green block" upon receiving a 201 customer's routes or a peer's routes. This also minimizes the 202 incremental cost. 204 Since it is physically impossible to promote a "yellow" route to a 205 "green" route, because the originators "green" block is absent, this 206 is a very strong mechanism for stopping route leaks. Validating link 207 type versus color, after validation of any "green block" present, is 208 sufficient to stop route leaks. 210 5. Security Considerations 212 None per se. 214 6. IANA Considerations 216 This document contains no IANA-specific material. 218 7. Acknowledgements 220 To be added later. 222 8. References 224 8.1. Normative References 226 [RFC1773] Traina, P., "Experience with the BGP-4 protocol", 227 RFC 1773, March 1995. 229 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 230 Communities Attribute", RFC 1997, August 1996. 232 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 233 Protocol 4 (BGP-4)", RFC 4271, January 2006. 235 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 236 Reflection: An Alternative to Full Mesh Internal BGP 237 (IBGP)", RFC 4456, April 2006. 239 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 240 "Multiprotocol Extensions for BGP-4", RFC 4760, 241 January 2007. 243 8.2. Informative References 245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", BCP 14, RFC 2119, March 1997. 248 Author's Address 250 Brian Dickson 251 Brian Dickson 252 703 Palmer Drive, 253 Herndon, VA 20170 254 USA 256 Email: brian.peter.dickson@gmail.com