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

Re: IPSEC Security Gateways & NAT

"Chen, David" <dchen@ellacoya.com> writes:

> Derek,
> 
> My explanation:
> 1. IKE
> Problem:
> 1) Today's IKE using UDP/IP to exchnage packet.
> 2) It can not traverse through NAPT device due to the
> addresses are used for ID (and protected) and 
> the addresses/ports are changed by the NAPT device. 
> 
> Solution:
> The idea to use yet another UDP/IP header is to shied the IKE packet from
> NAPT device.
> It will require the IKE deamon to encapsulate/de-encapsulate the outer
> UDP/IP header before 
> processing today's IKE packets.

Would it not be easier to change the IKE naming procedures so that the
endpoint identifiers are not necessarily tied to the actual source IP
Address of the packets?  Wouldn't that make more sense and require
fewer changes overall?

I agree that it is a problem that the IKE ID is tied to the source and
destinatin IP address.  Currently, however, the __ONLY__ time there is
this particular problem is when using pre-shared static keys for
authentication.  Well, first, I would suggest people not use
pre-shared static keys.  That suggestion notwithstanding, wouldn't it
be better if this problem was fixed completely, so that pre-shared
static keys are _NOT_ tied to the IP Source Address?

> 2. IPSec data channel:
> The packet's format is:
> IPHeader, Transport header, AH, ESP, IP Header, IP payload.
> It constructs this packet (with header mapping) at the time of encryption,
>  not after ESP is done.

Remember, with normal ESP/AH, there _IS_ no transport header.  With
normal IPSec you have:

	<IP> <AH?> <ESP [IP?] [Transport] [Data]>

Any transport header is encrypted.  Copying that transport header
would be a breach in security.

ESPoUDP, however, adds a UDP header up front _AFTER_ encryption, in
order to give the NAT box something to change.  Therefore, you get:

	<IP> <UDP> <ESP [IP?] [Transport] [Data]>

The <UDP> header just says src/dest ports 500/500 so the NAT gateway
has something with which to munge between the IPSec Peers.  Again,
this _CAN_ be added after encryption with no ills.

The only problem with this approach is if both the initiator and
responder are behind a NAT.  However, in that situation you would need
some a-priori knowledge in order for the initiator to address a packet
such that it will reach the responder (hense my requirement for
reachability).  This implies that UDP port 500 on the NAT box must
forward to the IPSec SG behind it in order to meet the reachability
requirement.  So, if we fix the 'pre-shared static keys require
source/dest ip address matching' problem, we fix this case as well.

So, let's fix the problem in IKE that pre-shared static keys require
the source/dest ip address to match.  Then we don't need any of this
double encapsulation of IKE, and simple UDP encapsulation of ESP
continues to work.

> Regards,
> 
> --- David

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