[arin-ppml] Set aside round deux

[Owen DeLong]

On Aug 1, 2010, at 2:40 PM, Roger Marquis wrote:

> Ted Mittelstaedt wrote:
>> Owen ... Your running around preaching the evils of NAT and half of these
>> SOHO's out there likely think your talking about some insect that flies up
>> their nose when they ride their bicycle. And the ones that know what it is,
>> they aren't aware of those NAT problems and so they are going to conclude
>> that NAT works fine. I'm just saying, when preaching IPv6, you gotta flog a
>> horse that the listener understands.
> 
> It's not a matter of understanding.  Many of us have been deploying NAT
> for decades.  We understand that it brings both costs and benefits,
> however, in our companies NAT is just one element in a matrix.
> 
> We understand NAT's role in multi-homing gateways, we understand the
> security provided by NAT, and we also understand the drawbacks to the
> so-called NAT alternatives.  If there is a lack of understanding it has
> more to do with these and other business deliverables.  Aside from
> network engineering our IT departments are also responsible for securing
> IP (intellectual property), managing intrusion detection systems, meeting
> budgets, and regulatory compliance.  These are all at least as important
> as the perceived convenience of network engineering staff.
> 
I've spent plenty of time in enterprise networking and the vast majority
of enterprise networkers I have met who actually understand things are,
frankly, inclined to view NAT as a necessary evil rather than  a good thing.

If you think NAT offers any security whatsoever, I would argue that pretty
well proves a certain lack of understanding. NAT does not do anything
for you that a default-deny state-ful inspection policy cannot do without
mangling the headers. A default-deny state-ful policy fails just as closed
as a NAT and is no harder or easier to subvert.

> This should not imply that I've met a network engineer who has any
> problems with NAT.  The organizations I have worked for are not ILECs or
> backbone providers, so neteng job candidates expressing a problem with
> NAT would not normally get past the first interview.  That said, it does
> seem that the arin-ppml mailing list is backbone-centric, and if it had
> more representation from administrators of other network models we would
> hear less from the minority of engineers who have problems with NAT and
> more from the rest who understand NAT's advantages over the proposed
> alternatives.
> 
Interesting that you refer to those who do not mind NAT as administrators
and those who understand reality as engineers. I think that is a good and
valid distinction as network administrators do tend to be more checklist
procedure oriented and less grounded in the theory and under-the-hood
nature of networking. I can see where such a group would be less informed
on the true costs of NAT and would be less likely to understand all of the
problems it causes which are outside of their experience. Since they are
probably limited in experience to networks that had NAT before they
got any where near the network and have likely never experienced a
network without NAT, it would make sense.

The majority of network administrators, those who follow a set script
for dealing with things and have to escalate problems not within their
script to an engineer probably don't understand why NAT is bad or
know that objecting to it is even possible. I will buy that, and, given
some of your earlier statements, if you so claim, I am willing to consider
you part of that group.

The majority of network engineers, on the other hand, are unlikely
to think that NAT is anything better than a necessary evil in IPv4
at best and no longer necessary in IPv6.

Owen