Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses
draft-ietf-mptcp-threat-08

This document does a good job of analyzing the threats for MPTCP. Thanks you.

While fully understandable, I found the text a bit wordy, with extra phrases and clauses thrown in where they really weren't needed. This document could be much more concise, and if you are doing a new revision, you might want to consider tightening up the text. But this is purely a style issue, and the authors are free to ignore this comment if they so choose.

Some examples of things that can be tightened:
"It should be noted that yada yada yada" - this implies that somebody should sometime in the future note this, but you are noting it now, so all you need is the yada yada yada without "It should be noted that".

I recommend you check any "Note that" usages; they are almost always unnecessary.

"Similarly to the MPTCP case, the Shim6 protocol is a layer 3
      protocol so all the communications involving the target address
      are at stake, as opposed to the MPTCP case, where the impact can
      be limited to a single TCP connection."
would be much more concise as simply "The Shim6 protocol is a layer 3
      protocol so all the communications involving the target address
      are at stake; in MPTCP, the impact can
      be limited to a single TCP connection."

s/behaviour of SCTP as defined/behaviour of SCTP/

I recommend checking to see if removing some of these phrases actually changes the meaning of the sentence:
s/as such//g
s/So,//g
s/As we stated earlier,//
s/In order to do that,//
s/This means that//
s/In particular//g
s/We assume that//g
s/So, at least,//
s/In addition,//
s/the so called//
s/It should be noted that/
s/In other words,//
s/namely//
s/In this case,//
s/basically//
s/This implies that//
s/It seems that/
s/It seems reasonable to assume that//
s/This per se,/This/
s/The result is that/
s/This means that//
s/This basically means that//

and some specific places:
s/In addition, we have the target of the flooding attack, target T which has an IP address IPT./
   Target T has an IP address IPT./
s/In the first step of this attack (depicted as step 1 in the figure), the attacker A/
  The attacker A/
s/the second step of the attack (depicted as step 2 in the figure)/
   the second step of the attack/
 or /step 2 of the attack/ (to align it with the figure labels)

s/The actual details of this/The details/
s/somehow more secure/more secure/
s/Similarly to the previous case,//
s/As opposed to the previous one,//
s/As we have described earlier,//

This is an excellent document and I can warmly recommend its approval. Thank you for writing it, Marcelo.

Some small comments:

In Section 3, where the document discusses differences between MIPv6 RO and MPTCP situation I had a couple of comments. First, I'm not sure I understand what you mean with the bullet about MIPv6 relying on the original path always being available. MIPv6 certainly assumes that the path that we are using at that moment is working, and if it is not, the system will attempt to move to some other address or network attachment point. Secondly, I think you are missing one additional difference: in MIPv6 we assume that there's always a trusted third party (the home agent) that can help us with some of the security problems. In MPTCP there is no such entity. You might also be missing the difference that MPTCP intends to be able to use multiple paths simultaneously, which was not an original design goal of the MIPv6 work.

In Section 6.3, the text discusses the effects of NAT on securing the implicitly reported new address. The text fails to explain that while explicit mode would allow better protection of the reported new address, such protection would be pointless because it would protect an address that is no longer relevant on the outside of the NAT. You actually *need* to report the address as changed by the NAT. And by the way, I see nothing wrong with that... that's is how current TCP works, too.

I like the basic recommendations in Section 7. But I am unsure if the analysis in the document actually supports the advanced recommendation to have optional support for HMAC. Why would that needed? Also, should the conclusions say something about how MPTCP design should deal with sequence number spaces -- it seems that different choices here would result in different impacts.