Bob,
> This is staring to sound a lot more like a research project than
> something the IETF should be considering standardizing now. I wonder if
> it might be better to complete the research and then decide the best way
> to signal it's usage (e.g., bit, control protocols, etc.).
You may be right that *how* exactly to *use* the bit is
more a research issue than a standardization issue. At least
we should get much more peer-review from the security people
on CGA and any other such methods.
However, what Erik and the MIPv6 Design Team suggested is that
the "bit" is *reserved* at this time for future use. From
the MIPv6 point of view, it *also* acts as a safeguard against
the possible future situation where RR becomes the weakest
link in IPv6 security, e.g. because ND gets secured. It would
allow gradual shift-out from RR at that point of time.
Basically, it looks like we are not much going anywhere:
- The currently known alternatives to RR do not seem to
get accepted at the MIPv6 WG due to IPR issues.
Personally I consider it very unlikely that new similar
methods would magically emerge without IPRs.
- Thus, MIPv6 Route Optimization cannot move forward
unless RR can be made secure enough.
- It looks like some people (me included) would not like
to see RR widely deployed *unless* there is a clear way
out of it. A way that does *not* require world-wide
security infrastructure.
- The "bit method" is one such a way, but nobody wants
to adopt it, at least not for MIPv6 RR.
- Ergo, MIPv6 is stuck, again.
Actually, it *may* be possible to augment RR design so that no
such external safeguard, as the bit, is needed. We are looking
at that, right now. Unfortunately there are some IPR issues on
that path, too, and I don't know if they can be resolved.
However, even if we could "fix" RR, that does *not* remove
the need for other zero-conf security solutions (such as
Secure ND), as I explained in the other note to Tony.
Thus, I really think that we should make such a bit
*reservation* for two reasons: Firstly, to provide
a migration path to zero-conf security, e.g. Secure ND,
and secondly, to provide a controlled way of disabling
RR for certain *addresses*. (Note that it must be
disabled for *addresses*, not nodes, due to MitM and
impersonation attacks.) If it later turns out that
the reservation does not need to be used, after all,
the better. Then release it or use it for something even
more productive.
--Pekka Nikander
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
