Subject: [Mobike] does mobike support end-to-end use of tunnel mode?

From: Jari Arkko <[email-masked]>
Date: Fri, 27 Jan 2006 00:14:29 +0200

Hi,

Erik read our protocol spec recently, and he had
questions about the use of addresses in the protocol.
Specifically, he was worried about "time shifting"
or "address stealing" attacks where a host uses
first address A in one place and then later B in
another place. The question is what happens when
some other host that comes later to the first place
and gets the same address A as the first host. Will
two hosts be able to communicate with the same peer?
What will happen with ongoing sessions of the first
host?

I explained that in MOBIKE the outer addresses
as such don't matter; they are just the tunnel
endpoints (although Appendix A describes a
case where an implementation can get this
wrong). What matters is the inner addresses --
its those addresses that are used to match what
packets go to what peer. Getting the address
allocations right is essentially for the security
of the system. This is indeed the case even without
MOBIKE in base IKEv2 VPN usage*.

However, Erik asked whether the document makes
it clear that it only supports the scenario where
at least one of the peers is a gateway that ensures
the address allocations are correct. And I was unable
to answer that. Are we making it clear enough? Also,
is it possible to use MOBIKE in host-to-host tunnel
mode? If so, how? And have the security considerations
relating to such usage been described?

Thoughts, anyone? Erik, feel free to post more detailed
questions and concerns...

--Jari

*) But I was unable to find a statement either in
RFC 4306 or the clarifications document about
address allocation authorization issues.

_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Mohan Parthasarathy <[email-masked]>
Date: Thu, 26 Jan 2006 17:20:43 -0800 (PST)

Jari,

This is the same case what Thomas Aura raised and the
Appendix has the answers. Regarding, host-to-host
tunnel mode, i would say that it is not supported by
observing the following.

In the Introduction,

   The main scenario for MOBIKE is enabling a remote
access VPN
   user to move from one address to another without   

   re-establishing all security associations with the 
   VPN gateway.

And in scope and limitations,

   This document focuses on the main scenario outlined
above, and
   supports only tunnel mode IPsec SAs.

This tells me that only VPN gateway is supported.

In the host-to-host tunnel mode case, one can still
assume that
no two nodes (among a set of nodes) have the same
"inner"
address. Is there any problem in making such
assumptions ?

-mohan

---

From: Jari Arkko <[email-masked]>
Date: Tue, 31 Jan 2006 10:57:39 +0200

>This tells me that only VPN gateway is supported.
I think so too, but maybe it should be made more
explicit, if people are misunderstanding it?

>address. Is there any problem in making such
I was thinking about that, but I'm not sure I have a foolproof
method. Maybe FCFS allocation of inner addresses is one
approach, but it still has some question marks. For instance,
how do we know that we can deallocate an allocated address?

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 31 Jan 2006 14:41:51 +0200

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

---

From: <[email-masked]>
Date: Tue, 31 Jan 2006 16:56:07 +0200

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-masked] 
> [mailto:[email-masked]] 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,
>

---

From: Mohan Parthasarathy <[email-masked]>
Date: Tue, 31 Jan 2006 16:59:48 -0800 (PST)

>    to create IPsec SAs with that address in the
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

---

From: Mohan Parthasarathy <[email-masked]>
Date: Tue, 31 Jan 2006 17:08:14 -0800 (PST)

> explicit, if people are misunderstanding it?
Sure. Extra clarification is always good.

> how do we know that we can deallocate an allocated
Just use static addresses. Perhaps, we should
understand
this use case a little better.

-mohan