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
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
