Network Working Group S. Chen Internet-Draft Y. Zhang Intended status: Standards Track H. Wang Expires: December 5, 2021 Z. Li Huawei Technologies June 3, 2021 BGP Over QUIC draft-chen-idr-bgp-over-quic-00 Abstract Border Gateway Protocol (BGP) is an autonomous system routing protocol. The main function of BGP is to exchange routing and reachability information between autonomous systems(AS) on the Internet. BGP uses TCP to implement reliable and orderly transmission of information. Similar to TCP, QUIC is a UDP-based, byte-stream-based reliable data transmission service. In addition, by integrating with TLS 1.3, QUIC also supports functions such as establishing connections with minimum latency and providing confidentiality and integrity protection for the transmitted data, and multi-stream multiplexing. Taking use of QUIC for BGP can achieve the possible advantages. This document defines the mechanism of BGP over QUIC to and corresponding procedures. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 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 December 5, 2021. Chen, et al. Expires December 5, 2021 [Page 1] Internet-Draft BGP over QUIC June 2021 Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Design Consideration . . . . . . . . . . . . . . . . . . . . 4 3.1. BGP Specification Compatibility . . . . . . . . . . . . . 4 3.2. Design for Minimum Latency . . . . . . . . . . . . . . . 4 3.3. Eliminate Head-of-line Block . . . . . . . . . . . . . . 4 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. BoQ Protocol Stack . . . . . . . . . . . . . . . . . . . 5 4.2. Port number and ALPN . . . . . . . . . . . . . . . . . . 5 4.3. Stream mapping . . . . . . . . . . . . . . . . . . . . . 5 4.4. BGP Session Establishment . . . . . . . . . . . . . . . . 6 4.4.1. BGP FSM . . . . . . . . . . . . . . . . . . . . . . . 6 4.4.2. 1-RTT Handshake . . . . . . . . . . . . . . . . . . . 10 4.4.3. 0-RTT Handshake . . . . . . . . . . . . . . . . . . . 11 4.5. BGP session management . . . . . . . . . . . . . . . . . 15 4.5.1. Error Handling . . . . . . . . . . . . . . . . . . . 15 4.5.2. Session closure . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction BGP is used to distribute IP routes between autonomous systems and it is one of the most important Internet protocols. BGP Multiprotocol Extensions (MP-BGP) [RFC4760] enables BGP to distribute routes of various address families, such as VPN-IPv4 routes[RFC4364], VPN-IPv6 routes [RFC4659], and EVPN routes [RFC7432]. Chen, et al. Expires December 5, 2021 [Page 2] Internet-Draft BGP over QUIC June 2021 BGP is a routing protocol that requires long-term session persistence. BGP requires that transport protocol provide reliable and secure data transmission services. In [RFC4271] , TCP is defined as the transport protocol for BGP. However, TCP does not protect the confidentiality of the transmitted data. Currently, BGP uses MD5, TCP-AO and TCP Over TLS to provide integrity protection. However, MD5 has been considered an insecure encryption algorithm ([RFC6151]). TCP-AO ([RFC5925][RFC5926]) is unable to encrypt the payload. TLS ([RFC5246][RFC8446]) can be added between BGP and TCP to provide identity authentication, confidentiality, and integrity protection for BGP. However, the way is inefficient since when establishing a BGP session, a three-way handshake is adopted to establish a TCP connection, and then TLS handshake authentication is also performed. QUIC [RFC9000] [RFC9001] is a UDP-based transport protocol that provides the following functions: 1. Reliable data transmission service based on byte streams similar to TCP. 2. Support low-latency connection establishment. 3. Authentication of the server is provided during connection establishment. 4. Authentication of the client is provided during connection establishment. (Optional) 5. QUIC provides confidentiality and integrity protection for transport data and key fields in QUIC headers. QUIC also supports periodic key updates. 6. Supports stream multiplexing, including unidirectional and bidirectional streams. 7. Supports connection migration Comparing with BGP over TCP, BGP over Quic (BoQ) provides the following benefits: 1. The BGP session establishment delay can be reduced since the handshake times can be reduced comparing with BGP over TCP/TLS. 2. The head-of-line block between BGP address families can be eliminated by adopting stream-multiplexing for BGP. Chen, et al. Expires December 5, 2021 [Page 3] Internet-Draft BGP over QUIC June 2021 3. Endogenous transport-layer security is provided, and no additional TLS is required. This document defines the mechanism of BGP over QUIC to and corresponding procedures. 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. ALPN: Application-Layer Protocol Negotiation 3. Design Consideration 3.1. BGP Specification Compatibility BoQ replaces only the transport layer of BGP over TCP, requiring that the BGP protocol specification remain backward compatible. Note that during the establishment of a BGP session, the BGP session state machine needs to receive transport-layer event. The BoQ also needs to receive and process QUIC-related events. 3.2. Design for Minimum Latency QUIC provides minimal connection setup delay. The BGP session setup delay is shortened from TLS 1.3(1 RTT) + TCP(3 RTT) to QUIC(1 RTT). If a BGP session is not established for the first time, the RTT can be set to 0 to shorten the BGP session setup delay. As the core routing protocol of the Internet, a large-scale BGP session needs to be established over a long distance. Reducing the BGP session setup delay helps improve the overall network performance. 3.3. Eliminate Head-of-line Block Data transmitted in a BGP session can be classified into multiple objects: address family, VRF, and route prefix. Different objects can be mapped to different QUIC streams as required to isolate these objects, thereby eliminating the head-of-line blocking problem. Chen, et al. Expires December 5, 2021 [Page 4] Internet-Draft BGP over QUIC June 2021 4. Specification 4.1. BoQ Protocol Stack + - - - - - - - - - - - + - - - - - - - - - + - - - - - - - - + | TLS 1.3 Handshake | TLS 1.3 Alerts | BGP-4 | + - - - - - - - - - - - + - - - - - - - - - + - - -(API)- - - + | QUIC Transport | | (streams, reliability, congestion, etc.) | + - - - - - - - - - - - + - - - - - - - - - + - - - - - - - - + | UDP | + - - - - - - - - - - - + - - - - - - - - - + - - - - - - - - + | IPv4 / IPv6 | + - - - - - - - - - - - + - - - - - - - - - + - - - - - - - - + Figure 1. QUIC Protocol Stack QUIC provides reliable data transmission services based on byte streams. In addition, QUIC uses TLS 1.3 [RFC8446] to protect confidentiality and integrity of transmitted data. 4.2. Port number and ALPN According to Figure 1, QUIC is an application protocol that runs on top of UDP. However, QUIC is designed as a generic (application- layer) transport protocol and does not define a standalone UDP port [I-D.ietf-quic-applicability]. The QUIC uses the port of the application protocol to identify a specific application protocol. In addition, in some cases, multiple protocol versions can run simultaneously on a port number. For example, multiple protocol versions of HTTPS use TCP/UDP port 443, such as HTTP/2 [RFC7540] and HTTP/3 [I-D.ietf-quic-http]. BGP uses TCP/UDP port 179, and currently only a unique valid protocol version BGP-4 exists. Therefore, the QUIC may use only UDP port 179 to uniquely identify the BoQ (that is, BGP-4 over QUIC). The ALPN does not need to be specified. 4.3. Stream mapping In a QUIC connection, up to 2 ^ 62 - 1 QUIC streams can be created and the QUIC stream can be unidirectional or bidirectional. 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, but does not guarantee a transmission sequence of data of different streams. QUIC also supports stream-level flow control. This function is called stream multiplexing. Chen, et al. Expires December 5, 2021 [Page 5] Internet-Draft BGP over QUIC June 2021 BGP can take use of the stream multiplexing to solve the head-of-line issues. For example, for MP-BGP [RFC4760], multiple address families can be deployed in a BGP session. Each address family can be configured with multiple VRFs, and each VRF can contain multiple route prefixes. To isolate objects at different layers and eliminate queue head blocking between these objects, the following QUIC stream mapping mode can be selected: Option 1, Mapping streams based on address families: One or more address family can be mapped to one stream. Option 2, Mapping streams based on VRFs: One or more VRFs can be mapped to one stream. Option 3, Mapping streams based on prefix: it can be combinations of prefixes. Note that regardless of which mapping mode is selected, data of the same object MUST be received and transmitted using the same QUIC stream. 4.4. BGP Session Establishment 4.4.1. BGP FSM Before distributing routes, BGP needs to establish a point-to-point connection, called a BGP session. [RFC4271] defines BGP FSM to describe the BGP session establishment process. A BGP session can be established in two phases: 1. Establish a transport layer connection. For BGP over TCP, a TCP connection is established through a three-way handshake. For BoQ, a 1-RTT handshake or 0-RTT handshake is used to establish a QUIC connection. 2. Establish a BGP session. After a transport-layer connection is established, BGP peers exchange BGP Open and BGP Keepalive messages. If the BGP peers reach the Established state, the BGP session has been established. Similar to TCP, QUIC distinguishes the client (active party) from the server (passive party). Therefore, the connection conflict detection and resolution methods described in [RFC4271] are also applicable to BoQ FSM. In this document, BGP FSM is referred to as BoQ FSM. In the 1-RTT handshake, the BoQ FSM inherits the BGP FSM defined in [RFC4271]. Chen, et al. Expires December 5, 2021 [Page 6] Internet-Draft BGP over QUIC June 2021 TCP-related session attributes should be replaced with BoQ FSM- specific session attributes and FSM events defined in this document. In addition, the processing of BoQ FSM in the 0-RTT handshake is added. The session attributes and FSM events specific to BoQ FSM are defined as follows: 1.Session Attribute (1) Optional Session Attributes: PassiveQuicEstablishment Description: This option indicates that the BGP FSM will passively wait for the remote BGP peer to establish the BGP QUIC connection. Value: TRUE or FALSE (2) Optional Session Attributes: TrackQuicState Description: The BGP FSM normally tracks the end result of a QUIC connection attempt rather than individual QUIC messages. Optionally, the BGP FSM can support additional interaction with the QUIC connection negotiation. . Value: TRUE or FALSE 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 Chen, et al. Expires December 5, 2021 [Page 7] Internet-Draft BGP over QUIC June 2021 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. Chen, et al. Expires December 5, 2021 [Page 8] Internet-Draft BGP over QUIC June 2021 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 Chen, et al. Expires December 5, 2021 [Page 9] Internet-Draft BGP over QUIC June 2021 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 4.4.2. 1-RTT Handshake Normally, a BoQ should use the QUIC 1-RTT handshake to establish a BGP session because it does not require any preconditions. In particular, 1-RTT MUST be used when a BGP session is established for the first time. When the 1-RTT handshake is used, the BoQ FSM only needs to replace the TCP event in the BGP FSM [RFC4271] with the QUIC event according to the mapping in section 4.4.1. The QUIC has complete security only when it reaches the Handshake Confirmed state. Therefore, the BoQ FSM should allow the BGP Open message to be sent only after receiving the QuicConnectionConfirmed event. Although to reduce the connection setup delay, QUIC allows application data to be sent before the Handshake Confirmed state is reached. However,the BGP FSM status needs to be changed for security reasons and the same issues as 0-RTT. Therefore, it is not recommended that the BGP Open message be sent before the Handshake Confirmed state is reached. If the DelayOpen or PassiveQuicEstablished function is configured on the local system, 1-RTT is also required. Chen, et al. Expires December 5, 2021 [Page 10] Internet-Draft BGP over QUIC June 2021 4.4.3. 0-RTT Handshake When the 0-RTT handshake is used, the QUIC client sends a connection establishment request (Initial packet) with a BGP Open Data message. (Referred to as early data and sent using 0-RTT packets) , which means: (1) After sending an Initial packet, the client enters the BGP OpenSent state. (2) After receiving the Client Initial packet and sending the Server Initial/Handshake packet, the server may send BGP Open and change the status to BGP OpenConfirmed. At this time, the Server has not reached the Handshake Complete state. (3) When receiving the Server Initial/Handshake/BGP Open message, the client also reaches the BGP OpenConfirmed state. In this case, the client is not in the Handshake Complete state either. Therefore, in the 0-RTT handshake, the BoQ FSM can directly skip the BGP Connect and Active states. This minimizes the BGP session setup delay. After a BGP peer is disconnected from the Established state, 0-RTT can be used for re-establishment. It should be noted that when the BoQ reaches the BGP OpenConfirmed state, because neither the client nor the server reaches the Handshake Complete state, the handshake may fail. Therefore, during the 0-RTT handshake, before the Handshake Confirmed state is reached, that is, before the BoQ FSM receives the QuicConnectionConfirmed event, the BGP KEEPALIVE/UPDATE/ROUTE-REFRESH message MUST NOT be sent but the NOTIFICATION message MAY be sent. When the 0-RTT handshake is used to establish a BGP session, delete the Connect and Active states and replace Section 8.2.2 of [RFC4271] with the following content. For details about the event indexes, refer to [RFC4271]. Idle state: Initially, the BGP peer FSM is in the Idle state. Hereafter, the BGP peer FSM will be shortened to BGP FSM. In this state, BGP FSM refuses all incoming BGP connections for this peer. No resources are allocated to the peer. In response to a ManualStart event (Event 1) or an AutomaticStart event (Event 3), the local system: Chen, et al. Expires December 5, 2021 [Page 11] Internet-Draft BGP over QUIC June 2021 - initializes all BGP resources for the peer connection, - sets ConnectRetryCounter to zero, - starts the ConnectRetryTimer with the initial value, - initiates a QUIC connection to the other BGP peer,In addition, the Initial packet carries the BGP Open packet. - listens for a connection that may be initiated by the remote BGP peer, and - changes its state to OpenSent. For details about how to handle other events in this state, refer to [RFC4271]. OpenSent: In this state, the BGP OPEN packet has been sent to the neighbor along with the Initial packet. The start events (Events 1, 3,6,29-31) are ignored in the OpenSent state. If a ManualStop event (Event 2) is issued in the OpenSent state,the local system: - sets the ConnectRetryTimer to zero, - releases all BGP resources, - drops the QUIC connection, - sets the ConnectRetryCounter to zero, and - changes its state to Idle. In response to the ConnectRetryTimer_Expires event (Event 9), the local system: - drops the QUIC connection, - restarts the ConnectRetryTimer, - initiates a QUIC connection to the other BGP peer. In addition, the Initial packet carries the BGP Open packet. Chen, et al. Expires December 5, 2021 [Page 12] Internet-Draft BGP over QUIC June 2021 - continues to listen for a connection that may be initiated by the remote BGP peer, and - stays in the OpenSent state. If the local system receives a DelayOpenTimer_Expires event (Event12), the local system: - sends the NOTIFICATION with the Error Code Finite State Machine Error, - sets the ConnectRetryTimer to zero, - stops and clears the DelayOpenTimer (set to zero), - drops the QUIC connection, - increments the ConnectRetryCounter by 1, - optionally performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and - changes its state to IDLE. If the BGP FSM receives a QuicConnection_Valid event (Event 32),the QUIC connection is processed, and the connection remains in the OpenSent state. If the BGP FSM receives a Quic_CR_Invalid event (Event 15), the local system rejects the QUIC connection, and the connection remains in the Opensent state. If the QUIC connection succeeds (Event 34 or Event 35), the local system has sent the OPEN packet to the neighbor,the local system: - stops the ConnectRetryTimer (if running) and sets the ConnectRetryTimer to zero, - sets the HoldTimer to a large value, and - stays in the OpenSent state. If the TCP connection fails (Event 36), the local system: - restarts the ConnectRetryTimer (with the initial value), - releases all BGP resources, - increments the ConnectRetryCounter by 1, Chen, et al. Expires December 5, 2021 [Page 13] Internet-Draft BGP over QUIC June 2021 - optionally performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, - continues to listen for a connection that may be initiated by the remote BGP peer, and - changes its state to Idle. If the BGP message header checking (Event 21) or OPEN message checking detects an error (Event 22)(refer to Section 6.2 of [RFC4271] ), the local system: - sends a NOTIFICATION message with the appropriate error code, - sets the ConnectRetryTimer to zero, - releases all BGP resources, - drops the QUIC connection, - increments the ConnectRetryCounter by 1, - (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is TRUE, and - changes its state to Idle. If a NOTIFICATION message is received with a version error (Event 24), the local system: - sets the ConnectRetryTimer to zero, - releases all BGP resources, - drops the QUIC connection, - increments the ConnectRetryCounter by 1, - (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is TRUE, and - changes its state to Idle. When an OPEN message is received, all fields are checked for correctness. If there are no errors in the OPEN message (Event 19), the local system: - sets the BGP ConnectRetryTimer to zero, Chen, et al. Expires December 5, 2021 [Page 14] Internet-Draft BGP over QUIC June 2021 - sends a KEEPALIVE message, and - sets a KeepaliveTimer (via the text below) - sets the HoldTimer according to the negotiated value (refer to Section 4.2 of [RFC4271] ), - changes its state to OpenConfirm. In response to any other event (Events 8,10-11,20,23,25-28),the local system: - sends the NOTIFICATION with the Error Code Finite State Machine Error, - sets the ConnectRetryTimer to zero, - releases all BGP resources, - drops the QUIC connection, - increments the ConnectRetryCounter by 1, - (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and - changes its state to Idle. OpenConfirm: For details, refer to [RFC4271] . The only modification is to replace TCP Event with QUIC Event. For details, refer to section 4.4.1. Established: For details, refer to [RFC4271]. The only modification is to replace TCP Event with QUIC Event. For details, refer to section 4.4.1. 4.5. BGP session management 4.5.1. Error Handling As shown in section 4.4.1, BoQ 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 Chen, et al. Expires December 5, 2021 [Page 15] Internet-Draft BGP over QUIC June 2021 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. 4.5.2. Session closure QUIC provides three ways to close a connection (refer to Section 10 of[RFC9000] ): (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 Section 6.2.1 of [RFC9002] . 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. Chen, et al. Expires December 5, 2021 [Page 16] Internet-Draft BGP over QUIC June 2021 (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. 5. 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. BoQ enhances transport-layer security for BGP sessions, refer to[RFC7475] : (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. As described in Section 8 of [RFC8446] and Section 9.2 of [RFC9001], the 0-RTT handshake may cause replay attacks. To avoid Replay attacks, the following methods are recommended: (1) By default, the 0-RTT handshake is not used to establish a BGP session. (2) If the 0-RTT handshake is used to establish a BGP session, it is recommended that the receiver directly discard the replayed packets in case of replay attacks. This does not affect the BGP session establishment. RFC 8470 also provides detailed analysis and mitigation measures for the risk of replay attacks caused by the use of early TLS data. Chen, et al. Expires December 5, 2021 [Page 17] Internet-Draft BGP over QUIC June 2021 6. Contributors TBD 7. Acknowledgments TBD. 8. References [I-D.ietf-quic-applicability] Kuehlewind, M. and B. Trammell, "Applicability of the QUIC Transport Protocol", draft-ietf-quic-applicability-11 (work in progress), April 2021. [I-D.ietf-quic-http] Bishop, M., "Hypertext Transfer Protocol Version 3 (HTTP/3)", draft-ietf-quic-http-34 (work in progress), February 2021. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . Chen, et al. Expires December 5, 2021 [Page 18] Internet-Draft BGP over QUIC June 2021 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . [RFC7475] Dawkins, S., "Increasing the Number of Area Directors in an IETF Area", BCP 9, RFC 7475, DOI 10.17487/RFC7475, March 2015, . [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, . [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, May 2021, . Authors' Addresses Shuanglong Chen Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: chenshuanglong@huawei.com Chen, et al. Expires December 5, 2021 [Page 19] Internet-Draft BGP over QUIC June 2021 Yongkang Zhang Huawei Technologies 101 Yuhuatai Software Avenue Nanjing China Email: zhangyongkang@huawei.com Haibo Wang Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: rainsword.wang@huawei.com Zhenbin Li Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Chen, et al. Expires December 5, 2021 [Page 20]