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