The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: laforge@gnumonks.org, linux-kernel@vger.kernel.org
Subject: Re: [FWD: NAT counting]
Date: 10 Feb 2003 23:52:26 +0100	[thread overview]
Message-ID: <p73d6lzbvf9.fsf@oldwotan.suse.de> (raw)
In-Reply-To: "Luck, Tony"'s message of "10 Feb 2003 23:43:23 +0100"

"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

       reply	other threads:[~2003-02-10 22:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <DD755978BA8283409FB0087C39132BD1A07CC8@fmsmsx404.fm.intel.com.suse.lists.linux.kernel>
2003-02-10 22:52 ` Andi Kleen [this message]
2003-02-10 22:34 [FWD: NAT counting] Luck, Tony
2003-02-11  7:49 ` Leonard Milcin, Jr
2003-02-11 11:45   ` Harald Welte
     [not found] <1044545755.21354.9.camel@tux.rsn.bth.se>
2003-02-09 10:00 ` [Fwd: " Harald Welte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=p73d6lzbvf9.fsf@oldwotan.suse.de \
    --to=ak@suse.de \
    --cc=laforge@gnumonks.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox