Subject: [multipathtcp] Summary of MPTCP interim meeting

From: <[email-masked]>
Date: Fri, 4 Oct 2013 10:19:47 +0100

Thanks to everyone for joining the call yesterday. A quick summary of where I think we got to, particularly so that people not on the call can check they agree with the emerging consensus:-

The 2-prong approach is good

For prong 1 (small fixes to RFC6824 to get security exactly same as SCTP with dynamic addresses & very similar to TCP security. We believe should be sufficient to get on Standards track),

*         we fix the ADD-ADDR attack (with HMAC - same method as for JOIN);

*         we think about solving the attack that Olivier mentioned on the list yesterday;

*         we think about how to ensure future compatibility with Prong 2
on the last point, we want to make sure that MPTCP hosts will be able (optionally) to negotiate better security. This shouldn't need any major changes (there is space in the MP_CAPABLE option), but we should define now how to signal upgraded security

For prong 2, (more secure),

*         2 choices are to secure signalling better (as RFC6824 has keys in the clear on the MP_CAPABLE exchange) - or to secure data as well

*         tentative conclusion is to go for second choice (just securing signalling doesn't help because need to be compatible with NATs - and NATs change the source address therefore attacker can do same thing)

*         then two possibilities are SSL and TCPcrypt. Tend to favour TCPcrypt as secures more of the traffic

*         (side note - in this case, may want ADD_ADDR not to be HMAC'd so the middleboxes can manipulate subflows (this is OK as data is secured - for RFC6824bis we still want ADD_ADDR to be secured))

*         Pursuing TCPcrypt needs AD input - is it just wanted by mptcp or by other WGs? This affects eg whether we specify an integrated mptcp+tcpcrypt

Thanks
phil