Narayanan, Vidya writes: > 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.
Main thing between resumption and failover is that resumption assumes you reconnect back to same host, as in failover you can reconnect to another host. I myself consider resumption as subset of the failover cases, i.e. failover cover more things than what resumption itself covers. Note, that charter explictly mentions that the resumption can also be to the cluster of closely cooperating gateways, but cooperating protocols inside that cluster are not part of the our scope. > > 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. With WLAN and so on I do not think the problem is the RF part, I think it is the DHCP and so on part. For example in IETF it usually takes me about 10 seconds to just to get DHCP address when I first time connect to the network (for some reason it seems the servers always answer only after 2-3 retries). I have not really seen WLAN networks that offer anywhere near the subsecond connection times you seem to assume here. It might be true in the cellular-to-cellular handoffs, but do you really use IPsec and resumption on such environments. I would expect mobike would be much better used there, as if you need IPsec for one cellular network, you might as well do it always. > Obviously, the firewalls need to be handled properly if the operator > wants this to work - so, that is not the primary issue. If you start to talk about WLANs, then you are not talking about operators, you are talking about random basestations someone has set up somewhere. I can assume network operators to configure their boxes properly, I cannot really assume random home user for setting their WLAN basestation properly. > 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 thing that makes replay attacks harder is that attacker does not get the ticket he could replay. If you walk around on the street and see some random WLAN named "open wifi" and your phone decides to see if it works, and gets DHCP address, and after that tries resumption to gateway, you just sent that ticket to attacker. Attacker will then take that packet from the air, or from the basestation, and use it to attack, i.e. after he takes that packet and sends it to gataway (for example with fake source IP, so return packets never reach you), then your ticket is killed, and your accounts billing started going. > 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. Yes, after client sent the ticket, but that does not mean server ever got that ticket from client. I.e if the "fake" WLAN is set up so it will drop all UDP port 500/4500 packets, you never get any IPsec resumption on that network, but you still assume your ticket is valid as for your point of view it was never used. The attacker can see that ticket, and can then mount the attack. Or it could be that the WLAN is set up to allow any UDP packets out, but only "known" UDP packets in (dns and nothing else). In this case you yourself make the attack, i.e. you kill your ticket by sending it to the server, but server's reply never reaches you, so you still think you have not used the ticket, but server has done that. > The protocol does allow for IP address changes and also allows the > client to request a new IP address from the gateway for its internal > IP address - do you see a reason why this doesn't work? Other than the fact that draft does not mention it, no. As an implementor, I would add checks that IP address must be same, as there is no mention that IP-addresses could change. Also I would not send NAT detection payloads, as they are not mentioned in the draft. If such feature is wanted, it MUST be specified in the document too. Do not assume implementors guess correctly. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
