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

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




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





Follow-Ups: