On 3/12/2015 2:23 AM, Tero Kivinen wrote:
> Joe Touch writes:
>> Although I can't disagree with your assessment of the direct discussion
>> on protecting TCP headers, the conclusion below seems to ignore the
>> discussion on "Forcing the restart of a TCPINC connection".
>
> Breaking TCP connections is active attack.
>
> There is ways we can protect against the forcing restart of the tcpinc
> connection that does not include protecting headers, but they cannot
> really prevent them, they can just convert them to full scale DoS...
I cannot make any sense of the following concurrent claims:
"protect against the forcing restart"
"cannot really prevent them,"
Either you can protect against them or you cannot.
>> I wonder how people think their solution will magically protect against
>> forced restarts if the TCP header isn't included.
>
> We cannot protect against forced restarts, but we can protect against
> downgrade attacks.
A forced restart can be used as part of a downgrade attack, but it has
other purposes, notably disrupting communications while off-path.
> I.e. using DNS (DANE) or some other method to
> signal that other end support tcpinc, and then if we actually manage
> to make first tcpinc connection to the peer, but then got tcp
> connection broken down and the next connection do not suddenly support
> tcpinc, we know something is fishy here.
That presumes all TCP endpoints sharing an IP address are identical and
use identical paths.
I.e., you could have been sent to a different endpoint (load balancing
at a server farm) that doesn't support TCPINC.
Your path to that endpoint could also have changed to go over one that
no longer supports TCPINC.
All you know is that capabilities have changed, and that can happen for
benign reasons.
> Also if the certificate / raw public key or similar changes after the
> restart, we again now something is fishy there.
You're again jumping to conclusions.
> The question is what do we do for that?
That's a downgrade or change of cert issue, which is independent of a
RST attack.
...
> Also some kind of protecting against TCP resets or FINs is possible
> even when we do not protect tcp headers. For example if we use TLS we
> might ignore FINs unless we have cleanly shut down the TLS before.
In that case, you'd be protecting the TCP connection against useful
resets too.
> For
> the resets we might send keepalive for the TCP connection instead of
> tearing it down immediately. We the keepalive confirms the connection
> is still alive, we can ignore the reset etc.
You then have to ask whether the keepalive is more important than the
reset. Wouldn't an attacker then just send a keepalive? If you don't
protect the header, you're back where you started, aren't you?
Joe
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
