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