[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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).
2) from the SG to NAT:
100.10.10.1/500->1.2.3.4/4999
from NAT to Laptop
100.10.10.1/500->10.10.10.49/500
> Similarly, this scheme still can do IKE even another NAT in between
> NAT-GW and Home-SG for bi-directional NAT.
I'd like to see this example spelled out. If the responder is behind
a NAT, there has to be some way to address it from the 'outside'.
Could you please show this example fully? So far I see no need to any
extra IKE encapsulation. Perhaps this variant may show the necessity,
but until I see an example of how it would work (and how the endpoints
are addressed) then I don't believe it.
> For other IPSec packets,
>
> The UDP->UDP and TCP->TCP mapping, I mean the IPSec packet originator
> will copy the inner UDP/TCP/protocol to outer UDP/TCP/protocol before
> encryption. (slightly different of tunnel mode)
There are no 'UDP' or 'TCP' IPSec packets. There is only ESP. What's
below the ESP can be anything, and you just don't know. You shouldn't
know. You shouldn't care. Again, I don't see why you need to do
this. It's extra work, extra bytes, and IMHO no benefit.
> Looks like the ESPoUDP is inserting UDP in the IPSec packets?
> Then, there will be no mapping due to the inner IP header have been
> encrypted.
>
> Thanks for clarifying the ESPoUDP.
Yes, an ESPoUDP packet basically looks like this:
<IP> | <UDP> | <ESP>
So, you have the raw IP header, than the UDP header, and then the ESP
Header and Data. I don't know exactly how it is specified, but I
would suppose that the ESP (header + data) is really just carried
along as the data portion of the UDP packet. Others may disagree :)
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
Follow-Ups:
References: