Scott C Moonen writes: > IKEv1 was unclear about the scope of this notification, and I'm glad that > IKEv2 made clear that it applies to identities and not IP addresses. But > there is an unfortunate chicken-and-egg problem here, and I'm kicking > myself for not noticing this back in 2009. The paragraph makes it clear > that the decision to send INITIAL_CONTACT is based on the authenticated > identities, and that the notify is sent in IKE_AUTH. However, the initiator > does not know the authenticated identities until it receives the IKE_AUTH > response. Even if the initiator sends an optional IDr payload, the > responder is not obligated to choose the same identity.
I do not think this is real issue. The initiator who is initiating the connection is initiating the IKEv2 connection only because it thinks it does not have existing usable IKEv2 SA / Child SA with the peer it wants to talk to. If it would have usable IKEv2 SA / Child SA with the peer it wants to talk to, it would be using that instead of creating a new one. So when initiator is sending this new connection it will know whether this is initial contact or whether it is creating multiple connections with the same peer with some other reasons (for example with different IDi). Also note that INITIAL_CONTACT is only fall back crash recovery system, in normal case the normal IKEv2 liveness checks will destroy old SAs after a while. > So it seems to me that the initiator can only confidently send > INITIAL_CONTACT based on IDi, and maybe based on IDr if it makes a > comprehensive search of its PAD. I.e., the initiator can send > INITIAL_CONTACT only if (1) its IDi is not in use by any other active > IKE_SA, or (2) the combination of its IDi and all permitted IDr's that may > be used for the remote address, based on an exhaustive search of the PAD, > is not in use by any other active IKE_SA. Yes. > This suggests to me that in general the usefulness of INITIAL_CONTACT is > limited. I wonder about a couple things. First, is there any interest in an > extension that allows for INITIAL_CONTACT after the IKE_AUTH completes? As this is backup crash recovery system, I think there is no point of making it more complicated than what it already is. The current rfc already says that you should send it "after a crash". I.e. it is not normally meant to be sent for every single new IKEv2 connection, altought I think most of the implementations do send it. > (And is that something that would be worth piggybacking onto the QCD > draft?) Second, is there room to stipulate, perhaps in an erratum or in a > clarifications draft, that when the initiator sends an optional IDr, the > INITIAL_CONTACT notification applies only if the responder ends up choosing > that identity as its IDr? I think interpreting the INITIAL_CONTACT in such a way that it only applies to the IDi, and IDr sent by the initiator, and if the responder selects different IDr, it should not delete the IKE SA between the original IDi and IDr it selected. Note, that the currect text says "recipient MAY use this information to delete any other IKE SAs it has to the same authenticated identity without waiting for a timeout." In most cases if the initiator's IDr is not acceptable most likely the created IKE SA will not be very useful at all. Also initiator IDr is not very commonly used, and was meant to be used in cases where same server hosts several security gateways and the IDr is used to select one of them. What happens if the proposed IDr is not acceptable, is not covered by the RFCs. I myself would classify that case as a corner case which might require special handling in some scenarios, but that special handling can be done by the implementation without affecting the interoperability, i.e. the security gateway implementation supporting multiple local identities, and getting connection in where the initiator's IDr is not acceptable, it should interpert INITIAL_CONTACT to only apply to the proposed original initiator's IDi/IDr pair, not the newly selected one. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
