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

--- [email protected] wrote:

> 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.
> 
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 ?

-mohan

> 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
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>