On Tue, May 07, 2002 at 02:20:49AM +, Baldur Gislason wrote:
> Also, there's a kernel option:
> # RANDOM_IP_ID causes the ID field in IP packets to be randomized
> # instead of incremented by 1 with each packet generated. This
> # option closes a minor information leak which allows remote
> #
On Mon, 6 May 2002, Garrett Wollman wrote:
> < said:
>
> > Is doing this wise? I have this nagging feeling that randomizing (or
> > zeroing on each new connection) the timestamp would degrade its usefulness
> > for PAWS checks and the like. (Don't ask me how, I haven't thought it
> > through
Also, there's a kernel option:
# RANDOM_IP_ID causes the ID field in IP packets to be randomized
# instead of incremented by 1 with each packet generated. This
# option closes a minor information leak which allows remote
# observers to determine the rate of packet generation on the
# machine by w
< said:
> Is doing this wise? I have this nagging feeling that randomizing (or
> zeroing on each new connection) the timestamp would degrade its usefulness
> for PAWS checks and the like. (Don't ask me how, I haven't thought it
> through fully.)
I don't think so, because the timestamps, as cur
On Mon, 6 May 2002, Garrett Wollman wrote:
> 1) Change the RFC 1323 implementation to use ticks relative to the
> time the socket was created. This is fairly easy to do and requires
> changes to only a handful of lines of code. (Keep in mind that only
> timestamps we send over the network ough
Currently, FreeBSD's implementation of RFC 1323 uses the contents of
the `ticks' variable verbatim in the TCP timestamp options that it
generates. This is perhaps undesirable, in that it allows the system
at the other end to determine how long the system has been up.
(Current versions of `nmap' d
