> Message: 2 > Date: Sun, 6 Sep 2009 10:15:17 +0300 > From: Yoav Nir <y...@checkpoint.com> > Subject: Re: [IPsec] Issue #26: Missing treatment of error cases > To: "ipsec@ietf.org WG" <ipsec@ietf.org>, Tero Kivinen > <kivi...@iki.fi> > Message-ID: <e71a2f1d-63ad-4890-9b74-32d2cb5eb...@checkpoint.com> > Content-Type: text/plain; charset="us-ascii" > > 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. I appreciate the softer wording here. However, I find the wording "usually with no other payloads" unduly mysterious. If the concern is that mentioning the DELETE payload may cause implementors to rely on the DELETE payload in this case then words could be added to alleviate that concern.
For example, the words... "usually with no other payloads." ...could be replaced with: "with no other payloads except an optional DELETE payload. As stated, the DELETE payload is optional in this case and should not be relied upon to cause deletion of the IKE SA." > 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 I find the clause, "or in the INFORMATIONAL exchnage immediately following it" to be troublesome. I presume that this text is talking only about the INFORMATIONAL exchange immediately following the IKE_AUTH exchange, if any, started by the original initiator (i.e. an INFORMATIONAL exchange with message ID of 2) but that is not explicitly stated here and may be worth clarifying. I think that having to interpret the notify type differently depending on the INFORMATIONAL message ID is inelegant but given that the silent delete described here may be a common practice it seems that documenting it is goodness. I think that the description of the handling of the notify types here begs the question of how they should be handled in exchanges other than the initial exchanges or the INFORMATIONAL exchange with message ID 2. > > Extension documents may define new error notifications with these > semantics, but MUST NOT use them unless the peer is known to > understand them. Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694)
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
