Subject: [IPsec] Issue #53: Handling of INITIAL_CONTACT

From: Yaron Sheffer <[email-masked]>
Date: Wed, 1 Apr 2009 23:37:55 +0300

Yaron:

2.4: Clarif-7.9 is unclear: [this MUST be sent in the first IKE_AUTH
request.] 'however, receiving parties need to deal with it in other
requests' - what requests? How? Why should it ever happen?

SF discussion:

David Black: if you put initial_contact in anything other than an IKE_AUTH

          something is wrong, do you have the critical bit on it?

          Tero: comes from IKEv1

          Greg Lebowitz: clarify: only pay attention to it if it arrives in
IKE_AUTH

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 3 Apr 2009 16:06:33 +0300

>           Greg Lebowitz: clarify: only pay attention to it if it arrives in

To clarify how it comes from IKEv1: In the IKEv1 the extra
notification payloads sent along the main mode or aggresive mode
exchanges were not authenticated, meaning that attackers could add /
remove those. Because of this it was considered unsafe to send
INITIAL_CONTACT notifications during the initial phase 1, and it was
usually sent only after the initial exchange as a separate
informational exchange.

As in IKEv2 the IKE_AUTH messages are authenticated, I do not really
see any reason why we should allow INITIAL_CONTACT anywhere else than
in the IKE_AUTH request, but as the generic rule says you can put
status notifications anywhere, and those should not cause errors,
meaning that if INITIAL_CONTACT is sent anywhere else it can be
ignored.

I remember there was also discussion earlier whether the responder can
send INITIAL_CONTACT notification to tell that it does not have any
SAs. The current ikev2bis text says it MUST be first IKE_AUTH request,
meaning it cannot be sent by the responder (which is sending IKE_AUTH
response, not request).

I think the current MUST is ok, and we should just change the
"receiving parties need to deal with it in other requests." to
"receiving parties MAY ignore it in other messages."

I do not want implementations to fail the whole IKE SA because of
someone reused old IKEv1 code and sent INITIAL_CONTACT as separate
INFORMATIONAL exchange. Ignoring it is safe option, as it does provide
interoperability. Processing it in other exchanges should also be
allowed, but not required (i.e. I do not want to make some
implementation non-conformant, just because they want to be backwards
compatible with their old versions which sent INITIAL_CONTACT in
"wrong" place). The whole INITIAL_CONTACT processing is only
optimization and not very important for the IKEv2, as the IKEv2 is
reliable protocol, meaning that other end most likely have already
detetected that the old IKE SA was lost before the initiator
reconnects after crash.
-- 
[email-masked]