BGP over QUIC
draft-retana-idr-bgp-quic-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Alvaro Retana , Yingzhen Qu , Shuanglong Chen , Jeff Tantsura | ||
| Last updated | 2022-10-24 | ||
| Replaces | draft-retana-idr-bgp-quic-stream, draft-chen-idr-bgp-over-quic | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-retana-idr-bgp-quic-00
IDR Workgroup A. Retana
Internet-Draft Y. Qu
Intended status: Standards Track Futurewei Technologies, Inc.
Expires: 27 April 2023 S. Chen
Huawei Technologies
J. Tantsura
Microsoft
24 October 2022
BGP over QUIC
draft-retana-idr-bgp-quic-00
Abstract
This document defines the use of QUIC as BGP transport protocol.
Status of This Memo
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 Notice
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.
Retana, et al. Expires 27 April 2023 [Page 1]
Internet-Draft BGP over QUIC October 2022
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Key Advantages and Design Consideration . . . . . . . . . . . 3
3.1. BGP Specification Compatibility . . . . . . . . . . . . . 3
3.2. Confidentiality and Integrity . . . . . . . . . . . . . . 4
3.3. Multiple QUIC Streams . . . . . . . . . . . . . . . . . . 4
4. BGP over QUIC (BoQ) . . . . . . . . . . . . . . . . . . . . . 4
4.1. BoQ Connection Establishment . . . . . . . . . . . . . . 5
4.2. Multiple BGP Sessions . . . . . . . . . . . . . . . . . . 5
4.2.1. Multiple BGP Sessions Using QUIC Streams . . . . . . 5
4.2.2. MultiStream Capability . . . . . . . . . . . . . . . 6
4.2.3. Modifications to the BGP FSM . . . . . . . . . . . . 6
4.2.4. BGP Session Establishment and Collision Avoidance . . 7
5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Error Handling with MultiSteam Support . . . . . . . . . 8
5.2. Session closure . . . . . . . . . . . . . . . . . . . . . 9
6. BGP Finite State Machine . . . . . . . . . . . . . . . . . . 10
6.1. Optional Session Attributes . . . . . . . . . . . . . . . 10
6.2. FSM Event . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Operational Considerations . . . . . . . . . . . . . . . . . 14
7.1. Using BoQ . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. BGP Multi Session Backward Compatibility . . . . . . . . 14
7.3. BGP Multi Session Prioritization . . . . . . . . . . . . 14
7.4. Configurations . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. UDP Port for BoQ . . . . . . . . . . . . . . . . . . . . 16
9.2. Registration of the BGP4 Identification String . . . . . 16
9.3. Multiple Streams . . . . . . . . . . . . . . . . . . . . 16
9.4. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
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.
Retana, et al. Expires 27 April 2023 [Page 2]
Internet-Draft BGP over QUIC October 2022
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.
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. Terminology
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.
3. Key Advantages and Design Consideration
To use QUIC as a transport protocol for BGP, the following design
requirements are considered.
3.1. BGP Specification Compatibility
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).
Retana, et al. Expires 27 April 2023 [Page 3]
Internet-Draft BGP over QUIC October 2022
3.2. Confidentiality and Integrity
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
3.3. Multiple QUIC Streams
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).
4. BGP over QUIC (BoQ)
Before two BGP speakers start exchanging routing information, they
need to establish a BGP session. A BGP session can be established in
two phases:
1. Establish a transport layer connection. See Section 4.1.
2. Establish a BGP session. After a transport-layer connection is
established, BGP peers exchange protocol messages as specified in
[RFC4271]. Section 4.2 specifies a mechanism that allows
multiple BGP sessions in a single QUIC connection.
[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.
Retana, et al. Expires 27 April 2023 [Page 4]
Internet-Draft BGP over QUIC October 2022
4.1. BoQ Connection Establishment
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].
4.2. Multiple BGP Sessions
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.
4.2.1. Multiple BGP Sessions Using QUIC Streams
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.
Retana, et al. Expires 27 April 2023 [Page 5]
Internet-Draft BGP over QUIC October 2022
4.2.2. MultiStream Capability
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:
Capability code (1 octet): TBD1
Capability length (1 octet): 1
Capability value (1 octet): flag field reserved.
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].
4.2.3. Modifications to the BGP FSM
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.
Retana, et al. Expires 27 April 2023 [Page 6]
Internet-Draft BGP over QUIC October 2022
4.2.4. BGP Session Establishment and Collision Avoidance
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:
1) The BGP Identifier of the local system is compared to the BGP
Identifier of the remote system (as specified in the OPEN
message). Comparing BGP Identifiers is done by converting them to
host byte order and treating them as 4-octet unsigned integers.
2) If the value of the local BGP Identifier is less than the
remote one, the local system closes the BGP connection that
already exists (the one that is already in the OpenConfirm state)
and accepts the BGP connection initiated by the remote system.
2a) Otherwise, the local system closes the newly created BGP
connection (the one associated with the recently received OPEN
message) and continues to use the existing one (the one that is
already in the OpenConfirm state).
Retana, et al. Expires 27 April 2023 [Page 7]
Internet-Draft BGP over QUIC October 2022
3) If the BGP Identifiers of the peers involved in the connection
collision are identical, then the session initiated by the BGP
speaker with the larger AS number is preserved.
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].
The remainder of the process is as specified in [RFC4271].
5. Error Handling
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.
5.1. Error Handling with MultiSteam Support
OPEN message error handling is defined in section 6.2 of [RFC4271].
This document introduces the following OPEN Message Error subcodes:
Retana, et al. Expires 27 April 2023 [Page 8]
Internet-Draft BGP over QUIC October 2022
TBD2 - MultiSession Conflict - Used if the MSC is exchanged by
both peers in the "initial session" but is not present when
establishing a new session.
TBD3 - Session Capability Mismatch - Used if a BGP speaker
terminates a session in the case where it sends an OPEN message
with the MSC but receives an OPEN message without it.
TBD4 - Network Layer Protocol Mismatch - Used if a BGP session has
already been established for a signaled Network Layer Protocol,
either individually or as part of a set.
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.
5.2. Session closure
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.
Retana, et al. Expires 27 April 2023 [Page 9]
Internet-Draft BGP over QUIC October 2022
(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.
6. BGP Finite State Machine
6.1. Optional Session Attributes
This document adds two optional Session attributes to the list in
Section 8 of [RFC4271]:
14) PassiveQUICEstablishment
15) TrackQUICState
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
Optional Session Attributes: PassiveQUICEstablishment,
TrackQUICState
Option 1: PassiveQUICEstablishment
Description: This option indicates that the BGP FSM will
passively wait for the remote BGP peer to establish the BGP
QUIC connection. The local node is a QUIC server [RFC9000].
Value: TRUE or FALSE
Option 2: TrackQUICState
Retana, et al. Expires 27 April 2023 [Page 10]
Internet-Draft BGP over QUIC October 2022
Description: The BGP FSM tracks the end result of a QUIC
connection attempt rather than individual QUIC messages.
Optionally, the BGP FSM can support additional interaction with
the TCP connection negotiation.
Value: TRUE or FALSE
6.2. FSM Event
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.
Retana, et al. Expires 27 April 2023 [Page 11]
Internet-Draft BGP over QUIC October 2022
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
Retana, et al. Expires 27 April 2023 [Page 12]
Internet-Draft BGP over QUIC October 2022
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
Retana, et al. Expires 27 April 2023 [Page 13]
Internet-Draft BGP over QUIC October 2022
Corresponding TCP events: Event 18
7. Operational Considerations
7.1. Using BoQ
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.
7.2. BGP Multi Session Backward Compatibility
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.
7.3. BGP Multi Session Prioritization
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.
Retana, et al. Expires 27 April 2023 [Page 14]
Internet-Draft BGP over QUIC October 2022
7.4. Configurations
For BGP multi session, a configuration command SHOULD be implemented
to allow grouping of some AFI/SAFIs into one session.
8. Security Considerations
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.
9. IANA Considerations
Retana, et al. Expires 27 April 2023 [Page 15]
Internet-Draft BGP over QUIC October 2022
9.1. UDP Port for BoQ
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".
9.2. Registration of the BGP4 Identification String
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
9.3. Multiple Streams
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 | IETF |
| | | Document] | |
+-------+------------------------+-----------+-------------------+
Table 1: MultiStream Capability
9.4. Error Codes
IANA is asked to assign three values from the OPEN Message Error
subcodes registry as follows:
Retana, et al. Expires 27 April 2023 [Page 16]
Internet-Draft BGP over QUIC October 2022
+=======+=================================+=================+
| Value | Name | Reference |
+=======+=================================+=================+
| TBD2 | MultiSession Conflict | [This Document] |
+-------+---------------------------------+-----------------+
| TBD3 | Session Capability Mismatch | [This Document] |
+-------+---------------------------------+-----------------+
| TBD4 | Network Layer Protocol Mismatch | [This Document] |
+-------+---------------------------------+-----------------+
Table 2
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] |
+--------------------+------------------------+-----------------+
Table 3
10. Acknowledgement
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.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Retana, et al. Expires 27 April 2023 [Page 17]
Internet-Draft BGP over QUIC October 2022
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease
Notification Message", RFC 4486, DOI 10.17487/RFC4486,
April 2006, <https://www.rfc-editor.org/info/rfc4486>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
2009, <https://www.rfc-editor.org/info/rfc5492>.
[RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP
Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286,
June 2011, <https://www.rfc-editor.org/info/rfc6286>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
11.2. Informative References
[I-D.chen-idr-bgp-over-quic]
Chen, S., Zhang, Y., Wang, H., and Z. Li, "BGP Over QUIC",
Work in Progress, Internet-Draft, draft-chen-idr-bgp-over-
quic-00, 3 June 2021, <https://www.ietf.org/archive/id/
draft-chen-idr-bgp-over-quic-00.txt>.
[I-D.ietf-idr-bgp-multisession]
"Multisession BGP", Work in Progress, Internet-Draft,
draft-ietf-idr-bgp-multisession-07, 13 September 2012,
<https://www.ietf.org/archive/id/draft-ietf-idr-bgp-
multisession-07.txt>.
[I-D.retana-idr-bgp-quic-stream]
Retana, A., Qu, Y., and J. Tantsura, "Use of Streams in
BGP over QUIC", Work in Progress, Internet-Draft, draft-
Retana, et al. Expires 27 April 2023 [Page 18]
Internet-Draft BGP over QUIC October 2022
retana-idr-bgp-quic-stream-02, 11 May 2022,
<https://www.ietf.org/archive/id/draft-retana-idr-bgp-
quic-stream-02.txt>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/info/rfc4272>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
February 2015, <https://www.rfc-editor.org/info/rfc7454>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/info/rfc9001>.
[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
May 2021, <https://www.rfc-editor.org/info/rfc9002>.
Authors' Addresses
Alvaro Retana
Futurewei Technologies, Inc.
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Email: aretana@futurewei.com
Yingzhen Qu
Futurewei Technologies, Inc.
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Email: yingzhen.qu@futurewei.com
Retana, et al. Expires 27 April 2023 [Page 19]
Internet-Draft BGP over QUIC October 2022
Shuanglong Chen
Huawei Technologies
No.156 Beiqing Rd.
Beijing
100095
China
Email: chenshuanglong@huawei.com
Jeff Tantsura
Microsoft
United States of America
Email: jefftant.ietf@gmail.com
Retana, et al. Expires 27 April 2023 [Page 20]