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

From: Martin Duke <[email-masked]>
Date: Mon, 8 Mar 2021 15:51:24 -0800

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.
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?

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.

Martin

---

From: Ian Swett <[email-masked]>
Date: Mon, 8 Mar 2021 20:33:03 -0500

On Mon, Mar 8, 2021 at 6:51 PM Martin Duke <[email-masked]> wrote:

> 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.
> 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?
>

Can you outline the issue/attack that you're concerned about on this second
point?  Allowing a change of address without validation exposes a variety
of issues.  I'm not sure what issues hiding a change of port or address
creates?  I agree that if there is to be a change, it'd be ideal to have
port beget port change and address beget address changes.

> Martin
> --
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque
>

---

From: Martin Duke <[email-masked]>
Date: Mon, 8 Mar 2021 18:12:25 -0800

21.1.3 of quic-transport is the definitive source, but briefly, an attacker
could rewrite the source address of client packets mid-connection. As the
proxy has no explicit means of validating this, and the server isn't aware,
this could result in a large amount of traffic sent to a victim.

Alternately, one could instead make it clear that these packets are in all
respects part of the MASQUE connection and all address change requirements
are still in effect. Either would work.

On Mon, Mar 8, 2021, 17:33 Ian Swett <[email-masked]> wrote:

> Can you outline the issue/attack that you're concerned about on this
> second point?  Allowing a change of address without validation exposes a
> variety of issues.  I'm not sure what issues hiding a change of port or
> address creates?  I agree that if there is to be a change, it'd be ideal to
> have port beget port change and address beget address changes.
>
>
>> Martin
>> --
>> Masque mailing list
>> [email-masked]

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 09 Mar 2021 05:10:05 -0800

Hi Martin,

> On Mar 8, 2021, at 3:51 PM, Martin Duke <[email-masked]> 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

---

From: Martin Duke <[email-masked]>
Date: Tue, 9 Mar 2021 06:35:33 -0800

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 <[email-masked]> wrote:

> You’re quite correct that this ends up being quite similar to some NAT
> considerations, or almost a client-side load balancer.
>
> Specifically:
>
> https://github.com/tfpauly/quic-proxy/issues/41
>
> https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp/issues/42
>
> Best,
> Tommy
>
>
> Martin
>
>
>

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 09 Mar 2021 09:26:49 -0800

> On Mar 9, 2021, at 6:35 AM, Martin Duke <[email-masked]> 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:

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

> On Tue, Mar 9, 2021 at 5:10 AM Tommy Pauly <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Martin,
> 
>> On Mar 8, 2021, at 3:51 PM, Martin Duke <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Martin Duke <[email-masked]>
Date: Tue, 9 Mar 2021 09:32:41 -0800

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 <[email-masked]> wrote:

> 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 MASQUE connection anymore.
>
>
> 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.
>

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 09 Mar 2021 09:41:40 -0800

> On Mar 9, 2021, at 9:32 AM, Martin Duke <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On Mar 9, 2021, at 6:35 AM, Martin Duke <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Martin Duke <[email-masked]>
Date: Tue, 9 Mar 2021 09:48:55 -0800

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 <[email-masked]> wrote:

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