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