[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

"bound@zk3.dec.com" at Feb 5, 98 00:00:47 am
Content-Type: text
Sender: owner-ipsec@portal.ex.tis.com
Precedence: bulk


Jim,

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

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.

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

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. 

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

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

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

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

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

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.

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

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.

> /jim
> 
> -
> To unsubscribe, email 'majordomo@livingston.com' with
> 'unsubscribe nat' in the body of the message.
> 

Regards,
suresh
Follow-Ups: References: