idnits 2.17.1 draft-dai-quic-netconf-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: ---------------------------------------------------------------------------- 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 20 has weird spacing: '...ansport prot...' == 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...' == (25 more instances...) -- The document date (October 28, 2019) is 1614 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 158, but not defined == Missing Reference: 'RFC4642' is mentioned on line 351, but not defined == Missing Reference: 'RFC5280' is mentioned on line 381, but not defined == Missing Reference: 'RFC4742' is mentioned on line 431, but not defined ** Obsolete undefined reference: RFC 4742 (Obsoleted by RFC 6242) == Missing Reference: 'RFC7301' is mentioned on line 437, but not defined == Missing Reference: 'RFC7858' is mentioned on line 454, but not defined == Unused Reference: 'RFC6101' is defined on line 503, but no explicit reference was found in the text == Unused Reference: 'RFC3080' is defined on line 506, 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: April 28, 2020 L. Zhou 6 China Information Communication Technologies Group 7 October 28, 2019 9 Using NETCONF over QUIC connection 10 draft-dai-quic-netconf-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 protocol. QUIC, a new UDP-based transport protocol, can facilitate to 18 improve the transportation performance when being used as an 19 infrastructure layer of NETCONF. This document describes how to use 20 the QUIC protocol as the transport protocol of 21 NETCONF(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 protocol used by NETCONF is TCP related. 124 As is well know, 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 a 141 good candidate transport protocol for the secure transport layer of 142 NETCONF. This document specifies how to use QUIC as the secure 143 transport protocol for QUIC. 145 In this document, the terms "client" and "server" are used to refer 146 to the two ends of the QUIC connection. The client actively 147 initiates the QUIC connection. The terms "manager" and "agent" are 148 used to refer to the two ends of the NETCONF protocol session. The 149 manager issues NETCONF remote procedure call (RPC) commands, and 150 the agent replies to those commands. Generally, a "manager" is a 151 "client" meanwhile an "agent" is a "server". 153 1.1 Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 2. Connection management 161 2.1. Draft Version Identification 163 *RFC Editor's Note:* Please remove this section prior to 164 publication of a final version of this document. 166 NETCONFoQUIC uses the token "NoQ" to identify itself in ALPN and Alt- 167 Svc. Only implementations of the final, published RFC can identify 168 themselves as "NoQ". Until such an RFC exists, implementations MUST 169 NOT identify themselves using this string. 171 Implementations of draft versions of the protocol MUST add the string 172 "-" and the corresponding draft number to the identifier. 174 2.2. Connection setup 175 2.1.1. Version negotiation 177 QUIC versions are identified using a 32-bit unsigned number, and the 178 version 0x00000000 is reserved to represent version negotiation. 180 Version negotiation ensures that client and server agree to a QUIC 181 version that is mutually supported. 183 A server sends a Version Negotiation packet where multiple QUIC 184 versions are listed to the client, the order of the values reflects 185 the server's preference (with the first value being the most 186 preferred version). Reserved versions MAY be listed, but unreserved 187 versions which are not supported by the alternative SHOULD NOT be 188 present in the list. 190 When received the Version Negotiation packet, Clients MUST ignore any 191 included versions which they do not support. 193 If both of the server and the client support the QUIC version that 194 uses TLS version 1.3 or greater as its handshake protocol, the afore- 195 mentioned QUIC version should be the preferred QUIC version of the 196 server and the client. 198 2.1.2. Connection establishment 200 QUIC connections are established as described in [I-D.ietf-quic- 201 transport]. During connection establishment, NETCONFoQUIC support is 202 indicated by selecting the ALPN token "NoQ" in the crypto handshake. 204 The peer acting as the NETCONF manager MUST also act as the client 205 meanwhile the peen acting as the NETCONF agent must also act as the 206 server. 208 The manager should the initiator of the QUIC connection to the agent 209 meanwhile the agent act as a connection acceptor. 211 2.3. Connection Closure 213 2.3.1. QUIC connection termination mode 215 There are following methods to terminate a QUIC connection: 217 (1) idle timeout: If the idle timeout is enabled, a connection is 218 silently closed and the state is discarded when it remains idle for 219 longer than both the advertised idle timeout and three times the 220 current Probe Timeout (PTO). 222 (2) immediate close: An endpoint sends a CONNECTION_CLOSE frame 223 (Section 19.19) to terminate the connection immediately. 225 (3) stateless reset: A stateless reset is provided as an option of 226 last resort for an endpoint that does not have access to the state 227 of a connection. 229 2.3.2. NETCONFoQUIC consideration for connection termination 231 When a NETCONF session is implemented based on a QUIC connection, the 232 idle timeout should be disabled in order to keep the QUIC connection 233 persistent even if the NETCONF session is idle. 235 When a NETCONF server receives a request, it will 236 gracefully close the NETCONF session. The server must close the 237 associated QUIC connection. 239 When a NETCONF entity receives a request for an 240 open session, it should close the associated QUIC connection. 242 When a NETCONF entity detects any QUIC connection interrupt status, 243 it should send a request to the peer NETCONF entity. 245 When a stateless reset event occurs, nothing needs to be done by 246 either the manager or the agent. 248 3 Stream mapping and usage 250 [RFC6241] specifies protocol layers of NETCONF, the protocol layers 251 structure can also be seen from figure 1 of this document, it is 252 noted that this figure is just a citation from [RFC6241]. 254 Layer Example 255 +-------------+ +-----------------+ +----------------+ 256 (4) | Content | | Configuration | | Notification | 257 | | | data | | data | 258 +-------------+ +-----------------+ +----------------+ 259 | | | 260 +-------------+ +-----------------+ | 261 (3) | Operations | | | | 262 | | | | | 263 +-------------+ +-----------------+ | 264 | | | 265 +-------------+ +-----------------+ +----------------+ 266 (2) | Messages | | , | | | 267 | | | | | | 268 +-------------+ +-----------------+ +----------------+ 269 | | | 270 +-------------+ +-----------------------------------------+ 271 (1) | Secure | | SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... | 272 | Transport | | | 273 +-------------+ +-----------------------------------------+ 275 Figure 1: NETCONF Protocol Layers 277 It can be learned from figure 1 that there are two kinds of main data 278 flow exchanged between manager and agent: 280 (1) Configuration data from manager to agent. 282 (2) Notification data from agent to manager. 284 The two kinds of data flow should be mapped into QUIC streams. 286 QUIC Streams provide a lightweight, ordered byte-stream abstraction 287 to an application. Streams can be unidirectional or bidirectional 288 meanwhile streams can be initiated by either the client or the 289 server. Unidirectional streams carry data in one direction: from 290 the initiator of the stream to its peer. Bidirectional streams 291 allow for data to be sent in both directions. 293 QUIC uses Stream ID to identify the stream. The least significant bit 294 (0x1) of the stream ID identifies the initiator of the stream. The 295 second least significant bit (0x2) of the stream ID distinguishes 296 between bidirectional streams (with the bit set to 0) and 297 unidirectional streams. Table 1 describes the four types of streams 298 and this table can also be seen from [I-D.ietf-quic-transport]. 300 +------+----------------------------------+ 301 | Bits | Stream Type | 302 +------+----------------------------------+ 303 | 0x0 | Client-Initiated, Bidirectional | 304 | | | 305 | 0x1 | Server-Initiated, Bidirectional | 306 | | | 307 | 0x2 | Client-Initiated, Unidirectional | 308 | | | 309 | 0x3 | Server-Initiated, Unidirectional | 310 +------+----------------------------------+ 312 Table 1: Stream ID Types 314 3.1. Bidirectional stream between manager and agent 316 The NETCONF protocol uses an RPC-based communication model. So, the 317 configuration data from manager to agent is exchanged based on 318 '' (the manager initiating) and '' (sent by the 319 agent) and so on. So the messages used to exchange configuration data 320 should be mapped into one or more bidirectional stream whose stream 321 type is 0. 323 3.2. Unidirectional stream from agent to manager 325 There are some notification data exchanged between the agent and the 326 manager. Notification is a server-initiated message indicating that 327 a certain event has been recognized by the server. 329 Notification messages are initiated by the agent and no reply is 330 needed from the manager. So the messages used to exchange 331 configuration data should be mapped into one unidirectional stream 332 whose stream type is 3. 334 4 Endpoint Authentication 336 4.1 using QUIC handshake authentication 338 NETCONFoQUIC is recommended to use the QUIC version uses TLS version 339 1.3 or greater. Then, the TLS handshake process can be used for 340 endpoint authentication. 341 4.1.1. Server Identity 343 During the TLS negotiation, the client MUST carefully examine the 344 certificate presented by the server to determine if it meets the 345 client's expectations. Particularly, the client MUST check its 346 understanding of the server hostname against the server's identity as 347 presented in the server Certificate message, in order to prevent 348 man- in-the-middle attacks. 350 Matching is performed according to the rules below (following the 351 example of [RFC4642]): 353 o The client MUST use the server hostname it used to open the 354 connection (or the hostname specified in the TLS "server_name" 355 extension [RFC5246]) as the value to compare against the server 356 name as expressed in the server certificate. The client MUST NOT 357 use any form of the server hostname derived from an insecure 358 remote source. 360 o If a subjectAltName extension of type dNSName is present in the 361 certificate, it MUST be used as the source of the server's 362 identity. 364 o Matching is case-insensitive. 366 o A "*" wildcard character MAY be used as the leftmost name 367 component in the certificate. For example, *.example.com would 368 match a.example.com, foo.example.com, etc., but would not match 369 example.com. 371 o If the certificate contains multiple names then a match with 372 any one of the fields is considered acceptable. 374 If the match fails, the client MUST either ask for explicit user 375 confirmation or terminate the connection and indicate the server's 376 identity is suspect. 378 Additionally, clients MUST verify the binding between the identity 379 of the servers to which they connect and the public keys presented 380 by those servers. Clients SHOULD implement the algorithm in 381 Section 6 of [RFC5280] for general certificate validation, but MAY 382 supplement that algorithm with other validation methods that 383 achieve equivalent levels of verification (such as comparing the 384 server certificate against a local store of already-verified 385 certificates and identity bindings). 387 If the client has external information as to the expected identity 388 of the server, the hostname check MAY be omitted. 390 4.1.2. Client Identity 392 The server MUST verify the identity of the client with 393 certificate- based authentication according to local policy to 394 ensure that the incoming client request is legitimate before any 395 configuration or state data is sent to or received from the client. 397 4.2 using third-party authentication 399 A third-party authentication mechanism can also be used for 400 NETCONFoQUIC endpoint authentication. for example, a SASL profile 401 based authentication method can be used. 403 5. Security Considerations 405 The security considerations described throughout [RFC5246] and 406 [RFC4741] apply here as well. 408 This document in its current version does not support third-party 409 authentication (e.g., backend Authentication, Authorization, and 410 Accounting (AAA) servers) due to the fact that TLS does not specify 411 this way of authentication and that NETCONF depends on the transport 412 protocol for the authentication service. If third-party 413 authentication is needed, BEEP or SSH transport can be used. 415 An attacker might be able to inject arbitrary NETCONF messages via 416 some application that does not carefully check exchanged messages 417 or deliberately insert the delimiter sequence in a NETCONF message 418 to create a DoS attack. Hence, applications and NETCONF APIs MUST 419 ensure that the delimiter sequence defined in Section 2.1 never 420 appears in NETCONF messages; otherwise, those messages can be 421 dropped, garbled, or misinterpreted. If the delimiter sequence is 422 found in a NETCONF message by the sender side, a robust 423 implementation of this document should warn the user that illegal 424 characters have been discovered. If the delimiter sequence is found 425 in a NETCONF message by the receiver side (including any XML 426 attribute values, XML comments, or processing instructions), a robust 427 implementation of this document must silently discard the message 428 without further processing and then stop the NETCONF session. 430 Finally, this document does not introduce any new security 431 considerations compared to [RFC4742]. 433 6 IANA Considerations 435 This document creates a new registration for the identification of 436 NETCONFoQUIC in the "Application Layer Protocol Negotiation (ALPN) 437 Protocol IDs" registry established in [RFC7301]. 439 The "noq" string identifies NETCONFoQUIC: 441 Protocol: NETCONFoQUIC 443 Identification Sequence: 0x6e 0x6f 0x71 ("noq") 445 Specification: This document 447 In addition, it is requested for IANA to reserve a UDP port TBD for 448 'NETCONF over QUIC'. 450 7 Acknowledgements 452 This document is written by referring [I-D.ietf-quic-transport] 453 edited by Jana Iyengar and Martin Thomson and [I-D.ietf-quic-http] 454 edited by Mike Bishop, and from [RFC7858] authored by Zi Hu, Liang 455 Zhu, John Heidemann, Allison Mankin, Duane Wessels, and Paul 456 Hoffman. 458 Many thanks to all the afore-mentioned editors and authors. 460 8 References 462 8.1 Normative References 464 [I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, 465 "QUIC: A UDP-Based Multiplexed and Secure Transport", 466 draft-ietf-quic-transport-18 (work in progress), 467 January 2019. 469 [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 470 4741, December 2006. 472 [RFC5246] Dierks, T. and E. Rescorla, "The Transport 473 Layer Security (TLS) Protocol Version 1.2", 474 RFC 5246, August 2008. 476 [RFC6241] Enns, R., "NETCONF Configuration Protocol", RFC 477 6241, December 2011. 479 [RFC6242] M. Wasserman., "Using the NETCONF Protocol over 480 Secure Shell (SSH)", RFC 6242, June 2011. 482 [RFC5539] Dierks, T. and E. Rescorla, "NETCONF over 483 Transport Layer Security (TLS)", RFC 5539, May 2009. 485 [RFC4743] T. Garddard, "Using NETCONF over the Simple 486 Object Access Protocol (SOAP)", RFC 4743, December 2006. 488 [RFC4744] E. Lear, "Using the NETCONF Protocol over the 489 Blocks Extensible Exchange Protocol (BEEP)", RFC 4743, 490 December 2006. 492 [I-D.ietf-quic-http] Bishop, M., "Hypertext 493 Transfer Protocol Version 3 (HTTP/3)", draft- 494 ietf-quic-http-18 (work in progress), January 495 2019. 497 8.2 Informative References 499 [RFC5246] M. Badra, "The Transport Layer 500 Security (TLS) Protocol Version 1.2", 501 RFC 5246, August 2008. 503 [RFC6101] M. Rose, "The Secure Sockets Layer (SSL) 504 Protocol Version 3.0", RFC 6101, August 2011. 506 [RFC3080] M. Rose, "The Blocks Extensible Exchange 507 Protocol Core", RFC 3080, March 2001. 509 Authors' Addresses 511 Jinyou Dai 512 China Information Communication Technologies Group. 513 Gaoxin 4th Road 6# 514 Wuhan, Hubei 430079 515 China 517 Email: djy@fiberhome.com 519 Xueshun Wang 520 China Information Communication Technologies Group. 521 Gaoxin 4th Road 6# 522 Wuhan, Hubei 430079 523 China 525 Email: xswang@fiberhome.com 527 Yang Kou 528 China Information Communication Technologies Group. 529 Gaoxin 4th Road 6# 530 Wuhan, Hubei 430079 531 China 532 Email: ykou@fiberhome.com 534 Lifen Zhou 535 China Information Communication Technologies Group. 536 Gaoxin 4th Road 6# 537 Wuhan, Hubei 430079 538 China 540 Email: lfzhou@fiberhome.com