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

<[email protected]> Wed, 1 Feb 2006 10:31:44 +0200
Newsgroups gmane.ietf.mobike
Message-ID <[email protected]>
Mohan Parthasarathy wrote:
 
> This still does not describe the limitation. If i can
> assume that the PAD can be configured appropriately,
> then you can ensure what address a peer gets. So,
> there seems to be a use case where this is limiting. 
> Can someone describe that ?

In host-to-host IPsec use, either your addresses are static 
(so you don't have that big need for MOBIKE), or your PAD is not 
configured appropriately -- or you're doing something like BTNS.

To take a concrete example: suppose my laptop wants to establish 
an IPsec SA with my local mail server.  Assuming some kind of 
corporate PKI, the laptop could create an IKE_SA, authenticate the 
mail server, and authenticate itself as "pasi-dot-eronen-at-
nokia-dot-com" (or "laptop-123456-at-nokia-dot-com").

But there's practically no way the mail server's PAD would contain
child SA authorization data saying that "pasi-dot-..  is allowed to
create IPsec SAs with traffic selectors matching address
192.0.2.123", since the address came from DHCP...

So either creating the IPsec SA fails, or the PAD contains data
saying "pasi-dot-... (and all other employees) are allowed to create
SAs for practically any address" (or at least addresses they can
spoof).  The latter is not exactly very secure... but that's what 
some people are using anyway (sort of like BTNS).

The "Experiences with Host-to-Host IPsec" paper by Tuomas Aura,
Michael Roe, and Anish Mohammed (try Google for PDF) describes
this and many other issues with host-to-host IPsec in detail.

With typical "VPN gateway" use, the problem doesn't really exist.
When the gateway allocates the client a new IP address using
configuration payloads, it can at the same time update the PAD.

None of this is really specific to MOBIKE as such, so I think
we should not add text about this to the MOBIKE draft...

Best regards,
Pasi