>>> Stepping up a level, it seems important to figure out what we are >>> trying to achieve with DoS prevention. An on-path attacker can just >>> suppress tcpinc negotiation or block packets until the TCP state >>> machine gives up. So, this mostly applies to off-path attackers? >> >> Actually, we already have evidence of "listen in the middle, inject from >> the side." It would be nice to protect against such attacks. > > Can you be a bit more explicit about what you are referring to here?
Referring to the QUANTUM attacks (http://www.wired.com/2014/03/quantum/, https://www.techdirt.com/articles/20131004/10522324753/how-nsa-pulls-off-man-in-the-middle-attacks-with-help-telcos.shtml). >> That means preventing RST injection. > > See above for the consequences of this. I think that by now, we all understand the tradeoff. If we want to prevent illegitimate RST attacks, we will also prevent use of unprotected RST by rebooting hosts. Which is why I believe the protocol should be able to differentiate between protected RST, which should be processed immediately, and unprotected RST, which should be treated according to host policy. -- Christian Huitema _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
