Re: Mobile IP and Mobike

"James Kempf" <[email protected]>
Newsgroups gmane.ietf.mobike
Message-ID <[email protected]>
Tero,

> 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.
>

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.

> 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.

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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.