Subject: Re: Back to work

From: Ian Swett <[email-masked]>
Date: Mon, 2 Nov 2020 07:21:04 -0500

On Sat, Oct 31, 2020 at 4:41 PM Martin Duke <[email-masked]> wrote:

> I want to carefully think through the various scenarios here, two "normal"
> ones and two attack ones. But the summary is that the proposal to always
> use the amp limit is good, if we add a coupe of more recommendations for
> clients (in bold below)
>
> 1) Normal NAT rebinding. The connection is idle for a long period. A good
> server will have reset its congestion controller due to the long idle
> period.
>
> The client then sends a packet (if the server does first, it'll probably
> disappear).  Whether or not that packet is small, the server is going to be
> limited by the amplification limit rather than congestion control. One
> alternative is to kill the connection after an idle period and restart with
> 0RTT, but that's only superior because the client has to send a bunch of
> bytes. The recommendation here, I think, is that *clients SHOULD send one
> or more full-size datagrams when restarting after a long idle period*, *and
> possibly reset its PMTU assumptions. *[I can't remember what DPDLPMTUD
> says about idle periods]
>

I'd suggest a non-normative can in this case, but I think it's worth
pointing out.

>
> If the client does this, the server will be able to validate address and
> MTU in one RTT. Otherwise, it's going to have to take two. But the
> recommendation is sufficient to mitigate the impact of the 3x limit in NAT
> rebinding cases.
>
> 2) Spoofed NAT rebinding. An attacker rewrites source addresses on someone
> else's packets, or opens a valid connection and then switches the source
> address to the victim. The amplification limit will prevent anything bad
> from happening here, then PATH_CHALLENGE will fail and we're done.
>
> 3) Normal Migration. The client suddenly changes the CIDs and source IP.
> (a) If the path is pre-validated, there is no issue. PATH_CHALLENGE and
> PATH_RESPONSE SHOULD have been padded to handle MTU and address validation
> simultaneously.
> (b) If the path is not-prevalidated, the client SHOULD pad PATH_CHALLENGE.
> This will be more restrictive than init-cwnd, unless *the client sends 3
> datagrams or so, padded pings if necessary.*
>

I think this is already a MUST pad PATH_CHALLENGE?

>
> 4) Spoofed Migration: the attacker opens a connection, then sends packets
> with new CIDs and the victim's IP. It is impossible for this to be
> pre-validated. Because the attacker has to send 1 byte for every 3 the
> victim gets, this is safe.
>
> I'll propose some text in review.
>

Besides on 1, are you suggesting any additional changes to the existing
PR?  I agree with your analysis, except I believe the client already MUST
pad PATH_CHALLENGE in these cases.

>
> On Fri, Oct 30, 2020 at 8:08 PM Ian Swett <ianswett=
> [email-masked]> wrote:
>
>> Thanks for all the awesome discussion.
>>
>> It sounds like we're landing on text that requires the 3x limit be
>> enforced until path validation succeeds, even if it's believed it's NAT
>> rebinding.  I don't think that's a huge performance hit for the reasons
>> stated above, but it does add some complexity for some implementations, so
>> I'm not sure if it'll be widely enforced or not?
>>
>> To answer Jana's question(far above) about resetting the congestion
>> controller, my thinking is the following.  In cases when the server
>> believes it's NAT migration, it does not reset the congestion controller
>> and this limits the potential attack to the congestion window built up
>> prior to the migration.  Additionally, the server has to believe it's a NAT
>> migration, which makes the attack unpredictable or useless in the presence
>> of modern NATs and Firewalls.
>>
>> So what I'd argue for is that NAT migrations MAY be treated as validated
>> paths, but the congestion controller MUST NOT be reset in that case.  I
>> think this fits what MT said their implementation currently did and what I
>> believe ours does today as well.
>>
>> Thanks, Ian
>>
>> On Thu, Oct 29, 2020 at 9:28 PM Eric Kinnear <ekinnear=
>> [email-masked]> wrote:
>>
>>> Agreed, I think that’s where the “client needs to pad PATH_CHALLENGE and
>>> any PATH_RESPONSE needs to be padded if the challenge was padded” came
>>> from.
>>>
>>> To the point about it being an error case — that totally makes sense,
>>> and as Christian points out, that is also significantly more likely under
>>> some of the attacks than someone being both idle and transferring lots of
>>> data at the same time.
>>>
>>> I’m pretty sure we did previously have text that allowed the server to
>>> treat the new address as validated if only the port changed, but we took it
>>> out to help with some of the MOTS attacks. Also fully agreed that it would
>>> be really nice to not split the logic across retaining some things (CC/RTT)
>>> some of the time, but not others (Path, MTU validation).
>>>
>>> All this said, I suspect these are all edge cases enough that the more
>>> conservative PR (as currently written) would be totally sufficient.
>>> My current feeling is that if we wanted to carve it out such that a
>>> small packet from an attacker on the side (or an unintentional migration)
>>> didn’t generate MAX(full_size_packet, 3x_what_came_in_from_the_attacker)
>>> sized packets, that would be neat, but not absolutely necessary.
>>>
>>> Thanks,
>>> Eric
>>>
>>>
>>> > On Oct 29, 2020, at 5:09 PM, Martin Thomson <[email-masked]> wrote:
>>> >
>>> > On Fri, Oct 30, 2020, at 10:42, Christian Huitema wrote:
>>> >> That means doing thing differently for a regular migration and for a
>>> NAT
>>> >> rebinding. A regular migration happens starts the client sends a full
>>> >> size packet, with a not yet seen CID, and containing a path challenge.
>>> >> Responding to that with a full size response makes sense. But if the
>>> >> server receives a short packet, with an already used CID, and without
>>> a
>>> >> path challenge, that's probably a NAT rebinding. Responding with full
>>> >> size challenge packets is counter-productive.
>>> >
>>> > Ahh, that seems sensible.  Conveniently, the current PR results in
>>> what you describe, so I have less work to do :)
>>>
>>>

