Hey,

"A Technique for Counting NATted Hosts", Steven M. Bellovin
http://www.research.att.com/~smb/papers/fnat.pdf

Section IV Privacy and correctness issues suggest the following:
* The simplest case, though, is if the DF (Don't Fragment) bit is set in
the IP header of the incoming packet. In such situations, the NAT box can
rewrite the IPid field freely, since there will never be any reassembly.
* The second case is ordinary packets with DF not set. Such packets may be
fragmented by any router along the path to the destination, and hence must
carry unique IPid fields. Accordingly, a NAT should rewrite all such IPid
fields, to ensure uniqueness. A NAT that treated DF packets differently
than non-DF packets for the same protocol would thus leak the fact that at
least two different policies exist behind it. Therefore, to preserve
privacy the NAT should do the same thing - send a unique IPid field - on
all packets.
* The third case, though, is more complex, and puts an extra burden on
NATs: where already-fragmented packets arrive at the NAT, it must preserve
uniqueness while also ensuring that all fragments of the same datagram
carry the same new IPid field. Doing so requires that it keep state for
each fragment of each packet, until it determines that it has sent all
fragments of it.
* Using a random IPidfield has its own challenges to uniqueness. While
linear congruential generators have a maximal cycle length, such
generators are easily cryptanalyzed. A keyed generator, as is used in
OpenBSD and FreeBSD, provides some protection, but one needs to be careful
to avoid duplication if the generator is rekeyed periodically.

Commercial home NAT devices and IPFilter don't seem to implement this.

I guess it would be nice to implement this in PF. Perhaps in the form of a
scrub option to randomize the IPid field (comparable to TCP state
modulation). Scrub already provides all means of fragment reassembly,
needed to change the IPid of fragments belonging to each other.


Cheers,

Dries
--
Dries Schellekens
email: [EMAIL PROTECTED]

Reply via email to