Re: Internal WG Review: MIPv6 Signaling and Handoff Optimization (mipshop)

[gabriel montenegro <gab@sun.com>]

Bernard Aboba wrote:
> > That's clear enough for me!
> > (if it's OK with the rest of the IESG to have a charter that says 
> > this.... security people, are you reasonably happy with this?)
>
>
> We have had quite a bit of experience now with trying to solve security 
> problems w/low latency in a mobile environment.  Diameter MIPv4, 
> MIPv6/IPsec interactions, EAP w/fast handoff, etc.  We know these 
> problems are HARD -- that these interactions are difficult to analyze, 
> that they often require new thinking.
>
> So far, very little of that thinking is actually occurring, either in 
> IETF or in IRTF.  And I think this is because we have taken on too many 
> of these things as WG work items before the technology was truly 
> understood.
>
> I hope that MIPSHOP is not continuing this tradition of "design before 
> thinking" but based on the discussion so far, I'm concerned.
>
> At some point, some where, we are going to have to get a group of people 
> to sit down, and help us develop the technology with which we will solve 
> these problems, instead of just experimenting.  And so far I don't see 
> what the plan is for accomplishing that.

We recognize these are hard problems, and we also recognize that we can't
claim in the charter that we will solve them within the tight schedule we're
targetting.

As Jim alluded to before, Erik Nordmark suggested that we not aim at
solving the security issues as a main goal of MIPSHOP. Thus, we're
proceeding in parallel. We want to finish off HMIPv6/FMIPv6 in order
to allow experimentation with them, knowing
full well that initially they may lack a complete security solution
(more so for FMIPv6 than for HMIPv6).

Of course, if and when we decide to advance them beyond experimental,
we will only do so if the security issues are solved (and this may require
rechartering, as the current charter only envisions experimental status). But it is deemed
that even without completely solving them, these protocols are sufficiently
new that experimentation is in order, and would highly benefit from a somewhat
stable snapshop (i.e., experimental RFC's).

About how to document this: I agree that the requirements document is one
place to do so. However, the only requirements document currently in the
charter is related to "Localized Mobility Management" which in practice applies
to HMIPv6, not to FMIPv6.

But, I actually think that documenting the security shortcomings, should go in the
security considerations section of the respective documents (HMIPv6 and FMIPv6).
This would make it clear in the documents themselves one important reason
why they are Experimental and not proposed standard.

Finally, Bernard talks about the dearth of efforts to look into this space.
Some thinking has happened in the areas he himself mentioned (so I don't agree that
no thinking is going on), some other has happened in the MIPv6 route optimization
efforts (which HMIPv6 recently benefitted from, by the way), and we're hoping still
more can happen in a companion and related IRTF RG we're currently chartering.
This IRTF group will focus on currently misunderstood/unclear mobility optimization
issues and security is certainly one of them.

Would this approach of:

1. Not delaying further testing of MIPSHOP protocols by proceeding with the current
   charter that specifically targets EXPERIMENTAL protocols,
2. Clarifying in those EXPERIMENTAL protocols the currently known
   shortcomings (including, of course, those related to security)
3. and, Including the corresponding security focus in the related
   IRTF RG,

be acceptable?

[Notice, that if #3 produces good output, this could become the feedback
needed in order to advance the EXPERIMENTAL protocols to PS, but that would
require rechartering, so is not the charter we're reviewing right now.]

-gabriel