]> HPE

jeffrey.haas@hpe.com

OpenSSL

beck@obtuse.com

Futurewei Technologies

yingzhen.ietf@gmail.com

AREA Network Working Group BGP TLS transport layer security PKI The Border Gateway Protocol, Version 4 (BGP-4) (RFC 4271) uses TCP (RFC 9293) as its transport layer protocol. There are proposals to run BGP over TLS-based transport protocols, including QUIC. This document discusses authentication considerations for running BGP over TLS protocols and defines a PKI framework to provide for authenticating BGP peering sessions.

Introduction The Border Gateway Protocol, Version 4 (BGP-4) uses TCP as its transport layer protocol. TCP provides a sequenced, reliable byte stream for BGP to deliver its PDUs for a BGP session. BGP is provides its own framing layer. TCP provides no security mechanisms, including authentication, data integrity, or privacy, for its users. (See for definitions of these properties.) Attacks against BGP running over TCP lead to the development of TCP-MD5 and later the TCP Authentication Option (TCP-AO) . These mechanisms protect against disrupting the TCP stream. In particular, it provides for data integrity of the TCP stream and also provides a form of authentication via using shared secrets needed to implement these mechanisms. discusses how TCP-AO is not intended to replace the use of IPsec or TLS . There are proposals to run BGP over alternative transport protocols, including QUIC . QUIC leverages TLS version 1.3 , which provides for authentication and also privacy. Data integrity is also a property of TLS, however when TLS is carried over TCP, it does not provide protection of the TCP stream. TLS makes use of certificates as part of its authentication infrastructure. This document defines a public key infrastructure (PKI) profile for authenticating BGP peering sessions when carried over TLS transport.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here. AS: Autonomous System. ASN: Autonomous System Number. CA: Certificate Authority. RPKI: Resource Public Key Infrastructure.

A History of Securing BGP Transport Sessions Modernly, BGP-4 doesn't provide for authentication of its sessions within the protocol. An earlier version of BGP-4 defined in attempted to define an authentication mechanism, however it was problematic and not deployed. BGP's security issues using TCP were noted in and later as part of . By that time, the use of TCP-MD5 - even with its deficiencies - were part of best current operational practice. Securing BGP using IPsec has been offered as an option, as was typical of IETF routing protocols carried over TCP. However, the general deployment of routing protocols using IPsec has been problematic for various reasons. While many implementations offer IPsec as an authentication option, it is not commonly deployed. Mechanisms such as TCP-MD5, TCP-AO, and IPsec provide for authenticating a BGP session through the use of shared secrets. These are used to provision their mechanisms for a given BGP peering session and are tied to a pair of IP addresses for the session.

Why Authenticate BGP Pair-wise authentication of BGP session endpoints provide assurance that each side of the BGP session is the expected party. However, this authentication only provides assurance that each side has provided the necessary credential for the mechanism and that it is associated with the BGP speaker's IP address. Validating that each party supplying this information is a trusted party requires additional scrutiny. Nothing in the BGP protocol or IP address assignment for a BGP speaker attests to whether that party is legitimate or not. For example, a fraudulent party claiming to be the trusted party could be supplying the credentials to secure the session. This permits the fradulent party to participate in BGP routing in the same role as the trusted party for devious reasons. A trusted channel for distributing these security credentials is thus needed.

Using TLS Certificates for BGP TLS 1.3 is leveraged by many protocols to provide for authentication, data integrity, and privacy. It leverages PKI certificates to validate the TLS session. Some of the details for validating certificates are left to applications using those certificates. The web PKI is inappropriate for validating TLS sessions protecting BGP. Many resources addressed by web PKI certificates are particular to websites and a certificate validation model where a large number of trust anchors are distributed to web browsers and other HTTPS clients for validation of TLS sessions. The resources appropriate for validation in the BGP protocol include the Autonomous System (AS) number for the peering session, and the IP address for the peering session.

Authenticating BGP Using TLS Certificates Authenticating BGP peering sessions needs only to be done in a pair-wise fashion between two BGP speakers. Authentication of BGP sessions using this profile rely upon end entity certificates carried in TLS that contain the following fields: One or more "ASIdentifer" fields for that BGP speaker's local AS numbers. Optionally, one or more "IPAddress" fields for that BGP speaker's local IP address endpoints for the BGP session.

