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

I do not have a strong opinion on where text should
go. But personally I would like to see some note
about the inner address allocation authorization issues
(even if that note pushes the blame to IKEv2 where it
belongs).

--Jari

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