[arin-ppml] Stepping forward, opening my mouth and removing all doubt about

[Brian Johnson]

Owen DeLong carved in a stone tablet:
> Let's put it closer to 75%.  Here's a list of popular things that
> function
> 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
behind NAT.

> 	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
> additional
> 		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
has
> 		a bit torrent available.

I use bit torrent to download distros all the time from behind a NAT
system.

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

- Brian