From owner-cvs-all Thu Dec 20 12:52:27 2001 Delivered-To: cvs-all@freebsd.org Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by hub.freebsd.org (Postfix) with SMTP id 6D06437B41F for ; Thu, 20 Dec 2001 12:52:12 -0800 (PST) Received: (qmail 87998 invoked by uid 3193); 20 Dec 2001 20:52:11 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Dec 2001 20:52:11 -0000 Date: Thu, 20 Dec 2001 15:52:10 -0500 (EST) From: Mike Silbersack X-Sender: To: Jonathan Lemon Cc: , Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c In-Reply-To: <20011220143101.E26326@prism.flugsvamp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 20 Dec 2001, Jonathan Lemon wrote: > 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. MD5 is only used for outgoing syn-acks if strict rfc1948 mode is enabled (which it is not by default); normally, arc4random is used. > > 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. I'm rusty on the syncache implementation, so bear with this if it's wrong: If you're involved in being synflooded, the cache is going to be mostly full. On the other hand, if you're not being flooded, the cache will generally be mostly empty. Also, a flood is probably going to go on for a while. Hence, if the table's above a certain percent full, you could assume that you're should make cookies, because they'll be needed. Otherwise, just use arc4random(), and accept that a few connections will get dropped right when a flood starts, but that you'll be ok after that. nmap's randomness detection is majorly flawed in that it seems to try syns to different ports; it can't even tell when RFC 1948 style generation is being used. > > 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. Ah, I see now; I glanced over the code and didn't check was sc_irs was. Disregard my statement. > > 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(). Even if it's not commonly used, it should be implemented for completeness. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message