Project

General

Profile

Bug #8989

Allow IKEV2 pf_key(7P) key management cookies to be updated after set

Added by Jason King over 2 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
networking
Start date:
2018-01-24
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

Upstream of Joyent OS-6480:

Joyent's OS-6333 (illumos #8927) allowed the use of 64-bit key management cookie (KMC) values in anticipation of IKEv2. This was to allow for a succinct, unambiguous way to link an IPsec SA (a child SA in IKEv2 parlance) with the corresponding IKEv2 SA (Security Association) that is handling the key management when the kernel is requesting the IKEv2 daemon to perform some key management function on it's behalf (typically to create a replacement IPsec SA with a new key when an IPsec SA has reached the end of it's lifetime). This is accomplished by using the local IKE SPI (Security Parameter Index) as the cookie value. The IKEv2 daemon has full control over how the local IKE SPI is chosen and we have elected to make it randomly generated and unique across all IKEv2 SAs managed by a given IKEv2 daemon instance, so the local IKE SPI can act as a unique identifier. However the existing code does not allow the KMC value of an IPsec SA to be changed once set.

Unlike IKEv1, IKEv2 has explicit support for also refreshing the key material used to encrypt IKE protocol traffic (a rekey operation in IKEv2 parlance). Without this, when the IKE SA has reached the end of it's lifetime, it along with any IPsec SAs it has created must be deleted and the entire key exchange process (IKE protocol algorithm negotiation, IKE authentication, child (IPsec) SA negotiation and creation). With the rekey support, new key material can be generated and exchanged, eliminating this potentially disruptive operation (all subject to operator preference).

At a high level, this IKE rekey operation creates a new IKE SA (with a new key) and once created, any still live child (IPsec) SAs are then moved to this new IKE SA (i.e. they are now managed by the new IKE SA instance). This necessitates being able to update existing IPsec SAs with a new KMC value (via an SADB_UPDATE or SADB_UPDATE_PAIR message).
This change will add a new KMC protocol SADB_X_KMP_IKEV2 and will update the kernel SADB code to allow SADB_X_KMP_IKEV2 KMCs to be updated even after being set. The existing closed source in.iked will not be affected as it does not try to change KMCs after being set (and it also uses a KMC protocol of SADB_X_KMP_IKE whose behavior will not change).

History

#1

Updated by Electric Monk over 2 years ago

  • % Done changed from 0 to 100
  • Status changed from New to Closed

git commit 4c5582ef5befe9f7cecf33c219b1c314562dff33

commit  4c5582ef5befe9f7cecf33c219b1c314562dff33
Author: Jason King <jason.king@joyent.com>
Date:   2018-02-08T16:35:10.000Z

    8989 Allow IKEV2 pf_key(7P) key management cookies to be updated after set
    Reviewed by: Dan McDonald <danmcd@joyent.com>
    Reviewed by: Richard Lowe <richlowe@richlowe.net>
    Approved by: Gordon Ross <gordon.ross@nexenta.com>

Also available in: Atom PDF