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

["James Kempf" <kempf@docomolabs-usa.com>]

> as long as you do intra-technology handover, and the handover is done in a
> way that's visible to the link layer as a handover, that's true.
>
> if (for instance) you do GSM-to-Bluetooth handovers, there's no link
> between the link layers.

True.

>And if we say "this is obvious" long enough, some
> link layer designer might get the point.........
>

The IEEE 802.20 group has discussed incorporating keeping the back link
open, based primarily on Flarion's contribution, but they have just started
work. Also, not clear given the politics of 802.20 whether preconditions for
swift conclusion of a successful standard (on the order of 802.11) are
there.

> >> And of course the obvious common question: Where are the security
> >> requirements going to be developed....?
> >> (HMIPv6 introduces an obvious point for man-in-the-middle attacks,
which
> >> may not even have to be on-link, for instance. So it's not security
> >> neutral....)
> >
> > HMIPv6 has some security currently, not sure if it addresses your
> > particular concern since it's been a while since I looked at the
> > document. The security considerations in the current FMIPv6 draft are
> > rather weak, there are some approaches that have been discussed in the
> > WG, most utilize IPsec in rather cumbersome ways or depend on as-yet
> > incomplete solutions like AAA key exchange. Erik Nordmark mentioned the
> > possibility of deferring specific security solutions for FMIPv6 until
and
> > unless the work went from Experimental to Proposed Standard, don't know
> > whether that's a still viable proposition, but I think it may be
> > difficult to come up with anything clean in the short time period during
> > which this WG is expected to exist.
>
> actually the requirements doc is where I'd expect to see security become a
> hot issue, exactly because of the long history of pushing security issues
> under the carpet in this environment.

Yes, there should be something in the requirements doc.

> For the protocols, if the intent is to let the experimental protocols out
> in the field with security that's inadequate for production use, I think
> the charter should say that (even though I know there will be heated
debate
> about it in the public review....).
>
> If that's not the intent, I think that should be obvious from the charter
> too.
>

It has been discussed. How about something like:

    Security solutions for HMIPv6 and FMIPv6 have been discussed, but the
current design state for some of these solutions is tentative and
experimental in nature. The Working Group expects that the protocol designs
published as Experimental may not have security sufficient for production
use, but that the requirements document will clearly articulate security
requirements sufficient for production use. Specification of strong security
solutions for these protocols sufficient for production use is a
prerequisite for future standardization consideration.

> > One of the intents of the WG is to get the work published as
Experimental,
> > since it has been underway for 3 years now, then sort out integrating
the
> > various bits of handover related technology that are being done in
various
> > parts of IETF within the IP Mobility Research group in IRTF, filling in
> > holes where necessary and coming up with a clean, integrated handover
> > solution having strong security. That would then be a possible candidate
> > for PS.
>
> I understand that. My worry is truth in advertising in the charter text,
so
> that we avoid having this debate when the protocols are on the IESG's
plate
> for final review, not so much (at this stage) what the final solution is.
>

Agree.

            jak