Subject: Re: [nat66] To NAT66, or NOT to NAT66, that is the question

From: Roger Marquis <[email-masked]>
Date: Fri, 29 Oct 2010 18:19:16 -0700 (PDT)

Margaret Wasserman:
> There _also_ seem to be use cases where enterprise administrators use
> NAT specifically for the purpose of blocking (most or all?) incoming
> connections.  I do not know if we have explored that use cases well
> enough to know if it could be served by a stateful firewall and/or a
> combination of NAT66 and a stateful firewall.

_Also_?  Some?  Really?  I don't mean to question Margaret's experience
but I have to wonder what this statement is based on.  Most of us
security professionals use NAT to block _all_ incoming connections
_by_default_.  This is known as fail-closed.

Internal hosts that need static mappings to external IPs get them, as
exceptions to the default rule.

Question for Margaret: would you consider firewalls that fail-open to be
best practice?  If not then why do you consider that model to be
appropriate when applied to NAT66?

> I think it would make sense for the IETF to look into those use cases in
> more detail, as was already done for CPE equipment.

Why would the IETF analyze what is codified in nearly every firewall
security policy and standard practice across the overwhelming majority of
home and business uplinks?

Roger Marquis

---

From: Gert Doering <[email-masked]>
Date: Sat, 30 Oct 2010 12:06:12 +0200

Hi,

> _by_default_.  This is known as fail-closed.

Would you please not speak of "us security professionals"?  I consider
your attitude toward NAT inacceptable, and do not want to be put into the
same basket as you.  Speak for yourself, don't assume you can speak for
"most of us security professionals".

Gert Doering
        -- NetMaster
-- 
did you enable IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: "S.P.Zeidler" <[email-masked]>
Date: Sat, 30 Oct 2010 20:09:33 +0200

> _by_default_.  This is known as fail-closed.

I use firewall rules for that. :)

Given that your NAT device is likely your firewall, why do you trust
your co-admins not to accidentially change N:1 NAT if you don't trust
them to keep the incoming block around?

I don't think N:1 NAT is in the long-term best interest of enterprises,
even if it will likely take about as long to un-learn NAPT as it took
to learn CIDR. Privacy is a concern, but newer Windows machines seem
to do privacy addressing with great abandon, and other current OSes
at least use them if told.

I don't see much point in trying to prevent people from using whatever
they want now, though, as long as it has no immediate impact on
third parties; standard practise will change by itself when the
advantages are apparent. Same holds true for NAT at all and potential
better solutions, btw.

regards,
	spz
-- 
[email-masked] (S.P.Zeidler)

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 30 Oct 2010 16:12:43 -0400

Hi Roger,

On Oct 29, 2010, at 9:19 PM, Roger Marquis wrote:
> but I have to wonder what this statement is based on.

My statements are based on statements made by others here on this  
list, and at presentations of NAT66, as well as my work experience at  
companies that chose to use NAT for various reasons.  I have managed  
IT, run enterprise networks and/or been involved in network planning  
for a few small-to-medium-sized enterprises, and we chose to use NAT  
on most of those networks for various reasons.

Some people say that NAT66 (as defined in the NAT66 document) will  
address their needs for NAT in IPv6.  They want to use NAT in IPv6 for  
address independence, and they do not desire the other features/side  
effects of NAPT -- blocking inbound connections, forcing multiple  
nodes to use a single address which interferes with tracking/ 
identification of individual nodes outside the NAT, port sharing which  
results in several nodes having only one instance of a given port, etc.

Some people say that they need a IPv6 NAT box that blocks all incoming  
connections (unless they intentionally let something in).  At least  
some of this group would be happy with a device that combines NAT66  
and a stateful firewall that defaults to a closed configuration (as  
mentioned in this draft).  I am not sure that I understand how/if an  
IPv6 NAPT box would meet this need better than a NAT66/Stateful FW  
combination, as long as the stateful firewall "failed closed", as you  
say.  Can you explain why you view NAPT as a better solution than a  
NAT66/Stateful FW combination?

Other people actually seem to _want_ to have multiple internal nodes  
addressed at a single IP address using port translation.  In most  
cases I've heard described, this is desired for its "topology hiding"  
properties.  The ability to track/identify individual nodes outside  
the site can go both ways -- it can make it easier for network  
administrators to locate/diagnose network issues, but it also makes it  
easier for attackers to identify individual nodes to attack.  I've  
heard people argue on both sides of this issue.

For folks who only want NAT for address independence, NAT66 (possibly  
combined with a stateful firewall) provides that, without all of the  
other NAT side effects.  For folks who actually _want_ the properties  
and/or side effects of sharing a single address among multiple nodes,  
NAT66 won't do what they want, and they will ask their vendors for  
something else.  That "something else" may be defined by the IETF or  
by customers/vendors, but it is not the intended subject of discussion  
on this list.

Margaret

> Most of us

> _______________________________________________
> nat66 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nat66

---

From: Roger Marquis <[email-masked]>
Date: Sat, 30 Oct 2010 14:16:16 -0700 (PDT)

> "most of us security professionals".

Ok, cansider my statements as applicable to enterprise security
professionals then, the ones with responsibility for edge firewalls, the
overwhelming majority of whom know that NAT is an important security tool
and have no carrier-driven or marketing-driven hidden agendas.

Roger Marquis

---

From: Keith Moore <[email-masked]>
Date: Sat, 30 Oct 2010 19:14:11 -0400

> and have no carrier-driven or marketing-driven hidden agendas.

Sorry, no.  I know a lot of enterprise security people who are smarter and better informed than that.  The people to whom you're referring are those who aren't qualified for their jobs.  Admittedly there are a lot of people who fit that description, but we certainly shouldn't let them dictate future Internet architecture.

---

From: Gert Doering <[email-masked]>
Date: Sun, 31 Oct 2010 11:56:48 +0100

Hi,

> and have no carrier-driven or marketing-driven hidden agendas.

I have built enterprise networks in the past, and we've used NAT in some
places, and avoided NAT like the plague in other places.

NAT is a useful tool at times, and a major pain at other times.  
*Professionals* can analyze a situation and pick *the right tool*, instead
of blindly following the "everybody does this!!" lore.

If you want to state that *you* like NAT, fine.  But don't assume you can
speak for others, or for "security professionals".

Gert Doering
        -- NetMaster

---

From: Roger Marquis <[email-masked]>
Date: Sun, 31 Oct 2010 08:52:12 -0700 (PDT)

> places, and avoided NAT like the plague in other places.

It is difficult to read a statement containing "like the plague" and not
see bias in it.  Be that as it may...

> of blindly following the "everybody does this!!" lore.

Would be interesting to know what Joseph bases his claim of "blindly
following the "everybody does this!!" on.  This view is wholly
inconsistent with the security professionals I have worked with over the
past 15 years.  NAT is often spec'ed for IPv4 address conservation but
even where it is not NAT is still used by the overwhelming majority of
address-rich sites.  Having been the CISO of a telecommunications
equipment company with two /16s where NAT was used nevertheless you would
think someone in neteng would have told me they were opposed to NAT, but
none did.  None have either, ever, except in forums like this.  This
leads me to believe that the opposition to NAT is based on a poor
understanding of infrastructure security and/or a hidden agenda.  Given
the profit potential of universal routability my inclination would be to
suspect the astroturf agenda, particularly given how NAT-detractors:

  A) have yet to provide a detailed rebuttal to the many uses of NAT, and

  B) are in conflict with the charter of this mailing list.  As such claims
  that NAT should not be standardized (by the IETF or elsewhere) should be
  moderated.  That there is no moderation also indicates bias.

> speak for others, or for "security professionals".

