MOBIKE BOF Report

["James Kempf" <kempf@docomolabs-usa.com>]

The MOBIKE BOF discussed modifications to IKE to support mobility for VPN
tunnels. Subsidiary benefits might be SCTP endpoint changes, Mobile IP IPsec
signaling tunnel changes, and (possibly) HIP. The history on this (according
to CharlieK) is that the IPsec WG apparently could not come to concensus
about how to put this into IKEv2, and so clients like Mobile IP had to do
workarounds. The BOF also discussed a kind of transport based tunnel mode
for IKE (BEET, Bound End to End Tunnel) which was somewhat orthogonal to the
basic idea but fits in with the mobility theme and would be fairly simple to
do.

My (very rough) notes are below, taken real time and not edited except for
spelling mistakes. My impression of the BOF was that there were two
solutions presented, and a fairly high level description of the problem, but
the technical implications of the high level description for VPN tunnels was
not clearly articulated. I think the BOF chairs probably had a very good
idea of the technical issues, and some of the participants as well, but
having that written down might help to refine the solutions. I also think
the charter needs refinement.

The two most controversial issues were whether to support load sharing and
whether to work on BEET mode. On the first, I think load sharing is somewhat
orthogonal to the security issues and probably would be best kept out of the
charter, though it might be worthwhile considering how it could be done. As
for BEET mode, the protocol is pretty straightforward and so it would
probably not be much of a stretch to do it. On the other hand, it is likely
to irritate hard core IKE types because it requires some modifications to
IKE that are not as straightforward as those required for standard mobile
VPN tunnels. Also (again according to CharlieK) BEET utilizes transport
mode, which is basically not used today much.

Bottom line: the charter needs refinement, the task would probaby benefit
from a clearer and more technically detailed problem statement, but,
overall, I think it should be chartered.

                    jak


------------------------------------------------

Background
--------------

Mobility left out fo IKEv2, this BOF?WG? would address.

Example application is a laptop connected through GPRS to the Internet and
also through WLAN. Laptop is connected to corporate VPN gateway through a
fixed address. When laptop moves, need to rekey which is time consuming.

Basic IKEv2 Extensions
----------------------------

Method to update IKE SA to endpoint addresses.

Way to have multiple addresses in both ends.

Some form of auth or verif, like return routability check or addresses in
certificate.

Protocol - (described, new IKEv2 messsage and INFORMATION)

Multiple IP addresses w. single security association.

What happens with replay protection?

Return routability.

Addresses in a cert or statically configured, no need.

Otherwise, before starting to use new address, send empty informational
exchange and wait for reply. Prevent flloding attack against third parties.

Multihoming support. Retransmissions for IKE SA. Try first address,
retransmit to next until reply.
Retransmissions to different IP addresses can be done simultaneously.
Do not mark SA down until have tired a few times.

IPsec SA Address Update.

Update the IPsec SA tunnel endpoint addresses. Some SAs can move and some
stay. Update multiple SAs at one time. Support for multiple endpoint
addresses.

simple protocol using new payload, no notifications as there is space onlhy
for one SPI, use format similar to delete payload.

BEET (Bound End to End Tunnel) Mode IPsec
-----------------------------------------------------

Separating transport from IP address change.

Transport header but limited tunnel semantics. Fixed pair of inner addresses
and addresses ranges not allowed. Like a combination of transport mode and
Bellovin's hostNAT.

Motivation: save bytes. In some cases, up to 51%

Motivation: id/loc split. Inner addresses are ids outers are locators

Objection: Adds complexity. But 98 lines of code in Kame stack
Objection: hard to add to existing implementations. But make optional, use
tunnel mode if not there.
Objection: optional features are bd for portability. But check using PF_KEY.
Objection: Not needed. But also for NAT traversal, HIP, multi6 and others.

Mike: Not an ESP extention, something else that IKE must negotiate, revision
to 2401 about how it works when things move. Extention to IKE to define this
mode to explain how it works.

Mike: (CharlieK) How does this relate to this BOF or WG? WG is focussed on
tunnel mode when external addresses change, payloads might be same, proposal
to fold in and have WG deal with this? Answer: seems to be a need for this
and IPsec WG will close down.

Scope and charter
---------------------

Goals: provide movement and multi-homing of VPN road-warriers w.o.
re-establishing SAs.
           components for other WGS. Ex. Ablity to change SCTP endpoints or
MIP tunnel movement.

Nongoals: Not a full mobility protocol. No:
    ways to hide mobility and multihoming from transport protocols
    handle IP address change hiding from third parties.
    opportunistic auth
    route optimizations
   load ballancing
   not using IKEv1

Qeustion marks;
  PFKEY extensions
   BEET mode (would like to include both)

Questions about how BEET mode fits in. Comment: the one end of the tunnel is
like a NAT.

Deliverables:listed.

Relation to other work in IETF.

SCTP - smoother changes to SCTP endpoints

MIP - avoid re-running IKE after movements.

HIP - PFKEY and BEET support.

Room sense:

Moderate hands on people willing to work on docs, etc. and in implementing
deploying.

Question on whether enough info is available. SteveB says that charter
negotiation is necessary, maybe a requirements and problem statement doc.

Strong show of hands for forming a WG.