<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 through the so-called "trusted networks" that often arguably have a reduced degree of security than the IPsec case. > 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. 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? > 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? > As Yaron indicated, NAT traversal will work here. And, designing for broken firewalls and NATs as the primary case seems strange. > Those are not covered by the current document, and at least something > MUST be said about those issues. Sure, adding text for these in a more explicit fashion would be fine. > 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. I don't understand why you need 2 RTs to account for IP address changes or NAT-T. As I said, I don't want to design for broken firewalls as the primary case - if there are broken firewalls, things may be slower, but, I don't buy the argument that things should always be slower to account for possible broken firewalls. Vidya > kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
