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

Re: Heartbeats Straw Poll

> It is critical that the IP addresses are returned ASAP after the
> client has disconnected so they can be reused for the next client.

Is this "critical" as a consequence of excessively tight address
allocation policies?

If you're billing by "connect time" (a silly concept in a
connectionless network), bill the client until they either explicitly
delete the SA or DHCPRELEASE a leased address or until the SA/lease
expires.  That will give clients an incentive to do a clean
disconnect.. :-)

> > Keep-alives are most important if a dead session is consuming critical 
> > resources.  What resources are these?  Memory is very cheap these days, 
> > much cheaper than programmer time to hack IKE.  (To say nothing of WG 
> > time to consider the changes to IKE...)  Accounting?  Apart from the 
> > fact that I don't even understand what resource you're accounting for, 
> The same resources that we have been tracking for many years now.
> Duration of the call being of primary importance, 

That's not a "resource".  The memory used by the SA's is a resource;
so are any the IP addresses (but if you're allocating ip addresses,
you must be using some other protocol besides ipsec so that other
protocol could handle it).  As Steve said, memory is cheap... 

> bytes in/out,

well, if i disappeared, i'm not sending any bytes..

> disconnect reason, etc.

again, that's not a "resource."; it may be interesting to know for
diagnostic reasons, but it's not a "resource".

> > you can always record the timestamp of the last packet received on an 
> > SA.  That's cheap and easy; you're already doing far more processing 
> > than that per received packet.
> Not necessary cheap since it does effect your per-packet code path, but
> considering how much work goes into each packet for IPsec, I'll give you that
> one.  However this algorithm is not accurate enough to serve the purposes of
> accounting or IP address management.

"not accurate enough"?  It lets you know exactly when the client last
used its SA... more accurately than missed heartbeats would..

> I would hope the original is destroyed.  This really shouldn't be
> any different than a new phase 1/2 SA negotiation sequence with a
> peer which didn't receive the SA delete messages.

Well, certainly you should send using the newest SA which matches your
policy.  with respect to reception, at a minimum, I would hope that
there's a grace period there around rekey time to accept packets sent
to the old SA which were delayed in transit.  

I don't see the harm in letting the SA's live until they expire unless
a DELETE or INITIAL-CONTACT or other affirmative indication that
they're gone on the other end comes in..

					- Bill

Follow-Ups: References: