Subject: Re: [BEHAVE] Can we have on NAT66 discussion?

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:
>
>
>     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]
>         <mailto:[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] <mailto:[email-masked]>
>             https://www.ietf.org/mailman/listinfo/behave
>
>
>         _______________________________________________
>         Behave mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/listinfo/behave
>
>
>     _______________________________________________
>     Behave mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/behave
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>   

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 13 Nov 2008 07:06:04 -0800

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.
 
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.
 
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.
 
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.
 
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.

________________________________

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?

Thanks,

- Mark

---

From: "Eric Klein" <[email-masked]>
Date: Thu, 13 Nov 2008 14:28:14 +0200

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.

Eric
On Thu, Nov 13, 2008 at 12:09 PM, Mark Townsley <[email-masked]> wrote:

>
> 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
>
>
>
>
>
>> 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:
>>
>>> 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.

---

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:
> 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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 13 Nov 2008 13:15:35 -0800

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 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?
 
I know that I can give clear and concise answers to these questions, but I think many who argue against the concept of NAT prefer not to think about them.
 
The single answer to the service endpoint discovery problem in my view is that it is a DNS infrastructure problem and no other infrastructure should be involved, certainly not IP. 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.
 
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!
 
Another set of problems come from the fact that by default a NAT box will block incomming connections. This is in many cases exactly the intended outcome, but not always. 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.

From: Scott Brim [mailto:[email-masked]]
Sent: Thu 11/13/2008 11:51 AM
To: Hallam-Baker, Phillip
Cc: Mark Townsley; Eric Klein; Routing Research Group Mailing List; Behave WG; [email-masked]; [email-masked]
Subject: Re: [BEHAVE] Can we have on NAT66 discussion?

swb

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 13 Nov 2008 13:29:19 -0800

You are far too dogmatic in your assertion of what is a security control here. I do not think that there are many folk in the security area who would make such a direct contradiction. 
 
There might be dispute as to whether NAT is an effective security control, Steve Bellovin has written papers on that (which I consider less than conclusive) but NAT is certainly employed as a security control and is certainly effective against certain types of real world attack.
 
NAT is used to provide two types of security:
 
1) A lighweight, verifiable means of blocking inbound connections
2) A lightweight means of limiting the ability of external observers to map the internal structure of a network.
 
The first is interesting as the property that is provided by NAT that is not provided by a standard firewall is auditability and provability. A NAT design is failsafe, it is highly unlikely that a mistake in the NAT code will cause inboud connections to work.it takes effort to make it work. A firewall with no NAT component is not failsafe, if there are bugs packets can get through. There is no way for an independent auditor to determine if a black box is a firewall or a standard ethernet hub unless it is seen in the act of rejecting a packet.
 
The second is something that some folk dispute, but nevertheless is a real obstacle to certain types of (legitimate) investigation. The amount of effort and network access required to circumvent a NAT scheme is considerable and does not lend itself to simple automation. So what we have here is the ongoing dispute between the adherents of old style 'security perfectionists' who think that any security flaw renders a system ineffective and the folk like myself who have long argued that security is risk management (yes, even before that book came out).

From: Eric Klein [mailto:[email-masked]]
Sent: Thu 11/13/2008 2:07 PM
To: Hallam-Baker, Phillip
Cc: Mark Townsley; Routing Research Group Mailing List; Behave WG; [email-masked]; [email-masked]
Subject: Re: [BEHAVE] Can we have on NAT66 discussion?

Hi Phillip,

On Thu, Nov 13, 2008 at 5:06 PM, Hallam-Baker, Phillip <[email-masked]> wrote:

	 

Agreed

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.

	 

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.

	 

This is why I am proposing a wider audience make a decission rather than having several groups making solutions without understanding the need.

	
	
	Thanks,
	
	- Mark

---

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:

> * How does a sevice endpoint advertise its existence at the network  

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.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Nov 2008 17:28:39 -0500

Hallam-Baker, Phillip wrote:
> packet is constant from source to destination is plain bonkers.

On the contrary, the idea that an application must not care that the IP
address of a packet is consistent from source to destination is plain
bonkers.  Even assuming the existence of a higher level identifier and a
secure, fast, scalable, reliable way of finding routes to that
identifier, there will still be some need to talk to a host or an interface.

