Subject: [rrg] The case for NAT66

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 12 Nov 2008 12:55:17 +0100

Sorry for crossposting, but I think this is relevant both for BEHAVE  
(NAT people) and RRG (routing people). Please prune the to/cc in your  
replies as appropriate.

We've had some discussions about NAT66 on the BEHAVE list which were  
mostly the traditional issues: people will implement it regardless, if  
the IETF produces a spec at least we can avoid more brokenness than  
necessery, etc.

These are all relevant arguments. But there is a reason why NAT66 may  
be useful that goes beyond all of that. In 1996 Mike O'Dell came up  
with an idea named 8+8 and later GSE where the top 64 bits of the IPv4  
address are used for routing and the bottom for identification. This  
is problematic for a number of reasons, but one aspect of this idea is  
very promising: routers get to rewrite the top 64 bits of addresses.

Currently, either routers ignore the addresses and then we have no  
accountability if a user with ISPs A and B sends a packet with an A  
address to B, or B blocks the packet and we have accountability but no  
connectivity. This is an issue that we didn't really manage to solve  
with shim6, which uses the "take addresses from all ISPs" model.  
Rewriting in routers would give us both connectivity AND  
accountability, as well as a hint for the return path.

With some extra logic, a proxy shim6 can be built on top of this  
rewriting capability that would make shim6 much more palatable to many  
end-users so it may reduce the demand for PI address space and  
therefore the pressure on the routing system.

So if we adopt NAT66 we will be giving up something (the idea that  
referrals can work easily) but at the same time we gain a lot of  
potential for the future. But only if we specify NAT66 such that it  
can apply to all transports and still allow incoming sessions. If we  
end up with an IPv4-style port overloading NAT66 we gain nothing and  
lose a lot.
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Christian Vogt <[email-masked]>
Date: Wed, 12 Nov 2008 19:34:16 +0200

Iljitsch -

You are right.  Fail-over functionality for multi-homed networks suffers
from a deployment problem because it requires support on both ends of a
connection.  We could conquer the deployment problem if we specified the
fail-over functionality as part of NAT66, thereby piggybacking the
deployment of the fail-over functionality to the deployment of NAT66.

In fact, in doing so, we would exploit vendors' desire for standard
compliance to make them implement the fail-over functionality, and we
would exploit operators' perceived benefits of NAT to make them deploy
the functionality.  Sounds like a reasonable deployment strategy.

BTW, we did already discuss this idea on the BEHAVE list.  Check this:

http://www.nabble.com/Why-IETF-should-standardize-IPv6-NAT-to20290669.html#a20293096

In that thread, we considered that NAT66 is the same as the Unilateral
mode of Six/One Router [1], and that we could augment NAT66 to support
also Six/One Router's Bilateral mode.  Having said this, I do believe
that NAT66 should be standardized also for other reasons [2].

- Christian

[1] http://users.piuha.net/chvogt/pub/2008/vogt-2008-six-one-router-design.pdf

[2] http://www.ietf.org/mail-archive/web/behave/current/msg04611.html

---

From: Christian Vogt <[email-masked]>
Date: Wed, 12 Nov 2008 19:34:16 +0200

Iljitsch -

- Christian

---

From: Mark Townsley <[email-masked]>
Date: Thu, 13 Nov 2008 11:09:17 +0100

I would prefer not to have the same discussion again and again in 
multiple places. Let's just try and stick to behave for the moment, 
though at some point if the work continues it would need to be passed 
around elsewhere. We are not chartering the work one way or another at 
the moment, for now this is merely "discussion" of the topic.

- Mark