No sorry, the real world doesn't work like that.  I can speak for others
because I've been working with other network engineers for 15+ years,
including some of the best (Yahoo paranoids, banking auditors, credit
card vendor developers, ...)  In all those years I have never met anyone
with the audacity to claim they are opposed to NAT in any employment
situation.  This may be that they do not wish to have their credibility
doubted among their managers and co-workers, or more likely, they would
not have gotten the job in the first place had they indicated a bias
against NAT.  I don't need to speculate but I can say that my sample size
is large and statistically relevant.

Roger Marquis

---

From: Roger Marquis <[email-masked]>
Date: Sun, 31 Oct 2010 09:47:33 -0700 (PDT)

> A) have yet to provide a detailed rebuttal to the many uses of NAT

One way NAT-detractors could back-up their claims of "harm" would be to
answer Chris Engel's request for an example of where NAT would break
something that statefulness would not.

SIP, SCTP and P2P are examples of where statefulness is both required for
security and where the same statefulness permits such applications and
protocols to work seamlessly with NAT.

Given the lack of any rebuttal to these examples it would seems that
NAT-detractors either want these protocols to be allowed past firewalls
without statefulness and/or do not understand the security problems of
statelessness.  If this is not the case perhaps someone could explain
why?

Roger Marquis

---

From: Fred Baker <[email-masked]>
Date: Sun, 31 Oct 2010 09:53:10 -0700

On Oct 31, 2010, at 8:52 AM, Roger Marquis wrote:

> A) have yet to provide a detailed rebuttal to the many uses of NAT,

There may be a use that the authors of this document didn't consider, but I know they were attempting to respond to that question in

http://www.ietf.org/rfc/rfc4864.txt
4864 Local Network Protection for IPv6. G. Van de Velde, T. Hain, R.
     Droms, B. Carpenter, E. Klein. May 2007. (Format: TXT=95448 bytes)
     (Status: INFORMATIONAL)

---

From: Keith Moore <[email-masked]>
Date: Sun, 31 Oct 2010 18:59:11 -0400

> something that statefulness would not.

A stateful firewall can (at least in principle) be configured to enforce finer-grained policy than a NAT. 

> protocols to work seamlessly with NAT.

Any pro-NAT arguments that try to cite specific protocols that happen to work with NAT, or expect their opponents to enumerate applications that don't work with NAT, are inherently irrelevant, and not worth responding to.

The purpose of the Internet is not to support only a few specific protocols that you might have happened to have heard of today, or that might happen to work through NAT.  

Keith

---

From: Christian Huitema <[email-masked]>
Date: Mon, 1 Nov 2010 03:59:15 +0000

> SIP, SCTP and P2P are examples of where statefulness is both required 
> for security and where the same statefulness permits such applications 
> and protocols to work seamlessly with NAT.

SIP works through NAT if you implement ICE, STUN and TURN. That is, SIP developers have engineered with great pain a set of workarounds that mostly works through most NAT. There are still residual cases where it breaks, e.g. some pathological NAT. The workarounds have significant deployment costs, e.g. TURN servers in the DMZ, and significant run time overhead, e.g. constant flow of state maintenance packets with their cost in traffic overhead and battery life. Saying that "stateful NAT enables SIP" is only right in some Orwellian twist of the word "enables." 

As for P2P, I don't know what you refer to. P2P protocols based on TCP-IP mostly don't work through NAT, although they can be made to work through some NAT if one deploys TCP > IPv6 > Teredo -- another of those "interesting" engineering efforts designed to alleviate the effects of NAT. Saying that P2P works seamlessly with NAT smells of Alice in Wonderland...

-- Christian Huitema

---

From: John Payne <[email-masked]>
Date: Mon, 1 Nov 2010 01:44:46 -0400

> and have no carrier-driven or marketing-driven hidden agendas.

Nope. NAT66 as per the draft, but for address independence, not security.
The stateful firewall handles the connection blocking, the NAT handles the separation between the enterprise addressing and the local provider addressing, and regular audits handle the "humans are touching configs" aspect.