[Swan-dev] Calling all Message ID bugs
antony at phenome.org
Tue Feb 19 00:05:07 UTC 2019
On Mon, Feb 18, 2019 at 06:41:53PM -0500, Paul Wouters wrote:
> On Tue, 19 Feb 2019, Antony Antony wrote:
> > Here a few corner cases.
> > what happens in case where
> > an admin type connection down in the middle of the rekey.
> > I mean the initial rekey message is lost and pluto is doing its retransmit
> > cycle. While it is doing that admin type a "auto --down/delete conn"
> > n=1 would suggest pluto can't initiate a delete informational message
> > until rekey message is acknowledged. You have to go on retransmitting
> > rekey. While at it also think the same case without liveness/dpd and with
> > liveness. They wold be different.
> Yes, i guess the "down" message would have to go on the "pending list".
then wait for how long? I think it is hard decide when there is no liveness.
The user experience would be bad, when waiting to delete. It is likely
to end up with strange hacks. Think of iphone where users are impatient.
> I think people agree at IETF this needs clarification.
a solution at IETF level would be send a delete with ignore previous
messages notification, N(IGNORE_UPTO=6). Which would definitely solve the
mobike issue. I wonder if there are side effects to pushing deletes with
such a notification payload. Otherwise this would fix the delete case
waiting on rekey or liveness response.
Instead of IGNORE_UPTO one could also make it a range, if that would help
to fix where n > 1.
Then one end could fire of back to back deletes, and the initiator could
delete the connection.
As for pluto when deleting multiple IPsec SA do we send one delete each
I herd Paul mention send a delete to IKE SA if IKE SA and IPsec SA(s) are
going down at once.
More information about the Swan-dev