| Internet-Draft | BGP over QUIC | October 2022 |
| Retana, et al. | Expires 27 April 2023 | [Page] |
This document defines the use of QUIC as BGP transport protocol.¶
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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
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."¶
This Internet-Draft will expire on 27 April 2023.¶
Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Border Gateway Protocol (BGP) [RFC4271] is the routing protocol used to exchange routing and reachability information among autonomous systems, and it uses TCP as its transport protocol to provide reliable packet communication. BGP establishes peer relationships between routers using a TCP session on port 179.¶
The Multiprotocol Extensions for BGP-4 (MP-BGP) [RFC4760] allow BGP to carry information for multiple Network Layer protocols. However, only a single TCP connection can reach the Established state between a pair of peers [RFC4271].¶
QUIC [RFC9000] is a UDP-based multiplexed and secure transport protocol that provides connection-oriented and stateful interaction between a client and server. It integrates TLS and allows the exchange of application data as soon as possible. QUIC can provide low latency and encrypted transport with resilient connections.¶
This document specifies the procedures for BGP to use QUIC as a transport protocol (Section 4), including error handling (Section 5). Changes to the BGP Finite State Machine (FSM) [RFC4271] are described in Section 6.¶
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.¶
Client: QUIC client, the active part of QUIC connection.¶
Server: QUIC server, the passive part of QUIC connection.¶
BGP over TCP: BGP using TCP as the transport layer, as [RFC4271].¶
BoQ: BGP over QUIC, i.e., BGP using QUIC as the transport layer.¶
To use QUIC as a transport protocol for BGP, the following design requirements are considered.¶
BoQ replaces only the transport layer of BGP over TCP. The BGP protocol specification remains backward compatible.¶
During the establishment of a BGP session, the BGP FSM receives transport-layer events. In BoQ, these corresponding events are replaced by QUIC events (Section 6).¶
QUIC integrates TLS 1.3 [RFC8446] to encrypt payload and most control information to protect confidentiality and integrity of transmitted data.¶
+ - - - - - - - - - - - + - - - - - - - - - + - - - - - - - - +
| TLS 1.3 Handshake | TLS 1.3 Alerts | BGP-4 |
+ - - - - - - - - - - - + - - - - - - - - - + - - -(API)- - - +
| QUIC Transport |
| (streams, reliability, congestion, etc.) |
+ - - - - - - - - - - - + - - - - - - - - - + - - - - - - - - +
| UDP |
+ - - - - - - - - - - - + - - - - - - - - - + - - - - - - - - +
| IPv4 / IPv6 |
+ - - - - - - - - - - - + - - - - - - - - - + - - - - - - - - +
Figure 1. BGP over QUIC Protocol Stack
¶
QUIC supports stream multiplexing. In a QUIC connection, up to 2 ^ 62 - 1 QUIC streams can be created. In one connection, data of multiple streams may be transmitted at the same time. QUIC strictly ensures a transmission sequence of data of the same stream and supports stream-level flow control.¶
MP-BGP [RFC4760] speficies support for multiple Network Layer protocols. When using a TCP connection, these different services compete for control plane resources. BoQ can have multiple BGP sessions (streams) within one QUIC connection (Section 4.2).¶
Before two BGP speakers start exchanging routing information, they need to establish a BGP session. A BGP session can be established in two phases:¶
[RFC4271] defines BGP FSM operation, connection conflict detection and resolution for BGP over TCP. BGP over QUIC follows the same definitions except the explicit modifications defined in this document.¶
BoQ uses QUIC version 1 as the underlying transport. The use of other QUIC transport versions with may be defined by future specifications.¶
QUIC connections are established as described in [RFC9000]. During connection establishment, a BGP speaker SHOULD use UDP port 179 and MUST select the Application-Layer Protocol Negotiation (ALPN; see [RFC7301]) token "bgp4" in the TLS handshake. Support for other application-layer protocols MUST NOT be offered in the same handshake. A connection MUST be closed if the ALPN token is not as indicated, or if other application-layer protocols are offered in the same handshake.¶
After a QUIC connection is established, the first message sent by each endpoint is an OPEN message, which is used to indicate whether the connection uses one of more QUIC streams to exchange BGP messages (Section 4.2). The message format and framing is unchanged [RFC4271].¶
In QUIC, application protocols exchange information via streams, and multiple streams can be multiplexed onto an underlying connection. Each stream is a separate unidirectional or bidirectional channel of "order stream of bytes." Moreover, each stream has flow control which limits bytes sent on a stream, together with flow control of the connection.¶
There are different options to map streams. This document specifies a complementary and backward compatible mechanism to establish multiple BGP sessions using QUIC streams. An implementation can assign one or more Network Layer protocols to a BGP session.¶
A QUIC stream is created by sending a BGP OPEN message, and each stream MUST be bidirectional as described in Section 2.1 of [RFC9000]. In addition, the corresponding stream MUST end (clean termination) as described in Section 2.4 of [RFC9000] when a BGP session is terminated.¶
Section 4.2.4 describes the Connection Collision Detection procedure to be used with streams. Each BGP session operates independently, which means critical conditions (such as a malformed message) in one session won't affect others.¶
The MultiStream Capability (MSC) is defined to indicate that a BGP speaker supports multiple sessions as specified in this document. The capability [RFC5492] is defined as follows:¶
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+
¶
Flags: bitfield - MUST be set to zero and ignored by the receiver.¶
The MSC only applies when using BGP over QUIC. It MUST be included in all OPEN messages. It MUST be ignored otherwise.¶
BGP multiple session support defined in Section 4.2 applies only if both peers advertise the MSC during the establishment of the "initial session." In particular, if a peer that advertises the MSC doesn't receive an OPEN message with the MSC from its peer, it SHOULD NOT terminate the session.¶
Using the MSC allows peers to establish multiple BGP sessions, one per QUIC stream. Each new BGP session is established using a separate OPEN message [RFC4271] and MUST include the MSC. If both peers exchange the MSC in the "initial session," they MUST include it when establishing other sessions. Otherwise, the new session MUST be terminated, and the Error Subcode MUST be set to MultiStream Conflict (TBD2), defined in Section 5.¶
Once a BGP session is established, it follows the procedures specified in [RFC4271].¶
The modifications to the BGP FSM are described in Section 6. For simplicity and security reason, it is suggested that 1-RTT is used.¶
BGP multi-session support doesn't modify the BGP FSM, but the collision handling procedure should be replaced with the procedure described below.¶
Before creating a new session, a BGP speaker should check that no session exists for the same Network Layer protocol(s). If a session already exists, the BGP speaker SHOULD NOT attempt to create a new one.¶
If a pair of BGP speakers try to establish a BGP session with each other simultaneously, then two parallel sessions will be formed. In the case of BGP over QUIC, the IP addresses of the connection cannot be used to resolve collisions when using multiple streams.¶
To avoid connection collisions, a session is identified by the My Autonomous System and BGP Identifier fields pair in the OPEN message. In this context, a connection collision is the attempt to open a BGP session for which the set of Network Layer protocols is the same. One of the connections MUST be closed.¶
The connection collision is resolved using the extension specified in [RFC6286]. In other words, the session with the higher-valued BGP Identifier is preserved [RFC4271]. If the BGP Identifiers are identical, then the session with the larger ASN is preserved [RFC6286].¶
Upon receiving an OPEN message, the local system MUST examine all of its sessions in the OpenConfirm state. A BGP speaker MAY also examine sessions in an OpenSent state if it knows the BGP Identifier of the peer by means outside of the protocol. If among these sessions, there is one to a remote BGP speaker whose BGP Identifier and ASN pair equals the one in the OPEN message, and this session collides with the connection over which the OPEN message is received, then the local system performs the following collision resolution procedure:¶
Unless allowed via configuration, a connection collision with an existing BGP session in the Established state causes the closing of the newly created session.¶
Closing the BGP session (that results from the collision resolution procedure) is accomplished by sending the NOTIFICATION message with the Error Code Cease, Subcode Connection Collision Resolution (7) [RFC4486].¶
BGP over Quic error handling involves the following three types of errors:¶
(1) QUIC error: Includes stream error and connection error [RFC9001]. In some cases, a stream error may cause a connection error. For example, if an operation error occurs on all streams, the connection error should be triggered to close the connection.¶
(2) TLS alert: In [RFC9001],a QUIC endpoint MUST treat any alert from TLS as if it were at the "fatal" level. For TLS alerts, this includes replacing any alert with a generic alert, such as handshake_failure (0x128 in QUIC).¶
(3) BGP error: If an error occurs in BGP processing [RFC4271], it can be mapped to the following BoQ Error Codes[RFC9000].¶
This document defines some of the following BoQ Error Codes:¶
(1) BOQ_NO_ERROR (0x00): No error. This is used when the connection or stream needs to be closed, but there is no error to signal.¶
(2) BOQ_INTERNAL_ERROR (0x01): The BoQ implementation encountered an internal error and is incapable of continuing the stream or the connection.¶
OPEN message error handling is defined in section 6.2 of [RFC4271]. This document introduces the following OPEN Message Error subcodes:¶
Section 4.2.2 recommends not terminating a session when only one peer supports the MSC. If such a BGP speaker does terminate the session, the Error Subcode MUST be set to Session Capability Mismatch (TBD3).¶
Any individual BGP session can be terminated as specified in [RFC4486]. If multiple sessions are to be terminated, then the procedure MUST be followed for each one.¶
QUIC provides three ways to close a connection(see [RFC9000] Section 10):¶
(1) Idle timeout¶
(2) Immediate Close¶
(3) Stateless Reset¶
When the idle timer expires, the connection is closed immediately. Idle timeout can be calculated using the following formula:¶
idle_timeout=MAX(min_idle_timeout, 3*PTO)¶
The PTO is a time that the sender should wait for an acknowledgment of a sent packet. For a calculation method, refer to [RFC9002] Section 6.2.1.¶
When establishing a QUIC connection, the transmission parameter max_idle_timeout is used. Endpoints advertise local idle_timeout to each other. If no max_idle_timeout advertisement is received from the remote end, the remote idle_timeout is set to a value of 0. Based on the values of local idle_timeout and remote idle_timeout, there are three possible scenarios:¶
(1) If both the values are 0, disable the idle timeout function.¶
(2) If there is only one value 0, set min_idle_timeout to a non-zero value in between.¶
(3) If neither value is 0, set min_idle_timeout to the smaller value.¶
Two options are available for the idle timer during BGP session establishment. Option 1 is recommended by default.¶
Option 1: Set this parameter to 0, indicating that idle timeout is disabled.¶
Option 2: The value must be greater than the value of BGP HoldTimer. It is recommended that the value be greater than five times the value of BGP HoldTimer.¶
This document adds two optional Session attributes to the list in Section 8 of [RFC4271]:¶
Section 8.1.1 of [RFC4271] describes the linkage between the FSM functionality, events, and optional session attributes. When using BoQ, Group 3 (TCP processing) is replaced with:¶
Group 3: QUIC processing¶
QUIC directly encapsulates the handshake process of TLS 1.3 [RFC8446]. In addition, QUIC requires that all packets must be explicitly acknowledged. Therefore, QUIC defines the end state of two connection establishment [RFC9001]¶
(1) Handshake Complete: TLS 1.3 has successfully completed the handshake.¶
(2) Handshake Confirmed: The QUIC has successfully completed the handshake.¶
On the client, the state is Handshake Complete and then Handshake Confirmed. On the server, the two states are reached at the same time.¶
The transport layer events for BoQ FSM are defined as follows :¶
Event 29: ManualStart_with_PassiveQuicEstablishment¶
Definition: Local system administrator manually starts the peer connection, but has PassiveQuicEstablishment enabled.¶
Status: Optional, depending on local system¶
Optional Attribute Status:¶
1) The PassiveTcpEstablishment attribute SHOULD be set to TRUE if this event occurs.¶
2) The DampPeerOscillations attribute SHOULD be set to FALSE when this event occurs.¶
Corresponding TCP events: Event 4¶
Event 30: AutomaticStart_with_PassiveQuicEstablishment¶
Definition: Local system automatically starts the BGP connection with the PassiveQuicEstablishment enabled.¶
Status: Optional, depending on local system¶
Optional Attribute Status:¶
1) The AllowAutomaticStart attribute SHOULD be set to TRUE.¶
2) The PassiveTcpEstablishment attribute SHOULD be set to TRUE.¶
3) If the DampPeerOscillations attribute is supported, the DampPeerOscillations SHOULD be set to FALSE.¶
Corresponding TCP events: Event 5¶
Event 31: AutomaticStart_with_DampPeerOscillations_and_PassiveQuicEstablishment¶
Definition: Local system automatically starts the BGP peer connection with peer oscillation damping enabled and PassiveQuicEstablishment enabled. The exact method of damping persistent peer oscillations is determined by the implementation and is outside the scope of this document.¶
Status: Optional, depending on local system¶
Optional Attribute Status:¶
1) The AllowAutomaticStart attribute SHOULD be set to TRUE.¶
2) The DampPeerOscillations attribute SHOULD be set to TRUE.¶
3) The PassiveTcpEstablishment attribute SHOULD be set to FALSE.¶
Corresponding TCP events: Event 7¶
Event 32: QuicConnection_Valid¶
Definition: This parameter is applicable only to the QUIC server. It indicates that the Handshake Confirmed state is reached.¶
Status: Optional¶
Optional Attribute Status: 1) The TrackTcpState attribute SHOULD be set to TRUE if this event occurs.¶
Corresponding TCP events: Event 14¶
Event 33: Quic_CR_Invalid¶
Definition: This parameter applies only to the QUIC server and indicates that an invalid QUIC connection request is received. Initial packets with invalid source addresses or port numbers,invalid destination addresses or port numbers or version negotiation or address validation fails.¶
Status: Optional¶
Optional Attribute Status: 1) The TrackTcpState attribute should be set to TRUE if this event occurs.¶
Corresponding TCP events: Event 15¶
Event 34: Quic_CR_Acked¶
Definition: This parameter applies only to the QUIC client. It indicates that an Initial ACK message is received from the QUIC server and an Initial/Handshake message is sent to the QUIC server. Note: When this event is received, the QUIC client has reached the Handshake Complete state.¶
Status: Mandatory¶
Corresponding TCP events: Event 16¶
Event 35: QuicConnectionConfirmed¶
Definition: This parameter applies to both QUIC client and QUIC server, indicating that the Handshake Confirmed state has been reached.¶
Status: Mandatory¶
Corresponding TCP events: Event 17¶
Event 36: QuicConnectionFails¶
Definition: This parameter applies to both the QUIC client and the QUIC server. It indicates that an error occurs in the QUIC handshake before the system enters the Handshake Confirmed state.¶
Status: Mandatory¶
Corresponding TCP events: Event 18¶
The decision to use BoQ instead of the TCP-based mechanism defined in [RFC4271] is an operational decision and out of the scope of this document. An implementation MUST provide a configuration mechanism to enable BoQ on a per-peer basis. More granularity (per Network Layer protocol, for example) is not recommended as it may increase the operational complexity.¶
Connectivity problems (e.g., blocking UDP) can result in a failure to establish a QUIC connection; BGP speakers SHOULD attempt to establish a TCP-based BGP session in this case.¶
A BGP speaker that doesn't understand the MSC will ignore it [RFC5492]. Section 4.2.2 recommends not terminating a session when only one peer supports the MSC.¶
One of the drawbacks of a single BGP session is that control plane messages for all supported Network Layer protocols use the same connection, which may cause resource contention.¶
QUIC [RFC9000] does not provide a mechanism for exchanging prioritization information. Instead, it recommends that implementations provide ways for an application to indicate the relative priority of streams, in this case, mapped to BGP sessions. An operator should prioritize BGP sessions (streams) that carry critical control plane information if the functionality is available. The definition of this functionality and the determination of the importance of a BGP session are both outside the scope of this document.¶
An example implementation is to have four priority (0-3) defined, and smaller number means higher priority. Each AFI/SAFI should be assigned a default priority and optional configuration to modify the default value. For example, IPv4 and IPv6 unicast AFI/SAFI (1/1 and 2/1) may have priority of 1, while BGP-LS (16388/71 and 16388/72) may have a priority of 3, and BGP FlowSpec (1/133 and 1/134) may have a priority of 4.¶
For BGP multi session, a configuration command SHOULD be implemented to allow grouping of some AFI/SAFIs into one session.¶
This document replaces the transport protocol layer of BGP from TCP to QUIC. It does not modify the basic protocol specifications of BGP, and therefore does not introduce new security risks to the basic BGP protocol. The non-TCP-related considerations of [RFC4271], [RFC4272], and [RFC7454] apply to the specification in this document.¶
BoQ enhances transport-layer security for BGP sessions, refer to [RFC7454] :¶
(1) Supports server identity authentication.¶
(2) (Optional) Supports client identity authentication.¶
(3) Confidentiality protection of BGP messages is supported. All BGP messages are encrypted for transmission.¶
(4) Supports integrity protection for BGP messages.¶
The use of a specific UDP port number and an ALPN token Section 4.1 protects a BGP Speaker from attempts to establish an unexpected BGP session. Additionally, all packets directed to UDP port 179 on the local device and sourced from an address not known or permitted to become a BGP neighbor SHOULD be discarded.¶
With BGP multi session support using QUIC streams, it separates the control plane traffic over multiple sessions, the effect of a session-based vulnerability is reduced; only a single session is affected and not the whole connection. The result is increased resiliency.¶
On the other hand, a high number of BGP sessions may result in higher resource utilization and the risk of depletion. Also, more sessions may imply additional configuration and operational complexity. However, this risk is mitigated by the fact that BGP sessions typically require explicit configuration by the operator.¶
IANA is requested to add a reference to [this document] for the UDP port 179 entry in the "Service Name and Transport Protocol Port Number Registry".¶
This document creates a new registration for the identification of BGP [RFC4271] in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry.¶
The "bgp4" string identifies BGP-4 [RFC4271]:¶
Protocol: BGP-4¶
Identification Sequence: 0x62 0x67 0x70 0x34 ("bgp4")¶
Specification: This document¶
IANA is asked to assign a new Capability Code for the MultiStream Capability (Section 4.2.2) as follows:¶
| Value | Description | Reference | Change Controller |
|---|---|---|---|
| TBD1 | MultiStream Capability | [This Document] | IETF |
IANA is asked to assign three values from the OPEN Message Error subcodes registry as follows:¶
| Value | Name | Reference |
|---|---|---|
| TBD2 | MultiSession Conflict | [This Document] |
| TBD3 | Session Capability Mismatch | [This Document] |
| TBD4 | Network Layer Protocol Mismatch | [This Document] |
IANA is asked to assign two values from the Cease NOTIFICATION Message Error subcodes registry as follows:¶
| Value | Name | Reference |
|---|---|---|
| BOQ_NO_ERROR | Stream Closed No Error | [This Document] |
| BOQ_INTERNAL_ERROR | Stream Internal Error | [This Document] |
This document merges and replaces [I-D.chen-idr-bgp-over-quic] and [I-D.retana-idr-bgp-quic-stream]. The authors acknowledge the contributions made by the authors and contributors of those documents.¶
This document references the text and procedures defined in [I-D.ietf-idr-bgp-multisession], and we are grateful for their contributions.¶
The authors would like to thank xx for review and comments.¶