[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Heartbeats Straw Poll
On Tue, 8 Aug 2000, Steven M. Bellovin wrote:
> In message <Pine.GSO.4.10.10008072341440.9000-100000@uzura.cisco.com>, Skip Boo
> th writes:
>
>
> >If I understand this proposal correctly, it depends on the SG which still has
> >state to be transmitting data. In a client to SG scenario, most of the traffi
> >c
> >from the SG to the client will only occur as the result of the client making
> >some transaction request. Thus when the client disconnects, there is a high
> >probability that no traffic will flow in the direction of the client. This
> >mechanism doesn't seem to allow the SG to reliably determine when the peer has
> >lost state.
>
> Right -- but I still don't understand why it matters that much. As you
> say, the client will initiate most transfers, so it will know if things
> are dead, and hence if renegotiation is needed. Why does the server
> even care?
The server cares because it has to do things like stop accounting (a very
important remote access function) and return IP addresses back to the DHCP
server or to it's local pool. It is critical that the IP addresses are returned
ASAP after the client has disconnected so they can be reused for the next
client.
> 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, bytes in/out, disconnect reason, etc.
> 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.
>
> If you really need to know if an SA is dead, use a layered solution.
> The IPsec endpoint can periodically send a protected ICMP ECHO to the
> far end. If it is acknowledged, all is well. More generally, *any*
> traffic received can reset the timer. If m pings in a row are lost,
> throw away the SA and let any new traffic from your side create a new
> one. The far side can run the same protocol; if your side discards its
> half of the SA, the far side won't receive any response to its pings,
> so it will tear down its side as well.
This is a fair proposal and one that has been made before if memory serves me
correctly. It is simply a keepalive mechanism, albeit one that doesn't require
any change to IKE which is probably a good thing. However it does double the
number of SAs a box must terminate in the remote access scenario.
>
> The really interesting question, to me, is what should happen when a
> new SA is created with the same SPD data as an existing one. That is,
> what happens when one side thinks things are dead and tries to create a
> new SA, while the other side thinks things are fine. That can happen
> with my proposal and with keep-alives -- the condition that creates any
> sort of keep-alive failure is a loss of communications.
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.
>
> Btw -- any sort of keep-alive, whether at the IKE level or not, can
> defeat port idle timers. This in turn can lead to overconsumption of
> two different resources that are in short supply: modem ports on the
> terminal server, and the money used to pay hotels that charge for
> overly-long calls. (We won't even discuss ISPs that charge by byte
> volume....)
Agreed.
-Skip
>
> --Steve Bellovin
>
>
>
>
Follow-Ups:
References: