[arin-ppml] Set aside round deux

[Ted Mittelstaedt]

On 8/2/2010 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.
>
> 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.
>

The problem is that comparing IPv4 NAT to some hypothetical IPv6 NAT
implementation isn't an apples-to-apples comparison.

For the residential CPE folks, you can build a cheap, NATless
IPv6 CPE that has a default inbound deny rule and stateful
inspection, that uses UPnP to open holes as-needed, automagically.
SO I don't even count them in the equation.

For the corporate folks, the principle reason to use NAT is that
their ISP cannot supply them with enough public numbers as needed
for the inside, or if they can they would be very expensive.
That won't be a problem with IPv6.   Thus, NAT is a requirement
for them for IPv4 at the current time, and all examination
and discussion of security, portability and everything else all
revolves around the NAT environment from the get-go.

With IPv6, NAT is not a requirement so that assumption does not
hold true.

I could logically prove that a NAT-less IPv4 connection is just
as secure as a NAT-less IPv6 connection but it's always going
to be trumped by the requirement for NAT due to the small supply
of public IP addresses any org gets from their ISP.

Ted