[arin-ppml] Set aside round deux

[Owen DeLong]

On Aug 2, 2010, at 12:18 PM, Joe Maimon wrote:

> 
> 
> 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.
> 
Bring it on...

> 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?
> 
This differs from the current reality with NAPT how? I don't see any reason that state-ful inspection without NAPTT would be any more or less secure than it is with NAPT.

> 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?
> 
The presence of NAPT does nothing to improve this and the absence of NAT would only
have the following effect:

	1.	Your audit logs will be easier to correlate.
	2.	Things are easier to troubleshoot because you don't have to correlate address
		mappings that are transient in nature.
	3.	Historical data will be more useful (again due to  lack of transient mappings that
		may or may not get recorded).

> 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.
> 
In many cases, yes, but, in some cases no.

However, a key issue here is that you are juxtaposing residential and enterprise requirements
in a manner that doesn't really further either discussion.

In the residential situation, I'm not worried about any failure to deploy IPv6 due to lack of NAT.
Residential users are going to end up on IPv6 simply as a result of the lack of IPv4 and the fact
that they are least in a position to manipulate their providers' behavior.

In the enterprise situation (where this thread started and where my comments have primarily
been directed), as you point out, there is a firewall administrator responsible for working with
the users to evaluate such requests and analyze the security implications for the organization.
It's that person's job to be the "bad guy" when required. His job isn't any harder or easier because
of NAPT and it doesn't get any better or worse as a result of deprecating NAPT.

> 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).
> 
Many things that I would not call stupid protocol tricks are unwieldy in a NAPT environment but
work just fine in a stateful inspection environment. Address mangling introduces additional
problems that are not present simply from stateful inspection.

> 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.
> 
Agreed. I don't see how NAPT helps this, however.

> 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.
> 
That doesn't necessarily have to be true, but, given the ubiquity of things like UPNP on residential
gateways, I don't see how that really matters. Oh, and, I have seen people get told try putting
your machine directly behind the DSL modem instead of behind the router... (Which amounts
to turn off NAPT). It really is just about as easy.

> 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.
> 
Uh, no, see above.

> 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.
> 
First, not everyone shares this belief, but, even for those that do, there are things that break from NAT without layering violations.

> 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.
> 
I'm fine with users choosing to do whatever damage they want to their own network. What I would like to avoid is having that choice inflict that damage upon ISVs and others in the form of requiring vast amounts of code to create NAT traversal technologies to overcome that damage when there is no longer any need to damage the network in such a way.

Owen