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: Yoav Nir <ynir_at_nospam>
Date: Mon Sep 14 2009 - 19:02:06 GMT
To: "ipsec@ietf.org WG" <ipsec@ietf.org>


OK. One more try:

2.21. Error Handling

    There are many kinds of errors that can occur during IKE processing.     If a request is received that is badly formatted, or unacceptable for

    reasons of policy (e.g., no matching cryptographic algorithms), the     response MUST contain a Notify payload indicating the error. If an     error occurs in the processing of an IKE_AUTH response, and leads to     an authentication failure, then the initiator MAY initiate an     INFORMATIONAL exchange with a Notify payload describing the problem.     For other invalid responses, it is not a good idea to initiate an     exchange for carrying a Notify payload, but the node should take care

    to clean up the state (for example, by sending DELETEs for bad SAs).

    If an error occurs outside the context of an IKE request (e.g., the     node is getting ESP messages on a nonexistent SPI), the node SHOULD     initiate an INFORMATIONAL exchange with a Notify payload describing     the problem.

    Errors that occur before a cryptographically protected IKE SA is     established must be handled very carefully. There is a trade-off     between wanting to be helpful in diagnosing a problem and responding     to it and wanting to avoid being a dupe in a denial of service attack

    based on forged messages.

    If a node receives a message on UDP port 500 or 4500 outside the     context of an IKE SA known to it (and not a request to start one), it

    may be the result of a recent crash of the node. If the message is     marked as a response, the node MAY audit the suspicious event but     MUST NOT respond. If the message is marked as a request, the node     MAY audit the suspicious event and MAY send a response. If a     response is sent, the response MUST be sent to the IP address and     port from whence it came with the same IKE SPIs and the Message ID     copied. The response MUST NOT be cryptographically protected and     MUST contain a Notify payload indicating INVALID_IKE_SPI. The     INVALID_IKE_SPI notification indicates an IKE message was received     with an unrecognized destination SPI; this usually indicates that the

    recipient has rebooted and forgotten the existence of an IKE SA.

    A node receiving such an unprotected Notify payload MUST NOT respond     and MUST NOT change the state of any existing SAs. The message might

    be a forgery or might be a response, the genuine correspondent was     tricked into sending. A node should treat such a message (and also a

    network message like ICMP destination unreachable) as a hint that     there might be problems with SAs to that IP address and should     initiate a liveness check for any such IKE SA. An implementation     SHOULD limit the frequency of such tests to avoid being tricked into     participating in a denial of service attack.

    A node receiving a suspicious message from an IP address (and port,     if NAT traversal is used) with which it has an IKE SA SHOULD send an     IKE Notify payload in an IKE INFORMATIONAL exchange over that SA.     The recipient MUST NOT change the state of any SAs as a result, but     may wish to audit the event to aid in diagnosing malfunctions. A     node MUST limit the rate at which it will send messages in response     to unprotected messages.

    All errors that occur in an IKE_AUTH exchange, causing the     authentication to fail for whatever reason (invalid shared secret,     invalid ID, untrusted certificate issuer, revoked or expired     certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED     notification. If the error occurred on the responder, the     notification is returned in the protected response, and is usually     the only payload in that response. If the error occurs on the     initiator, the notification MAY be returned in a separate     INFORMATIONAL exchange, usually with no other payloads. Note,     however, that messages that contain an unsupported critical payload,     or where the whole message is malformed (rather than just bad payload

    contents), MUST be rejected in their entirety, and only lead to an     UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX Notification. The     receiver should not verify the payloads related to authentication in     this case.

    If authentication has succeeded in the IKE_AUTH exchange, the IKE SA     is established, but establishing the child SA, or requesting     configuration information may still fail. This failure does not     automatically cause the IKE SA to be deleted. Specifically, a     responder may include all the payloads associated with authentication

    (IDr, Cert and AUTH) while sending error notifications for the     piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS,     NO_PROPOSAL_CHOSEN, etc.), and the initiator MUST NOT fail the     authentication because of this. The initiator MAY, of course, for     reasons of policy later delete such an IKE SA.

    Only authentication failures and malformed messages lead to a     deletion of the IKE SA without requiring an explicit INFORMATIONAL     exchange carrying a DELETE payload. Other error conditions require     such an exchange, if policy dictates that this is needed.

    In an IKE_SA_INIT exchange, any error notification causes the     exchange to fail, although some, like COOKIE, INVALID_KE_PAYLOAD or     INVALID_MAJOR_VERSION may lead to a subsequent successful exchange.     In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately

    following it, only the following notifications cause the IKE SA to be

    deleted or not created, without a DELETE payload:

    o UNSUPPORTED_CRITICAL_PAYLOAD
    o INVALID_SYNTAX
    o AUTHENTICATION_FAILED

    Extension documents may define new error notifications with these     semantics, but MUST NOT use them unless the peer is known to     understand them.



IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec