Subject: [nat66] Preliminary BOF Request

From: Margaret Wasserman <[email-masked]>
Date: Tue, 20 Jan 2009 22:21:49 -0500

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

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 23 Jan 2009 14:26:25 -0800

Any and all discussions in the IETF related to nat MUST NOT imply any kind
of security. The fact that product marketing departments do that is
absolutely out of scope, as the IETF needs to stay focused on the technical
reality that mangling the header does not have any security impact (try to
take a static 1:1 address mapping and show how that node is any more secure
than it would be without the nat). To that end, bullet 2) creates an invalid
set of goals for this proposed bof. 

Independent of that, the entire 'we have to do this because we can' mindset
should be questioned. There has not been a demonstrated need for a 66nat,
just claims that 'people will build it so we should define it'. The
motivation is the same 'promote product interoperability' that was used to
force NAT-PT off the experimental track to PS. It took several years to
recognize how misguided that decision was, but fortunately it occurred
before people felt forced into IPv6 deployments, so it did not see
widespread use. Handing people the 'feel-good' familiar nat tool in the name
of security, will be like handing a loaded gun to someone intent on
committing suicide. There will be no way to recall this, as simply marking
an RFC to historic will not remove a wide-scale deployment, or deter vendors
from shipping products (note that the bof proposal is based on vendors
shipping products despite the lack of a document to begin with, so why would
they care about a recall). It could be argued that poor application
interaction with 66nat is really in the best interest of the end user, as
they would be removed as impediments, where making it just-passable will
condemn the world to an unnecessarily complex topology forever. 

This proposed bof will be a waste of time and energy for an already
overloaded IESG, though keeping people that insist on doing this work
occupied and away from real progress would not be a bad thing...

Tony

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Margaret Wasserman
> Sent: Tuesday, January 20, 2009 7:22 PM
> To: [email-masked]
> Cc: Magnus Westerlund
> Subject: [nat66] Preliminary BOF Request
> 
> 
> Here is a preliminary BOF request that I've put together for a NAT66-
> related BOF at IETF 74.  I'm sending it to all four of the Internet and
> Transport ADs, as I am not sure it has been decided which area would be
> the best home for this work.
> 
> Thoughts or comments on this BOF proposal?
> 
> Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 23 Jan 2009 17:43:39 -0500

Hi Tony,

> set of goals for this proposed bof.

"Simple Security" is one of the primary reasons cited for using NAT,  
and the IPv4 NAT property of blocking inbound connections is an  
important part of some security solutions.  While I agree that NAT is  
not the only, and probably not the best, way to achieve this  
functionality, it is a feature of NATs that is widely used, and relied  
upon, in IPv4.

If we go with a one-to-one, two-way algorithmic mapping, our NAT  
solution will not have this property.  IMO, we need to make it clear  
that our solution does not have this property, and also make it clear  
how this property can be obtained.  Our v6ops documents already  
recommend the use of a firewall for IPv6 networks.  There also seems  
to be some consensus view that a similar type of functionality can be  
obtained using a "stateful firewall", but (as far as I know) we have  
not actually specified how to build/configure a firewall to block  
inbound connections while allowing outbound ones, and I think we  
should do that.

When we do go through the exercise of defining this solution, it will  
be interesting to see how it compares to IPv4 NAT in terms of its  
architectural impact on the network.

Margaret

---

From: james woodyatt <[email-masked]>
Date: Fri, 23 Jan 2009 14:53:29 -0800

On Jan 20, 2009, at 19:21, Margaret Wasserman wrote:
> related BOF at IETF 74.  I'm sending it to all four of the Internet  
> and Transport ADs, as I am not sure it has been decided which area  
> would be the best home for this work.
>

Skipping past the summary (tl;dr)...

> 1) A Best Current Practices (BCP) RFC describing how to obtain
> the Simple Gateway and Simple Security features of NAT without
> performing address translation.  This document is intended for home
> gateway manufacturers and other standards bodies that define home
> gateway functionality.

Recommend rewriting this section as follows: "1) A Best Current  
Practices (BCP) RFC, which is to be intended for residential gateway  
manufacturers and other standards bodies that define functional  
requirements of residential gateways, that describes why NAT66 is  
neither necessary nor advised, and also references existing and  
forthcoming RFCs that describe how residential IPv6 gateways with  
simple security should function."

> 2) A Standards-Track (PS) RFC that describes an IPv6 Network
> Address Translation mechanism that provides the Simple Security and
> Address Independence benefits of IPv4 NAT, while minimizing the
> problems caused by IPv4 NAT.  This solution is expected to involve a
> one-to-one, algorithmic address mapping mechanism with no port
> mapping.  It may or may not include a checksum-neutral mapping
> algorithm and/or a cryptographic mapping mechanism.

Agree with Tony Hain.  IPv6 Network Address Translation (NAT66) MUST  
NOT be confused with IPv6 Simple Security (the topic of another draft  
in V6OPS, i.e. draft-ietf-v6ops-cpe-simple-security, which *does*  
attempt to mirror the stateful filtering behavior of IPv4 NAT).  Also,  
since NAT66 doesn't provide the security features of IPv6 Simple  
Security, and there is no consensus that a need exists for the Address  
Independence facility it attempts to provide, I don't see why NAT66  
should be standards-track.

Recommend rewriting this section as follows: "2) An Experimental (EXP)  
RFC that describes an IPv6 Network Address Translation mechanism that  
provides some address independence at the expense of some of the  
familiar problems caused by NAT with IPv4.  This experimental solution  
is expected to involve a one-to-one, algorithmic address mapping  
mechanism with no port mapping.  It may or may not include a checksum- 
neutral mapping algorithm and/or a cryptographic mapping mechanism."

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Fred Baker <[email-masked]>
Date: Fri, 23 Jan 2009 16:48:25 -0800

On Jan 23, 2009, at 2:26 PM, Tony Hain wrote:

> just claims that 'people will build it so we should define it'.

that isn't quite accurate. You will recall an entire presentation on  
the topic I gave at the last IETF giving two major reasons, one of  
which is very much under discussion in rrg to improve internet scaling?
_______________________________________________
nat66 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nat66

---

From: Fred Baker <[email-masked]>
Date: Fri, 23 Jan 2009 18:44:01 -0800

Pretty much

On Jan 23, 2009, at 5:52 PM, Christian Huitema wrote:

> So, what are the expected benefits?
>
> I have so far heard the following:
>
> 1) Simple security;
> 2) Network structure concealment;
> 3) Provider independence;
> 4) Multi-homing
>
> As Tony and James pointed out, simple security is not a function of  
> address translation, but rather a function of the firewall. It is  
> the classic "don't allow a packet to come in if it is not recognized  
> as the answer to a previous packet that came out". There are various  
> implementations, with various properties, depending on what people  
> mean by "recognized as an answer", i.e. by source address, by source  
> address + port, by address pairs, by address pairs + source port, by  
> address pairs plus port pairs. Behave spent a lot of time parsing  
> that out for NAT44.
>
> The network concealment is an interesting feature in some cases,  
> although its usefulness is probably widely overrated in the presence  
> of browser or flash cookies. There are two basic variants, depending  
> on the amount of concealment desired: 1-1 mapping between internal  
> and external, or 1-N mapping. I am sure someone someday will try 1-N  
> mapping, and the result will be amusing. That is, if you have a  
> perverse sense of humor.
>
> The provider independence feature is what Fred alluded to in his  
> previous message. The idea is to get some kind of static internal  
> structure, and then present different external addresses depending  
> on the provider of the day. It certainly has some advantages,  
> although provider independent addresses provide pretty much the same  
> result to customers. (Not to providers, of course.)
>
> The multi-homing feature combines some aspects of provider  
> independence with the old 8+8 idea. It has pros and cons, e.g.  
> simpler than SHIM6 but also less robust to changes in multi-homing  
> configuration.
>
> All of these have interesting engineering challenges of their own,  
> interesting effects on applications like SIP, and interesting  
> interaction with security protocols, for example IPSEC.
>
> Is that what we are speaking about?
>
> -- Christian Huitema
>
>
>

---

From: Christian Huitema <[email-masked]>
Date: Fri, 23 Jan 2009 17:52:03 -0800

1) Simple security;

As Tony and James pointed out, simple security is not a function of address translation, but rather a function of the firewall. It is the classic "don't allow a packet to come in if it is not recognized as the answer to a previous packet that came out". There are various implementations, with various properties, depending on what people mean by "recognized as an answer", i.e. by source address, by source address + port, by address pairs, by address pairs + source port, by address pairs plus port pairs. Behave spent a lot of time parsing that out for NAT44.

The network concealment is an interesting feature in some cases, although its usefulness is probably widely overrated in the presence of browser or flash cookies. There are two basic variants, depending on the amount of concealment desired: 1-1 mapping between internal and external, or 1-N mapping. I am sure someone someday will try 1-N mapping, and the result will be amusing. That is, if you have a perverse sense of humor.

The provider independence feature is what Fred alluded to in his previous message. The idea is to get some kind of static internal structure, and then present different external addresses depending on the provider of the day. It certainly has some advantages, although provider independent addresses provide pretty much the same result to customers. (Not to providers, of course.)

The multi-homing feature combines some aspects of provider independence with the old 8+8 idea. It has pros and cons, e.g. simpler than SHIM6 but also less robust to changes in multi-homing configuration.

All of these have interesting engineering challenges of their own, interesting effects on applications like SIP, and interesting interaction with security protocols, for example IPSEC.

-- Christian Huitema

---

From: james woodyatt <[email-masked]>
Date: Sat, 24 Jan 2009 16:29:46 -0800

> simpler than SHIM6 but also less robust to changes in multi-homing  

I would say that it's only one of several available approaches to  
provider independence while preserving a static interior topology  
without requiring smaller sites to use PI allocations.  It has the  
unique advantage of not requiring existing IPv6 node implementations  
to be revised, but it comes at the expense of the non-trivial and well- 
known consequences of network address translation.

While SHIM6 is complicated, I would say that its main detraction as an  
alternative to NAT66 is that it doesn't have a very good incremental  
deployment story.  It is, however, not the only way to design a shim  
layer aimed at giving us multi-homing and provider independence.  I  
suspect there are better ways to address that problem, which would  
still require updates to existing IPv6 node implementations while  
allowing for a more incremental deployment than SHIM6 does.

Shorter james: I think the expected benefits in Provider Independence  
and Multi-homing are red herrings, and the real argument for NAT66 is  
that it Applies No Pressure To Upgrade Existing Node Implementations.

I don't think this concern is worth having.

We have already decided that an update to existing node  
implementations -- e.g. for something like NAT64, etc. instead of  
standardizing on NAT-PT -- will be necessary to facilitate IPv6  
transition in the presence of both IPv4-only and IPv6-only endpoints.

I say we should just find a better tunnel/shim mechanism than SHIM6 at  
the same time we are going about the NAT64 thing and revise the IPv6  
node and router requirements in one big document drop.

Call it "IPv6-2010: Attack Of The Shims" or something and use it to  
drive a whole new upgrade cycle.

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 24 Jan 2009 22:16:11 -0500

On Jan 24, 2009, at 7:29 PM, james woodyatt wrote:
> to be revised, but it comes at the expense of the non-trivial and  
> well-known consequences of network address translation.

In addition to avoiding the use of provider-allocated addresses inside  
the site, some network administrators also want to avoid the need for  
their ISP(s) to route their PI addresses.  I am not 100% sure why, but  
given the problems that I've experienced in situations where my  
companies have asked our ISPs to route our IPv4 PI addresses  
(allocated from swamp space), it would seem that this type of  
configuration is less reliable and requires significantly more  
coordination than having the ISP route the ISP's own addresses and  
using a NAT box for provider-independent addressing within the site.

> While SHIM6 is complicated, I would say that its main detraction as  
> an alternative to NAT66 is that it doesn't have a very good  
> incremental deployment story.  It is, however, not the only way to  
> design a shim layer aimed at giving us multi-homing and provider  
> independence.  I suspect there are better ways to address that  
> problem, which would still require updates to existing IPv6 node  
> implementations while allowing for a more incremental deployment  
> than SHIM6 does.

I would very much like to see a multihoming solutions (based on SHIM6  
or otherwise) that is as easy to deploy (and as incrementally  
deployable) as NAT.  Even if we can figure out a way to do that,  
though, it will be a while before it is standardized and available,  
and I think we'll see IPv6 NAT deployment in the meantime (and perhaps  
in parallel).

Margaret

---

From: Rémi Després <[email-masked]>
Date: Sun, 25 Jan 2009 09:57:34 +0100

Christian, Fred,

I had a similar but longer list in a presentation in Minneapolis
(http://www.ietf.org/proceedings/08nov/slides/behave-15.pdf slide 3):
1. Local addressing independence (Easy renumbering)
2. Multi-homed CPEs
3. Incoming connection filtering
4. Topology Hiding (invisibility of private routing plans)
5. Host privacy (no visible association of connections to individual
hosts).

While points 1-4 are essentially in agreement with Christian's 1-4
(permuting 1 & 3, and 2 & 4, and making them somewhat more explicit),
point 5 should IMO be added to Christian's list:
- Consecutive HTTP requests from a browser that doesn't keep cookies
cookies cannot, from the outside of a NAT44 site, be recognized as
coming from the same host.
- Some users may wish, in IPv6, to keep this type of NAT44 dependent
privacy , at least for some of their web activities.

Another point made in Minneapolis, is roughly that, if CPEs are NAT66
capable in any way, hosts should be able to control whether they are
permitted to modify addresses or not (noted by Dave Thaler in the last
sentence of http://www.ietf.org/proceedings/08nov/minutes/behave.txt):
- In IPv6, host should be able to protect *end-to-end transparency*
whenever and wherever desirable for applications.
- This capability, which has been lost in IPv4 with NAT44s, should not
be lost also in IPv6.
This point should IMO be in the list of items to be discussed.

Regards,

RD

Fred Baker  -  le (m/j/a) 1/24/09 3:44 AM:

Fred Baker  -  le (m/j/a) 1/24/09 3:44 AM:
>> 1) Simple security; 2) Network structure concealment; 3) Provider
>> independence; 4) Multi-homing

---

From: james woodyatt <[email-masked]>
Date: Sun, 25 Jan 2009 10:34:01 -0800

On Jan 24, 2009, at 19:16, Margaret Wasserman wrote:
>
> [...] I think we'll see IPv6 NAT deployment in the meantime (and  
> perhaps in parallel).

p1. it remains to be seen whether IPv6 NAT deployments will be  
successful at trading off transparency and interoperability for the  
benefits we are only *supposing* they will provide.

p2. by itself, the deployment of IPv6 NAT is not a reason for IETF to  
*standardize* it.  we are deploying IPv6 Simple Security today, and no  
one is arguing that it should be standardized.

---

From: james woodyatt <[email-masked]>
Date: Sun, 25 Jan 2009 10:36:49 -0800

> whenever and wherever desirable for applications.

Which prompts me to ask the annoying question: should hosts be  
required to opt *IN* or *OUT*?  I don't see any reason why hosts  
should be required to opt OUT, but I'm prepared to hear arguments for  
it.  I expect they will be highly entertaining.

---

From: Fred Baker <[email-masked]>
Date: Mon, 26 Jan 2009 05:17:09 +0000

On Jan 25, 2009, at 6:36 PM, james woodyatt wrote:

> should be required to opt OUT, but I'm prepared to hear arguments  
> for it.  I expect they will be highly entertaining.

That comment ("hosts should be able to opt out") sounds like an  
interesting and irrelevant comment. If for example I am using NAT in  
some form to implement GSE (such as using Lancaster University's  
prototype Linux implementation), and am using a ULA internal to a  
network, the ULA will not have routing outside and the only external  
routing in the network is likely to be a default route leading to the  
GSE gateway. So the effect of opting out will be to disable external  
connectivity. Think about the mechanics of this...
_______________________________________________
nat66 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nat66

---

From: Christian Huitema <[email-masked]>
Date: Sun, 25 Jan 2009 21:29:42 -0800

> connectivity. Think about the mechanics of this...

Good thing that STUN already defines operation for detecting NAT66 mappings...

-- Christian Huitema

---

From: Fred Baker <[email-masked]>
Date: Mon, 26 Jan 2009 05:57:31 +0000

really

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Jan 2009 10:35:42 +1300

It seems to me that these points were all discussed at some
length, if not in the same exact words, in RFC 4864.
I'm not seeing anything new in this discussion, except
the idea of using NAT66 instead of providing architectural
solutions to the gaps identified in that RFC.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Jan 2009 10:39:52 +1300

James,

On 2009-01-25 13:29, james woodyatt wrote:
...
> suspect there are better ways to address that problem, which would still
> require updates to existing IPv6 node implementations while allowing for
> a more incremental deployment than SHIM6 does.

I'd be interested to see a proof of concept that this can be done. There
was quite a lot of discussion of alternative approaches before the shim6
direction was chosen, reflected in RFC 4177, 4218 and 4219.

    Brian

---

From: Fred Baker <[email-masked]>
Date: Tue, 27 Jan 2009 04:41:36 +0000

Then you must be talking about a very different GSE than I am.

---

From: Rémi Després <[email-masked]>
Date: Tue, 27 Jan 2009 11:42:47 +0100

Brian E Carpenter  -  le (m/j/a) 1/26/09 10:35 PM:
> It seems to me that these points were all discussed at some length, 
> if not in the same exact words, in RFC 4864. I'm not seeing anything
>  new in this discussion, except the idea of using NAT66 instead of 
> providing architectural solutions to the gaps identified in that RFC.
> 
> 
> 
> 
> 
I agree that RFC 4864  is a great starting point for all this discussion:
it contains more useful details than any reasonable  e-mails
can contain, and covers well the analysis status in May 2007.

Yet, there is room left, IMHO, for BETTER isolating where, and for which
purpose, IPv6 addresses might usefully be modified in CPEs.

Only when this is done, IMHO again,  it will be time to decide whether
what is left should be called NAT66, or should rather be called
differently to avoid confusion (in particular if the retained solutions
would just be "architectural").

More comments below on the two point which, in my understanding, are
worth making beyond RFC 4864:

1. HOST PRIVACY

In the gap analysis of  RFC 4864, the closest reference to Host Privacy,
as I define it, is under "Minimal Traceability of Privacy Addresses" (6.3).

It suggests that privacy addresses would be a basis for a solution.
But, unless privacy addresses would be changed more frequently than
realistic, they don't prevent that, from the outside,  consecutive Web
requests from a same host can be identified as such.

To do better, I introduced an approach in
www.ietf.org/proceedings/08nov/slides/behave-15.pdf, where CPEs perform
a stateless scrambling by of:
(1) the part of an internal address which is after the ISP prefix;
(2) bits 2-15 of the internal port number if it is a dynamic port.

It seems now that his scrambling should advantageously be limited to Web
requests (external port 80), to eliminate the risk of interfering with
possible expectations of other applications.

So far, no one has shown interest for this approach, but it remains on
the table.

2. HOST PRIVACY "ON DEMAND"

Let us consider a site where IPv6 internal routing is based ULAs
(typically *to avoid renumbering difficulties*, a legitimate concern),
and where at least some hosts know the /48 prefix an ISP has assigned to
their site, so that they can build their own global addresses.

Such a hosts can take as source address of  its  outgoing packets
either its ULA or its global address.

(Note that, in the global address case, global packets have to be
encapsulated in local ones. Otherwise, reverse path forwarding in
intra-site routing would prevent site traversal.)

