An Overview of BGPSEC
draft-ietf-sidr-bgpsec-overview-03

Network Working Group                                       M. Lepinski
Internet Draft                                         BBN Technologies
Intended status: Informational                                S. Turner
Expires: January 15, 2014                                          IECA
                                                          July 15, 2013
                                    
                                      
                           An Overview of BGPSEC 
                  draft-ietf-sidr-bgpsec-overview-03.txt 

Abstract 

   This document provides an overview of a security extension to the 
   Border Gateway Protocol (BGP) referred to as BGPSEC.  BGPSEC improves 
   security for BGP routing. 

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), its areas, and its working groups.  Note that 
   other groups may also distribute working documents as Internet-
   Drafts. 

   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." 

   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt 

   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html 

   This Internet-Draft will expire on November 8, 2012. 

Copyright Notice 

   Copyright (c) 2012 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 
 
 
 
Lepinski and Turner      Expires January 2013                  [Page 1] 


Internet-Draft             BGPSEC Overview                    July 2013 
 
   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. Background.....................................................3 
   3. BGPSEC Operation...............................................4 
      3.1. Negotiation of BGPSEC.....................................4 
      3.2. Update signing and validation.............................5 
   4. Design and Deployment Considerations...........................6 
      4.1. Disclosure of topology information........................7 
      4.2. BGPSEC router assumptions.................................7 
      4.3. BGPSEC and consistency of externally visible data.........8 
   5. Security Considerations........................................8 
   6. IANA Considerations............................................8 
   7. References.....................................................9 
      7.1. Normative References......................................9 
      7.2. Informative References....................................9 
    
1. Introduction 

   BGPSEC (Border Gateway Protocol Security) is an extension to the 
   Border Gateway Protocol (BGP) that provides improved security for BGP 
   routing [RFC 4271].  

   A comprehensive discussion of BGPSEC is provided in the following set 
   of documents: 

     .  [I-D.sidr-bgpsec-threats]:  

        A threat model describing the security context in which BGPSEC 
        is intended to operate. 

     .  [I-D.sidr-bgpsec-protocol]: 

        A standards track document specifying the BGPSEC extension to 
        BGP. 

     .  [I-D.sidr-bgpsec-ops]: 

        An informational document describing operational considerations 
        for BGPSEC deployment. 
 
 
Lepinski and Turner      Expires January 2013                  [Page 2] 


Internet-Draft             BGPSEC Overview                    July 2013 
 
     .  [I-D.turner-sidr-bgpsec-pki-profiles] 

        A standards track document specifying a profile for X.509 
        certificates that bind keys used in BGPSEC to Autonomous System 
        numbers, as well as associated Certificate Revocation Lists 
        (CRLs), and certificate requests. 

     .  [I-D.turner-sidr-bgpsec-algs] 

        A standards track document specifying suites of signature and 
        digest algorithms for use in BGPSEC. 

     .  [I-D.sriram-bgpsec-design-choices] 

        An informational document describing the choices that were made 
        by the author team prior to the publication of the -00 version 
        of draft-ietf-sidr-bgpsec-protocol. Discussion of design choices 
        made since the publication of the -00 can be found in the 
        archives of the SIDR working group mailing list. 

   The remainder of this document contains a brief overview of BGPSEC 
   and its envisioned usage.  

2. Background  

   The motivation for developing BGPSEC is that BGP does not include 
   mechanisms that allow an Autonomous System (AS) to verify the 
   legitimacy and authenticity of BGP route advertisements (see for 
   example, [RFC 4272]).  

   The Resource Public Key Infrastructure (RPKI), described in 
   [RFC6480], provides a first step towards addressing the validation of 
   BGP routing data. RPKI resource certificates are issued to the 
   holders of AS number and IP address resources, providing a binding 
   between these resources and cryptographic keys that can be used to 
   verify digital signatures. Additionally, the RPKI architecture 
   specifies a digitally signed object, a Route Origination 
   Authorization (ROA), that allows holders of IP address resources to 
   authorize specific ASes to originate routes (in BGP) to these 
   resources. Data extracted from valid ROAs can be used by BGP speakers 
   to determine whether a received route was originated by an AS 
   authorized to originate that route (see [RFC6483] and [I-D.sidr-
   origin-ops]). 

   By instituting a local policy that prefers routes with origins 
   validated using RPKI data (versus routes to the same prefix that 
   cannot be so validated) an AS can protect itself from certain mis-
   origination attacks. For example, if a BGP speaker accidently (due to 
 
 
Lepinski and Turner      Expires January 2013                  [Page 3] 


Internet-Draft             BGPSEC Overview                    July 2013 
 
   misconfiguration) originates routes to the wrong prefixes, ASes 
   utilizing RPKI data could detect this error and decline to select 
   these mis-originated routes. However, use of RPKI data alone provides 
   little or no protection against a sophisticated attacker. Such an 
   attacker could, for example, conduct a route hijacking attack by 
   appending an authorized origin AS to an otherwise illegitimate AS 
   Path. (See [I-D.sidr-bgpsec-threats] for a detailed discussion of the 
   BGPSEC threat model.) 

   BGPSEC extends the RPKI by adding an additional type of certificate, 
   referred to as a BGPSEC router certificate, that binds an AS number 
   to a public signature verification key, the corresponding private key 
   of which is held by one or more BGP speakers within this AS. Private 
   keys corresponding to public keys in such certificates can then be 
   used within BGPSEC to enable BGP speakers to sign on behalf of their 
   AS. The certificates thus allow a relying party to verify that a 
   BGPSEC signature was produced by a BGP speaker belonging to a given 
   AS. The goal of BGPSEC is to use signatures to protect the AS Path 
   attribute of BGP update messages so that a BGP speaker can assess the 
   validity of the AS Path in update messages that it receives. 

3. BGPSEC Operation 

   The core of BGPSEC is a new optional (non-transitive) attribute, 
   called BGPSEC_Path_Signatures. This attribute consists of a sequence 
   of digital signatures, one for each AS in the AS Path of a BGPSEC 
   update message. (The use of this new attribute is formally specified 
   in [I-D.sidr-bgpsec-protocol].) A new signature is added to this 
   sequence each time an update message leaves an AS. The signature is 
   constructed so that any tampering with the AS path or Network Layer 
   Reachability Information (NLRI) in the BGPSEC update message will 
   result in the recipient being able to detect that the update is 
   invalid.  

3.1. Negotiation of BGPSEC 

   The use of BGPSEC is negotiated using BGP capability advertisements 
   [RFC 5492]. Upon opening a BGP session with a peer, BGP speakers who 
   support (and wish to use) BGPSEC include a newly-defined capability 
   in the OPEN message. 

   The use of BGPSEC is negotiated separately for each address family. 
   This means that a BGP speaker could, for example, elect to use BGPSEC 
   for IPv6, but not for IPv4 (or vice versa). Additionally, the use of 
   BGPSEC is negotiated separately in the send and receive directions. 
   This means that a BGP speaker could, for example, indicate support 
   for sending BGPSEC update messages but require that messages it 

 
 
Lepinski and Turner      Expires January 2013                  [Page 4] 


Internet-Draft             BGPSEC Overview                    July 2013 
 
   receives be traditional (non-BGPSEC) update message. (To see why such 
   a feature might be useful, see Section 4.2.) 

   If the use of BGPSEC is negotiated in a BGP session (in a given 
   direction, for a given address family) then both BGPSEC update 
   messages (ones that contain the BGPSEC_Path_Signature attribute) and 
   traditional BGP update messages (that do not contain this attribute) 
   can be sent within the session. 

   If a BGPSEC-capable BGP speaker finds that its peer does not support 
   receiving BGPSEC update messages, then the BGP speaker must remove 
   existing BGPSEC_Path_Signatures attribute from any update messages it 
   sends to this peer.  

3.2. Update signing and validation 

   When a BGP speaker originates a BGPSEC update message, it creates a 
   BGPSEC_Path_Signatures attribute containing a single signature. The 
   signature protects the Network Layer Reachability Information (NLRI), 
   the AS number of the originating AS, the AS number of the peer AS to 
   whom the update message is being sent, and a few other pieces of data 
   necessary for security guarantees. Note that the NLRI in a BGPSEC 
   update message is restricted to contain only a single prefix.  

   When a BGP speaker receives a BGPSEC update message and wishes to 
   propagate the route advertisement contained in the update to an 
   external peer, it adds a new signature to the BGPSEC_Path_Signatures 
   attribute. This signature protects everything protected by the 
   previous signature, plus the AS number of the new peer to whom the 
   update message is being sent.  

   Each BGP speaker also adds a reference, called a Subject Key 
   Identifier (SKI), to its BGPSEC Router certificate. The SKI is used 
   by a recipient to select the public key (and selected router 
   certificate data) needed for validation. 

   As an example, consider the following case in which an advertisement 
   for 192.0.2/24 is originated by AS 1, which sends the route to AS 2, 
   which sends it to AS 3, which sends it to AS 4. When AS 4 receives a 
   BGPSEC update message for this route, it will contain the following 
   data: 

     .  NLRI : 192.0.2/24 

     .  AS_Path : 3 2 1 

     .  BGPSEC_Path_Signatures Attribute with 3 signatures : 

 
 
Lepinski and Turner      Expires January 2013                  [Page 5] 


Internet-Draft             BGPSEC Overview                    July 2013 
 
          o  Signature from AS 1 protecting 

             192.0.2/24, AS 1 and AS 2 

          o  Signature from AS 2 protecting 

             Everything AS 1's signature protected, and AS 3 

          o  Signature from AS 3 protecting 

             Everything AS 2's signature protected, and AS 4  

   When a BGPSEC update message is received by a BGP speaker, the BGP 
   speaker can validate the message as follows. For each signature, the 
   BGP speaker first needs to determine if there is a valid RPKI Router 
   certificate matching the SKI and containing the appropriate AS 
   number. (This would typically be done by looking up the SKI in a 
   cache of data extracted from valid RPKI objects. A cache allows 
   certificate validation to be handled via an asynchronous process, 
   which might execute on another device.)  

   The BGP speaker then verifies the signature using the public key from 
   this BGPSEC router certificate. If all the signatures can be verified 
   in this fashion, the BGP speaker is assured that the update message 
   it received actually came via the path specified in the AS_Path 
   attribute. Finally, the BGP speaker can check whether there exists a 
   valid ROA in the RPKI linking the origin AS to the prefix in the 
   NLRI. If such a valid ROA exists the BGP speaker is further assured 
   that the AS at the beginning of the validated path was authorized to 
   originate routes to the given prefix. 

   In the above example, upon receiving the BGPSEC update message, a BGP 
   speaker for AS 4 would first check to make sure that there is a valid 
   ROA authorizing AS 1 to originate advertisements for 192.0.2/24. It 
   would then look at the SKI for the first signature and see if this 
   corresponds to a valid BGPSEC Router certificate for AS 1. Next, it 
   would then verify the first signature using the key found in this 
   valid certificate. Finally, it would repeat this process for the 
   second and third signatures, checking to see that there are valid 
   BGPSEC router certificates for AS 2 and AS 3 (respectively) and that 
   the signatures can be verified with the keys found in these 
   certificates.   

4. Design and Deployment Considerations 

   In this section we briefly discuss several additional topics that 
   commonly arise in the discussion of BGPSEC. 

 
 
Lepinski and Turner      Expires January 2013                  [Page 6] 


Internet-Draft             BGPSEC Overview                    July 2013 
 
4.1. Disclosure of topology information 

   A key requirement in the design of BGPSEC was that BGPSEC not 
   disclose any new information about BGP peering topology.  Since many 
   ISPs feel peering topology data is proprietary, further disclosure of 
   it would inhibit BGPSEC adoption.  

   In particular, the topology information that can be inferred from 
   BGPSEC update messages is exactly the same as that which can be 
   inferred from equivalent (non-BGPSEC) BGP update messages.  

4.2. BGPSEC router assumptions 

   In order to achieve its security goals, BGPSEC assumes additional 
   capabilities in routers. In particular, BGPSEC involves adding 
   digital signatures to BGP update messages, which will significantly 
   increase the size of these messages. Therefore, an AS that wishes to 
   receive BGPSEC update messages will require additional memory in its 
   routers to store (e.g., in ADJ RIBs) the data conveyed in these large 
   update messages. Additionally, the design of BGPSEC assumes that an 
   AS that elects to receive BGPSEC update messages will do some 
   cryptographic signature verification at its edge router. This 
   verification will likely require additional capability in these edge 
   routers.  

   Additionally, BGPSEC requires that all BGPSEC speakers will support 
   4-byte AS Numbers [RFC4893]. This is because the co-existence 
   strategy for 4-byte AS numbers and legacy 2-byte AS speakers that 
   gives special meaning to AS 23456 is incompatible with the security 
   the security properties that BGPSEC seeks to provide.  

   For this initial version of BGPSEC, optimizations to minimize the 
   size of BGPSEC updates or the processing required in edge routers 
   have not been considered. Such optimizations may be considered in the 
   future.  

   Note also that the design of BGPSEC allows an AS to send BGPSEC 
   update messages (thus obtaining protection for routes it originates) 
   without receiving BGPSEC update messages. An AS that only sends, and 
   does not receive, BGPSEC update messages will require much less 
   capability in its edge routers to deploy BGPSEC. In particular, a 
   router that only sends BGPSEC update messages does not need 
   additional memory to store large updates and requires only minimal 
   cryptographic capability (as generating one signature per outgoing 
   update requires less computation than verifying multiple signatures 
   on each incoming update message). See [I-D.sidr-bgpsec-ops] for 
   further discussion related to Edge ASes that do not provide transit.) 

 
 
Lepinski and Turner      Expires January 2013                  [Page 7] 


Internet-Draft             BGPSEC Overview                    July 2013 
 
4.3. BGPSEC and consistency of externally visible data 

   Finally note that, by design, BGPSEC prevents parties that propagate 
   route advertisements from including inconsistent or erroneous 
   information within the AS-Path (without detection).  In particular, 
   this means that any deployed scenarios in which a BGP speaker 
   constructs such an inconsistent or erroneous AS Path attribute will 
   break when BGPSEC is used.  

   For example, when BGPSEC is not used, it is possible for a single 
   autonomous system to have one peering session where it identifies 
   itself as AS 111 and a second peering session where it identifies 
   itself as AS 222.  In such a case, it might receive route 
   advertisements from the first peering session (as AS 111) and then 
   add AS 222 (but not AS 111) to the AS-Path and propagate them within 
   the second peering session. 

   Such behavior may very well be innocent and performed with the 
   consent of the legitimate holder of both AS 111 and 222.  However, it 
   is indistinguishable from the following man-in-the-middle attack 
   performed by a malicious AS 222. First, the malicious AS 222 
   impersonates AS 111 in the first peering session (essentially 
   stealing a route advertisement intended for AS 111). The malicious AS 
   222 then inserts itself into the AS path and propagates the update to 
   its peers.   

   Therefore, when BGPSEC is used, such an autonomous system would 
   either need to assert a consistent AS number in all external peering 
   sessions, or else it would need to add both AS 111 and AS 222 to the 
   AS-Path (along with appropriate signatures) for route advertisements 
   that it receives from the first peering session and propagates within 
   the second peering session. 

5. Security Considerations 

   This document provides an overview of BPSEC; it does not define the 
   BGPSEC extension to BGP.  The BGPSEC extension is defined in [I-
   D.sidr-bgpsec-protocol].  The threat model for the BGPSEC is 
   described in [I-D.sidr-bgpsec-threats].   

6. IANA Considerations 

   None. 

 
 
Lepinski and Turner      Expires January 2013                  [Page 8] 


Internet-Draft             BGPSEC Overview                    July 2013 
 
7. References 

7.1. Normative References 

   [RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., "A Border Gateway 
   Protocol 4 (BGP-4)", RFC 4271, January 2006. 

   [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 
   Numbers", RFC 4893, May 2007. 

   [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 
   with BGP-4", RFC 5492, February 2009. 

   [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 
   Secure Internet Routing", February 2012. 

   [RFC6483] Huston, G., and G. Michaelson, "Validation of Route 
   Origination using the Resource Certificate PKI and ROAs", February 
   2012. 

   [I-D.sidr-origin-ops] Bush, R., "RPKI-Based Origin Validation 
   Operation", draft-ietf-sidr-origin-ops, work-in-progress. 

   [I-D.sidr-bgpsec-threats] Kent, S., "Threat Model for BGP Path 
   Security", draft-ietf-sidr-bgpsec-threats, work-in-progress. 

   [I-D.sidr-bgpsec-protocol] Lepinski, M., Ed., "BPSEC Protocol 
   Specification", draft-ietf-sidr-bgpsec-protocol, work-in-progress. 

   [I-D.sidr-bgpsec-ops] Bush, R., "BGPSEC Operational Considerations", 
   draft-ietf-sidr-bgpsec-ops, work-in-progress. 

   [I-D.sidr-bgpsec-algs] Turner, S., "BGP Algorithms, Key Formats, & 
   Signature Formats", draft-ietf-sidr-bgpsec-algs, work-in-progress. 

   [I-D.sidr-bgpsec-pki-profiles] Reynolds, M. and S. Turner, S., "A 
   Profile for BGPSEC Router Certificates, Certificate Revocation Lists, 
   and Certification Requests", draft-sidr-bgpsec-pki-profiles, work-in-
   progress. 

7.2. Informative References 

   [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 
   4272, January 2006 

   [I-D.sriram-bgpsec-design-choices] Sriram, K., "BGPSEC Design Choices 
   and Summary of Supporting Discussions", draft-sriram-bgpsec-design-
   choices, work-in-progress. 
 
 
Lepinski and Turner      Expires January 2013                  [Page 9] 


Internet-Draft             BGPSEC Overview                    July 2013 
 
 

Author's' Addresses

   Matt Lepinski
   BBN Technologies
   10 Moulton Street
   Cambridge MA 02138
    
   Email: mlepinski@bbn.com
   
   Sean Turner
   IECA, Inc.
   3057 Nutley Street, Suite 106
   Fairfax, VA 22031
    
   Email: turners@ieca.com
    

 
 
Lepinski and Turner      Expires January 2013                 [Page 10]