>>>>> On Thu, 28 Apr 2005 12:37:39 +0300,
>>>>> Jari Arkko <[EMAIL PROTECTED]> said:
>> Does this simple answer address your question? If not, please explain
>> the point (that I could not understand). If it does, do you want to
>> update the draft regarding this issue? E.g., do you want to emphasize
>> that this is not for security and the rule should apply whether or not
>> ND/DHCPv6 is secured? Or can we just leave the text as is?
>>
> I can't speak for Allison, but looking at Section 5.6 and thinking
> about this in the context of security, I actually do see an issue
> in the current text. [...snip]
[...]
> The issue with this is that when we have inconsistent information,
> it may make sense to consider the security of the information source
> along with how recent the information is. You might turn on
> security for ND but not for DHCP, due to software availability
> or other reasons. The SEND specification actually goes to great
> length to explain how it works when you have multiple routers
> and environments with varying support for SEND. Something
> similar may be needed here.
Thanks for the detailed explanation. I was also thinking about a
similar point from the original comment, but I did not really consider
that level of details.
If this was the intent of the original comment, I see the point.
And,
> I would suggest rephrasing the last sentence of 2462bis draft
> as follows:
> If inconsistent information is learned from different sources,
> information learned securely from sources SHOULD have
> precendence over information learned without protection.
> For instance, Section 8 of RFC 3971 discusses how to deal
> with information learned through Secure ND conflicting
> with information learned through plain ND. Where there
> is no security difference, the most recently obtained values
> SHOULD have precedence over information learned earlier.
I generally agree with the sense of the proposed text. Thanks for the
proposal.
In the context of rfc2462bis, however, I'm afraid the suggested text
may carry too strong an implication. That is, it will explicitly
affect existing implementations by specifying a concrete behavior with
an RFC2119 keyword.
So, it may make more sense just to provide related consideration (but
not a requirement for implementations), e.g.:
[...] However, it is not considered a
fatal error if information received from multiple sources is
inconsistent. Hosts accept the union of all information received via
the stateless protocol and DHCPv6.
If inconsistent information is learned from different sources, an
implementation may want to give information learned securely
higher precedence over information learned without protection.
For instance, Section 8 of RFC 3971 discusses how to deal with
information learned through Secure ND conflicting with information
learned through plain ND. The same discussion can apply to the
preference between information learned through plan ND and
information learned via secured DHCPv6, and so on.
In any case, if there is no security difference, the most recently
obtained values SHOULD have precedence over information learned
earlier.
What do you (and others, Allison in particular) think?
Thanks,
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
