Subject: [IPsec] INITIAL_CONTACT in IKEv1

From: riyaz talikoti <[email-masked]>
Date: Tue, 12 Jun 2018 14:23:46 +0530

Hi All,
Need help with couple of questions related to INITIAL_CONTACT in IKEv1

1. Is it NOT wrong to send INITIAL_CONTACT notification in QUICK MODE?
Will it NOT end up in deleting the IKE SA(Phase 1 SA) which is being
created as part of just completed AGGRESSIVE MODE exchange?
If we receive INITIAL_CONTACT notification in QUICK MODE, as a responder
should we ignore the notification?

2. On receiving INITIAL_CONTACT we delete IKE SA. Doesn't it make sense to
delete all IPSec SA's(Phase 2 SA's) which are part of that particular IKE
SA(Phase 1 SA) ?
Because the whole purpose is to inform responder to delete all previous
connection related to this identity as initiator is coming UP freshly.

Regards
Riyaz

---

From: Yoav Nir <[email-masked]>
Date: Tue, 12 Jun 2018 20:04:40 +0300

> On 12 Jun 2018, at 11:53, riyaz talikoti <[email-masked]> wrote:
> 
> Hi All,
> Will it NOT end up in deleting the IKE SA(Phase 1 SA) which is being created as part of just completed AGGRESSIVE MODE exchange?
> If we receive INITIAL_CONTACT notification in QUICK MODE, as a responder should we ignore the notification?
> 
> 2. On receiving INITIAL_CONTACT we delete IKE SA. Doesn't it make sense to delete all IPSec SA's(Phase 2 SA's) which are part of that particular IKE SA(Phase 1 SA) ?
> Because the whole purpose is to inform responder to delete all previous connection related to this identity as initiator is coming UP freshly.
> 

Hi, Riyaz

INITIAL_CONTACT is defined in section 4.6.3.3 or RFC 2407.  It does not specify that this notification should only be sent in phase 1 messages, although I agree that it makes little sense in the context of QUICK MODE.

So the answer to #1 is that it is not wrong.

The meaning of this notification is that all IKE SAs except the one being used or created in this negotiation is not known to the sender. RFC 2407 unfortunately talks only of an “SA” without specifying whether this is about an IKE SA or an IPsec SA. I think the only sane interpretation is that this is about IKE SAs. So if an AGGRESSIVE negotiation created an IKE SA and this IKE SA is used to protect the QUICK MODE, that IKE SA is safe. If the AGGRESSIVE negotiation was used to create a different IKE SA, then it will be deleted.

You are always allowed to ignore an INITIAL_CONTACT notification. It is meant to help you with state management.  If you use some other IKE SA created before you received the INITIAL_CONTACT, you are very likely to get an error.

Regarding question #2: To clarify, on receiving INITIAL_CONTACT you delete all the other IKE SAs, not the one used in the negotiation.
The question of deleting the associated IPsec SAs when deleting an IKE SA is, unfortunately, not answered in the IKEv1 RFCs. Most vendors followed Cisco’s example and deleted them. A few didn’t.  In the case of INITIAL-CONTACT it makes even more sense than when an IKE SA is explicitly deleted with a DELETE payload.

HTH

Yoav

---

From: riyaz talikoti <[email-masked]>
Date: Thu, 14 Jun 2018 21:33:23 +0530

Hi Yoav,
Thanks a lot for the response.
Just a quick question on top of what you wrote. 

If a responder did not delete IPSec SA’s and only deletes IKE SA when it receives IC. 
Will it not result in blackhole? 

Lets say 
PEER-A ——————— — — PEER-B
IKE SA(XX)			         IKE SA(XX)
IPSEC SA(SPI AA)                   IPSEC SA(SPI AA)

PEER-A starts initiating new session and starts AGGRESSIVE_MODE. 
PEER-B receives IC and lets say PEER-B deletes ONLY IKE SA(XX)(recommended by RFC), 
But will NOT delete IPSEC SA(SPI AA)(as RFC does not mention anything about it).

And AM and QM exchanges gets completed and new sets of SA’s comes UP on both sides

Now 
PEER-A ——————— — — PEER-B
IKE SA(YY)			          IKE SA(YY)
IPSEC SA(SPI BB)                   IPSEC SA(SPI BB)
						  IPSEC SA(SPI AA) —> NOT DELETED When IC is received.

For outgoing traffic from PEER-B, if SPI AA is chosen from SADB, will it NOT get dropped at PEER-A with INVALID_SPI.
So does it not make sense to delete all IPSec SA’s when IC is received.

Regards
Riyaz

> On 12-Jun-2018, at 10:34 PM, Yoav Nir <[email-masked]> wrote:
> 
> 
>> On 12 Jun 2018, at 11:53, riyaz talikoti <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi All,

---

From: Yoav Nir <[email-masked]>
Date: Thu, 14 Jun 2018 19:25:20 +0300

I think at a minimum we have to have the behavior well-defined rather than open to interpretation. That IMO is the most important thing we got in IKEv2.

As long as some IKE SA exists between PEER-A and PEER-B, the peer that does not have the IPsec SA can inform the other side with an INVALID_SPI protected notification. But I agree it’s better to not get into this situation by wiping out the IPsec SAs with the IKE SA. Like we do in IKEv2.

> On 14 Jun 2018, at 19:03, riyaz talikoti <[email-masked]> wrote:
> 
> Hi Yoav,
>> On 12-Jun-2018, at 10:34 PM, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>