]> Watsen Networks

kent+ietf@watsen.net

Operations and Management Network Configuration This RFC extends NETCONF Call Home and RESTCONF Call Home [RFC 8071] to support the QUIC protocol [RFC 9000]. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Network Configuration Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This RFC extends NETCONF Call Home and RESTCONF Call Home to support the QUIC protocol . RESTCONF supports QUIC with its implicit support for HTTP/3 . NETCONF supports QUIC with . The QUIC-based call home solution presented in this document is nearly identical to the TLS-based solution defined in RFC 8071, with the primary difference being the use of UDP instead of TCP. RFC 8071 provides a full description and motivation for call home. This document merely maps the solution to the QUIC protocol.

Applicability Statement The techniques described in this document are suitable for network management scenarios such as the ones described in . However, these techniques are only defined for NETCONF Call Home and RESTCONF Call Home, as described in this document. The reason for this restriction is that different protocols have different security assumptions. The NETCONF and RESTCONF protocols require clients and servers to verify the identity of the other party. This requirement is specified for the NETCONF protocol in , and for the RESTCONF protocol in Sections and of . This contrasts with the base QUIC protocol, which does not require programmatic verification of the other party, e.g., in says "the server is optionally able to learn and authenticate an identity for the client." In such circumstances, allowing the QUIC server to contact the QUIC client would open new vulnerabilities. Any use of call home with QUIC for purposes other than NETCONF or RESTCONF will need a thorough contextual risk assessment. A risk assessment for this RFC is in the Security Considerations section .

Relation to RFC 9001 This document uses the QUIC with the exception that the statement "The client initiates the exchange and the server responds" made in does not apply. Assuming the reference to client means "QUIC client" and the reference to server means "QUIC server", this statement does not hold true in call home, where the network element is the QUIC server and yet still initiates the UDP exchange. Security implications related to this change are discussed in Security Considerations .

The NETCONF/RESTCONF Convention Throughout the remainder of this document, the term "NETCONF/ RESTCONF" is used as an abbreviation in place of the text "the NETCONF or the RESTCONF". The NETCONF/RESTCONF abbreviation is not intended to require or to imply that a client or server must implement both the NETCONF standard and the RESTCONF standard.

Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Editorial Note (To be removed by RFC Editor) This document contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Please apply the following replacements:

• XXXX --> the assigned RFC number for this draft
• PORT-X --> the IANA-assigned port number for NETCONF Call Home (QUIC)
• PORT-Y --> the IANA-assigned port number for RESTCONF Call Home (QUIC)

Solution Overview The diagram below illustrates call home from a protocol layering perspective: | | | | | | 2. QUIC | |<-----------------------------------| | | | | | 3. NETCONF/RESTCONF | |<-----------------------------------| | | Note: arrows point from the "client" to the "server" at each protocol layer ]]> This diagram makes the following points:

1. The NETCONF/RESTCONF server begins by sending an empty UDP datagram to the NETCONF/RESTCONF client.
2. Using this source IP address of the UDP datagram, the NETCONF/RESTCONF client initiates a QUIC session to the NETCONF/RESTCONF server.
3. Using this QUICsession, the NETCONF/RESTCONF client initates a NETCONF/RESTCONF session to the NETCONF/RESTCONF server.

The NETCONF or RESTCONF Client The term "client" is defined in and . In the context of network management, the NETCONF/RESTCONF client might be a network management system.

Protocol Operation C1. The NETCONF/RESTCONF client listens for UDP datagrams from NETCONF/RESTCONF servers. The client MUST support receiving UDP datagrams on the IANA-assigned ports defined in , but MAY be configured to listen to a different port. C2. Upon receiving a UDP datagram, the NETCONF/RESTCONF client ensures that the datagram contains at least 1200 bytes. If the datagram contains less than 1200 bytes, the NETCONF/RESTCONF client stops processing the connection attempt. C3. The NETCONF/RESTCONF client initiates the standard QUIC client protocol to the IP address and port extracted from the received UDP datagram. C4. As part of establishing the QUIC connection, the NETCONF/RESTCONF client MUST validate the server's presented certificate. This validation MAY be accomplished by certificate path validation or by comparing the certificate to a previously trusted or "pinned" value. If the certificate contains revocation checking information, the NETCONF/RESTCONF client SHOULD check the revocation status of the certificate. If it is determined that a certificate has been revoked, the client MUST immediately close the connection. C5. If certificate path validation is used, the NETCONF/RESTCONF client MUST ensure that the presented certificate has a valid chain of trust to a preconfigured issuer certificate, and that the presented certificate encodes an "identifier" that the client had awareness of prior to the connection attempt. How identifiers are encoded in certificates MAY be determined by a policy associated with the certificate's issuer. For instance, a given issuer may be known to only sign IDevID certificates having a unique identifier (e.g., serial number) in the X.509 certificate's "CommonName" field. C6. After the server's certificate is validated, the QUIC protocol proceeds as normal to establish a QUIC connection. When performing client authentication with the NETCONF/RESTCONF server, the NETCONF/RESTCONF client MUST ensure to only use credentials that it had previously associated for the NETCONF/RESTCONF server's presented server certificate. C7. Once the QUIC connection is established, the NETCONF/RESTCONF client starts either the NETCONF-client or RESTCONF-client protocol. Assuming the use of the IANA-assigned ports, the NETCONF-client protocol is started when the UDP datagram is received on port PORT-X and the RESTCONF-client protocol is started when the the UDP datagram is received on port PORT-Y.

Configuration Data Model How a NETCONF or RESTCONF client is configured is outside the scope of this document. This includes configuration that might be used to enable listening for call home connections, configuring trusted certificate issuers, and configuring identifiers for expected connections. That said, YANG modules for configuring a NETCONF and RESTCONF clients, including call home, are provided in {{RFC10010}} and {{RFC10011}} respectively.

The NETCONF or RESTCONF Server The term "server" is defined in and . In the context of network management, the NETCONF/RESTCONF server might be a network element or a device.

Protocol Operation S1. The NETCONF/RESTCONF server sends a UDP datagram containing at least 1200 bytes to the NETCONF/RESTCONF client. The server MUST support connecting to one of the IANA-assigned ports defined in , but MAY be configured to connect to a different port. Using the IANA-assigned ports, the server connects to port PORT-X for NETCONF over QUIC, port PORT-Y for RESTCONF over QUIC. S2. The NETCONF/RESTCONF server listens for incoming QUIC connections on the UDP address and port used when it sent the initial UDP datagram to the NETCONF/RESTCONF client. S3. As part of establishing the QUIC connection, the NETCONF/RESTCONF server will send its certificate to the NETCONF/RESTCONF client. The server MUST also send all intermediate certificates leading up to a well known and trusted issuer. How to send a list of certificates is defined in . S4. Establishing a QUIC session requires server authentication of client credentials in all cases except with RESTCONF, where some client authentication schemes occur after the TLS connection has been established. If TLS-level client authentication is required, and the client is unable to successfully authenticate itself to the server in an amount of time defined by local policy, the server MUST close the connection. S5. Once the QUIC connection is established, depending on how the NETCONF/RESTCONF server is configured, it starts either the NETCONF-server or RESTCONF-server over QUIC protocol, per and respectively.. Assuming the use of the IANA-assigned ports, the NETCONF-server over QUIC protocol is used after connecting to remote port PORT-X and the RESTCONF-server protocol is used after connecting to remote port PORT-Y. S6. If a persistent connection is desired, the NETCONF/RESTCONF server, as the connection initiator, SHOULD actively test the aliveness of the connection using a keep-alive mechanism. The NETCONF/RESTCONF server SHOULD send PING Frame , and ensure an ACK Frame in received in an amount of time set by local policy. If the connection is lost, the NETCONF/RESTCONF server should initiate is new connection by going back to S1.

Configuration Data Model How a NETCONF or RESTCONF server is configured is outside the scope of this document. This includes configuration that might be used to specify hostnames, IP addresses, ports, algorithms, or other relevant parameters. That said, YANG modules for configuring NETCONF and RESTCONF servers, including call home, are provided in {{RFC10010}} and {{RFC10011}} respectively.

Security Considerations The solution in this document extends to support call home using QUIC for the NETCONF and RESTCONF protocols, and respectively. The security considerations described in those documents apply here as well. The solution in this document shims a standard QUIC client initated connection by having the QUIC server start a connection by asking the QUIC client to start a standard QUIC-client connection back to it. Thus the security analysis focuses on this interaction. An analysis for the unprotected role reversal is in . In order to thwart an amplication attack, the initial UDP datagram must be at least 1200 bytes. In order to thwart an injection attack, the payload of initial UDP datagram is discarded. In order to thwart a denial of service attack, precautions mitigating DoS attacks are recommended, such as temporarily blacklisting the source IP address and port after a set number of unsuccessful connection attempts. This document recommends the NETCONF/RESTCONF server, as the connection initiator, to actively test the aliveness of the QUIC connection by sending a PING Frame and expecting an ACK frame in an amount of time set by local policy. The PING and ACK frames are cryptographically protected, after mutual authentication, and therefore do not introduce an attack vector.

Operational Considerations The transports supported in , specifically SSH and TLS, are all TCP-based, which enabled the solution to rely on the full-duplex nature of TCP to tunnel thru middleboxes. But QUIC is UDP-based, and thus solution entails the server sending an initial UDP datagram instead. Whilst the effect on the client is the same (i.e., causing it to initiate a secure connection to the server), it cannot do so over a tunnel opened by the server. Thus this solution has a dependency on middleboxes recognizing and using the server's initial UDP datagram to allow the client-initiated QUIC connection. Please note that the last paragraph in says: A connection will time out if no packets are sent or received for a period longer than the time negotiated using the max_idle_timeout transport parameter; see Section 10. However, state in middleboxes might time out earlier than that. Though REQ-5 in [RFC4787] recommends a 2-minute timeout interval, experience shows that sending packets every 30 seconds is necessary to prevent the majority of middleboxes from losing state for UDP flows [GATEWAY].

IANA Considerations IANA has assigned two UDP port numbers in the "User Ports" range with the service names "netconf-ch-quic" and "restconf-ch-quic". These ports will be the default ports for NETCONF Call Home and RESTCONF Call Home when using QUIC. Below is the registration template following the rules in . Service Name: netconf-ch-quic Port Number: PORT-X Transport Protocol(s): UDP Description: NETCONF Call Home (QUIC) Assignee: IESG iesg@ietf.org Contact: IETF Chair chair@ietf.org Reference: RFC XXXX Service Name: restconf-ch-quic Port Number: PORT-Y Transport Protocol(s): UDP Description: RESTCONF Call Home (QUIC) Assignee: IESG iesg@ietf.org Contact: IETF Chair chair@ietf.org Reference: RFC XXXX

References Normative References Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK] This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client, respectively. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Fiberhome Telecom LTD./CICT. China PCL. China Mobile Viagenie Ionio Systems This document specifies how to use QUIC as a secure transport for exchanging Network Configuration Protocol (NETCONF) messages. NETCONF over QUIC allows to take advantage of QUIC streams, for example, to eliminate some TCP head-of-line blocking issues. NETCONF over QUIC provides security properties similar to NETCONF over TLS. This document also defines a YANG module which augments the ietf- netconf-client and ietf-netconf-server YANG modules. Editorial note (to be removed by the RFC Editor This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for this draft * BBBB --> the assigned RFC value for draft-ietf-netconf-netconf- client-server * CCCC --> the assigned RFC value for draft-ietf-netconf-quic- client-server The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). This document describes how Transport Layer Security (TLS) is used to secure QUIC. The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. IEEE SA-Standards Board This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry. This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered. This memo documents an Internet Best Current Practice.

Acknowledgments The author would like to thank the following for lively discussions on list and in the halls (ordered by first name): Lucas Pardu.