Re: [Masque] Comments on draft-Pauly-masque-quic-proxy

[Tommy Pauly <[e-mail]>]

> On Mar 9, 2021, at 6:35 AM, Martin Duke <[e-mail]> wrote:
> 
> I don't think this applies to base CONNECT-UDP. If the client changes its address, the MASQUE connection will do all the verification necessary to mitigate any attacks.

Yes, the proxy will do the validation, but it may want to reset the port to give a hint to the target to look at least like a NAT rebinding event.

> 
> The difference in your draft is the UDP packets are not entirely part of the MASQUE connection anymore.

They’re no longer tunneled, they are just forwarded, right. The proxy becomes a switch/NAT.

> In fact, it would be good to clarify to what extent they do count as part of the connection. Do they:
> 1) have (implied?) packet numbers?
> 2) if so, can they be acknowledged?
> 3) If not, how can they count against congestion control?

The packet numbers, ACKs, and congestion control are all end-to-end, and do not involve the “control” connection between the client and proxy after tunneling starts.

The forwarder still gets to rate control if it wants on a per-flow basis.

> 4) Can they trigger address change events, or will the proxy get a new socket to make the server handle it?

The proxy always is able to choose what socket to forward on, and what rate it allows for forwarding.

Tommy

> 
> I'm sure there are several other similar questions.
> 
> On Tue, Mar 9, 2021 at 5:10 AM Tommy Pauly <[e-mail] <mailto:[e-mail]>> wrote:
> Hi Martin,
> 
>> On Mar 8, 2021, at 3:51 PM, Martin Duke <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Thanks for writing this draft! I have some comments mostly focused on migration.
>> 
>> I conceptualize this design as the proxy falling back to NAT behavior after the handshake is done. If that’s correct, I suggest you take a look at the (rapidly evolving!) NAT section of the quic-managability draft.
> 
> You’re quite correct that this ends up being quite similar to some NAT considerations, or almost a client-side load balancer.
> 
>> Specifically:
>> 
>> 1) you should discuss the implications of the client receiving NEW_CONN_ID. I gather the client would have to request it from the proxy and revert to tunneling for that CID if rejected?
> 
> That is correct! It’s described a bit in section 4, but we could expand upon it:
> 
>    A client sends new CONNECT-UDP requests when it wants to start a new
>    QUIC connection to a target, when it has received a new Server
>    Connection ID for the target, and before it advertises a new Client
>    Connection ID to the target.
> 
> 
>> 
>> 2) It’s important that any address or port change by the client translate to a new UDP socket in the server direction. To do otherwise would break the path validation mechanisms that protect against a variety of attacks. To the maximum extent possible, port changes should beget port changes and address changes lead to address changes, as QUIC implementations may use this as a heuristic.
> 
> Yes, I agree, and will be adding that to the next version:
> 
> https://github.com/tfpauly/quic-proxy/issues/41 <https://github.com/tfpauly/quic-proxy/issues/41>
> 
> I do think this plays into the base CONNECT-UDP as well:
> 
> https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp/issues/42 <https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp/issues/42>
> 
> Best,
> Tommy
> 
>> 
>> Martin
>