Subject: FW: Why?

From: "Tony Hain" <[email-masked]>
Date: Thu, 10 Mar 2005 18:29:14 -0800

> -----Original Message-----
> From: Tony Hain [mailto:[email-masked]]
> Sent: Thursday, March 10, 2005 6:23 PM
> To: [email-masked]'; [email-masked]'; [email-masked]'
> Cc: [email-masked]'
> Subject: Why?
> 
> Why are we wasting effort in every WG and research area on NAT traversal
> crap???
> 
> All week people have been telling me that IPv6 has to show a clear value,
> but those same people are totally writing off the cost of their effort to
> define the array of NAT traversal schemes, the cost of vendors to build
> that crap, then the extensive cost of network managers to operate the
> complex environments that end up being created by this house of cards. It
> is long past time that any protocol that requires a NAT helper is just a
> non-starter and the WG should be closed.
> 
> On another topic, why is it that the API is so sacred that we will create
> a massive array of complex approaches to avoid defining a real session
> layer. We put imitation session efforts at layer 4 (SCTP), layer 3.5
(HIP),
> layer 3.25 (shim), and the TRILL crap is trying to do it at layer 2.5.
> Doing things the hard way allows smart people to feel they are important,
> but it doesn't make the network work better.
> 
> Tony

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

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 10 Mar 2005 18:49:02 -0800

>>Why are we wasting effort in every WG and research area on NAT traversal

FWIW I'm also concerned that we are doing too many different NAT 
traversal protocols. It should be sufficient to just define how IPv6 is 
tunneled across NATs and start using more IPv6 in the applications.

>>layer. We put imitation session efforts at layer 4 (SCTP), layer 3.5 (HIP),

I don't understand what makes you think TRILL is trying to do a session 
layer. If it does, then any other routing and tunneling approach should 
also be given the same verdict.

    Erik

---

From: shogunx <[email-masked]>
Date: Fri, 11 Mar 2005 05:36:00 -0500 (EST)

> tunneled across NATs and start using more IPv6 in the applications.

I agree wholeheartedly.  Lets face the reality of the situation.
Carriers have abused IPv4 for financial reasons.  As a result, NAT is
widely deployed, because it was and is an effective workaround for
dealing with siad carriers trying to squeeze extra money from IP
addresses.  There is nothing that can be done about that now, except
implement the solution that has been written to solve the problem, IPv6,
right on top of the existing NAT's.  With full application layer support
for v6, NAT will eventually deprecate, and be little more than a bad
memory.  The open source community has a wide variety of v6 enabled
daemons and clients already, for almost every widely used protocol.  While
these can easily be implemented on any host, good luck getting the general
public to do so.  The solution for migration most likely lies in somebody
developing a little v6 router, that autoconfigs a tunnel with a small
allocation of addresses.

Scott

> also be given the same verdict.

sleekfreak pirate broadcast
http://sleekfreak.ath.cx:81/

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 11 Mar 2005 07:04:52 -0500

This discussion seems to take as a premise the view that if we define 
applications only on IPv6, even though they could be defined on IPv4, that 
this will give people a reason to use IPv6.
It also seems to take as a premise that if we don't define ways to work 
around NATs, people won't use the applications with NATs.

The fact is that external evidence indicates that both premises are false.
For a long time we tried ignoring NATs.  As a result, people crafted many 
strange and non-interoperable ways to work with NATs.
I know of several initiatives that tried to define their protocols for 
IPv6.  Some even thought they had good reasons.  Before the work was even 
done, I saw customers requesting vendors to supporting the initiative using 
IPv4 directly.

Trying to pretend something won't work with IPv6 is not a substantive value 
add for IPv6.

Not needing NAT is a minor value add for IPv6.  But we have already seen 
several major corporations publicly indicate that they intend to use NAT 
with IPv6, even though they can get enough public address space.

As far as I can tell, following through on the kind of approach discussed 
here would simply make our products les useful, and reduce actual 
interoperability in the field.

Yours,
Joel M. Halpern

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 11 Mar 2005 07:53:55 -0600

I think it should be in the other way around. Show the developers and
service providers that some applications can take advantage of IPv6 and
require less effort to be developed (because no need to care of the NAT),
and consequently less cost, less investment.

IPv6 is an innovation opportunity, and makes life more simple to everyone,
and consequently can generate more business.

The ISPs need to look IPv6 as a way to aggregate services and applications
and get a couple of extra euros for every service, every month, form every
customer. This can make a huge difference, specially when the revenues for
the access price are going down and down (and the bandwidth high and high),
and consequently they will not even able to cover the access cost with that
fees.

Starting to charge for IPv6 addresses, using IPv6 NAT, and so on, will not
help, on the other way around, will bring us to the same situation as with
IPv4 in terms of innovation and development of services and applications:
BUSINESS.

In the long-term I don't think the Telcos/ISPs will take that path, because
is against their business, their opportunity to add value to their networks.
But they may have for some time the wrong perception about this, and is also
our mission to avoid that happening as much as possible, probably educating
them, as I feel this only happens precisely because the lack of knowledge or
strategic vision about the future of Internet.

What we can do about that ?

Regards,
Jordi

> De: "Joel M. Halpern" <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Fri, 11 Mar 2005 07:04:52 -0500
> Para: "[email-masked]" <[email-masked]>
> Asunto: Re: FW: Why?
>

---

From: Edward Lewis <[email-masked]>
Date: Fri, 11 Mar 2005 09:29:46 -0500

I am not here to defend NAT, but...(and I can't resist answering a 
blue-sky subject line)

>and consequently can generate more business.

I mean this as a reality check, not an argument.

"makes life more simple to everyone" is a subjective statement. 
There are some people that get comfortable with a way of doing 
business or solving a problem.  These people are generally not 
engineers, and are more likely to be in operations.  I am not saying 
the operators are anti-innovation, but if your job is operations, a 
stable environment is a good environment.  "The devil you know is 
better than the devil (or angel) you don't."

>and consequently they will not even able to cover the access cost with that

My comment is not directed at the revenue end of the "business" but 
at the staffing end of the business.  The pool of unemployed 
operators-to-be (generalizing) is more aware of how to manage NAT'd 
networks than the pool of those knowing new (pick'em) technology. 
I.e., operations managers can and should deal with innovation, 
rank-and-file workers aren't employed to change the world.

>What we can do about that ?

Get operators involved.  Not just ISPs but enterprises - medium to 
power users.  You're not going to get the small and personal users, 
they don't have time for the IETF.

Getting operators involved does not mean reading internet drafts.  It 
means engaging them in dialog, deriving operational requirements from 
them.  It means inviting and baiting them into workshops.  (They 
won't show just because you email them, you have to get them to show.)

I am saying this from the experience of DNSSEC, that long-lived 
project to extend DNS.  In retrospect, one reason it has taken so 
long is that initially it was defined by security experts without the 
input of operators.  Operators have come into the fold and now there 
is an operations-friendly proposal.  But operators don't come as one 
unified bloc, new operators come to the table all the time with more 
input.  This is why there are still discussions over details in the 
protocol.

I realize that NAT breaks the theoretical idea of the network layer 
being end-to-end and I realize the consequences.  All protocols would 
be simpler if universal addressing was a reality, as the textbooks 
say it should be.  If life were like the textbooks, extending 
features would be fun and easy, a thousand flows would bloom.

But reality isn't according to theory.  The Internet with NAT, 
"split-brain" DNS, firewalls, etc., and a client-server mentality is 
proving useful to many folks today.  As engineers we have to deal 
with that, not ignore it, as we try to innovate further.

To make this clear - I am not saying I want to protect NAT, etc.  I 
think it is foolish to engineer as if it was a nuisance.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Achieving total enlightenment has taught me that ignorance is bliss.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 11 Mar 2005 14:42:23 +0100

I have a totally different evaluation of the IPv6 issue I suggest you to 
consider.

IPv6 was specified as "IPv4 with larger addresses", this is what has been 
delivered and this is what is deployed by the RIRs and demanded by the 
market. One uses IPv6 as an extended IPv4 space. Any pressure for IPv6 will 
give the feeling that IPv6 is not IPv4 fully compatible and will lead to a 
disinterest of IPv6 (because IPv6 is the least used one, please will strive 
for stability). To say that IPv6 is better is even worse and will push 
people to better IPv4 (with NATs and others). To look for "the killer 
application" is the worst signal to the market: the market does not want 
revolution but services. (NATs are a general patch concept: HTTP.1.1 is 
another way to save on IP addresses which is more blocking the Internet 
development than NATs. NAT are now userboxes which are used for many other 
purposes and will stay).

The reason we need IPv6, IMHO is totally different. We need its size and 
flexibility to switch the internet from being an access network to an 
interactive network. I explain: when you start building a network you build 
its addressing to optimize the routing with the resources you have 
(centralized then  decentralized network -the network of networks is 
decentralized). Then your network grows, and there is a time it can become 
a distributed network (the initial Paul Bahan/Louis Pouzin catenet concepts 
now permitted). The leader is no more the routing but the directory. So, 
you do not adapt the addressing to the routing (as do the RIRs) ,you design 
the routing to match the addressing. IPv4 or IPv6 is allocated along the 
same line by the RIR. This was the initial phase of the internet. In the 
case of the Internet its mature phase needs addressing schemes most 
probably more based upon geopolitic structures of the demand (but it would 
be fool to dedicate the addressing to such an approach only).

The IETF had five things to do.
1. to identify the need. It did it with "longer address". It did not 
identify the legacy/global transition aspect (NGN?) but that was really up 
to the ICANN process to do it.
2. to develop the standard. Done.
3. to guide the experimental phase what it did with the legacy deployment 
(RIRs). Done.
4. to transfer to the market operators what has been made with NRO being 
now formed and now ITU. May be sometime Space and Geography blocks. Done.
5. to support their specific needs to permit them to be complementary and 
adequate to their markets, their coopetition supporting their deployment 
and fostering cost reduction, stability and innovation. This is the phase 
we are entering now.

The first need they all have is that IPv4 becomes fully IPv6 compatible. 
When this is achieved, the transition is achieved.
For what it may be worth, from the users side.
jfc

At 13:04 11/03/2005, Joel M. Halpern wrote:
>done, I saw customers requesting vendors to supporting the initiative 
>using IPv4 directly.
>
>Trying to pretend something won't work with IPv6 is not a substantive 
>value add for IPv6.
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 11 Mar 2005 09:12:42 -0600

Below, in-line.

Regards,
Jordi

> De: Edward Lewis <[email-masked]>
> Fecha: Fri, 11 Mar 2005 09:29:46 -0500
> Asunto: Re:Why?

I can't give details here, but some people is already having new business
because that. *IS* reality check.

> better than the devil (or angel) you don't."

Yes, they feel comfortable, but they are not safe ;-)

I was not referring anyway to non-engineers, but mainly application
developers, service providers, etc. They can have a better experience when
doing their job with IPv6 in mind, specially if they ignore IPv4. This is
possible today, even if you need to use tunnels all the time, or other
transition mechanisms such as Teredo, among others.

Those transition mechanisms, in this phase, don't create any operational
stability problem in the IPv4 network.

> input.  This is why there are still discussions over details in the

Agree and I'm already doing that most of my time ;-).

But still we need new ideas to attract them. I now is not probably the IETF
job, maybe ISOC and some other organizations should be much more deeply
involved here ?

> with that, not ignore it, as we try to innovate further.

I don't agree with that. The COST of doing that with NAT vs doing with IPv6
is a very important technical and economical consideration.

---

From: Tim Chown <[email-masked]>
Date: Fri, 11 Mar 2005 15:10:59 +0000

> with IPv6, even though they can get enough public address space.

Do you have pointers to these indicators?   I assume the reason is lack of
PI space, or is it a mixture of the other commonly cited reasons?

Tim

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 11 Mar 2005 15:24:07 -0800

> around NATs, people won't use the applications with NATs.

I suffer from no such disillusions as those are not the premise for the
initial note, though without having the background in the original note it
is easy to see why someone might come to that conclusion. 

My assumption is that the market will not ignore the opportunity to develop
NAT traversal technologies. That does not equate to a need for the IETF to
waste valuable resources standardizing hacks that attempt to mask previous
hacks. In particular the IAB needs to be looking forward and helping the
application community understand that there are approaches today that allow
them to ignore the nonsense that has grown in the network by using IPv6
tunneling as a NAT traversal tool. This approach completely avoids the need
for complex and error prone ALGs.

> using
> value

I assume you meant 'without IPv6', and the point is completely lost on the
IETF that we -can- build complex NAT traversal, but that does not mean we
should. Intelligent people find the challenge stimulating so it is easy to
understand the lure of solving the hard problem. At the same time the
resulting complexity makes no operational sense at scale and substantially
raises the costs of running the network and developing or deploying new
applications. The result is not a win for the Internet as a whole.

> with IPv6, even though they can get enough public address space.

They have been sold the NAT == Security kool-aid. See:
draft-vandevelde-v6ops-nap-01.txt

> interoperability in the field.

Generating hack after hack is raising the operating cost of the network. The
frog is in the pot and the water temperature is rising. Does it have to
reach a boil before we recognize that we should have left that environment
behind? 

Tony

---

From: Keith Moore <[email-masked]>
Date: Fri, 11 Mar 2005 23:28:20 -0500

> But we have already seen several major corporations publicly indicate 
> that they intend to use NAT with IPv6, even though they can get enough 
> public address space.

we need to give them a clear message that IPv6 was not meant to be used 
in this way, that IPv6 is intended to support a wider range of 
applications than is possible with IPv4+NAT, and that IPv6 applications 
cannot be expected to work in the presence of NATs.  if people want to 
build dysfunctional networks, that's their own business - there are no 
standards police that I know of.  but our job is to describe the 
necessary and sufficient conditions for interoperability.  and a 
necessary condition for interoperability in the v6 world (really in the 
v4 world also) is the absence of NAT.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 14 Mar 2005 10:34:51 -0500

inline.

> for complex and error prone ALGs.

I agree that ALGs are not the answer, and I believe the reasons for that 
are treated in:

http://www.ietf.org/internet-drafts/draft-iab-nat-traversal-considerations-00.txt

As I mentioned during the plenary, the document above makes a case that 
the right answer in many situations are vpn-ish technologies that 
include v6 tunnels. However, different applications have different 
needs, and there are real differences between the various vpn-ish 
solutions (TURN, STUN, teredo, etc.) that are driving their development 
and adoption. For VoIP, where the nat traversal issue has been 
especially painful, the increase in voice latency, packet loss, and 
substantial cost increase of relaying traffic through the tunnel 
servers, has driven people to solutions like STUN. Thus, I cannot agree 
that there only needs to be a single solution here.

That said, I agree that the IAB nat traversal consideration document 
lacks adequate consideration of how evolution plays into this, and I'll 
endeavor to improve the document on that front.

Another concern I have is that, in an IPv6-only world, even if you 
eliminate NAT, there will still be firewalls, and those firewalls will 
frequently have the property that they block traffic coming from the 
outside to a particular IP/port on the inside unless an outbound packet 
has been generated from the inside from that IP/port. This means that IP 
addresses are not globally reachable. You'd still need most of the same 
solutions we have on the table today to deal with this problem. Indeed, 
in the VoIP space, I believe you'd need pretty much everything, 
excepting you'd be able to remove a single attribute from a few of the 
protocols (STUN and TURN in particular), which tell the endpoint its 
address on the other side of the NAT. The endpoint knows its address, 
but all of the protocol machinery is still needed to rendezvous with the 
other participant in the call.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 14 Mar 2005 17:06:03 +0100

Regarding the firewalls and IPv6, I agree with your comment, but also there
are some other reasons why that's bad, see:

draft-vives-v6ops-ipv6-security-ps-03.txt
and
draft-palet-v6ops-ipv6security-02.txt

Regards,
Jordi

> De: Jonathan Rosenberg <[email-masked]>
> Fecha: Mon, 14 Mar 2005 10:34:51 -0500
> Para: Tony Hain <[email-masked]>
> CC: "[email-masked]" <[email-masked]>
> Asunto: Re: FW: Why?
> 
> inline.
> 
> Tony Hain wrote:
> 
>> Joel M. Halpern wrote:
>>

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 14 Mar 2005 16:46:33 -0800

Jonathan Rosenberg wrote:
> ...

I have a fundamental problem with an IAB document that implies NAT provides
a firewall. The artifact of lack of state is exploited to prevent inbound
connections, but that has nothing to do with a policy rich firewall, and
even less to do with anything resembling 'security'. 

As I said in an earlier post, the entire focus of this document is the wrong
direction for the IAB. It should be focused on simplifying application
operation, so there should be no NAT in the title. The IAB should be looking
at how applications can avoid worrying about the convolution in the network,
not focusing on how to navigate it.

It is also broken in that it focuses on Client/Server application models,
which are generally less of an issue for applications in a NAT environment.
Peer-to-peer applications have more trouble with mangled headers so the
second thing to do (after changing the title & focus) is to rework this so
that P2P issues are up front.

> that there only needs to be a single solution here.

You appear to be too focused on the weeds to notice the path forward. Yes
many of the IPv6 transition technologies have the same issues as the NAT
traversal technologies in IPv4 (in many cases they do exactly the same thing
but with different encapsulated packets). That said if the applications
community doesn't get the point that they can leave all that crap behind
when native IPv6 is available to them then they will never move. If the
applications community doesn't do their part we will always be stuck with
the garbage in the network. 

> endeavor to improve the document on that front.

I will try to send text, but I am buried for the next couple of months.

> has been generated from the inside from that IP/port. 

There is work going on outside the IETF to deal with this issue. There is no
point in wasting years arguing when progress can be made in the real world.

> This means that IP
> solutions we have on the table today to deal with this problem. 

Not necessarily. 

> Indeed,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Mar 2005 15:44:59 +0100

...
> other participant in the call.

I think this is why we chartered MIDCOM in the first place. Maybe
people would like to help with that work?

   Brian

---

From: Keith Moore <[email-masked]>
Date: Tue, 15 Mar 2005 10:51:13 -0500

>> eliminate NAT, there will still be firewalls, and those firewalls 
>> will frequently have the property that they block traffic coming from 
>> the outside to a particular IP/port on the inside unless an outbound 
>> packet has been generated from the inside from that IP/port. This 
>> means that IP addresses are not globally reachable. You'd still need 
>> most of the same solutions we have on the table today to deal with 
>> this problem. Indeed, in the VoIP space, I believe you'd need pretty 
>> much everything, excepting you'd be able to remove a single attribute 
>> from a few of the protocols (STUN and TURN in particular), which tell 
>> the endpoint its address on the other side of the NAT. The endpoint 
>> knows its address, but all of the protocol machinery is still needed 
>> to rendezvous with the other participant in the call.
>
> I think this is why we chartered MIDCOM in the first place.

MIDCOM has always seemed like the wrong direction to me.  We don't need 
a way for apps to open up holes in firewalls, because that makes 
firewalls useless for dealing with rogue apps.  And while there is 
still some utility to be gained from perimeter defenses, the notion of 
firewalls as a primary defense against attack is anachronistic at best 
(and that's being kind).

What we need is an architecture for multilayered defense that allows 
centralized policy specification (which is merged with host policy) and 
which is application-aware.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 15 Mar 2005 17:22:42 +0100

Hi Keith,

Then you may be interested in this effort:
draft-vives-v6ops-ipv6-security-ps-03.txt
draft-palet-v6ops-ipv6security-02.txt

Regards,
Jordi

> De: Keith Moore <[email-masked]>
> Fecha: Tue, 15 Mar 2005 10:51:13 -0500
> Para: Brian E Carpenter <[email-masked]>
> CC: "[email-masked]" <[email-masked]>, Jonathan Rosenberg <[email-masked]>
> Asunto: Re: Why?
>

---

From: Melinda Shore <[email-masked]>
Date: Tue, 15 Mar 2005 10:25:06 -0500

> I think this is why we chartered MIDCOM in the first place.

Yes, and midcom as currently specified does support firewall attributes.

To get back to the broader questions, when we set out to do midcom and
to address the general problem of middleboxes our priorities included
restoring, to the extent possible, end-to-end function, and "security"
where security included both securing the protocol itself as well as
not interfering with end-to-end security, which really is a terrible
problem with many types of middleboxes.

As NAT traversal work has gone forward in other parts of the IETF I
think those priorities have been lost, or at least shifted down the
list.  That's not a good thing.  I think part of the problem has been
that telecomm-type applications tend towards heavy mediation of
control data and some mediation of user data.  Another problem is a
real-world problem, and that's that it's a lot easier to throw new
crap into a network than it is to modify what's already there.  I'm
not sure how to solve that particular problem, but while I disagree with
Tony's proposed solution to the NAT situation I think he's 100% correct
in his characterization of it.

I'd like to see the IETF refocus its NAT traversal efforts on trying
to adhere to good architectural principles.  If that's too airy,
perhaps the question should be framed as whether or not the proposed
mechanism allows securing communication between two endpoints.

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Tue, 15 Mar 2005 11:16:35 -0500

On Tuesday, March 15, 2005, at 10:51 AM, Keith Moore wrote:
> centralized policy specification (which is merged with host policy) 
> and which is application-aware.

You mean like midcom?

Melinda

---

From: Keith Moore <[email-masked]>
Date: Tue, 15 Mar 2005 22:20:20 -0500

>> and which is application-aware.

no.  for the most part, apps shoudn't have to be aware of the existence 
of middleboxes, and there shouldn't be an either/or decision about 
trustworthiness of the app.  (you might make an exception for certain 
kinds of explicit proxies.) rather the middleboxes and apps should all 
be made aware of the network's policy and all expected to enforce it at 
a level which is consistent with their function.  there should be 
strict limits as to the degree to which a middlebox can interfere with 
e2e traffic.  other components, e.g. intrusion detection should also be 
made aware of the policy so that they can detect when it is violated 
and raise appropriate alarms.

---

From: Joe Touch <[email-masked]>
Date: Fri, 18 Mar 2005 10:54:32 -0800

>>layer 3.25 (shim), and the TRILL crap is trying to do it at layer 2.5.

TRILL does not NAT, nor does it need specific mechanisms to traverse 
NATs (it works fine behind or in front, and isn't intended to be 
deployed across NATs).

If you have specific issue with the "TRILL crap", please provide details 
that indicate you have at least read the "TRILL crap".

Joe (co-author of the "TRILL crap")

---

From: Joe Touch <[email-masked]>
Date: Sat, 19 Mar 2005 05:31:18 -0800

> NATs (it works fine behind or in front, and isn't intended to be 

FWIW, TRILL also does not emulate a session layer either, any more than 
the state in routing or bridging does.

Although you have issue with session layer emulation and its overuse, 
beware the words of Abraham Maslow: "when the only tool you have is a 
hammer, everything _LOOKS_ like a nail" [emphasis mine]. TRILL is not a 
nail.