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. > - 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. When we discussed this in the design team, nobody see any reason why it should reply without the delete payload. In all implementation I know the SPI itself is enough to delete the SA, it does not really matter whether that Child SA was already moved to the new IKE SA or whether it was still in the Old IKE SA. This means sending delete to either one of the SA will cause the Child SA to go and that SPI cannot refer to any other Child SA. So most of the implementations will be replying with delete payload as usual and the Child SA is deleted. Implementations are always allowed not to return the delete payload immediately if they like, so the old behavior from RFC4718 is still also allowed, but not preferred. We tought it would be best to try to limit the amount of cases where half-closed SAs could be created so we though it is better to close the Child SA directly without going first to the half-closed state, and waiting for the other end to send another delete payload (using new IKE SA?) for the other half. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
