[IPsec] Reauthentication extension for IKEv2

Hi,

The reauthentication procedure for IKEv2 works as follows (from
draft-ietf-ipsecme-ikev2bis-00 2.8.2):

   IKEv2 does not have any special support for reauthentication.
   Reauthentication is done by creating a new IKE_SA from scratch (using
   IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
   payloads), creating new CHILD_SAs within the new IKE_SA (without
   REKEY_SA notify payloads), and finally deleting the old IKE_SA (which
   deletes the old CHILD_SAs as well).

While this approach works and reuses existing protocol elements, it has
some disadvantages. The problem is that we actually can't know that an
incoming IKE_SA setup is used for reauthentication, as creating multiple
identical IKE_SAs is perfectly feasible.

1. If a lot CHILD_SAs are established within the IKE_SA, this procedure
   needs a lot of exchanges to complete, increase load and reauth
   duration. During this stage, we also have multiple CHILD_SAs with
   the same traffic selectors. Defining priorities is difficult, as
   we don't know if the new IKE_SA is actually for reauthentication or
   not.
2. The server doesn't know that the new IKE_SA creation is used for
   reauthentication and can't assign the same INTERNAL_ADDRESS to the
   peer without risking an address conflict. This will result in an
   address change and will close established connections using that
   address.
3. Housekeeping and connection monitoring gets ways more complicated,
   as the new IKE_SA does not have any relation to the old one.

Mainly because of 2., we have been forced to do the reauthentication
procedure by closing the IKE_SA before establishing the new one. This
will eliminate the address flicker, but introduces a connectivity gap of
seconds.

While there are workarounds to these problems, I don't see a way to
implement reauthentication properly and reliable. Because of these
problems I'm thinking about an extension to do the reauthentication
within an established IKE_SA (think of the existing rekeying procedure,
but with an additional AUTH/EAP exchange).

What do you think about such an extension? Already considered something
similar, or does your reauthentication procedure work hassle-free? I'm
wondering if we are the only ones facing these problems or if such an
extension would gain broader acceptance...

Regards,
Martin - strongSwan project

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec