multipath-tcp / draft-ietf-mptcp-rfc6824bis Goto Github PK

(From Phil Eardley)

Section 5 - Security
This section needs updating to reflect the changes in the bis.:

Discuss the revised MP_CAPABLE
I'm not sure if the new fast close option (option R) has any security impact?
Discuss the MP_PRIO change (no off path address indication)
Discuss downgrade attacks (to v0) during connection initiation

(From Phil)

Need to add sub-sections on closing subflow & fast close & fallback

(From Phil)

Appendix D Finite state machine
I presume we don't need similar FSM for fastclose?

Something that needs fixing which Christoph and I just noticed during a chat at the IETF:

S3.7 on Fallback has
<<Note that this rule essentially prohibits the sending of data on the
third packet of an MP_CAPABLE or MP_JOIN handshake, since both that
option and a DSS cannot fit in TCP option space.>>
this needs a mod now data is allowed on the third packet.

S2.7 - I think the third bullet about notable features could be slightly altered, with enhanced security for ADD_ADDR and MP_CAPABLE. You could also add a mention of rfc7430

(From Phil)

However in Section 3.1 I think it would be good to include a more extensive figure about this - showing the different ways & timings for when the ack is known to have been delivered - ie figure showing somehow that A or B may be one that first sends data - and therefore when A knows that the ACK has indeed been successfully delivered to B.
The actual text (in the para starting " If B has data to send first, then the reliable delivery of the ACK...") is pretty good - however, there are a lot of "this packet", "this is" etc - likely that someone could misinterpret what a "this" refers to. A figure would help clarify and/or breaking the text up .

<< Note that new subflows MUST NOT be established > (using the process documented in Section 3.2) until a Data Sequence > Signal (DSS) option has been successfully received across the path > (as documented in Section 3.3).>>
In the case where A sends data first, then the MP-CAPABLE is sent instead of the DSS. Does the text quoted mean that new subflows are not allowed (until an actual DSS is sent) or are they allowed because DSS has kind of been inferred?

[phil2] the figure in S2.1 (ie in the Operation Overview section) should be modified. As it is compulsory to send the MP_CAPABLE ACK message on the first data packet. Sending MP_CAPABLE ACK without data is done if host A doesn't have data to send, but you still have to send ACK later with the first data. Whereas the natural way to interpret the current fig in S2.1 is that the Ack is sent once.