There was a lot of debate in the original IPsec working group about
INITIAL_CONTACT. We should be careful not to add any MUSTs that would make
noticing it mandatory, since that would complicate minimal implementations. It
would be reasonable to say that if an IKE SA is deleted in response to an
INITIAL_CONTACT notification, the node deleting is SHOULD NOT send a DELETE
payload or any other notification on the obsolete SA.
The real use of INITIAL_CONTACT involves semantics not specified in IKEv2 (and
I never really understood the semantics in the architecture document). The
problem is that if there are two SAs that specify duplicate traffic selectors
(or even overlapping), how is the destination supposed to know which one to use
when sending outbound traffic? INITIAL_CONTACT addresses the problem in
practice but not in theory, because it closes SAs with the same authenticated
identity, not with the same traffic selectors (which could be independent).
It's a can of worms that I don't think we should reopen unless there is some
real problem we're trying to solve.
--Charlie
-----Original Message-----
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Paul
Hoffman
Sent: Friday, January 01, 2010 11:29 AM
To: Tero Kivinen; Yaron Sheffer
Cc: IPsecme WG
Subject: Re: [IPsec] Clarifying what happens with INITIAL_CONTACT
At 1:08 PM +0200 12/29/09, Tero Kivinen wrote:
>Paul Hoffman writes:
>> At 5:28 PM +0200 12/28/09, Yaron Sheffer wrote:
>> > You are adding two MUSTs, which we SHOULD NOT do unless we have
>> > very good reasons, such as interop problems, security issues, or
>> > major functionality problems (like memory leaks). I'm not sure any
>> > of these apply, so I suggest that you change the wording to be
>> > non-normative.
>>
>> Whoops, all good points. I got carried away. How about:
>>
>> When an initiator receives an INITIAL_CONTACT notification in
>> response to its IKE_AUTH request, it silently deletes any IKE SAs and
>> associated Child SAs for that responder without sending any
>> notifications to the responder. If a responder receives an
>> INITIAL_CONTACT notification in an IKE_AUTH request, it silently
>> deletes any IKE SAs and associated Child SAs for that initiator
>> without sending any notifications to the initiator.
>
>I would actually keep the keyword we have in the RFC4306, i.e. "MAY".
>It says "... recipient MAY use this information to delete any other
>IKE_SAs ...". I am not sure what you say above and the MAY are really
>same. For me the text above says you need to do it, even when it does
>not have word "MUST" in it, as it only gives you exactly one option.
>
>As implementations are not required to understand (or send)
>INITIAL_CONTACT notifications writing text like you have is bit
>dangerous, as some people might still read that recipient of
>INITIAL_CONTACT needs to silently delete any IKE SAs when it receives
>INITIAL_CONTACT.
Hrm. Another good point. Ignore this proposed change. FWIW, what I was really
trying to get at in the addition was that, if you delete SAs when you get an
INITIAL_CONTACT, you should do it silently, not by sending Delete
notifications. But I don't see how to do that without adding normative-like
language; if others can see how to say that, by all means let me know.
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
