Subject: Re: [rrg] RRG recommendation

From: [email-masked] (Noel Chiappa)
Date: Sun, 1 Nov 2009 15:36:56 -0500 (EST)

> From: "Stephen D. Strowes" <[email-masked]>

    > a larger layer-3 address space renders NAT redundant

Ah, no. If it were just space, why is there, e.g. NAT66?

For _one_ example of a non-extra-space capability that NAT provides, two
words: provider independence. Others may have different causes to mention...

    > Some recent efforts in the IETF ... at least acknowledge NAT is
    > probably here to stay

Only insofar as the architecture does not provide people the capabilities
they need (see preceeding comment). Had we an alternative which actually met
peoples' needs, over time it might recede (although no faster than IPv4,
where the need for NAT is manifest).

    > In a sense, the "least evil" future of NAT. 

To me, that's like saying that burning someone to death is less evil than
hanging them. Well, maybe, but the difference is 'in the noise'...

>From an architectural point of view, NAT is truly ugly, and not just because
it fiddles with the packet contents. There's also the issue that it's putting
state in the network (and 'engineered' NAT might make that slightly less
ugly, for example by allowing replication, etc, so it's not quite so
brittle), etc, etc.

	Noel

---

From: "Stephen D. Strowes" <[email-masked]>
Date: Sun, 01 Nov 2009 21:29:48 +0000

> hanging them.  Well, maybe, but the difference is 'in the noise'...

Indeed. This is just one direction I've seen people pulling in the IETF. 
I didn't mean to imply that "least evil" was equivalent to "good"... ;-)

> ugly, for example by allowing replication, etc, so it's not quite so

Agree completely. We both suggest that there are reasons why networks 
might want to keep it, and that old views like "NAT is temporary until 
IPv6 rolls out" just aren't as simple as maybe they once sounded. So 
possibly NAT remains a required ugliness?

I'm just not sure what's gained by throwing the question of NAT over the 
fence to the IETF. What will they say differently?

-S.

---

From: William Herrin <[email-masked]>
Date: Sun, 1 Nov 2009 20:34:58 -0400

> words: provider independence. Others may have different causes to mention...

Noel,

>From an architectural point of view, an address-overloaded NAT
firewall is more secure than stateful-nontranslating and packet
filtering firewalls because an error in the firewall is not capable of
opening up the span of internal hosts to direct access from the
external network. It's security is beat only by the application-layer
proxy which is much much uglier.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Eliot Lear <[email-masked]>
Date: Mon, 02 Nov 2009 14:00:12 +0100

> proxy which is much much uglier.

Please let's not do another half-assed job of analyzing the security of 
NATs.  If you REALLY want to take this on, then do it in a real paper 
that includes a complete threat analysis, such as what happens in the 
real world today with browser attacks that REALLY don't care about IP 
addresses.

Eliot

---

From: William Herrin <[email-masked]>
Date: Mon, 2 Nov 2009 09:33:46 -0400

On Mon, Nov 2, 2009 at 9:00 AM, Eliot Lear <[email-masked]> wrote:
>> filtering firewalls
> NATs.  If you REALLY want to take this on, then do it in a real paper that
> includes a complete threat analysis

Eliot,

Even if I cared enough about the topic to do a proper analysis, this
is surely not the forum for it. My comment was offered only insofar as
it supports Scott's proposal that NAT should be treated as a permanent
part of the architecture with whatever impact to routing that happens
to have.

I manage a number of firewalls both personally and professionally. I
use NAT in some of them and packet filters in others, both to
excellent effect in their respective scenarios. There are a couple of
the NAT scenarios I'd be loath to give up.

Regards,
Bill Herrin

---

From: Eliot Lear <[email-masked]>
Date: Mon, 02 Nov 2009 15:42:06 +0100

Bill,

And my point is this:

NAT "Security" is not easily answered in a single paragraph, and you 
cannot support Scott as such.  If one is to say that private addresses 
offer some sort of security above and beyond various forms of firewalls, 
one has to consider what the threat is.  Is it a virus on a port that is 
being LISTENed to?  If so, under what circumstances does NAT provide 
protection, above and beyond firewalls?  It's not as easy as it sounds 
to answer these questions, IMHO.

I can say this: with all of this NAT around, there sure are a VAST 
amount of 0wn3d systems out there.  How much more would there be without 
NAT?

Eliot

---

From: Scott Brim <[email-masked]>
Date: Mon, 02 Nov 2009 09:49:37 -0500

Eliot Lear allegedly wrote on 11/02/2009 9:42 AM:
> cannot support Scott as such.  

Huh?

> amount of 0wn3d systems out there.  How much more would there be without

I would guess not many.  Probably the vast majority of the ones that
would be reachable directly without NAT are being taken over by other
means already.  But this is a digression from the main topic.

---

From: Tony Li <[email-masked]>
Date: Mon, 02 Nov 2009 09:35:49 -0800

A simple question: what does NAT really have to do with our discussion 
about routing architecture?

Regards,
Tony

---

From: Scott Brim <[email-masked]>
Date: Mon, 02 Nov 2009 13:35:30 -0500

The discussion has strayed off the path but what I said originally was:

> - NAT is now architecture.  The IETF needs to decide how much NAT it
>   wants the Internet to have in the future.  This strongly influences
>   what we do in routing/addressing, because outlying, dwindling cases
>   (either the NAT ones or the non-NAT ones) can be handled specially.

---

From: Christian Vogt <[email-masked]>
Date: Thu, 5 Nov 2009 05:19:01 -0500

>>  (either the NAT ones or the non-NAT ones) can be handled specially.

Scott -

Could you clarify which of the following is your point?

- That IETF should decide whether a routing scalability solution should
   be NAT-compatible.

- That IETF should decide whether a NAT-based routing scalability
   solution is acceptable.

I don't think there is a doubt regarding the need for NAT compatibility.
Unless a solution is for IPv6 only, it will have to deal with NATs.

- Christian

---

From: Scott Brim <[email-masked]>
Date: Thu, 05 Nov 2009 04:26:43 -0800

> Unless a solution is for IPv6 only, it will have to deal with NATs.

Neither, I think (and imho even if the Internet were v6 only we would
still have NAT.)  But the amount of NAT in the Internet, and where,
affects the requirements on routing.  Suppose endpoints were upgraded to
handle having IP addresses change in the middle of a session, and
Six/One Router (which includes NAT) was deployed everywhere.  Think
about the job RRG would have to do.  Now suppose completely the
opposite.  So how much NAT there is, and where, affects the parameters
that a change to routing architecture has to address.  As part of
thinking of routing and addressing, the IETF needs to decide what the
engineering goals are for the future of the Internet wrt NAT.

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 08 Nov 2009 13:56:38 +1300

>>   (either the NAT ones or the non-NAT ones) can be handled specially.

An argument has been made, and I don't intend to endorse it, that
stateless NAT66 would be a fine solution to the problems of
multihoming, BGP scaling, and renumbering hassles, all in
one simple wrapper.

In other words, if you accept this argument, there is no problem
with the current (1994 vintage) routing architecture.

[Something about not shooting messenger goes here.]

    Brian

---

From: Christian Vogt <[email-masked]>
Date: Sun, 8 Nov 2009 07:06:09 -0500

> multihoming, BGP scaling, and renumbering hassles, all in

This brings up a more general question:  Should the RRG recommendation
be restricted to those solutions that RRG endorses?  Or should it also
include solutions that have limitations, such as NAT66, along with an
explanation of those limitations?

Although the latter option is more a solution space analysis than a
"recommendation", it would in my opinion be more valuable to the IETF
because it would be more comprehensive.  Thoughts?

> [Something about not shooting messenger goes here.]

Jeez, better put this note to the beginning of your email.  Putting it
at the end is risky.  It might be too late. ;-)

- Christian

---

From: Scott Brim <[email-masked]>
Date: Sun, 08 Nov 2009 21:07:43 +0900

> because it would be more comprehensive.  Thoughts?

This is the point I was trying to make.  As Dave Clark said, "architect
the inevitable".  In order for the IETF to have a strategy for
developing routing, the IETF needs to make a prediction about how much
NAT there will be where.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 08 Nov 2009 13:12:38 +0100

> developing routing, the IETF needs to make a prediction about how much

A very easy thing for him to say.

---

From: Christian Vogt <[email-masked]>
Date: Sun, 8 Nov 2009 09:05:30 -0500

On Nov 8, 2009, Scott Brim wrote:

> In order for the IETF to have a strategy for developing routing, the
> IETF needs to make a prediction about how much NAT there will be  
> where.

Why?  NAT66 stands as a potential solution, with its pros and cons,
independent of such a prediction.

- Christian

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Mon, 9 Nov 2009 00:42:59 -0800

> multihoming, BGP scaling, and renumbering hassles, all in

This argument requires PI space used for outer addresses for session
survivability for provider failure events.  And in that case, well, you
have the entire route-scaling problem in a nutshell.

> [Something about not shooting messenger goes here.]

No problem, I just think your argument above is incomplete.

-Darrel

---

From: Scott Brim <[email-masked]>
Date: Mon, 09 Nov 2009 17:54:19 +0900

> have the entire route-scaling problem in a nutshell.

That assumes no changes to hosts and no pinning of routing.

---

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

> have the entire route-scaling problem in a nutshell.

That's if you want session survivability. If you sacrifice
that requirement, the outer address can be PA. That's probably the
strongest argument against this as a way forward, if you get over
NAT hatred.

   Brian

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Mon, 9 Nov 2009 01:01:00 -0800

> strongest argument against this as a way forward, if you get over

Right, I just wanted to make sure we were comparing apples to apples.

-Darrel

---

From: Christian Vogt <[email-masked]>
Date: Mon, 9 Nov 2009 04:21:46 -0500

> That assumes no changes to hosts and no pinning of routing.

Right, fail-over support in hosts would enable session continuity.
Thus, NAT would be used in combination with Shim6, Six/One, the
name-oriented stack, or something similar.  (Don't know what you mean by
"pinning of routing", though.)

An attractive property of this combination of solutions, deployment-
wise, is the alignment of benefits and costs:  The network operator pays
for provider-independent addressing, by setting up a NAT.  The host pays
for improved session robustness, by upgrading to fail-over support.  And
importantly, there is no dependency between the new network support and
the new host support.  Either one would work without the other.  (Though
fail-overs still depend on support at the remote peer.)

Without intending to sales-pitch this particular combination of
solutions, I think its alignment of benefits and costs is key.

- Christian

---

From: William Herrin <[email-masked]>
Date: Mon, 9 Nov 2009 10:42:07 -0500

On Mon, Nov 9, 2009 at 3:56 AM, Brian E Carpenter
<[email-masked]> wrote:
>>you have the entire route-scaling problem in a nutshell.
>

Which is all well and good in the client case, but in the server case
requires both semantics in the DNS system which are not compatible
with current practice (i.e. applications must be aware of and actually
use the TTL) and try-next-address semantics which are different from
the current sockets API defaults (should try the next address with the
first SYN retransmit but shouldn't give up on attempts to any address
until one of them succeeds).

Regards,
Bill Herrin

---

From: William Herrin <[email-masked]>
Date: Mon, 9 Nov 2009 10:43:27 -0500

> until one of them succeeds).

Correction: the latter is a client issue, so it's not all well and
good in the client case either.

Regards,
Bill

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Nov 2009 11:35:45 +1300

> good in the client case either.

