MPTCP Protocol draft-ietf-mptcp-multiaddressed-02 Update and Open Issues Alan Ford IETF79 – Beijing 1

Changes since -01 Subflow policy control DSN_MAP checksum Security proposal Various editorial fixes 2

Receiver Subflow Policy Control Previously, sender was in full control – no way of receiver signalling preferences of paths. –E.g. for varying monetary costs of paths. Overloading ECN signal was not welcomed. So, we have added a flag to MP_JOIN and ADD_ADDR to identify a subflow as “backup”. Signals to other peer only to send traffic on this subflow if no non-backups are available. New MP_PRIO option to change this during the lifetime of a subflow. 3

DSN_MAP Checksum DSN_MAP provides mapping between subflow and connection-level sequence spaces A checksum is needed to detect if middlebox has changed data on subflow, since this could break sequence numbering alignment Previous proposals: – CRC-32: too expensive – Copying first/last bytes: too unreliable Now using TCP checksum algorithm over data Lightweight, suitable for our needs, and can be combined with segment checksumming 4

Security We need to mitigate against the identified threats: hijacking and flooding attacks We need a security mechanism at subflow initiation to ensure: – That the new subflow does belong as part of the MPTCP connection – i.e. the two hosts at each end of the new MPTCP subflow are the same as those at the start of the MPTCP connection 5

Previous (-01) Proposal 6

Each end has a 32-bit token Tokens used as authenticators – Seen in every subflow SYN exchange – Once you know one, you can glean the other IDSN set at MP_CAPABLE handshake DSNs used as blind attack security – Need heuristics for dropping subflows; do not send DATA_ACK until DSN_MAP seen Not stateless (but could echo tokens in ACK) 7

Current (-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) 8

Current (-02) Proposal 9

Suitable? What is “good enough”? We want something no worse than TCP. Over and above the previous proposal, in this hash-based security, the only vulnerable point is the initial subflow SYN exchange – all other subflow establishment is protected. It protects against the threats and meets the recommendations in draft-ietf-mptcp-threat-03. But it involves more complexity, including using the initial two packets of payload. Is it accepted that the previous proposal was insufficiently secure? Sufficient key/token lengths in the new proposal? Are there other options out there we could re-use? E.g. adaptations of TCP-AO? Flags for agility can be deployed in MP_CAPABLE. 10

Any other open issues? “Lightweight MPTCP” – Demand for optional components for trusted environments, e.g. checksums, security? – Or leave to implementation? Implementations are ongoing… – Wide-scale testing will help to identify any unexpected issues, and help to develop behavioural heuristics Do things seem sound for now? 11