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

Re: Heartbeats Straw Poll

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
>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?

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, 
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.

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.

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.

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 

		--Steve Bellovin