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. Also I do not know any normal cases where it would be useful to send error message to the response. In some cases it may possible that initiator will process the response packet, and notice there is something wrong and do actions. One of the cases is for example when initiator asked for transport mode, but responder selected tunnel mode and initiator's policy does not allow tunnel mode. In this example the current RFC4306 text already says initiator deletes the SA. Can you give me any example when it would be possible to use this feature? Note, that this is new requirement that was not in the RFC4306. Note, that this also goes against the rule that no response never generates new requests (it is not explictly mentioned in the IKEv2, but is still there). This means that if either end has bug that cases for example the response packet of the INFORMATIONAL exchange causes other end to send error notification to the other end (using same broken INFORMATIONAL exchange) then the peers will go to INFORMATIONAL exchange loop. Because of the looping problem, and the problem there is no way to relate new INFORMATIONAL exchange request to the response which triggered it, I would actually suggest we forbid this situation and say that errors in response must be handled otherwise (most likely by deleting the IPsec SA or IKE SA or simply ignoring the error case (if it does not affect the state of the SAs)). > 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. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
