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

[Magnus Westerlund <[e-mail]>]

Hi,

This was the reason I was asking about it. It might not work, but if you where using TLS level cert I don’t see how you can offer the certificates and just take into account what higher level role you expect and from that evaluate the identity provided by the peer and then restrict the higher *CONF protocol procedures accepted.

If one are using auth on *CONF level that should work without issues. As this would be in relation to the *CONF protocol messages.

I think it is something for you to consider as you anyway are defining how *CONF will function over QUIC. Then you could think about if you just can handle the process reversal that the QUIC server is the one acting as *CONF client. One might even consider if the ALPN here could be used such that a *CONF client in its QUIC server only accepts if it gets *CONF client ALPN. Thus making clear which direction the *CONF messages will be handled. This would also make it clear that when the *CONF server initiates a QUIC connection it makes clear that it is for this purpose of asking the client to talk to it.

Cheers

Magnus

From: Kent Watsen <[e-mail]>
Date: Wednesday, 29 July 2026 at 12:08
To: Magnus Westerlund <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [netconf] Re: draft-kwatsen-netconf-quic-call-home

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 RFC 8071<https://datatracker.ietf.org/doc/rfc8071/> to support QUIC:

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