Hello all.
Issue #26 was submitted by Tero Kivinen. It concerns section 2.21
("error handling") and states that several things are missing:
- handling of errors before authentication
- listing what error conditions cause the IKE SA to be deleted entirely
- listing how errors are handled in the piggybacked exchanges.
Following is our suggested new text. Please let us know what you
think. Also, please take a look at the description of
"AUTHENTICATION_FAILED" in section 3.10.1. "response to an IKE_AUTH
message" means either an IKE_AUTH response to an IKE_AUTH request, or
an INFORMATIONAL request that describes an error in the IKE_AUTH
response. Do you think this phrasing is clear enough?
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 MAY 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,
unrecognized ID, untrusted certificate issuer, revoked or expired
certificate, etc.) MUST result in an AUTHENTICATION_FAILED
notification. If the error occurred on the responder, the
notification MUST be returned in the protected response, and MUST be
the only payload in that response. If the error occurs on the
initiator, the notification MUST be returned in a separate
INFORMATIONAL exchange, with no other payloads. Note, however, that
messages that contain an unsupported critical payload, or that are
otherwise malformed, MUST be rejected in their entirety, and only
lead to an UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX
Notification. The receiver MUST NOT verify the payloads related to
authentication in this case.
If authentication has succeeded in the IKE_AUTH exchange, the IKE SA
is established, provided that there are no unsupported critical
payloads. Establishing the child SA, or requesting configuration
information may still fail, but they do 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 packets lead to a
deletion
of the IKE SA without requiring an explicit DELETE payload. Other
error conditions require such a payload. In an IKE_SA_INIT
exchange,
any error notification causes the exchange to fail. In an IKE_AUTH
exchange, or in the subsequent INFORMATIONAL exchnage, 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
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
