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 >> 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 > ^^^^^^ > > Typo. > >> 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. > > 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. > -- > kivi...@iki.fi > > Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
