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 not what they specified, so they are not going to use it (and that solution presented at that time, would work perfectly with MOBIKE now). > The conclusion was that a scenario of using MOBIKE and MIP6 between > the same two endpoints must be avoided. So I assume nobody has yet specified how to use MIP6 and MOBIKE together, but instead MIP6 still want to use their modified version of IPsec? > 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. Charter or draft does not say anything about resumption to be aimed for mobility use cases. I do not say it should not be one possible use case, but again it is hard to decide which optimizations to take when we do not have common idea where this protocol is meant for. As I still do not know where resumption is really meant for, I cannot really say what kind of protocol it should be. > > 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. And where can I find this "good threat analysis"? As you did ignore my point that this sitution can happen also without any attacker, by just in normal use with misconfigured networks. > If the incentive doesn't exist or is not meaningful, the likelihood > is generally low, causing the attack to be of low importance. It is really hard to imagine what kind of incentive could DoS attackers have in general. They could be just pissed of with some operator charging too much money for their phone calls, and they could try to make that operators networks perform badly. If the network is really set up using break-before-make connections (which I still do not belive anybody would really use), they can cause two drops by just first luring network user to wrong network and stealing ticket, and second break when network user tries to use the already consumed ticket later. I.e. they just set up WLAN basestation sending out station id which matches the operators allowed WLAN network. When user roams to that network, it will not get connection at all, thus his phone call breaks. User has still already sent out the ticket to the network, which was stolen by the attacker, and attacker uses that ticket to destroy the state from the SGW side. Now when client moves back to cellular network (after detecting that WLAN it tried to move to didn't offere serivce), everything works fine, until it finally reaches the proper WLAN and tries to move to that. Now the ticket is already used, and instead of the unacceptable 1 RT, he actually now have 3 round trips + Diffie-Hellman time, which is by your definition unacceptable for VoIP handoffs. Of course as attacker does not want to make active transmissions himself, he will rather make virus attacking phones and pdas, which will set up the attack, i.e turn on the WLAN on the phone and starts faking to be basestation, and forwarding the ticket packets forward, but dropping all others. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