High Level Validation Procedure The local BGP speaker receiving the end entity certificate from the remote BGP speaker validates the TLS certificate; details of this validation are described in subsequent sections. If the certificate has been successfully validated, the received ASIdentifier is checked against the expected remote AS for the BGP session. If the ASIdentifier successfully validates, and an IPAddress field is present, the IPAddress prefix is validated against the remote peer's expected IP endpoints. If all of these procedures have succeded, the peer has been authenticated and the BGP protocol may use this TLS session. Otherwise, the session should be closed.

AS-level Trust Anchors Since BGP sessions are pair-wise, in principle the peering session could be provisioned with the local end entity certificate and the expected remote end entity certificate. This is somewhat similar to provisioning per-session shared secrets for other mechanisms. In the absence of additional validation, it also is no better from a trust perspective: How did you get this end certificate in the first place and why do you trust it? Consider the case where the end entity certificates are issued by a certificate authority that is operating at the BGP AS level. If all end entity certificates protecting BGP peering sessions are issued by their AS-level CA, and the AS's CA certificate is used as the trust anchor for the session, then all that is required to be installed on a BGP speaker is the remote peer's AS-level CA certificate. Unlike per-session end entity certificates, the AS-level CA certificate may be made available through channels where validation of authenticity of the certificate is easier. This permits service providers to have a higher degree of confidence that the end entity certificate supplied during the TLS handshake has been issued by the service provider.

Trusted Third Party Trust Anchors An option that may appeal to some service providers to validate AS-level certificates is to permit a trusted third party to be a mutual parent in the validation hierarchy. One such example might include the Regional Internet Registries (RIRs) that are already issuing AS numbers to service providers for BGP use. While RIRs appear at first glance to be a natural fit for such mutual trusted third parties, any party that has the trust of two parties participating in validation can serve this purpose. The core proposition to this model is that the third party is trusted. Such a party can issue certificates that would permit validation to proceed in a pair-wise fashion for a service provider using this trust relationship.

Issuing End Entity Certificates In models where an AS-level CA exists, end entity certificates protecting BGP peering sessions are created on an as-needed basis and provisioned onto the protected systems. This may be "push" model where a centralized provisioning system creates and distributes the end entity certificates and associated BGP peering configuration for each BGP speaker. Another possible model is a "pull" model where sufficient trust exists between the requesting BGP speaker and the AS-level certificate infrastructure. Such a model has some resemblance to the use cases enabled by the ACME protocol .

BGP TLS Certificate Profile

Introduction This document defines a profile for X.509 Public Key Certificates intended for use in identifying BGP autonomous systems (ASes) by their registered Autonomous System Number (ASN) for purposes of TLS authentication. This profile specifies the use of a new Subject Alternative Name (SAN) extension type to carry the ASN, facilitating the verification of the certificate holder's identity as a legitimate holder of the AS and supporting cryptographic authentication in routing and network security protocols. It defines a new Other Name for inclusion in the X.509 Subject Alternate Name (SAN) to carry an AS number. The intention of this document is to define a certificate profile for use in a TLS handshake for transport connections used by protocols to exchange routing information. X.509 certificates are a foundational element of public key infrastructure (PKI), providing cryptographic binding between a public key and an identity. In the context of network routing and infrastructure security, such as RPKI (Resource Public Key Infrastructure) or future secure routing mechanisms, it is essential to cryptographically bind a public key to an AS's unique identifier—the Autonomous System Number (ASN). This profile specifies the minimal requirements and constraints for X.509 certificates used to identify an AS solely by its ASN. It leverages existing X.509 standards, primarily , and defines a specific approach for ASN inclusion in the Subject Alternative Name extension. Unlike the Autonomous System identifier delegation extension from , this profile is not intended to reflect the association of routing ip addresses to AS numbers for purposes of validating routing decisions. This profile is intended for use cases in which an endpoint is to be identified as a specific ASN endpoint of a TLS connection, for securing routing control connections, such as BGP. This profile is intended to provide a mechanism whereby an AS can reliably generate short lived end entity certificates to reliably identify TLS connection endpoints. TLS can be used with fixed certificates or pre-shared keys, and may be very appropriate to use in that model for certain uses in this space where the two relying parties at each end of a connection have decided to trust each other by some out of band mechanism. The focus of this draft is to establish a certificate profile for a PKI that enables the ability to establish trust via either a mutually operated, or third party CA in a reliable manner, with short lived end-entity certificates provisioned automatically from an intermediate certificate dedicated to this purpose for an ASN.

