Hi, 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: Initiator Responder IKE_SA_INIT -> <- IKE_SA_IMIT 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 as normal. 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 :) Paul _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
