Re: [netconf] Re: draft-kwatsen-netconf-quic-call-home

[Kent Watsen <[e-mail]>]

Thanks Magnus. 

Some comments to ensure that I understand your idea correctly.

You mention mutual authentication, which is indeed required for the *CONF protocols, but note that client-auth MAY be via TLS client-cert or via higher-layer client auth mechanism (e.g., HTTP client auth). 

Also note that the directionality of the auth is critical, as Operators demand that it’s stable between regular and call home connections.  

My understanding is that ServerHello cannot be sent before ClientHello. 

Is your idea still a good fit?

Kent 

On Jul 29, 2026, at 4:32 AM, Magnus Westerlund <magnus.westerlund=[e-mail]> wrote:



Hi,

If I understand this correctly you are doing mutual TLS for authentication so both the *CONF client and server knows who they are expecting to talk to. The server also knows the client’s address port. So why complicating it with a new packet type rather than to just define that both *CONF clients and servers shall act as QUIC Servers, and *CONF servers MAY be QUIC clients and the *CONF client MUST be QUIC client, then after the QUIC connection is established the *CONF Client knows its role and does the *CONF procedures over the established connection?

/Magnus

From: Kent Watsen <[e-mail]>
Date: Wednesday, 29 July 2026 at 01:28
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: draft-kwatsen-netconf-quic-call-home

This short I-D extends https://datatracker.ietf.org/doc/rfc8071/" rel="nofollow"> RFC 8071 to support QUIC:

https://datatracker.ietf.org/doc/html/draft-kwatsen-netconf-quic-call-home" rel="nofollow">https://datatracker.ietf.org/doc/html/draft-kwatsen-netconf-quic-call-home

The "solution" (if it stands) is to add a single UDP datagram into the connection exchange before the standard Initial Packet.

Comments, questions, concerns?

Kent  // author of RFC 8071