Certificate Fields and Extensions This profile extends the base X.509 certificate profile defined in . The following table specifies the requirements for critical fields and extensions.

Version Field Requirement Specification version MUST Set to 2 (meaning X.509 version 3).

Temporal Validity End entity certificates using this profile MUST NOT be valid for more than two weeks. Revocation methods SHOULD NOT be used to verify the continued validity of end entity certificates. Automated methods SHOULD be used to provision end entity certificates to devices that use them. Intermediate certificates using this profile MUST NOT be valid for more than one year. Revocation methods SHOULD be used to verify the continued validity of intermediate certificates.

Subject and Subject Public Key Info Field Requirement Specification subject SHOULD NOT Certificates in this profile are primarily identified by the ASN in the SAN extension. The subject field SHOULD be empty (an empty sequence of RDNs). subjectPublicKeyInfo MUST Contains the public key associated with the AS. subjectKeyIdentifier MUST Contains the subjectKeyIdentifier for the public key. authorityKeyIdentifier SHOULD Contains the authorityKeyIdentifier for the public key of the certificate’s issuer, if the certificate is not self-signed.

Extensions The following extensions are mandatory or critical for this profile:

Basic Constraints Field Requirement Specification basicConstraints MUST MUST be present. If the certificate is an End-Entity certificate (AS identity), CA MUST be set to FALSE. If the certificate is for a CA that issues AS Identity Certificates, CA MUST be set to TRUE.

Key Usage Field Requirement Specification keyUsage MUST MUST be present. For End-Entity AS Identity Certificates, digitalSignature MUST be asserted.

Extended Key Usage (EKU) Field Requirement Specification extKeyUsage MUST EKU values SHOULD be one or both of TLS client authentication, and TLS server authentication. Other EKU values SHOULD NOT be present.

Subject Alternative Name (SAN) - Critical The ASN is carried within the GeneralName type using a specific OID. Field Requirement Specification subjectAlternativeName MUST MUST be present and MUST be marked as CRITICAL. ASIdentifier MUST The ASN MUST be carried in a GeneralName of type otherName. The OID and structure of this otherName are defined below. IPAddress MAY One or more IP addresses MAY be carried in the certificate. Other SAN names SHOULD NOT be present.

RFC 3779 Extensions extensions used for validating the RPKI SHOULD NOT be present. Field Requirement Specification id-pe-ipAddrBlocks SHOULD NOT This profile is deliberately separate from RPKI. id-pe-autonomousSysIds SHOULD NOT This profile is deliberately separate from RPKI.

AS Identifier Encoding in Subject Alternative Name The ASN SHALL be included in the Subject Alternative Name extension using the otherName choice of the GeneralName type. The specific OID for the AS Identifier is:

NOTE: A specific OID MUST be obtained from IANA for this profile before final standardization. For this draft, we use the placeholder id-pe-ASIdentifier. The ASIdentifier structure, defined by this OID, SHALL be an ASN.1 INTEGER representing the AS Number. AS Numbers range from 1 to 4,294,967,295.

The ASN.1 structure within the SAN extension will look like this:

When encoding the ASN: The type-id is set to id-pe-ASIdentifier. The value is the ASN.1 INTEGER representation of the AS Number (e.g., AS 64496 would be encoded as the integer 64496).

End Entity Certificate Issuance Any intermediate certificates used to issue end entity certificates using this profile MUST include all id-pe-ASIdentifier names as the end entity certificate. Such intermediate certificates MAY include SAN IP address name constraints as per and if present they MUST be marked critical

