Re: [FWD: NAT counting]

Re: [FWD: NAT counting]

[Luck, Tony]

> Linux is not 'being fixed', because I don't regard this as a bug - and
> only bugs need fixing.
> 
> I don't want to have the NAT code to _always_ rewrite the IP ID because
> of performance reasons.  I think we should leave the current behaviour
> and provide an _optional_ 'IPID' target for the mangle table.  So
> everybody who wants IP ID rewriting can use that target.

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.

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?

-Tony Luck  

Re: [FWD: NAT counting]

[Leonard Milcin, Jr]

Luck, Tony wrote:
 > (...)
 > 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
 > (...)

Sometimes it is desirable to hide the true number of hosts behind the 
NAT. For example in home-made Linux NAT Gateways where few people share 
the same internet connections even if ISP doesn't allow sharing 
connection ;)

Re: [FWD: NAT counting]

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

On Tue, Feb 11, 2003 at 08:49:59AM +0100, Leonard Milcin, Jr wrote:
> Luck, Tony wrote:
> > (...)
> > 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
> > (...)
> 
> Sometimes it is desirable to hide the true number of hosts behind the 
> NAT. For example in home-made Linux NAT Gateways where few people share 
> the same internet connections even if ISP doesn't allow sharing 
> connection ;)

No doubt.  But as I initially stated: I don't want to do this by
default.  We will give the user a choice [by means of an IPID target in
the mangle table].

-- 
- Harald Welte <laforge@gnumonks.org>               http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
 as I'm the dictator."  --  George W. Bush Dec 18, 2000

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [FWD: NAT counting]

[Andi Kleen]

"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

Re: [Fwd: NAT counting]

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

On Thu, Feb 06, 2003 at 09:46:44PM -0500, Stephen Clark wrote:
> 
> Is Linux being fixed to prevent this?

Linux is not 'being fixed', because I don't regard this as a bug - and
only bugs need fixing.

I don't want to have the NAT code to _always_ rewrite the IP ID because
of performance reasons.  I think we should leave the current behaviour
and provide an _optional_ 'IPID' target for the mangle table.  So
everybody who wants IP ID rewriting can use that target.

-- 
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
 as I'm the dictator."  --  George W. Bush Dec 18, 2000

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]