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

Re: IPSEC Security Gateways & NAT

Except:
	a) it is the only required authentication "system", and
	b) it's unfortunately being used a lot.

I would be more than happy to require RSA.  Why wasn't that done?
(rhetorical question).

Besides, from the human-factors point of view, using pre-shared keys
is easier from a ui standpoint: "Here is your IKE password."
Moreover, this whole argument just points to the fact that pre-shared
keys are a problem.  If it weren't for the existing pre-shared keys
protocol, NAT wouldn't be as much of a problem (except for ESP
encapsulation).

Ah well.

-derek

"Hilarie Orman" <HORMAN@volera.com> writes:

> I feel that it would be a mistake to fix pre-shared static keys.
> They were meant to bootstrap initial adoption of IKE and
> should be allowed to die a natural death from disuse.
> 
> Hilarie
> 
> >>> Derek Atkins <warlord@mit.edu> 06/13/01 10:24AM >>>
> "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

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

--=_3862299D.C9A8683C--