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

RE: Releasing IP addresses assigned with IKECFG

Thanks Roy.  That's what I stated in my last paragraph.  There are other
ways of doing it in an interoperable way (such as a few things that Ben
suggested).  However, the IP expiration method seems to be the best way,
given that there is no way to tell when a Client hangs up "un-politely".

But I guess that just means we agree. 

Cheers,
Steph.

> -----Original Message-----
> From: Roy Pereira [mailto:royp@cisco.com]
> Sent: Thursday, January 20, 2000 5:16 PM
> To: Stephane Beaulieu; ipsec
> Subject: RE: Releasing IP addresses assigned with IKECFG
> 
> 
> A better way is to use the expiration attribute and have the 
> gateway expire
> the allocated address.  It is up to the client software to 
> renegotiate for
> the same or another address.
> 
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephane Beaulieu
> Sent: Thursday, January 20, 2000 10:05 AM
> To: ipsec
> Subject: FW: Releasing IP addresses assigned with IKECFG
> 
> 
> Sorry, meant to post this to the list.
> 
> -----Original Message-----
> From: Stephane Beaulieu
> Sent: Thursday, January 20, 2000 9:52 AM
> To: 'Ben McCann'
> Subject: RE: Releasing IP addresses assigned with IKECFG
> 
> 
> >
> > Assume a security gateway assigns an IP address to a remote
> > access client
> > via IKECFG. How does the gateway _know_ the client is done
> > with that IP
> > address? You can _not_ use the expiration or deletion of the Phase 1
> > SA because it can be rekeyed independently of the Phase 2 SA's that
> > presumably reference the assigned IP address.
> >
> > The only solution I can see is for the gateway to track all Phase 1
> > and 2 SA's so the IP address can be reclaimed when all SA's to the
> > client are deleted or expired. (This requires reliable 
> DELETE's so it
> > can't be reliably implemented without Son of IKE).
> 
> This is one possible solution.  You don't necessarily need 
> reliable DELETEs
> if you have some other method of detecting dead SAs.  In the 
> remote access
> case, you often don't get the deletes because people often 
> disconnect their
> laptaps before tearing down the IPSec connection.
> 
> Things would be much simpler if we could assume that the 
> phase 1 SA would
> always be around to help manage our phase 2 SAs.  Then you 
> could bind the IP
> address to the phase 1 SAs only.
> 
> 
> >
> > Are there other options? Does IKECFG require an extension 
> to _release_
> > the IP address (and any other resources allocated via 
> IKECFG) when the
> > client is about to disconnect from the VPN? For example, 
> should we add
> > a RELEASE payload type to the set of SET, ACK, REQUEST, and REPLY?
> 
> Perhaps, but then you'd have to set up a phase 1 SA just to 
> release it's IP
> address.  And again, many times, the Clients terminate their 
> connections in
> a very non-friendly way, and you wouldn't have the chance to 
> send a RELEASE
> payload.  Perhaps the best way is to just wait until all the 
> phase 1s and
> phase 2s disapear for whatever reason (deletes, inactivity, missing
> hearbeats...)
> 
> The protocol does allow one method which might help you 
> address this issue.
> With IKE-CFG you can specify a time period for which the IP address is
> leased.  The Client is then responsible for requesting a new 
> IP (or renewing
> the lease on the existing one) before that time expires.  If 
> he doesn't do
> so, the GW will (or at least should) tear down all SAs and 
> put that IP back
> in it's available pool.
> 
> Hope this helps,
> Stephane.
> 
> >
> > -Ben McCann
> >
> > P.S. I'm assuming the remote client only requests an IP 
> address after
> > its first Phase 1 exchange with the gateway. It should 
> continue using
> > that address while it has existing Phase 2 SA's independent
> > of the rekeying
> > activity of the Phase 1 SA. In other words, only request an
> > address after
> > you send INITIAL_CONTACT in a Phase 1 exchange.
> >
> > --
> > Ben McCann                              Indus River Networks
> >                                         31 Nagog Park
> >                                         Acton, MA, 01720
> > email: bmccann@indusriver.com           web: www.indusriver.com
> > phone: (978) 266-8140                   fax: (978) 266-8111
> >
> 
>