Re: [Masque] DNS in connect-ip

[David Schinazi <[e-mail]>]

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
>