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. Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Tero Kivinen <kivi...@iki.fi> To: Scott C Moonen/Raleigh/i...@ibmus Cc: Paul Hoffman <paul.hoff...@vpnc.org>, "ipsec@ietf.org WG" <ipsec@ietf.org>, ipsec-boun...@ietf.org, Yoav Nir <y...@checkpoint.com> Date: 09/22/2009 05:06 AM Subject: Re: [IPsec] Issue #26: Missing treatment of error cases Scott C Moonen writes: > > <t>NOTE FOR WG DISCUSSION: Having other payloads in the message is > > allowed but there are none suggested. One WG member mentioned the > > possibility of adding a DELETE payload when the error is sent in a > > separate INFORMATIONAL exchange. Do we want to allow such additional > > payloads that have operational semantics?</t> > > I think you are asking specifically about the IKE_AUTH response? If so, I > agree that DELETE does not make sense in the IKE_AUTH response, and > N(AUTHENTICATION_FAILED), for example, is sufficient to delete the IKE SA. > I think we can forbid DELETE in the IKE_AUTH response. However, because > a separate INFORMATIONAL exchange cannot be definitively correlated to the > IKE_AUTH exchange, I'd like to retain the option of sending both DELETE > and N(AUTHENTICATION_FAILED) (for example) in a separate INFO exchange. You cannot really get AUTHENTICATION_FAILED in any other places than IKE_AUTH, as the text says: AUTHENTICATION_FAILED 24 Sent in the response to an IKE_AUTH message when for some reason the authentication failed. There is no associated data. Thus AUTHENTICATION_FAILED can always be correlated to the IKE_AUTH. On the other hand, I think it is clear that unless we explictly forbid other payloads you are free to add whatever payloads are normally allowed in INFORMATIONAL exchange anyways (i.e. notice, delete, vendori ID payloads, or even configuration payloads etc). Most likely the other end either processes those or ignores them, and if your error notify is fatal error like INVALID_SYNTAX then it really does not matter as the IKE SA will be deleted anyways. The IKEv2 does not really restrict what you can send in INFORMATIONAL exchange, but there are lots of cases where those simply do not make any sense. -- kivi...@iki.fi
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
