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
