Re: [IPsec] Issue #98: 1 or two round trips for resumption
Narayanan, Vidya writes: The requirement is quite simple and you just seem to ignore it or provide unacceptable alternatives. The handoff latency must be good What handoff? We are talking about resumption, not handoff. I do not consider those same. Or then I understand completely wrong what handoff is, and what resumption is. For me handoff is when you have active connection to one place, and then you want to move that connection to another place without interrupting the communications. Resumption is when we have connection that was disconnected temporarely because of some reason, and we want to resume it after some period of time. Their requirements are very different and if we are really making standard for handoff, then our protocol would be different. enough to support VoIP like applications and the handoff may imply needing an IPsec session between the mobile and a network entity (be it a VPN or for MIP6 channel security). You claim that in such scenarios, IPsec should be used all the time, even on the interfaces that don't require it for security purposes - so, even if the device is not running MIP6 until it moves to the new interface, it now needs to establish an IPsec session. I am not claiming it should be used all the time, but I am claiming that if you are planning to start to use IPsec again you should not first tear down your non-IPsec connection while you set up the IPsec connection. You should keep the old connection alive and then when you have IPsec connection ready, then you move your traffic to that connection requiring IPsec. I do not really belive you get very good handoff with break before make methods on any networks. However, this is not acceptable for various reasons (including that operators are not interested in maintaining IPsec sessions for all devices just in case it roams at some point). They do not need to maintaing IPsec session for all devices for all time, they need to resume them about 10-100ms before they are actually required, i.e. before they break their old connection. One dropped packet on the IPsec resume is going to cause several times longer delay than one round trip. It is bed idea to design system so it does not tolerate even single lost packet. Also, designing for a fixed set of interfaces is a problem - it may not always be 3G and WiFi - it could be 3G and WiMAX; it could be 3G infrastructure and 3G Femto; it could be 3G infrastructure and 3G multi-hop, etc. In many of these cases, handoffs don't happen using a single radio operating in multi-mode. Then when you decide you are going to roam to network that requires IPsec, you can resume the IPsec connection using the old connection (even when it is unneeded there), and then you have IPsec connection which you can move to new network with single round trip protocol. With WiFi the network setup time is usually much longer than one round trip. In devices I normally use (laptop, pda etc) the device requires about 3-10 seconds to get network up and working (turning radio on, finding basestation, connecting to basestation, getting IP-address via DHCP etc). I have not ever seen wlan that would work so fast that it would be enough for VoIP handoffs. I do not know about WiMAX, but at least my 3G cellular phone usually takes about 1-2 seconds to create data connection (i.e. when I select which internet connection to use to the time when it actually starts loading the page) and it seemed to take about one more second before the packet it sent out actually reaching my server. Adding 20-40 ms for one more round trip time to that does not really affect the big picture. On the other hand if you can do network setup while still keeping old connection alive, then you can also do the resumption and the one round trip during that time too. Can you explain me on what kind of devices you can really do handoff to new network with break and make method? So what is the exact problem there? The fundamental issue is that MIP6, using the K bit, allows the IP address on the IKE SA to change, thereby accomplishing the MOBIKE functionality and also conflicting with it if it ran together. When using MOBIKE you should not use the K-bit (if that is what I think it is), but you should just leave the IP-address handling of the IKE and IPsec to MOBIKE. The MOBIKE was meant to be used as building tool for MIP6, i.e. it still requires MIP6 to start using it, i.e. there should have been separate document specifying how to use MOBIKE and MIP6 together. It never assumed it would solve the MIP6 problem directly, it assumed that MIP6 and MOBIKE could together be used to solve the problem. Please read the thread on MOBIKE and MIP6 on the MIP6 mailing list from back in 2006 if you are interested in more details. I have not really been interested in MIP6, after I showed them how MIP6 and IPsec can easily used together without any modifications to either MIP6 or IPsec, but they said that solution was
Re: [IPsec] Issue #98: 1 or two round trips for resumption
It is impossible for IETF to think about those other standard bodies, as we do not know what they plan to do. I have several times tried to get people to explain me the use case for which this protocol has been aimed for, so I could think whether some specific attack or optimization is suitable or not, but as only reply I have received is, that it is outside the scope of this discussion, then there is really no point of blaming people for making decisions for other standard bodies. What else can we do? Nobody has still explained me why the 1 RT protocol is required for those other standard bodies, and why should the security of this protocol be weaker because of the requirements from those other unknown standard bodies. The requirement is quite simple and you just seem to ignore it or provide unacceptable alternatives. The handoff latency must be good enough to support VoIP like applications and the handoff may imply needing an IPsec session between the mobile and a network entity (be it a VPN or for MIP6 channel security). You claim that in such scenarios, IPsec should be used all the time, even on the interfaces that don't require it for security purposes - so, even if the device is not running MIP6 until it moves to the new interface, it now needs to establish an IPsec session. However, this is not acceptable for various reasons (including that operators are not interested in maintaining IPsec sessions for all devices just in case it roams at some point). Also, designing for a fixed set of interfaces is a problem - it may not always be 3G and WiFi - it could be 3G and WiMAX; it could be 3G infrastructure and 3G Femto; it could be 3G infrastructure and 3G multi-hop, etc. In many of th ese cases, handoffs don't happen using a single radio operating in multi-mode. Also, mobility may need to be handled by MIP6 and we know that it doesn't co-exist with MOBIKE. That is news for me. One of the reasons MOBIKE was created was to allow it to be used as building block for Mobile IP. So why does not MIP6 and MOBIKE co-exits? We at least tried to make MOBIKE so it could be used by Mobile IP, and there were Mobile IP people taking part in the specification process back then. So what is the exact problem there? The fundamental issue is that MIP6, using the K bit, allows the IP address on the IKE SA to change, thereby accomplishing the MOBIKE functionality and also conflicting with it if it ran together. Please read the thread on MOBIKE and MIP6 on the MIP6 mailing list from back in 2006 if you are interested in more details. The conclusion was that a scenario of using MOBIKE and MIP6 between the same two endpoints must be avoided. Also note that as I mentioned above, there are scenarios where MIP6 doesn't kick off until a handoff occurs. I am thinking it might not be worth of standardizing the resumption at all, if we for that again hear 3 years after we finished the work that it cannot be used because of some unspecified reason. Well, the current approach for designing it for known air interfaces that some of us may be familiar with and some models where multiple interfaces need to simultaneously be active is certainly not going to help it. We might as well say that this is not meant for addressing the mobility use cases. snip Most of the DoS attackers are not wanting to get something meaningful in return. I still think we need to design protocols so they are secure against such attacks. I'm really surprised by this. A good threat analysis should determine the likelihood and impact of an attack and likelihood largely depends on the attacker's incentive. If the incentive doesn't exist or is not meaningful, the likelihood is generally low, causing the attack to be of low importance. NIST's Risk Management Guide goes through a good description of how to do a threat analysis and is useful. Simply protecting against attacks that we can all dream up, regardless of the threat model or motivations is not useful. Vidya ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #98: 1 or two round trips for resumption
Narayanan, Vidya writes: Somehow, we in the IETF think that we can make decisions for other standards bodies, especially ones that do real deployments. I don't know how we can say things like they should always use the IKE SA whether they need it or not - there can be several reasons not to use it when they don't need it, including how some VPN vendors may charge. It is impossible for IETF to think about those other standard bodies, as we do not know what they plan to do. I have several times tried to get people to explain me the use case for which this protocol has been aimed for, so I could think whether some specific attack or optimization is suitable or not, but as only reply I have received is, that it is outside the scope of this discussion, then there is really no point of blaming people for making decisions for other standard bodies. What else can we do? Nobody has still explained me why the 1 RT protocol is required for those other standard bodies, and why should the security of this protocol be weaker because of the requirements from those other unknown standard bodies. Also, mobility may need to be handled by MIP6 and we know that it doesn't co-exist with MOBIKE. That is news for me. One of the reasons MOBIKE was created was to allow it to be used as building block for Mobile IP. So why does not MIP6 and MOBIKE co-exits? We at least tried to make MOBIKE so it could be used by Mobile IP, and there were Mobile IP people taking part in the specification process back then. So what is the exact problem there? I am thinking it might not be worth of standardizing the resumption at all, if we for that again hear 3 years after we finished the work that it cannot be used because of some unspecified reason. I'm also further intrigued by this attack we are so passionately discussing - the motivation for the attacker here is to annoy other users? Almost all DoS attacks are only there to annoy the users. If someone uses DoS attack to bring some web server or dns-name server or similar down for few hours, that is just annoying users. Everything will work again when the attacks stops, and might even work during the attack but access might be much slower than normally. Surely, the attacker gets nothing meaningful in return - I simply can't see how the risk of such an attack can be anywhere close to even medium - it is barely low in my view. Most of the DoS attackers are not wanting to get something meaningful in return. I still think we need to design protocols so they are secure against such attacks. And it is not only against protecting against the attacks, this is also against normal working of the protocol. I.e. if sending one packet whose response packets gets lost, can destroy state from the server, in such way that client cannot detect that, and needs to start IKE SA creation from the beginning, I consider even that a big problem. When we were specifying the MOBIKE we made sure it works also in cases where some of the network connections are one-way, i.e. no return packets get back. It consideres such links broken, and does not use them. This was considered important to get it right, because in that environment it was seen that quite often the links it might see might have such unidirectional properties, and the whole protocol cannot be broken because of one such link. With resumption the whole protocol breaks down if such unidirectional link is ever tried to be used. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #98: 1 or two round trips for resumption
Lakshminath Dondeti writes: You should not really do break-before-make style of transitions on real-time environments, and if you keep the old connection while making the new one, then this whole issue is non-issue. Good advice, but that consensus process is from elsewhere. Not every device has multiple interfaces, not every architecture implements the idea of multiple simultaneous associations with base stations, and so on. We were discussing moving traffic from secure cellular network (which do not require IPsec protection, and IKE SA was suspended because of that) to unsecure WLAN network (which now requires IPsec protection because it is unsecure). Do you really say some device which can talk to both WLAN and cellular network cannot talk to both of them simultaneously? Even with if they cannot be used simultaneously they can still bring the IKE SA up while using the cellular network, and then use MOBIKE to move the already up and resumed IKE SA from cellular to WLAN. It seems there is again some scenarios you are refering to that I do not know about, as I do not really think you are now talking about the same use case anymore. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #98: 1 or two round trips for resumption
Somehow, we in the IETF think that we can make decisions for other standards bodies, especially ones that do real deployments. I don't know how we can say things like they should always use the IKE SA whether they need it or not - there can be several reasons not to use it when they don't need it, including how some VPN vendors may charge. Also, mobility may need to be handled by MIP6 and we know that it doesn't co-exist with MOBIKE. I'm also further intrigued by this attack we are so passionately discussing - the motivation for the attacker here is to annoy other users? Surely, the attacker gets nothing meaningful in return - I simply can't see how the risk of such an attack can be anywhere close to even medium - it is barely low in my view. The reward for the attacker in return for the work is non-existent - if someone can steal spectrum or otherwise get Internet access for free or get access to other users' credentials, etc., it is worth discussing and protecting against. In this case, I'd say that we've already spent more time discussing it than it is worth it. Vidya -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Tero Kivinen Sent: Thursday, April 23, 2009 6:50 AM To: Dondeti, Lakshminath Cc: IPsecme WG; Paul Hoffman Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption Lakshminath Dondeti writes: MOBIKE assumes that the other side has state, correct? Yes. Session resumption has to do with providing that state. How are they the same? In this example given (handover from cellular to wlan, without breaking existing phone call), I do not really see any point why the IKE SA state needs to be removed from the server side, and as such I think the much better solution is to use MOBIKE and keep IKE SA up all the time. As I do not have any idea where people want to use the resumption, I have VERY HARD time to justify the different protocol options. But anyways one of the things required is that it shall not have negative impact on IKEv2 security features, and I think 1 RT protocol will have negative impact to security features. Under attack, the protocol stretches to 3 RTs. 3 RT + Diffie-Hellman + public key operation + user interaction to type in password or securid token etc. So, you are saying that there is no noticeable difference between 1 and 2 RTs, but there is between 2 and 3? Is your point that the DH computation will be noticed? With group 18: yes... With typing in the passphase to do reauthentication with RSA token card : yes. With digging out your securid card and typing in pin, and typing in the next token to the prompt: yes. My point is that we'd beyond the real-time budgets after 1 RT anyway. You should not really do break-before-make style of transitions on real-time environments, and if you keep the old connection while making the new one, then this whole issue is non-issue. -- 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
Re: [IPsec] Issue #98: 1 or two round trips for resumption
On 4/23/2009 7:19 PM, Tero Kivinen wrote: Lakshminath Dondeti writes: MOBIKE assumes that the other side has state, correct? Yes. Session resumption has to do with providing that state. How are they the same? In this example given (handover from cellular to wlan, without breaking existing phone call), I do not really see any point why the IKE SA state needs to be removed from the server side, and as such I think the much better solution is to use MOBIKE and keep IKE SA up all the time. As I do not have any idea where people want to use the resumption, I have VERY HARD time to justify the different protocol options. But anyways one of the things required is that it shall not have negative impact on IKEv2 security features, and I think 1 RT protocol will have negative impact to security features. I fail to understand the security issue though in that the attack has already been identified as mere annoyance and does not result in any compromise. Under attack, the protocol stretches to 3 RTs. 3 RT + Diffie-Hellman + public key operation + user interaction to type in password or securid token etc. Depends. Some VPN clients do better than others and some require little to no user interaction. So, you are saying that there is no noticeable difference between 1 and 2 RTs, but there is between 2 and 3? Is your point that the DH computation will be noticed? With group 18: yes... With typing in the passphase to do reauthentication with RSA token card : yes. With digging out your securid card and typing in pin, and typing in the next token to the prompt: yes. Same as above. But the real point here is that under the attack scenario, the user has bad experience. As long as the attack is categorized as low risk, we don't have to worry about this, do we? My point is that we'd beyond the real-time budgets after 1 RT anyway. You should not really do break-before-make style of transitions on real-time environments, and if you keep the old connection while making the new one, then this whole issue is non-issue. Good advice, but that consensus process is from elsewhere. Not every device has multiple interfaces, not every architecture implements the idea of multiple simultaneous associations with base stations, and so on. If our goal is to design for multiple different scenarios and if the attack is really not serious, I really don't see why we would rule out 1 RT exchange. regards, Lakshminath ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #98: 1 or two round trips for resumption
On 4/22/2009 4:11 PM, Tero Kivinen wrote: Lakshminath Dondeti writes: I still do not think making the 1 RT protocol to 2 RT protocol in that case would really cause any noticeable effect to the actual handover. How do you know this? Because 10ms-100ms is MUCH less than 10 seconds or so I usually see as DHCP delays on WLAN networks. And there is already way to do that in 1 RT protocol, i.e. MOBIKE. With MOBIKE you can recover the changing of the network or IP-address in 1 RT. The 10seconds are not a barometer. So, 1 RT will be closer to the 10ms than the 2 RT, which is better, so I am not sure how you figure it is not noticeable. If someone is in a call, the 2 RT adds to the latency. Resumption should not really be used for that. Resumption means that something caused the IKEv2 SA in the client to removed, without telling that to the server, and thats why client decided to use resumption instead of just continuing using the IKEv2 SA it has up and running. If we take the network outage example from the charter, the duration of network outage is usually MUCH, MUCH longer than the 2 RTs required to reconnect to the server. I ask because, I would like to use those arguments to tell people who are experts in handovers that multiple RTs don't matter. Tell them to use correct protocol on correct places. If they want subsecond recovery from the handover from one network to another, they should use MOBIKE, and keep the IKEv2 SA up all the time (Altough even with MOBIKE it usually takes several seconds for the nodes to actually react that they have lost connectivity, and needs to start corrective actions, but if we assume subsecond recovery is required, then we can also assume the network can immediately tell when recovery actions are required). When did MOBIKE come into picture? What are you saying Tero, that IPsec session resumption is an alternative to MOBIKE and a slow one at that? Even if this happens, the payoff for the attacker is very little since the legitimate parties can always establish another connection. No, he does not, as if he was trying to do handover from cellular to WLAN, he would simply continue using cellular in that point, but the accounting for example would be enabled for both (i.e. for servers point of view he is using WLAN and cellular simulatenously, from clients point of view he using only cellular). Again then when he finally gets WLAN which works, he suddenly have 3 RT protocol to use (trying resumption, failing that, and falling back to full IKE) with user authentication, and possibly even user interaction. The quality of experience would be bad because another session needs to be established when under attack, but at the cost the attacker has to pay, one might even say that this is not even a serious threat. Making the user to do user interaction by simply sniffing one packet from the air, and forwarding it to the right server is very cheap way to annoy people... Annoy being the keyword. I am now more convinced that we are really making the protocol inefficient because some kid might try to annoy some people some time. To counter such potential annoyances which may not happen at any frequency that matters, we are going to sacrifice the user experience all the time? I fail to understand this line of reasoning. What am I missing? thanks, Lakshminath For users point of view it does not even look he is under attack, he just sees that this crappy network again requires him to reauthenticate at random times. Note, that he does not blame the attacker's network, as he didn't detect anything there. The attack can have happened hours before, and then when he finally comes to the home WLAN network, or some other network which actually works, he sees that he needs to reauthenticate. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #98: 1 or two round trips for resumption
Lakshminath Dondeti writes: When did MOBIKE come into picture? What are you saying Tero, that IPsec session resumption is an alternative to MOBIKE and a slow one at that? Yes. Both solve the same problem that IKE SA recovers from the IP-address change, or switching from one network to another (i.e. from cellular to WLAN). I do not really see any fundamental reason why the IKE SA needs to be taken down when in cellular. I can see reasons why it might not be needed, but the IKE SA could still be kept up and running, and if done that way, then MOBIKE will offer solution how to move the IKE SA to the new network, and it will mostly do it in 1 RT. Annoy being the keyword. I am now more convinced that we are really making the protocol inefficient because some kid might try to annoy some people some time. To counter such potential annoyances which may not happen at any frequency that matters, we are going to sacrifice the user experience all the time? I am saying we are not sacrificing the user experience in any noticeable way even if we do 2 RT protocol. I expect that 99.999% users will never notice whether the 1 RT or 2 RT protocol was used if there is no attack. On the other hand, 100% users will notice the attacks if 1 RT protocol is used, and 0% of users will notice the attacks if 2 RT protocol is used. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #98: 1 or two round trips for resumption
On 4/23/2009 3:57 PM, Tero Kivinen wrote: Lakshminath Dondeti writes: When did MOBIKE come into picture? What are you saying Tero, that IPsec session resumption is an alternative to MOBIKE and a slow one at that? Yes. Both solve the same problem that IKE SA recovers from the IP-address change, or switching from one network to another (i.e. from cellular to WLAN). I do not really see any fundamental reason why the IKE SA needs to be taken down when in cellular. I can see reasons why it might not be needed, but the IKE SA could still be kept up and running, and if done that way, then MOBIKE will offer solution how to move the IKE SA to the new network, and it will mostly do it in 1 RT. MOBIKE assumes that the other side has state, correct? Session resumption has to do with providing that state. How are they the same? Annoy being the keyword. I am now more convinced that we are really making the protocol inefficient because some kid might try to annoy some people some time. To counter such potential annoyances which may not happen at any frequency that matters, we are going to sacrifice the user experience all the time? I am saying we are not sacrificing the user experience in any noticeable way even if we do 2 RT protocol. I expect that 99.999% users will never notice whether the 1 RT or 2 RT protocol was used if there is no attack. On the other hand, 100% users will notice the attacks if 1 RT protocol is used, and 0% of users will notice the attacks if 2 RT protocol is used. Under attack, the protocol stretches to 3 RTs. So, you are saying that there is no noticeable difference between 1 and 2 RTs, but there is between 2 and 3? Is your point that the DH computation will be noticed? My point is that we'd beyond the real-time budgets after 1 RT anyway. Now of course, to prove any of this (as opposed to your word against mine), we have to workout test scenarios and the like and measure user perception (we can throw in 5 9's all we want, but people spend millions on real perception testing). All I am asking for is for the group to realize that there are cases where the budgets are low and therefore allow the 1 RT exchange. regards, Lakshminath ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #98: 1 or two round trips for resumption
On 4/21/2009 5:23 PM, Tero Kivinen wrote: I still do not think making the 1 RT protocol to 2 RT protocol in that case would really cause any noticeable effect to the actual handover. Hi Tero, How do you know this? I ask because, I would like to use those arguments to tell people who are experts in handovers that multiple RTs don't matter. Especially as you still most likely have the cellular network there to be used, while you are doing DHCP + IKE_SESSION_RESUME etc on the WLAN, thus only thing that is affected is that traffic moves 100ms later from cellular to WLAN. On the other hand security problems are big issue, as you most likely How do we know that they are a big issue? Do we expect these systems to be under attack most of their operational life? try to IKE_SESSION_RESUME exchange over any WLAN you happen to see, thus you effectively broadcast your tickets to attackers at will, so attackers can simply take those tickets and sent them to server and get your session resumed, but not forward any other traffic. Also any firewall allowing port 500 packets out but not in, will cause similar effect, as you will not get reply back, but server will consume your ticket. Even if this happens, the payoff for the attacker is very little since the legitimate parties can always establish another connection. The quality of experience would be bad because another session needs to be established when under attack, but at the cost the attacker has to pay, one might even say that this is not even a serious threat. I really would liked to be convinced that I am wrong here, but I see this to be a quite moderate or low risk attack. thanks, Lakshminath That case also brings out completely new issue which has not been discussed before, i.e. whether the IKE_SESSION_RESUME must come from the same IP-address than what was used before for the IKE SA, i.e. can the IP-addresses change during the IKE_SESSION_RESUME. If that is allowed, then what about NATs, i.e. is it allowed that even when there was no NAT between hosts before, there is new NAT found during the IKE_SESSION_RESUME? Those are not covered by the current document, and at least something MUST be said about those issues. After this example use scenario, I am even more convinced that 2 RT protocol is better and needed, especially if we do allow IP-addresses change, and might need to do NAT-T detection on the IKE_SESSION_RESUME exchange too. Allowing IP-addresses change means that the network where the packets can come in, are different, meaning they might have misconfigured firewalls or similars there, and killing your resumption ticket by just trying to connect through broken firewall is bad idea. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #98: 1 or two round trips for resumption
Lakshminath Dondeti writes: I still do not think making the 1 RT protocol to 2 RT protocol in that case would really cause any noticeable effect to the actual handover. How do you know this? Because 10ms-100ms is MUCH less than 10 seconds or so I usually see as DHCP delays on WLAN networks. And there is already way to do that in 1 RT protocol, i.e. MOBIKE. With MOBIKE you can recover the changing of the network or IP-address in 1 RT. Resumption should not really be used for that. Resumption means that something caused the IKEv2 SA in the client to removed, without telling that to the server, and thats why client decided to use resumption instead of just continuing using the IKEv2 SA it has up and running. If we take the network outage example from the charter, the duration of network outage is usually MUCH, MUCH longer than the 2 RTs required to reconnect to the server. I ask because, I would like to use those arguments to tell people who are experts in handovers that multiple RTs don't matter. Tell them to use correct protocol on correct places. If they want subsecond recovery from the handover from one network to another, they should use MOBIKE, and keep the IKEv2 SA up all the time (Altough even with MOBIKE it usually takes several seconds for the nodes to actually react that they have lost connectivity, and needs to start corrective actions, but if we assume subsecond recovery is required, then we can also assume the network can immediately tell when recovery actions are required). Even if this happens, the payoff for the attacker is very little since the legitimate parties can always establish another connection. No, he does not, as if he was trying to do handover from cellular to WLAN, he would simply continue using cellular in that point, but the accounting for example would be enabled for both (i.e. for servers point of view he is using WLAN and cellular simulatenously, from clients point of view he using only cellular). Again then when he finally gets WLAN which works, he suddenly have 3 RT protocol to use (trying resumption, failing that, and falling back to full IKE) with user authentication, and possibly even user interaction. The quality of experience would be bad because another session needs to be established when under attack, but at the cost the attacker has to pay, one might even say that this is not even a serious threat. Making the user to do user interaction by simply sniffing one packet from the air, and forwarding it to the right server is very cheap way to annoy people... For users point of view it does not even look he is under attack, he just sees that this crappy network again requires him to reauthenticate at random times. Note, that he does not blame the attacker's network, as he didn't detect anything there. The attack can have happened hours before, and then when he finally comes to the home WLAN network, or some other network which actually works, he sees that he needs to reauthenticate. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #98: 1 or two round trips for resumption
Narayanan, Vidya writes: Hi Yaron, We are going back to revisiting consensus here and re-explaining the use cases and I'd certainly like to keep this to as minimum a revisit as possible. The use cases go back to what has been documented in the problem statement we published a while back - draft-vidya-ipsec-failover-ps-02 - it is now expired, but, you should be still able to get to the draft. From the ipsecme charter: Failover from one gateway to another, mechanisms for detecting when a session should be resumed, and specifying communication mechanisms between gateways are beyond the scope of this work item. Thus failover from one gateway to another is outside the scope of this document. If I remember right most of the use cases in draft-vidya-ipsec-failover-ps-02.txt was specifically failover, not resumption use cases. As a key point, I'll note that the situation where resumption is used here is a handoff case for a particular client and does not involve all clients connecting at once, where DH could be a problem. And, in these cases, there is no user interaction involved - the mobile devices are doing everything they can to make handoffs seamless and work with no user or even application involvement. If you are only worried about the case of simultaneous reconnection of thousands of nodes, you can feel free to always use the 2-RT method in your gateway implementation - I am pointing out that it is not the universally applicable use case. From the abstract of the resumption document: To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as a VPN gateway) needs to re-establish a large number of SAs with various end points. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment. So at least it was seen as important use case, and is thats why included in the abstract (and the ipsecme charter text). And, in most cellular deployments, IPsec is used for untrusted access networks (e.g., WLAN), while the DHCP servers and AAA servers are accessible from other access networks as well. And, a handoff from cellular to WLAN needs to be seamless - you can envision an IPsec SA being set up all the time, but only resumed and actively used after you handoff to WLAN. Hmm.. This is again something completely different what I tought for what the resumption protocol is supposed for. For example for this use it would be useful to have have some way to force deletion of the state from the server, i.e. say that this IKE SA is now going to go to sleep, so you can remove the state, and there is no need to do dead peer detection on it. The current protocol do not have anything like that, and if you delete IKE SA you also delete the ticket, so that mechanism cannot be used for that. I still do not think making the 1 RT protocol to 2 RT protocol in that case would really cause any noticeable effect to the actual handover. Especially as you still most likely have the cellular network there to be used, while you are doing DHCP + IKE_SESSION_RESUME etc on the WLAN, thus only thing that is affected is that traffic moves 100ms later from cellular to WLAN. On the other hand security problems are big issue, as you most likely try to IKE_SESSION_RESUME exchange over any WLAN you happen to see, thus you effectively broadcast your tickets to attackers at will, so attackers can simply take those tickets and sent them to server and get your session resumed, but not forward any other traffic. Also any firewall allowing port 500 packets out but not in, will cause similar effect, as you will not get reply back, but server will consume your ticket. That case also brings out completely new issue which has not been discussed before, i.e. whether the IKE_SESSION_RESUME must come from the same IP-address than what was used before for the IKE SA, i.e. can the IP-addresses change during the IKE_SESSION_RESUME. If that is allowed, then what about NATs, i.e. is it allowed that even when there was no NAT between hosts before, there is new NAT found during the IKE_SESSION_RESUME? Those are not covered by the current document, and at least something MUST be said about those issues. After this example use scenario, I am even more convinced that 2 RT protocol is better and needed, especially if we do allow IP-addresses change, and might need to do NAT-T detection on the IKE_SESSION_RESUME exchange too. Allowing IP-addresses change means that the network where the packets can come in, are different, meaning they might have misconfigured firewalls or similars there, and killing your resumption ticket by just trying to connect through broken firewall is bad idea. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #98: 1 or two round trips for resumption
Hi Tero, To answer the last part of your mail, we always intended address change (and presumably, NAT detection status change) to be supported. This should be clarified in the document, and I have opened Issue #100 for this. However, given that normal NAT detection happens during IKE_SA_INIT, can you clarify why this would work better if we had a 2 RT protocol? Thanks, Yaron -Original Message- From: Tero Kivinen [mailto:kivi...@iki.fi] Sent: Tuesday, April 21, 2009 14:53 To: Narayanan, Vidya Cc: Yaron Sheffer; Paul Hoffman; IPsecme WG Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption Narayanan, Vidya writes: Hi Yaron, We are going back to revisiting consensus here and re-explaining the use cases and I'd certainly like to keep this to as minimum a revisit as possible. The use cases go back to what has been documented in the problem statement we published a while back - draft-vidya-ipsec-failover-ps-02 - it is now expired, but, you should be still able to get to the draft. From the ipsecme charter: Failover from one gateway to another, mechanisms for detecting when a session should be resumed, and specifying communication mechanisms between gateways are beyond the scope of this work item. Thus failover from one gateway to another is outside the scope of this document. If I remember right most of the use cases in draft-vidya-ipsec-failover-ps-02.txt was specifically failover, not resumption use cases. As a key point, I'll note that the situation where resumption is used here is a handoff case for a particular client and does not involve all clients connecting at once, where DH could be a problem. And, in these cases, there is no user interaction involved - the mobile devices are doing everything they can to make handoffs seamless and work with no user or even application involvement. If you are only worried about the case of simultaneous reconnection of thousands of nodes, you can feel free to always use the 2-RT method in your gateway implementation - I am pointing out that it is not the universally applicable use case. From the abstract of the resumption document: To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as a VPN gateway) needs to re-establish a large number of SAs with various end points. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment. So at least it was seen as important use case, and is thats why included in the abstract (and the ipsecme charter text). And, in most cellular deployments, IPsec is used for untrusted access networks (e.g., WLAN), while the DHCP servers and AAA servers are accessible from other access networks as well. And, a handoff from cellular to WLAN needs to be seamless - you can envision an IPsec SA being set up all the time, but only resumed and actively used after you handoff to WLAN. Hmm.. This is again something completely different what I tought for what the resumption protocol is supposed for. For example for this use it would be useful to have have some way to force deletion of the state from the server, i.e. say that this IKE SA is now going to go to sleep, so you can remove the state, and there is no need to do dead peer detection on it. The current protocol do not have anything like that, and if you delete IKE SA you also delete the ticket, so that mechanism cannot be used for that. I still do not think making the 1 RT protocol to 2 RT protocol in that case would really cause any noticeable effect to the actual handover. Especially as you still most likely have the cellular network there to be used, while you are doing DHCP + IKE_SESSION_RESUME etc on the WLAN, thus only thing that is affected is that traffic moves 100ms later from cellular to WLAN. On the other hand security problems are big issue, as you most likely try to IKE_SESSION_RESUME exchange over any WLAN you happen to see, thus you effectively broadcast your tickets to attackers at will, so attackers can simply take those tickets and sent them to server and get your session resumed, but not forward any other traffic. Also any firewall allowing port 500 packets out but not in, will cause similar effect, as you will not get reply back, but server will consume your ticket. That case also brings out completely new issue which has not been discussed before, i.e. whether the IKE_SESSION_RESUME must come from the same IP-address than what was used before for the IKE SA, i.e. can the IP-addresses change during the IKE_SESSION_RESUME. If that is allowed, then what about NATs, i.e. is it allowed that even when there was no NAT between hosts before, there is new NAT found during the IKE_SESSION_RESUME? Those are not covered by the current document, and at least
Re: [IPsec] Issue #98: 1 or two round trips for resumption
snip From the ipsecme charter: Failover from one gateway to another, mechanisms for detecting when a session should be resumed, and specifying communication mechanisms between gateways are beyond the scope of this work item. Thus failover from one gateway to another is outside the scope of this document. If I remember right most of the use cases in draft-vidya-ipsec-failover-ps-02.txt was specifically failover, not resumption use cases. This is really just a terminology issue. Most of the use cases in that document are applicable to resumption. In fact, the current solution for resumption is based on what was produced as a result of that problem statement (combined with Yaron's draft at the time), with the ability to exchange failover gateway candidates removed. In other words, we are not handling anything specific to failovers, but, prior to this charter and WG, failover included resumption in the work we did. snip From the abstract of the resumption document: To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as a VPN gateway) needs to re-establish a large number of SAs with various end points. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment. So at least it was seen as important use case, and is thats why included in the abstract (and the ipsecme charter text). I'm not suggesting that it isn't important - just pointing out that it is not the only use case for resumption. And, in most cellular deployments, IPsec is used for untrusted access networks (e.g., WLAN), while the DHCP servers and AAA servers are accessible from other access networks as well. And, a handoff from cellular to WLAN needs to be seamless - you can envision an IPsec SA being set up all the time, but only resumed and actively used after you handoff to WLAN. Hmm.. This is again something completely different what I tought for what the resumption protocol is supposed for. This has been discussed from the early days and I believe I've brought it up at almost every meeting, even at the last SFO session. As a contributor from the mobile side, this is my primary use case for the resumption work. For example for this use it would be useful to have have some way to force deletion of the state from the server, i.e. say that this IKE SA is now going to go to sleep, so you can remove the state, and there is no need to do dead peer detection on it. Good point - it would be nice to avoid having to do DPD on it and this would certainly be a useful feature if we wanted to consider it. The current protocol do not have anything like that, and if you delete IKE SA you also delete the ticket, so that mechanism cannot be used for that. I still do not think making the 1 RT protocol to 2 RT protocol in that case would really cause any noticeable effect to the actual handover. Especially as you still most likely have the cellular network there to be used, This is conjecture and not a fact. And, I'd prefer to design for seamless, quick handoffs, not with an assumption that you have a second interface up. while you are doing DHCP + IKE_SESSION_RESUME etc on the WLAN, thus only thing that is affected is that traffic moves 100ms later from cellular to WLAN. And, btw, WLAN is only one type of untrusted network - other scenarios may be cellular-to-cellular handoffs in roaming scenarios, cellular to WiMAX handoffs, etc. In some of these cases, there are even RF limitations if you are using a single radio, multi-mode chipset. I'd prefer that we keep the discussion on the RF systems itself out and see what best we can do with our protocols. On the other hand security problems are big issue, as you most likely try to IKE_SESSION_RESUME exchange over any WLAN you happen to see, thus you effectively broadcast your tickets to attackers at will, so attackers can simply take those tickets and sent them to server and get your session resumed, but not forward any other traffic. Also any firewall allowing port 500 packets out but not in, will cause similar effect, as you will not get reply back, but server will consume your ticket. Obviously, the firewalls need to be handled properly if the operator wants this to work - so, that is not the primary issue. I don't understand what you mean by not forward any other traffic in your description of the attack. The attacker does not have the keys to decipher any of the actual packets. The only thing the attacker can do is replay a ticket *after* it has already been sent by the client - in this case, we already talked about some limited backend state the gateway can maintain to limit the impact due to replays. It is also important to note that the other backend entities (which was Pasi's main concern) are accessible
Re: [IPsec] Issue #98: 1 or two round trips for resumption
At 11:15 PM +0530 4/20/09, Lakshminath Dondeti wrote: Before the one roundtrip mechanism is deleted, could you summarize how the security issue that was raised is applicable under the threat model we work with? No, I can summarize it after it is deleted, given that I deleted it in my last message. The security issues that Pasi sent to the mailing list over a month ago include: - A replay of a ticket can cause exhaustion of many resources, not just CPU or state on the gateway. Pasi listed these about a month ago. - A replay of a ticket can cause a legitimate resumption to fail, depending on the algorithms used in the IKE SA. This is unrelated to your, um, interesting logic about RFC 3552. The WG can decide its threat models as it sees fit. The IKEv2 RFC really defines what is in scope. Server state exhaustion attacks are not in scope for being mandatorily made more difficult for some definition of more. I don't see anything in RFC 4306 that limits the scope of the threat models for extensions. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #98: 1 or two round trips for resumption
On 4/20/2009 11:50 PM, Paul Hoffman wrote: At 11:15 PM +0530 4/20/09, Lakshminath Dondeti wrote: Before the one roundtrip mechanism is deleted, could you summarize how the security issue that was raised is applicable under the threat model we work with? No, I can summarize it after it is deleted, given that I deleted it in my last message. The security issues that Pasi sent to the mailing list over a month ago include: - A replay of a ticket can cause exhaustion of many resources, not just CPU or state on the gateway. Pasi listed these about a month ago. That was some interesting logic based on a fictional deployment. Are we to optimize specifically for Pasi's vision of deploying networks? - A replay of a ticket can cause a legitimate resumption to fail, depending on the algorithms used in the IKE SA. This is unrelated to your, um, interesting logic about RFC 3552. The WG can decide its threat models as it sees fit. Huh, and presumably without ever documenting such a threat model! The IKEv2 RFC really defines what is in scope. Server state exhaustion attacks are not in scope for being mandatorily made more difficult for some definition of more. I don't see anything in RFC 4306 that limits the scope of the threat models for extensions. So, are you suggesting that we design IKEv2 for one threat model and IKEv2 session resumption for another? regards, Lakshminath --Paul Hoffman, Director --VPN Consortium ___ 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 #98: 1 or two round trips for resumption
Considering that I didn't know what now meant and this message didn't have a deadline, I hope my input is considered. I prefer the first option - we need to document the associated threat model with each assumption, but, deployments need to figure out what their threat model is. The one RT resumption mechanism is key for handoff situations and for certain environments, it doesn't allow new attacks that are feasible outside of the IPsec use anyway. If we threw out this model, we will be preventing a whole class of use cases that could otherwise use this resumption mechanism. Note that for these use cases, it is not much more expensive to just do the DH and use regular IKEv2, instead of using resumption, if the latter also involved as many roundtrips. Thanks, Vidya -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Paul Hoffman Sent: Wednesday, April 08, 2009 10:56 AM To: IPsecme WG Subject: [IPsec] Issue #98: 1 or two round trips for resumption Greetings again. Tracker issue #98 is the same as the message that Pasi sent to the mailing list last month; see http://www.ietf.org/mail- archive/web/ipsec/current/msg04050.html. There is disagreement among the authors of the session resumption draft how to deal with this issue. One proposal is to add text similar to Pasi's to the document in order to let implementers understand all the things that they might need to do to prevent damage from a replay attack. If this is the method chosen, it should probably be as a section in the main body of the document, not as a security consideration because the issues are more operational than security. A different proposal is to get rid of the one-round-trip mode and have the protocol always take two round trips. This prevents the attack that Pasi brings up, at a higher cost for the clients and server. If you have a preference between these two proposal, please state it now. --Paul Hoffman, Director --VPN Consortium ___ 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 #98: 1 or two round trips for resumption
[As a coauthor of this draft:] Hi Vidya, Can you please give a more detailed description of this use case, where: - The gateway doesn't care about CPU consumption, to the extent where it doesn't mind the extra DH+RSA operations for thousands of simultaneously arriving clients, and, - The number of round trips until something useful happens (e.g. user interaction) is so low that our 1 extra RT becomes critical. Thanks, Yaron -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Narayanan, Vidya Sent: Monday, April 20, 2009 22:52 To: Paul Hoffman; IPsecme WG Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption Considering that I didn't know what now meant and this message didn't have a deadline, I hope my input is considered. I prefer the first option - we need to document the associated threat model with each assumption, but, deployments need to figure out what their threat model is. The one RT resumption mechanism is key for handoff situations and for certain environments, it doesn't allow new attacks that are feasible outside of the IPsec use anyway. If we threw out this model, we will be preventing a whole class of use cases that could otherwise use this resumption mechanism. Note that for these use cases, it is not much more expensive to just do the DH and use regular IKEv2, instead of using resumption, if the latter also involved as many roundtrips. Thanks, Vidya -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Paul Hoffman Sent: Wednesday, April 08, 2009 10:56 AM To: IPsecme WG Subject: [IPsec] Issue #98: 1 or two round trips for resumption Greetings again. Tracker issue #98 is the same as the message that Pasi sent to the mailing list last month; see http://www.ietf.org/mail- archive/web/ipsec/current/msg04050.html. There is disagreement among the authors of the session resumption draft how to deal with this issue. One proposal is to add text similar to Pasi's to the document in order to let implementers understand all the things that they might need to do to prevent damage from a replay attack. If this is the method chosen, it should probably be as a section in the main body of the document, not as a security consideration because the issues are more operational than security. A different proposal is to get rid of the one-round-trip mode and have the protocol always take two round trips. This prevents the attack that Pasi brings up, at a higher cost for the clients and server. If you have a preference between these two proposal, please state it now. --Paul Hoffman, Director --VPN Consortium ___ 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 Scanned by Check Point Total Security Gateway. smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #98: 1 or two round trips for resumption
On Mon, Apr 20, 2009 at 11:20:55AM -0700, Paul Hoffman wrote: At 11:15 PM +0530 4/20/09, Lakshminath Dondeti wrote: Before the one roundtrip mechanism is deleted, could you summarize how the security issue that was raised is applicable under the threat model we work with? No, I can summarize it after it is deleted, given that I deleted it in my last message. The security issues that Pasi sent to the mailing list over a month ago include: - A replay of a ticket can cause exhaustion of many resources, not just CPU or state on the gateway. Pasi listed these about a month ago. - A replay of a ticket can cause a legitimate resumption to fail, depending on the algorithms used in the IKE SA. Can a replay cache help? Note though that getting replay caches to perform well is hard. Ask any Kerberos V implementor. Nico -- ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #98: 1 or two round trips for resumption
Hi Paul, For my clarification, could you please state who are the people on each side of this? I've gone through all emails I have on this thread and I only see Yoav's email supporting the second approach. It is entirely possible that my email isn't working as it should - but, I'd appreciate a pointer to the second email that supported removing the one RT exchange. Thanks, Vidya -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Paul Hoffman Sent: Monday, April 20, 2009 10:16 AM To: IPsecme WG Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption co-chair hat on Greetings again. Of the people who replied, two favored mandating two round trips, and one favored keeping the current one round trip. That (anemic) result, plus the comment that lead to this thread, leads me to say that we need to change draft-ietf-ipsecme-ikev2-resumption to require two round trips. Draft authors: please prepare a -03 with only the two-round-trip solution, and pull out the text about the one-round-trip option. If someone really objects to this, please prepare a personal Internet Draft that lists exactly how you would change the current -03 draft to cover all the security issues that were brought forward. --Paul Hoffman, Director --VPN Consortium ___ 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 #98: 1 or two round trips for resumption
I prefer the second proposal. I would rather have one (even if longer) variation of the protocol over two variations (even if one is shorter) With such a possible attack published, auditors are going to force large installations to use the safer (and longer) version anyway, as it is up to the gateway to decide. -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Paul Hoffman Sent: Wednesday, April 08, 2009 8:56 PM To: IPsecme WG Subject: [IPsec] Issue #98: 1 or two round trips for resumption Greetings again. Tracker issue #98 is the same as the message that Pasi sent to the mailing list last month; see http://www.ietf.org/mail-archive/web/ipsec/current/msg04050.h tml. There is disagreement among the authors of the session resumption draft how to deal with this issue. One proposal is to add text similar to Pasi's to the document in order to let implementers understand all the things that they might need to do to prevent damage from a replay attack. If this is the method chosen, it should probably be as a section in the main body of the document, not as a security consideration because the issues are more operational than security. A different proposal is to get rid of the one-round-trip mode and have the protocol always take two round trips. This prevents the attack that Pasi brings up, at a higher cost for the clients and server. If you have a preference between these two proposal, please state it now. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. Email secured by Check Point ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
