Re: [IPsec] Issue #26: Missing treatment of error cases
Yoav, You are sending an informational notification, so how could you say the SA does not exist and no delete should be sent? If an authentication error is discovered when processing the IKE_AUTH response then responder thinks an IKE SA exists and the initiator intends to delete that SA. In this case it seems clean for the initiator to send an INFORMATIONAL exchange containing AUTHENTICATION_FAILED and treating the SA as being deleted. I do not see the harm in including a DELETE in this case and it seems to be a more appropriate action than sending the AUTHENTICATION_FAILED. I'm fine with not requiring the DELETE, but I don't think including the DELETE is bad and should be discouraged. I think it reinforces the initiator's intentions and is unambiguous. Dave Wierbowski From: Yoav Nir To: David Wierbowski/Endicott/i...@ibmus Cc: "ipsec@ietf.org" , Keith Welter/Raleigh/i...@ibmus Date: 09/04/2009 03:25 PM Subject:Re: [IPsec] Issue #26: Missing treatment of error cases Sent by:ipsec-boun...@ietf.org On Sep 4, 2009, at 5:53 PM, David Wierbowski wrote: >Yes, I will soften the language a bit, but I won't mention a DELETE payload. If some implementations do it. >others may come to expect it. We don't want to encourage that by suggesting that it's a good idea. Yoav, Why is it a a bad idea to include a DELETE payload in this case? Because the IKE SA was not really created, so there is no IKE SA to delete. It's a bad idea because it is superfluous, and we don't want to risk anyone relying on this.___ 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
Re: [IPsec] Issue #26: Missing treatment of error cases
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 To: Yoav Nir Cc: "ipsec@ietf.org WG" 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 i
Re: [IPsec] Issue #26: Missing treatment of error cases
David Wierbowski writes: > You are sending an informational notification, so how could you say the SA > does not exist and no delete should be sent? The IKE SA is NOT up and valid in the initiator. It is halfway up as the other end has not been authenticated, and that IKE SA cannot be used in general. > If an authentication error is discovered when processing the IKE_AUTH > response then responder thinks an IKE SA exists and the initiator intends > to delete that SA. In this case it seems clean for the initiator to send > an INFORMATIONAL exchange containing AUTHENTICATION_FAILED and treating the > SA as being deleted. I do not see the harm in including a DELETE in this > case and it seems to be a more appropriate action than sending the > AUTHENTICATION_FAILED. > > I'm fine with not requiring the DELETE, but I don't think including the > DELETE is bad and should be discouraged. I think it reinforces the > initiator's intentions and is unambiguous. If you use that kind of halfway up IKE SA for sending INFORMATIONAL message to other end (who thinks the IKE SA is up and valid), then I agree that sending both N(AUTHENTICATION_FAILED) and DELETE would be the correct way to do it. DELETE only would also be ok. Sending only N(AUTHENTICATION_FAILED) would be bit ambiquous, and I would not recommend that, but as initiator still do not have IKE SA up but has only halfway up SA, for initiator it does not matter what other end does for the INFORMATIONAL exchange anyways... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
Scott C Moonen writes: > 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. True, but that does not mean the IKE SA is valid, it just means they do have shared unauthenticated keys for encryption and MAC. I.e that encrypt & MAC proves that the reply comes back from the same server who did Diffie-Hellman, but it does not mean it came back from the correct intended responder. The reply could be generated also by man in the middle. > 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. That adds quite of lot of special code (i.e you need to make sure that IKE SA is not used for anything else while you are waiting for reply), and does not really help that much. This will cause server to clean up the IKE SA faster than it normally would, but as client initiated this there is most likely no data coming from the server to client anyways thus no traffic is really lost. The client will still fail the IKE SA and as client was the one who initiated it, it will most likely try again and the user noticing things does not work tries to fix things. This kind of authentication failures usually do not go away without user intervention anyways. >From the responders point of view the IKE SA is there, so he does not care which way the initiator does, so this is not something that needs to be defined at all (i.e. there is no need to define whether it is allowed, recommended or forbidden). Whether implementation does this can be completely left to as local matter. > 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). You are free to do that. It will gain you so that server will delete the IKE SA bit earlier than it would otherwise (i.e. otherwise it would need to wait for the DPD to kick in (which would most likely happen quite soon, as there is completely idle IKE and IPsec SA there) and that would then delete the IKE SA). For the original users point of view (i.e. the initiator / client) this does not matter, as he still cannot get connection... I myself as implementor writing code do not want to add such code to our product as it is just adding code that is very seldomly run and even less seldomly tested, and which can contain security bugs, thus the product is safer and better without such code. But this is just my own opinion, and other implementors might have different opinions, and I am ok with text which says you MAY do it. I would object against SHOULD, and object very strongly against MUST. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPsec Digest, Vol 65, Issue 14
> Message: 2 > Date: Sun, 6 Sep 2009 10:15:17 +0300 > From: Yoav Nir > Subject: Re: [IPsec] Issue #26: Missing treatment of error cases > To: "ipsec@ietf.org WG" , Tero Kivinen > > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > 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. 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 SHOULD 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, > 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. If the error occurs on the > initiator, > the notification MAY be returned in a separate INFORMATIONAL > exchange, usually with no other payloads. I appreciate the softer wording here. However, I find the wording "usually with no other payloads" unduly mysterious. If the concern is that mentioning the DELETE payload may cause implementors to rely on the DELETE payload in this case then words could be added to alleviate that concern. For example, the words... "usually with no other payloads." ...could be replaced with: "with no other payloads except an optional DELETE payload. As stated, the DELETE payload is optional in this case and should not be relied upon to cause deletion of the IKE 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 authentica
