Subject: Re: [multipathtcp] Comments on threats draft

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 01 Oct 2010 16:31:02 +0200

Hi Andrew,

sorry for the delay and thanks for the comments

replies below

El 21/09/10 13:01, McDonald, Andrew escribió:
> Hi Marcelo (& all),
>
> I've been reading the MPTCP Threat Analysis draft 
> (draft-ietf-mptcp-threat-02), and wanted to provide some 
> feedback/comments.
>
> Sections 5 and 6 provide a nice, detailed work through of the key 
> problem scenarios faced by MPTCP.
>
> One problem that is not currently mentioned, but has been discussed 
> recently on the list, is SYN flooding and the need to support 
> countermeasures for this (e.g. SYN cookies). In the context of MPTCP 
> it is relevant to note that this applies primarily to the initial 
> handshake - for subsequent 'join' handshakes the receiving end will 
> already have the relevant connection state if the SYN is valid 
> (assuming appropriate identifiers in the SYN), and so can reject the 
> connection if this state does not exist.

the thing here is why this is different from the normal TCP case?
I mean, the goal of the draft is to identify threats introduced by MPTCP 
(compared to TCP) and i am not sure this is the case.
>
> The draft currently steps straight from discussion of attacks to 
> recommendations on solutions. I think it would be helpful to insert a 
> summary of security requirements before this. This would, hopefully, 
> provide a checklist against which we could evaluate the security 
> solutions being proposed.
>
> A suggestion for this section would be:
>
> --x--x--
>
> Security Requirements
>
> From the analysis of threats, we can identify some key requirements 
> for the security components of MPTCP:
> 1) Verify that the address received in requests to add/remove a 
> subflow belongs to the other endpoint.
mmm, actually, if you manage achieve this first requirement, then you 
are done!
the problem is that this is very hard to do, so we usually go for less 
ambitious goal.
Actually, to prevent hijacking we aim for a goal that would be something 
like: Make sure that the additional addresses are added by the same 
party that you initially established the communication with

>    (This is primarily motivated by the flooding attacks described in 
> section 5.)
> 2) Verify that requests to add/remove a subflow genuinely come from 
> the other endpoint.
well, the flooding attacks are more about "making sure that the guy 
receiving the traffic actually wants it)

>    (This is primarily motivated by the hijacking attacks described in 
> section 6.1.)
> 3) Verify that a request to add/remove a subflow is 'fresh', i.e., it 
> has not been time-shifted/replayed.
>    (This is primarily motivated by the time-shifting attacks described 
> in section 6.2.)
>

well, actually, this is not really a time shofted attack, but a reply 
attack, right?

actually, we are reccomending a solution that is vulnerable to time 
shifted attacks, so i am not sure we should require time shofted attack 
protection.
> Further goals should also be considered:
> 1) A man-in-the-middle should only be able to masquerade as a valid 
> endpoint if he has witnessed the entire initial handshake. Preferably 
> demonstration of knowledge of the 'current state' of the connection 
> should also be required.
again, this is contradictory with the requirement of preveting time 
shifted attacks

>    (This is based on the desire, from section 6.1, to avoid off-path 
> attackers whilst supporting the use of NATs, as discussed in section 
> 6.3, and aiming for an 'at least as good as standard TCP' level of 
> security where knowledge of endpoint addresses/ports and current 
> sequence numbers are required to hijack a connection.)
> 2) Future enhancement of the security solution should be supported. At 
> a minimum this should include support for algorithm agility for any 
> cases where cryptographic functions are used.
>

this is stated in the reccomendations.

My main problem with defining requirements is that they are very hard to 
phrase properly. This is not a requirements document but a threat 
analysis, which is food for thought when designing a solution. Agreeing 
in threats is way much easier than agreeing in requirements. I would not 
extend the scope of this document ot requirements, since we are not 
chartered to do so.

> --x--x--
>
> I'm also not totally sure about the placement of the current section 
> 6.3 on NAT considerations. I'd suggest pulling this out as a 
> subsection of a new section entitled something like "Solution 
> Constraints". NAT would be one item under this, with others being the 
> requirement for low data overhead on TCP handshake messages (because 
> of restrictions space in TCP options) 

but this doesn't really apply. I mean we could send public jeysin the 
payload, nothing prevents us from doing that.

> and the need for low computation overhead (particular at the 
> SYN-received stage, before the handshake is complete, to avoid high 
> computational requirements during high workloads).
imho this is a rat-hole. stating that some forms of crypto are heavy 
have proven to be a rat-hole many times before, so i would rather stay 
away from that, if we can.

Regards, marcelo

>
> In this section, it might also be worth noting the desire to support 
> the 'break-before-make' scenario for adding subflows, since this also 
> places significant constraints on what a security solution might look 
> like.
>
> Best regards,
>
> Andrew
>