ipsec September 2009 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: Re: [IPsec] Issue #26: Missing treatment of error cases

Re: [IPsec] Issue #26: Missing treatment of error cases

From: Tero Kivinen <kivinen_at_nospam>
Date: Tue Sep 22 2009 - 09:00:37 GMT
To: Scott C Moonen <smoonen@us.ibm.com>

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. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec