Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt

From: [email-masked]
Date: Wed, 21 Apr 2004 17:29:10 -0500

> 
> S. Daniel Park wrote:
> > not sure because I didn't follow up this thread fully but
> > this is my personal concern.
> > 
> > If this draft would be a RFC as standard track, I guess
> > current RR in 24version will not be used for Mobile IPv6
> > with the implementation aspect. Is there any consideration 
> > or requirement ? I hope to see more improved and clarified 
> > something in this draft. 
> 
> I may have misunderstood the question, but the proposed
> mechanism is an alternative and optional scheme for
> authorizing BUs related to route optimization.
> 
> As such, the base RR mechanism is used by default
> unless this specific scheme is implemented and
> configured on. The proposed mechanism is applicable
> only to a certain (limited) class of situations, so
> you would not always have such a configuration available.
> 
> Or perhaps you are asking whether the mechanism is used
> in addition to RR? I think the authors have inteded the
> mechanim to be used as a replacement (for the situations
> that it applies to) rather than as an add-on. 

I think this method can be considered as an alternate to
RR based RO when the MN and CN share a key/secret. For the
subset of CNs that the MN has a preconfigured key/secret,
RR is not applied. But it does not necessarily replace the
RR based RO scheme. The MN *should* be capable of doing
RO using RR for the larger set of CNs. So I would'nt call
it as a replacement, but rather an alternate scheme for
a set of CNs that the MN is aware of.

>There has
> also been some discussion on the list about whether the
> proposed mechanism should be merged with care of address
> testing from the base RFC or possibly some improvement of
> that, such as CBA/EBU. I personally think that something
> along those lines might be fruitful and would make the
> mechanism more widely applicable, though it may be too
> early to tell yet.

Maybe the authors could express their thoughts on the
enhancement proposals.
  
> --Jari
-Basavaraj 

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6

---

From: "Christian Vogt" <[email-masked]>
Date: Thu, 22 Apr 2004 12:02:44 +0200

On Monday, March 29, 2004 11:59 AM [GMT+1=CET],
Jari Arkko <[email-masked]> wrote:

> [...]                                         There has

> Maybe the authors could express their thoughts on the

Hi Basavaraj, hi MIP6 folks,

Charlie's pre-configured-keys proposal is targeted at making things easier for peers that have some kind of a trust relationship in addition to a security relationship. The security relationship identifies the pre-configured keys. The trust relationship is required to let the correspondent node trust in the mobile node actually being present at a registered care-of address. This allows the peers to forego the care-of-address test.

In an email from March 15, I mentioned that there may be scenarios in which peers have a security relationship, but no trust relationship. For instance, an ISP may configure its media servers with the keys of its customers. The customers could then use their keys and Mobile IPv6 for communications with the media servers, but some customers might misuse the lack of a care-of-address test to wage a re-direction-based flooding attack against an arbitrary IP host.

IMO, there is an easy way to combine standard Mobile IPv6's care-of-address tests with Charlie's pre-configured-keys proposal. Here is an excerpt from my email from March 15:

> [...]                                   Maybe this [the combination
> of pre-configured keys with a care-of-address test] could
> be realized by a CoTI/CoT exchange, and by authenticating a Binding
> Update with a key produced with the pre-configured key and the
> Care-of Keygen Token? The (64-bit) pre-configured key would play the
> role of the Home Keygen Token in this case. One would still avoid the
> HoTI/HoT exchange, and one would avoid involving the home agent in
> the binding-update procedure.

Sure, the care-of-address test would partly vitiate the binding-update-latency improvement that pre-configured keys bring along. But at least we save a potentially long home-address test through the mobile node's home agent.

Using a *concurrent* care-of-address test (i.e., one running in parallel with data transfer to and from a new care-of address as described in [1] and [2]) could help to avoid the additional latency of the care-of-address test during the critical phase. The concurrent care-of-address test could be protected by Credit-Based Authorization [2]. Credit-Based Authorization was first presented during the MOBOPTS session at the 59th IETF meeting in Seoul. I am currently putting the finishing touches to an Internet-Draft describing Credit-Based Authorization in more detail.

Best regards!!

- Christian

[1] Early Binding Updates for Mobile IPv6
    http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-binding-updates-00.txt
[2] http://www.tm.uni-karlsruhe.de/~chvogt/research/ebu-cba.pdf

-- 
Christian Vogt
Institute of Telematics, University of Karlsruhe (TH)
www.tm.uka.de/~chvogt/

"If we knew what we were doing, it wouldn't be called
research, would it?" (Albert Einstein)

> Maybe the authors could express their thoughts on the

"§©šŠX§‚X¬´È©ê'~Šà†Ûi³ÿðÃžµú+ƒùšŠYšŸùb²Ø§~æŠž