1

MPTCP Protocoldraft-ietf-mptcp-multiaddressed-02

Update 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/ACKB->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/ACKB->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?