Subject: (NAT) Re: Interactions between IPSEC and NAT

From: Alex Alten <[email-masked]>
Date: Wed, 04 Feb 1998 19:46:15 -0800

At 03:59 PM 2/4/98 -0500, Perry E. Metzger wrote:
>
>Dan Nessett writes:
>> Anyone thought about this so that they can provide us with a nice clean
>> answer :-) ?
>
>Yes. If you want security, you can't use NAT, because by definition
>the thing NAT is trying to do (peek in and/or alter your packets) is
>what security is designed to prevent. Protocols like SSL have exactly
>the same issue, btw. Any protocol that protects the contents of your
>data will have the same issue.
>
>This is not fixable -- any "fixes" someone could propose to this would
>be so horrible as to make the entire point of security moot.
>
>Perry
>
>

This is what bothers me about the direction IPSEC has taken.  The
addition of security should not break things like trusted NATs.  If you
define an IP "trusted node" as all hosts, routers, firewalls, NATs, etc., 
that want to interoperate securely as a secure network. Then the only thing 
IPSEC should do is secure IP packets, the IP header and payload, between 
two trusted nodes (actually between two trusted interfaces).  The question 
that remains is whether or not to allow untrustworthy nodes to handle the 
IP packets.  If not, then encrypt the IP header, since all the trusted 
routers can decrypt it, decide how to route it, and then re-encrypt before 
transmitting it.  If so, then just MAC the IP header (but still encrypt & 
MAC the payload).  In this latter case insecure NATs (and routers which 
fragment) will not be able to work with the secure nodes, but any insecure 
node that doesn't adjust the IP packet will work as-is.  The really difficult 
issues of how to establish and control the network of trusted nodes, 
and how to implement and enforce network-wide policy can then be tackled.

- Alex

Alex Alten
[email-masked]
P.O. Box 11406
Pleasanton, CA  94588  USA
(510) 417-0159

-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: [email-masked]
Date: Thu, 05 Feb 1998 00:00:47 -0500

I think IPSEC has it right, and Perry gave us the bottom line many
messages ago.

I am talking to my friend Ray at X and I encrypt my packet which is the
checksum and all stuff.  IPSEC gives me the hope that NO ONE else can
see the data including my ISP or routers or NAT boxes I don't even know,
between me and Ray.  I like the idea of not being violated on the
Internet.

I have already figured out to avoid NAT in most cases with IPv6 and now
working on an NNAT for IPv4 if I can find someone who wants to do the
writing?  At first I thought DHCPv4 could not do NNAT but now I think it
can though it does not have the Reconfigure msg of DHCPv6 I think we can
do it with Multicast packets.  The other option is to use DHCPv6 for
IPv4 nodes too, which is possible.

For those that want IPSEC, but need a temporary address like NAT does,
the goal is to just avoid using NAT and I think this is very doable.

I am not saying that NAT cannot still be used cause it will at least
until IPv6 is pervasive, but I think we (engineers) are trying to solve
this problem in the wrong way.  We should be working on solutions to
avoid NAT when it is not an optimal way to do "business" on the Internet.

Do we discuss such notions here or do we need to have an Avoidance of
NAT BOF and eventual Working Group at the L.A. IETF?

Changing IPSEC for NAT is a bad engineering idea IMO.  

/jim

-

---

From: Alex Alten <[email-masked]>
Date: Wed, 04 Feb 1998 23:23:24 -0800

At 01:09 AM 2/5/98 -0500, Perry E. Metzger wrote:
>Alex Alten writes:
>> addition of security should not break things like trusted NATs.
>
>The function of IPsec is to keep a packet from being touched or read
>in transit. 

IP packets are designed with routing in mind.  There are fields which
need to be adjusted between hops.  This means IP security can only be 
designed with a single hop in mind.  This also means that IP security 
must be part of a complete security system, of which IP security is 
just one component, the component which protects inter-router hops.  
A secure, trusted NAT can certainly be part of that system.

>> If not, then encrypt the IP header, since all the trusted routers
>> can decrypt it, decide how to route it, and then re-encrypt before
>> transmitting it.
>
>We don't do that, actually. You can't bring all the routers on the
>internet into your security perimeter -- that simply won't work. Thus,
>we don't try. IPsec works via encapsulation -- the outer IP address is
>in the clear, as it must be for routing to work. 

This is realistic, I stated this as my alternative.  However the outer IP
address must be at least be verified somehow, either via a MAC over it or
duplicate routing information inside the protected encapsulation area.

>For stuff like NAT to work you would need to include all NAT boxes and
>routers in your security perimeter, and I fundamentally cannot think
>of a design for this stuff that will work and will involve arbitrary
>numbers of intermediate nodes on the global internet -- I belive that
>it just can't be done in practice. Maybe I'm just not bright enough,
>but I think that instead its an issue of having enough arrows in my
>back to know better.
>

I absolutely agree.  In fact, regardless of NAT, all the routers must
be part of the security system (or security perimeter).  For an
arbitrary number of insecure routers, then I think only a transport
or application level security will work.

>> The really difficult issues of how to establish and control the
>> network of trusted nodes, and how to implement and enforce
>> network-wide policy can then be tackled.
>
>When you come up with a functioning protocol, let us know. I don't
>believe one is possible, but I'm more than willing to listen.
>

Admittedly it is a tough problem to solve, given the datagram nature of 
IP and its high performance requirements for routing.  It's much easier
to do it at the TCP level.

- Alex
--
Alex Alten
[email-masked]
P.O. Box 11406
Pleasanton, CA  94588  USA
(510) 417-0159

-

---

From: Alex Alten <[email-masked]>
Date: Thu, 05 Feb 1998 01:03:31 -0800

At 02:39 AM 2/5/98 -0500, Perry E. Metzger wrote:
>Maybe you ought to read the spec. It might answer a lot of your
>questions. Believe it or not, we did know what we were doing.

I have to really question if you knew what you were doing.  Go 
read Rogaway's cryptographic analysis--have you fixed the issues 
he raised?  Are you still seriously considering a PK solution for 
managing trust?  If so, then God help anybody that has to implement 
it and get a real customer to use it.

>Your viewpoint is a wee bit unrealistic -- there is, in practice, no
>way to make even a tiny fraction of the routers trusted. It is also
>unneeded -- we know how to provide security in a network where nothing
>except the endpoints need to be trusted. 

Unfortunately you have come up with a solution I find cumbersome,
slow, difficult to administer, with an awkward trust model, no 
auditing, and no key recovery.

> Might I suggest that you
>study this topic a bit more in depth before commenting further?

You know Perry, not everyone who studies this field goes off and wastes
their time writing RFC's and I-D's. I prefer to apply for patents and sell 
them.

- Alex

--
Alex Alten
[email-masked]
P.O. Box 11406
Pleasanton, CA  94588  USA
(510) 417-0159

-

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 5 Feb 1998 09:55:18 +0000 (GMT)

Jim,

> IPv4 nodes too, which is possible.

Glad to hear that you desided to work on that. I always thought it was a
good idea.

> the goal is to just avoid using NAT and I think this is very doable.

Exactly! 'NAT bypass' is one way to do that and I hope you will find out
another.

> avoid NAT when it is not an optimal way to do "business" on the Internet.

In all this thread of discussion three solutions for NAT and IPSEC
coexistance have been proposed.

1) Implement NAT and IPSEC at the same node. This can give you gateway to
gateway security.

2) Do the above plus IPSEC between end-user and NAT. This can only work if
the NAT is trusted and will give a kind fo end to end security, thought, a
lot of people will argue with this...

3) Try to avoid NAT when IPSEC (or other end-to-end sensitive app.) is
required. 'NAT bypass' attempts to do
exactly that by building an l2tp tunnel (nothing to do with IPSEC tunnels)
between itself and the NAT. The NAT then sends a global IP address through
the tunnel and the host can now use the globally valid IP address to do
IPSEC end-to-end, bypassing the NAT function.

