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

[Tommy Pauly <[e-mail]>]

> On Nov 8, 2021, at 8:43 AM, Eric Rescorla <[e-mail]> wrote:
> 
> 
> 
> On Mon, Nov 8, 2021 at 7:52 AM Tommy Pauly <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
>> On Nov 7, 2021, at 3:12 PM, Eric Rescorla <[e-mail] <mailto:[e-mail]>> 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>
> 
> I could live with that, though I do like to make it impossible to do bad things.

Okay, let’s discuss on the issue.
> 
> 
>> 
>> 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).
> 
> I would make several points here.
> 
> First, while it's desirable to be able to use the proxy's DNS cache, it's increasingly insufficient to simply get the A/AAAA records, for reasons such as SVCB. For instance, you wouldn't be able to do ECH using the DNS version alone because you would need to look up the SVCB. So, while it does incur a round trip, it seems like you are going to need to do a DNS resolution for this case.

Yes, ECH does require doing a DNS lookup, but (a) ECH may not be applicable to the type of connection I’m doing with CONNECT-IP and (b) the records for A / AAAA / HTTPS / SVCB may have different TTLs and thus have different caching benefits.

> 
> Second, even taken on its own terms, if I understand this mechanism correctly, I think it's still broken for the reason I mentioned above. The problem is that you are using the ROUTE_ADVERTISEMENT as an implicit DNS resolution--to tell you what to put in the dst-addr. If that's true, then I think you need to require that the ROUTE_ADVERTISEMENT to be strict.

Yes, I agree that the route advertisement needs to be strict if this is allowed.
> 
> 
>> 
>> 
>> 
>> 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?
> 
> "Note: peers MUST NOT blindly trust ROUTE_ADVERTISEMENT. They MUST filter it through local policy"

Hm, OK. What would “local policy” be here? I guess in the case of personal VPN, my client may expect a full tunnel, but if the server tells me I can’t route to a specific subnet (maybe it doesn’t allow 10.0.0/24, reasonably), my only recourse would be to fail the connection, not to try to send to addresses that are disallowed.

Tommy

> 
> -Ekr
> 
> 
> Best,
> Tommy
> 
>> 
>> 
>> 
>> 
>> -- 
>> Masque mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/masque <https://www.ietf.org/mailman/listinfo/masque>
> 
> -- 
> Masque mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/masque <https://www.ietf.org/mailman/listinfo/masque>