NETCONF Call Home and RESTCONF Call Home Using QUIC
draft-kwatsen-netconf-quic-call-home-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Kent Watsen | ||
| Last updated | 2026-07-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-kwatsen-netconf-quic-call-home-01
Network Configuration K. Watsen
Internet-Draft Watsen Networks
Updates: 8071 (if approved) 28 July 2026
Intended status: Standards Track
Expires: 29 January 2027
NETCONF Call Home and RESTCONF Call Home Using QUIC
draft-kwatsen-netconf-quic-call-home-01
Abstract
This RFC extends NETCONF Call Home and RESTCONF Call Home [RFC 8071]
to support the QUIC protocol [RFC 9000].
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."
Watsen Expires 29 January 2027 [Page 1]
Internet-Draft NC/RC Call Home Using QUIC July 2026
This Internet-Draft will expire on 29 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Applicability Statement . . . . . . . . . . . . . . . . . 3
1.2. Relation to RFC 9001 . . . . . . . . . . . . . . . . . . 3
1.3. The NETCONF/RESTCONF Convention . . . . . . . . . . . . . 4
1.4. Requirements Terminology . . . . . . . . . . . . . . . . 4
1.5. Editorial Note (To be removed by RFC Editor) . . . . . . 4
2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
3. The NETCONF or RESTCONF Client . . . . . . . . . . . . . . . 5
3.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 5
3.2. Configuration Data Model . . . . . . . . . . . . . . . . 6
4. The NETCONF or RESTCONF Server . . . . . . . . . . . . . . . 7
4.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 7
4.2. Configuration Data Model . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Operational Considerations . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
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].
Watsen Expires 29 January 2027 [Page 2]
Internet-Draft NC/RC Call Home Using QUIC July 2026
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.
Watsen Expires 29 January 2027 [Page 3]
Internet-Draft NC/RC Call Home Using QUIC July 2026
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:
Watsen Expires 29 January 2027 [Page 4]
Internet-Draft NC/RC Call Home Using QUIC July 2026
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:
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.
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.
Watsen Expires 29 January 2027 [Page 5]
Internet-Draft NC/RC Call Home Using QUIC July 2026
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.
Watsen Expires 29 January 2027 [Page 6]
Internet-Draft NC/RC Call Home Using QUIC July 2026
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.
Watsen Expires 29 January 2027 [Page 7]
Internet-Draft NC/RC Call Home Using QUIC July 2026
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.
Watsen Expires 29 January 2027 [Page 8]
Internet-Draft NC/RC Call Home Using QUIC July 2026
6. Operational Considerations
Please see the last paragram in Section 10.1.2 of [RFC9000].
7. 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 [RFC6335].
Service Name: netconf-ch-quic Port Number: PORT-X Transport
Protocol(s): UDP Description: NETCONF Call Home (QUIC) Assignee: IESG
iesg@ietf.org (mailto:iesg@ietf.org) Contact: IETF Chair
chair@ietf.org (mailto: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 (mailto:iesg@ietf.org) Contact: IETF Chair
chair@ietf.org (mailto:chair@ietf.org) Reference: RFC XXXX
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>.
Watsen Expires 29 January 2027 [Page 9]
Internet-Draft NC/RC Call Home Using QUIC July 2026
[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>.
Watsen Expires 29 January 2027 [Page 10]
Internet-Draft NC/RC Call Home Using QUIC July 2026
Acknowledgments
The author would like to thank the following for lively discussions
on list and in the halls (ordered by first name): Lucas Pardu.
Author's Address
Kent Watsen
Watsen Networks
Email: kent+ietf@watsen.net
Watsen Expires 29 January 2027 [Page 11]