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