Scott C Moonen writes: > Tero, I don't understand. Two weeks ago you said: > > If you use that kind of halfway up IKE SA for sending INFORMATIONAL > > message to other end (who thinks the IKE SA is up and valid), then I > > agree that sending both N(AUTHENTICATION_FAILED) and DELETE would be > > the correct way to do it. DELETE only would also be ok. > > Now I think you are suggesting that DELETE is improper in this case, which > directly contradicts your earlier note.
You can either send N(AUTHENTICATION_FAILED) or you can send DELETE, sending them both does not really help (if you send both you just say twice that delete this SA). Or you can simply log the situation to the local end and ask user to take corrective actions (for example if you are VPN client software) and assume that next connection with INITIAL_CONTACT or DPD will take care of the old IKE SA. The reason sending both of them might make sense is that it should be complatible with almost any implementation, i.e. those who consider N(AUTHENTICATION_FAILED) fatal will delete IKE SA because of that and those who do not, still delete the IKE SA because of the DELETE payload. As this is very small corner case which do not affect the interoperability, and in most situations it does not even have any perceivable effect on the whole system, I do not really have strong opinion in either way. It also depends what kind of other text we have. In my suggested text it is clear that N(AUTHENTICATION_FAILED) causes IKE SA to be deleted, so in that case sending delete would be unnecessary (i.e. N(AUTHENTICATION_FAILED) would be enough). With the RFC4306 text sending delete might be helpful (but not required). -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
