> 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. That means preventing RST injection. > But > for most settings, just having it be relatively difficult for an off-path > attacker to DoS the connection would probably be OK, since you > have application layer mechanisms that deal with other types of > network failure anyway. Looking at the big picture, an encrypted TCP can be naturally extended to support multi-homing. If we do that, then we will regret giving misbehaving on-path agents a way to DOS a connection. In fact, it seems that the reasonable balance is to empower the endpoints of the TCP connection. Detect that an RST is not signed, and let the end point decide whether to believe it or to ignore it. Use channel binding to detect MITM, then let the application decide whether to continue using the MITM connection or not. Etc. -- Christian Huitema _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
