idnits 2.17.1 draft-beck-bgp-security-tracking-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 4) being 121 lines 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 (Mar 2019) is 1870 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: 'RFC4271' is defined on line 345, but no explicit reference was found in the text == Unused Reference: 'RFC1997' is defined on line 357, but no explicit reference was found in the text == Unused Reference: 'RFC4360' is defined on line 361, but no explicit reference was found in the text == Unused Reference: 'RFC6793' is defined on line 365, but no explicit reference was found in the text == Unused Reference: 'RFC7300' is defined on line 370, but no explicit reference was found in the text == Unused Reference: 'RFC7607' is defined on line 379, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIDR Working Group J. Beck 2 Internet-Drafts A. Gray 3 Intended status: Standards Track Charter 4 Expires: Oct 1, 2019 Mar 2019 6 BGP Security Tracking 7 draft-beck-bgp-security-tracking-00 9 Abstract 11 This document describes the BGP Path Security Tracking attribute, an 12 extension to BGP-4. This attribute provides a transitive means for 13 networks to indicate BGP security checks in place to upstream 14 networks. Upstream networks can optionally use that information to 15 modify the path selection algorithm giving preference to paths 16 reporting better security where the prefix length is the same and 17 as-path length is similar. Effectively reporting no security would 18 be treated the same as prepending the announcement once and reporting 19 strong security would be treated the same as not prepending. The net 20 result of using the information to influence path selection is that 21 more secured paths would be preferred over less secured paths. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on Oct 1, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction ....................................................2 58 2. Requirements Language ...........................................3 59 3. BGP Security Tracking Attribute .................................3 60 4. Canonical Representation.........................................4 61 5. Cost Value of Security Methods Used..............................4 62 6. Modifying Path Selection Algorithm...............................5 63 7. Error Handling...................................................5 64 8. Security Considerations .........................................5 65 9. IANA Considerations .............................................6 66 10. References .....................................................6 67 10.1. Normative References ......................................6 68 10.2. Informative References ....................................6 69 Acknowledgments ....................................................7 70 Contributors .......................................................7 71 Authors' Addresses .................................................8 73 1. Introduction 75 Securing BGP from unauthorized prefix leaks is important. There are 76 multiple measures available to validate inbound route announcements 77 but most are only locally significant within an autonomous system 78 (AS).The BGP Security tracking attribute allows a BGP speaking router 79 to optionally mark the validation steps that were performed on a 80 prefix with an attribute after accepting the prefix as valid for the 81 purpose of transparency and allowing that information to influence 82 the BGP path selection process. A router that learns of a prefix 83 equal in length from multiple sources may optionally choose a path 84 with better advertised security practices over a less secured one. 86 The intent is to encourage better security practices and partially 87 limit the radius and impact of unauthorized route announcements. 88 Functionally the path selection is modified by assigning a cost 89 based security practices implemented. A network with no ingress 90 security would have a cost of 1 and a network with good ingress 91 security would have a cost of 0. The BGP path selection algorithm 92 would then be modified to evaluate the sum of ASN's in AS_PATH 93 combined with the security measures for each network. A prefix 94 with an AS_PATH length of 3 with no security would have a "cost" 95 of 6 and prefix with an AS_PATH length of 3 with "good" security 96 would have a "cost" of 3 allowing preference to the theoretically 97 more secure path. Because the "cost" of security is less than or 98 equal to an additional ASN in AS_PATH a bad actor is discouraged 99 from spoofing false ASN's for the purpose of forging the security 100 of that relationship. 102 2. Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 3. BGP Security Tracking Attribute 110 This document defines the BGP Security Tracking attribute as an 111 optional transitive path attribute of variable length. The values 112 are written to the prefix being accepted by the border router 113 typically over an eBGP session before being announced upstream 114 to other iBGP or eBGP peers. Networks opting not to disclose the 115 information or not running supporting software do not push a value 116 to the accepted prefix. 118 (Attribute type code for Security Tracking is to be assigned by IANA) 120 The format of the field is a concatenated list of 32-bit pairs of 121 values, with each pair having the following definition: 123 0 1 2 3 124 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 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | ASN Writing Value | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Reserved |B|R|R|A|C|P|N| 129 | |S|E|V|P|M|L|D| 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 All bits in the bitfield must start set to zero, and then set as below: 133 +------+-------------+------------------------------------------------+ 134 | Abbr | Name | Set to 1 if and only if | 135 +------+-------------+------------------------------------------------+ 136 | BS | BGPSec | Evaluated against BGPSec and returned VALID | 137 | RE | RPKI Eval | Evaluated against RPKI and was not INVALID | 138 | RV | RPKI Valid | Evaluated against RPKI and was VALID | 139 | AP | AS-Path | Validated against a per-customer AS-Path filter| 140 | CM | Community | Validated against a community tag value | 141 | PL | Prefix List | Validated against a per-customer prefix list | 142 | ND | Blocked | Data Not Disclosed | 143 +------+-------------+------------------------------------------------+ 145 The order of the attribute SHOULD reflect the order of ASN's in the 146 AS_PATH. An ASN that is in the AS_PATH that lacks a corresponding BGP 147 Security Tracking Attribute is assumed to be not participating or not 148 supported. 150 Setting a value is OPTIONAL but a network router MUST NOT modify 151 values written by other downstream ASN's in the AS_PATH. 153 A value SHOULD be determined by the ingress router over an eBGP 154 boundary. The originating ASN MUST NOT set a value for itself. 156 4. Canonical Representation 158 The canonical representation of the BGP Security Tracking attribute 159 is 2 separate unsigned integers in decimal notation in the following 160 order: Autonomous System Number, Security Methods Used. Numbers MUST 161 NOT contain leading zeros; a zero value MUST be represented with a 162 single zero. Each number is separated from the next by a single colon. 163 For example: 64496:50 (RPKI Valid, validated against prefix list) or 164 64496:1 (data administratively suppressed). 166 5. Cost Value of Security Methods Used 168 84% of ASN's are stubs. Average AS-PATH length is 4-5 hops 169 or 3.8 hops after accounting for prepends. Research by Sharon 170 Goldberg and Boston University reflects that security against 171 invalid announcements requires a combination of methods to be 172 successful. 173 (Ref: http://www.cs.bu.edu/~goldbe/papers/BGPsecurityGoldbe.pdf) 175 As such, it is the intent of the cost values to reward use of 176 multiple approaches and best practices. The use of the BGP Security 177 Tracking attribute to modify the Path Selection Algorithm of BGP is 178 OPTIONAL. 180 Methodology: By default networks with no security or no available 181 data have a cost metric of 1. That value is reduced by 0.5 or 0.25 182 for validation methods used until the cost reaches 0 with 0 being the 183 lowest possible and 1 being the highest possible value. 185 The cost reduction amounts are as follows: 187 1. Not Disclosed -0 189 2. Filtered against prefix list -0.5 191 3. RPKI Valid -0.5 193 4. RPKI Invalid +1 195 5. BGPsec -0.5 197 6. Validated against community -0.25 199 7. Validated against AS_PATH -0.25 201 6. Modifying BGP Best Path Selection Algorithm 203 The use of the BGP Security Tracking attribute to modify the BGP Best 204 Path Selection Algorithm of BGP is OPTIONAL. 206 In the path selection algorithm where a prefix is normally selected 207 based on shortest AS_PATH this process is modified to take the sum of 208 the AS_PATH plus the security tracking cost of the path. Functionally 209 less secured paths have a higher cost of AS_PATH + Security and more 210 secured paths have a lower cost of AS_PATH + Security. 212 Example 6.1 214 View from within ASN 64496: 216 Security Attribute: 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | 64496 | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | 0 |1|0|1|1|0|1|0| - cost = 0 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | 64497 | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | 0 |0|0|0|1|1|0|0| - cost = 0.5 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | 64498 | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | 0 |0|0|0|0|0|1|0| - cost = 0.5 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 In example 6.1 even though the AS_PATH length is 3 the combined 232 "cost" to reach the prefix is 4. There is no security value for ASN 233 64499 because it is the originating ASN and doesn't perform ingress 234 validation of its own routes. There are 3 security tracking values 235 because 64496:90 was written by the local ASN. 237 Example 6.2 239 View from within ASN 64496: 240 Security Attribute: 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | 64996 | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | 0 |0|0|0|0|0|0|1| - cost = 1 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | 65537 | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | 0 |0|0|0|0|0|0|1| - cost = 1 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | 65536 | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | 0 |1|0|1|1|0|1|0| - cost = 0 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 In example 6.2 even the AS_PATH length is 3 and the security "cost" 256 is 2 for a total cost to reach the prefix of 5. A network evaluating 257 a prefix with equal length received from both the example 6.1 and 6.2 258 path will see example 6.1 as having a shorter [AS_PATH + Security] 259 preferring it. 261 In the event of a tie in combined AS_PATH + Security length the path 262 with the lower security cost should be preferred breaking the tie. In 263 the event they are both tied the router should continue through 264 normal path selection or ECMP behavior. 266 7. Error Handling 268 The error handling of BGP Path Security Tracking is as follows: 270 o A BGP Security Tracking attribute SHALL be considered malformed if 271 the length of the BGP Security Tracking Attribute value, expressed 272 in octets, is not a non-zero multiple of 8. 274 o A BGP Security Tracking attribute SHALL be considered 275 malformed due to presence of duplicate ASNs. 277 o A BGP Security Tracking attribute exceeding the number of 278 ASNs in AS_PATH SHALL pair entries with corresponding ASN's in 279 AS_PATH ignoring invalid entries (to handle potential 280 repercussions of remove-private) 282 o A BGP UPDATE message with a malformed BGP Security Tracking 283 attribute SHALL be handled using the approach of "treat-as- 284 withdraw" as described in Section 2 of [RFC7606]. 286 o If bits in the Reserved section are set, they MUST be preserved 287 and MUST NOT be used for evaluation of the security "cost". 289 The BGP Security Tracking ASN field may contain any value, 290 and a BGP Security Tracking attribute MUST NOT be considered 291 malformed if the ASN field contains an unallocated, unassigned, 292 or reserved ASN. 294 8. Security Considerations 296 As this document describes a security protocol, many aspects of 297 security interest are described in relevant sections. This section 298 points out issues that may not be obvious in other sections. 300 Spoofing of invalid path attribute values: 301 The most obvious means to defeat this measure is to falsify data 302 about security checks that were not actually performed such as 303 reporting that a prefix has been thoroughly validated when it has 304 not. This is addressed by being lower to equal in value in the BGP 305 Best Path Algorithm. If a bad actor is able to forge data it would 306 generally be more beneficial to do so by shorting the AS_PATH rather 307 than falsifying data about prefix validation or spoofing downstream 308 ASN's for the purpose of reporting those borders as secure. 310 The exception to this is that it is possible to defeat RPKI 311 validation by spoofing the valid origin ASN as being downstream 312 artificially extending the AS_PATH length for the purpose of 313 validating RPKI. In that case it would be more beneficial to forge 314 the path security attribute data rather than shorten the AS_PATH. 316 More Specific Prefix Announcement: 317 The purpose of the path security tracking is to be able to select 318 more secure paths over less secure paths where prefix length is 319 equal. It does not override the preference for more specific routes 320 over less specific routes and as such doesn't directly address the 321 problem of invalid more specific announcements into the BGP table. 322 It does indirectly help by encouraging adoption of better input 323 validation and potential increased adoption of recommended best 324 practices. 326 Network administrators should note the recommendations in [RFC7454] 327 "BGP Operations and Security". 329 9. IANA Considerations 331 It is requested that IANA assign a value for SECURITY_TRACKING for 332 an optional transitive attribute under the "BGP Path Attributes" 333 subregistry under the Border Gateway Protocol (BGP) Parameters 334 registry. 336 10. References 338 10.1. Normative References 340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 341 Requirement Levels", BCP 14, RFC 2119, 342 DOI 10.17487/RFC2119, March 1997, 343 . 345 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 346 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 347 DOI 10.17487/RFC4271, January 2006, 348 . 350 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 351 Patel, "Revised Error Handling for BGP UPDATE Messages", 352 RFC 7606, DOI 10.17487/RFC7606, August 2015, 353 . 355 10.2. Informative References 357 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 358 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 359 . 361 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 362 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 363 February 2006, . 365 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 366 Autonomous System (AS) Number Space", RFC 6793, 367 DOI 10.17487/RFC6793, December 2012, 368 . 370 [RFC7300] Haas, J. and J. Mitchell, "Reservation of Last Autonomous 371 System (AS) Numbers", BCP 6, RFC 7300, 372 DOI 10.17487/RFC7300, July 2014, 373 . 375 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 376 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 377 February 2015, . 379 [RFC7607] Kumari, W., Bush, R., Schiller, H., and K. Patel, 380 "Codification of AS 0 Processing", RFC 7607, 381 DOI 10.17487/RFC7607, August 2015, 382 . 384 Acknowledgments 386 The authors would like to thank Jon Doe 388 Contributors 390 The following people contributed significantly to the content of the 391 document: 393 Jon Doe 394 Company Name 395 Email: email@domain.com 397 Authors' Addresses 399 Jody Beck 400 Charter Communications 401 14810 Grasslands Drive 402 Englewood, CO 80112 403 United States of America 404 Email: jody.beck@charter.com 406 Andrew Gray 407 Charter Communications 408 14810 Grasslands Drive 409 Englewood, CO 80112 410 United States of America 411 Email: andrew.gray@charter.com