[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
>
References: