Re: 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