Bodo Moeller <[email protected]> writes:
> Specifically, can we get some more clarity regarding the attack model --
> what do you expect attackers to do, and what do you expect to achieve by
> your defenses?
The attack is off-path RST injection: An attacker knows there is a TCP
connection between two IP addresses and also knows at least one of the
two port numbers. The attacker cannot drop packets between the two
hosts, but can inject packets with forged IP addresses. Hence, by
injecting RST segments, the attacker disrupts communication between the
two hosts.
> As said before, I think there'd be value in authenticating FIN. For
> everything else, I'm not that sure; I'd like to see a more coherent
> and more complete story.
Authenticating FIN and nothing else is a good option to have on the
table if there's an argument supporting it. Unlike other header fields,
FIN protection is not to hard to achieve with a proposal like Use TLS.
That's why I'd like to see this discussion re-framed as "which header
bits need protection?" rather than "should we protect the header?"
Then we can do a cost-benefit analysis.
To seed the discussion, in addition to the RST and FIN bits, here are
some other things people might or might not care about:
- Either protecting the urgent pointer and bit or specifying that
tcpinc is not compatible with urgent data (since socket APIs can be
coaxed into unexpected behavior by manipulating the urgent pointer).
- Protecting the sequence number. For example, the TCP-Minion group
is very keen on being able to decrypt and use TCP packets out of
order. Protecting the sequence number is one way for them to
achieve that goal.
- Protecting the acknowledgment number (and SACK option). The ability
to inject false acknowledgments facilitates off-path DoS attacks,
though not quite as simple as RST injection. Separately, the
ability to forge acknowledgments allows an attacker to preserve the
lifetime of encryption keys in a host's memory. (Can be addressed
with higher-layer acks or heartbeats, too.)
David
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
