Re: Back to work

[Ian Swett <[e-mail]>]

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 <[e-mail]> wrote:

> 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 <[e-mail]> wrote:
>
>>
>>
>> On Sat, Oct 31, 2020 at 4:41 PM Martin Duke <[e-mail]>
>> 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=
>>> [e-mail]> 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=
>>>> [e-mail]> 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 <[e-mail]>
>>>>> 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 :)
>>>>>
>>>>>