🚀 go-pugleaf

In article <ajt9ku$fvh$1@panix3.panix.com>, shore@panix.com says...
> 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.
I think your first sentence is based on the fact stated in your second. 
I understand what you're getting at now. However, people that are likely 
to use those protocols are more likely to be looking at getting public 
IP address space anyway. And I would recommend it in that case.

> 
> >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.
Ok. So maybe the cost is more significant than I originally implied. I 
still stand by my point that it was necessary anyway, due to the lack of 
IP space, and so was unavoidable.
> 
> >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.
True, NAT breaks the end-to-end plan. However, it goes back to the fact 
that the IP space was not available, and incidentally, still isn't.
> 
> >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.
If the users don't have administrative access to the box performing NAT, 
then there really isn't a problem with users running unauthorized 
servers. Sure, there are ways the users can get by NAT to run 
unauthorized servers, such as relaying thru another public server to 
which they have a session (essentially connecting to a public proxy), 
however, NAT isn't the cause of the problem. Even if the user had a 
public IP , no NAT, and his traffic was passing thru a firewall, he 
would still be able to run his unauthorized server.

Overall, I agree with you that NAT has made a nuisance of itself in 
soime cases, but I believe that the inconveniences of NAT are FAR 
outweighed by what NAT has made possible for Internet connectivity. 

-- 
Dave Phelps
Phone Masters Ltd.
deadspam=tippenring