idnits 2.17.1 draft-dai-netconf-quic-netconf-over-quic-01.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 11) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 17 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 95 has weird spacing: '...llowing aspec...' == Line 98 has weird spacing: '...nection betw...' == Line 99 has weird spacing: '...ed data deli...' == Line 100 has weird spacing: '...between prot...' == Line 106 has weird spacing: '... to any par...' == (24 more instances...) -- The document date (November 08, 2021) is 900 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) == Missing Reference: 'RFC2119' is mentioned on line 160, but not defined == Missing Reference: 'RFC4642' is mentioned on line 354, but not defined == Missing Reference: 'RFC5280' is mentioned on line 384, but not defined == Missing Reference: 'RFC4742' is mentioned on line 434, but not defined ** Obsolete undefined reference: RFC 4742 (Obsoleted by RFC 6242) == Missing Reference: 'RFC7301' is mentioned on line 440, but not defined == Missing Reference: 'RFC7858' is mentioned on line 457, but not defined == Unused Reference: 'I-D.ietf-quic-tls' is defined on line 471, but no explicit reference was found in the text == Unused Reference: 'RFC6101' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'RFC3080' is defined on line 513, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-27 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-27 ** Obsolete normative reference: RFC 4741 (Obsoleted by RFC 6241) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5539 (Obsoleted by RFC 7589) ** Downref: Normative reference to an Historic RFC: RFC 4743 -- Duplicate reference: RFC4743, mentioned in 'RFC4744', was also mentioned in 'RFC4743'. ** Downref: Normative reference to an Historic RFC: RFC 4743 (ref. 'RFC4744') == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-18 Summary: 8 errors (**), 0 flaws (~~), 21 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dai 3 INTERNET-DRAFT X. Wang 4 Intended Status: Proposed Standard Y. Kou 5 Expires: May 08, 2022 L. Zhou 6 China Information Communication Technologies Group 7 November 08, 2021 9 Using NETCONF over QUIC connection 10 draft-dai-netconf-quic-netconf-over-quic-01 12 Abstract 14 The Network Configuration Protocol (NETCONF) provides mechanisms to 15 install, manipulate, and delete the configuration of network devices. 16 At present, almost all implementations of NETCONF are based on TCP 17 based protocol. QUIC, a new UDP-based, secure and multiplexed transport 18 protocol, can facilitate to improve the transportation performance, 19 information security and resource utility when being used as an 20 infrastructure layer of NETCONF. This document describes how to use the 21 QUIC protocol as the transport protocol of NETCONF(It is so called 22 NETCONFoQUIC). 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as 32 Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Copyright and License Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Connection management . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Draft Version Identification . . . . . . . . . . . . . . . 4 65 3.2. Connection setup . . . . . . . . . . . . . . . . . . . . . 4 66 3.3. Connection Closure . . . . . . . . . . . . . . . . . . . . 5 67 4 Stream mapping and usage . . . . . . . . . . . . . . . . . . . 6 68 4.1. Bidirectional stream between manager and agent . . . . . . 8 69 4.2. Unidirectional stream from agent to manager . . . . . . . . 8 70 5 Endpoint Authentication . . . . . . . . . . . . . . . . . . . . 8 71 5.1 using QUIC handshake authentication . . . . . . . . . . . . 8 72 5.1.1. Server Identity . . . . . . . . . . . . . . . . . . . 8 73 5.1.2. Client Identity . . . . . . . . . . . . . . . . . . . 9 74 5.2 using third-party authentication . . . . . . . . . . . . . . 10 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 77 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 78 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 9.1 Normative References . . . . . . . . . . . . . . . . . . . 11 80 9.2 Informative References . . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 The Network Configuration Protocol (NETCONF) [RFC6241] defines a 86 mechanism through which the configuration of network devices can be 87 installed, manipulated, and deleted. 89 NETCONF can be conceptually partitioned into four layers: Content 90 layer, operation layer, message layer and security transport layer. 92 The Secure Transport layer provides a communication path between the 93 client and server. NETCONF can be layered over any transport 94 protocol that provides a set of basic requirements, the requirements 95 include the following aspects: 97 (1). NETCONF is connection-oriented, requiring a persistent 98 connection between peers. This connection MUST provide reliable, 99 sequenced data delivery. NETCONF connections are long-lived, 100 persisting between protocol operations. 102 (2). NETCONF connections MUST provide authentication, data integrity, 103 confidentiality, and replay protection. NETCONF depends on the 104 transport protocol for this capability. 106 So, the NETCONF protocol is not bound to any particular transport 107 protocol, but allows a mapping to define how it can be implemented 108 over any specific protocol. At the present, there are a few secure 109 transport protocols that can be used to carry NETCONF: 111 (1). [RFC6242] specifies how to use secure shell(SSH) as the secure 112 transport layer of NETCONF. 114 (2). [RFC5539] specifies how to use transport layer security(TLS) as 115 the secure transport layer of NETCONF. 117 (3). [RFC4743] specifies how to use simple object access 118 protocol(SOAP)as the secure transport layer of NETCONF. 120 (4). [RFC4744] specifies how to use blocks extensible exchange 121 protocol(BEEP) as the secure transport layer of NETCONF. 123 However, because of the connection-oriented feature, almost all of 124 the current secure transport protocols used by NETCONF is TCP based. 125 As is well known, TCP has some shortcomings such as head-of-line 126 blocking. 128 [I-D.ietf-quic-transport] specifies a new transport protocol that has 129 the following features: 131 (1). UDP based 133 (2). Stream multiplexing 135 (3). Stream and connection-level flow control 137 (4). Low-latency connection establishment 139 (5). Authenticated and encrypted header and payload 141 It can be learned from the afore-mentioned information that QUIC is 142 also a proper candidate transport protocol for the secure transport 143 layer of NETCONF. In addition, QUIC can perfectly fix the shortcoming 144 such as head of line blocking of TCP. This document specifies how to use 145 QUIC as the secure transport protocol for QUIC. 147 In this document, the terms "client" and "server" are used to refer 148 to the two ends of the QUIC connection. The client actively 149 initiates the QUIC connection. The terms "manager" and "agent" are 150 used to refer to the two ends of the NETCONF protocol session. The 151 manager issues NETCONF remote procedure call (RPC) commands, and 152 the agent replies to those commands. Generally, a "manager" is a 153 "client" meanwhile an "agent" is a "server". 155 2. Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC 2119 [RFC2119]. 161 3. Connection management 163 3.1. Draft Version Identification 165 *RFC Editor's Note:* Please remove this section prior to 166 publication of a final version of this document. 168 NETCONFoQUIC uses the token "NoQ" to identify itself in ALPN and Alt- 169 Svc. Only implementations of the final, published RFC can identify 170 themselves as "NoQ". Until such an RFC exists, implementations MUST 171 NOT identify themselves using this string. 173 Implementations of draft versions of the protocol MUST add the string 174 "-" and the corresponding draft number to the identifier. 176 3.2. Connection setup 177 3.2.1. Version negotiation 179 QUIC versions are identified using a 32-bit unsigned number, and the 180 version 0x00000000 is reserved to represent version negotiation. 182 Version negotiation ensures that client and server agree to a QUIC 183 version that is mutually supported. 185 A server sends a Version Negotiation packet where multiple QUIC 186 versions are listed to the client, the order of the values reflects 187 the server's preference (with the first value being the most 188 preferred version). Reserved versions MAY be listed, but unreserved 189 versions which are not supported by the alternative SHOULD NOT be 190 present in the list. 192 When received the Version Negotiation packet, Clients MUST ignore any 193 included versions which they do not support. 195 If both of the server and the client support the QUIC version that 196 uses TLS version 1.3 or greater as its handshake protocol, the afore- 197 mentioned QUIC version should be the preferred QUIC version of the 198 server and the client. 200 3.2.2. Connection establishment 202 QUIC connections are established as described in [I-D.ietf-quic- 203 transport]. During connection establishment, NETCONFoQUIC support is 204 indicated by selecting the ALPN token "NoQ" in the crypto handshake. 206 The peer acting as the NETCONF manager MUST also act as the client 207 meanwhile the peen acting as the NETCONF agent must also act as the 208 server. 210 The manager should the initiator of the QUIC connection to the agent 211 meanwhile the agent act as a connection acceptor. 213 3.3. Connection Closure 215 3.3.1. QUIC connection termination mode 217 There are following methods to terminate a QUIC connection: 219 (1) idle timeout: If the idle timeout is enabled, a connection is 220 silently closed and the state is discarded when it remains idle for 221 longer than both the advertised idle timeout and three times the 222 current Probe Timeout (PTO). 224 (2) immediate close: An endpoint sends a CONNECTION_CLOSE frame 225 (Section 19.19 of [I-D.ietf-quic-transport]) to terminate the 226 connection immediately. 228 (3) stateless reset: A stateless reset is provided as an option of 229 last resort for an endpoint that does not have access to the state 230 of a connection. 232 3.3.2. NETCONFoQUIC consideration for connection termination 234 When a NETCONF session is implemented based on a QUIC connection, the 235 idle timeout should be disabled in order to keep the QUIC connection 236 persistent even if the NETCONF session is idle. 238 When a NETCONF server receives a request, it will 239 gracefully close the NETCONF session. The server must close the 240 associated QUIC connection. 242 When a NETCONF entity receives a request for an 243 open session, it should close the associated QUIC connection. 245 When a NETCONF entity detects any QUIC connection interrupt status, 246 it should send a request to the peer NETCONF entity. 248 When a stateless reset event occurs, nothing needs to be done by 249 either the manager or the agent. 251 4 Stream mapping and usage 253 [RFC6241] specifies protocol layers of NETCONF, the protocol layers 254 structure can also be seen from figure 1 of this document, it is 255 noted that this figure is just a citation from [RFC6241]. 257 Layer Example 258 +-------------+ +-----------------+ +----------------+ 259 (4) | Content | | Configuration | | Notification | 260 | | | data | | data | 261 +-------------+ +-----------------+ +----------------+ 262 | | | 263 +-------------+ +-----------------+ | 264 (3) | Operations | | | | 265 | | | | | 266 +-------------+ +-----------------+ | 267 | | | 268 +-------------+ +-----------------+ +----------------+ 269 (2) | Messages | | , | | | 270 | | | | | | 271 +-------------+ +-----------------+ +----------------+ 272 | | | 273 +-------------+ +-----------------------------------------+ 274 (1) | Secure | | SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... | 275 | Transport | | | 276 +-------------+ +-----------------------------------------+ 278 Figure 1: NETCONF Protocol Layers 280 It can be learned from figure 1 that there are two kinds of main data 281 flow exchanged between manager and agent: 283 (1) Configuration data from manager to agent. 285 (2) Notification data from agent to manager. 287 The two kinds of data flow should be mapped into QUIC streams. 289 QUIC Streams provide a lightweight, ordered byte-stream abstraction 290 to an application. Streams can be unidirectional or bidirectional 291 meanwhile streams can be initiated by either the client or the 292 server. Unidirectional streams carry data in one direction: from 293 the initiator of the stream to its peer. Bidirectional streams 294 allow for data to be sent in both directions. 296 QUIC uses Stream ID to identify the stream. The least significant bit 297 (0x1) of the stream ID identifies the initiator of the stream. The 298 second least significant bit (0x2) of the stream ID distinguishes 299 between bidirectional streams (with the bit set to 0) and 300 unidirectional streams. Table 1 describes the four types of streams 301 and this table can also be seen from [I-D.ietf-quic-transport]. 303 +------+----------------------------------+ 304 | Bits | Stream Type | 305 +------+----------------------------------+ 306 | 0x0 | Client-Initiated, Bidirectional | 307 | | | 308 | 0x1 | Server-Initiated, Bidirectional | 309 | | | 310 | 0x2 | Client-Initiated, Unidirectional | 311 | | | 312 | 0x3 | Server-Initiated, Unidirectional | 313 +------+----------------------------------+ 315 Table 1: Stream ID Types 317 4.1. Bidirectional stream between manager and agent 319 The NETCONF protocol uses an RPC-based communication model. So, the 320 configuration data from manager to agent is exchanged based on 321 '' (the manager initiating) and '' (sent by the 322 agent) and so on. So the messages used to exchange configuration data 323 should be mapped into one or more bidirectional stream whose stream 324 type is 0. 326 4.2. Unidirectional stream from agent to manager 328 There are some notification data exchanged between the agent and the 329 manager. Notification is a server-initiated message indicating that 330 a certain event has been recognized by the server. 332 Notification messages are initiated by the agent and no reply is 333 needed from the manager. So the messages used to exchange 334 configuration data should be mapped into one unidirectional stream 335 whose stream type is 3. 337 5 Endpoint Authentication 339 5.1 using QUIC handshake authentication 341 NETCONFoQUIC is recommended to use the QUIC version uses TLS version 342 1.3 or greater. Then, the TLS handshake process can be used for 343 endpoint authentication. 344 5.1.1. Server Identity 346 During the TLS negotiation, the client MUST carefully examine the 347 certificate presented by the server to determine if it meets the 348 client's expectations. Particularly, the client MUST check its 349 understanding of the server hostname against the server's identity as 350 presented in the server Certificate message, in order to prevent 351 man- in-the-middle attacks. 353 Matching is performed according to the rules below (following the 354 example of [RFC4642]): 356 o The client MUST use the server hostname it used to open the 357 connection (or the hostname specified in the TLS "server_name" 358 extension [RFC5246]) as the value to compare against the server 359 name as expressed in the server certificate. The client MUST NOT 360 use any form of the server hostname derived from an insecure 361 remote source. 363 o If a subjectAltName extension of type dNSName is present in the 364 certificate, it MUST be used as the source of the server's 365 identity. 367 o Matching is case-insensitive. 369 o A "*" wildcard character MAY be used as the leftmost name 370 component in the certificate. For example, *.example.com would 371 match a.example.com, foo.example.com, etc., but would not match 372 example.com. 374 o If the certificate contains multiple names then a match with 375 any one of the fields is considered acceptable. 377 If the match fails, the client MUST either ask for explicit user 378 confirmation or terminate the connection and indicate the server's 379 identity is suspect. 381 Additionally, clients MUST verify the binding between the identity 382 of the servers to which they connect and the public keys presented 383 by those servers. Clients SHOULD implement the algorithm in 384 Section 6 of [RFC5280] for general certificate validation, but MAY 385 supplement that algorithm with other validation methods that 386 achieve equivalent levels of verification (such as comparing the 387 server certificate against a local store of already-verified 388 certificates and identity bindings). 390 If the client has external information as to the expected identity 391 of the server, the hostname check MAY be omitted. 393 5.1.2. Client Identity 395 The server MUST verify the identity of the client with 396 certificate- based authentication according to local policy to 397 ensure that the incoming client request is legitimate before any 398 configuration or state data is sent to or received from the client. 400 5.2 using third-party authentication 402 A third-party authentication mechanism can also be used for 403 NETCONFoQUIC endpoint authentication. for example, a SASL profile 404 based authentication method can be used. 406 6. Security Considerations 408 The security considerations described throughout [RFC5246] and 409 [RFC4741] apply here as well. 411 This document in its current version does not support third-party 412 authentication (e.g., backend Authentication, Authorization, and 413 Accounting (AAA) servers) due to the fact that TLS does not specify 414 this way of authentication and that NETCONF depends on the transport 415 protocol for the authentication service. If third-party 416 authentication is needed, BEEP or SSH transport can be used. 418 An attacker might be able to inject arbitrary NETCONF messages via 419 some application that does not carefully check exchanged messages 420 or deliberately insert the delimiter sequence in a NETCONF message 421 to create a DoS attack. Hence, applications and NETCONF APIs MUST 422 ensure that the delimiter sequence defined in Section 2.1 never 423 appears in NETCONF messages; otherwise, those messages can be 424 dropped, garbled, or misinterpreted. If the delimiter sequence is 425 found in a NETCONF message by the sender side, a robust 426 implementation of this document should warn the user that illegal 427 characters have been discovered. If the delimiter sequence is found 428 in a NETCONF message by the receiver side (including any XML 429 attribute values, XML comments, or processing instructions), a robust 430 implementation of this document must silently discard the message 431 without further processing and then stop the NETCONF session. 433 Finally, this document does not introduce any new security 434 considerations compared to [RFC4742]. 436 7 IANA Considerations 438 This document creates a new registration for the identification of 439 NETCONFoQUIC in the "Application Layer Protocol Negotiation (ALPN) 440 Protocol IDs" registry established in [RFC7301]. 442 The "noq" string identifies NETCONFoQUIC: 444 Protocol: NETCONFoQUIC 446 Identification Sequence: 0x6e 0x6f 0x71 ("noq") 448 Specification: This document 450 In addition, it is requested for IANA to reserve a UDP port TBD for 451 'NETCONF over QUIC'. 453 8 Acknowledgements 455 This document is written by referring [I-D.ietf-quic-transport] 456 edited by Jana Iyengar and Martin Thomson and [I-D.ietf-quic-http] 457 edited by Mike Bishop, and from [RFC7858] authored by Zi Hu, Liang 458 Zhu, John Heidemann, Allison Mankin, Duane Wessels, and Paul 459 Hoffman. 461 Many thanks to all the afore-mentioned editors and authors. 463 9 References 465 9.1 Normative References 467 [I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, 468 "QUIC: A UDP-Based Multiplexed and Secure Transport", 469 draft-ietf-quic-transport-27 (work in progress), 470 Fegruary 2019. 471 [I-D.ietf-quic-tls] M. Thomson. and S. Turner., 472 " Using TLS to Secure QUIC", 473 draft-ietf-quic-tls-27 (work in progress), 474 February 2019. 476 [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 477 4741, December 2006. 479 [RFC5246] Dierks, T. and E. Rescorla, "The Transport 480 Layer Security (TLS) Protocol Version 1.2", 481 RFC 5246, August 2008. 483 [RFC6241] Enns, R., "NETCONF Configuration Protocol", RFC 484 6241, December 2011. 486 [RFC6242] M. Wasserman., "Using the NETCONF Protocol over 487 Secure Shell (SSH)", RFC 6242, June 2011. 489 [RFC5539] Dierks, T. and E. Rescorla, "NETCONF over 490 Transport Layer Security (TLS)", RFC 5539, May 2009. 492 [RFC4743] T. Garddard, "Using NETCONF over the Simple 493 Object Access Protocol (SOAP)", RFC 4743, December 2006. 495 [RFC4744] E. Lear, "Using the NETCONF Protocol over the 496 Blocks Extensible Exchange Protocol (BEEP)", RFC 4743, 497 December 2006. 499 [I-D.ietf-quic-http] Bishop, M., "Hypertext 500 Transfer Protocol Version 3 (HTTP/3)", draft- 501 ietf-quic-http-18 (work in progress), January 502 2019. 504 9.2 Informative References 506 [RFC5246] M. Badra, "The Transport Layer 507 Security (TLS) Protocol Version 1.2", 508 RFC 5246, August 2008. 510 [RFC6101] M. Rose, "The Secure Sockets Layer (SSL) 511 Protocol Version 3.0", RFC 6101, August 2011. 513 [RFC3080] M. Rose, "The Blocks Extensible Exchange 514 Protocol Core", RFC 3080, March 2001. 516 Authors' Addresses 518 Jinyou Dai 519 China Information Communication Technologies Group. 520 Gaoxin 4th Road 6# 521 Wuhan, Hubei 430079 522 China 524 Email: djy@fiberhome.com 526 Xueshun Wang 527 China Information Communication Technologies Group. 528 Gaoxin 4th Road 6# 529 Wuhan, Hubei 430079 530 China 532 Email: xswang@fiberhome.com 534 Yang Kou 535 China Information Communication Technologies Group. 536 Gaoxin 4th Road 6# 537 Wuhan, Hubei 430079 538 China 539 Email: ykou@fiberhome.com 541 Lifen Zhou 542 China Information Communication Technologies Group. 543 Gaoxin 4th Road 6# 544 Wuhan, Hubei 430079 545 China 547 Email: lfzhou@fiberhome.com