- Prefix conversion by CPE(s) has to be performed if internal source
addresses are ULAs.
- Conversion must be avoided if source addresses are global (a  sign of E2E
transparency expectation).

This may still be unclear, or controversial. Bu I hope it will be seen
as a contribution to the (useful) debate.

Regards,

RD

>> (http://www.ietf.org/proceedings/08nov/slides/behave-15.pdf slide 
>> 3): 1. Local addressing independence (Easy renumbering) 2. 
>> Multi-homed CPEs 3. Incoming connection filtering 4. Topology 
>> Hiding (invisibility of private routing plans) 5. Host privacy (no
>>  visible association of connections to individual hosts).
>> 
>> (permuting 1 & 3, and 2 & 4, and making them somewhat more 
>> explicit), point 5 should IMO be added to Christian's list: - 
>> Consecutive HTTP requests from a browser that doesn't keep cookies 
>> coming from the same host. - Some users may wish, in IPv6, to keep 
>> this type of NAT44 dependent privacy , at least for some of their 
>> web activities.
>> 
>> Another point made in Minneapolis, is roughly that, if CPEs are 
>> NAT66 capable in any way, hosts should be able to control whether 
>> they are permitted to modify addresses or not (noted by Dave Thaler
>>  in the last sentence of 
>> http://www.ietf.org/proceedings/08nov/minutes/behave.txt): - In 
>> IPv6, host should be able to protect *end-to-end transparency* 
>> whenever and wherever desirable for applications. - This 
>> capability, which has been lost in IPv4 with NAT44s, should not be
>>  lost also in IPv6. This point should IMO be in the list of items
>> to be discussed.
>> 
>> Regards,
>> 
>> RD
>> 
>> 
>> 
>>>> 1) Simple security; 2) Network structure concealment; 3) 
>>>> Provider independence; 4) Multi-homing
>> _______________________________________________ nat66 mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/nat66
>> 
> 
>

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 27 Jan 2009 14:11:26 -0800

Every implementation where the network presumes omniscient knowledge about
what the end user intended is inherently broken. GSE is not only doing that,
it is saying that 'it doesn't matter what the end user wanted, the network
admin for the router currently holding the packet gets to do whatever they
want to the header'. There will be no way to diagnose what is going on,
because every packet could take a very different path as each hop along the
way distorts reality with its own nat66 policy, which might include
load-balancing. 

It looks like the only cure for this nat66 nonsense is to mandate AH
everywhere...

Tony 

> Of Fred Baker
> Sent: Monday, January 26, 2009 8:42 PM
> To: Brian E Carpenter
> Cc: Christian Huitema; 'Margaret Wasserman'; [email-masked]; 'Magnus
> Westerlund'
> Subject: Re: [nat66] Preliminary BOF Request
> 
> 3):
> explicit),
> NAT66

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 27 Jan 2009 15:13:05 -0700

RFC 3489 did not support v6 address families but 5389 does - have a  
glance at section 15.1.

---

From: Fred Baker <[email-masked]>
Date: Wed, 28 Jan 2009 06:42:00 +0000

> It looks like the only cure for this nat66 nonsense is to mandate AH  

In which case we will once again find out just exactly how much power  
a statement by the IETF requiring network administrators to do  
something has. All point to point interfaces default to PPP, right?

> Every implementation where the network presumes omniscient knowledge  
> about what the end user intended is inherently broken. GSE is not  
> only doing that, it is saying that 'it doesn't matter what the end  
> user wanted, the network admin for the router currently holding the  
> packet gets to do whatever they want to the header'. There will be  
> no way to diagnose what is going on, because every packet could take  
> a very different path as each hop along the way distorts reality  
> with its own nat66 policy, which might include load-balancing.

I understand your viewpoint. That is in fact part of why I specified  
the BUPT prototyping effort the way I did - to force a worst case  
oscillation in addressing and drive the test crazy.

     ftp://ftpeng.cisco.com/fred/gse/nat66-gse.html

That said, I rather strongly suspect that your view of the end user  
doesn't work in the Internet even without NATs. Let's imagine that one  
has two addresses and a target system/service has one addresses, and  
both ends are using shim6. Let's further assume that the two systems  
are respectively in Singapore and Canberra, and that the two ISPs in  
Singapore have different contracts with the ISP in Canberra; one  
routing traffic directly, and the other via an intermediate Tier 1.  
Yes, I'm referring to the little routing test Geoff conducted and  
reported to the IAB perhaps ten years ago. By choice of address pair,  
one had the opportunity of using an 80 ms RTT or one that was over 600  
ms. And let's note that since these are three different ISPs with  
three different prefixes, no static rule on source or destination  
address choice can be guaranteed to work.

What is the user's intention? I will give strong odds that it is to  
"access the peer machine for some particular transaction in the manner  
that completes the transaction in the least wall clock time". It might  
be to download a picture or html file, send an email, or etc. And the  
only way that it will make the right choice is by either (a) monkeying  
with DNS to only present the address that has a relatively short RTT  
or (b) monkey with routing to send the datagram on the short delay  
path. But standard routing is not about delay (I was at the time  
arguing that expected path delay should be available in routing to  
enable such decisions), it is about contracts.

Now, if I am allowed to, I can force such things to work right in  
routing, and in so doing GSE would select the corresponding address  
pair. shim6 lacks the information, apart from some form of history or  
reputation mechanism.

So in that case, GSE has a hope of serving the user's intent, and  
shim6 gets it right some percentage of the time.

Believe it or not, I am also a strong supporter of the end to end  
principle. What I believe, that you apparently don't, is that there is  
value in the network helping the user achieve his intended goals. I  
also believe that there is a fair bit of state and intelligence in  
routing that the user's administration uses to meet its goals, which  
is valid and relevant and may be at odds with the actual user - if the  
"user" is a virus, we usually prefer that the user loses that  
particular battle.

So please don't be knee-jerk here. The NAT66 proposal (and the one  
like it but without the checksum offset mechanism that GSE originally  
proposed) don't have the same effect as NAT44; they don't prevent  
access. What they do is create a situation in which a host that thinks  
it has one address on a given interface in fact has several, which a  
peer should choose among and might change its mind concerning as it  
interacts with routing. But the user's intent rarely has anything to  
do with the value of the address - let me ask, when you ask google  
where to find content and you click on a link, do you even know what  
the address was, and if you did would it affect you in any way? The  
user's intent has far more to do with the behavior of the application  
he has chosen. So I will argue that a technology that enables the  
routing system to have a number of prefixes comparable to the number  
of transit networks in the world and enables any system to address a  
peer anywhere else achieves the user's probable intent regardless of  
whether the technology in question rewrites the locator. 
_______________________________________________
nat66 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nat66

---

From: Fred Baker <[email-masked]>
Date: Wed, 28 Jan 2009 06:42:04 +0000

Magnus:

If you grant a BOF, I would suggest that there be an agenda item to  
permit those who are simply opposed to NATs to talk, and a separate  
agenda item for those who would like to have discussions concerning  
NATs and NAT-related technology. The reason is that we will need some  
time in which "damn it I hate NATs and will DOS every discussion of  
them" is specifically off-topic. I'm not opposed to having dissent,  
but unless it is recognized and managed, there will be no chance for a  
reasonable discussion - we will spend the whole meeting fending off DOS.

Fred

On Jan 27, 2009, at 10:11 PM, Tony Hain wrote:

> about

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 28 Jan 2009 07:58:34 -0500

This is an excellent idea.  I wonder if there is a way to phrase this  
as a constructive agenda item?  Maybe "the case against NAT in IPv6"  
or something like that?

The problem here is that there are people who believe that "NAT" is  
the enemy.  They make a false distinction between NAT and  
"architectural solutions".  They love SHIM6, even if it is run in a  
proxy, because it isn't NAT...  But, how is SHIM6 run in a proxy all  
that "architecturally" different than a NAT box with end-to-end  
signaling and a significant incremental deployment problem?

Margaret

On Jan 28, 2009, at 1:42 AM, Fred Baker wrote:

> NATs and NAT-related technology. The reason is that we will need  
> some time in which "damn it I hate NATs and will DOS every  
> discussion of them" is specifically off-topic. I'm not opposed to  
> having dissent, but unless it is recognized and managed, there will  
> be no chance for a reasonable discussion - we will spend the whole  
> meeting fending off DOS.
>
> Fred
>

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 28 Jan 2009 10:41:03 -0800

> enable such decisions), it is about contracts.

It might be, or it might be that one transaction has little impact on
another. Consider the case where one isp provides low-latency modest
bandwidth, while another provides high-bandwidth with moderate-jitter. The
end user would clearly want voice traffic to go over the low-latency path,
and would also clearly want a streaming video feed to avoid that path due to
the marginal bandwidth and its likely impact on the voice traffic. The
omniscient routing system you propose would 'help' the end user by directing
the video stream due to contractual arrangements between the ISPs, and the
end user would have no say in the matter so they would always get crappy
voice, or always have the voice drop out when a video stream is running. 

> shim6 gets it right some percentage of the time.

Shim6 was DOA, because it inherently breaks what little security
architecture there is, and GSE has the same problem because edge firewall
rules can't be informed in real-time in a trusted manner about the header
changes that the omniscient routing system is making. Assuming that the only
place that rewrites a header is an enterprise firewall is naive at best ...

> "user" is a virus, we usually prefer that the user loses that

The difference in our viewpoints is that I recognize that there are multiple
administrations with conflicting goals along the path, where maybe one of
them actually cares about the end user, just maybe. The issue is that the
network 'intelligence' requires input from the user to even attempt to meet
their goal, but historically has refused to accept that input as 'too much
state'. 

> interacts with routing. 

If it were the peer getting to choose I would have fewer problems. GSE is
about letting every administration along the path arbitrarily rewrite the
header to meet its goals, not any other ISP's goals, and certainly not
either endpoint's goals. Since there is no secure communication between the
arbitrary ISP rewrite and the firewalls near the endpoints, there is no way
to establish state that is meaningful beyond the syn packet.

> But the user's intent rarely has anything to

It can't be open-loop, so if rewriting is supposed to occur it would make
more sense for the network to inform the end system to send the packet that
way to begin with using SCTP's multiple address capability. At least with
that approach, SCTP-aware firewalls would have a chance of keeping up. 

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Jan 2009 11:52:13 +1300

On 2009-01-29 07:41, Tony Hain wrote:
...
> architecture there is

It doesn't break IPsec. Can you clarify what you believe it breaks?

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Jan 2009 11:58:55 +1300

On 2009-01-29 01:58, Margaret Wasserman wrote:
> 
> This is an excellent idea.  I wonder if there is a way to phrase this as
> a constructive agenda item?  Maybe "the case against NAT in IPv6" or
> something like that?

Either that, or simply declare the topic out of scope. Certainly
it must not block the main discussion.

> 
> The problem here is that there are people who believe that "NAT" is the
> enemy.  They make a false distinction between NAT and "architectural
> solutions".  They love SHIM6, even if it is run in a proxy, because it
> isn't NAT...  But, how is SHIM6 run in a proxy all that
> "architecturally" different than a NAT box with end-to-end signaling and
> a significant incremental deployment problem?

I'm not sure the people who like shim6 necessarily like proxy shim6,
which is not well enough defined anyway.

    Brian

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 28 Jan 2009 15:08:06 -0800

Firewall state assumes that all packets in a stream will have the same address. Change the address after state is established and see if the packet gets forwarded by the router.

Tony

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Wednesday, January 28, 2009 2:52 PM
> To: [email-masked]
> Cc: 'Fred Baker'; 'Christian Huitema'; 'Margaret Wasserman';
> [email-masked]; 'Magnus Westerlund'
> Subject: Clarification re shim6 [Re: [nat66] Preliminary BOF Request]
>

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 28 Jan 2009 15:09:53 -0800

> which is not well enough defined anyway.

You might even want to note that not everyone that is opposed to nat66 likes shim6 in any form... ;)

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Jan 2009 13:25:38 +1300

Stateful firewalls are hardly an architecture. But anyway, this is
an issue for the shim6 list.

Thanks
    Brian

---

From: Fred Baker <[email-masked]>
Date: Thu, 29 Jan 2009 08:45:08 +0000

On Jan 28, 2009, at 6:41 PM, Tony Hain wrote:
>> I will argue that a technology that enables the routing system to  
>> have a number of prefixes comparable to the number of transit  
>> networks in the world and enables any system to address a peer  
>> anywhere else achieves the user's probable intent regardless of  
> It can't be open-loop, so if rewriting is supposed to occur it would  
> make more sense for the network to inform the end system to send the  
> packet that way to begin with using SCTP's multiple address  
> capability. At least with that approach, SCTP-aware firewalls would  
> have a chance of keeping up.

You may recall that I proposed something like that at one point; that  
in a shim6-like network with overlaid prefixes, if A, which had  
addresses a' and a", addressed B and the datagram went through the  
wrong DMZ, the DMZ would reply "repeat this request using this  
address". I suspect that there are attacks in that; a mis-configured  
DMZ might literally send the wrong address.

But more to the point, the other reason that shim6 is DOA is the level  
of complexity it imposes on the edge administrator. Administrations I  
talk with tell me that they are unwilling to manage that level of  
complexity as they don't see it buying them anything, and oh by the  
way take a walk through RFC 3582's goals and ask how many shim6 meets.

I would argue that the opinions of the actual end user and/or his  
agent on his machine is only one part of the "user's intent" question.  
Another part is the administration that supplies his Internet service.  
Now if he is supplying his own service, that's one thing. But for most  
of us, the service is in fact something we hire an IT department to  
supply for us or contract with an access ISP, and the agreement with  
that administration gives them a certain level of voice in that "end  
user intent". So discussions that bring every nitty-gritty point back  
to "I want the network to ask my mother-in-law her opinion" pretty  
quickly become nonsense; she doesn't know and she doesn't care. She  
has an ISP or an IT department and expects them to take care of that.

There is one further, and in my mind very fundamental, point I'm  
making here. We really do need the ability to have a discussion on GSE  
or other uses of the technology, knowing and understanding that you  
and others don't find such uses compelling and consider all  
administrations to be attacking their users rather than supplying SLA- 
guaranteed services to them. If you can tell me how to address the  
concerns you raise in a way that administrations that might use it  
would consider acceptably straightforward, I'm all ears. But the  
discussion that continually recurs in this area doesn't sound  
constructive. It has the effect of a DOS - it prevents us from having  
any other discussion than "Tony and others don't like NATs and will  
filibuster every use of the word to stop them".

I need for these discussions to lead in a constructive direction.  
"Don't do that" isn't constructive. Neither is "I can imagine a  
complete melt-down in which some idiot designs a network poorly and  
nothing works". Yes, but is that really the norm? "I have these issues  
and would consider them addressed if the following requirements were  
met" is constructive, and would be both helpful and interesting.

