Christian,
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.
I agree with you but instead of extending an encrypted TCP to support
multihoming, we could extend Multipath TCP to support encryption.
Looking at the RST attack which is currently discussed, Multipath TCP
already provides a solution to cope with this attack. Since Multipath
TCP supports make before break and break before make, the reception of a
RST on a subflow (even if there is only one subflow) would terminate
this subflow but not the Multipath TCP connection. A Multipath TCP host
that receives a RST can simply recreate a new subflow and the connection
(as seen from the application) would continue. The reception of the RST
would cause a small interruption of the dataflow (during the
reestablishment of one subflow), but this is similar to classical
retransmissions for packet losses. This works for TLS, SSH, BGP or
whatever application runs above Multipath TCP.
Although this WG was chartered to extend regular TCP and not Multipath
TCP, I think that Multipath TCP already contains several mechanisms
(subflow management, middlebox interference, data sequence numbers
notably) that will be very useful for any TCPinc proposal.
Olivier
--
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
