On Sat, Aug 23, 2014 at 10:41 AM, Christian Huitema <[email protected]> wrote:
> > 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? > That means preventing RST injection. See above for the consequences of this. -Ekr > 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. >
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
