Pekka Nikander wrote:
> Well, personally I consider the bit method as a gross
> hack, and really wish that we can create something better.
> The need is there.  We just need a method.

The bit method is not only a gross hack, it is entirely unnecessary. All
it provides is an optimization for the receiver to decide if a CGA check
is worth the effort, and for nodes that are aware enough to look for the
bit they could just as easily check every IID. In fact if they really
care, they have to check every IID just to make sure there was no
tampering. If they do check there is no opportunity to bid down since
the source is in control of deciding to generate a CGA to begin with,
and the receiver is in control of deciding if a CGA was received. If a
CGA is not necessary, what value did the bit provide? (a minor time
saving at the receiver) If a CGA is necessary and the key didn't match,
what value did the bit provide? (absolutely nothing) If a CGA is
necessary and the key did match, what value did the bit provide? (wasted
time checking a bit then deciding to run the hash) On the other hand, if
the bit did exist, how many opportunities are there for an intermediary
to flip it and disrupt the expectations at either end? As the lengthy
discussion on the list shows, this proposal for a bit actually generates
more problems than it solves.

In the grand scheme of things, the minor optimization for a receiver to
avoid the cpu burden of checking a hash is really a bad reason to chew
up a bit which carries no other value. As far as I can tell the CGA
mechanism is just another way to generate a 3041 IID, and it is up to
the end points to decide if they want to impose a higher level semantic
to that bit string. Using a bit doesn't help them decide since the
source could just as easily use a non-CGA 3041 IID as clear the bit. Any
clueful receiver would get the hint that a non-CGA 3041 IID meant the
sender didn't care about securing this address, while a CGA based one
meant it did care.

Just get over the idea of using a bit, it is a very bad idea ...
Tony



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

Reply via email to