Subject: Re: [nat66] Necessity for NAT remains in IPv6

From: Roger Marquis <[email-masked]>
Date: Tue, 10 Nov 2009 13:05:12 -0800 (PST)

Brian E Carpenter wrote:
> The harm is generic harm to innovation and applications architecture.

That is a theoretical harm, or rather an opinion of such.  It is not
supported by the widespread use of IPv4 NAT.  In fact the ubiquity of
IPv4 NAT is proof that such criticisms are baseless.

Perhaps more importantly, in the past the IETF required RFC candidates to
have working implementations before being approved.  IPv6 has no working
implementation because, in large part, it does not include a NAT standard.

> The prime example today is the grotesque things that VoIP protocol
> designers have been forced to do.

Pure FUD.  SIP is the issue here, not VOIP.  SIP is a badly designed
protocol in many ways, not just for its embedding of network layer
addresses as authentication.  VOIP protocols such as IAX have no issues
with NAT because they learned the lessons of history, not by layering
workarounds on top of workarounds.  No honest criticism of NAT can fail to
note these details and yet we continue to read these vague and general
criticism because...  well, because either 1) NAT critics cannot make a
defensible point, 2) they do not understand the issues with SIP, or 3) they
stand to profit by prolonging the IPv4 address shortage.

> Mainly because the problems are totally undiagnosable, especially for
> the typical home user/help desk combination. And should we really be
> pushing technology that we know to be unreliable? As an engineer, that's
> actually a violation of my professional ethics.

As an engineer you should know how to implement logging in such a way that
permits monitoring of your own networks.  Some very large NAT'd networks
have no such logging issues.  Once again, statements of opinion, offered as
fact, as those noted above, vague and unsupportable.

Roger Marquis

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Nov 2009 12:30:37 +1300

> IPv4 NAT is proof that such criticisms are baseless.

Er, no, it's proof that application designers have found work-arounds
for the lack of address transparency caused by NAT. A common technique
is of course to add an application-specific endpoint identifier
above whatever method is used to punch a session through the NAT.
In many cases that ends up being the misuse of HTTP as a generic
transport protocol, since pretty much every NAT/firewall combination
lets HTTP through.

The node/supernode system in Skype exists mainly for this reason, for
example. When I mentioned VoIP, I was not only thinking of the
SIP/STUN/ICE/TURN mess.

...
> have no such logging issues.  

There's nothing vague about the complete lack of useful logging
of NAT bindings in the D-Link and LinkSys devices I have used in
my home, which makes it totally impossible to track and trace
problems. This covers the vast majority of NAT deployment in the
Internet. I don't know whether all enterprise-grade NATs keep better
logs; I'm glad to hear that some do.

   Bria

---

From: Roger Marquis <[email-masked]>
Date: Tue, 10 Nov 2009 16:20:53 -0800 (PST)

> for the lack of address transparency caused by NAT.

"lack of address transparency caused by NAT" is rhetorical.  It would be
more accurate to point out that application designers fixed protocols that
were poorly designed in the first place.  They do this in order to keep
state as well as NAT.  Since statefulness has to be preserved anyhow there
would be no net gain in doing away with NAT.  With regard to protocols,
I assume you are not defending the design of SIP/STUN/TURN, ftp, ...
If not please do explain.

NAT "translates" layers 3 and 4 the same way routers translate MAC
addresses.  If this is a "work-around" then router vendors have a lot of
explaining to do.  I take it you are not seriously suggesting IPv6 do away
with MAC layer translation?  Can you explain why not?

> A common technique is of course to add an application-specific
> endpoint identifier above whatever method is used to punch a
> session through the NAT.

What you call "whatever method" firewalls call statefulness.  The session
is "punched" by the state engine.  NAT is added to that with little or no
overhead.  I take it you are not seriously suggesting IPv6 do away with
statefulness?  If not then please explain the difference.

> my home

It does not take many CPU cycles in the equipment I typically use (Juniper
Netscreen, Cisco ASA, Sonicwall, and various http load balancers).  Again,
I assume you are not seriously suggesting IPv6 do away with NAT because
low-end equipment does not implement sufficient logging for your
requirements.  If not could you explain again how this is factor in your
anti-NAT position?

Roger Marquis

---

From: Martin Röhricht <[email-masked]>
Date: Wed, 11 Nov 2009 09:24:55 +0900

> IPv4 NAT is proof that such criticisms are baseless.

I don't consider lacking support for newer transport protocols such as 
SCTP or DCCP a theoretical harm that is already caused by NATs nowadays.

> implementation because, in large part, it does not include a NAT standard.

Say what? This theorem is by far much more theoretical than the one you 
blamed above.

Martin Roehricht

---

From: Keith Moore <[email-masked]>
Date: Tue, 10 Nov 2009 19:44:42 -0500

Roger Marquis wrote:
> "lack of address transparency caused by NAT" is rhetorical.  It would
> be more accurate to point out that application designers fixed
> protocols that were poorly designed in the first place.
That's completely and utterly false.

1. The core Internet protocol suite was never designed or intended to
support NAT.  NAT breaks IP routing, because IP routing protocols expect
IP address prefixes to mean the same thing for every router that makes
decisions based on that information.   NAT breaks DNS, because DNS (as
designed) expects that an IP address will mean the same everywhere in
the network.   Yes, two-faced DNS exists, but it's an ugly hack and the
addresses *do* leak. 

Actually if there's a single core assumption in the Internet Protocol,
it's that everything on the network will use the same packet format and
the same address space.

2. No, for better or worse, the Internet was not designed with
expectation that all applications will use higher layer identifiers. 
DNS didn't even exist when the Internet architecture was being worked
out, and DNS names have never been suitable as general-purpose
application layer identifiers.

> They do this in order to keep state as well as NAT.  Since
> statefulness has to be preserved anyhow there would be no net gain in
> doing away with NAT.  
That's also incorrect.  When application writers find that NATs are
getting in the way of  their applications, they have little choice other
than to provide servers in the network core that can relay traffic
between application instances behind NATs.   And of course this creates
more state that doesn't share fate with the endpoints, but it's
unavoidable.  Without the NATs in the way, many of those applications
would not need state other than at the endpoints.
> addresses.
Bullshit.  Routers don't "translate" MAC addresses.  They route packets
from one L2 network to another.  This doesn't affect IP apps at all
because apps don't care what the MAC address is, and there was never any
expectation in the Internet that MAC addresses would be preserved
end-to-end, or even that they would exist.
> What you call "whatever method" firewalls call statefulness.  The
> session is "punched" by the state engine.  NAT is added to that with
> little or no overhead.
Little or no overhead to the router, you mean.  It's a PITA for everyone
else. 

Keith

---

From: Roger Marquis <[email-masked]>
Date: Tue, 10 Nov 2009 16:47:48 -0800 (PST)

Martin Röhricht wrote:
> I don't consider lacking support for newer transport protocols such as SCTP 
> or DCCP a theoretical harm that is already caused by NATs nowadays.

Caused by NAT, or caused by the need to keep-state?

> Say what? This theorem is by far much more theoretical than the one you 

Quoting from RFC 1603 section 1.1, although the need for working
implementations is outlined in many other IETF documents:

    In general, an Internet Standard is a specification that is
    stable and well-understood, is technically competent, has
    multiple, independent, and interoperable implementations
    with operational experience, enjoys significant public
    support, and is recognizably useful in some or all parts of
    the Internet.
    ...

Roger Marquis

---

From: Martin Röhricht <[email-masked]>
Date: Wed, 11 Nov 2009 09:59:59 +0900

> Caused by NAT, or caused by the need to keep-state?

Caused by NAT---if the intermediate NA(P)T-Gateway does not explicitly 
support a "new" transport protocol, corresponding packets cannot be 
forwarded. Try using SCTP with your home NAT today and report the results.

Martin Roehricht

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Nov 2009 14:08:44 +1300

On 2009-11-11 13:20, Roger Marquis wrote:
> "lack of address transparency caused by NAT" is rhetorical.  

No, it isn't. Try RFC2101, RFC2775, RFC2993, RFC3027, RFC3234, and RFC4924.

> It would be

SIP and FTP were certainly designed on the assumption of address
transparency. I'm not interested in defending or attacking those
designs; it was simply the standard design assumption in
the Internet at the time. Of course, STUN/TURN/ICE is a horrible
kludge as a result.

> NAT "translates" layers 3 and 4 the same way routers translate MAC

NAT translates layer 3 logical addresses, which were designed
to be globally unique, and kludges various bits of some layer 4
protocols accordingly. Routers don't translate physical layer
addresses; they decouple separate physical links and logical
address regions. In this respect, the OSI model is the best way
to describe things (I never thought I'd feel the need to say
that on an IETF list).

If this is a "work-around" then router vendors have a lot of
> with MAC layer translation?  Can you explain why not?

That question simply doesn't arise. Who's being rhetorical now?

> statefulness?  If not then please explain the difference.

Firewall state and NAT state are orthogonal. You can have either
one without the other. Of course, some protocols need to find a way
to punch through pure firewalls, but that's a quite different
problem from punching through NAT. The fact that the two get
confused is itself a source of complexity.

> requirements.  If not could you explain again how this is factor in your

I would prefer a world in which millions of consumers do not
suffer random, undiagnosable session failures. I agree that this
is orthogonal to whether certain types of sites are using enterprise
grade NAT for the reasons you and Chris have given. If we do document
NAT66 we need to be very clear about the applicability statement.

    Brian

---

From: Roger Marquis <[email-masked]>
Date: Tue, 10 Nov 2009 17:12:42 -0800 (PST)

> forwarded. Try using SCTP with your home NAT today and report the results.

Can you tell us what network gear passes SCTP without NAT but drops it when
NAT is enabled, or is this a rhetorical argument?

Roger Marquis

---

From: Keith Moore <[email-masked]>
Date: Tue, 10 Nov 2009 23:44:24 -0500

Roger Marquis wrote:
> Can you tell us what network gear passes SCTP without NAT but drops it
> when NAT is enabled, or is this a rhetorical argument?
any IP router.

---

From: Roger Marquis <[email-masked]>
Date: Tue, 10 Nov 2009 22:05:56 -0800 (PST)

>> when NAT is enabled, or is this a rhetorical argument?

Any router?  Router?  When was the last time anyone implemented NAT on a
router?  NAT is a firewall technology, not a router technology.

Once again we see that, when pressed for details, arguments against NAT
simply don't hold water.

Roger Marquis

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Nov 2009 21:29:21 +1300

> router?  NAT is a firewall technology, not a router technology.

I'm not an expert on all products, but Google quickly found me this:

http://www.cisco.com/en/US/docs/security/asa/asa80/asdm60/user/guide/fwmode.html

"This chapter describes how the firewall works in each firewall mode. To set the mode at the CLI, see the "Setting Transparent
or Routed Firewall Mode at the CLI" section on page 3-4.

This chapter includes the following sections:

•Routed Mode Overview

•Transparent Mode Overview

Routed Mode Overview

In routed mode, the security appliance is considered to be a router hop in the network. It can use OSPF or RIP (in single
context mode). Routed mode supports many interfaces. Each interface is on a different subnet. You can share interfaces between
contexts.

This section includes the following topics:

•IP Routing Support ..."

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Nov 2009 21:33:03 +1300

Oops, sorry, went too fast there

But Cisco do teach people how to fix problems with router NATs:

http://ciscostudy.blogspot.com/2006_02_10_archive.html

Regards
   Brian

---

From: Keith Moore <[email-masked]>
Date: Wed, 11 Nov 2009 06:43:03 -0500

