Subject: [multipathtcp] Association hijacking attack

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 22 Nov 2010 17:29:06 +0100

Hello,

An annoying attack for multipath TCP is the association hijacking attack
described in Aura/Nikkander/Camarillo's paper.

It works as follows.

Asumme hosts A and B that have a multipath TCP connection. A's address
expires and is reallocated to attacker C. Upon reception of a TCP
segment from B, C can discover TCP and DSN sequence numbers and inject
packets (acks and data) in the mptcp flow.

C could also ensure that A stops receiving data from B. In the current
draft, the remove_addr option is not secured and addresses are indexed
by using an 8 bits integer. C could simply send a remove_addr option for
A's remaining address index without knowing A's address.

In the current specification, it is difficult for A, even if it is
multihomed, to tell B to cancel the flows using its old address. The
only option is to send a RST if A can know in advance that it will loose
its address or send a remove_addr option, but these options are not sent
reliably. Furthermore, if A is behind a NAT, sending a remove_addr
option does not help C to determine the subflow that is affected by the
loss of A's address.

To deal with this attack in the presence of NAT, we cannot simply rely
on the add_addr and remove_addr options. We'd suggest to add to each TCP
subflow a unique identifier, that is not based on IP addresses nor port
numbers as these can be modified by NATs, but contains information that
is exchanged during the establishment of each subflow. The initial
subflow must also have its own subflow identifier because one of the
communicating host might lose the address used for the initial subflow.

In the current draft, the subflow identifiers could be :
- the two keys that are exchanged during the initial flow establishement
- the two nonces that are exchanged during the establishment of a subflow

Without such subflow identifiers, we do not think that it is possible to
deal with this attack.

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

---

From: "Ford, Alan" <[email-masked]>
Date: Wed, 24 Nov 2010 09:29:57 -0000

Hi Olivier,

> described in Aura/Nikkander/Camarillo's paper.

If I understand this correctly, the threat exists because an attacker
takes over a previously valid address and is able to fake the
continuation of the TCP session (the subflow) before the victim was able
to close it?

If that is the case, then it is a very difficult special case to cope
with, since it abuses already-existing TCP sessions. And, I wonder if
trying to prevent that it going significantly beyond our "no worse than
TCP" goal? Some comments inline...

> packets (acks and data) in the mptcp flow.

This is assuming the packet also contains a DATA_ACK so it knows
(roughly) the DSN to inject back towards B, otherwise with only the
DSN_MAP it would also need to create a session towards A and inject
packets that way (essentially, a man-in-the-middle attack). It also
relies on knowing the throughput at which the other subflow is
operating, to have a reasonable chance of getting data in-window.

> A's remaining address index without knowing A's address.

Yes, but C would need to know what address index(es) to close. Sure, it
could attempt to spam all 255 possible requests, but that would be a bit
suspicious and probably relatively easy to protect against.

> option does not help C to determine the subflow that is affected by
the

Actually, that's the exactly purpose of the REMOVE_ADDR option - it
allows A to remove its lost subflow without needing to know what source
address was used. If it was able to do this before C got hold of the TCP
subflow, this attack would not exist. 

The problem with this is that some previously designed security against
attack may actually hinder this particular threat. Since we propose that
the REMOVE_ADDR ensures there is no response to a TCP keepalive before
removing the address (to ensure it's not a fake request to remove a
still-existing subflow) - but in this case, that very protection would
keep the subflow alive if C could respond to the keepalive. Hmmm!

> communicating host might lose the address used for the initial
subflow.

Well that's almost what we have with the Address IDs. What would a
subflow ID give us, over and above the Address ID?

(I had wondered about subflow IDs before and am interested to see if
they bring any new security benefits.)

> Without such subflow identifiers, we do not think that it is possible
to

The nonces probably make good subflow identifiers.

However, could you explain a bit more what extra protection this is
giving over the existing mechanism? I'm not sure I see what portions of
the protocol would change, and what benefits this would bring.

Cheers,
Alan

---

From: "McDonald, Andrew" <[email-masked]>
Date: Tue, 30 Nov 2010 15:23:51 +0000

On 24/11/2010 09:29, Ford, Alan wrote:
> TCP" goal?

This was also my thought on reading this. It seems that the basic attack 
applies to TCP, so questions that arise are:
- are the consequences worse in the MPTCP case than the normal TCP case?
- is it easier to perform than in the normal TCP case?

The main difference is that the 'victim' is continuing to use the 
connection at the same time as the attacker. Are there scenarios where 
this is an issue?

A possible one:
Let us imagine a user communicating with a webserver.
User sends "GET /login?user=myusername&password=reallysecret"
Server responds with response including "Cookie: magicstring"

One could imagine the response being sent to the 'old' address and so 
reaching the attacker.

In the simple TCP case one could imagine this as:
- Victim sends GET
- Victim loses address
- Server sends HTTP response, and then does further retransmissions 
having not received an ACK
- Attacker acquires address
- Attacker receives HTTP response
But this requires a fairly short interval between address loss and the 
attacker acquiring the address.

In the MPTCP case it might be:
- Victim loses address A
[stuff happens on connection]
- Attacker acquires address A
- Victim sends GET from address B
- Server sends HTTP response, using address A (because it's interface 
selection algorithm thinks that would be a good idea)
- Attacker receives HTTP response

So, MPTCP could be regarded as 'worse' because it allows for a longer 
interval between address loss and acquisition. (Depending on what the 
definition of 'worse' is.)

If the 'victim' could do a proactive "remove address", as Alan suggests, 
this would mitigate this by reducing the interval over which the attack 
is possible. (But mechanisms to avoid the attacker making use of the 
"remove address" would need to be considered.)

regards,

Andrew