And nobody has demonstrated an application-independent mapping service
that is anywhere nearly up to that task.  Until somebody does,
statements about what the architecture "should" do, or what applications
"should not" do with addresses, are at best wishful thinking, and at
worst delusion.  And the more often someone makes such a statement
without qualification, the more it looks like the latter.

Keith

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 13 Nov 2008 14:40:08 -0800

Well that is precisely what distinguishes an 'architecture' from a collection of ad hoc heuristic approaches.
 
It is not necessarily going to be the case that every Internet protocol is going to precisely map to the Internet architecture. In fact I would suggest that people are never going to fix FTP.
 
But what you can do with an architecture is to tell application designers, 'here is the Internet, here is how you plug your stuff into our stuff and this is what you can expect to happen when you do it that way and you can expect it to continue to work that way for the indefinite future'.
 
Sure there are going to be legacy exceptions, but there is a big difference between having a system with six legacy protocols that are not quite compliant and one where new incompatibilities are being established every day.

From: Iljitsch van Beijnum [mailto:[email-masked]]
Sent: Thu 11/13/2008 4:34 PM
To: Hallam-Baker, Phillip
Cc: [email-masked]; Behave WG; IETF Discussion; Routing Research Group Mailing List
Subject: Re: [BEHAVE] Can we have on NAT66 discussion?

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 13 Nov 2008 14:50:22 -0800

It is called the principle of encapsulation.
 
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. HTTP is not quite so agile but would be had we had SRV at the time. 
 
In SMTP the IP address does not remain constant end to end and never did. 
 
Simply asserting that "there will still be some need to talk to a host or an interface" without giving instances is hardly a compelling argument. More proof by unsupported assertion seems to me.

From: Keith Moore [mailto:[email-masked]]
Sent: Thu 11/13/2008 5:28 PM
To: Hallam-Baker, Phillip
Cc: Mark Townsley; Eric Klein; Routing Research Group Mailing List; Behave WG; [email-masked]; [email-masked]
Subject: Re: [BEHAVE] Can we have on NAT66 discussion?

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Nov 2008 18:03:10 -0500

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. HTTP is not quite so agile but would be had we had SRV at the
> time.
>  

You're extrapolating a long way from a small sample size.

> Simply asserting that "there will still be some need to talk to a host
> or an interface" without giving instances is hardly a compelling
> argument. More proof by unsupported assertion seems to me.

It's what you have to do to diagnose problems in deeply layered systems.
 You have to be able to strip away the layers that aren't working until
you find one that does.

Keith

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 14 Nov 2008 09:58:51 +0200

On Thursday 13 November 2008 21:30:39 ext Darrel Lewis (darlewis), you wrote:
> 	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.

That's not _quite_ true. The truth is that many boxes that are NATs also are 
firewalls.

A full cone NAT, with UPnP IGD (or NAT-PMP) is barely providing any security 
protection to the host. And many NATs have the so-called "DMZ" function 
whereby they'll forward all incoming traffic to a specified internal host.

Besides, if you don't have a public IP address, you are not addressable from 
the Internet. Whether you have a NAT, a set of proxies or no connection, is 
irrelevant - the lack of addressability is your "protection", not the NAT.

If you have public space internally, you can also NATs outbound, and not 
inbound. Then you NAT provides obviously no protection at all. A firewall 
would.

> 	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.

We have the IPv6 security RFC. We have the IPv6 simple CPE security and the 
NAT security I-Ds.

> 	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.

Yes. And that's the whole point: the firewall function is providing some kind 
of protection. Not the NAT function.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

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:

> decades.

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

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.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Eric Klein" <[email-masked]>
Date: Thu, 13 Nov 2008 21:07:03 +0200

Hi Phillip,

On Thu, Nov 13, 2008 at 5:06 PM, Hallam-Baker, Phillip
<[email-masked]>wrote:

> 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.
>
>
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.

>  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.

>
> 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.
>
>
> 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,
> >
> > <mailto:[email-masked] <[email-masked]>>> wrote:
> >
> >
> >         <mailto:[email-masked] <[email-masked]>>
> wrote:
> >
> >             [email-masked] <mailto:[email-masked] <[email-masked]>>
> >         [email-masked] <mailto:[email-masked] <[email-masked]>>
> >     [email-masked] <mailto:[email-masked] <[email-masked]>>