Am I making sense?

---

From: Fred Baker <[email-masked]>
Date: Thu, 29 Jan 2009 09:05:49 +0000

IPsec != Security. Never did.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 29 Jan 2009 09:26:29 -0800

> address".

Thinking of it, it ought to be possible to replicate the functionality of SHIM6 by defining a globally named overlay on top of NAT-afflicted networks. Something along the lines of Teredo would work, if the rendezvous service can manage the global identifiers. Of course, that would end up not very different from an identifier plus locator split...

-- Christian Huitema

---

From: Scott Brim <[email-masked]>
Date: Thu, 29 Jan 2009 12:33:29 -0500

Excerpts from Christian Huitema on Thu, Jan 29, 2009 09:26:29AM -0800:
> > You may recall that I proposed something like that at one point;
> > that in a shim6-like network with overlaid prefixes, if A, which
> > had addresses a' and a", addressed B and the datagram went through
> > the wrong DMZ, the DMZ would reply "repeat this request using this
> > address".
> 
> Thinking of it, it ought to be possible to replicate the
> functionality of SHIM6 by defining a globally named overlay on top
> of NAT-afflicted networks. Something along the lines of Teredo would
> work, if the rendezvous service can manage the global identifiers.
> Of course, that would end up not very different from an identifier
> plus locator split...

... for certain kinds of identifiers.  

Are you thinking these would look like addresses?  If so, how would
routing be done?  Would a source forward a packet toward a system of
rendezvous servers which would then translate the header addresses and
forward the packets on?  Are you thinking that translation would be
something like DNS?  I'm asking because I suspect that whatever form
your solution takes, it will look a lot like something we're already
exploring.  

Scott

---

From: Ted Hardie <[email-masked]>
Date: Thu, 29 Jan 2009 10:00:14 -0800

>it must not block the main discussion.

Hmm, since the main point of a BoF in the IETF is to determine
whether or not the community supports the working going forward
here, I would have some trouble with a move to declare out of
scope the objections.  If you're going to do that, skip the BoF, eh?

Managing the time so that people can describe the proposed work
and discuss it is rationally is clearly necessary.  But if someone
gets up at the mic and says "this class of activity damages my use
of the Internet", that can't be out of scope for a BoF like this. 

That's my personal opinion, anyway.
				regards,
					Ted Hardie
_______________________________________________
nat66 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nat66

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Jan 2009 09:39:13 +1300

> of the Internet", that can't be out of scope for a BoF like this. 

That's OK, as long as there is space for the counter-argument,
which goes "this is going to happen anyway, so we need to
write a spec that minimizes the damage." But those positions being
stated, they shouldn't prevent the technical discussion. Personally,
I think the existence of those two positions is well established
and not very productive to spend time on. I agree with *both*
of them, by the way.

   Brian

---

From: Ted Hardie <[email-masked]>
Date: Thu, 29 Jan 2009 13:46:21 -0800

At 12:39 PM -0800 1/29/09, Brian E Carpenter wrote:
>write a spec that minimizes the damage."

I hope the argument actually says:  "Here are the requirements
which we need met, and this is why this approach satisfies them."
That allows you to have the discussion of whether exploring
other approaches which satisfy the same need (and may have
different trade-offs) is in or out of scope.  Starting with
"this is going to happen anyway"  will leave that discussion
popping up in the corners throughout the life of the WG.

> But those positions being

If the BoF leaders can find a way to have the folks holding these
positions talk to each other rather than past each other, I will
count it a great success. 
			good luck,
				Ted
_______________________________________________
nat66 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nat66

---

From: Fred Baker <[email-masked]>
Date: Fri, 30 Jan 2009 07:30:37 +0000

I would agree. I am not opposed to the topic being discussed. But take  
a look at this email thread. How much discussion is about NATs, their  
proposed algorithms, and their proposed uses, and how much is about  
"we don't want no stinkin' NATs"?

Put it on the agenda, and in part of the agenda declare it off topic.

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 30 Jan 2009 14:06:35 -0800

> "we don't want no stinkin' NATs"?

That would be because the proposed use creates an infrastructure based
impediment to the end user where the dubious 'value' is only perceived by a
few of the many transit administrations along the path. Working around this
impediment requires complex & fragile 3rd party services to inform the
endpoints about how to lie to their peer about who they are conversing with.
Never mind the task of keeping that updated in real-time as the transit
administrators change 'reality' on the fly, either due to transient
failures, or arbitrary attempts to shift traffic around. 

This entire discussion is not about how to create a better environment for
application development and deployment. It is simply about 'we can, so we
want to no matter what the outcome will be'. 

Tony

---

From: Fred Baker <[email-masked]>
Date: Fri, 30 Jan 2009 22:26:11 +0000

> want to no matter what the outcome will be'.

You continue to willfully ignore my entire presentation on the topic  
of more scalable routing and addressing, given in the behave meeting  
last Novemebr, and whose slides are included in Margaret's slides in  
the proceedings.
_______________________________________________
nat66 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nat66