Subject: Re: [mobile-ip] Protecting the MN-HA signaling with IPsec

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Wed, 09 Oct 2002 18:37:08 +0900 (JST)

Hi,

From: Jari Arkko <[email-masked]>

> And then to the reasons of tunnel mode vs. tunnel mode plus HAO/RH2.
> Here are some considerations:
> 
> - There's an efficiency difference of 24 bytes/packet in favor of
>    the tunnel-mode only solution. This probably does not matter at
>    all for just HOT/HOTI protection, but it may matter for protecting
>    all of the payload packets. Yet, in the long term I would somehow
>    see it more likely that the traffic is secured end-to-end rather
>    than just to the HA.
> 
>    Conclusion: it may matter a bit (no pun intended), but not much.

Agree.

> - Direct tunnel mode encapsulation needs an API towards IPsec.
>    (It needs an implementation of an API, I don't think we need
>    to specify it).
> 
>    The functionality that is needed is this: whenever a care-of
>    address is updated in a binding entry, find all tunnel mode SAs where
>    the destination selector is the corresponding home address
>    and the source selector is the home agent, and update the tunnel
>    gateway address. (Exercise for the reader: prove that this is
>    sufficient even when dynamic keying is used.)

I want to hear about the validity of this procedure from IPsec (IKE?)
experts.

>    The IPsec implementation that I wrote long time ago would have
>    been able to offer such an API. Do all implementations have this?
>    No. Is the API requirement unreasonable: I don't think so, it
>    is likely that most implementations need an API anyway for a
>    variety of reasons, including management.

For example, KAME has such an API but it is provided only for user
space programs, not for the kernel inside.  Because we are
implementing MIP6 in the kernel, we cannot utilize the API (currently
at least).

>    Conclusion: The direct tunnel mode encapsulation requires an
>    API, but in some cases such an API may be available. But it
>    is an additional burden.

Right.

> - Recreate vs. update: Francis pointed out that it was
>    possible to do a create/delete e.g. via PF_KEY instead
>    of adding complex support for modifying SAs.
> 
>    (I might also be possible to have IKE renegotiate, but
>    that I actually doubt because I don't know how the
>    tunnel gateway would be set correctly automatically.
>    Remember that IKE is run on the care-of addresses,
>    so I'm not sure it survives movement if if the SAs
>    created by it do.)
> 
>    Conclusion: there may be some easier ways to do the
>    API than to require an update operation.
> 
> All in all, it's some bandwidth savings and slightly
> prettier format vs. some additional implementation
> requirements. Which side has heavier weight? When writing
> the draft I was undecided for a long time, but I now think
> that perhaps this is something where we should just require
> the cleanest packet format. UNLESS this causes real problems
> for many implementations.
 
> Keiichi, others, please comment if this is possible in
> your implementation!

With respect to possibility, it is possible if we create the kernel
API for IPsec SA/SPD handling.

I also want to hear other implementor's voice.  For example, those who
are not implementing both IPsec and MIP6 may want to use SA(HA, MN
HoA) for tunneling because of lack of the API (or difficullty to
create the API).

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
KAME Project <[email-masked]>

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 09 Oct 2002 11:20:33 -0700

> implementing MIP6 in the kernel, we cannot utilize the API (currently

isnt your SA database in the kernel?

Vijay

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Thu, 10 Oct 2002 10:19:33 +0900 (JST)

> isnt your SA database in the kernel?

Yes.  Sorry for my confusing text.  I mean we just don't have the API
now.  It takes some time to define and implement such API, but it is
possible from the implementation point of view.

---
Keiichi SHIMA