something.Minutes of the IKEv2 mobility and multihoming BOF (mobike) at IETF-58 Date: Tuesday 11.11.2003 17:00-18:00 Chairs: Jari Arkko <Jari.Arkko@ericsson.com> Tero Kivinen <kivinen@ssh.fi> Minutes: Pasi Eronen (Pasi.Eronen@nokia.com) Spencer Dawkins (spencer@mcsr-labs.org) Charlie Kaufman (charliek@microsoft.com) Merged by Jari Arkko (jari.arkko@ericsson.com) Slides: http://mobike.kivinen.iki.fi Preliminaries ------------- Jari Arkko bashed the agenda. There were no comments. Tero Kivinen: Background & Main scenario ---------------------------------------- Background: mobility stuff was left out from IKEv2, but it's needed for moving hosts and possibly for Mobile IP. Rekeying is an option sometimes, but its too slow and consumes resources with additional SAs. More importantly, it may require user interaction where token cards are involved. Motivating scenario is a laptop connected to home network via VPN. Home network assigns internal IP address and tunnels to laptop's current address. Laptop should be able to change from wired to wireless network or between wireless networks without dropping the internal IP address or breaking connections. Goal is to support endpoint address changing during an IPsec session while maintaining the SA (i.e. without rekeying). Multi-homing an increasingly common scenario. IP addresses change when user changes networks. Francis Dupont: If we just rekey, this does not protect the outer addresses, and this opens a security problem? Tero/Jari: Response is that these are what this protocol design effort is intended to avoid. James Kempf: in GPRS, your IP address doesn't change since you're using same GGSN all the time? Tero: right, but most likely it will change if I go from here to Finland.. Basic IKEv2 extensions, to allow the parties to update existing IKE SA endpoint addresses (not necessarily the best or only solution) Pekka Nikander: Is the idea to have multiple ip addresses in single SA? Tero: Yes Pekka: What happens to replay protection if the connections have seriously different QoS? Tero: It depends, needs more work. Francis Dupont: Is supporting multiple addresses at the same time necessary, this is a bit more complex? In most cases, we don't have the IP addresses in certs (because we don't known them). Return routability check is easy: just send an empty informational exchange and wait for reply. Rules how to use multiple IP addresses. Don't mark IKE SA dead until you retry all IP addresses several times Not all IPSEC SAs move just because IKE SA moves - leave e-mail up through GPRS, because it's always up, etc... Need a strategy for what address(es) to send to during transition. How to keep SA updates from ping-ponging back and forth? This was about moving IKE SA around. We also need to update IPsec SA tunnel endpoint addresses. We also need a way to move only some of the SAs, because we might e.g. want to use video feed only via WLAN, never GPRS. Lauri Tarkkala: We don't have atomic updates, so what happens during the update when the state will be out of sync? Tero: If you can still receive both IP addresses, it's ok; if you have lost your old address already, there's nothing we can do anyway. Pekka Nikander: Do I understand correctly that this is only about outer addresses? Tero: Yes. Pekka: what about transport mode? Tero: we don't know yet if we will consider transport mode at all, this is mainly about road warrior type setup. Francis Dupont: you need an easy way to move all SAs in one shot Tero: most likely you have only a very small number of IPsec SAs, like one. Pekka Nikander's BEET mode presentation --------------------------------------- Background: this is related to end-point identifier / locator split discussion in nsrg/multi6/hip, avoiding transport protocol reconnection when underlying IP addresses change. Transport header with tunnel semantics. Fixed (compressed out) inner addresses. Equivalent to transport Mode + Bellovin's Host NAT. Aimed at end to end SAs with one or both endpoints changing IP addresses. Relates to this BOF if we decide to do transport mode also. This is one possible way to do things so that transport layer protocols don't see change in addresses. Motivations save bytes id/loc split Objections adds complexity (98 lines in Ericsson's implementation) hard to add to existing implementations optional features are bad for portability (use by other IPSEC protocols) not needed (see Pekka's slides for details) Spencer Dawkins: what do you mean by portability? Pekka: portability of key management protocol (e.g. IKE) implementations, this is easy to address David Black: ESP doesn't have modes; what you have here is new SA processing mode, and you need IKE to negotiate this node. Pekka: the reason why I'm calling this ESP extension, is because IPsec WG has said that I can't call this IPsec (because this is not 2401) Francis Dupont: Is BEET relevant for this BOF or not? Jari: We will ask that question later. Pekka: Really depends whether we want to address transport mode or not. Charlie Kaufman: How this relates to this BOF, since this BOF is focused on tunnel mode? Pekka: There seems to be need for something like this; if IPsec WG would continue, that would be more logical place. Jari: Scope and charter discussion ---------------------------------- (see Jari's slides for details) Goals: Smooth address transition for road warriors Specific components useful to other WGs: - Changing SCTP endpoints - Protecting Mobile IP signaling without renegotiation - PFKEY extensions, BEET mode for HIP? Non-goals: - Load balancing - Handling address changes imposed by third parties (e.g. NAT boxes) - Provide opportunistic authentication (like HIP) - Provide optimization of routing paths (like MIPv6 RO) - Support use within IKEv1 Discussion: Michael Robertson: when doing "failover" from WLAN to GPRS, do I have to know both IP addresses beforehand? Tero: No Michael Robertson: Why load balancing is out of scope? Tero: it could be there, but it's complicated James Kempf: Load balancing is actually quite complicated, some of this really research stuff. Vijay Devarapalli: where the BEET mode fits in? it looks like a new mode (like transport and tunnel), requiring modifications to IKE Tero: we need to modify IKE anyway. Vijay: i want this to become a wg, so limit scope Bill Sommerfeld: If we do load balancing, we need help from people who have done that in other contents. About beet, it looks small enough not to cause too much delay. And it's separable, so if we get problems we can throw it away. Think of it as a funky form of header compression. Francis Dupont: I don't thing we need to have multiple multiple concurrent IP addresses, updating them is enough. James Kempf: clearly define the problem being solved. Andrew McGregor: if it's reasonable to use mobike for transport mode, we really need something special (to avoid transport connections dying); BEET could do that. Jari continued with relation to other work in IETF (such as SCTP, MIP, HIP) Francis: (didn't catch this) Mark Zimmerman: One scenario you mentioned is dead peer detection? Do you see mobike as completing or complementing IKEv2 DPD? Tero: We have DPD already in IKEv2, and we are using that as a mechanism to notice when address changes. Lauri Tarkkala: About BEET mode, if it's a WG item, it should be standards track; if going informational, just publish it now. Jari: 1st question: are there interested people to *WORK* on this? (Roughly ten hands raised) Jari: 2nd question: I understand that companies don't want to reveal plans, but is there's interest from service providers or vendors to actually use or implement this? (A few shy hands raised) Jari: 3rd question: is there enough information to decide if we want WG or not? Clearly the charter is ready yet, but is the big picture clear? (About 30 hands) Jari: Anyone opposing? (no hands) James Kempf: I think there should be a clear problem statement. Steven Bellovin: Working out an adequate charter needs discussion, and writing down a problem statement is usually a good way to clarify your thinking. Mohan Parthasarathy: (comment about multihoming I did'nt catch) Bill Sommerfield: there's lot of similarity between multihoming and mobility in terms of system impact, maybe you can solve two problems for the price of one Jari: do you think we should create a WG? (About 50 hands) Jari: anyone against? (Two hands) Someone: Comment about avoiding surprises, I think the group name is slightly misleading. it's not just IKEv2, also IPsec SAs. And BEET is neither IKEv2 or IPsec (currently). But I don't have a better suggestion either. End of meeting 18:05 |