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

Hmm.. I think this is more a limitation of MOBIKE (and IKEv2
in general) rather than a security consideration of MOBIKE.

How about adding this to Section 1.2 (Scope and Limitations)?

   IKEv2 relies on information in the Peer Authorization Database
   (PAD) when determining if the peer is authorized to create an IPsec
   SA with particular traffic selectors. MOBIKE does not change this
   part of IKEv2. This may limit the applicability of MOBIKE in
   host-to-host IPsec scenarios: although MOBIKE allows the peers to
   update the tunnel header addresses, it does not modify the child SA
   authorization data in the PAD. In other words, using some particular
   tunnel header address does not imply that the peer is authorized
   to create IPsec SAs with that address in the traffic selector.

Best regards,
Pasi

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of ext Jari Arkko
> Sent: 31 January, 2006 14:42
> To: Erik Nordmark
> Cc: MOBIKE Mailing List
> Subject: Re: [Mobike] does mobike support end-to-end use of 
> tunnel mode?
> 
> Erik,
> 
> Here are some text changes that may help clarify applicability
> and the issues relating to the allocation of inner addresses. First
> a new subsection to be added to the security considerations
> section:
> 
>   5.x. Inner Address Ownership
> 
>   MOBIKE ensures that the IKEv2 peer is always the same
>   entity regardless of its changing addresses. These addresses
>   are in the IKEv2 messages as well as outer addresses in
>   IPsec tunnel packets.
> 
>   However, MOBIKE relies entirely on IKEv2 in the use of inner
>   addresses. Typically, the same inner addresses are employed
>   throughout the lifetime of the IKEv2 security association, i.e.,
>   MOBIKE does not modify the inner addresses. Changing the
>   inner address would in often result in a need to re-establish
>   existing transport layer connections, as these are often
>   bound to specific addresses.
> 
>   As with IKEv2, it is necessary to ensure that peers are authorized
>   to use the inner addresses that they negotiate when creating
>   child SAs. The Peer Authorization Database (PAD) specified in
>   RFC 4301 [RFC4301] allows administrators to specify what
>   inner addresses specific IKEv2 peers have. In addition, it
>   is necessary to ensure that the dynamic allocation of addresses
>   through configuration payloads does not allow peers to
>   "hijack" addresses from other nodes.
> 
> And in Section 1.2 (Limitations) change:
> 
>    This document focuses on the main scenario outlined above, and
>    supports only tunnel mode IPsec SAs.
> 
> =>
> 
>    This document focuses on the main scenario outlined above, and
>    supports only tunnel mode IPsec SAs when at least one of the
>    parties is a VPN gateway.
> 
> --Jari