Tero Kivinen wrote: > > pasi.ero...@nokia.com writes: > > - Section 2.25: "A peer that receives a CHILD_SA_NOT_FOUND > > notification SHOULD silently delete the Child SA": Is this really > > necessary? I think this notification should only occur in cases where > > DELETE payload for this Child SA pair has already been sent, and > > probably has been processed already by the time the > > CHILD_SA_NOT_FOUND > > notification is received. > > I agree on that, and I proposed new wording for that: > > A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer > receives a request to rekey a Child SA that does not exist A peer > that receives a CHILD_SA_NOT_FOUND notification SHOULD silently > delete the Child SA (if it still exists, as most likely delete > notification sent by the other hand has already deleted it) and > send a request to create a new Child SA from scratch if such > Child SA does not yet exists.
Thanks -- this is much clearer. > > - Section 2.25.2, "If a peer receives a request to delete a Child > > SA when it is currently rekeying the IKE SA, it SHOULD reply as > > usual, with a Delete payload." I noticed this is different from > > what RFC 4718 recommended, but this is probably OK, given the > > other text... (but I still hope this was intentional change :-) > > This was intentional change. <snip> OK; with this reply, I'm OK with closing issue #142. Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