Roger Marquis wrote:
> Keith Moore wrote:
>>> Can you tell us what network gear passes SCTP without NAT but drops
>>> it when NAT is enabled, or is this a rhetorical argument?
>>
>> any IP router.
>
no, NAT is not a firewall technology.  it's not exactly a router
technology either, though it is often incorporated in routers, and
devices that primarily exist to perform NAT are often marketed as "routers".

the point is that ordinary packet forwarding devices (i.e. routers)
don't break SCTP, but NATs do.
> Once again we see that, when pressed for details, arguments against NAT
Once again we see that someone who wants to be in denial, will maintain
that state of denial, no matter what.

---

From: Roger Marquis <[email-masked]>
Date: Wed, 11 Nov 2009 08:05:36 -0800 (PST)

> devices that primarily exist to perform NAT are often marketed as "routers".

We all know how NAT is used, and what the terms firewall, router, and
statefulness mean Keith.

> don't break SCTP, but NATs do.

In the real world end-node networks do not use routers they use firewalls.
All firewalls implement stateful filtering of ingress flows.  Since
statefulness breaks SCTP with or without NAT your argument against NAT is
tangental.

Whether routers are capable of NAT is irrelevant.  NAT is not used on
routers.  NAT is used on edge devices i.e., firewalls.  Firewalls by
definition are not simple packet filters and they are not simple "packet
forwarding devices".  Firewalls implement statefulness.  Statefulness
breaks SCTP with or without NAT.

You can argue against statefulness but all you want, but there is no market
for edge devices that do not implement statefulness.  Without statefulness
it is impossible to implement effective security policies.  Nobody builds
such devices because nobody would buy them.  If OTOH you know of some other
method of implementing flow validation we would all like to hear about it.
The patent alone would be worth millions.

Bottom line: in the real world NAT is not used without statefulness.  To
make an argument against NAT that holds water you have to explain where NAT
breaks anything (in real world application) that wouldn't otherwise be
broken by the need to keep state.

Roger Marquis

---

From: Keith Moore <[email-masked]>
Date: Wed, 11 Nov 2009 11:16:35 -0500

> Bottom line: in the real world NAT is not used without statefulness. 
> To make an argument against NAT that holds water you have to explain
> where NAT breaks anything (in real world application) that wouldn't
> otherwise be broken by the need to keep state.
More bullshit.  The degree to which statefulness breaks things is only a
small fraction of the degree to which NAT breaks things.

---

From: Martin Röhricht <[email-masked]>
Date: Thu, 12 Nov 2009 01:23:23 +0900

Okay, this is my last respond on this topic, as I think this discussion 
(as even been hold off-list) is more or less useless.

> breaks SCTP with or without NAT.

No no no. NAT is not used on edge devices. My notebook for instance 
doesn't implement NAT, although it would like to use an SCTP-based 
protocol. My default gateway does however and this default gateway acts 
as ... a router.
Statefulness as implemented for a firewall does *not* break SCTP. It is 
the network translation that does. Statefulness is just about given any 
ingress flow for IP address X, protocol port Y, and protocol z that 
needs to correspond to a given egress flow. That works perfectly fine 
with SCTP or any other protocol above that uses address information in 
its payload. But with NATs that does not work anymore.

> The patent alone would be worth millions.

See above. Stateful firewalls would still be supported in a NAT-free world.

> broken by the need to keep state.

To hold water I would recommend you to explain to me and many other how 
protocols like SCTP or any other given protocol that holds address 
information in its payload can be supported by NAT gateways.

That's it,
Martin

---

From: Roger Marquis <[email-masked]>
Date: Wed, 11 Nov 2009 08:43:53 -0800 (PST)

> small fraction of the degree to which NAT breaks things.

Can you give us an example?  Is there a protocol in use in the real world
which ingress flows can be validated by a state-keeping firewall (at the
network edge) but only without NAT.

Please do be specific.  We are network engineers and curious how how the
claimed flow's state is kept and how NAT does not work when added to that.

