[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SA Recovery (was RE: issues from the bakeoff)
>>>>> "Slava" == Slava Kavsan <bkavsan@ire-ma.com> writes:
Slava> Thanks Tim, I agree that active keep-alive will solve the
Slava> problem, but it will take some time to agree on the standard
Slava> for that.
Slava> In the interim I was trying to stimulate discussion on the use
Slava> of usually long series of INVALID_SPI messages from the
Slava> re-booted node, which are unfortunately unprotected, but may
Slava> contain some "clue" of their authenticity.
I've wanted that too, but I haven't been able to come up with a scheme
that feels at all comfortable as far as Denial of Service
vulnerability. You're suggesting that a message might have some clue
of its authenticity -- such as what? I agree that this is possible
for the case where I delete an SA and for some reason the other end
does not (I can remember the SPI I deleted for a while). But it's
hard to see how a freshly rebooted node can look at an incoming SPI,
which is typically a random number, and distinguish a valid random
number from an invalid one.
Rate limiting the recovery mechanisms may help. But I'd rather push
harder on the keep-alive solution. Supposedly there are already
implementation of proprietary schemes, and it seems to me that in any
case the mechanism needed is really trivial. How long can it take to
define such a beast? (In other words, can it take significantly
longer than the invalid_spi driven recovery mechanisms? I wonder.)
paul
References: