[multipathtcp] Comments on threats draft

["McDonald, Andrew" <[e-mail]>]

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 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.
    (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.
    (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.)

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.
    (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.

--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) 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).

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