Re: Internal WG Review:: Internal WG Review: Mobility for IPv6 (mip6)

[Thomas Narten <narten@us.ibm.com>]

Note: In re-reviewing this thread, I just noticed that the two
co-chairs for this group weren't included in the charter properly and
consequently one didn't get cc'ed on the thread. The co-chairs are:

       Gopal Dommety <gdommety@cisco.com>
       Basavaraj.Patil@nokia.com

> Based on the history of MIPv6 (c.f. 2 years to finish up after the basic
> problem with route optimization security was discovered) and the number of
> work items this proposed WG is attempting to cover, the proposed schedule
> looks hopelessly optimistic to me. I think 3 years is probably a much better
> estimate.

Perhaps. But IMO, the base MIPv6 spec should get revved in about a
year. There should be plenty of implementation experience by then
(from what I hear), and it's important to capture the results of that
quickly.

> >      - Route optimization will require security mechanisims for
> >        trusting and updating the binding information. Return-routability
> >        is the basic mechanism for route-optimization. Mechanisims using
> >        a shared secret Key/Security Association will be considered.
> >        Methods for establishing a security association between the mobile
> >        node and the correspondent node are out of the scope of the WG.
> >

> I'm unclear about what is being proposed in this work item.

My understanding is that this is really about allowing a MN and CN,
that already have a pre-existing shared secret, to use that for RO,
rather than Return-Routability. There does seem to be interest in this
in the WG.

> Clearly, the task of setting up a full IPsec security association
> (which is what I presume is meant by "security association") is out
> of scope, because that is already done by IKE.

Correct.

> Was the intent to eliminate any asymmetric key-based mechanism at
> all, even something like TLS? In that case, the restriction would
> seem to limit discussion to some AAA-based mechanism, and this work
> item should explicitly say that.

I believe the intent is not to turn this into a more general way to
negotiate keys. I'd have concerns with going that route.

> If that is not the intent, then the work item should explicitly state that
> various proposed alternatives to RR will be considered, and one selected, or
> possibly that requirements will be generated and an alternative selected
> based on requirements.

The one concern I have with all this is that right now, we have one
way of doing RO. Adding another one means there is more than one way,
and that implies you may need a framework for negotiating which gets
used. And/or one needs to develop a framework that allows for a third
and fourth (even if they are not specified yet) for down the
road. That may prove more tricky that first appears.

Thomas