---

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.

		
		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> 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: "Eric Klein" <[email-masked]>
Date: Fri, 14 Nov 2008 11:15:50 +0200

Hi Darrel,
Comments below
On Thu, Nov 13, 2008 at 9:30 PM, Darrel Lewis (darlewis) <[email-masked]

> 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
> 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.
>
>
> If you are keeping the source IP address the full length of the session,
then there is no problem of loosing hte identiy of the source host, thus
there should be no problem with address filtering - this is the point of not
breaking the end-to-end connectivity that is built into v6. This has nothing
to do with ports, so that requirement is not relevant as far as I can see.

>    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.
>
>
> 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.
>
> addresses IPv6 site.   We should publicly document the differences, it would
> likely make or break the case for NAT66.
>
> Darrel, this is exactly my point. I do not want to predujice the final
solution, but until we know what we want to fix just throwing NAT at it is
not good enough. If there is a real need that requires some or all of the
old NAT44 then I will suppor it - but I want to know why we need it over
anyother solution first.
Eric
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 14 Nov 2008 08:43:03 -0800

The Internet has two protocols that account for >95% of user interactions, email and Web. Pointing out that one of those protocols involves an IP address change en-route might be a single data point but it is a significant one.
 
Also note that the same is true of IRC, Jabber and other 'chat' type protocols.
 
In fact the only application protocol I am aware of that is built on the assumption that the IP address remains constant end to end would be FTP which is an antique design.
 
I propose that we either move FTP to historic or start a revision effort if there is sufficient interest in continuing it as a separate protocol from HTTP.
 
FTP does not work through NAT, does not support encryption or confidentiality in a satisfactory manner and exchanges passwords en-clair.
 
That is not a protocol that should be allowed to be the gating factor for Internet architecture discussions. HISTORIC does not imply obsolete, or that people must stop using it, merely that it is a protocol that does not meet contemporary standards acceptance criteria and there is insufficient interest in producing a revision.

There is certainly a set of file management type interactions that is handled better by FTP than HTTP. But neither protocol can be said to handle these interactions particularly well.
 
For example, I have a bunch of digital photos on my home machine that I would like to be able to synchronize to a machine at a different location for backup security. It is somewhat easier to write scripts that upload the data via FTP, but not by much. 
 
What I really want is a standards based protocol that keeps two object stores in synchronization transparently and in real time. And I want that protocol to be sufficiently simple and free of unnecessary UI interaction that it can be embedded in a digital camera, WiFi picture frame or the like so that once a device is attached, updates are pushed transparently.

This pretty much suggests to me that tweaking FTP to meet modern protocol expectations is probably not worth the effort. Better to declare it Historic and let others propose a replacement if there is a genuine need.

Sent: Thu 11/13/2008 6:03 PM

Keith

---

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
>
> 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.
>
> 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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 14 Nov 2008 08:49:31 -0800

BGP is not a secure protocol.
 
We may work out a way to make BGP somewhat more secure, but most likely to defend against attacks such as flooding and DDoS rather than impersonation of end entities.
 
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?

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

From: Iljitsch van Beijnum [mailto:[email-masked]]
Sent: Fri 11/14/2008 3:57 AM
To: Hallam-Baker, Phillip
Cc: Keith Moore; Behave WG; IETF Discussion; Routing Research Group Mailing List; Eric Klein; Mark Townsley
Subject: Re: [BEHAVE] Can we have on NAT66 discussion?

---

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: <[email-masked]>
Date: Fri, 14 Nov 2008 17:14:01 -0000

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.

Perhaps you missed this statement from
<http://www.ietf.org/internet-drafts/draft-mrw-behave-nat66-01.txt>

   NAT66 devices that comply with
   this specification MUST NOT perform port mapping.

--Michael Dillon

---

From: Keith Moore <[email-masked]>
Date: Fri, 14 Nov 2008 12:41:24 -0500

