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