Internet DRAFT - draft-van-beijnum-sidrops-pathrpki

draft-van-beijnum-sidrops-pathrpki







SIDR Operations                                           I. van Beijnum
Internet-Draft                                             BGPexpert.com
Updates: RFC 3779, RFC 8210 (if                            June 20, 2019
         approved)
Intended status: Experimental
Expires: December 22, 2019


                       Path validation with RPKI
                 draft-van-beijnum-sidrops-pathrpki-00

Abstract

   This memo adds the capability to validate the full BGP AS path to the
   RPKI mechanism.

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 https://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 December 22, 2019.

Copyright Notice

   Copyright (c) 2019 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
   (https://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.




Van Beijnum             Expires December 22, 2019               [Page 1]

Internet-Draft          Path validation with RPKI              June 2019


1.  Introduction

   With RPKI, it's possible for BGP routers to validate the origin AS
   found in the BGP AS path attribute for a given IP prefix.  However,
   RPKI can't validat the rest of the AS path, allowing for route leaks
   types 1 - 4 as described in RFC 7908 [RFC7908].

   This specification extends RPKI to allow for validating the full BGP
   AS path, based on the observation that each AS in a valid AS path has
   either a trust relation with the origin AS or has a trust relation
   with the local AS (the AS performing validation).  I.e., each
   intermediary AS provides transit service to either the origin AS or
   the local AS.

   An extension to RFC 3779 [RFC3779] allows for binding a list of
   allowed transit ASes to a set of IP addresses.  Operators of RPKI
   [RFC6480] relying party software add to this their list of locally
   allowed transit ASes through manual configuration.  An update to the
   RPKI-router protocol [RFC8210] lets relying party software propagate
   the thus created list of allowed ASes for the prefix(es) in question
   so BGP routers can validate the corresponding AS paths.

1.1.  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 RFC 2119 [RFC2119].

2.  Changes to the ROA certificate format

   RFC 3779 [RFC3779] specifies an extension to X.509 certificates that
   contains a set of AS numbers: id-pe-autonomousSysIds.  This is the
   set of valid origin ASes for a given set of IP addresses.

   This memo adds another extension to X.509 certificates with the name
   id-pe-autonomousSysIdsPath.  id-pe-autonomousSysIdsPath is identical
   in syntax to the existing id-pe-autonomousSysIds, allowing for code
   reuse.

   An explicit specification of the id-pe-autonomousSysIdsPath extension
   will be added to a later version of this document.

3.  Changes to the RPKI-router protocol

   This memo updates the RPKI-router protocol [RFC8210] by adding
   version 2 of the RPKI-router protocol.  Version 2 is a superset of
   version 1; all implemenations that support version 2 MUST also
   support version 1.  Version negotiation is performed as specified in



Van Beijnum             Expires December 22, 2019               [Page 2]

Internet-Draft          Path validation with RPKI              June 2019


   RFC 8210 [RFC8210], with the addition that version 2 may now be
   advertised and used if advertised by both sides.

   Version 2 extends the IPv4 Prefix PDU and IPv6 Prefix PDU.  All
   version 1 PDUs (including the IPv4 and IPv6 Prefix PDUs) may also be
   used without changes by version 2, and are transmitted with version
   number 1.

   The format of the version 2 IPv4 Prefix PDU is as follows:

      0          8          16         24        31
      .-------------------------------------------.
      | Protocol |   PDU    |                     |
      | Version  |   Type   |         zero        |
      |    2     |    4     |                     |
      +-------------------------------------------+
      |                                           |
      |                   Length                  |
      |                                           |
      +-------------------------------------------+
      |          |  Prefix  |   Max    |          |
      |  Flags   |  Length  |  Length  |   zero   |
      |          |   0..32  |   0..32  |          |
      +-------------------------------------------+
      |                                           |
      |                IPv4 Prefix                |
      |                                           |
      +-------------------------------------------+
      |                                           |
      |       Autonomous System Number  1         |
      |                                           |
      +-------------------------------------------+
      |                                           |
      |       Autonomous System Number ...        |
      |                                           |
      +-------------------------------------------+
      |                                           |
      |       Autonomous System Number  n         |
      |                                           |
      `-------------------------------------------'

      Version: 2

      Length: the length of the PDU: 16 + 4 * the number of Autonomous
      System Numbers present.






Van Beijnum             Expires December 22, 2019               [Page 3]

Internet-Draft          Path validation with RPKI              June 2019


      Autonomous System Numbers: AS numbers allowed in the BGP AS path.
      See the section "path filter semantics" later in this document.
      At least one Autonomous System Number must be present.

      All other fields are the same as in version 1.

   The format of the version 2 IPv6 Prefix PDU is as follows:

      0          8          16         24        31
      .-------------------------------------------.
      | Protocol |   PDU    |                     |
      | Version  |   Type   |         zero        |
      |    2     |    6     |                     |
      +-------------------------------------------+
      |                                           |
      |                   Length                  |
      |                                           |
      +-------------------------------------------+
      |          |  Prefix  |   Max    |          |
      |  Flags   |  Length  |  Length  |   zero   |
      |          |  0..128  |  0..128  |          |
      +-------------------------------------------+
      |                                           |
      +---                                     ---+
      |                                           |
      +---            IPv6 Prefix              ---+
      |                                           |
      +---                                     ---+
      |                                           |
      +-------------------------------------------+
      |                                           |
      |       Autonomous System Number  1         |
      |                                           |
      +-------------------------------------------+
      |                                           |
      |       Autonomous System Number ...        |
      |                                           |
      +-------------------------------------------+
      |                                           |
      |       Autonomous System Number  n         |
      |                                           |
      `-------------------------------------------'

      Version: 2

      Length: the length of the PDU: 28 + 4 * the number of Autonomous
      System Numbers present.




Van Beijnum             Expires December 22, 2019               [Page 4]

Internet-Draft          Path validation with RPKI              June 2019


      Autonomous System Numbers: AS numbers allowed in the BGP AS path.
      See the section "path filter semantics" later in this document.
      At least one Autonomous System Number must be present.

      All other fields are the same as in version 1.

   For the purposes of determining uniqueness of IPvX PDUs, only the
   fields {Prefix, Len, Max-Len, ASN} are considered, as per RFC 8210
   [RFC8210], where ASN is the first Autonomous System Number in a
   version 2 IPvX PDU.

   So for a given {Prefix, Len, Max-Len, ASN} either a version 1 IPvX
   PDU or a version 2 IPvX PDU may be transmitted, but not both.  The
   relying party software generates a version 2 IPvX PDU when an id-pe-
   autonomousSysIdsPath with one or more ASes is present in a ROA and
   generates a version 1 IPvX PDU otherwise.

4.  Path filter semantics

   The order in which allowed ASes appear in a ROA is relevant.  This
   order, and the order of the locally allowed ASes, is retained in the
   list of ASes sent to routers using the RPKI-router protocol version
   2.  A BGP AS path validates when all unique AS numbers in the path
   are present in the filter in the same order, ignoring AS numbers
   present in the filter that are missing from the BGP AS path.

   If an AS path contains an AS_SET with more than one AS number in it
   and the implementation doesn't perform AS_SET sorting specified as an
   option in the BGP protocol specification [RFC4271] appendix F.4.,
   then filtering behavior is undefined.

   Example: the ROA for 192.0.2.0/24 lists the ASes 200 100.  The local
   relying party software is configured to allow the transit AS 800 and
   the local AS 900.  (The local AS normally doesn't appear in AS paths
   but may be prepended and SHOULD therefore be listed in the filter.)
   This results in the following sequence of Autonomous System Numbers
   in the RPKI-router protocol IPv4 Prefix PDU:

   100 200 800 900

   Conceptually, this results in the following regular expression BGP AS
   path filter:

   ^(900_)*(800_)*(200_)*(100_)+$

   However, filtering can be performed more efficiently as shown in the
   example code in the appendix.




Van Beijnum             Expires December 22, 2019               [Page 5]

Internet-Draft          Path validation with RPKI              June 2019


5.  Internet exchange route servers

   Many networks interconnect through internet exchanges.  In many
   cases, rather than maintain a direct BGP neighbor relationship
   between the routers in both ASes, networks connected through an
   internet exchange interconnect through one or more route servers
   operated by the internet exchange.

   As there are many internet exchanges throughout the world and
   connectivity is subject to change, it would be difficult to add all
   possible route servers ASes to ROAs.  However, in practice this many
   not be an issue as many route servers don't include their own AS in
   the AS path.

6.  IANA Considerations

   This memo includes no request to IANA.

7.  Security considerations

   When two organizations that communicate over the internet both fully
   implement this specification, they have the ability to make sure to
   avoid paths containing ASes that neither of them has authorized to
   carry their their communication, as long as the BGP AS path attribute
   is an accurate reflection of the actual communication path.

   In the absence of BGPsec [RFC8205], an AS that doesn't appear on the
   filter list may forge an AS path in order to reroute traffic through
   it.  However, that AS must then transmit BGP updates with an AS path
   that doesn't match its own AS as configured by its neighbor.  Some
   implementations check if the neighbor AS and the left most AS in AS
   paths are the same, as per the MAY in RFC 4271 [RFC4271] section 6.3.
   So these implementations would reject the forged AS path.

   Another way to accomplish the same result of a valid looking BGP AS
   path but an invalid communication path would be for a malicious
   network to connect to other networks by presenting a falsified AS
   number when setting up a BGP session.  It is unclear to what degree
   networks make sure the AS numbers that new customers or peers claim
   to hold are legitimate.

8.  References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.




Van Beijnum             Expires December 22, 2019               [Page 6]

Internet-Draft          Path validation with RPKI              June 2019


   [RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
              Addresses and AS Identifiers", RFC 3779,
              DOI 10.17487/RFC3779, June 2004,
              <https://www.rfc-editor.org/info/rfc3779>.

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

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
              February 2012, <https://www.rfc-editor.org/info/rfc6480>.

   [RFC7908]  Sriram, K., Montgomery, D., McPherson, D., Osterweil, E.,
              and B. Dickson, "Problem Definition and Classification of
              BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June
              2016, <https://www.rfc-editor.org/info/rfc7908>.

   [RFC8205]  Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
              Specification", RFC 8205, DOI 10.17487/RFC8205, September
              2017, <https://www.rfc-editor.org/info/rfc8205>.

   [RFC8210]  Bush, R. and R. Austein, "The Resource Public Key
              Infrastructure (RPKI) to Router Protocol, Version 1",
              RFC 8210, DOI 10.17487/RFC8210, September 2017,
              <https://www.rfc-editor.org/info/rfc8210>.

Appendix A.  Appendix: filter code example

   #include <stdio.h>

   struct pfxpdu
     {
       unsigned int version;
       unsigned int type;
       unsigned int length;
       unsigned int *path_filter;
     };

   unsigned int path_filter[] = { 100, 200, 800, 900, 0 };
   unsigned int as_path[]     = { 900, 900, 800, 300, 200, 100, 0 };

   char *filter_as_path(struct pfxpdu *pfxpdu, unsigned int *as_path,
     int as_path_length)
   {
     unsigned int path_filter_length = (pfxpdu->length - 16) / 4;
     int path_filter_index;



Van Beijnum             Expires December 22, 2019               [Page 7]

Internet-Draft          Path validation with RPKI              June 2019


     int as_path_index;

     // if the path filter is empty we return status unknown
     if (path_filter_length < 1)
       return("unknown");

     // check the origin AS as per version 1 of the protocol
     if (as_path[as_path_length - 1] != pfxpdu->path_filter[0])
       return("invalid");

     // if the pfxpdu version == 2 then we check the entire path
     if (pfxpdu->version == 2)
       {
         path_filter_index = 0;
         for (as_path_index = as_path_length - 1; as_path_index >= 0;
           as_path_index--)
           {
             while (path_filter_index < path_filter_length &&
               as_path[as_path_index] !=
                 pfxpdu->path_filter[path_filter_index])
               path_filter_index++;
             if (path_filter_index >= path_filter_length)
               return("invalid");
           }
       }
     return("valid");
   }

   unsigned int count_length(unsigned int *asns)
   {
     unsigned int length = 0;

     while (asns[length] != 0)
       length++;
     return length;
   }

   int main()
   {
     int i;
     int as_path_length;
     struct pfxpdu pfxpdu;

     as_path_length = count_length(as_path);

     pfxpdu.version = 2;
     pfxpdu.type = 4;
     pfxpdu.length = 16 + 4 * count_length(path_filter);



Van Beijnum             Expires December 22, 2019               [Page 8]

Internet-Draft          Path validation with RPKI              June 2019


     pfxpdu.path_filter = path_filter;

     printf("Filter regexp: ^");
     for (i = (pfxpdu.length - 16) / 4 - 1; i > 0; i--)
       printf("(%d_)*", pfxpdu.path_filter[i]);
     printf("(%d_)+$\n", pfxpdu.path_filter[0]);

     printf("AS path:");
     for (i = 0; i < as_path_length; i++)
       printf(" %d", as_path[i]);
     printf("\n");

     printf("RPKI status: %s\n", filter_as_path(&pfxpdu, as_path,
       as_path_length));
   }

Author's Address

   Iljitsch van Beijnum
   BGPexpert.com

   Email: iljitsch@muada.com





























van Beijnum             Expires December 22, 2019               [Page 9]