Roger Marquis

---

From: Keith Moore <[email-masked]>
Date: Wed, 11 Nov 2009 11:59:20 -0500

Roger Marquis wrote:
>>
>> More bullshit.  The degree to which statefulness breaks things is
>> only a small fraction of the degree to which NAT breaks things.
>
When NAT breaks the ability of the endpoints to use the connection at
all, whether it's authorized or not, whether the flow can be validated
by a firewall is irrelevant.

Also, your notion of the "real world" is one which is deliberately
broken via NAT, so of course nothing exists in your "real world" that
suits your criteria.

Keith

---

From: Roger Marquis <[email-masked]>
Date: Wed, 11 Nov 2009 10:19:59 -0800 (PST)

> by a firewall is irrelevant.

If this statement were to hold water it would also have to apply to
statefulness:

   When statefulness breaks the ability of the endpoints to use the
   connection at all, whether it's authorized or not, whether the flow can
   be validated by a firewall is irrelevant.

Are you disputing that?  In other words, if NAT is bad because it breaks
protocols how is statefulness any different?

> broken via NAT, so of course nothing exists in your "real world" that

My notion of the real world is broken?  Please do explain.  Real world use is
just what it is, has nothing to do with any individual.

And thank you for admitting the truth, that NAT breaks nothing in real
world use.

Roger Marquis

---

From: Chris Engel <[email-masked]>
Date: Wed, 11 Nov 2009 14:57:51 -0500

It does strike me as a little beside the point as to whether NAT is a "firewall technology" or a "router technology". In practice, the line between those devices is a little blurred these days anyways. Many devices advertised as "routers" have some basic packet filtering capabilities built in to them and almost all firewall devices (as opposed to personal FW software) are capable of doing some routing. Pretty much all those devices are capable of implementing NAT as well.

However, I personally don't see alot of difference between the statements "NAT is bad because it has the capability to break many protocols/applications"  and "Packet Filtering is bad because it has the capability to break many protocols/applications".

The bottom line is that there should be NO EXPECTATION that every application/protocol has connectivity from EVERY end point TO EVERY end point on the NET. In fact, wasn't part of the original DARPA specification that the NET remain significantly useful even in the face of massive disruption to it, with whole sections of nodes dropping out?

Once you put your packets across some-one else's network boundary, you shouldn't assume a mandate that they MUST be delivered. It's the CHOICE of the person who's boundary you are trying to cross into to determine what to do with them.

That NAT CAN (and even DOES) do harm. Sure I'll buy that. However the exact same thing can be said of firewall rules. It's failure to acknowledge the counter-argument that seems problematic.... NAT (just like FW rules) CAN (and even DOES) do benefit as well.

I guess the difference that I've seen argued is that with FW rules you CAN open them up where appropriate to let traffic through. However I don't see NAT being any different then that under IPv6...you CAN choose not to deploy it if the situation warrants or impliment a workaround where neccesary. It's up to you individually to judge what's most appropriate for your environment. There is a far cry between having a REQUIREMENT that you deploy in my mind and having the OPTION that you deploy.

Christopher Engel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Wednesday, November 11, 2009 3:33 AM
To: Brian E Carpenter
Cc: Roger Marquis; [email-masked]
Subject: Re: [nat66] Necessity for NAT remains in IPv6

Regards
   Brian

On 2009-11-11 21:29, Brian E Carpenter wrote:
>> Any router?  Router?  When was the last time anyone implemented NAT
>> on a router?  NAT is a firewall technology, not a router technology.
>
> "This chapter describes how the firewall works in each firewall mode.
> To set the mode at the CLI, see the "Setting Transparent or Routed
> Firewall Mode at the CLI" section on page 3-4.
>
> *Routed Mode Overview
> *Transparent Mode Overview
>
> Routed Mode Overview
>
> In routed mode, the security appliance is considered to be a router
> hop in the network. It can use OSPF or RIP (in single context mode).
> Routed mode supports many interfaces. Each interface is on a different
> subnet. You can share interfaces between contexts.
>
> *IP Routing Support ..."

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Nov 2009 11:54:28 +1300

