Subject: [IPsec] RFC 5996 and INITIAL_CONTACT

From: Scott C Moonen <[email-masked]>
Date: Thu, 19 May 2011 10:52:04 -0400

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-masked])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 26 May 2011 17:09:41 +0300

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

> is not in use by any other active IKE_SA.

Yes. 

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

> 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-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Fri, 27 May 2011 10:18:33 -0400

> with the same peer with some other reasons (for example with different

The problem is that we've defined "same peer" for INITIAL_CONTACT purposes
to be based only on identities. Until the connection is complete, the
initiator cannot know for sure if this peer will be using the same identity
as some other peer that it's already connected to. The RFC even explicitly
admits that this is a possibility ("may be replicated").

The implication is that *even after a crash* the initiator may not be able
to send INITIAL_CONTACT in every case.

> > is not in use by any other active IKE_SA.

Ok, thanks.

> between the original IDi and IDr it selected.

Ok, thanks.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
1-919-254-1388 (T/L: 444-1388)
http://www.linkedin.com/in/smoonen

From:	Tero Kivinen <[email-masked]>
To:	Scott C Moonen/Raleigh/IBM@IBMUS
Cc:	[email-masked]
Date:	05/26/2011 10:10 AM
Subject:	[IPsec] RFC 5996 and INITIAL_CONTACT

Yes.