Re: Back to work

[Eric Kinnear <[e-mail]>]

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 :)