Despite the tone of some of these message exchanges, if there
is a hole in RFC 4864, I'd like to work towards plugging it.
The IETF week is so intense that I think I'm going to set the
topic aside until I'm back home and rested, however.

Regards
   Brian Carpenter

---

From: Keith Moore <[email-masked]>
Date: Thu, 12 Nov 2009 18:10:54 -0500

> However, I personally don't see alot of difference between the statements "NAT is bad because it has the capability to break many protocols/applications"  and "Packet Filtering is bad because it ha…
One difference is granularity. 

If you just firewall your network, you can always change the
configuration to support new apps or special-purpose hosts as needed. 
On the other hand, if you NAT your whole network - assign private or
ULIA addresses to be used internally and translate at the borders - you
are stuck with NAT.  Chances are good that you can't turn off the NAT,
even for specific hosts or ports, without renumbering your whole
network.  (Okay, you might be able to set up a tunnel through your
NATted network that forwards traffic for a specific global address to a
specific host behind your NAT, but that gets tedious if you need to do
it for many hosts.) So when if you find that you have good reason to
support an application or appliance that doesn't work with NAT, you
won't be able to do that without significant disruption.

This is why firewalls are better for implementing security policy than
NATs.  A firewall gives you a lot more flexibility to implement the
policy you want, and to change it when you need to change it.   NATting
everything just gets in the way.

The distinction between policy and implementation is key.   Nobody is
trying to say that a network operator should not be able to implement a
policy that, say, prevents all externally originated traffic from
reaching one of his internal hosts.   At the same time, it's probably
not a good idea to "carve that policy in stone", so to speak, by relying
on private addressing, and/or investing in lots of hardware that is
designed to NAT but makes a poor firewall.
> The bottom line is that there should be NO EXPECTATION that every application/protocol has connectivity from EVERY end point TO EVERY end point on the NET. In fact, wasn't part of the original DARP…
No.   The intent was that the network would make a "best effort" to
route traffic to its specified destination even in the event of failure
of routers or communications links. 

These days I think we'd say that the network's job is to make a best
effort to route all traffic _that is permitted by policy_ to its
specified destination.
> That NAT CAN (and even DOES) do harm. Sure I'll buy that. However the exact same thing can be said of firewall rules. It's failure to acknowledge the counter-argument that seems problematic.... NAT…
When firewall policy does harm, it's presumably intentional.   If the
firewall breaks an app, the app is broken because it's supposed to be
broken. 

(Of course there are ways in which some firewalls break apps that have
nothing to do with policy, e.g. by breaking SMTP extension
negotiation.    I'm assuming a well-written firewall here.)

When NAT does harm, it's often an "accident", or "collateral damage". 
NATs interfere with applications that are _supposed_ or _expected_ to
work.  Remember that the vast majority of NAT boxes today aren't branded
as NATs - the typical user has no idea that the box is screwing with IP
addresses or even what that means.  The boxes are typically marketed as
"routers" that support "connection sharing".

Consequently, application developers quite reasonably interpret NATs as
damage and try to route around them (which incurs extra expense, raises
cost, lowers reliability, maybe forces changes to the funding model, etc.)

> I guess the difference that I've seen argued is that with FW rules you CAN open them up where appropriate to let traffic through. However I don't see NAT being any different then that under IPv6...…
Again, it's an issue of granularity and flexibility.  If you're just
enabling NAT for one host at a time, so that you can change the mappings
between external addresses and internal hardware, that's no big deal.  
You're not breaking the ability to support apps on all of your hosts
just for the sake of wanting to NAT a few hosts.  But if you're NATting
all of your hosts and using private addresses internally, you can't
easily change your policy to allow an application that is incompatible
with NAT.

Though it begs the question: which is more difficult to change - network
hardware that implements NAT, or people's ways of thinking about NAT?