[arin-ppml] Stepping forward, opening my mouth and removing all doubt about
bjohnson at drtel.com
Thu Aug 28 13:27:26 EDT 2008
Owen DeLong carved in a stone tablet:
> Let's put it closer to 75%. Here's a list of popular things that
> sub-optimally behind NAT:
Please define sub-optimal and whether this is due to the NAT or the
coding of the program.
> 1. Pick your favorite IM
I have yet to come across a modern IM client that doesn't work fine
> 2. VOIP (when it doesn't break outright)
I know several people who use Vonage behind cheap NAT routers.
> 3. P2P applications of various types -- Regardless of what
> you think of P2P filesharing, there are a number of
> P2P applications that have legitimate purposes and there
> are, frankly, many more legitimate P2P file shares than
> illegal ones. For example, virtually every linux distro
> a bit torrent available.
I use bit torrent to download distros all the time from behind a NAT
> 4. Voice and Video chats.
I have used voice and video chat applications from behind a NAT system.
This does require a broker to make connections or at least one side
having a directly addressable end-point though.
> 5. SSH
Have no idea what to say on this one unless you are securing your SSH
sessions by a remote IP address list.
> I'm willing to bet at least 75% of users use one or more of these
> on almost daily basis.
I will proceed under the assumption this is true :)
> Things which break behind NAT:
> 1. Inbound access to your machine from somewhere
> else. (Remote desktop, SSH, Web Server, etc.)
This I see as a viable gripe. But there are several vendors out there
offering free solutions for this using an external broker.
> Lots of people would _LIKE_ to do these things if they could,
> and, even more would be upset if it was suddenly taken away
> from them.
I can't agree with you more.
> Hence, I argue that your 10% figure is... optimistic.
> >> BUT - the fact of the matter is that stateful inspection
> >> of packets through a firewall shouldn't require this icky
> >> disgusting rewriting of source IP addresses. NAT is a
> >> transition technology and it has a lot more years left in
> >> it, but we cannot lose sight of the fact that it is a hack,
> >> despite our amazement that the elephant can actually dance.
> >> And you do not lay the foundations of a stable Internet
> >> on a hack.
> > Actually, that icky rewriting is a benefit from a network security
> > perspective. NAT has a tendency to fail closed while non-translating
> > firewalls have a tendency to fail open.
> This simply isn't true. Non-translating firewalls fail just as closed
> if the firewall supports stateful inspection. As an example, a
> Netscreen without NAT fails just as closed as a Netscreen
> with NAT configured.
This is a configuration and management issue. I can make my firewall act
either way depending on my configuration.
I have always leaned toward the no NAT option due to poorly designed
programs in the past, many of which broke severely under NAT. But as
time has evolved, I see no real reason to believe that for a large
volume of people, NAT is perfectly acceptable. It also provides a minor
amount of security through obscurity.
I have no plans to suggest anyone make such a change, but if v6 adoption
falls behind and I need more space after v4 exhaustion, I'll probably
propose a NAT firewall service trial on our network.
Keep the carrot in front of me... and I see the stick coming. :)
More information about the ARIN-PPML