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 07 2009 - 13:55:48 GMT
To: Tero Kivinen <kivinen@iki.fi>

On Sep 7, 2009, at 4:41 PM, Tero Kivinen wrote:

> Yoav Nir writes:
>> 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.
> I think MAY is better than SHOULD there, or even forbidding this
> completely.
> As said before I do not know any implementation which does this now,
> and there is also problem that there is no way to correlate the
> INFORMATIONAL exchange to the exchange which caused this problem. I.e.
> if you have window size 5, and you have 3 CREATE_CHILD_SA exchanges
> going, and then you get response to second of them that is invalid and
> you send INFORMATIONAL exchange out saying there was something wrong
> with the response, then there is no way for the other end to know to
> which of those exchanges that INFORMATIONAL related.

Agreed. How about SHOULD, but adding "if the error occurred in the response to an IKE_AUTH exchange, and in payloads related to authentication. A new exchange SHOULD NOT be triggered for reporting errors in child SAs, CFG, or notifications."

>> 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.
> When we discussed about the ticket #9 Pasi proposed a text that
> explains this case better, i.e. specifying that the "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."
> http://www.ietf.org/mail-archive/web/ipsec/current/msg04096.html
> This was supposed to be added to section 1.2, but it is not there.
> Perhaps we should add it here instead of 1.2 then (or at least add it
> to 1.2 if not here).
>> If the error occurs on the
>> initiator,
>> the notification MAY be returned in a separate INFORMATIONAL
>> exchange, usually with no other payloads.
> Here creating new INFORMATIONAL exchanges based on the errors in
> response may be allowed as there is no problems with correlating the
> message (no other exchanges is allowed before IKE_AUTH finishes), and
> there should not problems with loops, as the error notification was
> related to the IKE_AUTH not generic stuff.
> Also if there was problem when processing IKE_AUTH response, I would
> indicate that then the IKE_AUTH didn't finishs, thus we do not have
> IKE SA. If the problem was only in the Chid / IPsec SA part of the
> exchange then that can be fixed by deleting the IPsec 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
>> receiver should not verify the payloads related to
>> authentication in
>> this case.
>> If authentication has succeeded in the IKE_AUTH exchange, the
>> 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
> ^^^^^^
> Typo.
>> immediately
>> following it, only the following notifications cause the IKE SA to
>> be
>> deleted or not created, without a DELETE payload:
>> Extension documents may define new error notifications with these
>> semantics, but MUST NOT use them unless the peer is known to
>> understand them.
> This still leaves it bit open what happens if "malformed messages" are
> received later for example in CREATE_CHILD_SA exchange, and responder
> of the exchange detects that payload is malformed and returns
> INVALID_SYNTAX error notification. The last part says that in IKE_AUTH
> it will cause sa not to be created, but it does not talk about future
> exchanges. On the other hand earlier it says "Only ... malformed
> messages lead to a deletion of the IKE SA withotu requiring an
> explicit INFORMATIONAL exchange carrying a DELETE payload".
> For me that would also indicate that if I get INVALID_SYNTAX (which is
> returned if you send malformed messages) then you can silently delete
> the IKE SA.
> Perhaps we should add new paragraph about that too.

I think that any of these would be fatal to the particular exchange, but will not cause a silent discard of the IKE SA. You might have a policy that tells you to delete any IKE SA where you got or sent an INVALID_SYNTAX, but because it can also be a policy matter, we shouldn't really mandate it.
> --
> kivinen@iki.fi
> Scanned by Check Point Total Security Gateway.

IPsec mailing list