RFC 8205
BGPsec Protocol Specification
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 SpecificationAbstract
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.
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
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).
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.
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.
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".)
+---------------------------------------------------------+ | +-----------------+ | | | 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
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
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].
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.
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)
