Re: [Masque] Comments on draft-age-masque-connect-ip-01

[Ben Schwartz <[e-mail]>]

On Mon, Nov 8, 2021 at 10:52 AM Tommy Pauly <tpauly=
[e-mail]> wrote:

>
>
> On Nov 7, 2021, at 3:12 PM, Eric Rescorla <[e-mail]> wrote:
>
> ...

>
> Given that this is an IP layer mechanism, I would simply remove the
> DNS option; clients can always do DNS over the tunnel.
>
>
>
> I can see this either way.
>
> For cases where I don’t want a full tunnel, but just want to talk to one
> host, I would need to open an IP flow for a DNS server. I could of course
> open one, and then open a proxied flow to each target address, and request
> the same local address I got on the first.
>
> This would work, but is more back-and-forth, and also doesn’t give me a
> way to just ask the proxy to use it’s own DNS cache.
>

I think we need to be clear about what the alternatives are.  Suppose we
compare

A. CONNECT-IP supports DNS names. [current draft]
B. CONNECT-IP doesn't support hostnames but is co-located with a DoH server.

Then either way, the client benefits from a DNS cache at the proxy.


> For cases like CONNECT and CONNECT-UDP, we’ve found it very useful for
> latency to have the DNS cache run on the proxy, so that we benefit from all
> clients going through the proxy sharing the same cache, and not needing a
> round trip back to the client.
>

That benefit does not apply to CONNECT-IP, because the client must specify
an IP address, but it doesn't know what IP address to specify.  It
therefore has to wait the same full roundtrip anyway.  Compare

A.
 - [C->S] CONNECT-IP https://proxy.example/ip?target_host=target.example.com
 - [S->C] 200 OK, ROUTE_ADVERTISEMENT [192.0.2.1]
 - [C->S] IP Packet to 192.0.2.1

B.
 - [C->S] GET https://proxy.example/dns-query?dns=<target.example.com>
 - [S->C] 200 OK, <DNS Answer: 192.0.2.1>
 - [C->S] CONNECT-IP https://proxy.example/ip?target_host=192.0.2.1
 - [C->S] IP Packet to 192.0.2.1 (False Start)

CONNECT (TCP) and CONNECT-UDP are different.  TCP allows the server to act
on the resolved address without having to return it to the client.
CONNECT-UDP allows false-start with hostname targets (although CONNECT-UDP
with hostname targets is pretty crummy: it breaks failover, Happy Eyeballs,
etc.).

To that end, I’d like to at least *allow* connecting by a hostname in the
> protocol
>

I don't object to this functionality, but I don't think it is a performance
optimization.


> (even if some proxies wouldn’t choose to support that).
>

I don't think it can be optional.  If it's optional, it might as well not
be mentioned at all, since clients can't rely on it.