idnits 2.17.1 draft-retana-idr-bgp-quic-stream-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (11 May 2022) is 714 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Workgroup A. Retana 3 Internet-Draft Y. Qu 4 Intended status: Standards Track Futurewei Technologies, Inc. 5 Expires: 12 November 2022 J. Tantsura 6 Microsoft 7 11 May 2022 9 Use of Streams in BGP over QUIC 10 draft-retana-idr-bgp-quic-stream-02 12 Abstract 14 This document specifies the use of QUIC Streams to support multiple 15 BGP sessions over one connection in order to achieve high resiliency. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 12 November 2022. 34 Copyright Notice 36 Copyright (c) 2022 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Revised BSD License text as 45 described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Revised BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 52 2. Multiple BGP Sessions . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Multiple QUIC Streams . . . . . . . . . . . . . . . . . . 3 54 2.2. Multiple BGP Sessions Using QUIC Streams . . . . . . . . 4 55 3. MultiStream Capability . . . . . . . . . . . . . . . . . . . 4 56 4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 5 57 5. BGP Session Establishment and Collision Avoidance . . . . . . 6 58 6. Modifications to FSM . . . . . . . . . . . . . . . . . . . . 7 59 7. Operational Considerations . . . . . . . . . . . . . . . . . 7 60 7.1. Backward Compatibility . . . . . . . . . . . . . . . . . 7 61 7.2. Session Prioritization . . . . . . . . . . . . . . . . . 7 62 7.3. Other Considerations . . . . . . . . . . . . . . . . . . 8 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 66 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 11.2. Informative References . . . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 71 1. Introduction 73 The Border Gateway Protocol (BGP) [RFC4271] uses TCP as its transport 74 protocol. BGP establishes peer relationships between routers using a 75 TCP session on port 179. TCP also provides reliable packet 76 communication. 78 Multiprotocol Extensions for BGP-4 (MP-BGP) [RFC4760] allow BGP to 79 carry information for multiple Network Layer protocols. However, 80 only a single TCP connection can reach the Established state between 81 a pair of peers [RFC4271]. 83 As pointed out by [I-D.ietf-idr-bgp-multisession], there are some 84 disadvantages of using a single BGP session: 86 A common criticism of BGP is the fact that most malformed messages 87 cause the session to be terminated. While this behavior is 88 necessary for protocol correctness, one may observe that the 89 protocol machinery of a given implementation may only be defective 90 with respect to a given AFI/SAFI. Thus, it would be desirable to 91 allow the session related to that family to be terminated while 92 leaving other AFI/SAFI unaffected. As BGP is commonly deployed, 93 this is not possible. 95 A second criticism of BGP is that it is difficult or in some cases 96 impossible to manage control plane resource contention when BGP is 97 used to support diverse services over a single session. In 98 contrast, if a single BGP session carries only information for a 99 single service (or related set of services) it may be easier to 100 manage such contention. 102 QUIC [RFC9000] is a UDP-based multiplexed and secure transport 103 protocol. QUIC can provide low latency and encrypted transport with 104 resilient connections. [I-D.chen-idr-bgp-over-quic] specifies the 105 procedure to use BGP over QUIC. Complementary to it, this document 106 specifies a mechanism to support multiple BGP sessions using QUIC 107 streams. 109 Each BGP session operates independently. Thus, an error on one 110 session has no impact on any other session. The Network Layer 111 protocol(s) negotiated in the BGP OPEN message distinguish the 112 sessions. 114 1.1. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in BCP 119 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 2. Multiple BGP Sessions 124 2.1. Multiple QUIC Streams 126 QUIC [RFC9000] is a UDP-based secure transport protocol that provides 127 connection-oriented and stateful interaction between a client and 128 server. It integrates TLS and allows the exchange of application 129 data as soon as possible. 131 In QUIC, application protocols exchange information via streams, and 132 multiple streams can be multiplexed onto an underlying connection. 133 Each stream is a separate unidirectional or bidirectional channel of 134 "order stream of bytes." Moreover, each stream has flow control 135 which limits bytes sent on a stream, together with flow control of 136 the connection. 138 2.2. Multiple BGP Sessions Using QUIC Streams 140 BGP over QUIC [I-D.chen-idr-bgp-over-quic] proposes different options 141 to map streams. This document specifies a complementary and backward 142 compatible mechanism to establish multiple BGP sessions using QUIC 143 streams. An implementation can assign one or more Network Layer 144 protocols to a BGP session. 146 A QUIC stream is created by sending a BGP OPEN message, and each 147 stream MUST be bidirectional as described in Section 2.1 of 148 [RFC9000]. In addition, the corresponding stream MUST end (clean 149 termination) as described in Section 2.4 of [RFC9000] when a BGP 150 session is terminated. 152 Section 5 describes the Connection Collision Detection procedure to 153 be used with streams. Each BGP session operates independently, which 154 means critical conditions (such as a malformed message) in one 155 session won't affect others. 157 3. MultiStream Capability 159 The MultiStream Capability (MSC) is defined to indicate that a BGP 160 speaker supports multiple sessions as specified in this document. 161 The capability [RFC5492] is defined as follows: 163 Capability code (1 octet): TBD1 165 Capability length (1 octet): 1 167 Capability value (1 octet): flag field reserved. 169 0 1 2 3 4 5 6 7 170 +-+-+-+-+-+-+-+-+ 171 | Reserved | 172 +-+-+-+-+-+-+-+-+ 174 Flags: bitfield - MUST be set to zero and ignored by the receiver. 176 The MSC only applies when using BGP over QUIC 177 [I-D.chen-idr-bgp-over-quic]. It MUST be included in all OPEN 178 messages. It MUST be ignored otherwise. 180 This specification applies only if both peers advertise the MSC 181 during the establishment of the "initial session." Otherwise, the 182 processes specified in [I-D.chen-idr-bgp-over-quic] MUST be followed. 183 In particular, if a peer that advertises the MSC doesn't receive an 184 OPEN message with the MSC from its peer, it SHOULD NOT terminate the 185 session. 187 Using the MSC allows peers to establish multiple BGP sessions, one 188 per QUIC stream. Each new BGP session is established using a 189 separate OPEN message [RFC4271] and MUST include the MSC. If both 190 peers exchange the MSC in the "initial session," they MUST include it 191 when establishing other sessions. Otherwise, the new session MUST be 192 terminated, and the Error Subcode MUST be set to MultiStream Conflict 193 (TBD2), defined in Section 4. 195 Once a BGP session is established, it follows the procedures 196 specified in [RFC4271]. 198 4. Error Handling 200 OPEN message error handling is defined in section 6.2 of [RFC4271]. 201 This document introduces the following OPEN Message Error subcodes: 203 TBD2 - MultiSession Conflict - Used if the MSC is exchanged by 204 both peers in the "initial session" but is not present when 205 establishing a new session. 207 TBD3 - Session Capability Mismatch - Used if a BGP speaker 208 terminates a session in the case where it sends an OPEN message 209 with the MSC but receives an OPEN message without it. 211 TBD4 - Network Layer Protocol Mismatch - Used if a BGP session has 212 already been established for a signaled Network Layer Protocol, 213 either individually or as part of a set. 215 Section 3 recommends not terminating a session when only one peer 216 supports the MSC. If such a BGP speaker does terminate the session, 217 the Error Subcode MUST be set to Session Capability Mismatch (TBD3). 219 Any individual BGP session can be terminated as specified in 220 [RFC4486]. If multiple sessions are to be terminated, then the 221 procedure MUST be followed for each one. 223 5. BGP Session Establishment and Collision Avoidance 225 Before creating a new session, a BGP speaker should check that no 226 session exists for the same Network Layer protocol(s). If a session 227 already exists, the BGP speaker SHOULD NOT attempt to create a new 228 one. 230 If a pair of BGP speakers try to establish a BGP session with each 231 other simultaneously, then two parallel sessions will be formed. In 232 the case of BGP over QUIC, the IP addresses of the connection cannot 233 be used to resolve collisions when using multiple streams. 235 To avoid connection collisions, a session is identified by the My 236 Autonomous System and BGP Identifier fields pair in the OPEN message. 237 In this context, a connection collision is the attempt to open a BGP 238 session for which the set of Network Layer protocols is the same. 239 One of the connections MUST be closed. 241 The connection collision is resolved using the extension specified in 242 [RFC6286]. In other words, the session with the higher-valued BGP 243 Identifier is preserved [RFC4271]. If the BGP Identifiers are 244 identical, then the session with the larger ASN is preserved 245 [RFC6286]. 247 Upon receiving an OPEN message, the local system MUST examine all of 248 its sessions in the OpenConfirm state. A BGP speaker MAY also 249 examine sessions in an OpenSent state if it knows the BGP Identifier 250 of the peer by means outside of the protocol. If among these 251 sessions, there is one to a remote BGP speaker whose BGP Identifier 252 and ASN pair equals the one in the OPEN message, and this session 253 collides with the connection over which the OPEN message is received, 254 then the local system performs the following collision resolution 255 procedure: 257 1) The BGP Identifier of the local system is compared to the BGP 258 Identifier of the remote system (as specified in the OPEN 259 message). Comparing BGP Identifiers is done by converting them to 260 host byte order and treating them as 4-octet unsigned integers. 262 2) If the value of the local BGP Identifier is less than the 263 remote one, the local system closes the BGP connection that 264 already exists (the one that is already in the OpenConfirm state) 265 and accepts the BGP connection initiated by the remote system. 267 2a) Otherwise, the local system closes the newly created BGP 268 connection (the one associated with the recently received OPEN 269 message) and continues to use the existing one (the one that is 270 already in the OpenConfirm state). 272 3) If the BGP Identifiers of the peers involved in the connection 273 collision are identical, then the session initiated by the BGP 274 speaker with the larger AS number is preserved. 276 Unless allowed via configuration, a connection collision with an 277 existing BGP session in the Established state causes the closing of 278 the newly created session. 280 Closing the BGP session (that results from the collision resolution 281 procedure) is accomplished by sending the NOTIFICATION message with 282 the Error Code Cease, Subcode Connection Collision Resolution (7) 283 [RFC4486]. 285 The remainder of the process is as specified in [RFC4271]. 287 6. Modifications to FSM 289 The modifications to BGP FSM is described in section 4.4 of 290 [I-D.chen-idr-bgp-over-quic]. For simplicity and security reason, it 291 is suggested that 1-RTT is used. 293 This specification does not modify BGP FSM, but the collision 294 handling procedure should be replaced with the procedure described in 295 this document. 297 7. Operational Considerations 299 7.1. Backward Compatibility 301 A BGP speaker that doesn't understand the MSC will ignore it 302 [RFC5492]. Section 3 recommends not terminating a session when only 303 one peer supports the MSC. Instead, the operation will continue as 304 specified in [I-D.chen-idr-bgp-over-quic]. 306 7.2. Session Prioritization 308 One of the drawbacks of a single BGP session is that control plane 309 messages for all supported Network Layer protocols use the same 310 connection, which may cause resource contention. 312 QUIC [RFC9000] does not provide a mechanism for exchanging 313 prioritization information. Instead, it recommends that 314 implementations provide ways for an application to indicate the 315 relative priority of streams, in this case, mapped to BGP sessions. 316 An operator should prioritize BGP sessions (streams) that carry 317 critical control plane information if the functionality is available. 318 The definition of this functionality and the determination of the 319 importance of a BGP session are both outside the scope of this 320 document. 322 An example implementation is to have four priority (0-3) defined, and 323 smaller number means higher priority. Each AFI/SAFI should be 324 assigned a default priority and optional configuration to modify the 325 default value. For example, IPv4 and IPv6 unicast AFI/SAFI (1/1 and 326 2/1) may have priority of 1, while BGP-LS (16388/71 and 16388/72) may 327 have a priority of 3, and BGP FlowSpec (1/133 and 1/134) may have a 328 priority of 4. 330 7.3. Other Considerations 332 A configuration command SHOULD be implemented to allow grouping of 333 some AFI/SAFIs into one session. 335 8. Security Considerations 337 This document specifies how to establish multiple BGP sessions over a 338 single QUIC connection. The general operation of BGP is not changed, 339 nor is its security model. The security considerations of 340 [I-D.chen-idr-bgp-over-quic] apply. Also, the non-TCP-related 341 considerations of [RFC4271], [RFC4272], and [RFC7454] apply to the 342 specification in this document. 344 By separating the control plane traffic over multiple sessions, the 345 effect of a session-based vulnerability is reduced; only a single 346 session is affected and not the whole connection. The result is 347 increased resiliency. 349 On the other hand, a high number of BGP sessions may result in higher 350 resource utilization and the risk of depletion. Also, more sessions 351 may imply additional configuration and operational complexity. 352 However, this risk is mitigated by the fact that BGP sessions 353 typically require explicit configuration by the operator. 355 9. IANA Considerations 357 IANA is asked to assign a new Capability Code for the MultiStream 358 Capability (Section 3) as follows: 360 +=======+========================+===========+===================+ 361 | Value | Description | Reference | Change Controller | 362 +=======+========================+===========+===================+ 363 | TBD1 | MultiStream Capability | [This | IETF | 364 | | | Document] | | 365 +-------+------------------------+-----------+-------------------+ 367 Table 1: MultiStream Capability 369 IANA is asked to assign three values from the OPEN Message Error 370 subcodes registry as follows: 372 +=======+=================================+=================+ 373 | Value | Name | Reference | 374 +=======+=================================+=================+ 375 | TBD2 | MultiSession Conflicty | [This Document] | 376 +-------+---------------------------------+-----------------+ 377 | TBD3 | Session Capability Mismatch | [This Document] | 378 +-------+---------------------------------+-----------------+ 379 | TBD4 | Network Layer Protocol Mismatch | [This Document] | 380 +-------+---------------------------------+-----------------+ 382 Table 2 384 10. Acknowledgement 386 This document references the text and procedures defined in 387 [I-D.ietf-idr-bgp-multisession], and we are grateful for their 388 contributions. 390 The authors would like to thank xx for review and comments. 392 11. References 394 11.1. Normative References 396 [I-D.chen-idr-bgp-over-quic] 397 Chen, S., Zhang, Y., Wang, H., and Z. Li, "BGP Over QUIC", 398 Work in Progress, Internet-Draft, draft-chen-idr-bgp-over- 399 quic-00, 3 June 2021, . 402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 403 Requirement Levels", BCP 14, RFC 2119, 404 DOI 10.17487/RFC2119, March 1997, 405 . 407 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 408 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 409 DOI 10.17487/RFC4271, January 2006, 410 . 412 [RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease 413 Notification Message", RFC 4486, DOI 10.17487/RFC4486, 414 April 2006, . 416 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 417 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 418 2009, . 420 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 421 Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, 422 June 2011, . 424 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 425 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 426 May 2017, . 428 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 429 Multiplexed and Secure Transport", RFC 9000, 430 DOI 10.17487/RFC9000, May 2021, 431 . 433 11.2. Informative References 435 [I-D.ietf-idr-bgp-multisession] 436 Scudder, J., Appanna, C., and I. Varlashkin, "Multisession 437 BGP", Work in Progress, Internet-Draft, draft-ietf-idr- 438 bgp-multisession-07, 13 September 2012, 439 . 442 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 443 RFC 4272, DOI 10.17487/RFC4272, January 2006, 444 . 446 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 447 "Multiprotocol Extensions for BGP-4", RFC 4760, 448 DOI 10.17487/RFC4760, January 2007, 449 . 451 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 452 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 453 February 2015, . 455 Authors' Addresses 457 Alvaro Retana 458 Futurewei Technologies, Inc. 459 2330 Central Expressway 460 Santa Clara, CA 95050 461 United States of America 462 Email: aretana@futurewei.com 464 Yingzhen Qu 465 Futurewei Technologies, Inc. 466 2330 Central Expressway 467 Santa Clara, CA 95050 468 United States of America 469 Email: yingzhen.qu@futurewei.com 471 Jeff Tantsura 472 Microsoft 473 United States of America 474 Email: jefftant.ietf@gmail.com