Without being sure that I agree with you completely, Bill, I think
presenting a complete argument about these issues is very much
part of the architectural analysis that we need to back up
the final recommendation. We need an analysis for each of the
major classes of solution, and stateless NAT66 is one of them.
(NAT44 is hopelessly constrained by history and address space,
so doesn't seem to be a serious option anyway, IMHO.)

    Brian

---

From: Eliot Lear <[email-masked]>
Date: Mon, 09 Nov 2009 23:39:06 +0100

On 11/9/09 9:56 AM, Brian E Carpenter wrote:
> That's if you want session survivability.
>    
???

s/session survivability/TCP&SCTP session survivability/

???

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Nov 2009 12:00:44 +1300

Yes, stateful sessions. RFC3582 section 3.1.6 mentions UDP too, however
(and shim6 covers that).

   Brian

---

From: William Herrin <[email-masked]>
Date: Mon, 9 Nov 2009 18:06:03 -0500

On Mon, Nov 9, 2009 at 5:35 PM, Brian E Carpenter
<[email-masked]> wrote:
>>> in the server case

Hi Brian,

I could swear we already did that. IIRC, that's why I grouped the
ideas in Christian Vogt's Six/One Router with the map-encaps in the
solutions summary document instead of splitting it off into its own
section. Six/One Router obviously worked in a system strictly split
between DFZ address space and user address space that distributed a
map to the translators and detranslators but no one could demonstrate
how it would work statelessly or without a strict split in light of
the various DNS issues. I vaguely remember there was also a DNS server
scope problem... ran afoul of some issues discussed in Paul Vixie's
recent rant about "DNS lies."

Regards,
Bill Herrin

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Nov 2009 12:59:47 +1300

> recent rant about "DNS lies."

Not disagreeing, my point is that we need a consensus version of
this in the (supporting text for the) recommendation.

    Brian

---

From: Christian Vogt <[email-masked]>
Date: Mon, 9 Nov 2009 22:26:34 -0500

On Nov 10, 2009, William Herrin wrote:

> Six/One Router obviously worked in a system strictly split

Bill -

Let me chime in since you mention my proposal:  Can you be a bit more
specific regarding these DNS issues?  The idea to avoid them in
Six/One Router was to put both edge (internal) and transit (external)
addresses into the DNS, and to let the address selection mechanisms in
hosts pick an address that works best.  With appropriate prefixes for
edge and transit addresses, this would work without host changes.

- Christian

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 10 Nov 2009 00:01:56 -0800

On Nov 8, 2009, at 4:06 AM, Christian Vogt wrote:

> be restricted to those solutions that RRG endorses?

please define "RRG endorses" here?

as I see it, RRG recommendation should reflect our best collective  
understanding on what is the best solution to handle global routing  
scalability problem, whatever that may be.

> Or should it also
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg

---

From: Christian Vogt <[email-masked]>
Date: Tue, 10 Nov 2009 04:37:17 -0500

> please define "RRG endorses" here?

What I mean by my statement is what you say below:  A "recommendation"
would only consider the single solution that the RRG considers most
appropriate to fix the routing scalability problem.  This is in contrast
to evaluating and comparing multiple alternative solutions, which a
solution space analysis would do.  I personally believe that the
combination of both would be most useful for the IETF.

- Christian

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 10 Nov 2009 06:46:45 -0800

On Nov 10, 2009, at 1:37 AM, Christian Vogt wrote:

> appropriate to fix the routing scalability problem.

I do not recall seeing such a statement
(or if my msg gave that wrong impression, my apology)

>  This is in contrast
> solution space analysis would do.

Please see the Friday agenda that just got posted.

>  I personally believe that the

---

From: Christian Vogt <[email-masked]>
Date: Wed, 11 Nov 2009 04:06:35 -0500

> Please see the Friday agenda that just got posted.

Good.  This issue can better be discussed face-to-face.

- Christian

---

From: Scott Brim <[email-masked]>
Date: Thu, 12 Nov 2009 05:19:11 +0900

> so doesn't seem to be a serious option anyway, IMHO.)

I don't believe the RRG should do this.  My point, way back, was that
the RRG should recommend that the IETF do this, as input to planning
overall routing engineering.  Lixia points out that NAT won't be
everywhere, and that it will go away eventually (same as VA), but if it
is in most places for the next 5 years that has an impact on how we
chart the evolution of the routing and addressing architecture.  The
possible paths to the ultimate goal affect the ultimate goal, and
whether we ever get there.

---

From: Scott Brim <[email-masked]>
Date: Thu, 12 Nov 2009 05:22:08 +0900

> independent of such a prediction.

Well, exactly.  If NAT66 is everywhere then the RRG doesn't need to do much.

---

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

> I don't believe the RRG should do this.

I could read that to mean "we should not present an analysis of the
alternatives to support the recommendation". Am I misunderstanding
what you mean by "this"?

   Brian

---

From: William Herrin <[email-masked]>
Date: Wed, 11 Nov 2009 18:58:57 -0500

> edge and transit addresses, this would work without host changes.

Hi Christian,

Actually, now that you mention it, I'm coming up with a blank as to
how you'd get NAT to multihome statelessly at all even assuming that
session survivability over failures is not required.

In our prior discussions, I always assumed that the remote translator
(with his copy of a portion of the Internet's PI to PA map that
includes me) would restore my PI address to the packet before
delivering it to the endpoint. That's where you get unresolvable DNS
issues because folks starting from PA space need to deal with the
server's PA addresses while folks starting from PI space need to know
the server's PI address but the client isn't asking the authority
server; one in a possible chain of referal servers is. Hence Vixie's
"dns lies" problem.

If the remote translator, lacking my PI to PA map, passes my the PA
source address my translator put on the packet all the way to you and
my translator passes the PA source address your translator put on the
packet all the way to me, we'll end up trying to talk to each other
with different IP addresses.

A PI client (A) with two ISPs and a PI server (B) with two ISPs.

Ip addresses:
A: 1 (internal) 2, 3 (after translation into ISP's space)
B: 4 (internal) 5, 6 (after translation into ISP's space)

Round trip from A to B:
A->(1,5)->(2,5)->(2,4)->B->(4,2)->uh oh, how do I choose between 5 and
6? I've discarded the information that site A chose to talk to me at 5
and if I choose 6 by mistake, we'll see: (4,2)->(6,2)->(6,1)->A. A
sent a packet to 5 but got back a packet from 6.

Hmm. I guess if you add another constraint that a particular PI site
can only have one translator then you can do stateful NAT which
remembers which address to translate a particular flow back to. Let's
run with that assumption for a moment...

So, you're going to have regular split horizon DNS system. And outside
you're going to give me all PA addresses that will translate in to
your PI address. So I get a list of addresses and one of the ISPs is
down right now and packets to that address are dropping into a black
hole. As an app programmer I'm either going to stall for up to 2
minutes trying that address before I move to the next one, or I'm
going to give up on that address early (maybe too early). Or if I'm
fancy, I'll make a non-blocking connect and I'll start another
non-blocking connect on the next IP address in your DNS response every
50 ms until one of them connects. Then I'll drop the others since I
only needed the one.

Ouch. That's not so good.

Then there's the DNS pinning problem. The javascript security model
falls apart if you can change the name to address binding at will. A
bad actor DNS server coupled with a web server could effect a slow
scan of the address space inside your firewall courtesy of the CEO and
his web page with scrolling stock quotes. So, the browser won't change
to a server's alternate IP address once it's picked one that works, or
if it does it follows some arcane rules to avoid exposing you to a
javascript attack. That's not so good either; the user hits reload and
he doesn't necessarily get a shot at your other public IP address.

Regards,
Bill

---

From: William Herrin <[email-masked]>
Date: Wed, 11 Nov 2009 19:07:08 -0500

On Wed, Nov 11, 2009 at 3:08 PM, Scott Brim <[email-masked]> wrote:
> Tony Li allegedly wrote on 11/11/2009 4:28 AM:
>> We already understand enough about the routing token and the transport
>> token to understand that we need to fix this overloading.
>
> But it's not routing's problem that transport misuses location-dependent
> information.

Hi Scott,

Nor is it DNS's fault that applications ignore the TTL binding the
name to the IP address. But I'm going to throw your point about NAT
back at you: for better or for worse, these are now architecture.

Hi Brian,

Does this mean http://tools.ietf.org/html/draft-irtf-rrg-recommendation-02
is moving forward again? I'm willing to try to write a drop-in that
talks to how a NAT66-like system would work (like Christian discussed
with Six/One Router) and what the criticisms are vis-a-vis DNS and
client connection attempt behavior.

Regards,
Bill herrin

---

From: Scott Brim <[email-masked]>
Date: Thu, 12 Nov 2009 09:27:37 +0900

> back at you: for better or for worse, these are now architecture.

I disagree ... and this was one of the points in my very first message
in this thread -- the IETF needs to decide how much to fix this problem
at its root, and to the extent that they don't, how much routing will
have to compensate for not doing so.