2.6.13 IKEv2 Mobility and Multihoming (mobike) Bof

Current Meeting Report

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 

Slides: http://mobike.kivinen.iki.fi


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 

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 

    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 

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 

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.

  save bytes
  id/loc split

  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 
           - Provide opportunistic authentication (like HIP)
           - Provide optimization of routing paths (like MIPv6 RO)
           - Support use within IKEv1


    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


Background & Main Scenario
Bound End-to-End Tunnel (BEET)
Scope and Charter for MOBIKE
Basic IKEv2 extensions
Discussion -- Fate of the Group