Subject: [IPsec] Reauthentication extension for IKEv2

From: David Wierbowski <[email-masked]>
Date: Tue, 16 Sep 2008 10:12:21 -0400

>> But the real problem are application session: They might break during
>> these communication interrupts, and are guaranteed to break if the
>> INTERNAL_ADDRESS changes.
>
>I agree, thats why I think the way you presented there where you first
>remove the IKE SA and then start it over so you get the same address
>is the only one that really works. In most cases for remote
>access cases you have only one IPsec SA so creating new IKE SA and
>that IPsec SA is fast and should not disturb normal TCP/IP flows
>(unless your operating system does stupid things, like destroy all
>TCP/IP flows when you do the recreationg of the IKE SA).

Are we clarifying the IKEv2 clarifications now?  RFC 4718 states:

   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).

The suggestion above contradicts 4718.  It seems as if the best resolution
would be to add real support for reauthentication.

Dave Wierbowski

z/OS Comm Server Developer

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 17 Sep 2008 13:35:46 +0300

David Wierbowski writes:
> Are we clarifying the IKEv2 clarifications now?

No, I think the plan was to have new protocol. 

> RFC 4718 states:
> The suggestion above contradicts 4718.

That way of reauthentication is good if you do not have internal ip
allocated from the gateway. If you do have internal ip-address
allocated from the gateway, then that will most likely fail, as unless
the server implementation knows how about reauthentications it will
not allow giving out same IP-address to some other IKE SA. 

> It seems as if the best resolution

If we add new reauthentication protocol that would need to be separate
document not part of IKEv2bis. If we simply clarify how to do the
reauthentication without adding new protocols that can most likely be
added to the IKEv2bis.

We could for example add following paragraph to explain
reauthentication (after the paragraph you quoted):

   This method of reauthentication can introduce problems when used in
   combiation with configuration payloads (i.e. when client has
   INTERNAL_ADDRESS allocated from the gateway) unless the server
   implementation allows duplicate INTERNAL_ADDRESSs to be allocated
   to new IKE SA even when it is still in use with the old IKE SA. The
   server implementation should check that such duplicate addresses
   are only allowed when the new IKE SA connection comes from the same
   IP address and port, and has same configuration parameters than the
   existing IKE SA (i.e. requests same IP-address that is already in
   use) and when the authenticated identity of the both IKE SAs is
   exactly same. The server can also move the old IKE SA to degraded
   state, where it refuses to create more IPsec SAs (returning
   NO_ADDITIONAL_SAS error instead).

(I noticed that mentioning INITIAL_CONTACT notification is not needed,
as if there is INITIAL_CONTACT in the new IKE SA then the old IKE SA
will be removed when processing that INITIAL_CONTACT notification,
thus the IP address will be free). 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec