🚀 go-pugleaf

In article <MPG.17ccc360a78e8145989900@news.charter.net>,
Dave Phelps  <tippenring@deadspam.com> wrote:
>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.

Well, since STUN exists to help NATted endpoints find their
external address (something that's impossible to do reliably
without talking directly to the NATs along the path, but
STUN provides a reasonable heuristic in the absence of that
ability), pretty much by definition anybody who uses it is
NATted.  NATs are quite heavily used in organizations that
use IPSec VPNs, but either the translation is done before
encapsulation/after decapsulation or a NAT workaround
mechanism is used, risking adding additional instability to
the network, etc.

It's important to understand that there's no universal
solution to the problems that NAT introduces, nor can there
be.  As things stand right now you need to add stuff to your
network to get IPSec to work, other stuff to get H.323
(NetMeeting) to work, other stuff to get SIP and SIP-based
instant messaging to work, other stuff to get telephony
gateway protocols like MGCP and megaco to work, other stuff
to get gaming protocols to work, and the list gets ever
longer.  For the average home user behind a single NAT this
usually isn't a problem (unless he or she happens to want to
run a protocol for which there's no support), but for any
non-trivial network the effort and expense start to add up.
In some cases (large enterprises) they become quite
significant.

>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.

Let's be clear on something - address space was and is
available (current utilization is ~50%), but because of the
way distribution and ownership of addresses are handled the
folks who own address blocks benefit economically from
creating a false scarcity.  They make money selling
addresses.  This is a political and economic problem, not
technical.

Nevertheless, there is a technical solution, and that's
IPv6.  Over the medium-to-long term a transition to v6 is
almost certainly less expensive than continuing to pile on
NAT workarounds.

>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. 

Let's say that I run an IP-based PBX for my company and I
find that calls cannot get through my firewall/NAT.  I cast
around for a solution, like people do here, and I get a
response from company Splortsoft who tells me that their
software will solve the NAT traversal problem and that it
won't introduce any additional security holes.  In point of
fact it *does* introduce security holes by providing a means
to defeat local firewall policy - after all, if firewall
policy "understood" telephony protocols I wouldn't need to
buy anything from Splortsoft, right?  A wiser person than me
once said that there are no side effects, only effects, and
in this case it shouldn't be surprising that the stuff from
Splortsoft allows malicious contravention of firewall policy
in addition to allowing NAT traversal by protocols we like.
So here I am, the beleaguered network administrator,
installing software that allows people to violate the
policies I'm trying to enforce.  At this point it would make
more sense to chuck both the firewall and the software from
Splortsoft and get myself some addresses.

>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. 

There *is* an alternative.

(Trivial point, but a pet peeve nevertheless - the things
under discussion are "addresses," not "IPs.")
-- 
     Melinda Shore - Software longa, hardware brevis - shore@panix.com
          If you send me harassing email, I'll probably post it