Barney Wolff wrote:
> 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 <[EMAIL PROTECTED]> 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.
Consider that sequence number rollover is faster than you think
on a Gigabit system. 200,000 packets a second on unoptimized
firmware is not impossible, and the theoretical maximum is closer
to 1/2 million a second...
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
