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

["James Kempf" <kempf@docomolabs-usa.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.
>
> Hmmm... I understand your concern but I dont think that the time-taken
> for completing Mobile IPv6 should be the benchmark for everything else
> related to MIPv6.
>
> One option would be to keep the charter as currently proposed but
> limit the number of deliverables to a realistic number. The milestones
> can identify items that can be delivered in the next one year at which
> point we could recharter or revise milestones. From that perspective,
> I think what is doable and what MUST be done are:
> 1. The MIB for MIPv6 (MUST)
> 2. Bootstrapping problem/solution
> 3. Alternate MN-HA security scheme
> 4. RO based on shared secrets
>

I guess I'm unclear as to why a recharter would be needed. Why not simply
stage the milestones so that the less pressing work items are scheduled
later, i.e. prioritize?  Or do you feel that the work items omitted from the
above list might disappear as time goes on because they really aren't
necessary?

>
> >
> >Other than that, I have just one comment (embedded).
>
> >>
> >>      - 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. 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. 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.
>
> Reusing an existing IPsec SA between the MN and CN is one possibility
> but as Thomas has mentioned at sometime, such an SA does not
> necessarily provide the authorization for creating a binding cache
> entry for an MNs HoA in the CN.

Understood.

> What was intended here was the ability
> to do RO based on symmetric keys based authentication for example. How
> these keys are exchanged is outside the scope. The ability to use a
> binding data suboption for example in the BU sent by an MN to the CN
> is one possibility. AAA based schemes are not what we had in mind here.
>

Ok, but one thing that has become apparent at least to me is that when a
security solution leaves out important details like how keys are exchanged
or generated, it runs the risk of being nondeployable. It might make some
sense for the MIPv6 group to at least generate some requirements and direct
them to the right WG for solution.

> >
> >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.
>
> For limited scope deployments, symmetric key based authorization for
> RO is possible. For the larger scope RR based RO is the preferred
> mechanism. The intent is not to start evaluating the whole
> route-optimization mechanism all over again. We need to get some
> experience with what has been specified in the base MIPv6 draft
> first.
>

Right, I understand. I'm just concerned that, as with the case of BU
security prior to the development of RR, a mechanism specified without
sufficient detail may prove, upon closer examination, to have significant
deployability holes.

            jak