Hi Keith,
I think this version makes a lot of sense. A few comments:
* I don't like the asymmetrical nature of the notification, which
implies that only the original initiator can initiate the second
IKE_AUTH. There may be cases when the responder would like to
reauthenticate (e.g. mutual EAP with passwords). So I suggest to
have both peers send the notification if they support this extension.
* Please say explicitly whether/how this extension interacts with
RFC 6023: can the reauthenticated IKE SA be childless?
* The introduction mentions three problems. Please add text
somewhere on how they are solved by this proposal.
* Typo in Sec. 4: "MUST be the same as the as the SPIs".
Thanks,
Yaron
On 12/01/2011 23:20, Keith Welter wrote:
In the thread "Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00", Yoav
proposed:
"having an IKE_AUTH exchange in the middle of the IKE SA lifetime.
Suppose the IKE SA has been around for a couple of hours, and has been
used for creating some child SAs, why not keep it and just pass one or
more IKE_AUTH exchanges?"
draft-welter-ipsecme-ikev2-reauth-01 specifies this alternative design.
To refresh everyone's memory on the problems that the draft aims to
solve, I'll include the introductory text from the new version of the
draft here:
"IKE SA reauthentication as defined in [IKEv2] is accomplished by
creating a new IKE SA, creating new Child SAs, and deleting the old
IKE SA. Assuming that the old IKE SA has n Child SAs,
reauthentication as defined in [IKEv2] requires at least n+1 message
exchanges. This style of reauthentication does not scale well when n
is large. The extension described in this document allows
reauthentication of an IKE SA using a single IKE_AUTH exchange on the
IKE SA to be reauthenticated without creating a new IKE SA or new
Child SAs. The terms IKEv2, IKEv2 SA, and Child SA and the various
IKEv2 exchanges are defined in [IKEv2]
Other problems with IKE SA reauthentication as defined in [IKEv2]
include:
o Simultaneous IKE SA reauthentication may result in redundant SAs.
o Child SAs for which an internal address was assigned using the
Configuration Payload may experience a connection disruption for
reassignment of an internal address.
o While [IKEv2] describes how to handle exchange collisions that
may occur during IKE SA rekeying, it does not do so for exchange
collisions that may occur during reauthentication which could inhibit
interoperability in such cases."
Please share your comments on draft-welter-ipsecme-ikev2-reauth-01.
Thanks,
Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)
[email protected] wrote on 01/12/2011 12:32:07 PM:
> [image removed]
>
> [IPsec] draft-welter-ipsecme-ikev2-reauth-01
>
> Keith Welter
>
> to:
>
> ipsec
>
> 01/12/2011 12:36 PM
>
> Sent by:
>
> [email protected]
>
>
> A new version of I-D, draft-welter-ipsecme-ikev2-reauth-01.txt has
> been successfully submitted by Keith Welter and posted to the IETF
repository.
>
> Filename: draft-welter-ipsecme-ikev2-reauth
> Revision: 01
> Title: Reauthentication Extension
for IKEv2
> Creation_date: 2011-01-12
> WG ID: Independent Submission
> Number_of_pages: 6
>
> Abstract:
> This document describes an extension to the Internet Key Exchange
> version 2 (IKEv2) protocol that allows an IKEv2 Security Association
> (SA) to be reauthenticated without creating a new IKE SA or new Child
> SAs.
>
>
>
> The IETF Secretariat.
>
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
