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

[Eric Rescorla <[e-mail]>]

On Mon, Nov 8, 2021 at 10:26 AM Ben Schwartz <[e-mail]> wrote:

>
>
> 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
>
>
Ironically, because of Issue #43. If you were allowed to have
dst_addr=0.0.0.0 or something, then this would work.

-Ekr