]> Vodafone

hemant.sharma@vodafone.com

Vodafone

steven.clarke@vodafone.com

Ops & Management GROW BMP Security BMP over TLS BMPS The BGP Monitoring Protocol (BMP) defines the communication between a BMP station and multiple routers, referred to as network elements (NEs). This document describes BMP over TLS, which uses Transport Layer Security (TLS) to ensure secure transport between the NE and the BMP monitoring station. It updates regarding BMP session establishment and termination.

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 when, and only when, they appear in all capitals, as shown here.

Introduction The BGP Monitoring Protocol (BMP), as defined in , facilitates communication between NEs and a BMP station. Keeping this communication secure is important because it includes sharing sensitive information about BGP peers and monitored prefixes. The , "Security Considerations" acknowledges that while routes in public networks are generally not confidential, BGP is also utilized in private L3VPN networks where confidentiality is crucial. It highlights that without mutual authentication through secure transport mechanisms, the channel is vulnerable to various attacks and recommends using IPSec in tunnel mode with pre-shared keys for enhanced security in such scenarios. Additionally, a recent draft proposal, , titled "TCP-AO Protection for BGP Monitoring Protocol (BMP)" suggests an alternative approach using the TCP Authentication Option . This method authenticates the endpoints of the TCP session, thereby safeguarding its integrity. TCP-AO is beneficial in situations where full IPSec security may not be feasible, although unlike IPSec, it does not encrypt the session traffic. Alternatively, Transport Layer Security (TLS), offers endpoint authentication, data encryption, and data integrity defined in The Transport Layer Security (TLS) Protocol Version 1.2 and The Transport Layer Security (TLS) Protocol Version 1.3 . This document describes how to utilize TLS to secure BMP sessions between a monitoring station (acting as the server) and a Network Element (acting as the client). Unlike BGP, where either side can act as the server, BMP's role distinction simplifies the implementation of TLS in a client-server model. Henceforth, the term BMP over TLS will be referred to as BMPS.

BMP over TLS (BMPS)

Operational Summary The operation of BMPS is virtually the same as the original BMP specification defined in , but with an additional layer of security using TLS. In BMPS, the BMP station functions as the TLS server, while NEs act as TLS clients. Following the completion of the TCP three-way handshake, as defined in , each NE, functioning as a TLS client, initiates a TLS handshake with the BMP monitoring station, acting as the TLS server. Once the TLS connection is successfully established, NEs can immediately start transmitting BMP messages, as there is no separate BMP initiation or handshake phase. The following steps summarize the operational flow of BMPS:

1. The NE initiates and completes a TCP handshake.
2. The NE initiates and completes a TLS handshake with the BMP monitoring station.
3. BMP messages are transmitted by the NE according to .

A BMPS session ends when the underlying TCP or TLS session is terminated for any reason. The states, "No BMP message is ever sent from the monitoring station to the router." To adhere to this standard, the monitoring station MUST listen on separate ports for BMP (non-TLS) and BMPS (TLS) sessions. This approach also offers a simplified "make before break" migration from BMP to BMPS.

Transport Layer Security In regular TLS connections, the server has a TLS certificate along with a public/private key pair, whereas the client does not. For BMP over TLS (BMPS), it is REQUIRED to implement mutual TLS (mTLS), wherein both the server (BMP station) and the client (network element) have certificates, and both sides authenticate each other using their respective public/private key pairs. A self-signed "root" TLS certificate is REQUIRED for mTLS, allowing an organization to act as its own certificate authority. The certificates issued to both the BMP station and NEs should correspond to this root certificate. The operational flow of BMP over TLS is similar to standard TLS operations:

1. The NE initiates the connection to the BMP station.
2. The station presents its TLS certificate.
3. The NE verifies the station's certificate.
4. The NE presents its TLS certificate.
5. The station verifies the NE's certificate.
6. The TLS connection is established.
7. The NE begins transmitting BMP data to the station over the encrypted TLS channel.

TLS version 1.3, defined in , streamlines the handshake process and supports more robust cipher suites compared to TLS version 1.2 , enhancing both speed and security. However, widespread support for TLS 1.3 remains limited, with many systems still primarily utilizing TLS 1.2. The BMPS is REQUIRED to support TLS 1.2 or higher to ensure secure communication.

Operational Recommendations for BMPS The BMP over TLS (BMPS) is RECOMMENDED as an alternative mechanism to safeguard BMP sessions in scenarios where alternative protections like IPSec may not be feasible or deployed.

Security Considerations The BMPS implementation increases computational demands due to continuous encryption and decryption processes, resulting in high CPU utilization and potential vulnerability to denial-of-service attacks. The TLS cipher suites that provide only data integrity validation without encryption SHOULD NOT be used by default. The BMPS implementation SHOULD follow the best practices and recommendations for using TLS, as per the Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) as defined in .

IANA Considerations This document has no IANA actions.

References Normative References 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. This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases. This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. BMP is not suitable for use as a routing protocol. 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 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. Informative References This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community. This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK] This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK] 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] The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describes PCEPS -- the usage of Transport Layer Security (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP. This document updates RFC 5440 in regards to the PCEP initialization phase procedures. Vodafone Juniper Networks This document outlines the utilization of the TCP Authentication Option (TCP-AO), as specified in RFC5925, for the authentication of BGP Monitoring Protocol (BMP) sessions, as specified in RFC7854. TCP-AO provides for the authentication of BMP sessions established between routers and BMP stations at the TCP layer. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/hmntsharma/draft-hmntsharma-bmp-tcp-ao. Vodafone Juniper Networks This document outlines the utilization of the TCP Authentication Option (TCP-AO), as specified in RFC5925, for the authentication of BGP Monitoring Protocol (BMP) sessions, as specified in RFC7854. TCP-AO provides for the authentication of BMP sessions established between routers and BMP stations at the TCP layer. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/hmntsharma/draft-hmntsharma-bmp-tcp-ao.

Acknowledgments This document is the result of studying all the referenced RFCs and drawing some parallels from PCEPS , leading to the specification for BMP over TLS (BMPS). We are grateful to the contributors of the RFCs listed in the References section. Their work has been instrumental in shaping and inspiring the development of this specification.