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 <riyazin...@gmail.com> wrote: > > 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 <ynir.i...@gmail.com >> <mailto:ynir.i...@gmail.com>> wrote: >> >> >>> On 12 Jun 2018, at 11:53, riyaz talikoti <riyazin...@gmail.com >>> <mailto:riyazin...@gmail.com>> 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 >> >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
