Paul Hoffman writes:
> <section anchor='sect-2.21' title='Error Handling'>
>
> <t>If there is an error parsing or processing a response packet, the
> general rule is to not send bac any error message because responses
^^^
s/bac/back/
> should not generate new requests (and a new request would be the only
> way to send back an error message). Such errors in parsing or
> processing response packets should still cause the recipient to clean
> up the IKE state (for example, by sending a DELETE for a bad SA).</t>
> <t>In an IKE_SA_INIT exchange, any error notification causes the
> exchange to fail. Note that some error notifications such as COOKIE,
> INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent
> successful exchange. Because all error notifications are completely
> unauthenticated, the recipient should continue trying for some time
> before giving up but not immediately act based on the error
> notification unless corrective actions are defined in this
> specification, such as for COOKIE, INVALID_KE_PAYLOAD, and
> INVALID_MAJOR_VERSION.</t>
I think the last sentence is bit hard to parse.
> <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>
As I do not see any other reason to start new informational exchange
when processing IKE_AUTH reply than fatal errors when creating it
(i.e. AUTHENTICATION_FAILED) which already deletes the IKE SA, I do
not see any benefit from adding DELETE notification to the message. It
would be saying the same thing twice: "There was fatal error delete
the sa, and by the way delete the sa."
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
