MPTCP Protocol draft-ietf-mptcp-multiaddressed-02 Update and Open Issues

1. MPTCP Protocoldraft-ietf-mptcp-multiaddressed-02Update and Open Issues Alan Ford <alan.ford@roke.co.uk> IETF79 – Beijing

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

3. 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.

4. 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

5. 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

6. Previous (-01) Proposal

7. Previous (-01) Proposal • 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)

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

9. Current (-02) Proposal

10. 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.

11. 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?