idnits 2.17.1 draft-dai-quic-netconf-03.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 15 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 94 has weird spacing: '...llowing aspec...' == Line 97 has weird spacing: '...nection betw...' == Line 98 has weird spacing: '...ed data deli...' == Line 99 has weird spacing: '...between prot...' == Line 105 has weird spacing: '... to any par...' == (24 more instances...) -- The document date (October 26, 2020) is 1270 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 159, but not defined == Missing Reference: 'RFC4642' is mentioned on line 353, but not defined == Missing Reference: 'RFC5280' is mentioned on line 383, but not defined == Missing Reference: 'RFC4742' is mentioned on line 433, but not defined ** Obsolete undefined reference: RFC 4742 (Obsoleted by RFC 6242) == Missing Reference: 'RFC7301' is mentioned on line 439, but not defined == Missing Reference: 'RFC7858' is mentioned on line 456, but not defined == Unused Reference: 'I-D.ietf-quic-tls' is defined on line 470, but no explicit reference was found in the text == Unused Reference: 'RFC6101' is defined on line 509, but no explicit reference was found in the text == Unused Reference: 'RFC3080' is defined on line 512, 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: April 26, 2021 L. Zhou 6 China Information Communication Technologies Group 7 October 26, 2020 9 Using NETCONF over QUIC connection 10 draft-dai-quic-netconf-03 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 transport protocol, can 18 facilitate to improve the transportation performance, information 19 security and resource utility when being used as an infrastructure layer 20 of NETCONF. This document describes how to use the QUIC protocol as the 21 transport protocol of NETCONF(It is so called NETCONFoQUIC). 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Connection management . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Draft Version Identification . . . . . . . . . . . . . . . 4 64 2.2. Connection setup . . . . . . . . . . . . . . . . . . . . . 4 65 2.3. Connection Closure . . . . . . . . . . . . . . . . . . . . 5 66 3 Stream mapping and usage . . . . . . . . . . . . . . . . . . . 6 67 3.1. Bidirectional stream between manager and agent . . . . . . 8 68 3.2. Unidirectional stream from agent to manager . . . . . . . . 8 69 4 Endpoint Authentication . . . . . . . . . . . . . . . . . . . . 8 70 4.1 using QUIC handshake authentication . . . . . . . . . . . . 8 71 4.1.1. Server Identity . . . . . . . . . . . . . . . . . . . 8 72 4.1.2. Client Identity . . . . . . . . . . . . . . . . . . . 9 73 4.2 using third-party authentication . . . . . . . . . . . . . . 10 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 76 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 77 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 8.1 Normative References . . . . . . . . . . . . . . . . . . . 11 79 8.2 Informative References . . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 The Network Configuration Protocol (NETCONF) [RFC6241] defines a 85 mechanism through which the configuration of network devices can be 86 installed, manipulated, and deleted. 88 NETCONF can be conceptually partitioned into four layers: Content 89 layer, operation layer, message layer and security transport layer. 91 The Secure Transport layer provides a communication path between the 92 client and server. NETCONF can be layered over any transport 93 protocol that provides a set of basic requirements, the requirements 94 include the following aspects: 96 (1). NETCONF is connection-oriented, requiring a persistent 97 connection between peers. This connection MUST provide reliable, 98 sequenced data delivery. NETCONF connections are long-lived, 99 persisting between protocol operations. 101 (2). NETCONF connections MUST provide authentication, data integrity, 102 confidentiality, and replay protection. NETCONF depends on the 103 transport protocol for this capability. 105 So, the NETCONF protocol is not bound to any particular transport 106 protocol, but allows a mapping to define how it can be implemented 107 over any specific protocol. At the present, there are a few secure 108 transport protocols that can be used to carry NETCONF: 110 (1). [RFC6242] specifies how to use secure shell(SSH) as the secure 111 transport layer of NETCONF. 113 (2). [RFC5539] specifies how to use transport layer security(TLS) as 114 the secure transport layer of NETCONF. 116 (3). [RFC4743] specifies how to use simple object access 117 protocol(SOAP)as the secure transport layer of NETCONF. 119 (4). [RFC4744] specifies how to use blocks extensible exchange 120 protocol(BEEP) as the secure transport layer of NETCONF. 122 However, because of the connection-oriented feature, almost all of 123 the current secure transport protocols used by NETCONF is TCP based. 124 As is well known, TCP has some shortcomings such as head-of-line 125 blocking. 127 [I-D.ietf-quic-transport] specifies a new transport protocol that has 128 the following features: 130 (1). UDP based 132 (2).Stream multiplexing 134 (3). Stream and connection-level flow control 136 (4). Low-latency connection establishment 138 (5). Authenticated and encrypted header and payload 140 It can be learned from the afore-mentioned information that QUIC is 141 also a proper candidate transport protocol for the secure transport 142 layer of NETCONF. In addition, QUIC can perfectly fix the shortcoming 143 such as head of line blocking of TCP. This document specifies how to use 144 QUIC as the secure transport protocol for QUIC. 146 In this document, the terms "client" and "server" are used to refer 147 to the two ends of the QUIC connection. The client actively 148 initiates the QUIC connection. The terms "manager" and "agent" are 149 used to refer to the two ends of the NETCONF protocol session. The 150 manager issues NETCONF remote procedure call (RPC) commands, and 151 the agent replies to those commands. Generally, a "manager" is a 152 "client" meanwhile an "agent" is a "server". 154 1.1 Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119 [RFC2119]. 160 2. Connection management 162 2.1. Draft Version Identification 164 *RFC Editor's Note:* Please remove this section prior to 165 publication of a final version of this document. 167 NETCONFoQUIC uses the token "NoQ" to identify itself in ALPN and Alt- 168 Svc. Only implementations of the final, published RFC can identify 169 themselves as "NoQ". Until such an RFC exists, implementations MUST 170 NOT identify themselves using this string. 172 Implementations of draft versions of the protocol MUST add the string 173 "-" and the corresponding draft number to the identifier. 175 2.2. Connection setup 176 2.2.1. Version negotiation 178 QUIC versions are identified using a 32-bit unsigned number, and the 179 version 0x00000000 is reserved to represent version negotiation. 181 Version negotiation ensures that client and server agree to a QUIC 182 version that is mutually supported. 184 A server sends a Version Negotiation packet where multiple QUIC 185 versions are listed to the client, the order of the values reflects 186 the server's preference (with the first value being the most 187 preferred version). Reserved versions MAY be listed, but unreserved 188 versions which are not supported by the alternative SHOULD NOT be 189 present in the list. 191 When received the Version Negotiation packet, Clients MUST ignore any 192 included versions which they do not support. 194 If both of the server and the client support the QUIC version that 195 uses TLS version 1.3 or greater as its handshake protocol, the afore- 196 mentioned QUIC version should be the preferred QUIC version of the 197 server and the client. 199 2.2.2. Connection establishment 201 QUIC connections are established as described in [I-D.ietf-quic- 202 transport]. During connection establishment, NETCONFoQUIC support is 203 indicated by selecting the ALPN token "NoQ" in the crypto handshake. 205 The peer acting as the NETCONF manager MUST also act as the client 206 meanwhile the peen acting as the NETCONF agent must also act as the 207 server. 209 The manager should the initiator of the QUIC connection to the agent 210 meanwhile the agent act as a connection acceptor. 212 2.3. Connection Closure 214 2.3.1. QUIC connection termination mode 216 There are following methods to terminate a QUIC connection: 218 (1) idle timeout: If the idle timeout is enabled, a connection is 219 silently closed and the state is discarded when it remains idle for 220 longer than both the advertised idle timeout and three times the 221 current Probe Timeout (PTO). 223 (2) immediate close: An endpoint sends a CONNECTION_CLOSE frame 224 (Section 19.19 of [I-D.ietf-quic-transport]) to terminate the 225 connection immediately. 227 (3) stateless reset: A stateless reset is provided as an option of 228 last resort for an endpoint that does not have access to the state 229 of a connection. 231 2.3.2. NETCONFoQUIC consideration for connection termination 233 When a NETCONF session is implemented based on a QUIC connection, the 234 idle timeout should be disabled in order to keep the QUIC connection 235 persistent even if the NETCONF session is idle. 237 When a NETCONF server receives a request, it will 238 gracefully close the NETCONF session. The server must close the 239 associated QUIC connection. 241 When a NETCONF entity receives a request for an 242 open session, it should close the associated QUIC connection. 244 When a NETCONF entity detects any QUIC connection interrupt status, 245 it should send a request to the peer NETCONF entity. 247 When a stateless reset event occurs, nothing needs to be done by 248 either the manager or the agent. 250 3 Stream mapping and usage 252 [RFC6241] specifies protocol layers of NETCONF, the protocol layers 253 structure can also be seen from figure 1 of this document, it is 254 noted that this figure is just a citation from [RFC6241]. 256 Layer Example 257 +-------------+ +-----------------+ +----------------+ 258 (4) | Content | | Configuration | | Notification | 259 | | | data | | data | 260 +-------------+ +-----------------+ +----------------+ 261 | | | 262 +-------------+ +-----------------+ | 263 (3) | Operations | | | | 264 | | | | | 265 +-------------+ +-----------------+ | 266 | | | 267 +-------------+ +-----------------+ +----------------+ 268 (2) | Messages | | , | | | 269 | | | | | | 270 +-------------+ +-----------------+ +----------------+ 271 | | | 272 +-------------+ +-----------------------------------------+ 273 (1) | Secure | | SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... | 274 | Transport | | | 275 +-------------+ +-----------------------------------------+ 277 Figure 1: NETCONF Protocol Layers 279 It can be learned from figure 1 that there are two kinds of main data 280 flow exchanged between manager and agent: 282 (1) Configuration data from manager to agent. 284 (2) Notification data from agent to manager. 286 The two kinds of data flow should be mapped into QUIC streams. 288 QUIC Streams provide a lightweight, ordered byte-stream abstraction 289 to an application. Streams can be unidirectional or bidirectional 290 meanwhile streams can be initiated by either the client or the 291 server. Unidirectional streams carry data in one direction: from 292 the initiator of the stream to its peer. Bidirectional streams 293 allow for data to be sent in both directions. 295 QUIC uses Stream ID to identify the stream. The least significant bit 296 (0x1) of the stream ID identifies the initiator of the stream. The 297 second least significant bit (0x2) of the stream ID distinguishes 298 between bidirectional streams (with the bit set to 0) and 299 unidirectional streams. Table 1 describes the four types of streams 300 and this table can also be seen from [I-D.ietf-quic-transport]. 302 +------+----------------------------------+ 303 | Bits | Stream Type | 304 +------+----------------------------------+ 305 | 0x0 | Client-Initiated, Bidirectional | 306 | | | 307 | 0x1 | Server-Initiated, Bidirectional | 308 | | | 309 | 0x2 | Client-Initiated, Unidirectional | 310 | | | 311 | 0x3 | Server-Initiated, Unidirectional | 312 +------+----------------------------------+ 314 Table 1: Stream ID Types 316 3.1. Bidirectional stream between manager and agent 318 The NETCONF protocol uses an RPC-based communication model. So, the 319 configuration data from manager to agent is exchanged based on 320 '' (the manager initiating) and '' (sent by the 321 agent) and so on. So the messages used to exchange configuration data 322 should be mapped into one or more bidirectional stream whose stream 323 type is 0. 325 3.2. Unidirectional stream from agent to manager 327 There are some notification data exchanged between the agent and the 328 manager. Notification is a server-initiated message indicating that 329 a certain event has been recognized by the server. 331 Notification messages are initiated by the agent and no reply is 332 needed from the manager. So the messages used to exchange 333 configuration data should be mapped into one unidirectional stream 334 whose stream type is 3. 336 4 Endpoint Authentication 338 4.1 using QUIC handshake authentication 340 NETCONFoQUIC is recommended to use the QUIC version uses TLS version 341 1.3 or greater. Then, the TLS handshake process can be used for 342 endpoint authentication. 343 4.1.1. Server Identity 345 During the TLS negotiation, the client MUST carefully examine the 346 certificate presented by the server to determine if it meets the 347 client's expectations. Particularly, the client MUST check its 348 understanding of the server hostname against the server's identity as 349 presented in the server Certificate message, in order to prevent 350 man- in-the-middle attacks. 352 Matching is performed according to the rules below (following the 353 example of [RFC4642]): 355 o The client MUST use the server hostname it used to open the 356 connection (or the hostname specified in the TLS "server_name" 357 extension [RFC5246]) as the value to compare against the server 358 name as expressed in the server certificate. The client MUST NOT 359 use any form of the server hostname derived from an insecure 360 remote source. 362 o If a subjectAltName extension of type dNSName is present in the 363 certificate, it MUST be used as the source of the server's 364 identity. 366 o Matching is case-insensitive. 368 o A "*" wildcard character MAY be used as the leftmost name 369 component in the certificate. For example, *.example.com would 370 match a.example.com, foo.example.com, etc., but would not match 371 example.com. 373 o If the certificate contains multiple names then a match with 374 any one of the fields is considered acceptable. 376 If the match fails, the client MUST either ask for explicit user 377 confirmation or terminate the connection and indicate the server's 378 identity is suspect. 380 Additionally, clients MUST verify the binding between the identity 381 of the servers to which they connect and the public keys presented 382 by those servers. Clients SHOULD implement the algorithm in 383 Section 6 of [RFC5280] for general certificate validation, but MAY 384 supplement that algorithm with other validation methods that 385 achieve equivalent levels of verification (such as comparing the 386 server certificate against a local store of already-verified 387 certificates and identity bindings). 389 If the client has external information as to the expected identity 390 of the server, the hostname check MAY be omitted. 392 4.1.2. Client Identity 394 The server MUST verify the identity of the client with 395 certificate- based authentication according to local policy to 396 ensure that the incoming client request is legitimate before any 397 configuration or state data is sent to or received from the client. 399 4.2 using third-party authentication 401 A third-party authentication mechanism can also be used for 402 NETCONFoQUIC endpoint authentication. for example, a SASL profile 403 based authentication method can be used. 405 5. Security Considerations 407 The security considerations described throughout [RFC5246] and 408 [RFC4741] apply here as well. 410 This document in its current version does not support third-party 411 authentication (e.g., backend Authentication, Authorization, and 412 Accounting (AAA) servers) due to the fact that TLS does not specify 413 this way of authentication and that NETCONF depends on the transport 414 protocol for the authentication service. If third-party 415 authentication is needed, BEEP or SSH transport can be used. 417 An attacker might be able to inject arbitrary NETCONF messages via 418 some application that does not carefully check exchanged messages 419 or deliberately insert the delimiter sequence in a NETCONF message 420 to create a DoS attack. Hence, applications and NETCONF APIs MUST 421 ensure that the delimiter sequence defined in Section 2.1 never 422 appears in NETCONF messages; otherwise, those messages can be 423 dropped, garbled, or misinterpreted. If the delimiter sequence is 424 found in a NETCONF message by the sender side, a robust 425 implementation of this document should warn the user that illegal 426 characters have been discovered. If the delimiter sequence is found 427 in a NETCONF message by the receiver side (including any XML 428 attribute values, XML comments, or processing instructions), a robust 429 implementation of this document must silently discard the message 430 without further processing and then stop the NETCONF session. 432 Finally, this document does not introduce any new security 433 considerations compared to [RFC4742]. 435 6 IANA Considerations 437 This document creates a new registration for the identification of 438 NETCONFoQUIC in the "Application Layer Protocol Negotiation (ALPN) 439 Protocol IDs" registry established in [RFC7301]. 441 The "noq" string identifies NETCONFoQUIC: 443 Protocol: NETCONFoQUIC 445 Identification Sequence: 0x6e 0x6f 0x71 ("noq") 447 Specification: This document 449 In addition, it is requested for IANA to reserve a UDP port TBD for 450 'NETCONF over QUIC'. 452 7 Acknowledgements 454 This document is written by referring [I-D.ietf-quic-transport] 455 edited by Jana Iyengar and Martin Thomson and [I-D.ietf-quic-http] 456 edited by Mike Bishop, and from [RFC7858] authored by Zi Hu, Liang 457 Zhu, John Heidemann, Allison Mankin, Duane Wessels, and Paul 458 Hoffman. 460 Many thanks to all the afore-mentioned editors and authors. 462 8 References 464 8.1 Normative References 466 [I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, 467 "QUIC: A UDP-Based Multiplexed and Secure Transport", 468 draft-ietf-quic-transport-27 (work in progress), 469 Fegruary 2019. 470 [I-D.ietf-quic-tls] M. Thomson. and S. Turner., 471 " Using TLS to Secure QUIC", 472 draft-ietf-quic-tls-27 (work in progress), 473 February 2019. 475 [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 476 4741, December 2006. 478 [RFC5246] Dierks, T. and E. Rescorla, "The Transport 479 Layer Security (TLS) Protocol Version 1.2", 480 RFC 5246, August 2008. 482 [RFC6241] Enns, R., "NETCONF Configuration Protocol", RFC 483 6241, December 2011. 485 [RFC6242] M. Wasserman., "Using the NETCONF Protocol over 486 Secure Shell (SSH)", RFC 6242, June 2011. 488 [RFC5539] Dierks, T. and E. Rescorla, "NETCONF over 489 Transport Layer Security (TLS)", RFC 5539, May 2009. 491 [RFC4743] T. Garddard, "Using NETCONF over the Simple 492 Object Access Protocol (SOAP)", RFC 4743, December 2006. 494 [RFC4744] E. Lear, "Using the NETCONF Protocol over the 495 Blocks Extensible Exchange Protocol (BEEP)", RFC 4743, 496 December 2006. 498 [I-D.ietf-quic-http] Bishop, M., "Hypertext 499 Transfer Protocol Version 3 (HTTP/3)", draft- 500 ietf-quic-http-18 (work in progress), January 501 2019. 503 8.2 Informative References 505 [RFC5246] M. Badra, "The Transport Layer 506 Security (TLS) Protocol Version 1.2", 507 RFC 5246, August 2008. 509 [RFC6101] M. Rose, "The Secure Sockets Layer (SSL) 510 Protocol Version 3.0", RFC 6101, August 2011. 512 [RFC3080] M. Rose, "The Blocks Extensible Exchange 513 Protocol Core", RFC 3080, March 2001. 515 Authors' Addresses 517 Jinyou Dai 518 China Information Communication Technologies Group. 519 Gaoxin 4th Road 6# 520 Wuhan, Hubei 430079 521 China 523 Email: djy@fiberhome.com 525 Xueshun Wang 526 China Information Communication Technologies Group. 527 Gaoxin 4th Road 6# 528 Wuhan, Hubei 430079 529 China 531 Email: xswang@fiberhome.com 533 Yang Kou 534 China Information Communication Technologies Group. 535 Gaoxin 4th Road 6# 536 Wuhan, Hubei 430079 537 China 538 Email: ykou@fiberhome.com 540 Lifen Zhou 541 China Information Communication Technologies Group. 542 Gaoxin 4th Road 6# 543 Wuhan, Hubei 430079 544 China 546 Email: lfzhou@fiberhome.com