[Swan-dev] IKEv2 revival

[Paul Wouters]

On Fri, 1 May 2020, Tuomo Soini wrote:

>> the dpd/liveness action should be phased out. The hold action was to
>> keep a hold into place to prevent leaks, while another mechanism
>> restarts the connection. hold was never valid for connections with
>> rekey=no that are supposed to clean up all state when going down.
>
> Not so simple. auto=ondemand, rekey=no - that is on-demand tunneling.
> With this combination we absolutely want hold/trap.

Yes, but starting a connection also puts the policy in a hold. It is
the equivalent of add + route + initiate. The "route" causes the hold.

The real question here is some of the order or things, so we do not
briefly leak.

>> The fact that we can specify different dpdaction= for connections with
>> the same IKE SA is a limitation in our connection loading. I consider
>> it a misconfiguration that we do not need to support.
>
> I agree- and that is one reason why I think we should phase out
> dpdaction completely and add real logics which corresponds other config
> options. We really do know when we want tunnel to initiate again and
> when not.

Yup.

>> A liveness event that times out is a failure of the IKE SA, which
>> means it should affect ALL connections that share the IKE SA. They
>> should all go into failure mode. If revival is required, the
>> connections should go down into auto=ondemand to get a hold without a
>> leak. Once the connection is up the hold will be replaced with the
>> IPsec SA policy.
>
> Actually I think this works for most cases but not all. If only our end
> can initiate connection we should go to revival and try to get tunnel
> up. That is if config has auto=start we should initiate immediately.

revial == initiate immediately. The devil is in the details. We cannot
do delete + initiate without ensuring we put in a hold. I think the
revival code handles this?

> I agree. There must never be liveness before Child SA is established.
> Only established child sa can cause liveness checks to start.

The question is, what do you do when you have a shared IKE SA with
two children, and one of them is idle. It will trigger a liveness
I think but since the other SA is still live, I think we could just
not send one and assume the second one is just idle.

>> We should never try to send out a liveness probe if we are alread
>> waiting on an IKE reply. If a liveness probe is needed, then whatever
>> request is in transit will act as that liveness proof. If the current
>> request will timeout, that is also the equivalent to a failed liveness
>> probe, and the IKE SA gets torn down, taking down its children.
>
> Exactly - unlike with ikev1, when ike sa doesn't work we must take all
> our Child SAs down anyway.

Yup. And for IKEv1 the situation is just too bizarre to fix. You can
have a child with no ike sa, then if it becomes idle, you have to
setup a new IKE SA, and then you don't even know if the other end's
IKE SA is aware of that IPsec SA for a liveness probe.

Paul