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

[David Schinazi <[e-mail]>]

If I may jump in, Tommy I think you misunderstood EKR's point. EKR is
saying that in the common consumer VPN scenario it doesn't make sense for
the CLIENT to send routes to the SERVER. I think we can resolve EKR's
concern by taking this text from draft-cms-masque-connect-ip and copying it
to draft-age-masque-connect-ip:

   In theory, endpoints could use ROUTE_ADVERTISEMENT capsules to divert
   traffic from naive endpoints.  To avoid this, receivers of
   ROUTE_ADVERTISEMENT capsules MUST check their local policy before
   acting on such capsules, see Section 5.

https://datatracker.ietf.org/doc/html/draft-cms-masque-connect-ip-01#section-8

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

>
>
> 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]> wrote:
>
>>
>>
>> On Nov 7, 2021, at 3:12 PM, Eric Rescorla <[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
>>
>
> 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
>>
>> 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]
>> https://www.ietf.org/mailman/listinfo/masque
>>
>>
>> --
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque
>
>
> --
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque
>