Subject: Re: [multipathtcp] Comments regarding the threat ID

From: "Khiem Le" <[email-masked]>
Date: Mon, 1 Nov 2010 11:33:27 -0500

Hello Marcelo and all,

Here are my comments on the Threats ID. I was not able to give them
earlier, as I started following this WG not long ago. Hopefully my
comments will help improve the document.

The ID is a very good analysis of the possible threats, I essentially
agree with the analysis. I also agree that we should focus on the
additional vulnerabilities of multi-path compared to single path.

The document goes beyond a pure threats analysis, as it also outlines
some possible solutions. The solutions outlined seem reasonable to me.
However, correct me if I am wrong, since the intent of this document is
not to provide a normative description of the solutions, I think it
should be stated in the Introduction (and perhaps elsewhere) that the
outlined solutions are just an illustration of possible approaches to
address the threats, but not intended to be normative. It is clear that
we haven't yet reached the stage of a finalized security solution.

Section 7, Recommendations: "The MPTCP protocol should be extensible and
it should able to accommodate multiple security solutions, in order to
enable the usage of more secure mechanisms if needed." I agree with that
principle, but I think we should also consider environments where the
threats identified are already addressed by some other security
mechanism. I propose we add a sentence like "By the same token, in
environments known to be secure enough, it should be possible to turn
off the default MPTCP security." That I believe, will increase the
chance of MPTCP being more widely adopted.

Some editorial stuff:
- Sect 7, "Recommendation", not "Reccomendation"
- " These are the so-called time-shifted attacks. Since these are not
possible in today's TCP, we will also consider them as part of the
analysis." I guess you mean these attacks are not possible in single
path TCP, but since MPTCP opens up a window of vulnerability for these
attacks, we will also consider them as part of the analysis.

Cheers,

Khiem Le

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 01 Nov 2010 17:47:13 +0100

El 01/11/10 17:33, Khiem Le escribió:
> not to provide a normative description of the solutions,

this is given, since the document is informational and as such, it 
cannot provide normative specification of any protocol or solution.
>   I think it

the description of the solution is provided to describe the residual 
threats each one has.
The intro and the abstract makes very clear that the goal of the 
document is a threat analysis and not a solution description.
> off the default MPTCP security."
i do have a problem with reccomending that security can be turn off. 
Especially, in the case of mptcp where we have a very light weight 
security that provides a very basic security.

Regards, marcelo

>   That I believe, will increase the

---

From: "Khiem Le" <[email-masked]>
Date: Mon, 1 Nov 2010 15:10:44 -0500

Hi Marcelo,

Please see my comments marked KL below.

Khiem

-----Original Message-----
From: marcelo bagnulo braun [mailto:[email-masked]] 
Sent: Monday, November 01, 2010 11:47 AM
To: Khiem Le
Cc: mptcp
Subject: Re: [multipathtcp] Comments regarding the threat ID

KL: OK!

KL: To clarify, I am not advocating a security weaker than the default MPTCP security. The cases I have in mind are those where the security needs are strong and therefore there are already security schemes in the communications stack which provide that strong security (stronger than the default MPTCP security). An example is IP Security. Actually, this is in line with the stated principle that "MPTCP should be able to accommodate multiple security solutions, to enable more secure mechanisms if needed". 

Regards, marcelo

> attacks, we will also consider them as part of the analysis.

KL: What are your thoughts about the editorial comments?