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

> On Mar 9, 2021, at 9:32 AM, Martin Duke <martin.h.duke@gmail.com> 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 <tpauly@apple.com <mailto:tpauly@apple.com>> wrote:
> 
> 
>> On Mar 9, 2021, at 6:35 AM, Martin Duke <martin.h.duke@gmail.com <mailto:martin.h.duke@gmail.com>> 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 <tpauly@apple.com <mailto:tpauly@apple.com>> wrote:
>> Hi Martin,
>> 
>>> On Mar 8, 2021, at 3:51 PM, Martin Duke <martin.h.duke@gmail.com <mailto:martin.h.duke@gmail.com>> 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
>> 
> 
> -- 
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque