SIDR Working Group J. Beck Internet-Drafts A. Gray Intended status: Standards Track Charter Expires: Oct 1, 2019 Mar 2019 BGP Security Tracking draft-beck-bgp-security-tracking-00 Abstract This document describes the BGP Path Security Tracking attribute, an extension to BGP-4. This attribute provides a transitive means for networks to indicate BGP security checks in place to upstream networks. Upstream networks can optionally use that information to modify the path selection algorithm giving preference to paths reporting better security where the prefix length is the same and as-path length is similar. Effectively reporting no security would be treated the same as prepending the announcement once and reporting strong security would be treated the same as not prepending. The net result of using the information to influence path selection is that more secured paths would be preferred over less secured paths. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on Oct 1, 2019. Beck, et al. Expires Oct 1, 2019 [Page 1] Internet-Draft BGP Security Tracking Nov 2018 Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ....................................................2 2. Requirements Language ...........................................3 3. BGP Security Tracking Attribute .................................3 4. Canonical Representation.........................................4 5. Cost Value of Security Methods Used..............................4 6. Modifying Path Selection Algorithm...............................5 7. Error Handling...................................................5 8. Security Considerations .........................................5 9. IANA Considerations .............................................6 10. References .....................................................6 10.1. Normative References ......................................6 10.2. Informative References ....................................6 Acknowledgments ....................................................7 Contributors .......................................................7 Authors' Addresses .................................................8 1. Introduction Securing BGP from unauthorized prefix leaks is important. There are multiple measures available to validate inbound route announcements but most are only locally significant within an autonomous system (AS).The BGP Security tracking attribute allows a BGP speaking router to optionally mark the validation steps that were performed on a prefix with an attribute after accepting the prefix as valid for the purpose of transparency and allowing that information to influence the BGP path selection process. A router that learns of a prefix equal in length from multiple sources may optionally choose a path with better advertised security practices over a less secured one. The intent is to encourage better security practices and partially limit the radius and impact of unauthorized route announcements. Functionally the path selection is modified by assigning a cost based security practices implemented. A network with no ingress security would have a cost of 1 and a network with good ingress security would have a cost of 0. The BGP path selection algorithm would then be modified to evaluate the sum of ASN's in AS_PATH combined with the security measures for each network. A prefix with an AS_PATH length of 3 with no security would have a "cost" of 6 and prefix with an AS_PATH length of 3 with "good" security would have a "cost" of 3 allowing preference to the theoretically more secure path. Because the "cost" of security is less than or equal to an additional ASN in AS_PATH a bad actor is discouraged from spoofing false ASN's for the purpose of forging the security of that relationship. Beck, et al. Expires Oct 1, 2019 [Page 2] Internet-Draft BGP Security Tracking Nov 2018 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. BGP Security Tracking Attribute This document defines the BGP Security Tracking attribute as an optional transitive path attribute of variable length. The values are written to the prefix being accepted by the border router typically over an eBGP session before being announced upstream to other iBGP or eBGP peers. Networks opting not to disclose the information or not running supporting software do not push a value to the accepted prefix. (Attribute type code for Security Tracking is to be assigned by IANA) The format of the field is a concatenated list of 32-bit pairs of values, with each pair having the following definition: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASN Writing Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |B|R|R|A|C|P|N| | |S|E|V|P|M|L|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All bits in the bitfield must start set to zero, and then set as below: +------+-------------+------------------------------------------------+ | Abbr | Name | Set to 1 if and only if | +------+-------------+------------------------------------------------+ | BS | BGPSec | Evaluated against BGPSec and returned VALID | | RE | RPKI Eval | Evaluated against RPKI and was not INVALID | | RV | RPKI Valid | Evaluated against RPKI and was VALID | | AP | AS-Path | Validated against a per-customer AS-Path filter| | CM | Community | Validated against a community tag value | | PL | Prefix List | Validated against a per-customer prefix list | | ND | Blocked | Data Not Disclosed | +------+-------------+------------------------------------------------+ The order of the attribute SHOULD reflect the order of ASN's in the AS_PATH. An ASN that is in the AS_PATH that lacks a corresponding BGP Security Tracking Attribute is assumed to be not participating or not supported. Setting a value is OPTIONAL but a network router MUST NOT modify values written by other downstream ASN's in the AS_PATH. A value SHOULD be determined by the ingress router over an eBGP boundary. The originating ASN MUST NOT set a value for itself. Beck, et al. Expires Oct 1, 2019 [Page 3] Internet-Draft BGP Security Tracking Nov 2018 4. Canonical Representation The canonical representation of the BGP Security Tracking attribute is 2 separate unsigned integers in decimal notation in the following order: Autonomous System Number, Security Methods Used. Numbers MUST NOT contain leading zeros; a zero value MUST be represented with a single zero. Each number is separated from the next by a single colon. For example: 64496:50 (RPKI Valid, validated against prefix list) or 64496:1 (data administratively suppressed). 5. Cost Value of Security Methods Used 84% of ASN's are stubs. Average AS-PATH length is 4-5 hops or 3.8 hops after accounting for prepends. Research by Sharon Goldberg and Boston University reflects that security against invalid announcements requires a combination of methods to be successful. (Ref: http://www.cs.bu.edu/~goldbe/papers/BGPsecurityGoldbe.pdf) As such, it is the intent of the cost values to reward use of multiple approaches and best practices. The use of the BGP Security Tracking attribute to modify the Path Selection Algorithm of BGP is OPTIONAL. Methodology: By default networks with no security or no available data have a cost metric of 1. That value is reduced by 0.5 or 0.25 for validation methods used until the cost reaches 0 with 0 being the lowest possible and 1 being the highest possible value. The cost reduction amounts are as follows: 1. Not Disclosed -0 2. Filtered against prefix list -0.5 3. RPKI Valid -0.5 4. RPKI Invalid +1 5. BGPsec -0.5 6. Validated against community -0.25 7. Validated against AS_PATH -0.25 6. Modifying BGP Best Path Selection Algorithm The use of the BGP Security Tracking attribute to modify the BGP Best Path Selection Algorithm of BGP is OPTIONAL. In the path selection algorithm where a prefix is normally selected based on shortest AS_PATH this process is modified to take the sum of the AS_PATH plus the security tracking cost of the path. Functionally less secured paths have a higher cost of AS_PATH + Security and more secured paths have a lower cost of AS_PATH + Security. Example 6.1 View from within ASN 64496: Security Attribute: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 64496 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |1|0|1|1|0|1|0| - cost = 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 64497 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |0|0|0|1|1|0|0| - cost = 0.5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 64498 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |0|0|0|0|0|1|0| - cost = 0.5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In example 6.1 even though the AS_PATH length is 3 the combined "cost" to reach the prefix is 4. There is no security value for ASN 64499 because it is the originating ASN and doesn't perform ingress validation of its own routes. There are 3 security tracking values because 64496:90 was written by the local ASN. Example 6.2 View from within ASN 64496: Security Attribute: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 64996 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |0|0|0|0|0|0|1| - cost = 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 65537 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |0|0|0|0|0|0|1| - cost = 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 65536 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |1|0|1|1|0|1|0| - cost = 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In example 6.2 even the AS_PATH length is 3 and the security "cost" is 2 for a total cost to reach the prefix of 5. A network evaluating a prefix with equal length received from both the example 6.1 and 6.2 path will see example 6.1 as having a shorter [AS_PATH + Security] preferring it. In the event of a tie in combined AS_PATH + Security length the path with the lower security cost should be preferred breaking the tie. In the event they are both tied the router should continue through normal path selection or ECMP behavior. Beck, et al. Expires Oct 1, 2019 [Page 4] Internet-Draft BGP Security Tracking Nov 2018 7. Error Handling The error handling of BGP Path Security Tracking is as follows: o A BGP Security Tracking attribute SHALL be considered malformed if the length of the BGP Security Tracking Attribute value, expressed in octets, is not a non-zero multiple of 8. o A BGP Security Tracking attribute SHALL be considered malformed due to presence of duplicate ASNs. o A BGP Security Tracking attribute exceeding the number of ASNs in AS_PATH SHALL pair entries with corresponding ASN's in AS_PATH ignoring invalid entries (to handle potential repercussions of remove-private) o A BGP UPDATE message with a malformed BGP Security Tracking attribute SHALL be handled using the approach of "treat-as- withdraw" as described in Section 2 of [RFC7606]. o If bits in the Reserved section are set, they MUST be preserved and MUST NOT be used for evaluation of the security "cost". The BGP Security Tracking ASN field may contain any value, and a BGP Security Tracking attribute MUST NOT be considered malformed if the ASN field contains an unallocated, unassigned, or reserved ASN. Beck, et al. Expires Oct 1, 2019 [Page 5] Internet-Draft BGP Security Tracking Nov 2018 8. Security Considerations As this document describes a security protocol, many aspects of security interest are described in relevant sections. This section points out issues that may not be obvious in other sections. Spoofing of invalid path attribute values: The most obvious means to defeat this measure is to falsify data about security checks that were not actually performed such as reporting that a prefix has been thoroughly validated when it has not. This is addressed by being lower to equal in value in the BGP Best Path Algorithm. If a bad actor is able to forge data it would generally be more beneficial to do so by shorting the AS_PATH rather than falsifying data about prefix validation or spoofing downstream ASN's for the purpose of reporting those borders as secure. The exception to this is that it is possible to defeat RPKI validation by spoofing the valid origin ASN as being downstream artificially extending the AS_PATH length for the purpose of validating RPKI. In that case it would be more beneficial to forge the path security attribute data rather than shorten the AS_PATH. More Specific Prefix Announcement: The purpose of the path security tracking is to be able to select more secure paths over less secure paths where prefix length is equal. It does not override the preference for more specific routes over less specific routes and as such doesn't directly address the problem of invalid more specific announcements into the BGP table. It does indirectly help by encouraging adoption of better input validation and potential increased adoption of recommended best practices. Network administrators should note the recommendations in [RFC7454] "BGP Operations and Security". Beck, et al. Expires Oct 1, 2019 [Page 6] Internet-Draft BGP Security Tracking Nov 2018 9. IANA Considerations It is requested that IANA assign a value for SECURITY_TRACKING for an optional transitive attribute under the "BGP Path Attributes" subregistry under the Border Gateway Protocol (BGP) Parameters registry. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . 10.2. Informative References [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, . [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, . [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, . [RFC7300] Haas, J. and J. Mitchell, "Reservation of Last Autonomous System (AS) Numbers", BCP 6, RFC 7300, DOI 10.17487/RFC7300, July 2014, . [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, February 2015, . Beck, et al. Expires Oct 1, 2019 [Page 7] Internet-Draft BGP Security Tracking Nov 2018 [RFC7607] Kumari, W., Bush, R., Schiller, H., and K. Patel, "Codification of AS 0 Processing", RFC 7607, DOI 10.17487/RFC7607, August 2015, . Acknowledgments The authors would like to thank Jon Doe Contributors The following people contributed significantly to the content of the document: Jon Doe Company Name Email: email@domain.com Beck, et al. Expires Oct 1, 2019 [Page 8] Internet-Draft BGP Security Tracking Nov 2018 Authors' Addresses Jody Beck Charter Communications 14810 Grasslands Drive Englewood, CO 80112 United States of America Email: jody.beck@charter.com Andrew Gray Charter Communications 14810 Grasslands Drive Englewood, CO 80112 United States of America Email: andrew.gray@charter.com Beck, et al. Expires Oct 1, 2019 [Page 9]