RFC 5996 says this about INITIAL_CONTACT:
The INITIAL_CONTACT notification asserts that this IKE SA is the only
IKE SA currently active between the authenticated identities. . . .
The INITIAL_CONTACT notification, if sent, MUST
be in the first IKE_AUTH request or response, not as a separate
exchange afterwards . . .
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.
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.
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?
(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'm interested in any other thoughts or experience folks on the list have
to offer,
Scott Moonen ([email protected])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
