[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (NAT) Re: Interactions between IPSEC and NAT
Suresh,
> 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.
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.
>> 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.
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.
>> 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. 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.
>> 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.
>> 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.
>> 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.
Sincerely,
/jim
References: