🚀 go-pugleaf

In article <MPG.17cb70dd853f18d09898ff@news.charter.net>,
Dave Phelps  <tippenring@deadspam.com> wrote:
>NAT is indistinguishable from an attacker? I'm not sure what you mean 
>there.

There's no way to tell if you're getting an unexpected IP
address because there's an attacker in the middle or because
there's a NAT.  This breaks IPSec and makes other protocols,
like STUN, impossible to secure.

>NAT doesn't significantly increase the cost of equipment. 

Sure it does.  The two principle mechanisms for getting
non-trivial protocols across NAT have been stateful
inspection/payload rewrite, and proxies.  (Note that both
prevent you from securing your applications end-to-end.)
That means that you've got another participant in protocol
processing and that that participant has to support the
protocols that are causing you problems (FTP, SIP, H.323,
MGCP/megaco, gaming protocols, instant messaging protocols
... ), which in turn means that you need more processing
power in the boxes themselves and that the manufacturer
needs a team (or several teams, in the case of some of the
bigger manufacturers who have multiple product lines) of
developers adding protocol support to the NAT or proxy.

>A lot of the problems NAT introduces is because of programmers that have 
>written code without regard for the OSI model. If they would have left 
>IP addresses at layer 3, there wouldn't be nearly the problem that there 
>is. FTP and Netmeeting are two examples.

IP doesn't follow the OSI model, particularly.  If you're
talking about cleanliness between the layers, IP is
generally in pretty good shape there.  Dynamically
allocating data streams is good practice and while H.323 may
be misdesigned, its use of dynamically-allocated ports is
not the problem.  The problem, in the case of NAT, was that
one of the most fundamental design principles behind IP was
that addresses are globally unique and globally routable and
that they are immutable end-to-end.  NAT obviously breaks
that, and the consequences are pretty much what you'd
expect.

>Tell me, exactly how does NAT enable users to violate firewall policy? I 
>don't see how translating an internal address at the firewall somehow 
>bypasses firewall restrictions.

I said that many of the mechanisms that are being developed
to accomodate NAT provide the means for users to violate
local firewall policy.  There's an arms war going on between
manufacturers, who need to make sure that applications work
despite the presence of NATs, and users, who find firewalls
a big nuisance and who are using the NAT workarounds as
tools to allow them to run unauthorized servers, etc.
-- 
     Melinda Shore - Software longa, hardware brevis - shore@panix.com
          If you send me harassing email, I'll probably post it