Subject: [Mobike] Mobile IP and Mobike

From: "James Kempf" <[email-masked]>
Date: Thu, 11 Nov 2004 12:32:33 -0800

So nobody's come out and spoken directly to the issue, but there's been lots
of talk around the edges. Here's my interpretation of what the interaction
of Mobile IP and Mobike is.

>From the discussion on the list and at the meeting this week, it sounds like
Mobike and Mobile IP are separate and incompatible solutions to mobility,
with orthogonal deployment scenerios. They are incompatible because
deploying them together on the same box would result in duplicate "binding
update" messages between the host and the tunnel endpoint (which is the home
agent in Mobile IP). From this, I deduce that having both in a host stack at
the same time is to be discouraged. Their deployment scenerios are
orthogonal because Mobile IP is targetted at wireless network service
providers and Mobike is targeted more at enterprise customers with road
warriors. There might be some overlap for cases such as UMA, which is using
IPsec tunnels set up using IKEv2 over WLAN to tunnel gateways through which
circuit-switched GSM voice traffic and GSM signaling is directed, in
addition to GPRS traffic. The UMA gateways are presumably in a wireless
network operator's network.

Am I missing something? Is more detailed analysis necessary to confirm this
admittedly superficial description? Fire away!

            jak

_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Thu, 11 Nov 2004 22:13:23 +0100

=> they are incompatible as competing signaling between the mobile
node and the home agent, using the mobile IPv6 terms. One can use
the routing optimization of mobile IPv6 with a correspondent node
when mobike is used for the signaling with the home agent.
So the context (again) does matter.

   agent in Mobile IP).

=> I can't disagree (:-).

   From this, I deduce that having both in a host stack at
   the same time is to be discouraged.

=> I disagree: even the home agent and the security gateway can have
the same role they are deeply different. In fact, IMHO this convergence
between security and mobility is a very good thing, at least it should
obsolete my old I-D asking to avoid double tunelling!

   Their deployment scenerios are orthogonal because Mobile IP is
   targetted at wireless network service providers

=> this mobile == wireless == cellular credo makes no sense.

   and Mobike is targeted more at enterprise customers with road warriors.

=> in this room (SAAG session at IETF meeting) many use a nomadic VPN
(aka road warrior VPN) over a wireless network. I don't believe
there is a real split in usage, just that users will come from
two different communities.

   There might be some overlap for cases such as UMA, which is using
   IPsec tunnels set up using IKEv2 over WLAN to tunnel gateways through which
   circuit-switched GSM voice traffic and GSM signaling is directed, in
   addition to GPRS traffic.

=> I can speak about GPRS: the IP service is so poor (private IPv4
addresses, filtering madness, etc) that the best way to use them for
real things (i.e., to go somewhere throught the Internet) is to use
L2TP, i.e., use one of the options offered by current VPNs.
But mobility is not forgotten because it is needed for "vertical
handovers" when you can get locally faster and cheaper than GPRS.

=> orthogonal means than the product is zero. IMHO this is far too
pessimistic, and for the MOBIKE side you forget the multi-homing
and SCTP contexts (do we need to change the name of the WG to
avoid this bias?)

Thanks

[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Alper Yegin <[email-masked]>
Date: Thu, 11 Nov 2004 13:24:23 -0800

Thanks James for bringing this up. I'm also curious about this.

> So nobody's come out and spoken directly to the issue, but there's
been
> lots
> >From the discussion on the list and at the meeting this week, it
sounds
> like
> update" messages between the host and the tunnel endpoint (which is
the
> home
> agent in Mobile IP). From this, I deduce that having both in a host
stack
> at

So, my question is: can I use Mobike instead of Mobile IPv6 to achieve
the same level of IP-layer mobility management (except MIP6 route
optimization)? If not, what is the delta?

> Their deployment scenerios are
> warriors. 

I'm not sure what the protocol-level distinction is between the two
deployments in this context.

> admittedly superficial description? Fire away!

Alper

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Nov 2004 23:38:39 +0200

> of Mobile IP and Mobike is.

The mobike is targeted to the environments where the other end of the
connection is stable, i.e the VPN sgw or similar. The mobile ip both
ends can move, and the connection is not necessarely from the mobile
node to the sgw to the www-server (for example), but can also go
directly between mobile node and www-server.

The mobile IP can benefit from the MOBIKE when handing the mobile node
and home agent connection. I.e. instead of recreating the SAs from
scratch every time mobile node moves, or doing all kind of wierd IPsec
processing to make simulate same stuff inside the ipsec stack, mobile
IP can leave the MOBIKE to take care of the IPsec connection between
the mobile node and home agent, and it only needs to concenctrate to
the route optimization etc to make the connection which are not going
to the home agent or home network more efficient. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "James Kempf" <[email-masked]>
Date: Thu, 11 Nov 2004 14:07:41 -0800

Tero,

> directly between mobile node and www-server.

I'm not sure I understand. In both cases, presumably the mobile node is
communicating with a correspondent that is not the intermediate node. In
both cases, the intermediate node typically isn't moving. The mobile node
can be moving, but I believe what you are saying is that in the Mobike case,
the correspondent can't be move, is that it?

Wrt. direct routing between the mobile node and the correspondent, yes,
that's a difference.

> to the home agent or home network more efficient.

Actually, I'm not sure I agree. Mobile IP sends a Binding Update through an
ESP Auth tunnel, and could optionally also use encryption on the tunnel. If
both are used, and if in addition the Mobile Node uses an ESP Auth + Enc
tunnel for data traffic, it seems to me that it would be exactly the same as
for Mobike. Therefore, the Mobike "binding update" message to the home agent
would conflict with the Mobile IP message.

            jak

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 12 Nov 2004 03:08:52 +0200

> the correspondent can't be move, is that it?

In the mobike case the other end of the security association (i.e.
other end of MOBIKE protocol) will typically be corporate SGW. The SGW
will not move (ok, it might have multiple interfaces for
high-availibility use, but it will not be mobile). All the traffic
from using the MOBIKE will go through that tunnel from mobile host to
the SGW, and normally then continues from the SGW to the the host
INSIDE the coporate network. If mobile node wants to connect the some
other host in the internet (like www.cnn.com) it will either not use
MOBIKE and connect to that directly using his normal address (==i.e.
the connection will be broken if the IP address changes unless mobile
ip is used), or it will connect to the corporate firewall through the
SGW and make all packets be routed in both directions through the
tunnel. 

> would conflict with the Mobile IP message.

Before the mobile IP can send his AH/ESP protected binding update
packet to the home agent, he needs to make have that IPsec SA up and
working. If he tries to send them AFTER the previous IP address has
disappeared (i.e tries to use the new IP address), then the SA does
not work properly because reply packets go still back to the old
address (IPsec SA is tied to the previous IP address).

So what mobile IP needs to do it needs to recreate the IPsec and IKE
SAs. MOBIKE can make that recreation unnecessary, because it allows
mobile IP to inform MOBIKE that IP address change has occurred (or the
generic mobility policy module in the device informs both MOBIKE and
Mobile IP about this change) and the MOBIKE can fix the tunnel
endpoint addresses of the IPsec and IKE SAs so mobile IP can use the
IPsec SA tunnel to send his binding update packet to the home agent.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 11 Nov 2004 19:00:24 -0800

> address (IPsec SA is tied to the previous IP address).

IPsec SA is tied to the Home Address. IKE SA is tied to the CoA.
so a Binding Update can be sent right away.

Vijay

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 12 Nov 2004 08:07:34 +0200

> so a Binding Update can be sent right away.

That is not following the IKEv1/IKEv2 RFCs nor the architecture draft.
There tunnel mode SAs are tied to the IP addresses which are used to
when it is negotiated in the IKE. It is not very clean solution that
Mobile IP goes and modifies the internal databases of the IPsec module
(SAD). If you want to use standard IPsec then you need to renegotiate
the IPsec and IKE SAs before sending the binding update. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Fri, 12 Nov 2004 14:36:09 +0200

Folks,

Paul and I feel that this thread is not necessarily
contributing much to take our design work forward.
The primary goal and usage scenario for MOBIKE is
outlined in the charter and it deals with a VPN
user that moves around; lets focus on completing
our design to reach that goal.

(Mobile IPv6 RFCs rely on IPsec and IKE for a particular
part of their functionality, and there are also drafts
about IKEv2 usage. There are different ways that those
designs might evolve -- relying either more or less on
IPsec protocols and hence MOBIKE. However, our feeling
is that the discussion of that would be more appropriate
on the MIP6 list than in here, at least until we are
at a stage where our base protocol is done and we can
start to think about "MOBIKE for SCTP" or "MOBIKE for
MIPv6" and other similar issues. Even then, this would
have to be done in close co-operation with what people
in the "application" protocol WGs want.)

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Fri, 12 Nov 2004 06:01:59 -0800

Tero,

> SGW and make all packets be routed in both directions through the

This is certainly not how I use my VPN today and I don't think it would be a
good idea in any event to design MOBIKE so that it works this way.
Typically, people use a VPN into a corporate network because they also want
to derive the benefits of firewall support for external access, not simply
to access hosts within the corporate LAN. Most client side IPSec VPN
software grabs the entire network interface and IP stack so that external
connections are not possible except through the address in the corporate
network. This is a security measure, otherwise direct attacks on the host
from the Internet through the local address would be possible. One can
debate the wisdom of this approach, but the fact of the matter is that many
corporate VPN users do use it, and most WLAN public access hotspots (which
provide absolutely no security) assume that something like this scenerio is
what customers will use (or SSL VPNs, which are another story).

>From a technical standpoint, I also don't see why the host would need to use
its local address when contacting hosts outside the corporate network. The
local address is changing, but the address in the corporate network
presumably isn't, or, at least, I can't see any reason why it should. So it
should be possible to keep the address in the VPN gateway network constant,
unless I'm missing something, and continue to tunnel through the VPN
gateway, with perhaps a few lost packets while the address change signaling
and processing is underway.

It is true that, unlike Mobile IPv6, the host can't perform route
optimization so all traffic is forced to traverse the triangle route through
the VPN gateway. But Mobile IPv4 doesn't have route optimization either, so
the effect for MOBIKE would be to provide approximately the same
functionality as Mobile IPv4 and the Mobile IPv6 home agent to mobile node
connection, except in a form that provides a more incremental upgrade path
for existing VPN users, and, as compared with Mobile IPv4, with
authentication that is oriented more toward corporate users and not public
access networks and with support for encryption, which Mobile IPv4 does not
provide at all.

> IPsec SA tunnel to send his binding update packet to the home agent.

Vijay explained this so I won't repeat it.

But I'd like to point out that this is only true for MIPv6. Security for
MIPv4 is much less well defined.

                 jak

---

From: "James Kempf" <[email-masked]>
Date: Fri, 12 Nov 2004 06:04:33 -0800

Tero,

> the IPsec and IKE SAs before sending the binding update.

Right, this is exactly the point I was trying to get to. But it would
lengthen the binding update time.

            jak

---

From: Francis Dupont <[email-masked]>
Date: Fri, 12 Nov 2004 15:05:10 +0100

SAs.

=> this is off topics but Tero, you are plainly wrong here.
Mobile IPv6 takes care of the IPsec SAs and with the K bit set to one
of the IKE SA too. And this is supported by some implementations
(i.e., I can prove it :-).

Thanks

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 12 Nov 2004 17:00:42 +0200

> what customers will use (or SSL VPNs, which are another story).

Yes, that is the main scenario of the MOBIKE. Note, that there is no
need for moble IP in that case, which is the reason why I didn't
present this scenario in my last time.

The tunnel mode SA from the SGW to the VPN client, with the IP-address
given from the SGW, and with the MOBIKE updating the tunnel endpoint
addresses as the VPN client moves, is everything which is needed for
mobility for that kind of simple cases. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 12 Nov 2004 07:38:54 -0800

> the IPsec and IKE SAs before sending the binding update. 

you gotta be kidding me. :) the selectors are applied to
the inner IP header, not the outer one. and the selectors are
what are negotiated.

we got the Mobile IPv6 + IPsec documents reviewed by numerous
folks from the security area.

we have interoperable implementations (infact many
implementations). so, have to strongly disagree with you.

