Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP)
draft-ietf-mptcp-attacks-04

I support Stephen and Benoit's discusses.  In particular, the idea that on-path eavesdroppers represent a low threat is simply not true.

For the text about spoofed source addresses not being handled by ingress filtering, this is true - but also ignores the cases where the attacker is located in, for instance, the same enterprise network site and therefore ingress filtering wouldn't be useful anyway, I believe.

I am confused about the "Threat: Medium" and "Threat: Low" labels, and I don't think they really stand on their own without further explanation. It is unclear whether what they are intended to measure is the cost, likelihood, likely impact, or ease of mitigation of each threat. Perhaps all of those factors are relevant to discuss, but as of now they aren't discussed in a systematic way across the threats and the single label per threat provides very little information about how it was derived or what it means. I would suggest either removing the labels or expanding the explanation of what they mean.

RFC 6824 has to be a normative reference, surely... doesn't it?  Is it really possible to understand this document without it?  [Authors accepted this in discussion.]

As I understand this document, it's basically updating RFC 6181 with additional threat information that has come out of the development of 6824.  The complete MPTCP threat analysis is now 6181 plus this document, yes?  So shouldn't this document be marked as "updates 6181"?  [Authors don't think so; I'm happy to leave this to the authors and AD.]

The third sentence of the Introduction has the phrase "during the design of" twice, giving it a muddied meaning.  Can you please rephrase that sentence?  [Authors accepted this.]

Thanks Stephen for taking care of my security related DISCUSS

Thanks for the DISCUSSion:-) 

-- OLD COMMENTS below, I think those have been handled
by the authors

- section 2 (and elsewhere): You have a "Threat: Medium"
here, but you don't say what you mean by "Threat." Given
that you cannot estimate any probabilities I would guess
you mean something like "impact" possibly modulated by the
difficulty of mounting the attack. I'd say it'd be good to
say what you do mean by threat, or perhaps even change to
say in this case "Impact, Difficulty : Medium, Medium" or
some such. And the same elsewhere. While there are a lot
of different ways you can do this that are equally good,
but "threat" is probably the wrong word, and whatever
word(s) you do use probably need some definition. (Which
could be via RFC4949 if you like, though that has some
ambiguities.)

- p5, s/the Linux implementation/the current Linux
implementation/ would be more accurate (and don't they
prefer GNU/Linux?)

- section 5: I can't see how the threat here is low for
any reasonable definition of threat.

- section 6 assumes that "acceptable" == "low (threat)"
That seems a bit self-serving though - is it fair really?

- 5.1: There may be cases where there is the potential to
(post-facto) detect, but not prevent, a MitM. Not sure
that it'd work for MPTCP though, given NATs mean the
endpoints can't be sure of the identifiers used, but if at
least one subflow is not NATed and if there were a DH
exchange, then it could be possible to post-facto detect a
MitM and it could be that some use-cases might be such
that the endpoints would prefer to fail the connection
rather than allow for a connection with a possibly
undetectable MitM. Or, if there are cases where it'd be
hard for the potential MitM attacker to know if NAT had
happened or not, then that might movitate the attacker to
hold off in case they are later detected.  There's lots of
speculation there though, so I'm not recommending any
particular action, but I do think it'd be worth
considering and maybe documenting later on.  Probably too
speculative to be worth a mention here though.  (And it
does depend on a DH exchange.)

- 7.1: Surely TCPINC deserves a mention here?

- The secdir review [1] also made a couple of points that
are worth a look, but hasn't gotten any response that I
can see. 

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05162.html