> NAT BOF and eventual Working Group at the L.A. IETF?

I think NAT BOF (WG?) should be OK for that. I think NAT BOF was not about
making NAT work, it was more about addressing the problems that NAT
introduces.

> Changing IPSEC for NAT is a bad engineering idea IMO.  

Agree!

> /jim

Best Regards
George
-----------------------------
Internet Transport Research |
BTLABS                      |
--------------------------------------------------------------------------
Notice: This contribution is the personal view of the author and does not
necessarily reflect the technical nor commercial direction of British
Telecommunications plc.
--------------------------------------------------------------------------

-

---

From: Ben Rogers <[email-masked]>
Date: Thu, 5 Feb 1998 10:49:44 -0500 (EST)

>From the proposed NAT WG charter:

    The second set of documents will specify NAT friendly application
    and protocol design guidelines, interactions between NATs and
    applications such as DNS and protocols such as IP sec and mobile
    IP. The documents would also be extended to identify areas where
    NATs or other protocols and applications can be improved to overcome
    the shortcomings in interoperability or functionality.  Due to the
    importance of the issue, specific attention will be given to the
    problems created by NATs for security protocols such as IPsec.

Which makes it sound as if they're planning to be handling such issues.
I know that one of the important points mentioned in the Washington was
that if NAT were going to fly as a WG it would need to work around the
security interactions by modifications to the way we do NAT instead of
modifications to the way we do security.

ben

-

---

From: "Perry E. Metzger" <[email-masked]>
Date: Thu, 05 Feb 1998 11:04:21 -0500

> I have to really question if you knew what you were doing.  Go 
[...flamage deleted...]
> their time writing RFC's and I-D's. I prefer to apply for patents and sell 

You will pardon me, but I'm going to cut this off now. I really don't
think this is going to be productive for people, and most people
probably don't want to read any more comments from me, especially as
your comments speak for themselves. Nothing I could possibly say was
as damaging to you as your own words.

Perry
-

---

From: "Derrell D. Piper" <[email-masked]>
Date: Thu, 05 Feb 1998 10:08:56 -0800

>modifications to the way we do security.

There's a good idea!
-

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 5 Feb 1998 11:19:24 -0800 (PST)

Jim,

> I think IPSEC has it right, and Perry gave us the bottom line many

You may be right. There are tradeoffs and limitations to everything
including IPSec. Other members of the list including Yakov and Alex 
ALten pointed this out eloquently. So, I wont go into this.

> between me and Ray.  I like the idea of not being violated on the

If you consider NAT as a violation of your rights, you probably ought not
use NAT. I can understand. But, you may have no choice if you are 
communcating with vendors that do use NATs in their setup. NAT has its 
place in providing solutions to a set of problems. The level of security 
required is not universal to all. 

> IPv4 nodes too, which is possible.

Well, Jim, your proposal is not without its limitations and does not solve
the many problems that NAT does. It is not a replacement for NATs and 
here are some reasons why. 
    a) NATs do address and port translation. Your draft, which is based on 
       DNS and DHCP v6 does not.
    b) Load Share NATs do session binding and load sharing on a real-time 
       basis. Real-time address updates of DNS, in the past, at best are
       proved to be slow to adapt and have not been successful. And, your 
       draft does not solve the load share problem that NATs do.

    c) NATs do flow-based address asignment and translations.  Your draft 
       tries to divert flow based address assignment (limited only to sessions
       originating from V4 to V4+V6 nodes) through DHCP v6 and DNS to 
       V4+V6 nodes. The end nodes must be sensitive to who they are talking 
       to (V4 only or V4+v6 nodes), adapt multiple addresses (for 
       incoming or outgoing sessions) and choose a routing scheme based
       on who they are talking to etc.. 

> the goal is to just avoid using NAT and I think this is very doable.

Surely, there are alternatives to meeting the IPSec requirements even with
NATs in between. 

> avoid NAT when it is not an optimal way to do "business" on the Internet.

