Re: does mobike support end-to-end use of tunnel mode?

Erik Nordmark <[email protected]> Thu, 02 Feb 2006 11:37:43 -0800
Newsgroups gmane.ietf.mobike
Message-ID <[email protected]>
[email protected] wrote:

> Well... if you have host-to-host tunnel mode IPsec working in a 
> secure manner, MOBIKE could work as well. But this situation 
> is pretty rare.

Clarifying question: for this case are you assuming that the inner and 
outer IP addresses for the tunnel must be different?

I think tunnel mode can be used (per the RFCs even if implementations 
might not handle it) where the inner and outer IP addresses are the same.

If you apply MOBIKE to such a case, then you end up with an unsolved 
address ownership issues, because the existence of the IPsec SAs, which 
now use a different outer remote address, will prevent a different host 
which has "inherited" that outer address from establishing a SA with the 
same peer.

This end-to-end tunnel case was in fact the one that made me concerned.

A host is using some public-access network infrastructure. It gets 
allocated IP address B by a DHCP server.

B contacts server A (www.example.com), and uses Mobike.
As a result of this, A ends up with a (IKE and IPsec) SAs that make 
packets destined to IP address B be subject to the IPsec SA that was 
setup. Thus packets destined from A to B are placed on an ESP tunnel, 
with a destination of B.

The host (B) later moves to a different network, where it is assigned IP 
address C. It uses Mobike to move the IKE and IPsec SAs from using B to 
using C. This (and here is were the document is silent) means that 
packets sent from A to B and placed in an ESP tunnel with a destination 
of C. (In any case, there isn't any text I could find that says that 
there is no residual IKE or IPsec SA or policy that refer to B.)

What happens when another host appears on the initial public-access 
infrastructure and is assigned IP address B by the DHCP server? (This 
could be hours or days after the first host left.)
When that host tries to contact www.example.com, things would fail due 
to the SADB and SPD entries that were created by the original host.

---

The above isn't an issue for a IPsec SG that has static 
allocation/authorization of the inner IP addresses (having a fixed 
binding between the clients CERT and the inner IP address is clearly 
secure). Don't know if there are issues with IPsec SGs that do dynamic 
allocation of the inner IP address.

    Erik