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

[Martin Duke <[e-mail]>]

Cool. That ought to be clarified in the draft, and now the proxy definitely
needs to open a new UDP socket in the server direction when the client
address/port changes.

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

>
> On Mar 9, 2021, at 9:32 AM, Martin Duke <[e-mail]> wrote:
>
> I'm asking about these packets in the context of the MASQUE (outer)
> connection.
>
>
> Understood; packets that are not being tunneled have no relationship to
> the “control" MASQUE connection at all.
>
> Tommy
>
>
> 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
>>>
>>>
>>>
>> --
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque
>
>
>