Margaret Wasserman wrote:
>
> Hi Eric,
>
> According to the ADs and WG chairs, the correct forum for the NAT66 
> discussion is the BEHAVE WG.  So, let's discuss it there.
>
> Margaret
>
> On Nov 12, 2008, at 9:44 AM, [email-masked] wrote:
>
>> Cross posted to several lists
>> Can we keep the NAT66 discussion to less than WGs at a time?
>> I am trying to keep up with multiple threads on this and trying to 
>> explain that we do not have a valid requirement for NAT66 defined on 
>> any of the mailing lists (v6OPS, BEHAVE, Softwires, RRG, and now v6).
>> Le's get this to one group (maybe we need a new mailing list just for 
>> NAT66 discussions, but this is getting out of hand.
>> Until now the simple response is that "the IETF does not support NAT 
>> in the v6 architecture." If this needs changing lets do it right with 
>> proper gap analysis and needs assessment, and then seeing if there is 
>> a solution (several have been proposed that are not NAT) or if we 
>> need to create one, and if those fail then see about changing the 
>> architecture of IPv6.
>> Eric _______________________________________________
>> Behave mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/behave
>
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Mark Townsley <[email-masked]>
Date: Thu, 13 Nov 2008 15:10:49 +0100

Eric Klein wrote:
> Mark,
>  
> I agree with the sentiment, the problem is that the 5 different groups 
> are doing different things that all relate back to NAT in v6 (rather 
> than just coexistence) each under their own charter.
>  
> I have had suggestions that I bring this to ietf or inter-area mailing 
> lists for general consensus on a need and IETF overall position prior 
> to defining a solution.
> Behave seems a little limited in scope for the decision about do we or 
> don't we want to allow any form of native mode NAT into v6.
I agree, and it is not behave's place to make that decision at this 
time. I had originally proposed that this be discussed in int-area (if 
nothing else because behave's plate is rather full), but some folks 
pointed out that some modes may have affects on applications and that 
behave was best able to determine that, particularly within context of 
the other NATxy work. I'm looking forward to that assessment. So for now 
this should remain discussion to understand the problem space and 
potential solution space better, not a final referendum on whether or 
not the IETF is going to charter work in or otherwise endorse NAT66 in 
any manner.

Thanks,

- Mark
>  
> Eric
> On Thu, Nov 13, 2008 at 12:09 PM, Mark Townsley <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     multiple places. Let's just try and stick to behave for the
>     moment, though at some point if the work continues it would need
>     to be passed around elsewhere. We are not chartering the work one
>     way or another at the moment, for now this is merely "discussion"
>     of the topic.
>
>     - Mark
>
>
>
>
>
>         According to the ADs and WG chairs, the correct forum for the
>         NAT66 discussion is the BEHAVE WG.  So, let's discuss it there.
>
>         Margaret
>
>         On Nov 12, 2008, at 9:44 AM, [email-masked]
>         <mailto:[email-masked]> wrote:
>
>             I am trying to keep up with multiple threads on this and
>             trying to explain that we do not have a valid requirement
>             for NAT66 defined on any of the mailing lists (v6OPS,
>             BEHAVE, Softwires, RRG, and now v6).
>             Le's get this to one group (maybe we need a new mailing
>             list just for NAT66 discussions, but this is getting out
>             of hand.
>             Until now the simple response is that "the IETF does not
>             support NAT in the v6 architecture." If this needs
>             changing lets do it right with proper gap analysis and
>             needs assessment, and then seeing if there is a solution
>             (several have been proposed that are not NAT) or if we
>             need to create one, and if those fail then see about
>             changing the architecture of IPv6.
>             [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Scott Brim <[email-masked]>
Date: Thu, 13 Nov 2008 11:51:29 -0500

On 11/13/08 10:06 AM, Hallam-Baker, Phillip allegedly wrote:
> 
> I beleive that the question would not arise If we had a coherent
> Internet architecture
>  
> The idea that an application can or should care that the IP address of a
> packet is constant from source to destination is plain bonkers. It was
> no an assumption in the original Internet architecture and should not be
> an assumption that any application should rely on.

That's not the problem.  The issue is location.  Once we have
established a session then how the packets are labeled for network layer
purposes doesn't matter much (modulo security) but how do we get
communications set up in the first place?  Suppose I want to reach
"foo".  Who do I ask to find a locator for him?  Split DNS works fine
when there are just two states, inside and outside -- a DNS server can
be configured to know how to respond in each case.  But if you were to
sprinkle NATs all over the Internet there would be no place that could
give a confident answer about how I, over here, should name foo in the
network layer in order to get a packet to him, and have that answer get
to me in the correct form.  So it is very important to understand where
we think it might be safe to put what kinds of NATs.

swb

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 12 Nov 2008 19:07:39 -0500

Hi Eric,

Margaret

On Nov 12, 2008, at 9:44 AM, [email-masked] wrote:

> Le's get this to one group (maybe we need a new mailing list just  
> for NAT66 discussions, but this is getting out of hand.
> in the v6 architecture." If this needs changing lets do it right  
> with proper gap analysis and needs assessment, and then seeing if  
> there is a solution (several have been proposed that are not NAT) or  
> if we need to create one, and if those fail then see about changing  
> the architecture of IPv6.

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Thu, 13 Nov 2008 11:30:39 -0800

Eric, Philip,
 
Comments below inline with DL>
 
Thanks.

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Eric Klein
	Sent: Thursday, November 13, 2008 11:07 AM

		NAT66 is in fact a security requirement in many
applications and in others it is a compliance requirement. Stampy feet
protests that the idea is profane don't change those facts.

	NAT is not and never was a security feature, it was a way to use
fewer numbers because they were hard to get. Please stop the falacy that
NAT in any way is related to security, otherwise we would not need
firewalls.
	 
	DL> Port/Overload NAT for IPv4 (NAT:P) has security benefits in
that it requires explicit configuration to allow for inbound unsolicited
transport connections (via port forwarding) to 'inside' hosts.  This
mimics many of the default policies on most firewalls, hence the
confusion.  Note that can also cause security issues elsewhere in the
network.  The loss of information of the identity of the source host can
cause address filtering in the network to effect other devices than just
the one intended.
	 
	DL> I'm wondering if this is written down somewhere, because
both of the above points seem to be argued over and over again, without
people being genererally educated about them.

		I know that there are some people in the security area
who claim otherwise but they have been wrong on many issues in the past
and they are likely wrong on this one. Let us consider for a minute the
list of real world security measures that the IETF has successfully
deployed, well there is DKIM (sort of) and there is the post-facto
cleanup of SSL after it was successful and the post facto cleanup of
X.509 after that was successful. IPSEC is used as a VPN solution despite
being unsuited for the role as originally designed. 
		 
		On the negative side the same consensus that opposes
NAT66 has in the past opposed firewalls, the single most widely used
network security control. It has also promoted the idea of algorithm
proliferation and negotiation as a good thing (these days we consider it
bad). It has promoted the idea that the most important feature in a
security protocol is that it be absolutely secure against theoretical
attacks rather than easy enough to deploy and use that people actually
use it.

	This is not quite true, the ones who have been argueing against
it have constantly asked why we need it. But we still do not know why we
need NAT, no one has done the gap analysis. 
	 
	DL> I would argue that stateless filtering (e.g. access control
lists) are even more common than firewalls and are the single most
widely used network security control.  But the main point is that
firewalls ( statefull (flow based) filtering that usually have default
policies), are orthogonal to address translation.  They just happen to
occur at the same point in the topology in many networks.
	 
	DL> But I think Eric you have a good point about documenting the
relationship between a privately addressed IPv4 site and a publicly
addresses IPv6 site.   We should publicly document the differences, it
would likely make or break the case for NAT66.
	 
	Thanks,
	 
	-Darrel

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 Nov 2008 22:34:35 +0100

On 13 nov 2008, at 22:15, Hallam-Baker, Phillip wrote:

> Well yes, that is precisely the reason I beleive that we need to  
> take a look at a higher level and decide on one single answer

A single answer? That doesn't seem compatible with what the internet  
has evolved into over the past decades.

> to questions such as:

> * What describes the boundary between the network and the inter- 
> network?
> * How does a client endpoint connect to a service endpoint?
> * How does a sevice endpoint advertise its existence at the network  
> border?

Sounds an awful lot like the telco networks of yore. One of the cool  
things about the internet architecture is that many aspects of it are  
recursive. Having these borders is incompatible with that. On the  
other hand, many service providers use nasty hacks to get their stuff  
to work (just think about a concept like putting authentication in  
DHCP!) because the IP architecture doesn't allow for a service  
provider / customer demarcation point.

> By infrastructure here I am taking account of the fact that we might  
> in theory replace the DNS protocol, but only if the result was  
> transparent at a logical level.

And how would the new DNS be better than the old one, apart from such  
obvious things as removing the easy spoofing?

The reason that people

> Many of the problems with NAT result from the fact that we have  
> protocols such as FTP that use the IP address and port to pass a  
> pointer to a service endpoint - yuk!

is that you can't realistically do a referral based on a DNS name:

- DNS isn't always available
- DNS is insecure
- caching and TTLs and incorrect implementation of same make that an  
inconsistent view of the same data in different places can persist for  
significant amounts of time
- performance is relatively poor
- some users don't have a DNS name
- a large number of users can't set their own DNS name
- dynamic IP addresses usually come with static DNS names, i.e., with  
the address change the name changes as well

And then there is of course the issue of revisiting a very large  
number of protocols and implementations of these protocols in order to  
support FQDN based referrals.

But apart from these issues I agree with you.

> It would be really nice if there was actually a practical,  
> interoperable video conferencing system that works peer-to-peer  
> through NAT at both ends.

Not sure how this applies to the NAT66 discussion. The choice that  
we're talking about is between a type of NAT that can fairly easily  
support this versus no NAT, so it also works.
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 14 Nov 2008 09:57:32 +0100

On 13 nov 2008, at 23:50, Hallam-Baker, Phillip wrote:

> The most successful Internet protocols do not involve connections to  
> hosts today. SMTP is a connection to a service and has been for two  
> decades.

> In SMTP the IP address does not remain constant end to end and never  
> did.

SMTP is also the least secure protocol that is in wide use; hop-by-hop  
forwarding without authentication of the message itself is a security  
nightmare. We have the same issue with flooding of random IP packets.
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 14 Nov 2008 11:46:13 -0500

Could people who are interested in discussing NAT66 please do so on  
the [email-masked] mailing list and drop all of these cc:s?  You may  
not be aware, but you are sending this mail to thousands of people,  
and most folks who care about NAT66 are getting this more than once.

People who want to participate in the NAT66 discussion (or just read  
it) are encouraged to subscribe to the behave WG mailing list (To  
Subscribe: [email-masked], In Body: subscribe).

In an attempt to bring the discussion back to the subject at hand...   
There is a specific draft for NAT66 that we will be discussing at the  
behave WG meeting in Minneapolis:

http://www.ietf.org/internet-drafts/draft-mrw-behave-nat66-01.txt

Your comments (on the behave WG list only, please) are greatly  
appreciated.

Margaret

On Nov 13, 2008, at 2:07 PM, Eric Klein wrote:

> Hi Phillip,
>
> On Thu, Nov 13, 2008 at 5:06 PM, Hallam-Baker, Phillip <[email-masked] 
> > wrote:
> The idea that an application can or should care that the IP address  
> of a packet is constant from source to destination is plain bonkers.  
> It was no an assumption in the original Internet architecture and  
> should not be an assumption that any application should rely on.
>
> If you want to effect a transition from IPv4 to IPv6, the only way  
> to do that effectively is to design a protocol stack in which the  
> applications simply do not care whether their packets are routed  
> over IPv4, IPv6 or carrier pidgeon.
>
> Agreed
>
> NAT66 is in fact a security requirement in many applications and in  
> others it is a compliance requirement. Stampy feet protests that the  
> idea is profane don't change those facts.
>
> fewer numbers because they were hard to get. Please stop the falacy  
> that NAT in any way is related to security, otherwise we would not  
> need firewalls.
>
> I know that there are some people in the security area who claim  
> otherwise but they have been wrong on many issues in the past and  
> they are likely wrong on this one. Let us consider for a minute the  
> X.509 after that was successful. IPSEC is used as a VPN solution  
> despite being unsuited for the role as originally designed.
>
> On the negative side the same consensus that opposes NAT66 has in  
> the past opposed firewalls, the single most widely used network  
> security control. It has also promoted the idea of algorithm  
> proliferation and negotiation as a good thing (these days we  
> consider it bad). It has promoted the idea that the most important  
> feature in a security protocol is that it be absolutely secure  
> against theoretical attacks rather than easy enough to deploy and  
> use that people actually use it.
>
> This is not quite true, the ones who have been argueing against it  
> have constantly asked why we need it. But we still do not know why  
> we need NAT, no one has done the gap analysis.
>
> And yes, I have been guilty of many of the same mistakes. But unlike  
> some folk I am not about to compound that mistake by telling the  
> folk who want NAT66 that they should visit a re-education camp and  
> unlearn their heretical thoughts.
>
> The only reason NAT is bad in practice is because some people were  
> so opposed to the concept that they decided it would be a good thing  
> to allow designs that were purposefully designed to be NAT-unfriendly.
>
>
> If we don't want to have these discussions on the IETF list we  
> should have a separate architecture list.
>
> NAT66 is a reasonable protocol proposal to make. If BEHAVE does not  
> like the idea let the advocates start a new group.
>
> This is why I am proposing a wider audience make a decission rather  
> than having several groups making solutions without understanding  
> the need.
>
> From: [email-masked] on behalf of Mark Townsley
> Sent: Thu 11/13/2008 9:10 AM
> To: Eric Klein
> Cc: Routing Research Group Mailing List; Behave WG; [email-masked]; [email-masked]
> Subject: Re: [BEHAVE] Can we have on NAT66 discussion?
>
> Eric Klein wrote:
> > Mark,
> >
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>
>
>
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Lixia Zhang <[email-masked]>
Date: Fri, 14 Nov 2008 08:59:30 -0800

this thread has been posted to *4* mailing list.
not sure whether other list adm had the same issue, but rrg adm keeps  
getting lots non-member posting warnings ... so the msg would not get  
delivered without manual intervention (i.e. defeating the intention of  
cross posting)

wonder if there is a better way out...

Lixia (not complaining, just raising an awareness:)

On Nov 13, 2008, at 8:51 AM, Scott Brim wrote:

>> of a

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 15 Nov 2008 22:04:03 +0100

On 14 nov 2008, at 17:49, Hallam-Baker, Phillip wrote:

> BGP is not a secure protocol.

Not disagreeing, but what makes for a secure protocol?

> So why do you think it is appropriate for end user applications to  
> make assumptions about end entity identity on the basis of source IP  
> address?

I don't. But then again I don't believe in firewalls so it doesn't  
cost me anything to forego this assumption. But if all you have is a  
hammer and a nail comes along, you start hammering without asking too  
many questions. (I.e., addresses are there so if you have a firewall  
the natural thing is to filter based on them, even though it's  
problematic.)

> If you take a look at DKIM you will see that the approach there is  
> to independently authenticate the hops.

That didn't make sense in S-BGP so without being aware of the details  
of DKIM I'm going to assume it doesn't make sense there either.
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: "Tony Li" <[email-masked]>
Date: Sat, 15 Nov 2008 19:02:50 -0800

|> BGP is not a secure protocol.
|
|Not disagreeing, but what makes for a secure protocol?

As a friend of mine would say, the only way to be fully secure would be to
exchange no bits.

;-)

Tony