Olivier Bonaventure wrote this message on Tue, Aug 19, 2014 at 11:51 +0200:
> 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.
Though if the new subflow uses a different key, we'd need a way to
signal the upper layers to reauth the new channel, otherwise it'd be
a great way to MITM an authenticated connection...
> 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.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
