TCP Extensions for Multipath Operation with Multiple Addresses
draft-ietf-mptcp-rfc6824bis-18

(1) Section 2.3.  Editorial.  s/successful reception/successful receipt/

(2) Section 5.  Thanks for mentioning the possibility of a downgrade attack in both the protocol version and algorithm negotiation.  Since [RFC7430] spells out a clear attacker taxonomy, I’d recommend using it here too (just like it was used in the new text added for the downgrade attack on the version negotiation).  

Old:
Note that this would be susceptible to bid-down attacks only if the attacker was on-path (and thus would be able to modify the data anyway).

Proposed New:
Note that this negotiation would be susceptible to a bid-down attack by an on-path active attacker who could modify the crypto capability bits response from the receiver to use a less secure crypto mechanism.

(3) Section 6.
> Intrusion Detection Systems look out for traffic patterns and
>     content that could threaten a network.  Multipath will mean that
>     such data is potentially spread, so it is more difficult for an
>      IDS to analyze the whole traffic, and potentially increases the
>      risk of false positives.

I’d recommend being a bit clearer on the impact to NIDS.  Perhaps something like the following:

Intrusion Detection/Prevention Systems (IDS/IPS) observe packet streams for patterns and content that could threaten a network.  Multipath may require the instrumentation of additional paths and correlation of data from these paths to maintain comparable visibility into all of the traffic between end-points.  Without such changes, an IDS would get an incomplete view of the traffic where by increasing the risk of missing traffic of interest and producing false positive alerts.  MPTCP-aware IDS/IPS would need to read tokens to correlate multiple subflows and reassemble them for analysis.

Thank you -- this looks like it was a bunch of work; I learnt a lot while reviewing it.

Thanks for the work everyone has put into this document and moving from v0 to v1 of MPTCP. The document is also very easy to read even with its length ;-) Congratulations!

I am also trusting my SEC AD peers about whether the fixed length of the 160-bnit HMAC/ 32-bit random number fields will still be valid in the future.


== COMMENTS ==

-- section 3.4.1 --

"for example, IPv6 addresses when it has IPv4 only" when talking about what about "an implementation MAY discard incoming address advertisements at will" but what about a device getting IPv6 connectivity after the initial connection? Or the other way round, finally getting an IPv4 address via DHCPv4 'long after' IPv6 SLAAC+ optimistic DAD are executed? I understand that this is a MAY but...


-- section 3.4.2 --

An IPv6 address can also become no more preferred as you know, so may I suggest to add this case in addition to 'interface disappears' ?

-- section 6 --

While indeed MPTCP can increase the number of false positives in IPS/IDS, I would be more concerned by false negatives (== not detecting a threat) or are we using different meanings for 'false positive' ? Perhaps worth writing in the clear 'not detecting a threat' ?

== NITS ==

--section 3.1--

the bits labelled 'A'to 'H' could have been numbered or labelled with 'meaningful' letters.

Thanks for everyone who has worked on moving MPTCP onto
the standards track. I'd like to offer particular thanks
to the authors for refraining from making structural changes
to the document: the diff between RFC 6824 and this document
is clean and easy to use.

I found only one very minor editorial nit that you may want to fix if you
need to otherwise revise the document.

§3.7:

>  So far this section has discussed the lost of MPTCP options, either

Nit: "...the loss of..."

I probably would be “Yes”, if I am to finish reading this document before the telechat.

A couple of small things:

“Appendix E.  Changes from RFC6184”

 - Did you intent to write RFC6824 here?

Section 2.4 uses “DSS”, while section 2.6 uses “DATA_SEQUENCE_SIGNAL”. If I understood correctly they are the same thing. I suggest you use consistent terminology.

I agree with Alissa that the meaning of extensibility flag (and its interaction with versionning) should be clarified.

Thanks for addressing my DISCUSS and comments.

It’s really nice to have this update; thanks for all the work on it.

— Section 8.3 —

   Initial values for this registry are give in Table 4

Make it “given”.

Also, as Specification Required includes appointment of a designated expert, it would help a lot to include some brief guidance to the expert (see RFC 8126).