Re: [Masque] DNS in connect-ip

[Ben Schwartz <[e-mail]>]

Thanks for the context.  I think ChromeOS is an interesting example.  From the user's perspective, the distinction between Chrome and ChromeOS on the same device is generally uninteresting, and they likely wish to designate a single "VPN" for both.  This could be done by configuring the system with a connect-ip proxy, connect-udp proxy, and DoH server.  Chromium would use connect-udp and DoH directly, bypassing connect-ip entirely.  The rest of the OS would use connect-ip, and non-browser DNS queries would be tunneled into DoH via a local transparent forwarder.  (This is similar to how Chrome currently bypasses Android's transparent DoH forwarder, preferring direct DoH to the same DNS server.)

If configuration provides only a connect-ip proxy, that will result in unnecessary transfer overhead, MTU loss, and redundant congestion control.  The engineering necessary to avoid that seems straightforward, and if the standards are missing a piece for that then we should add it.
________________________________
From: David Schinazi <[e-mail]>
Sent: Tuesday, March 19, 2024 12:49 AM
To: Ben Schwartz <[e-mail]>
Cc: MASQUE <[e-mail]>
Subject: Re: [Masque] DNS in connect-ip

Hi Ben, While your proposal sounds interesting, it doesn't match how we are implementing MASQUE in practice. That's because for most implementations, the application and OS are different entities. In particular, we're deploying
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd
Hi Ben,

While your proposal sounds interesting, it doesn't match how we are implementing MASQUE in practice. That's because for most implementations, the application and OS are different entities. In particular, we're deploying CONNECT and CONNECT-UDP in Chrome, but are interested in CONNECT-IP for ChromeOS. (And I do realize that those two products have similar names and are built by the same corporate entity, but that's still how they work.) Because of the realities of the platform, we do need a "90s style" DNS configuration mechanism for the OS.

That said, I'm not saying I dislike your design - I think it's something we should also explore. But we can do that in parallel with what I'm proposing for DNS in connect-ip. One doesn't preclude the other.

Thanks,
David

On Mon, Mar 18, 2024 at 9:30 PM Ben Schwartz <[e-mail]<mailto:[e-mail]>> wrote:
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/<https://datatracker.ietf.org/doc/draft-schwartz-masque-access-descriptions/>

--Ben

________________________________
From: Masque <[e-mail]<mailto:[e-mail]>> on behalf of David Schinazi <[e-mail]<mailto:[e-mail]>>
Sent: Monday, March 18, 2024 9:29 PM
To: MASQUE <[e-mail]<mailto:[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