[Swan-dev] IKEv2 revival

[Andrew Cagney]

On Sun, 3 May 2020 at 21:18, Paul Wouters <paul at nohats.ca> wrote:
>
> On Sat, 2 May 2020, Andrew Cagney wrote:
>
> > Tuomo and I spent a bit of Friday debugging a regression where the
> > liveness probe was stomping on a DISCARD event (forcing it to REPLACE)
> > set according to the connection.
>
> I think there are two reasons why a state can get a DISCARD event. One
> is for when there is no rekeying scheduled and it reaches its end of
> life. The other is when it has been replaced by another IPsec SA, and
> we let it linger for a while. Unfortunately, "a while" is just the
> original end of life timeout. The revive code I guess tries to determine
> if this state is the c->newest_ipsec_sa and then is supposed to act
> differently (let it die or try to spin up new one)

Yes. SO_DISCARD assumes a failure and a timeout.  Other than logging
and who to blame it is identical to CRYPTO_TIMEOUT.

-> there should be a way to zap a state without any counting

> > Anyway, I think this points to the next change.  When retransmits
> > fail, force what ever event is in .st_event (and I'm tempted to rename
> > .st_event to .st_kill_event or .st_death_event).

The test results didn't come across as either better or worse :-/

So lets break this down.  An SA expected to end its life through either:

- CREATE_CHILD_SA/rekey exchange
- DELETE exchange

When looking at the user concepts, it seems to be something like:

- a rekey is CREATE_CHILD+SA+rekey exchange; with a bit saying that
should things go south revive the connection
- expire is just a delete with a bit saying if things go south, don't
revive the connection
- replace (no rekey) is more convoluted but from the POV if this state
it is just a delete (but start trying to establish the replacement
early), and perhaps also a bit saying revive the connection

so should any exchange timeout, I'm guessing it needs to though the
family and revive anything with the revive bit set



> Maybe st_afterlife ? :)
>
> Paul