Re: (NAT) Re: Interactions between IPSEC and NAT
Pyda Srisuresh <suresh@livingston.com> Fri, 06 February 1998 22:52 UTC
Delivery-Date: Fri, 06 Feb 1998 17:52:56 -0500
Return-Path: owner-nat@livingston.com
Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA17625 for <ietf-archive@ietf.org>; Fri, 6 Feb 1998 17:52:55 -0500 (EST)
Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA27600; Fri, 6 Feb 1998 14:40:30 -0800 (PST)
Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA22401 for nat-outgoing; Fri, 6 Feb 1998 14:41:55 -0800 (PST)
From: Pyda Srisuresh <suresh@livingston.com>
Message-Id: <199802062241.OAA22388@server.livingston.com>
Subject: Re: (NAT) Re: Interactions between IPSEC and NAT
To: bound@zk3.dec.com
Date: Fri, 06 Feb 1998 14:45:29 -0800
Cc: suresh@livingston.com, Andrade@netcom.com, perry@piermont.com, Dan_Nessett@tdc.3com.com, ipsec@tis.com, nat@livingston.com
In-Reply-To: <199802052135.AA29211@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Feb 5, 98 04:35:48 pm
Content-Type: text
Sender: owner-nat@livingston.com
Precedence: bulk
Reply-To: Pyda Srisuresh <suresh@livingston.com>
Jim, Thanks for your response and clarifications. Please note my comments below. cheers, suresh > > Suresh, > .... stuff deleted. > >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. > > 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. > Fair enough. Time will tell. > >> 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. > > 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. > > > a) NATs do address and port translation. Your draft, which is based on > > DNS and DHCP v6 does not. > > I consider this an advantage. > > > 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. > > Load Share is a side benefit of NAT we can have load shire without NAT. > My draft does not prevent load share. > > > 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.. > > 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. 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 > 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. > 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. > 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. > 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. > >> 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. > > 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. > > >> 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. > > 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. > Exactly my point. Thanks for the clarification. > >> 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. > > 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. > 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 > >> 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. > > 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. > OK, I understand. > Sincerely, > /jim > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message.
- RE: (NAT) Re: Interactions between IPSEC and NAT Vinod Valloppillil
- RE: (NAT) Re: Interactions between IPSEC and NAT Vinod Valloppillil
- Re: (NAT) Re: Interactions between IPSEC and NAT Perry E. Metzger
- Re: (NAT) Re: Interactions between IPSEC and NAT Steve Bellovin
- (NAT) Re: Interactions between IPSEC and NAT Alex Alten
- (NAT) Re: Interactions between IPSEC and NAT Cheng_Chen
- Re: (NAT) Re: Interactions between IPSEC and NAT bound
- (NAT) Re: Interactions between IPSEC and NAT Alex Alten
- (NAT) Re: Interactions between IPSEC and NAT Alex Alten
- Re: (NAT) Re: Interactions between IPSEC and NAT George Tsirtsis
- Re: (NAT) Re: Interactions between IPSEC and NAT Ben Rogers
- (NAT) Re: Interactions between IPSEC and NAT Perry E. Metzger
- (NAT) Re: Interactions between IPSEC and NAT Perry E. Metzger
- Re: (NAT) Re: Interactions between IPSEC and NAT Yakov Rekhter
- (NAT) Re: Interactions between IPSEC and NAT Raul Miller
- Re: (NAT) Re: Interactions between IPSEC and NAT Derrell D. Piper
- Re: (NAT) Re: Interactions between IPSEC and NAT Pyda Srisuresh
- Re: (NAT) Re: Interactions between IPSEC and NAT Alexei V. Vopilov
- Bill Sommerfeld
- Re: (NAT) Re: Interactions between IPSEC and NAT bound
- Re: (NAT) Re: Interactions between IPSEC and NAT Pyda Srisuresh
- Re: (NAT) Re: Interactions between IPSEC and NAT bound
- Re: (NAT) Re: Interactions between IPSEC and NAT Pyda Srisuresh