NETCONF Call Home and RESTCONF Call Home Using QUIC

Internet-Draft	NC/RC Call Home Using QUIC	July 2026
Watsen	Expires 29 January 2027	[Page]

About This Document

This note is to be removed before publishing as an RFC.¶

The latest revision of this draft can be found at https://kwatsen.github.io/quic-call-home/draft-kwatsen-netconf-quic-call-home.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-kwatsen-netconf-quic-call-home/.¶

Discussion of this document takes place on the Network Configuration Working Group mailing list (mailto:netconf@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/netconf/. Subscribe at https://www.ietf.org/mailman/listinfo/netconf/.¶

Source for this draft and an issue tracker can be found at https://github.com/kwatsen/quic-call-home.¶

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 29 January 2027.¶

1. Introduction

This RFC extends NETCONF Call Home and RESTCONF Call Home [RFC8071] to support the QUIC protocol [RFC9000].¶

RESTCONF [RFC8040] supports QUIC with its implicit support for HTTP/3 [RFC9114]. NETCONF [RFC6241] supports QUIC with [I-D.ietf-netconf-over-quic].¶

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.¶

1.1. Applicability Statement

The techniques described in this document are suitable for network management scenarios such as the ones described in Section 1.1 of [RFC8071]. 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 Section 2.2 of [RFC6241], and for the RESTCONF protocol in Sections 2.4 and 2.5 of [RFC8040].¶

This contrasts with the base QUIC protocol, which does not require programmatic verification of the other party, e.g., in Section 2.1 of [RFC9001] 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 Section 5.¶

1.2. Relation to RFC 9001

This document uses the QUIC [RFC9001] with the exception that the statement "The client initiates the exchange and the server responds" made in Section 2.1 of [RFC9001] 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 Section 5.¶

1.3. 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.¶

1.4. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

1.5. Editorial Note (To be removed by RFC Editor)

This section is to be removed before publishing as an RFC.¶

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)¶

2. Solution Overview

The diagram below illustrates call home from a protocol layering perspective:¶

         NETCONF/RESTCONF                    NETCONF/RESTCONF
              Server                              Client
                |                                    |
                |         1. UDO                     |
                |----------------------------------->|
                |                                    |
                |                                    |
                |         2. QUIC                    |
                |<-----------------------------------|
                |                                    |
                |                                    |
                |         3. NETCONF/RESTCONF        |
                |<-----------------------------------|
                |                                    |

               Note: arrows point from the "client" to
                 the "server" at each protocol layer

This diagram makes the following points:¶

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

3. The NETCONF or RESTCONF Client

The term "client" is defined in Section 1.1 of [RFC6241] and Section 1.1.5 of [RFC8040]. In the context of network management, the NETCONF/RESTCONF client might be a network management system.¶

3.1. 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 Section 7, 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 [RFC9000] 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" [RFC6125] 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 [Std-802.1AR-2009] 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 [RFC6241] or RESTCONF-client [RFC8040] 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.¶

3.2. 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 [RFC7950] modules for configuring a NETCONF and RESTCONF clients, including call home, are provided in {{RFC10010}} and {{RFC10011}} respectively.¶

4. The NETCONF or RESTCONF Server

The term "server" is defined in Section 1.1 of [RFC6241] and Section 1.1.5 of [RFC8040]. In the context of network management, the NETCONF/RESTCONF server might be a network element or a device.¶

4.1. 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 Section 7, 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 Section 4.4.2. of [RFC8646].¶

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 [I-D.ietf-netconf-over-quic] and [RFC8040] 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 Section 19.2 of [RFC9000], and ensure an ACK Frame Section 19.3 of [RFC9000] 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.¶

4.2. 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 [RFC7950] modules for configuring NETCONF and RESTCONF servers, including call home, are provided in {{RFC10010}} and {{RFC10011}} respectively.¶

5. Security Considerations

The solution in this document extends [RFC8071] to support call home using QUIC [RFC9000] for the NETCONF and RESTCONF protocols, [I-D.ietf-netconf-over-quic] and [RFC8040] 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 Section 5 of [RFC8071].¶

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.¶

8. References

8.1. Normative References

[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6125]: Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/rfc/rfc6125>.
[RFC6520]: Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, DOI 10.17487/RFC6520, February 2012, <https://www.rfc-editor.org/rfc/rfc6520>.
[RFC8071]: Watsen, K., "NETCONF Call Home and RESTCONF Call Home", RFC 8071, DOI 10.17487/RFC8071, February 2017, <https://www.rfc-editor.org/rfc/rfc8071>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8646]: "Not Issued", RFC 8646, <https://www.rfc-editor.org/rfc/rfc8646>.
[RFC9000]: Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/rfc/rfc9000>.

8.2. Informative References

[I-D.ietf-netconf-over-quic]: Dai, J., Yu, S., Cheng, W., Blanchet, M., and P. Andersson, "NETCONF over QUIC", Work in Progress, Internet-Draft, draft-ietf-netconf-over-quic-09, 27 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-over-quic-09>.
[RFC6241]: Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/rfc/rfc6241>.
[RFC7950]: Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/rfc/rfc7950>.
[RFC8040]: Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/rfc/rfc8040>.
[RFC9001]: Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/rfc/rfc9001>.
[RFC9114]: Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.
[Std-802.1AR-2009]: IEEE SA-Standards Board, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", December 2009, <http://standards.ieee.org/findstds/standard/802.1AR-2009.html>.