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 protected]> wrote:
>
>
>> On 12 Jun 2018, at 11:53, riyaz talikoti <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> 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.
>>
>
> 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
>
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
