Subject: IESG position on NAT traversal and IPv4/IPv6

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 15 Nov 2010 00:19:48 -0500

Hi,
In one of the working group meetings this past week, when the group was discussing a NAT traversal solution for their new protocol, an A-D suggested they not spend much time on NAT traversal.  He/she indicated the IESG was discouraging NAT traversal mechanisms for new protocols, in order to foster demand for IPv6 instead.  The A-D further noted that "we really want it to run over IPv6 more than we want it to run over IPv4".  After being asked for clarification he/she said that "if you build something that will encourage people to stay on IPv4 longer, when you send it into the IESG you will get pushback".

I am not going to name the WG nor A-D, because I'd rather encourage A-D's to speak their mind, and it doesn't matter who it was.  Also, anyone can make a mistake or be mis-interpreted, and perhaps that's all this was. (We don't read written prepared statements at the mic, after all :)

What I'd like to know is the IESG's position with respect to protocols trying to make themselves work around NATs in IPv4.  I'd like to know if the IESG will push back on new protocols if they attempt to work around NATs.

I would also like to understand the IESG's position with respect to IPv6 and whether protocols should not attempt to make themselves work around potential IPv6 NATs; and more importantly to handle the possibility that the firewall-type policies which NATs have by nature, may continue to be used in IPv6 on purpose even if addresses/ports don't get mapped.

I appreciate the workload you are always under, but I think it's important for us outside the IESG to know.  If this is not the right medium/process for asking such questions, my apologies... and please let me know the right way. :)

Thanks,
-hadriel

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 15 Nov 2010 01:06:02 -0500

Designing NAT traversal on a per protocol basis sounds like a mistake to me.

NAT traversal should be something that is supported at a higher level of
abstraction than one protocol. And there seem to be moves towards that
support.

But the idea of trying to starve protocols of features in order to encourage
transition to IPv6 has been tried for the past ten years and utterly failed.
How much more evidence is required?

One of the pathologies of the IETF is that it only takes one member of the
IESG to cling to some outdated dogma for it to survive. I remember I was
once on a panel discussing Web Services security when a person representing
the IETF view went off on a rant against firewalls as unnecessary and
insecure. Which was rather odd given that one of the security ADs at the
time happens to be an author of a pretty well known book on the topic of
firewalls.

One of the worst things a standards organization can do is to hold one set
of work hostage to deployment of some other priority.

The IETF has no power to force adoption of one particular architecture. If
unreasonable demands are made people will take work elsewhere.

On Mon, Nov 15, 2010 at 12:19 AM, Hadriel Kaplan <[email-masked]>wrote:

> Hi,
> In one of the working group meetings this past week, when the group was
> discussing a NAT traversal solution for their new protocol, an A-D suggested
> they not spend much time on NAT traversal.  He/she indicated the IESG was
> discouraging NAT traversal mechanisms for new protocols, in order to foster
> demand for IPv6 instead.  The A-D further noted that "we really want it to
> run over IPv6 more than we want it to run over IPv4".  After being asked for
> clarification he/she said that "if you build something that will encourage
> people to stay on IPv4 longer, when you send it into the IESG you will get
> pushback".
>
> I am not going to name the WG nor A-D, because I'd rather encourage A-D's
> to speak their mind, and it doesn't matter who it was.  Also, anyone can
> make a mistake or be mis-interpreted, and perhaps that's all this was. (We
> don't read written prepared statements at the mic, after all :)
>
> What I'd like to know is the IESG's position with respect to protocols
> trying to make themselves work around NATs in IPv4.  I'd like to know if the
> IESG will push back on new protocols if they attempt to work around NATs.
>
> I would also like to understand the IESG's position with respect to IPv6
> and whether protocols should not attempt to make themselves work around
> potential IPv6 NATs; and more importantly to handle the possibility that the
> firewall-type policies which NATs have by nature, may continue to be used in
> IPv6 on purpose even if addresses/ports don't get mapped.
>
> I appreciate the workload you are always under, but I think it's important
> for us outside the IESG to know.  If this is not the right medium/process
> for asking such questions, my apologies... and please let me know the right
> way. :)
>
> Thanks,
> -hadriel
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

-- 
Website: http://hallambaker.com/

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 15 Nov 2010 11:14:01 +0200

Hi Hadriel,

note that you do not really need to use the he/she convetion to hide the
identity of that AD because all the current ADs are male :o)

