Re: [Masque] DNS in connect-ip

[Ben Schwartz <[e-mail]>]

I think this would be a good and logical design if we believe that connect-udp, DoH, DNR (RFC 9463), PvD, etc. should not be combined with connect-ip.  In that case, connect-ip needs some kind of basic 1990s-style in-band DNS bootstrap mechanism, like DHCP or IPv6 RA, resulting in things like INTERNAL_IP4_DNS in IKEv2.

I would prefer a design where these standards are combined into an integrated package, with DNS specified alongside connect-ip, connect-udp, etc.  That would allow a variety of behaviors that are difficult or impossible in this draft:

* Clients could do a DNS query, get an HTTPS record, and then choose between connect-ip and connect-udp based on the indicated ALPNs.
* DNS could use a secure transport (without the delay of a DDR upgrade and reliance on IP certificates).
* DNS queries could avoid various inefficiencies of conveyance over connect-ip.
* Clients could use connect-ip's "target" and "ipproto" fields to connect to a destination selected via DNS.
* Clients could avoid establishing a connect-ip tunnel that turns out not to be needed for any current destination.
* connect-ip and connect-udp could share a DNS configuration (which logically applies to both).
* Clients could be protected from domain hijacking by draft-ietf-add-split-horizon-authority.

Overall, I think connect-ip, connect-udp, and DNS are all building blocks for a complete access service, and we should combine them via an overarching configuration, rather than trying to extend each of them as if it were the main "entry point".  Vending a "connect-ip" template directly to a client should be viewed as an extremely low-level configuration flow, similar to manually entering an IP gateway.

Not coincidentally, this is basically the argument for https://datatracker.ietf.org/doc/draft-schwartz-masque-access-descriptions/

--Ben

________________________________
From: Masque <[e-mail]> on behalf of David Schinazi <[e-mail]>
Sent: Monday, March 18, 2024 9:29 PM
To: MASQUE <[e-mail]>
Subject: [Masque] DNS in connect-ip

Hi fellow enthusiasts, Some colleagues recently reached out to me asking about implementing connect-ip into their platform as a VPN client, next to their IKEv2/IPsec implementation. However, they rapidly found that connect-ip didn't have
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd
Hi fellow enthusiasts,

Some colleagues recently reached out to me asking about implementing connect-ip into their platform as a VPN client, next to their IKEv2/IPsec implementation. However, they rapidly found that connect-ip didn't have a way to communicate DNS servers in-band, and that's a pretty important feature that almost every VPN protocol supports. Back when we standardized connect-ip, we had decided to not put it in RFC 9484 and that we'd do it later as an extension. Now that there's implementer interest, I think it would make sense for us to work on this. So I wrote up a quick draft about this:
https://datatracker.ietf.org/doc/draft-schinazi-masque-connect-ip-dns/<https://datatracker.ietf.org/doc/draft-schinazi-masque-connect-ip-dns/>

The chairs have gracefully accepted that I present this in the as-time presents section of the agenda today. I wouldn't expect anyone to have read the draft by then, and I'll cover the overall idea in the presentation to gauge interest, but I thought I'd still post it in case someone's bored between now and the session later today.

Cheers,
David