Multipath TCP Security Issues: A Request for Assistance

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

7. Simple (-01) Proposal

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: • SYN A->B: Option carries (K-A) • SYN/ACK B->A: Option carries (K-B) • ACK A->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): • SYN A->B: Option carries (Tok-B, R-A) • SYN/ACK B->A: Option carries (Tok-A, R-B) • ACK A->B: Payload carries: HMAC(Key=K-A|K-B, Message=R-A|R-B) • ACK B->A: Payload carries:HMAC(Key=K-B|K-A, Message=R-B|R-A)

10. Current (-02) Proposal

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