"Luck, Tony" <tony.luck@intel.com> writes:
> The fact that someone can deduce how many hosts are hidden behind
> a NAT gateway may, or may not, be a bug ... depending on whether you
> think that the NAT is supposed to keep this number a secret. But there
> is a real bug here too. Suppose you have two hosts behind your NAT
> that both have connections to the same host out in internet-land. And
> further suppose that both those hosts have the same value for their
> incrementing counter that they use for IPID. And finally suppose that
> they both send a fragmented packet to the same port on the same host.
It's fighting an already lost battle. 16bit ipid space is far too small
to do any rewriting tricks. You just don't have enough space to
space them out enough, especially when there is latency in the network.
>
> If your NAT router isn't re-writing the IPID, can't the target host get
> confused when it sees two fragments that have a source address from your
> NAT machine, that have the same IPID ... but really don't belong together?
Just do it without NAT on Gigabit with small packets. The ipids wrap
so fast you get data corruption very quickly. Most of it is catched
by the UDP checksum, but not everything. You can work around it by
setting the ip defragment timeout very short, but that makes it unusable
for a WAN.
Using IP fragmentation these days is in general a bug. I regard it at
the same level as using UDP without checksums. Use path MTU discovery
or a stronger protocol like SCTP. Alternatively Ipv6 with 32bit
fragment ids, but even that is too small for multi gigabit speeds.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Feb 15 2003 - 22:00:31 EST