RE: Initial Contact Message processing

[Gregory Lebovitz <Gregory@netscreen.com>]

> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@iki.fi] 
> Sent: Thursday, January 15, 2004 4:50 AM
> To: tls@rek.tjls.com
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Initial Contact Message processing
> 
> 
> Thor Lancelot Simon writes:
> > On Thu, Jan 15, 2004 at 05:21:16AM +0200, Tero Kivinen wrote:
> > > David Wierbowski writes:
> > > > Are you saying that an identity may use IPSec from one device 
> > > > only?
> > > 
> > > USer can use IPsec from multiple devices, but if you want to have 
> > > working solution going through NATs each identity should only be 
> > > tied to one device. This normally is the case, your 
> private key is 
> > > only stored in exactly one machine, and it is tied to one 
> > > certificate having one identity. If you have another 
> device you use 
> > > to connect to the same VPN you should have separate 
> private key and 
> > > identity for that (for example FQDN).
> > 
> > It seems to me that implementations could easily allow the 
> use of the 
> > identity,address,port tuple instead of just "identity" or 
> > "address,port" (the latter being a bug).  This seems more flexible 
> > and, to be honest, I don't see any downside to it at all.  Do you?
> 
> Yes. In that case it does not work if the other end is behind 
> NAT (i.e the host is rebooted, and it gets new address or 
> port after reboot, so the state is not cleared up). It also 
> does not clean up state if the user simply closes machine and 
> then moves another place and restarts it there (new IP). The 
> state is left running in those cases.
> 
> Anyways this is again somewhat policy matter, and depends on 
> the configuration and setup. 
> 
> > Requiring a different identity for each device used by a 
> given user is 
> > likely to cause severe problems with X.500 identies, 
> considering how 
> > certificates are usually allocated to users.
> 
> I do not see any problems there. It is actually much harder 
> to share the same private key in multiple machines than to 
> create separate private key and certificate for each device 
> (implementations allowing pkcs10 based certficiate enrollment 
> or similar, might not allow any standard way to get private 
> key out to another machine).
> 
> > I worked on one implementation (IKEv1 without Initial 
> Contact, FWIW) 
> > where this would have been an utter disaster for some of 
> our largest 
> > customers.
> 
> I do not see any problem for your implementation then to be 
> configured to use only IP/port or IP/port/ID if you do not 
> have NATs or mobile users there.
> 
> The use of INITIAL_CONTACT in the IKEv2 is much smaller 
> anyways, as the dead peer detection will detect the 
> disappearing remote hosts, so INITIAL_CONTACT only causes 
> that happen little bit sooner. 
> -- 
> kivinen@safenet-inc.com
> 

I think the initial quesiton on the thread pertained to IKEv1. In IKEv2, I
agree w/ Tero: we should depend more on dead peer detection than
INITIAL_CONTACT to solve the issue in question.

In IKEv1, I don't see a STANDARD way to handle multiple connections from the
same ID along with INTIAL_CONTACT use for reboot handling AND the NAT use
case. You could: 
 (a) create an implementation that somehow appends iterations to IDs, and
can read them too. But both sides of the connection would need to support it
(i.e. it would be a vendor proprietary implementation)
 (b) create different IDs for same entity, thus only ever using one ID at a
time. But this causes config/memory bloat

Gregory.