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

[Martin Duke <[e-mail]>]

I'm asking about these packets in the context of the MASQUE (outer)
connection.

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

>
>
> 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]> 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
>>
>>
>>
>