1. Multipath TCP Security Issues: A Request for Assistance Alan Ford (MPTCP WG)

2. MPTCP Background draft-ietf-mptcp-multiaddressed-02 Essentially, a way for multiple TCP connections (termed “subflows”) to be combined into a single MPTCP connection Appears as a regular TCP connection to the application Multiple subflows are created between different address pairs

3. MPTCP Features Uses TCP Options for signalling Subflow segments are mapped into connection-level sequence space: – Mapping of Subflow-level Sequence Number to Data-level Sequence Number

4. Creating new Subflows Now to the crux of the security problem Say a host is multi-addressed, and wants to open a new subflow from its second address to the same destination When a new TCP SYN comes in from this second address, how can the receiver know and verify which MPTCP connection it belongs to? A multi-addressed host can also signal its additional addresses to the peer

5. Threat Model draft-ietf-mptcp-threat-03 Most threats relate to hijacking: – On-path and off-path attackers – Live and time-shifted attacks – Leading to creating new subflows and injecting or intercepting data, potentially also closing existing subflows Essentially, we want to create a solution that is no worse than TCP today However, not all factors translate sufficiently well, so an appropriate goal is: ensure the hosts communicating in the new subflow setup are the same as the hosts in the initial connection setup

6. Simple (-01) Proposal Each end has a 32-bit token for the connection Tokens used as authenticators – Seen in every subflow SYN exchange – Once you know one, you can glean the other Initial Data Sequence Number set at MP_CAPABLE handshake DSNs used as blind attack security 6

7. Simple (-01) Proposal 7

8. But is this sufficient? We had concerns about attackers being able to join a connection with a time-shifted attack The Data Sequence Number would be required to be in-window for the path to be used, and we can prevent this information from being leaked – But we therefore cannot send data to newly initiated connection until it has verified it knows DSN through transmitting data: issues for unidirectional flows We started looking at a hash-based solution as an alternative

9. Hash-based (-02) Proposal Connection setup (MP_CAPABLE) exchanges keys: – SYNA->B: Option carries (K-A) – SYN/ACKB->A: Option carries (K-B) – ACKA->B: Options carry (K-A, K-B) Initial DSNs created from hashes of Keys New subflows (MP_JOIN) uses hash of Key as Token for Connection ID, plus Random Number (for replay protection), and HMACs this data using the Keys (keys never again seen in the clear): – SYNA->B:Option carries (Tok-B, R-A) – SYN/ACKB->A:Option carries (Tok-A, R-B) – ACKA->B:Payload carries: HMAC(Key=K-A|K-B, Message=R-A|R-B) – ACKB->A:Payload carries: HMAC(Key=K-B|K-A, Message=R-B|R-A) 9

10. Current (-02) Proposal 10

11. Our Questions Is this new security proposal adding anything? We are preventing time-shifted attacks being able to set up subflows in the first place – But we can have sequence-number protection against certain attacks, but this is not reliable in predictable traffic flows, and restricts some use cases – Still vulnerable if initial handshake is seen, but this is probably acceptable Or do we want something stronger? – But it needs to fit in TCP options, and not degrade user experience

12. Thank you for your time