---

From: Martin Duke <[email-masked]>
Date: Mon, 2 Nov 2020 07:01:00 -0800

My original proposal was for additional recommendations on (1) and (3), as
bolded.

I could live with non-normative text. My point is that these optimizations
are, IMO, extremely non-obvious and we would benefit readers to point them
out.

On Mon, Nov 2, 2020 at 4:21 AM Ian Swett <[email-masked]> wrote:

>> I want to carefully think through the various scenarios here, two
>> "normal" ones and two attack ones. But the summary is that the proposal to
>> always use the amp limit is good, if we add a coupe of more recommendations
>> for clients (in bold below)
>>
>> bytes. The recommendation here, I think, is that *clients SHOULD send
>> one or more full-size datagrams when restarting after a long idle period*,
>> *and possibly reset its PMTU assumptions. *[I can't remember what
>> DPDLPMTUD says about idle periods]
>>
>
>> 2) Spoofed NAT rebinding. An attacker rewrites source addresses on
>> someone else's packets, or opens a valid connection and then switches the
>> source address to the victim. The amplification limit will prevent anything
>> bad from happening here, then PATH_CHALLENGE will fail and we're done.
>>
>> (b) If the path is not-prevalidated, the client SHOULD pad
>> PATH_CHALLENGE. This will be more restrictive than init-cwnd, unless *the
>> client sends 3 datagrams or so, padded pings if necessary.*
>>
>
>>>> Agreed, I think that’s where the “client needs to pad PATH_CHALLENGE
>>>> and any PATH_RESPONSE needs to be padded if the challenge was padded” came
>>>> from.
>>>>
>>>> >> server receives a short packet, with an already used CID, and
>>>> without a

---

From: Ian Swett <[email-masked]>
Date: Mon, 2 Nov 2020 11:03:02 -0500

Thanks for clarifying.  I think I'd prefer non-normative, but I agree these
points are not obvious.

On Mon, Nov 2, 2020 at 10:01 AM Martin Duke <[email-masked]> wrote:

>>> 1) Normal NAT rebinding. The connection is idle for a long period. A
>>> good server will have reset its congestion controller due to the long idle
>>> period.
>>>
>>> 4) Spoofed Migration: the attacker opens a connection, then sends
>>> packets with new CIDs and the victim's IP. It is impossible for this to be
>>>> So what I'd argue for is that NAT migrations MAY be treated as
>>>> validated paths, but the congestion controller MUST NOT be reset in that
>>>> case.  I think this fits what MT said their implementation currently did
>>>> and what I believe ours does today as well.
>>>>
>>>> Thanks, Ian
>>>>
>>>>> >> That means doing thing differently for a regular migration and for
>>>>> a NAT

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 3 Nov 2020 16:40:12 +0000

Hi,

> > > > good server will have reset its congestion controller due to the long
> > > > idle period. 
> > > > 
> > > > disappear).  Whether or not that packet is small, the server is going to
> > > > be limited by the amplification limit rather than congestion control.
> > > > One alternative is to kill the connection after an idle period and
> > > > restart with 0RTT, but that's only superior because the client has to
> > > > send a bunch of bytes. The recommendation here, I think, is that clients
> > > > SHOULD send one or more full-size datagrams when restarting after a long
> > > > idle period, and possibly reset its PMTU assumptions. [I can't remember
> > > > what DPDLPMTUD says about idle periods]

I would think reseting the PMTU discovery for a NAT rebiding case would be a bit
overreaction. A NAT rebinding case would change the external port of the NAT
side, which is why the server see it as a new path. However, in most cases the
actual path will be identical between NAT and server, and the client to NAT path
should be unchanged. ECMP routing could possibly result in a different path
through some AS. However, if you deploy ECMP routing you actually have to work
with that E and ensure there are some equalness. And the DPLPMTUD should take
care of that if it doesn't work. 

What maybe one need to be a bit more careful here is not to call it "full-size"
datagram, but rather focus on that we need to ensure what DPLPMTUD will work is
to probe the minimal Maximum Packet Size for QUIC to work. Which is what Section
14.3 makes clear when DPLPMTUD is used. For DPLPMTUD it might make sense to
trigger a search after path validation of the BASE_PLPMTU. 

The point is that it is critical to verify the 1200 byte limit, then one like to
verify that previous known MTU (MPS) still works, then one can search for any
change in the MTU. And in NAT rebinding cases, both the BASE_PLPMTU and the MPS
is most likely still the same. Thus throwing away the previous knowledge of them
is unnecessary, instead verification of them in sequence makes more sense as it
avoid searching from BASE to previous working MPS. 

Cheers

Magnus

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 4 Nov 2020 08:53:31 +0000

See below.

> On 3 Nov 2020, at 16:41, Magnus Westerlund <magnus.westerlund=[email-masked]> wrote:
> 
> Hi,
> 
> 

This seems correct, the new path is likely the same in this case, and to me also there does not seem a large penalty for assuming a previously valid PLPMTU. In this respect The PLPMTU can be handled in a different way to CC, because for CC, it seems more likely that the path capacity might have changed over time.

A conservative approach would of course avoid black holes completely by resetting the MPS. I agree it would then be appropriate in that case to still retain the Size of the last PLPMTU as the initial target size to search for using DPLPMTUD (the spec does not prevent that).

Gorry