Date: Thu, 20 Dec 2001 14:31:01 -0600 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Mike Silbersack <silby@silby.com> Cc: Jonathan Lemon <jlemon@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c Message-ID: <20011220143101.E26326@prism.flugsvamp.com> In-Reply-To: <Pine.BSF.4.30.0112200219160.74187-100000@niwun.pair.com> References: <200112190612.fBJ6CE264053@freefall.freebsd.org> <Pine.BSF.4.30.0112200219160.74187-100000@niwun.pair.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 20, 2001 at 02:28:42AM -0500, Mike Silbersack wrote:
>
> Hm, I have a question about this change: Isn't using md5 for every
> outgoing packet going to eat a lot of cpu time?
Not every outgoing packet, every outgoing SYN,ACK. And it is no more
heavyweight than the existing tcp_new_isn(), which uses MD5 to generate
the ISN for initial outgoing SYNs.
> I think it might be a
> more reasonable heuristic to change to md5 generation only when the syn
> cache is more than half full and use arc4random at other times; this would
> use less cpu in the common case, but provide the cookie support when it is
> needed most.
Hmm, this will break the syncookie logic; since you don't know ahead
of time which entries are going to got dropped.
> (It'd also reduce my fears that someone might try some brute
> force attacks on the cookies.)
I've been trying to brute force the cookies, and haven't been at all
successful. According to nmap (unscientific survey!), it still has:
TCP Sequence Prediction: Class=truly random
Difficulty=9999999 (Good luck!)
However, this is a valid point; even though I'm using arc4random key
material, someone might still come up with an attack that works.
> For the hash function itself... perhaps part of the seq # the other end
> has sent should be incorporated in the hash? I think that with this
> scheme, we'd get duplicate syn-acks generated by different syns.
I don't follow this. All the syncache hash function needs is a reasonable
dispersion through the hash table; we still do an exact match by examining
the syncache entries. If you mean the syncookie hash, the ISN is part of
the cookie itself.
> Also, tcp_syncookies should probably unconditionally force a change back
> to arc4random() generation when disabled, given that it also disregards
> late arriving ack cookie responses.
I did seriously consider that, but decided against it at the last minute.
Perhaps I should rethink it, given that arc4random is faster than MD5().
--
Jonathan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011220143101.E26326>