anyway, this will be the last email on this thread from me.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 12 Nov 2004 07:43:52 -0800

> mobility for that kind of simple cases. 

not really. the sessions break if I switch to another VPN SGW or if
I cross security boundaries and move into the trusted network.

Vijay

---

From: Michael Richardson <[email-masked]>
Date: Fri, 12 Nov 2004 11:17:04 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "James" == James Kempf <[email-masked]> writes:
    James> think it would be a good idea in any event to design MOBIKE
    James> so that it works this way.  Typically, people use a VPN into
    James> a corporate network because they also want to derive the
    James> benefits of firewall support for external access, not simply
    James> to access hosts within the corporate LAN. Most client side

  "Typical" for Windows clients, true. Virus+remove-attack risk exceeds
any benefit from route optomization.

  Untypical for everyone else, including PDAs and other things.

    James> From a technical standpoint, I also don't see why the host
    James> would need to use its local address when contacting hosts
    James> outside the corporate network. The local address is changing,
    James> but the address in the corporate network presumably isn't,
    James> or, at least, I can't see any reason why it should. So it

  I do this all the time, as do my colleagues.
  We use the local address on the inside of peer-to-peer tunnels for
things like SIP. All of our machines have globally unique public IPs for
use inside their tunnels, and that is how we configure customer machines.

  This is because we have a more sophisticated IPsec policy ability.

  Please do not assume that the limits of current IP-Telco RemoteAccess
systems define what future usage is. 
  That's why we spent the 1980s and early 1990s working *around* the Telcos.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Fri, 12 Nov 2004 19:32:40 -0800

At 3:05 PM +0100 11/12/04, Francis Dupont wrote:
>=> this is off topics but ...

Yes it certainly is, so please drop it and all related "but this 
isn't Moble IP" threads.

One co-chair chimed in this morning, and now the other one will. We 
have a charter (see 
<http://www.ietf.org/html.charters/mobike-charter.html> if you have 
forgotten it). It is a charter that we agreed to *long ago*. Attempts 
to discuss things that are clearly off-charter, particularly attempts 
to discuss things that are known to be in the charter of a different 
WG, are unproductive.

If you want to change the charter, start a new thread with that in 
the subject. I would prefer that you didn't because we have made good 
progress under the current charter, but you can try. Once.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 15 Nov 2004 11:57:38 +0200

> the inner IP header, not the outer one. and the selectors are

Yes, but tunnel endpoint addresses are not selectors, and they are not
negotiated at all, they are taken from the IKE SA endpoint addresses.
IKE SA endpoint addresses are also not negotiated, they are taken from
the IP-addresses of the IKE packets. If no NAT traversal is used, then
the IP-addresses will be the ones used in the initial exchange. If NAT
traversal (NAT-T) is used then they SHOULD be from last authenticated
packet from the other end (Note, that the IP-addresses are not
negotiated).

This means that the when the SGW wants to send packets to the other
end it will use the exactly same OUTER IP addresses all the time, and
there is no standard method in the IPsec to change that anyway. The
MOBIKE is trying to define a method to do that.

> folks from the security area.

At least I did comment to the drafts that they require the combined
mobile IP and IPsec stacks, as the Mobile IP needs to modify the data
structures of the IPsec, and that kind of methods are not normally
implemented in the IPsec. 

> implementations). so, have to strongly disagree with you.

Of course you can combine Mobile IP and IPsec and make them to work
together, there is no question about that. It just means that you
cannot take IPsec from vendor A and Mobile IP from vendor B and assume
that they can work together at all. With MOBIKE changes to the IPsec,
you should be able to take IPsec from vendor A, MOBIKE from vendor C
and Mobile IP from vendor B, and assume that they will work together
(as long as IPsec and MOBIKE support the PFKEY extensions defined by
the MOBIKE later). 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 15 Nov 2004 12:00:12 +0200

> I cross security boundaries and move into the trusted network.

And the point being? Of course session will break if you want to break
them.

If you keep using the same VPN SGW all the time the sessions will not
break. You can even move inside the corporate network, if you simply
still keep using IPsec tunnel and send all data through the VPN SGW
still sessions will not break.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike