tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 8205

Proposed STD
Pages: 45
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: SIDR

BGPsec Protocol Specification

Part 1 of 3, p. 1 to 11
None       Next Section

Updated by:    8206


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                  M. Lepinski, Ed.
Request for Comments: 8205                                           NCF
Category: Standards Track                                 K. Sriram, Ed.
ISSN: 2070-1721                                                     NIST
                                                          September 2017


                     BGPsec Protocol Specification

Abstract

   This document describes BGPsec, an extension to the Border Gateway
   Protocol (BGP) that provides security for the path of Autonomous
   Systems (ASes) through which a BGP UPDATE message passes.  BGPsec is
   implemented via an optional non-transitive BGP path attribute that
   carries digital signatures produced by each AS that propagates the
   UPDATE message.  The digital signatures provide confidence that every
   AS on the path of ASes listed in the UPDATE message has explicitly
   authorized the advertisement of the route.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8205.

Copyright Notice

   Copyright (c) 2017 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.

Top       Page 2 
Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  BGPsec Negotiation  . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  The BGPsec Capability . . . . . . . . . . . . . . . . . .   4
     2.2.  Negotiating BGPsec Support  . . . . . . . . . . . . . . .   5
   3.  The BGPsec_PATH Attribute . . . . . . . . . . . . . . . . . .   6
     3.1.  Secure_Path . . . . . . . . . . . . . . . . . . . . . . .   8
     3.2.  Signature_Block . . . . . . . . . . . . . . . . . . . . .  10
   4.  BGPsec UPDATE Messages  . . . . . . . . . . . . . . . . . . .  11
     4.1.  General Guidance  . . . . . . . . . . . . . . . . . . . .  11
     4.2.  Constructing the BGPsec_PATH Attribute  . . . . . . . . .  14
     4.3.  Processing Instructions for Confederation Members . . . .  18
     4.4.  Reconstructing the AS_PATH Attribute  . . . . . . . . . .  19
   5.  Processing a Received BGPsec UPDATE Message . . . . . . . . .  21
     5.1.  Overview of BGPsec Validation . . . . . . . . . . . . . .  22
     5.2.  Validation Algorithm  . . . . . . . . . . . . . . . . . .  23
   6.  Algorithms and Extensibility  . . . . . . . . . . . . . . . .  27
     6.1.  Algorithm Suite Considerations  . . . . . . . . . . . . .  27
     6.2.  Considerations for the SKI Size . . . . . . . . . . . . .  28
     6.3.  Extensibility Considerations  . . . . . . . . . . . . . .  28
   7.  Operations and Management Considerations  . . . . . . . . . .  29
     7.1.  Capability Negotiation Failure  . . . . . . . . . . . . .  29
     7.2.  Preventing Misuse of pCount=0 . . . . . . . . . . . . . .  29
     7.3.  Early Termination of Signature Verification . . . . . . .  30
     7.4.  Non-deterministic Signature Algorithms  . . . . . . . . .  30
     7.5.  Private AS Numbers  . . . . . . . . . . . . . . . . . . .  30
     7.6.  Robustness Considerations for Accessing RPKI Data . . . .  32
     7.7.  Graceful Restart  . . . . . . . . . . . . . . . . . . . .  32
     7.8.  Robustness of Secret Random Number in ECDSA . . . . . . .  32
     7.9.  Incremental/Partial Deployment Considerations . . . . . .  33
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  33
     8.1.  Security Guarantees . . . . . . . . . . . . . . . . . . .  33
     8.2.  On the Removal of BGPsec Signatures . . . . . . . . . . .  34
     8.3.  Mitigation of Denial-of-Service Attacks . . . . . . . . .  36
     8.4.  Additional Security Considerations  . . . . . . . . . . .  36
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  38
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  39
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  39
     10.2.  Informative References . . . . . . . . . . . . . . . . .  41
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  43
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  44
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  45

Top      ToC       Page 3 
1.  Introduction

   This document describes BGPsec, a mechanism for providing path
   security for Border Gateway Protocol (BGP) [RFC4271] route
   advertisements.  That is, a BGP speaker who receives a valid BGPsec
   UPDATE message has cryptographic assurance that the advertised route
   has the following property: every Autonomous System (AS) on the path
   of ASes listed in the UPDATE message has explicitly authorized the
   advertisement of the route to the subsequent AS in the path.

   This document specifies an optional (non-transitive) BGP path
   attribute, BGPsec_PATH.  It also describes how a BGPsec-compliant BGP
   speaker (referred to hereafter as a BGPsec speaker) can generate,
   propagate, and validate BGP UPDATE messages containing this attribute
   to obtain the above assurances.

   BGPsec is intended to be used to supplement BGP origin validation
   [RFC6483] [RFC6811], and when used in conjunction with origin
   validation, it is possible to prevent a wide variety of route
   hijacking attacks against BGP.

   BGPsec relies on the Resource Public Key Infrastructure (RPKI)
   certificates that attest to the allocation of AS number and IP
   address resources.  (For more information on the RPKI, see RFC 6480
   [RFC6480] and the documents referenced therein.)  Any BGPsec speaker
   who wishes to send, to external (eBGP) peers, BGP UPDATE messages
   containing the BGPsec_PATH needs to possess a private key associated
   with an RPKI router certificate [RFC8209] that corresponds to the
   BGPsec speaker's AS number.  Note, however, that a BGPsec speaker
   does not need such a certificate in order to validate received UPDATE
   messages containing the BGPsec_PATH attribute (see Section 5.2).

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  BGPsec Negotiation

   This document defines a BGP capability [RFC5492] that allows a BGP
   speaker to advertise to a neighbor the ability to send or to receive
   BGPsec UPDATE messages (i.e., UPDATE messages containing the
   BGPsec_PATH attribute).

Top      ToC       Page 4 
2.1.  The BGPsec Capability

   This capability has capability code 7.

   The capability length for this capability MUST be set to 3.

   The 3 octets of the capability format are specified in Figure 1.

                   0   1   2   3      4      5   6   7
                 +---------------------------------------+
                 | Version          | Dir |  Unassigned  |
                 +---------------------------------------+
                 |                                       |
                 +------           AFI              -----+
                 |                                       |
                 +---------------------------------------+

                    Figure 1: BGPsec Capability Format

   The first 4 bits of the first octet indicate the version of BGPsec
   for which the BGP speaker is advertising support.  This document
   defines only BGPsec version 0 (all 4 bits set to 0).  Other versions
   of BGPsec may be defined in future documents.  A BGPsec speaker MAY
   advertise support for multiple versions of BGPsec by including
   multiple versions of the BGPsec capability in its BGP OPEN message.

   The fifth bit of the first octet is a Direction bit, which indicates
   whether the BGP speaker is advertising the capability to send BGPsec
   UPDATE messages or receive BGPsec UPDATE messages.  The BGP speaker
   sets this bit to 0 to indicate the capability to receive BGPsec
   UPDATE messages.  The BGP speaker sets this bit to 1 to indicate the
   capability to send BGPsec UPDATE messages.

   The remaining 3 bits of the first octet are unassigned and for future
   use.  These bits are set to 0 by the sender of the capability and
   ignored by the receiver of the capability.

   The second and third octets contain the 16-bit Address Family
   Identifier (AFI), which indicates the address family for which the
   BGPsec speaker is advertising support for BGPsec.  This document only
   specifies BGPsec for use with two address families, IPv4 and IPv6,
   with AFI values 1 and 2, respectively [IANA-AF].  BGPsec for use with
   other address families may be specified in future documents.

Top      ToC       Page 5 
2.2.  Negotiating BGPsec Support

   In order to indicate that a BGP speaker is willing to send BGPsec
   UPDATE messages (for a particular address family), a BGP speaker
   sends the BGPsec capability (see Section 2.1) with the Direction bit
   (the fifth bit of the first octet) set to 1.  In order to indicate
   that the speaker is willing to receive BGP UPDATE messages containing
   the BGPsec_PATH attribute (for a particular address family), a BGP
   speaker sends the BGPsec capability with the Direction bit set to 0.
   In order to advertise the capability to both send and receive BGPsec
   UPDATE messages, the BGP speaker sends two copies of the BGPsec
   capability (one with the Direction bit set to 0 and one with the
   Direction bit set to 1).

   Similarly, if a BGP speaker wishes to use BGPsec with two different
   address families (i.e., IPv4 and IPv6) over the same BGP session,
   then the speaker includes two instances of this capability (one for
   each address family) in the BGP OPEN message.  A BGP speaker MUST NOT
   announce BGPsec capability if it does not support the BGP
   multiprotocol extension [RFC4760].  Additionally, a BGP speaker
   MUST NOT advertise the capability of BGPsec support for a particular
   AFI unless it has also advertised the multiprotocol extension
   capability for the same AFI [RFC4760].

   In a BGPsec peering session, a peer is permitted to send UPDATE
   messages containing the BGPsec_PATH attribute if and only if:

   o  The given peer sent the BGPsec capability for a particular version
      of BGPsec and a particular address family with the Direction bit
      set to 1, and

   o  The other (receiving) peer sent the BGPsec capability for the same
      version of BGPsec and the same address family with the Direction
      bit set to 0.

   In such a session, it can be said that the use of the particular
   version of BGPsec has been negotiated for a particular address
   family.  Traditional BGP UPDATE messages (i.e., unsigned, containing
   the AS_PATH attribute) MAY be sent within a session regardless of
   whether or not the use of BGPsec is successfully negotiated.
   However, if BGPsec is not successfully negotiated, then BGP UPDATE
   messages containing the BGPsec_PATH attribute MUST NOT be sent.

   This document defines the behavior of implementations in the case
   where BGPsec version 0 is the only version that has been successfully
   negotiated.  Any future document that specifies additional versions
   of BGPsec will need to specify behavior in the case that support for
   multiple versions is negotiated.

Top      ToC       Page 6 
   BGPsec cannot provide meaningful security guarantees without support
   for 4-byte AS numbers.  Therefore, any BGP speaker that announces the
   BGPsec capability, MUST also announce the capability for 4-byte AS
   support [RFC6793].  If a BGP speaker sends the BGPsec capability but
   not the 4-byte AS support capability, then BGPsec has not been
   successfully negotiated, and UPDATE messages containing the
   BGPsec_PATH attribute MUST NOT be sent within such a session.

3.  The BGPsec_PATH Attribute

   The BGPsec_PATH attribute is an optional non-transitive BGP path
   attribute.

   This document registers an attribute type code for this attribute:
   BGPsec_PATH (see Section 9).

   The BGPsec_PATH attribute carries the secured information regarding
   the path of ASes through which an UPDATE message passes.  This
   includes the digital signatures used to protect the path information.
   The UPDATE messages that contain the BGPsec_PATH attribute are
   referred to as "BGPsec UPDATE messages".  The BGPsec_PATH attribute
   replaces the AS_PATH attribute in a BGPsec UPDATE message.  That is,
   UPDATE messages that contain the BGPsec_PATH attribute MUST NOT
   contain the AS_PATH attribute, and vice versa.

   The BGPsec_PATH attribute is made up of several parts.  The
   high-level diagram in Figure 2 provides an overview of the structure
   of the BGPsec_PATH attribute.  ("SKI" as used in Figure 2 means
   "Subject Key Identifier".)

Top      ToC       Page 7 
        +---------------------------------------------------------+
        |     +-----------------+                                 |
        |     |   Secure_Path   |                                 |
        |     +-----------------+                                 |
        |     |    pCount X     |                                 |
        |     |    Flags X      |                                 |
        |     |    AS X         |                                 |
        |     |    pCount Y     |                                 |
        |     |    Flags Y      |                                 |
        |     |    AS Y         |                                 |
        |     |      ...        |                                 |
        |     +-----------------+                                 |
        |                                                         |
        |   +---------------------+     +---------------------+   |
        |   |  Signature_Block 1  |     |  Signature_Block 2  |   |
        |   +---------------------+     +---------------------+   |
        |   |  Algorithm Suite 1  |     |  Algorithm Suite 2  |   |
        |   |  SKI X1             |     |  SKI X2             |   |
        |   |  Signature X1       |     |  Signature X2       |   |
        |   |  SKI Y1             |     |  SKI Y2             |   |
        |   |  Signature Y1       |     |  Signature Y2       |   |
        |   |       ...           |     |       ....          |   |
        |   +---------------------+     +---------------------+   |
        |                                                         |
        +---------------------------------------------------------+

         Figure 2: High-Level Diagram of the BGPsec_PATH Attribute

   Figure 3 provides the specification of the format for the BGPsec_PATH
   attribute.

         +-------------------------------------------------------+
         | Secure_Path                             (variable)    |
         +-------------------------------------------------------+
         | Sequence of one or two Signature_Blocks (variable)    |
         +-------------------------------------------------------+

                  Figure 3: BGPsec_PATH Attribute Format

   The Secure_Path contains AS path information for the BGPsec UPDATE
   message.  This is logically equivalent to the information that is
   contained in a non-BGPsec AS_PATH attribute.  The information in the
   Secure_Path is used by BGPsec speakers in the same way that
   information from the AS_PATH is used by non-BGPsec speakers.  The
   format of the Secure_Path is described below in Section 3.1.

   The BGPsec_PATH attribute will contain one or two Signature_Blocks,
   each of which corresponds to a different algorithm suite.  Each of

Top      ToC       Page 8 
   the Signature_Blocks will contain a Signature Segment for each AS
   number (i.e., Secure_Path Segment) in the Secure_Path.  In the
   most common case, the BGPsec_PATH attribute will contain only a
   single Signature_Block.  However, in order to enable a transition
   from an old algorithm suite to a new algorithm suite (without a
   flag day), it will be necessary to include two Signature_Blocks (one
   for the old algorithm suite and one for the new algorithm suite)
   during the transition period.  (See Section 6.1 for more discussion
   of algorithm transitions.)  The format of the Signature_Blocks is
   described below in Section 3.2.

3.1.  Secure_Path

   A detailed description of the Secure_Path information in the
   BGPsec_PATH attribute is provided here.  The specification for the
   Secure_Path field is provided in Figures 4 and 5.

             +-----------------------------------------------+
             | Secure_Path Length                 (2 octets) |
             +-----------------------------------------------+
             | One or more Secure_Path Segments   (variable) |
             +-----------------------------------------------+

                       Figure 4: Secure_Path Format

   The Secure_Path Length contains the length (in octets) of the entire
   Secure_Path (including the 2 octets used to express this length
   field).  As explained below, each Secure_Path Segment is 6 octets
   long.  Note that this means the Secure_Path Length is two greater
   than six times the number of Secure_Path Segments (i.e., the number
   of AS numbers in the path).

   The Secure_Path contains one Secure_Path Segment (see Figure 5) for
   each AS in the path to the originating AS of the prefix specified in
   the UPDATE message.  (Note: Repeated ASes are "compressed out" using
   the pCount field, as discussed below.)

     +------------------------------------------------------+
     | pCount         (1 octet)                             |
     +------------------------------------------------------+
     | Confed_Segment flag (1 bit) |  Unassigned (7 bits)   | (Flags)
     +------------------------------------------------------+
     | AS Number      (4 octets)                            |
     +------------------------------------------------------+

                   Figure 5: Secure_Path Segment Format

Top      ToC       Page 9 
   The AS Number (in Figure 5) is the AS number of the BGP speaker that
   added this Secure_Path Segment to the BGPsec_PATH attribute.  (See
   Section 4 for more information on populating this field.)

   The pCount field contains the number of repetitions of the associated
   AS number that the signature covers.  This field enables a BGPsec
   speaker to mimic the semantics of prepending multiple copies of their
   AS to the AS_PATH without requiring the speaker to generate multiple
   signatures.  Note that Section 9.1.2.2 ("Breaking Ties (Phase 2)") in
   [RFC4271] mentions the "number of AS numbers" in the AS_PATH
   attribute that is used in the route selection process.  This metric
   (number of AS numbers) is the same as the AS path length obtained in
   BGPsec by summing the pCount values in the BGPsec_PATH attribute.
   The pCount field is also useful in managing route servers (see
   Section 4.2), AS confederations (see Section 4.3), and AS Number
   migrations (see [RFC8206] for details).

   The leftmost (i.e., the most significant) bit of the Flags field in
   Figure 5 is the Confed_Segment flag.  The Confed_Segment flag is set
   to 1 to indicate that the BGPsec speaker that constructed this
   Secure_Path Segment is sending the UPDATE message to a peer AS within
   the same AS confederation [RFC5065].  (That is, a sequence of
   consecutive Confed_Segment flags are set in a BGPsec UPDATE message
   whenever, in a non-BGPsec UPDATE message, an AS_PATH segment of type
   AS_CONFED_SEQUENCE occurs.)  In all other cases, the Confed_Segment
   flag is set to 0.

   The remaining 7 bits of the Flags field are unassigned.  They MUST be
   set to 0 by the sender and ignored by the receiver.  Note, however,
   that the signature is computed over all 8 bits of the Flags field.

   As stated earlier in Section 2.2, BGPsec peering requires that the
   peering ASes MUST each support 4-byte AS numbers.  Currently assigned
   2-byte AS numbers are converted into 4-byte AS numbers by setting the
   two high-order octets of the 4-octet field to 0 [RFC6793].

Top      ToC       Page 10 
3.2.  Signature_Block

   A detailed description of the Signature_Blocks in the BGPsec_PATH
   attribute is provided here using Figures 6 and 7.

              +---------------------------------------------+
              | Signature_Block Length         (2 octets)   |
              +---------------------------------------------+
              | Algorithm Suite Identifier     (1 octet)    |
              +---------------------------------------------+
              | Sequence of Signature Segments (variable)   |
              +---------------------------------------------+

                     Figure 6: Signature_Block Format

   The Signature_Block Length in Figure 6 is the total number of octets
   in the Signature_Block (including the 2 octets used to express this
   length field).

   The Algorithm Suite Identifier is a 1-octet identifier specifying the
   digest algorithm and digital signature algorithm used to produce the
   digital signature in each Signature Segment.  An IANA registry of
   algorithm suite identifiers for use in BGPsec is specified in the
   BGPsec algorithms document [RFC8208].

   A Signature_Block in Figure 6 has exactly one Signature Segment (see
   Figure 7) for each Secure_Path Segment in the Secure_Path portion of
   the BGPsec_PATH attribute (that is, one Signature Segment for each
   distinct AS on the path for the prefix in the UPDATE message).

              +---------------------------------------------+
              | Subject Key Identifier (SKI)  (20 octets)   |
              +---------------------------------------------+
              | Signature Length              (2 octets)    |
              +---------------------------------------------+
              | Signature                     (variable)    |
              +---------------------------------------------+

                    Figure 7: Signature Segment Format

   The Subject Key Identifier (SKI) field in Figure 7 contains the value
   in the Subject Key Identifier extension of the RPKI router
   certificate [RFC6487] that is used to verify the signature (see
   Section 5 for details on the validity of BGPsec UPDATE messages).
   The SKI field has a fixed size of 20 octets.  See Section 6.2 for
   considerations for the SKI size.

Top      ToC       Page 11 
   The Signature Length field contains the size (in octets) of the value
   in the Signature field of the Signature Segment.

   The Signature field in Figure 7 contains a digital signature that
   protects the prefix and the BGPsec_PATH attribute (see Sections 4 and
   5 for details on signature generation and validation, respectively).



(page 11 continued on part 2)

Next Section