On Mon, 14 Apr 2003, Nickolay A. Kritsky wrote:
> Hi, folks @ freebsd-security.
>
> First, I am not sure if this is apropriate topic for that list, so
> sorry, if it is not.
I think it's the first on-topic post in years. :)
> Is it the place where synack iss is generated? If yes, then why
> net.inet.tcp.syncookies sysctl is turned on by default? Is arc4random
> not enough random? Was there another reason to `request exact RFC 1948
> compliance' by default? I am not just curious about that issue
> (although I _am_ curious :) ), but I am currnetly trying to understand
> the risks of trusted_hosts kind of security from rfc1948 point of view.
> I am not some cryptoanalyst, well to be honest I am totally new in
> cryptography, but from what I have read arc4 (or RC4 - they supposed
> to be identical) looks quite good as SPRNG given ARC4_MAXRUNS and
> ARC4_RESEED_SECONDS values are 16384 and 300s. Can anybody shed some
> light on this topic or point me to the URL to read.
>
> Any help is very good.
> ;-------------------------------------------
> ; NKritsky
Ok, I've been planning to write a little paper talking about our choices
in how FreeBSD generates sequence numbers, I guess I'll give you a quick
overview.
RFC1948 specifies that its algorithm be used for generating ISNs in
SYN-ACK and SYN packets. However, RFC1948 is flawed in that it is
_completely_ predictable for a given IP / port pair to anyone who has used
that IP. So, if we used RFC1948 for SYN-ACK generation, all you would
have to do is dialup from an AOL dynamic IP address once and connect to a
FreeBSD box. From that point on, you would be able to spoof connections
coming from that AOL dynamic IP until the box was rebooted.
So, FreeBSD does not use RFC1948 for SYN-ACK packets, only SYN packets.
Using RFC1948 for SYN packets isn't perfect, but it's an acceptable
risk.
Knowing the sequence number of a SYN may allow you to inject data and/or
reset a connection. However, looking back at the AOL dynamic IP example,
you can see that this is not an important case; any important server would
be on a static IP, so you wouldn't be able to interfere with FreeBSD ->
other server connections.
Despite 1948's shortcomings, it's the best solution for SYN usage right
now. Due to historical checks done during TIME-WAIT recycling on
server-side sockets, we have to maintain monotonicity at all times in
order to ensure that recycling works properly. (Luckily, SYN-ACK packets
have no such monotonicity requirements, despite what certain people keep
claiming.)
So, FreeBSD's sequence number generation looks like this:
SYN packets: stock RFC1948
SYN-ACK packets: arc4random or syncookies, depending on sysctl setting
Now, to answer your question about syncookies:
Yes, arc4random() generated SYN-ACK packets are more secure than
syncookies. However, syncookies exist to solve a practical problem: syn
flooding. If we tried to keep a listen queue entry for every SYN-ACK
packet we sent out, and we were being flooded with 5000 SYN-ACKs a second,
we would have to store tens of thousands of entries, which is not very
feasible.
Syncookies, on the other hand, require us to store no state, thereby
allowing us to keep the memory used during a synflood bounded. While they
do increase our susceptibility to spoofing a small amount, the tradeoff is
worth it. And, if you disagree, the sysctl is there for your use. <g>
Note that syncookies do nothing to solve the problem of network bandwidth
being used by a synflood attack; if an attacker can fill your uplink with
bogus packets, syncookies can't do much to help.
Also note that our initial syncookie implementation was flawed, and
should be patched or disabled if you're running a 4.7 or older kernel.
(See the recent security advisory for more info.)
I hope that helps your understanding of the issues involved in TCP
sequence number generation.
Mike "Silby" Silbersack