[arin-ppml] Set aside round deux

[Joe Maimon]

Owen DeLong wrote:


> The fact that NAT is widespread does not mean we can't deploy
> IPv6 without introducing that damage to IPv6. NAT is not the poor
> man's firewall, just a case of ignorance on the part of the poor
> man. The poor man's firewall is and has long been stateful
> inspection with a default deny inbound policy for all traffic not
> matching an existing state table entry. That works with or
> without the address mangling of NAT. NAT, on the other hand,
> does not work without stateful inspection.
>
> NAT does cause problems even for the single-homed small
> environment, whether those environments are aware of the
> problems or not.
>
> Owen
>

I would like to address this specific point, oft repeated that NAPT's 
stateful inspection protection is a byproduct and can easily be replaced 
with a basic firewall turned on by default.

While certainly true from a technical viewpoint, I think this glosses 
over a somewhat non technical practical reality and interaction between 
protocols, vendors, firewalls, designers, users and administrators.

Without the ubiquity of NAPT, how long do you think it will be before 
having a default deny inbound rule becomes non practical, or that UPNP 
hole punching is a basic requirement to the extent that firewall are a 
swiss cheese joke?

How many times as a NAT/Firewall admin on any size or class device have 
you been asked to "open the firewall" for this or that protocol?

Do those requesters even understand the concept of flow 
direction/initiation? The difference between permit rules and inbound 
translation maps, the difference between bi-directional static NAT and 
multiplexed NAPT or differing inside and outside ports? Have they even 
tried using the application before blaming the "firewall"? Do they know 
which ports and protocols are involved or whether the application can be 
tuned to work properly without a specific inbound permit, or worse a 
gigantic monster truck sized 16K dynamic port range hole? Yeah, I 
thought so. Its you who is the bad guy, breaking their cute little 
protocol/application. Now apply that to the residential market.

Protocol designers, users and administrators are not any less lazy than 
the rest of us. Possibly more. NAT ubiquity have forced all but the die 
hard idealists to avoid any use of cheap protocols tricks that prove 
burdensome and unwieldy in not only a NAPT environment, but also in an 
SPI environment, except as properly justified or required (one hopes).

That is a good thing in my opinion and I would hate to see the pendulum 
swing the other way to the extent that cheap CPE which are not intended 
to burden its user with actual operation of them can no longer use a 
default deny inbound SPI.

Its much easier to tell someone turn off the firewall if you want my 
protocol to work "just for testing" than to tell them to turn off NAPT.

In the former, the protocol will magically start to work and the 
firewall will stay off. In the latter, nothing will work and NAT will be 
turned back on. In a sense, this is the correct expansive definition of 
the phrase "NAT fails close", where fail is the failure of protocols, 
admins and users to adhere to proper security diligence.

Lets face it, requiring L4 and higher protocols to have knowledge of L3 
detail is a layering violation and should be frowned upon by those who 
believe layering violations are the source of all protocol evil.

So where does this leave me? I believe firmly that NAPT should become a 
choice made by users, not a requirement for basic service as it is now, 
nor a practical impossibility as IPv6 currently intends.

Joe