Subject: [rfc2462bis] config consistency vs secure ND/DHCPv6

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 28 Apr 2005 16:26:51 +0900

Hello,

In your IESG comments on draft-ietf-ipv6-rfc2462bis-07.txt, you said:

> Was there an analysis of the configuration consistency rule
> (section 5.6) of accepting the most recent information, while
> trying to secure both DHCPv6 and ND/addrconf (SEND)?

As far as I know, there was no such analysis.  But honestly speaking,
I don't understand the point of the question.  In my understanding,
this rule is not for security, but about how to deal with
configuration errors of servers/routers.  Whether or not ND is secured
with SEND and/or DHCPv6 is secured with its authentication mechanism,
inconsistency due to configuration errors can happen, and the same
rule should apply (as described in Section 5.6) in that case.

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?

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Jari Arkko <[email-masked]>
Date: Thu, 28 Apr 2005 12:37:39 +0300

>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. The current text is:

   It is possible for hosts to obtain address information using both the
   stateless protocol and DHCPv6 since both may be enabled at the same
   time.  It is also possible that the values of other configuration
   parameters such as MTU size and hop limit will be learned from both
   Router Advertisements and DHCPv6.  If the same configuration
   information is provided by multiple sources, the value of this
   information should be consistent.  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, the most recently obtained values
   always have precedence over information learned earlier.

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.

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.

--Jari

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 29 Apr 2005 15:12:07 +0900

>>>>> On Thu, 28 Apr 2005 12:37:39 +0300, 
>>>>> Jari Arkko <[email-masked]> said:

> in the current text. [...snip]

[...]

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

>    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

---

From: Jari Arkko <[email-masked]>
Date: Fri, 29 Apr 2005 10:27:26 +0300

>affect existing implementations by specifying a concrete behavior with
Ok. Didn't realize this.

>What do you (and others, Allison in particular) think?
Ok for me.

--Jari