In any case, I think I made my *personal* position pretty clear in the
BFCP over UDP discussion we had in the DISPATCH session. NAT traversal
is an essential feature if we want to deploy some of our technologies in
certain scenarios... and we need to make sure our technologies are
deployable. Technologies that are not deployable in the real world
become irrelevant pretty soon.

Cheers,

Gonzalo

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 15 Nov 2010 18:26:33 +0900

> abstraction than one protocol. And there seem to be moves towards that

As there are various kinds of NAT, it is a waste of effort to try
to have a universal NAT traversing protocol.

Instead, we should define some standard NAT for which simplest
NAT traversal is required for widest range of applications.

As end to end NAT with complete end to end transparency does not
require any NAT traversal for all applications, we are done.

> transition to IPv6 has been tried for the past ten years and utterly failed.

So true.

						Masataka Ohta

---

From: Jari Arkko <[email-masked]>
Date: Mon, 15 Nov 2010 14:07:43 +0200

FWIW, I think that we should provide NAT traversal in the protocols that 
we develop (or as a part of some more general toolbox that the protocols 
employ). This is important, and some protocols have been hurt by not 
having such support initially. NAT/FW traversal is also important even 
with IPv6, as you may have a firewall even in IPv6 (or be going through 
a NAT64).

Jari

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 15 Nov 2010 21:18:31 +0900

Jari Arkko wrote:

> NAT/FW traversal is also important even 

FYI, traversable firewall is, by definition, broken.

						Masataka Ohta

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 15 Nov 2010 11:41:31 -0500

On Nov 15, 2010, at 7:21 AM, David Harrington wrote:

> I believe I'm the AD you are referring to.

Yes but I wasn't trying to pick on anyone - just trying to understand what the official IESG position is.

> I never said "the IESG is discouraging NAT traversal mechanisms for new protocols,"

Nope, not in quotes - which was why I didn't put it in quotes.  That was my interpretation of the comments (and I think the interpretation of others in the room, given what the presenter and next person up to the mic said in response).  But absolutely I could have misinterpreted the comments, which was why I was asking for the official IESG position.

> I said (feel free to check the session recording, (ch3-fri-am 1:25), which is where I got the following text from):

I did check the session recording, multiple times, before sending the email.  I also considered not sending the email at all, because I was worried it would become about what you said.  I don't care what you said - you weren't reading a prepared speech. :) 
What I'm more concerned about is what the IESG position is, if there is one.

> If your core protocol ONLY works with an IPv4 NAT'd transport, I believe you will get pushback.

I didn't see the ppsp slides as saying it required a NAT for the protocol to work.  I don't even know how that could work - would it check to make sure there is a NAT??

> The solution should also be able to work in other environments, such as an un-NAT'd IPv6 environment.

Absolutely.  And it should work in environments with IPv6 NATs, and in environments with IPv6 firewalls, and in environments with IPv6 consumer gateways which block inbound packets until an outbound packet opens a pinhole.  All of those fundamentally require the same sort of NAT traversal as for IPv4.  None of us have a crystal ball to tell us how IPv6 will end up being deployed.

Having said all that, I'm curious what makes the IESG believe they have the authority to impose any such future vision/goal on WG proposed standards.  I don't believe RFC 3710, 2026 nor 2418 gives the IESG such discretion.  I could be misreading those RFCs, but I believe the criteria the IESG should be using are in RFC 2026 sections 4.1.1 and 6.1.2, and they're fairly limited.

-hadriel

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 15 Nov 2010 11:55:39 -0500

Masataka-san

You are incorrect.

Firewalls can be used for many purposes. Authenticated traversal is well
established in the firewall model. There is a copious amount of prior art.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 15 Nov 2010 12:07:34 -0500

On Mon, Nov 15, 2010 at 11:41 AM, Hadriel Kaplan <[email-masked]>wrote:

> Absolutely.  And it should work in environments with IPv6 NATs, and in
> environments with IPv6 firewalls, and in environments with IPv6 consumer
> gateways which block inbound packets until an outbound packet opens a
> pinhole.  All of those fundamentally require the same sort of NAT traversal
> as for IPv4.  None of us have a crystal ball to tell us how IPv6 will end up
> being deployed.
>

That is a good point. Regardless of whether I have NAT for IPv6, I will most
certainly operate with inbound connections disabled by default. That has
saved me against all manner of network worms.

One of the features of Stuxnet was that it attacked certain network attached
printers. I have at least two printers that are more than ten years old and
I could not justify paying the $3500 they would cost to replace new. Neither
is supported by the vendor so patches do not exist.

We really need to have the platform vendors provide an infrastructure to
support authenticated port management so that ports are opened for specific,
permissioned applications and not end up with hosts being thrown into DMZ by
default.

> Having said all that, I'm curious what makes the IESG believe they have the
> authority to impose any such future vision/goal on WG proposed standards.  I
> don't believe RFC 3710, 2026 nor 2418 gives the IESG such discretion.  I
> could be misreading those RFCs, but I believe the criteria the IESG should
> be using are in RFC 2026 sections 4.1.1 and 6.1.2, and they're fairly
> limited.

That should be the function of the IAB. But ever since the infamous Kobe
disaster it has not performed that function and neither has anyone else.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Nov 2010 05:41:15 +0900

Phillip Hallam-Baker wrote:

> established in the firewall model.

Given the diversity of firewalls and their operations, it's
practically impossible.

> There is a copious amount of prior art.

Remember what happened to path MTU discovery.

Just as path MTU discovery for IPv6 won't work, you can't expect
firewalls in the real world behave friendly to your own firewall
traversing protocols.

						Masataka Ohta

---

From: Martin Rex <[email-masked]>
Date: Tue, 16 Nov 2010 01:20:37 +0100 (MET)

> FYI, traversable firewall is, by definition, broken.

The reason why the internet hasn't completely collapsed by now
(with half of the nodes being PC drones) are the use of
firewalls&NATs to seperate "internal" networks from the internet,
be it home, organizational or governmental.

Try to convince folks to completely remove all outside doors,
windows, window gates, curtain, blinds, flyscreens from
their home to "leverage" many convenient un-restricted openings
to the interior of the house.  I doubt you mind a lot of followers,
and some of those who do might quickly and painfully find out that
the original access scheme to their house did have a few non-marginal
advantages for life, limb and property.

If your plan is to further delay IPv6 as long as possible, then
making it dependent on unrestricted end-to-end IPv6 connectivity
might be the most reliable approach to ensure the maximum pain
and resistance.

-Martin

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Nov 2010 15:17:16 +1300

In any case, there are four facts of life that can't be ignored:

1. We have a BEHAVE WG and it has a charter.

2. We'd better hope that as many protocols as possible can traverse NAT64, which
will be with us for many years.

3. An important protocol that needs to traverse NAT44 is called IPv6 (in a
tunnel).

4. Address scopes with limited reachability are plentiful, and
the boundaries between them need to be traversed. The problem is a
bit more than just NATs. Oh, there's a draft that mentions this:
draft-carpenter-referral-ps-01.txt, to be discussed on the
[email-masked] list.

   Brian

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Nov 2010 11:43:51 +0900

> to the interior of the house.

I'm not arguing against firewalls. There are various kinds of
firewalls each of which has its own configuration.

Just as path MTU discovery can not stop people filtering
ICMP, firewall traversal protocols can not traverse most
firewalls.

Instead, related parties with firewalls can communicate each
other through proper configuration of their firewalls without
any traversal protocols.

> might be the most reliable approach to ensure the maximum pain

All we need is to enable, but NOT MANDATE, complete end to end
transparency.

It is of course that end to end connectivity can be blocked
by firewalls.

						Masataka Ohta

---

From: Yoav Nir <[email-masked]>
Date: Tue, 16 Nov 2010 13:19:11 +0200

> Given the diversity of firewalls and their operations, it's

Why? Firewalls are not there to block arbitrary traffic. They are there to allow the required traffic, while blocking stuff that is either an attack or violates policy.

> firewalls in the real world behave friendly to your own firewall

Why not?  While I agree that firewalls are diverse, they are all made by vendors, and the big firewall vendors all have employees who participate in the IETF. An IETF standard that allows firewall traversal for legitimate traffic is very likely to be adopted by all the vendors. It might not work with some bargain basement home router you get at Wallmart, but even they eventually get updated software.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Nov 2010 20:59:45 +0900

Yoav Nir wrote:

> Why not?  While I agree that firewalls are diverse, they are all
> made by vendors, and the big firewall vendors all have employees
> who participate in the IETF. An IETF standard that allows firewall
> traversal for legitimate traffic is very likely to be adopted by
> all the vendors. It might not work with some bargain basement
> home router you get at Wallmart, but even they eventually get
> updated software.

According to your theory, a universal NAT traversal protocol
should already exists.

						Masataka Ohta

---

From: Martin Rex <[email-masked]>
Date: Tue, 16 Nov 2010 19:43:56 +0100 (MET)

> According to your theory, a universal NAT traversal protocol

Correct.  It is called the HTTP CONNECT method.

-Martin

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 17 Nov 2010 22:12:04 +0900

> Correct.  It is called the HTTP CONNECT method.

If, with your definition of "traversal", tunneling is a form
of traversal, tunneling by IPSEC is a standard firewall
traversal protocol and is much better than HTTP CONNECT
because of UDP.

So, we are done.

						Masataka Ohta

---

From: "Tadayuki HATTORI" <[email-masked]>
Date: Thu, 18 Nov 2010 00:39:57 +0900

At first, would you like to confirm the protocol is rgiht or wrong,
according to the constitutions of each nation.

It's the matter of right or wrong, not legal or illegal, isn't it?

---
TaddyHatty,

---

From: Martin Rex <[email-masked]>
Date: Wed, 17 Nov 2010 18:41:46 +0100 (MET)

> traversal protocol and is much better than HTTP CONNECT

Not quite.  Tunneling needs matching configurations on both ends,
and that rarely works, in particular on a global scale with
peers you do not know a-priori.

In the general case you have only control (and can modify)
the behaviour of your endpoints and nearby middle boxes on your side
of the network, and the other side is either accessible or not.

Home DSL routers usually do NAT.  For outgoing connections,
they're transparent.  For incoming connections, it is either
possible to configure static mappings (external->internal)
or there might be some dynamic configurability through UPnP.
UDP included.

-Martin

---

From: "David Harrington" <[email-masked]>
Date: Mon, 15 Nov 2010 20:21:40 +0800

Hi Hadriel,
 
I believe I'm the AD you are referring to.
I made the comments as a technical contributor, but also said that my
opinion was informed by discussions within the IESG. 
 
I think your characterization of my comments is a bit incorrect:
"In one of the working group meetings this past week, when the group
was discussing a NAT traversal solution for their new protocol, an A-D
suggested they not spend much time on NAT traversal.  He/she indicated
the IESG was discouraging NAT traversal mechanisms for new protocols,
in order to foster demand for IPv6 instead.  The A-D further noted
that "we really want it to run over IPv6 more than we want it to run
over IPv4".  After being asked for clarification he/she said that "if
you build something that will encourage people to stay on IPv4 longer,
when you send it into the IESG you will get pushback".

I never said "the IESG is discouraging NAT traversal mechanisms for
new protocols,"
 
The slide being shown differentiated the application from the NAT
traversal mechanism.
If your core protocol (ppsp tracker) ONLY works with a NAT'd transport
(which the slides could be interpreted to mean), I believe you will
get pushback.
My advice at the mic was to build the solution in such a way that it
is "transport agile".
I explicitly made the parallel with the security requirement for
algorithm agility.
The application aspects of the solution should not be dependent on a
NAT-specific transport solution.
 
I said (feel free to check the session recording, (ch3-fri-am 1:25),
which is where I got the following text from):
"I want to make sure you do not spend a tremendous amount of time
designing something that works for  all kinds of NATs, because our
goal is to get rid of NATs [said with a grin]. It's not everybody's
goal obviously. The IESG wants to see the migration to IPv6 completed,
and one of the things that we are seriously pushing back on is
anything that will help you keep NATs around longer so you can keep
IPv4 around longer, because we believe that's a bad solution to the
runout of IPv4 addressing. We recognize that right now you need to
deal with IPv4 networks, so therefore you have to deal with this, but
don't build a lot of assumptions into your core protocol because we
really want it to run over IPv6 more than we want it to run over
IPv4."
 
and later "we're trying to get people to go to IPv6. If you are
building something that will encourage people to stay on IPv4 even
longer, when you send this into the IESG you will get pushback."
 
Maybe my language was not as well considered as it should have been,
but it is my understanding that IETF consensus is to have the industry
transition from IPv4 to IPv6.
If your core protocol ONLY works with an IPv4 NAT'd transport, I
believe you will get pushback.
The solution should also be able to work in other environments, such
as an un-NAT'd IPv6 environment.
 
David Harrington

On Mon, Nov 15, 2010 at 12:19 AM, Hadriel Kaplan
<[email-masked]> wrote:

Hi,
In one of the working group meetings this past week, when the group
was discussing a NAT traversal solution for their new protocol, an A-D
suggested they not spend much time on NAT traversal.  He/she indicated
the IESG was discouraging NAT traversal mechanisms for new protocols,
in order to foster demand for IPv6 instead.  The A-D further noted
that "we really want it to run over IPv6 more than we want it to run
over IPv4".  After being asked for clarification he/she said that "if
you build something that will encourage people to stay on IPv4 longer,
when you send it into the IESG you will get pushback".

I am not going to name the WG nor A-D, because I'd rather encourage
A-D's to speak their mind, and it doesn't matter who it was.  Also,
anyone can make a mistake or be mis-interpreted, and perhaps that's
all this was. (We don't read written prepared statements at the mic,
after all :)

What I'd like to know is the IESG's position with respect to protocols
trying to make themselves work around NATs in IPv4.  I'd like to know
if the IESG will push back on new protocols if they attempt to work
around NATs.

I would also like to understand the IESG's position with respect to
IPv6 and whether protocols should not attempt to make themselves work
around potential IPv6 NATs; and more importantly to handle the
possibility that the firewall-type policies which NATs have by nature,
may continue to be used in IPv6 on purpose even if addresses/ports
don't get mapped.

I appreciate the workload you are always under, but I think it's
important for us outside the IESG to know.  If this is not the right
medium/process for asking such questions, my apologies... and please
let me know the right way. :)

Thanks,
-hadriel

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 18 Nov 2010 08:35:56 +0900

> Not quite.  Tunneling needs matching configurations on both ends,

Yes, of course.

> peers you do not know a-priori.

Where is the point to use firewalls or firewall functionality
of NAT to be tunneled by someone you do not know a-priori?

That's why I said:

: FYI, traversable firewall is, by definition, broken.

Or, if you are saying you and your peer are members of some
large organization, the organization can take care of
IPSEC peering configuration.

But, too often, it is a lot easier, a lot more convenient and
a lot more flexible to use ID/password at the application layer,
which is partly why IPSEC is not really deployed.

> they're transparent.

Unlike end to end NAT, legacy NAT is not very transparent.

> For incoming connections, it is either

If you want to run servers behind NAT, you need static IP
addresses and static port numbers, of course.

> or there might be some dynamic configurability through UPnP.

It works only after a connection is established through
a static IP address and a port number.

					Masataka Ohta

---

From: "Tadayuki HATTORI" <[email-masked]>
Date: Thu, 18 Nov 2010 11:26:56 +0900

Hey, are you Japanese or Not?
Have you already quited Japanese?

Anyone should consider about both the protocol and
the constitution of own nation simultaneously.

It's the matter of right or wrong, not legal or illegal.

---
TaddyHatty,

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 18 Nov 2010 13:47:32 -0500

From: [email-masked] [[email-masked]] On Behalf Of David Harrington [[email-masked]]
> designing something that works for all kinds of NATs, because our goal
> is to get rid of NATs [said with a grin]. It's not everybody's goal
> obviously. The IESG wants to see the migration to IPv6 completed, and
> one of the things that we are seriously pushing back on is anything
> that will help you keep NATs around longer so you can keep IPv4 around
> longer, because we believe that's a bad solution to the runout of IPv4
> addressing. We recognize that right now you need to deal with IPv4
> networks, so therefore you have to deal with this, but don't build a
> lot of assumptions into your core protocol because we really want it
> to run over IPv6 more than we want it to run over IPv4."

To my ear, that sounds a lot like what Hadriel said.  Certainly "one
of the things that we are seriously pushing back on is anything that
will help you keep NATs around longer" sounds to me like
discouragement of any comprehenaive (or even effective) NAT traversal
mechanism.

> transition from IPv4 to IPv6.

Certainly the IETF *consensus* is to have the industry transition from
IPv4 to IPv6.  But just as firmly, the IETF *realization* is that IPv4
will be around for another decade or more, with NATs, and if we want
our protocols to be used, we're going to have to deal with it.  I'm
sure that if the IETF does not provide ongoing IPv4 support, Microsoft
will do so...

Dale