Subject: [tcpinc] Forcing the restart of a TCPINC connection

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 10 Feb 2015 11:52:15 +0100

Hi,

In the context of the discussion about protecting or not the TCP 
headers, i was considering the following case.

Consider that A and B have an established TCPINC connection with a 
TCPINC solution that does not protect the TCP header.
Now C would like to eavesdrop the connection, but unfortunately for him, 
the payload is encrypted.
C decides then to send a FIN (or a RST) with the expectation to force 
the restart of the connection.

Now, there are two possible way forward for C's attack:

- Option 1) when A restarts the connection, C simply removes the TCPINC 
options, forcing the connection to fall back to regular TCP, so it can 
eavesdrop it.
This would allow an attacker to cherry-pick which connection to 
eavesdrop, even when protected with TCPINC. (I guess a solution for this 
is to establish a policy in the endpoints that if a previous connection 
with a given endpoint was TCPINC, then only allow TCPINC connections in 
the future. This may be a problem for mobile endpoints, where different 
access networks may have different filters).

- Option 2) when A restarts the connection, A performs the key exchange 
again, so C can act as a Man in the Middle (changing the keys and all) 
and eavesdrop the connection. I guess this really depends whether it 
will be normal to perform the key exchange again. I guess this depends 
on who restarts the connection. I mean if the user was downloading a 
file and the user himself clicks reload, maybe a new TCP connection 
(with a different ephemeral port) is reloaded and keys are exchanged 
again and C can have its way. I am not very sure how this would pay out, 
actually.

C can even combine 1) and 2) i.e. if he can tell in the new SYN if the 
old key will be reused, he can use option 1) and if the key wont be 
reused it can do option 2).

Is this a concern? Am i missing something?
Regards, marcelo

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Feb 2015 16:04:39 +1100

On 10 February 2015 at 21:52, marcelo bagnulo braun <[email-masked]> wrote:
> C decides then to send a FIN (or a RST) with the expectation to force the
> restart of the connection.

Unless peers are authenticated somehow, or peers are able to make some
sort of commitment to a key, then this seems like a plausible attack.
I guess that it falls under the "active" umbrella though.