On Thu, Aug 21, 2014 at 02:53:15PM -0700, John-Mark Gurney wrote: > Olivier Bonaventure wrote this message on Tue, Aug 19, 2014 at 11:51 +0200: > > 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...
Oh, if there's any way to bind the first to the previous then there's no problem, otherwise, yes, there's a problem. Since we're assuming (right?) that neither endpoint has crashed/rebooted yet, it seems fair to mix in the previous flow's session keys into the new flow's session key derivation, which cures the problem. (Just as in TLS renego (since it was fixed) and SSHv2 renego.) Make before or after break makes no difference, as long as the previous flow's TCB is still around. > > 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. Well, presumably it's enough to say that TCPinc should work with Multipath TCP. No? Nico -- _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