Hallam-Baker, Phillip wrote:
> We may work out a way to make BGP somewhat more secure, but most likely
> to defend against attacks such as flooding and DDoS rather than
> impersonation of end entities.
>  
> 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 the mapping service still need to be secure to thwart DoS
attacks.  (and it's a lot easier to get away with DoS attacks if you can
make them surgical - i.e. if you can make them apply only to a very
limited target without effecting anyone else)

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 14 Nov 2008 12:44:10 -0500

Hallam-Baker, Phillip wrote:
> The Internet has two protocols that account for >95% of user
> interactions, email and Web. Pointing out that one of those protocols
> involves an IP address change en-route might be a single data point but
> it is a significant one.

it's a fallacy that you can measure the value of a protocol by looking
at the percentage of transactions, bandwidth, etc. it uses.

> In fact the only application protocol I am aware of that is built on the
> assumption that the IP address remains constant end to end would be FTP
> which is an antique design.

that's because you don't know much about protocols.

Keith

---

From: SM <[email-masked]>
Date: Fri, 14 Nov 2008 09:51:35 -0800

At 08:43 14-11-2008, Hallam-Baker, Phillip wrote:
>I propose that we either move FTP to historic or start a revision 
>effort if there is sufficient interest in continuing it as a 
>separate protocol from HTTP.

There are a few I-D about FTP that have been submitted:

FTP Extension Registry
http://www.ietf.org/internet-drafts/draft-klensin-ftp-registry-00.txt

FTP Extension for Internationalized Text
http://www.ietf.org/internet-drafts/draft-klensin-ftp-typeu-00.txt

Streamlined FTP Command Extensions
http://www.ietf.org/internet-drafts/draft-peterson-streamlined-ftp-command-extensions-06.txt

FTP EXTENSION ALLOWING IP FORWARDING (NATs)
http://www.ietf.org/internet-drafts/draft-rosenau-ftp-single-port-05.txt

There were some discussion about one of the above I-Ds in Dublin.

Regards,
-sm

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 15 Nov 2008 21:56:34 +0100

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

> interactions, email and Web. Pointing out that one of those  
> protocols involves an IP address change en-route might be a single  
> data point but it is a significant one.

> Also note that the same is true of IRC, Jabber and other 'chat' type  

There are very many things that I do less than 95% of the time that  
are very important to me.

If you want to change the architecture such that IP addresses may  
change in transit under certain conditions, I'm willing to have that  
discussion, but I would rather not start from the assumption that the  
two most braindead protocols that we use on the internet are shining  
examples of how things should work.

Note though that IM has a number of functionalities, and several of  
them operate peer-to-peer (file transfer, audio/video chat).

> In fact the only application protocol I am aware of that is built on  
> the assumption that the IP address remains constant end to end would  
> be FTP which is an antique design.

Passive mode fixes this.

> What I really want is a standards based protocol that keeps two  
> object stores in synchronization transparently and in real time. And  
> I want that protocol to be sufficiently simple and free of  
> unnecessary UI interaction that it can be embedded in a digital  
> camera, WiFi picture frame or the like so that once a device is  
> attached, updates are pushed transparently.

To quote a former AD of some notoriety: anyone with a keyboard and  
time on their hands can write an internet draft. So go for it.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

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

> 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.)

> 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.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Fri, 14 Nov 2008 09:43:44 -0800

>    this specification MUST NOT perform port mapping.

Nope, that's why I was specific in saying 'IPv4' above.  I was trying to
provide an example for how NAT that do port overloading in IPv4 have
implicit security benefits.

-Darrel

---

From: "Tom.Petch" <[email-masked]>
Date: Wed, 19 Nov 2008 10:33:31 +0100

Not sure how wide this net is being cast but there has also been

 draft-ietf-secsh-scp-sftp-ssh-uri
 draft-ietf-secsh-filexfer-extensions
 draft-ietf-secsh-filexfer

Tom Petch

----- Original Message -----
From: "SM" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>
Cc: "Behave WG" <[email-masked]>; <[email-masked]>
Sent: Friday, November 14, 2008 6:51 PM
Subject: Re: FTP to HISTORIC? RE: [BEHAVE] Can we have on NAT66 discussion?

> Streamlined FTP Command Extensions
http://www.ietf.org/internet-drafts/draft-peterson-streamlined-ftp-command-exten
sions-06.txt