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

[Ballot comment]

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

[Ballot comment]
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.]

[Ballot comment]
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.

[Ballot discuss]
Me filing a security-related DISCUSS, I'm surprised myself :-)
Briefly chatting about the issue with Stephen Farrell, discovered by Stefan Winter part of his OPS-DIR review, he advised me to file a DISCUSS about this issue. I expect the Security ADs to follow up on this one.

From an OPS-DIR perspective, the document is Ready with very minor nits.
From a security perspective, IMHO not so.

The following are comments from my individual perspective, which I hope can be considered even though being so late.

The document readily admits that an attacker who can eavesdrop parts of the connection can hijack and MitM the connection to his liking. The document states in section 5 that:

  "This vulnerability was readily identified at
  the moment of the design of the MPTCP security solution and the
  threat was considered acceptable."

I believe the design of MPTCP predates the IETF's "perpass" considerations and did not take into account that pervasive passive attacks are possible and are being conducted at large scale on the internet on a day-to-day basis. The -attacks document now provides an easy-to-follow recipe to mount the attack, with the only prerequisite being that TCP headers can be inspected by an attacker.

MPTCP itself and its security implications need to be revisited (which is happening in the -bis document; I strongly hope that this is one of the parts which do get fixed). The suggested mitigations 1 and 2 in section 3.1 of the -attacks draft do not help in this scenario, because the additional information can be trivially eavesdropped. Mitigation 3 seems to prevent it, but is not the recommended one. In my understanding, none of the three are part of the actual protocol anyway. Does the mptcp-bis document go towards that mitigation 3, or did it find another way to prevent the described elevation from pervasive passive to off-path active MitM?

From my understanding, the recommendation in section 7 does not point towards that (best) mitigation nr. 3, which I find unacceptable as a recommendation for a standards-track-to-be.

The draft in its current state does not discuss perpass-style scenarios in the ADD_ADDR attack and their consequences in an adequate manner, and inappropriately classifies ADD_ADDR as a "medium" threat. From a security perspective, I would not find the document satisfactory and would like to see it revised.

[Ballot comment]
The following NITs are in the document:

Section 3
---------
SYN-flod -> SYN-flood
on-time attacker -> on-path attacker (?)
Section 7
---------
The caption of section 7 has a typo: Reccomendation -> Recommendation

[Ballot comment]
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.

[Ballot discuss]

Generalising from the discuss text posted eariler:

In what sense is the list of 5 attacks here complete? If
this list is not complete, then on what basis were these
attacks selected? I think you need to say. There is a real
danger that we only document (and mitigate) attacks that
we find interesting or have a plan for mitigation, so I'd
like to know how this list was arrived at.

[Ballot comment]

- 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

[Ballot discuss]

This is an 'early' discuss - I've not finished reading the
doc, but if the authors can respond quickly that might help
us all avoid doing unnecessary work:-) I'll update the
ballot later in any case, but in the meantime...

(1) intro, types of attacker: I don't get why an (on path)
eavesdropper cannot delete or delay packets - it seems to me
that this misses a specific kind of attacker who is passive
crypto-wise, but who can in fact delete or delay packets. I
think you need to specifically justify not factoring that
specific type of attacker out in the analysis as one that is
different from one that can only observe. Why is it ok for
that to be missing and did the WG discuss that?

[Ballot discuss]
I have two very simple points I'd like to discuss, please:

1. RFC 6824 has to be a normative reference, surely... doesn't it?  Is it really possible to understand this document without it?

2. 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"?

[Ballot comment]
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?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mptcp-attacks-02, which is currently in Last Call, and has the following comments:

We understand that,  upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Analysis of MPTCP residual threats and possible fixes) to Informational RFC


The IESG has received a request from the Multipath TCP WG (mptcp) to
consider the following document:
- 'Analysis of MPTCP residual threats and possible fixes'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-10-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This documents performs an analysis of the residual threats for MPTCP
  and explores possible solutions to them.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mptcp-attacks/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mptcp-attacks/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

  The intended status is Informational.
  This document provides information for possible security threats in MPTCP and provides some guidances for them.
  I believe Informational is appropriate status for the document.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This document describes an analysis for residual security threats in MPTCP spec and provides some guidances for them.
  The information in the document is used for updating the current MPTCP spec and discussions for future direction of MPTCP developments.

Working Group Summary:

  The analysis and guidances provided by this documents has been discussed in the WG. The problems in MPTCP pointed out by the document have already been addressed in RFC6824bis draft (draft-ietf-mptcp-rfc6824bis). The guidances in the document has also been used for discussions in the WG for future security enhancements of MPTCP.
  The consensus for this document was clear because of the usefulness of the document.

Document Quality:

  The document has been reviewed and discussed by multiple participants in the WG.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Yoshifumi Nishida is the Document Shepherd for this document.
  The Responsible Area Director is Martin Stiemerling

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

  I've reviewed the documents and made several editorial suggestions.
  I believe the quality of this draft is mature enough to be published.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

  I have no concern about it.
 
(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

  There is no need for particular reviews.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

  I have no concerns with the document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

  Yes. Each author has confirmed.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

  No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

  The analysis and guidances in the document were supported in the WG meetings as well as the ML.
  The consensus was solid and clear.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

  No one has indicated discontent.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  No issue was found by idnits 2.13.01

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

  I believe no formal review is needed.

(13) Have all references within this document been identified as either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
 
  No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

  The document does not involve any IANA considerations.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

  There is no need to require expert review for future allocations.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

  The document contains no formal language.