[Swan-dev] architecture of IKE resumption on the client side
paul at nohats.ca
Mon Jul 6 21:03:40 UTC 2020
For GSoC we are working on IKEv2 Session Resumption https://tools.ietf.org/html/rfc5723
The first (maybe only?) implementation does ticket by value.
The work flow is:
IKE_AUTH with TICKET REQUEST ->
<- IKE_AUTH with TICKET
At this point, the connection can "suspend".
On the client, it needs to keep some state (eg sk_d, IDi/IDr,certs) and
the ticket blob (which is encrypted and can only be read by the server)
On the server, all the state can be deleted (eg via failed livenes). If
the connection was an instance, it can be deleted.
To resume, the initiator sends an IKE_RESUMPTION exchange with the
ticket. The server decrypts the ticket to obtain connection, sk_d, etc.
Both ends can now compute the new SKEYSEED, and things continue almost
The question is what to do on the initiator to "suspend":
1) keep the connection, delete the states, and store some of the state
such as ticket and sk_d on the connection in struct temp_vars.
2) Keep the connection, delete the IPsec SA state and keep the IKE SA
state. Move it to a new state_kind STATE_PARENT_SUSPEND with a
cleanup event scheduled for the ticket lifetime received.
3) As two, but store everything on disk, including connection name, so
we can survive a reboot. This has a lot of implications, eg FIPS,
so maybe think about this only later.
1) is probably easier, as we won't need a new state_kind. It also
guarantees that we don't keep old obsolete information that was
stored on the state. Eg NAT detection, IP/port info etc. It is somewhat
ugly as it has to use temp_vars on the connection.
2) is harder as we need to fixup all the code handling all state_kind's.
It allows us to keep the IKE SA state, so no copying of SymKey stuff
back and forth. But no clean new state later on either.
We could combine 1) and 2) by creating the new IKE SA state, and copying
what we need from the old state, keeping pointers intact of symkeys, and
move it in STATE_PARENT_SUSPEND.
I'd like to hear from others :)
More information about the Swan-dev