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: Wed Sep 16 2009 - 12:51:25 GMT
To: Yoav Nir <ynir@checkpoint.com>


Yoav Nir writes:
> OK. One more try:

I think this is still bit confusing. How about splitting it to few subsections, i.e. 2.21. Error Handling 2.21.1 Error Handling in IKE_SA_INIT 2.21.2 Error Handling in IKE_AUTH 2.21.3 Error Handling after IKE SA is Authenticated 2.21.4 Error Handling Outside IKE SA

or something.

Now you need to be very careful when reading the text to understand when it is taking about IKE_AUTH or some other exchange and whether it is talking about errors in request and replies.

For example the text could look something like this:



2.21. Error Handling

    There are many kinds of errors that can occur during IKE     processing. The general rule is that if a request is received that     is badly formatted, or unacceptable for reasons of policy (e.g.,     no matching cryptographic algorithms), the response contains a     Notify payload indicating the error. Whether to send such response     depends whether the there is authenticated IKE SA or not.

    If there is an error parsing or processing response packet, then     generic rule is not to send any error back, as responses should     not generate new requests (which would be the only way to send     error message back). Such errors in parsing or processing response     packets should still take care to clean up the state (for example,     by sending DELETEs for bad SAs).

    Only authentication failures (AUTHENTICATION_FAILED) and malformed     messages (INVALID_SYNTAX) 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.

2.21.1 Error Handling in IKE_SA_INIT

    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.

    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. Note, as all error notifications are completely     unauthenticated, the recipient should not immediately act based on     them (unless corrective actions are known like COOKIE,     INVALID_KE_PAYLOAD etc), but continue trying for some time before     giving up.

2.21.2 Error Handling in IKE_AUTH

    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. Note, that although the     IKE_AUTH messages are encrypted and integrity protected, if the     peer receiving this notification has not authenticated the other     end yet, the information needs to be treated with caution.

    If the error occurs on the initiator, the notification MAY be     returned in a separate INFORMATIONAL exchange, usually with no     other payloads. This is exception for the general rule of not     starting new exchanges based on errors in responses.

    Note, however, that request 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 sent as response. 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.

    In an IKE_AUTH exchange, or in the INFORMATIONAL exchange     immediately following it (in case error happened in when     processing response to IKE_AUTH), 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.

2.21.3 Error Handling after IKE SA is Authenticated

    After the IKE SA is authenticated all requests having errors MUST     result in response notifying about the error.

    In normal situation there should not be cases where valid response     from other end results in error situation in the initiator, so     there should not be any reason for initiator to send error     messages to the other end. Because sending such error messages as     INFORMATIONAL exchange might lead to further errors causing loops     such errors SHOULD NOT be sent. If such errors are seen that might     mean that the peers do not have same state, thus it might be good     to delete the IKE SA to clean up state and start over from the     beginning.

    Similarly if the responder parsing the request notices it is badly     formatted (after it has passed the message authentication code     checks and window checks) and it sends INVALID_SYNTAX notification     back, then this error notification is considered fatal in both     ends meaning that IKE SA is deleted without explicit delete     payload.

2.21.4 Error Handling Outside IKE SA

    A node MUST limit the rate at which it will send messages in     response to unprotected 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.

    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.  

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