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

> On Nov 7, 2021, at 3:12 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> This document seems like a reasonable starting point. Good to see
> the authors converging. Some technical comments below.

Thanks for the comments!
> 
> Overall, I wonder if we should actually forbid the client from
> using IP addresses in packets when the target is specified.
> That would avoid goofy situations in which the client does
> 
>    CONNECT 192.0.2.1
> 
> And then sends to 192.0.2.2.

I think it’s more consistent to define the behavior of what error the sender receives when it sends a packet for which it didn’t have an assigned source address or a valid destination route. Is this cause for dropping the packet silently, sending an error capsule, or closing the request stream with an error?

I filed this to discuss: https://github.com/tfpauly/draft-age-masque-connect-ip/issues/43 <https://github.com/tfpauly/draft-age-masque-connect-ip/issues/43>
> 
>         
> S 4.1.
> 
>    target:  The variable "target" contains a hostname or IP address of a
>       specific host to which the client wants to proxy packets.  If the
>       "target" variable is not specified, the client is requesting to
>       communicate with any allowable host.  If the target is an IP
>       address, the request will only support a single IP version.  If
>       the target is a hostname, the server is expected to perform DNS
>       resolution to determine which route(s) to advertise to the client.
>       The server SHOULD send a ROUTE_ADVERTISEMENT capsule that includes
>       routes for all usable resolved addresses for the requested
>       hostname.
> 
> This treatment of DNS names seems like it's going to create a lot of
> additional complexity: for instance, how does the client know which IP
> to put in the dst field. You don't specify that the
> ROUTE_ADVERTISEMENT MUST *only* include valid addresses. For instance,
> suppose that the DNS name resolves to
> 
>   192.0.2.1
>   192.0.2.2
>   192.0.2.4 <-- No 192.0.2.3!
>   192.0.2.5
>   192.0.2.6
>   192.0.2.7
> 
> and the server advertises 192.0.2.1-192.0.2.7.
> 
> 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. 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. To that end, I’d like to at least allow connecting by a hostname in the protocol (even if some proxies wouldn’t choose to support that).

> 
> 
> 
> S 4.2.
> Is the server required to send ADDRESS_ASSIGN? If not, what is the
> client supposed to use as it's source address? Also, what happens
> if you only get a v6 address but need to talk to a v4 endpoint,
> or vice versa.

https://github.com/tfpauly/draft-age-masque-connect-ip/issues/42 <https://github.com/tfpauly/draft-age-masque-connect-ip/issues/42>

Probably the best thing to say is that any peer that can send packets MUST first have received an ADDRESS_ASSIGN capsule.

Regarding v4 and v6, yes, you do need the right family assigned.

> 
> 
> S 4.2.3.
> You should probably say something here about how in many cases
> you shouldn't trust a ROUTE_ADVERTISEMENT. For instance, it's
> incoherent for an ordinary consumer VPN client to start
> advertising routes.

A full-tunnel VPN server may not have a complex routing table, but it’s still possible to have some “excluded” routes that won’t be allowed (private subnets, etc). Traditionally, most VPN protocols do always include the route information. The “trust” here is just about what the endpoint is willing to route/forward.

What kind of warning were you imagining?

Best,
Tommy

> 
> 
> 
> 
> -- 
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque