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

[Martin Duke <[e-mail]>]

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.

The difference in your draft is the UDP packets are not entirely part of
the MASQUE connection anymore. 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?
4) Can they trigger address change events, or will the proxy get a new
socket to make the server handle it?

I'm sure there are several other similar questions.

On Tue, Mar 9, 2021 at 5:10 AM Tommy Pauly <[e-mail]> wrote:

> Hi Martin,
>
> On Mar 8, 2021, at 3:51 PM, Martin Duke <[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
>
> 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
>
> Best,
> Tommy
>
>
> Martin
>
>
>