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

[Basavaraj.Patil@nokia.com]

James,

>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


>
>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. 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.

>
>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. 

>
>
>            jak

-Basavaraj