Tero, > > 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." > > If that error occurred during IKE_AUTH because of authentication > failure or INVALID_SYNTAX or similar then there is no way to start new > INFORMATIONAL exchange as for the initiators part the IKE SA wasn't > finished, thus he DOES NOT have IKE SA to start INFORMATIONAL on.
We've already bent this rule a little bit if the responder detects an authentication failure. I.e., we've documented that the responder should encrypt&MAC his N(AUTHENTICATION_FAILED) response even though from his perspective he doesn't have a valid IKE SA. It seems reasonable to do something similar in this case. I.e., if the initiator detects an authentication failure (say, the responder's certificate has expired), it is reasonable for him to 1) send a protected INFORMATIONAL request over the unauthenticated SA with the error notify, and 2) disallow any other possible activity on that invalid SA except for retransmitting the request and waiting on the response. In our own case, if this happens as initiator, we will do this, sending a protected INFORMATIONAL request containing both N(AUTHENTICATION_FAILED) and also a DELETE for the IKE SA. In my view the DELETE is actually the more crucial payload here, and the Notify payload is primarily a courtesy to hint to the responder why the delete is being sent (since there is really no way to assert that a Notify in an INFORMATIONAL request relates to some other particular exchange). Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Tero Kivinen <kivi...@iki.fi> To: Yoav Nir <y...@checkpoint.com> Cc: "ipsec@ietf.org WG" <ipsec@ietf.org> Date: 09/07/2009 12:18 PM Subject: Re: [IPsec] Issue #26: Missing treatment of error cases Yoav Nir writes: > > 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." If that error occurred during IKE_AUTH because of authentication failure or INVALID_SYNTAX or similar then there is no way to start new INFORMATIONAL exchange as for the initiators part the IKE SA wasn't finished, thus he DOES NOT have IKE SA to start INFORMATIONAL on. So only place where IKE_AUTH could fail so that you have IKE SA but you would want to send notification back is that there was something wrong with the configuration payload or Child SA processing. If there is something wrong with Child SA processing, then correct way is not to install the SA, and send delete for the Child SA. If there was something wrong with the configuration payload processing, then depending on the situation you might want to delete the IKE SA (if you didn't get the IP-address at all or similar) or just ignore the error. I really DO NOT like the idea of triggering new exchanges based on the failures when parsing the response. In general IKEv2 has been written so there cannot really be errors on the responder (i.e. traffic selectors are narrowed based on the initiators proposal, so responder cannot select something that is not allowed by initiator, and same is for SAs proposals etc). Can you give me example where this would be used? I.e. situation where IKE_AUTH response packet caused error which needs to be communicated to the other end and which is not related to IKE SA authentication. > 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. Our implementation will silently delete IKE SA (i.e do not send DELETE notification as if state is so messed up that you get INVALID_SYNTAX errors, then DELETE notification will mostly generate same response) when it receives INVALID_SYNTAX or after it has sent out INVALID_SYNTAX as it assumes there is something badly wrong with either implementation and there is no point of continuing at that situation. I do not have any plans of changing that, and I think other implementations do something similar (i.e if you start sending them properly encrypted and authenticated random garbage they will tear down the IKE SA). -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