Intermediate CA Issuance The intermediate certificate for an AS can sign any leaf certificate for that AS that will then be able to authenticate a connection. Out Of Band Trust Anchor Exchange Relying parties using this model exchange trust anchors out of band. Relying parties using this model may decide to validate mutual trust out of band. Appropriate care should be taken in any such scenario which is out of scope of this document. With trust mutually established, they may exchange trust anchors which will in turn be trusted to sign end entity certificates for each of them. This could take the form of a self signed intermediate certificate that is elided as a trust anchor by each party. Each party in this case must take appropriate care that such a trust anchor is not considered trusted in other places. Third Party Trusted Certificate Authority Third party certificate authorities SHOULD validate requests for intermediate certificates using this profile by the following method: For every AS in an intermediate certificate request: Validate a CMS message containing the public key of the certificate is signed by the corresponding key for the AS in a currently validated RPKI tree. This signature is considered to be “proof of control of the AS” for these purposes.

Operational Considerations In circumstances where a BGP session's certificate validation may not be possible - for example, the validating trust anchors are not installed - operators may have need to permit BGP sessions to be established without validating the authenticity of the session. Implementations MUST provide a mechanism to permit sessions to establish in the absence of such validation. One mechanism may be to make use of "Trust of First Use (TOFU)". Another may be to disable validation altogether. While such practices are not recommended, operators have the option to do after the fact validation of the sessions that have been expediently trusted in this fashion. Implementations MUST provide operational access to the running session's certificates used for the running sessions. Similarly, implementations MUST provide logging facilities for when BGP sessions are permitted to be established when validation either cannot be done or is permitted even though validation has failed. End entity certificates are recommended to have a life time no longer than two weeks. Implementations SHOULD validate certificates used for the first use of a BGP session are valid within the expected life time. Implementations MAY ignore end entity certificate life time expiration that otherwise validates for sessions that have previously been seen to be established. Ignoring life time validation errors is a balance for the security stance of the operator and a desire for BGP resiliency in the face of tardy certificate updates.

Security Considerations

Certificate Validation Security Considerations The security of this profile relies on: Strong Identity Verification: The CA MUST strictly verify the applicant's control of the ASN before issuance of an intermediate. Flaws in this process can lead to impersonation. Criticality of SAN: Marking the subjectAlternativeName extension as critical ensures that relying parties that do not understand the id-pe-ASIdentifier OID will reject the certificate, preventing misinterpretation of the certificate's identity.

BGP Security Considerations Implementations MUST provide granular control over the certificate trust anchors used to authenticate individual BGP sessions. Use of this certificate profile for protecting BGP sessions carried over TLS have the opportunity to reduce impersonation of authorized parties peering with the BGP speaker. Correct provisioning of the trust anchors used for validating certificates is necessary to prevent such impersonation. Trusted third party trust anchors provide opportunities for reduced operational complexity and fewer certificates necessary for BGP speakers. However, they introduce the opportunity for impersonation attacks to be enabled by the these parties. Beware of who you trust.

IANA Considerations This document requests that IANA assign a unique OID under the SMI Security Private Extensions arc for id-pe-ASIdentifier to be used within the otherName field of the Subject Alternative Name extension.

This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. [STANDARDS-TRACK] This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document describes how Transport Layer Security (TLS) is used to secure QUIC. This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. Futurewei Technologies Futurewei Technologies Juniper Networks Huawei Technologies Nvidia This document specifies the procedures for BGP to use QUIC as a transport protocol with a mechanism to carry Network Layer protocols (AFI/SAFI) over multiple QUIC streams to achieve high resiliency. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK] The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report documents experience with BGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This memo describes a TCP extension to enhance security for BGP. [STANDARDS-TRACK] Border Gateway Protocol 4 (BGP-4), along with a host of other infrastructure protocols designed before the Internet environment became perilous, was originally designed with little consideration for protection of the information it carries. There are no mechanisms internal to BGP that protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior. This document discusses some of the security issues with BGP routing data dissemination. This document does not discuss security issues with forwarding of packets. This memo provides information for the Internet community. This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK] This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community. This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK] Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation.

Use of this Profile for Non-BGP Purposes Astute readers will note that while this document is written with a focus on BGP operational matters that similar security considerations apply for all other control plane protocols standardized by IETF that use TCP. The primary difference between the BGP use case and the more general-purpose control plane use case is the lack of a protocol-recognized "AS" as the party used both for protocol validation and as the identity for the CA certificates issuing end entity certificates. The authors will consider a future general-purpose "TLS for routing" profile in the future based on experience in discussing this more specific use case.

Acknowledgments TODO