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] 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.* 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. On Fri, Oct 30, 2020 at 8:08 PM Ian Swett <ianswett= [email protected]> 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 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 :) >> >>
