Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC

[神明達哉 <[e-mail]>]

On Sun, Feb 21, 2016 at 11:00 AM,  <[e-mail]> wrote:

> This is to initiate a two week working group last call of
> http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem.
> Please read it now. If you find nits (spelling errors, minor suggested
> wording changes, etc), comment to the authors; if you find greater
> issues, such as disagreeing with a statement or finding additional
> issues that need to be addressed, please post your comments to the
> list.

I've read the 06 version of the draft.  I don't think this document is
ready for publication, yet.  (I'm feeling dejavu of repeating the same
comments I made many months ago...) while I see potential of this doc
to be useful, it seems to have many issues in its current form such as
technically inaccurate (to me at least) statements or the mixture of
possibly useful information and very minor and operationally
unrealistic/hypothetical nit picking.  IMO, publishing it with these
issues would rather introduce confusion and/or misunderstanding.  More
specific comments follow.

- General: it's true that there's spec ambiguity regarding the M/O
  flags.  I also see different implementations can behave differently,
  possibly because of such ambiguity.  But simply because there's some
  ambiguity or behavior difference doesn't immediately mean these
  should be officially described in a document like an RFC (whose
  publication cost is expensive).  IMO, the ambiguity and/or behavior
  difference must lead to actual operational issues that matter in
  practice.  In that sense most of the points described in this
  document seem to be too minor (see specific discussions below).  I
  see at least a couple of points that may have real operational
  impact, such as Divergence 1-3 in Section 4.1 (which would make
  coexistence of SLAAC and DHCPv6-based address allocation impossible
  for some implementations, and I heard some operators want this type
  of operation).  My personal suggestion is to focus on such real
  issues, removing all minor points.  The resulting document might
  become very thin, but could be much more useful and readable.

- Abstract

   [...]  These are
   the M, O, and A flags, which by definition are advisory, not
   prescriptive.

  I don't think the A flag is "advisory", and I believe it's pretty
  clear from the specification (even if there might be an
  implementation that misunderstands it).  Will discuss this in more
  detail below.

- Section 1

   (A flag is
   also advisory by definition in standard, but it is quite prescriptive
   in implementations according to the test results in the appendix.)

  I'd like to know exactly what "advisory by definition in standard"
  means since IMO A flag is perfectly "prescriptive".  Section 5.5 of
  RFC4862 states:

   [...] Creation of
   global addresses as described in this section SHOULD be locally
   configurable.  However, the processing described below MUST be
   enabled by default.

  and subsection 5.5.3 specifies:

    a)  If the Autonomous flag is not set, silently ignore the Prefix
      Information option.

  and how to configure a global address from the prefix (the
  corresponding PIO should have the A flag on because of "a)").

  And, in fact, the draft itself seems to admit it's actually
  prescriptive and well understood by implementors accordingly.

- Section 3, item 1)

      [...]  More specifically, it is
      unclear whether RA (with M=1) is required to trigger DHCPv6; in
      other words, It is unclear whether hosts should initiate DHCPv6 by
      themselves if there are no RAs at all.

  The latter half of this looks a bit awkward.  "in other words"
  suggests rephrasing the same thing, but "whether hosts should
  initiate DHCPv6 without RA" is not really the same thing as
  "whether RA (with M=1) is required for DHCPv6".  perhaps "for
  example" or "in particular" might be a better phrase here.

  And, one minor nit: s/It is/it is/

- Section 3, item 3)

         When flags are in transition, e.g. the host is already SLAAC-
         configured, then M flag changes from FALSE to TRUE, it is not
         clear whether the host should start DHCPv6 or not; or vise
         versa, the host is already configured by both SLAAC and DHCPv6,
         then M flag change from TRUE to FALSE, it is also not clear
         whether the host should turn DHCPv6 off or not.

  I don't understand why we need the condition of "the host is already
  SLAAC-configured".  With or without, it's already (intentionally)
  clear per RFC4861/4862 whether the host should start DHCPv6 or not.
  Same for the latter part (regarding SLAAC).

  I'd also note that the very original intent of RFC2461/2462 was
  clear on this point: a change of M flag from FALSE to TRUE means the
  host should start DHCPv6; a change of M flag from TRUE to FALSE
  should not affect ongoing DHCPv6 sessions.  While it's true that
  RFC4861/4862 are (again, intentionally) silent on these, I'd say if
  an implementor actually wants to use this flag it's most natural to
  follow what 2461/2462 stated.

- Section 3, item 3)

         When one address configuration method is off, that is, the A
         flag or M flag changes from TRUE to FALSE, it is not clear
         whether one host should immediately release the corresponding
         address or just retain it until the lifetime expires.

  At least for the A flag, I'd say it's pretty obvious that host MUST
  NOT do that.  Otherwise the two-hour rule introduced in RFC4862
  would simply be pointless; an on-link attacker could easily force
  hosts to invalidate addresses by sending forged RAs with the PIO
  clearing the A flag.  True, it's not explicitly documented in the
  RFCs, but that doesn't immediately mean "it's not clear".  Is there
  actually an implementation that invalidates SLAAC-configured address
  on receiving a corresponding PIO with the A flag being 0?

- Section 3, item 4)

      But for A flag and O flag, ambiguity could possibly happen.  For
      example, when A is FALSE (when M is also FALSE) and O is TRUE, it
      is not clear whether the host should initiate a stand-alone
      stateless DHCPv6 session.

  Personally, I would consider a mere implementation defect.  I don't
  think any of the spec ambiguity can lead to this awkward behavior.
  For some kind of information document especially in the O&M area, it
  might note there is such a broken implementation.  But in this
  particular case I don't see it very useful in a practical sense
  either, since if both A and M are FALSE this network is almost
  unusable anyway.  This topic rather seems to be an artificial
  nitpicking.  (I vaguely recall we discussed this point on an earlier
  version of the draft, but I don't remember the conclusion, if any)

- Section 4.2, Divergence 2-1: same as the previous point.

- Section 4.2, Divergence 2-2

         1) Getting RDNSS from both the RAs and the DHCPv6 server, and
         the RDNSS obtained from the router has a higher priority.

  This doesn't seem to be very relevant to the main subject of this
  draft, i.e, it doesn't seem to be related to the M/O/A flags.  And,
  as this draft itself points out, RFC6106 (and its bis) clearly
  specifies the precedence on this point; this implementation is
  simply and clearly broken in terms of the spec conformance, and I
  don't see much value in pointing it out in this document.

- Section 4.2, Divergence 2-2

  It's not clear to me whether this is really about DNS
  configuration.  Isn't it just a variant of Divergence 1-3 of Section
  4.1, i.e., some implementation doesn't start DHCPv6 if it
  receives/has received PIO with A being TRUE?

- Section 5.2

   Ideally, these steps could be initiated by multicasting RA messages
   onto the link that is being renumbered.  Sadly, this is not possible,
   because the RA messages may elicit a different behavior from each
   host.

  This description is vague to me.  Can the problem(s) be more
  specific?

- Section 6

  Overall, I don't understand how this is specific to the main subject
  of this document (unclear specification of M/O flags, and some
  deviant implementation behavior regarding these, sometimes also
  related to the value of the A flag).  The security considerations in
  this section generally seem to be applicable with or without the
  M/O/A issues.  That is, an on-link attacker can do many bad things
  when RA or DHCPv6 isn't protected.

- Section 6

   If an attacker wants to perform MiTM (Man in The Middle) using a
   rogue DNS while legitimates RAs with the O flag set are sent to
   enforce the use of a DHCPv6 server, the attacker can spoof RAs with
   the same settings with the legitimate prefix (in order to remain
   undetectable) but advertising the attacker's DNS using RDNSS.

  I'm not sure if this is explicitly worth noting in the context of
  this document (see also the previous general point).  This type of
  attacker could also spoof DHCPv6 responses, so with or without the
  ambiguity of the RA flags and implementation variation, the attacker
  can force victim hosts to use forged RDNSS.

- Section 6

   Fedora 21 and Centos 7 behaviour cannot be explored for a MiTM attack
   using a rogue DNS information either, since the one obtained by the
   RAs of the first router has a higher priority.

  I don't understand this sentence (btw, I guess s/explored/exploited/).

- Appendix: to be honest I've not closely read the appendices.  But
  I guess that could actually be a point to be addressed: the
  information provided here seemed to be too unorganized, just listing
  random things, possibly including many duplicates.  I hope this
  section will be more well-organized and readable.  Also, even though
  I understand it doesn't have to be a comprehensive implementation
  list, I would consider it biased (and even possibly misleading) that
  it doesn't include any of open source BSD variants, while it talks
  about result of multiple flavors of Linux.  BSDs are also widely
  deployed IPv6 implementation developed differently from Linux, and
  anyone can examine the behavior at source-code level (like Linux,
  but not like Windows or MacOS or iOS).  If we keep this appendix,
  I'd strongly suggest including at least one open-source BSD variant.

--
JINMEI, Tatuya