[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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,
              <http://www.rfc-editor.org/info/rfc2119>.

   [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,
              <http://www.rfc-editor.org/info/rfc4271>.

   [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,
              <http://www.rfc-editor.org/info/rfc7606>.

10.2.  Informative References

   [RFC1997]  Chandra, R., Traina, P., and T. Li, "BGP Communities
              Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
              <http://www.rfc-editor.org/info/rfc1997>.

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
              February 2006, <http://www.rfc-editor.org/info/rfc4360>.

   [RFC6793]  Vohra, Q. and E. Chen, "BGP Support for Four-Octet
              Autonomous System (AS) Number Space", RFC 6793,
              DOI 10.17487/RFC6793, December 2012,
              <http://www.rfc-editor.org/info/rfc6793>.

   [RFC7300]  Haas, J. and J. Mitchell, "Reservation of Last Autonomous
              System (AS) Numbers", BCP 6, RFC 7300,
              DOI 10.17487/RFC7300, July 2014,
              <http://www.rfc-editor.org/info/rfc7300>.

   [RFC7454]  Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
              and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
              February 2015, <http://www.rfc-editor.org/info/rfc7454>.



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,
              <http://www.rfc-editor.org/info/rfc7607>.

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/