[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPSEC Security Gateways & NAT
>From: owner-ipsec@lists.tislabs.com on behalf of Derek Atkins
>[warlord@mit.edu]
>Sent: Wednesday, June 13, 2001 8:31 AM
>To: Chen, David
>Cc: 'jshukla'; ipsec@lists.tislabs.com
>Subject: Re: IPSEC Security Gateways & NAT
>
>"Chen, David" <dchen@ellacoya.com> writes:
>
>> Derek,
>> The idea of tunneling IKE by using UDP/IP will required the IPSec's IKE
>> daemon change.
>> In order to traverse any number of NAPT-GW between the initiator and
>> responder,
>> the initiator and responder have to encapsulate, de-capsulate the outer
>> UDP/IP header
>> fore process today's IKE packet.
>
>I still don't understand why you need to tunnel IKE (which is already
>UDP) in another UDP datagram. And I don't agree that there is any
>encapsulation/decapsulation required here. The only requirement I see
>is bi-directional reachability. There is no requirement that an
>endpoint know the _actual_ ip address of the other endpoint.
>
>> An example will be like this:
>>
>> Let's say, for today's IKE exchange, the address are assigned as
following:
>> (without NAT)
>> Laptop <========> SG
>> 100.10.10.49/500 <=========> 100.10.10.1/500
>
>Ok. I agree with this. With a direct connection you need no
>encapsulation.
>
>> If one directionally NAT exists between the Laptop and Home-SG:
>> Let's say, Laptop was assigned 10.0.1.1, NAT-GW is 10.10.10.1 and
>> Home-SG > is 100.10.10.1, Laptop<->NAT-GW<=====>Home-SG
>
>This is easy without any encapuluation. Let's assume the NAT-GW has
>an EXTERNAL address of 1.2.3.4 (the internal address is, as you said,
>10.10.10.1). Using your terminology:
>
>1) from Laptop to NAT
> 10.10.10.49/500->100.10.10.1/500
> from NAT to SG
> 1.2.3.4/4999->100.10.10.1/500
>
>As you can see, the packet makes it to the SG without any problems.
>No, the SG doesn't know the IP address of the original source, but
>that's ok. Just don't use IP-address-based names. Yes, this means
>that the 'pre-shared static keys' authentication transform must be
>changed, but it should be changed for other reasons too (I wont go
>into that in the message).
>
Agree with you here. I too can not see why tunneling is required for IKE.
Aggressive-mode or base-mode with non-ip identifiers seems to take care of
this
problem.
Main-mode with certificate is also possible but you have to play tricks like
accepting the SA proposal blindly and waiting till ID payload processing
to actually checking whether the accepted proposal matches policy.
-- sankar --
References: