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
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
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
