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

[Yoav Nir <ynir at checkpoint.com>]

OK. Let's try this again. Is this acceptable?

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 a response, then the initiator
    SHOULD initiate an INFORMATIONAL exchange with a Notify payload
    describing the problem.  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 should be  
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 exchnage  
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.