Date: Wed, 25 Jul 2001 21:38:12 -0400 From: Barney Wolff <barney@databus.com> To: Sean Chittenden <sean-freebsd-arch@chittenden.org> Cc: Mike Silbersack <silby@silby.com>, Barney Wolff <barney@databus.com>, arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: TCP sequence numbers: RFC1948 patch ready for testing Message-ID: <20010725213812.A28964@tp.databus.com> In-Reply-To: <20010725173859.C65546@rand.tgd.net>; from sean-freebsd-arch@chittenden.org on Wed, Jul 25, 2001 at 05:38:59PM -0700 References: <20010725032805.A21133@tp.databus.com> <20010725185434.V35719-100000@achilles.silby.com> <20010725173859.C65546@rand.tgd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Existing sessions would not be broken by rekeying. The risk is that some new session might fail - and this can happen any time a new session with the same tuple starts shortly after an old session which spans the rekeying event ends. If it becomes possible to brute-force (or smart-sneak) reverse MD5 in less time than the life of the Universe, the right answer is to change the hash, not to rekey. You guys don't seem to want to believe RFC1948: Note that the secret cannot easily be changed on a live machine. Doing so would change the initial sequence numbers used for reincarnated connections; to maintain safety, either dead connection state must be kept or a quiet time observed for two maximum segment lifetimes after such a change. Have you asked Steve Bellovin <smb@research.att.com> whether he still stands by those words? He's not that unapproachable, despite being one of the most prominent folks in computer networking and security around. But he earned that reputation by being right, pretty close to 100% of the time. Barney On Wed, Jul 25, 2001 at 05:38:59PM -0700, Sean Chittenden wrote: > > > 2. By rekeying you risk violating the monotonicity of the isn across > > > the rekeying, which is the whole point of not just doing random isn. > > > > I'll go ahead and remove the isn_offset addition. I'm not really willing > > to remove the rekeying, though; we can't say that a faster method of brute > > force attack will not arise. Would a longer rekeying interval such as a > > day or two suffice? I'm not concerned about rekeying breaking a few > > connections given that it will only happen occasionally. > > While I agree that rekeying isn't something that should be > removed, I am concerned with your last sentence. Breaking TCP sessions > strikes me as an indicator that there needs to be some way of > configuring this. Is there any chance you could make this a tunable > variable through sysctl such as the number of seconds between rekeying? > > Along similar lines, given that rekeying can be done lazily, > would it be possible to rekey through the use of an external program > that would be called by cron? If TCP sessions are going to be dropped, > I want to be able to control, know, and plan when without giving up the > added TCP security that this patch provides. -sc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010725213812.A28964>