[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On Wed, Feb 02, 2011 at 11:45:49PM -0500, Jay Ashworth wrote:
> ----- Original Message -----
> > From: "Blake Dunlap" <ikiris at gmail.com>
> > On Wed, Feb 2, 2011 at 22:34, Jay Ashworth <jra at baylink.com> wrote:
> > > I won't run an edge-network that *isn't* NATted; my internal machines
> > > have no business having publicly routable addresses. No one has *ever*
> > > provided me with a serviceable explanation as to why that's an
> > > invalid view.
> > Quite simply, its called Tragedy of the Commons. Everyone else has to
> > work harder to provide you services if you are using something which breaks
> > end to end connectivity, which costs everyone else money. The protocol
> > designers are making a stand against this for the good of the "commons".
> You'll have to document "everyone has to work harder to provide me services";
> this is not my first rodeo, and TTBOMK, it's *transparent* to the other end
> of any connection out of my edge network that it's NATted at my end.
> As for incoming connections, it's transparent to them as well -- and which
> ones are valid targets for such connections *is a policy decision of
> mine*, not subject to external opinion.
You're thinking too small -- it's not that individual TCP connections have
problems, it's that the ability to solve a given problem using connections
and UDP packets is badly constrained by a lack of end-to-end connectivity.
The proof is fairly obvious in the number of hacks that have been deployed
to try and get around NAT's inadequacies: Skype supernodes, STUN, all the
various conntrack helpers in netfilters, etc etc etc.
Now, if you decide that none of those applications are important to you,
sure, you can firewall them off as appropriate. But the pervasive
deployment of NAT means that the set of problems that can be solved is
constrained, and of the problems that *can* be solved, the solutions tend to
be more complicated, harder to implement, understand, and so on, which has a
cost to the community (higher prices, less solved problems, whatever your
desired metric may be). I think that's what Blake is getting at with his
Of course, I'm a tiny bit of a skeptic, as I really can't see how a stateful
firewall can know which other connections / packets are related without a
lot of the same dodgy shenanigans that goes on now, but at least if you've
gotten rid of the 1-to-N address mangling a fundamental stumbling block is
removed and people can get on and solve the remaining (tractable) problems.