i don't have a problem with including a section with this.
does anyone else has an opinion on this? Jari?
basically the additional text would to state that:
- since there are few sec values, it may be needed to reuse sec values
- this is a last resource option, since it may affect interoperation
- a long time is required between the deprecation of the old value and
the reassignment in order to prevent misinterpretation of the value by
old implementations
- this may affect interoperation (if an old implementation receives a
CGA generated with the new meaning of the sec value, it will fail)
- by no means an implementation should support both meaning of the Sec
value, since it may lead to downgrading attacks,
anything else needed in this section?
This seems sufficient IMO.
ok, i will wait for additional comments in this topic, and if no
opposition i will include some text in the next version
(2) Wouldn't the length of the modifier have to be defined as part
of the CGA SEC registry, too?
If we define the number of leading zero bits for Hash2, say N, as
part of the registry, we are no longer bound to the limit of 16 *
(23 - 1) = 112 bits which the 3-bit Sec parameter provides.
However, the length of the modifier should be at least as long as N
plus a certain number of bits for location privacy. Since this
may, at some future time, exceed the limit of 112 bits, it may be
good to define the modifier length as part of the IANA registry,
too.
I think this is a good point, indeed
However, I am not sure this needs to be encoded in the address
itself
i.e. in the sec value itself. I mean the only reason to encode
information in the address itself AFAICS is to prevent downgrading
atttacks, agree?
I wasn't saying that the length of the modifier needs to be encoded
into
the CGA, but it should rather be defined as part of the registry
entry.
You mean like additional information...
Yes.
I don't know...
i guess that if a new sec value is assigned, the details will need to
be defined in a RFC so i would say that the RFC would be right place
to
describe all the related information, including the modifier length
for
this particular sec value... i mean, as you mention, current 128 bit
modifier seems to be good enough for our needs now...
Summarizing, i don't have a strong opinion on this neither, but i
think
it would be easier/simpler to store this information in the associated
spec and reduce to the minimum the information contained in the
registry itself.
does anyone else has an opinion?
Hmm, the necessary length of the modifier follows directly from the
number of leading zeros for Hash2. Since this number of zeros is
defined as part of the registry entry,
this is not the case, actually
The registry only contains the name, the sec value and the RFC where
the sec value usage is defined
the number of zeros in the hash2 will also be defined in the RFC that
defines the sec value usage
that is why i suggest to define the modifier length in the RFc that
defines the SEC value also
the registry entry also seems to
be the right place to define the modifier length.
Adding more modifier bits to the CGA Parameters data structure in the
form of a variable-length extension field, as you mentioned, would also
be a viable option, because the MN could then decide for itself how
many
random bits it needs.
BTW, will there /always/ be an RFC for each new registry entry?
yes, the IANA considerations states
"future assignments are to be made through Standards Action [2]."
thanks, marcelo
Bye,
- Christian
--
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
