Re: [Masque] DNS in connect-ip

[David Schinazi <[e-mail]>]

Having the ability to use DoH makes sense long-term. And I like the idea of
having a configuration format that can handle a proxy with all of these
features (see Tommy's proposal [1]). But in the meantime, we currently have
systems with something akin to /etc/resolv.conf, so for those it makes
sense to allow connect-ip to be a drop-in replacement for IPsec or OpenVPN.
Once we have that we can then provide further improvements like switching
DNSo53-over-connect-ip to DoH, but production systems need incremental
development steps from what they have today to where we want them to be
later.

David

[1] https://datatracker.ietf.org/doc/draft-pauly-intarea-proxy-config-pvd/

On Tue, Mar 19, 2024 at 3:16 PM Ben Schwartz <[e-mail]> wrote:

> 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]> 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/
>
> --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/
>
> 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
>
>