[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
>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?
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
volume....)
--Steve Bellovin
Follow-Ups: