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