The meaning of the terms you use are subject to interpretation. What 
is "right", what is "optimal" and what it takes to do "business" - all vary 
considerably from observer to observer.

> NAT BOF and eventual Working Group at the L.A. IETF?

This a NAT mailing list and you are airing your thoughts on the list;
which I appreciate. We are in the process of trying to form a NAT work 
group, trying to get the language for charter just right so it is 
agreeable to IESG, IAB, Area advisors and WG chairs. The process has
been slower than I would like; but we are progressing...

Why are you advocating boycott of the upcoming NAT BOF and/or NAT WG at 
LA? Why do you feel the need to avoid the NAT forum. I do not appreciate 
your doing this. Is that because you believe NATs are the "wrong" way to
solve business problems. We went over this in the Munich BOF; And, the
majority of people in Munich as well as Washington BOF felt it a good
idea to have NAT work group.

> Changing IPSEC for NAT is a bad engineering idea IMO.  

I refer you to the charter and objectives stated for the BOFs in
Munich and Washington, DC. There was no such mention. We dont intend
adding this terminology to the eventual Work group charter either.

> 'unsubscribe nat' in the body of the message.

Regards,
suresh
-

---

From: [email-masked]
Date: Thu, 05 Feb 1998 16:35:48 -0500

Suresh,

>ALten pointed this out eloquently. So, I wont go into this.

As someone just said its not an IPSEC vs NAT its Security vs NAT and I
would even say Private Addresses vs using real Internet Addresses which
is causing NAT.

>required is not universal to all. 

If I do not have the choice to use end to end security on the Internet
then a very serious choice for nodes is missing.  Once we deploy IPv6
and IPSEC and other forms that do not need private addresses then I
agree with Yakov folks will have to change their mind, only my view of
where the world will go is far different from Yakov's I think.

>here are some reasons why. 

Of course my draft has limitations I am not clear I agree with you on
what the defintion of a limitation is vs an advantage though.

>       DNS and DHCP v6 does not.

I consider this an advantage.

>       draft does not solve the load share problem that NATs do.

Load Share is a side benefit of NAT we can have load shire without NAT.
My draft does not prevent load share.

>       on who they are talking to etc.. 

Yes my draft is to help users not have to have private addresses and can
move to the Next Generation Internet Protocol which is IPv6 more
expediently and does not require any translation.  The only cost is a
one time set up.  As far as providing flow based or IP Switched benefits
that is not a function of NAT and can be provided once the node has a
real IPv4 address.  But this is a philosophical discussion and not
technical so I will stop.

Please don't try to tell me that packets can move faster for IPv4 with
NAT than if NAT was not needed and the node has a real IPv4 Internet
address where NAT is not needed.  I don't believe that at all.

>Surely, there are alternatives to meeting the IPSec requirements even with

Well I just read the mobile draft for firewalls.  I think its good work
but it has much cost and requires some serious security dynamics to
provide end-to-end security.  In addition it only works public to
private now not private to private across the Internet.  I will read
George's by-pass draft this weekend.

I don't think its possible given the "trust" model assumed.  We can
change the trust model but that gets into philosophy too not
engineering.  Changing the philosophy of our trust model will take
awhile IMO, but thats not in this WG charter and we should probably take
that discussion elswhere.  

>considerably from observer to observer.

Well let me interpret it clearer for you.  Laissez-faire.  NAT is fine
but building alternatives to NAT is fine too.  I hope that is clearer.

>idea to have NAT work group.

Your misunderstanding my words.  I do think we need a NAT WG and
charter.  But based on a lot of mail here I also think we in the IETF
need to work on alternatives to NAT or translation.  The question is
should that be part of this WG?   I don't know?  I go to NAT now (when I
don't have other conflicts) and if there is a group doing an alternative
to NAT I will go there too.  I am not against this work and believe it
to be important because it exists in the market.  But I believe it
better to not use private addresses for many reasons and that is the
only reason for NAT in the market I can justify.   

>adding this terminology to the eventual Work group charter either.

This was just a comment to the list thats all as some suggested if IPSEC
don't work with NAT then IPSEC maybe should be changed.  So I was
responding to that mail.

Sincerely,
/jim

-

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 6 Feb 1998 14:45:29 -0800 (PST)

Jim,

    Thanks for your response and clarifications. Please note
my comments below.

cheers,
suresh
> Suresh,
.... stuff deleted. 

> where the world will go is far different from Yakov's I think.

Fair enough. Time will tell.

> one time set up.  

Yes, my point is simply that the proposal in your draft is a solution to 
a problem, relating to transition from V4 to V6.  It has its limitations 
as well. The solution path you identified in no way is a panacea to all 
problems NAT purports to solve and as such is far from being a replacement 
to NAT solution. I think, you agree with with me on this. If so, no need 
to belabor on this point any further.

>                   As far as providing flow based or IP Switched benefits

Yes, NAT is a flow based address assignment tool (unlike DHCP, which is
simply a resource manager).  You may be confusing this with flow based 
switching by IP routers. These are two different things.

> address where NAT is not needed.  I don't believe that at all.

The session setup latency is certainly much smaller with NATs, which
assign addresses dynamically vs. a set up that involves DHCP and DNS
record updates. Also, with NAT, routing is transparant to end nodes. 

> but building alternatives to NAT is fine too.  I hope that is clearer.
Exactly my point. Thanks for the clarification.

> only reason for NAT in the market I can justify.   

Thanks again for your clarification. Apparantly, I parsed your sentence
differently from what you expected. Anyways, here are my thoughts on the
subject. 

We are planning to form NAT work group only because NATs are a reality
and solve a set of problems in the real world; This is despite the
fact that NATs do not share the mainstream IETF paradigm of "single 
routing realm". So, in a sense, the rest of IETF is already persuing 
solutions in the mainstream. And, NAT WG would be persuing a deviation
from the mainstream. There are other work groups like "mobile IP" that 
share some of this theme.

So, if you have a solution that is more in the mainstream, there may be
already be some work groups in the mainstream that fit the bill. E.g.: 
ngtrans work group that deals with V4->V6 transition issues

> don't work with NAT then IPSEC maybe should be changed.  So I was

OK, I understand.

-

---

From: [email-masked]
Date: Fri, 06 Feb 1998 18:06:01 -0500

Suresh,

I don't see belaboring these points further.  I will agree that we
disagree on the values and capabilities of NAT and thats fine, rather 
than provide anymore counter arguments, because I believe the point of 
this mail list and group is to develop the specifics that relate to that 
which can be standardized in the IETF to support NAT technology.  

So lets start having that discussion because I am an engineer who is
interested and will build a NAT implementation as one solution to leave
IPv4 and move on to IPv6 and avoid private addresses as ONE customer
"choice" to accomplish this task.

As far as other solutions that don't use NAT I take your mail this is
not the place to work on that, though you put that politically quite
well as other comments you have made now and in the past, which is good
as your the chair and need to be nice to us.  Thank You.

Soooo... I will connect offline with a few folks and suggest we have a
BOF potentially of alternative solutions to NAT.  My work on NNAT is for
v4-v6 transition and that clearly belongs in the NGTRANS WG I agree.  But 
my engineering work on this has made me realize as an implementor I can
implement alternatives to NAT and I will see if others in our
community are interested in, in another forum.  Including for IPv4
regardless of IPv6.  So now I am also interested in solutions that can
avoid NAT in IPv4 too.

Others can send me mail PRIVATELY if you interested in such a BOF for
the L.A. meeting.

thanks for working to clear this up,
/jim

-

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 6 Feb 1998 16:40:24 -0800 (PST)

Jim, 

    Thanks for your understanding. I am not trying to be political,
just putting things in perspective. As for solutions that do not 
include NAT, I am not averse to them. I will certainly try to offer
whatever I can towards providing myriad of solutions to customers.
Thanks again.

cheers,
suresh

-