On Fri, Jul 8, 2016 at 10:03 AM, Tomek Mrugalski
<tomasz.mrugalski@gmail.com> wrote:

> So the day finally has come. Authors working on RFC3315bis believe that
> after over two years of work, this document is ready for working group
> last call. This call initiates the working group last call on
> draft-ietf-dhc-rfc3315bis-05 [1]. Since this is a large document (130+
> pages), there's upcoming meeting and a holiday period, chairs decided to
> do an extended last call that will last 4 weeks. Please post your
> comments by August 8th.

I've reviewed rfc3315bis-05.  As for whether to advance it, I'd
"abstain": personally, I don't like to give such a large spec a go
without an experiment of implementing it.  It's quite possible that it
has a serious issue that is hard to identify just by reading the text,
e.g., a critical oversight for some corner cases or inter-section
inconsistency.  Often these kinds of defects can be only noticed when
someone actually tries to implement it, or even better, when checking
interoperability between different implementations.  Unfortunately I
don't have that time myself, and I think it's irresponsible for me to
say it's good to go (I understand the motto of "believing in running
code" is more or less a thing of the past in the IETF already, so I'm
not insisting this be a requirement to advance the doc).

On a related question: is there anyone/group that actually implements
the major changes in this bis spec?  I wonder this since I believe
some relatively trivial errors (like the second comment on Section
20.4 below) can be quite easily detected once one tries to implement
it.  The fact that this level of issues still remains seems to suggest
that implementation status of the spec is actually quite poor, and
that makes me nervous (again, I know this is not an official
prerequisite for this doc to be published; it's just my personal
concern).

I also have some higher level concerns:

- I'm okay with deprecating the delayed authentication protocol, but
  I'm not sure if it's okay to ship the spec with no built-in
  authentication (the reconfigure key protocol is very limited and too
  weak).  As security/privacy is generally considered to be a critical
  part of any IETF spec today rather than just an optional "nice thing
  to have", I imagine this can be a big concern for the IESG.  If my
  observation is simply incorrect, that's fine; I'm not intending to
  raise this point as a blocking issue.  But if I'm right, it will be
  quite tricky issue.  I don't think it's realistic to introduce a new
  authentication mechanism to rfc3315bis, but then I have no good idea
  on how to address the concern.  My suggestion at this point is to
  consult a security AD sooner than later (i.e., in this last call
  period) to see whether the current approach can be a blocking issue
  or not, and if it is, how we could address it.

- I think overall tone of privacy considerations will have to be
  modernized.  It seems rfc3315bis currently still has the same (maybe
  implicit) assumptions that DHCP(v6) is generally free from privacy
  issues.  As we now all know the trend has been significantly changed
  in the IETF in general, and dhc is not an exception.  I've pointed
  out some specific text on this issue below, but I think it should
  also be considered a general issue.

- I wonder whether we should still keep IA_TA.  I don't know whether
  there's any real-world deployment of it (I personally don't know of
  any.  And, if it's not actually deployed, wouldn't the same argument
  apply as deprecating the delayed authentication protocol?  IA_TA is
  not just (almost or totally) unused, but can also do harm by
  introducing tricky corner cases as we discussed in RFC7550.

- On a somewhat related point, it was not clear to me how much of
  RFC7550 is integrated into rfc3315bis.  In particular, it's not
  clear whether it clearly specifies (and effectively enforces) the
  concept of using a single DHCPv6 session for all IA types.  This is
  another instance that made me think I can only abstain; if I
  actually tried to implement the spec I might be able to know it's
  well already described or identify inconsistency or lack of
  description.  But just by reading this size of doc it's quite
  difficult to tell for sure.

Specific comments on the text follow:

- Section 1

   DHCPv6 is the "stateful address autoconfiguration protocol" and the
   "stateful autoconfiguration protocol" referred to in "IPv6 Stateless
   Address Autoconfiguration" [RFC4862].

  This paragraph isn't necessary anymore and should be removed.
  RFC4862 already just refers to DHCPv6 (there's even no reference to
  the odd phrase of "stateful address autoconfiguration protocol" in
  RFC4862).

- Section 1.1

   number of follow up extensions published over the years.  Several
   notable extensions were published: prefix delegation [RFC3633],
   stateless [RFC3736], update to SOL_MAX_RT and INF_MAX_RT option

  A minor point, but I don't think RFC3736 is an "extension" as the
  RFC pretty clearly says in its abstraction.

- Section 3

   IPv6 Stateless Address Autoconfiguration [RFC4862] specifies
   [...] In addition, the
   protocol interaction by which a node begins stateless or stateful
   autoconfiguration is specified.

  Actually, RFC4862 doesn't specify "the protocol interaction"
  anymore (because we failed to cleanly define how M/O bits work).

- Section 4.1, on the description of "link"

                             IP.  Examples are Ethernet (simple or
                             bridged); Token Ring; PPP and PPPoE links,
                             X.25, Frame Relay, or ATM networks; and
                             Internet (or higher) layer "tunnels", such
                             as tunnels over IPv4 or IPv6 itself.

  This is not incorrect, but the examples include technologies almost
  dead today and now look a bit awkward.  You might want to modernize
  the examples.

- Section 4.1

   link-local address        An IPv6 address having a link-only scope,
                             indicated by having the prefix (FE80::/10),

  You might want to lower-case the prefix (i.e., to "fe80::/10").
  Although not necessarily for cases like RFCs, RFC5952 generally
  recommends to use lower-case letters.  rfc3315bis itself uses
  lower-cased version in other places, so it would at least be better
  to be consistent.

- Section 5.2

   the "stateful address autoconfiguration protocol" for IPv6 [RFC2462].

  s/RFC2462/RFC4862/. In general, unless you have a specific reason for
  referring to the older version all of these references should be
  updated to the latest version.  I won't repeat this sense of
  comment, but there are several other such cases.

- Section 5.4

   [...] the requesting router MUST
   set the valid lifetime in those advertisements to be no later than
   the valid lifetime specified in the IA_PD Prefix option.

  "no later than" sounds awkward as the lifetime is a duration, not a
  particular point in time.

- Section 6.3

   RENEW (5)       A client sends a Renew message to the server that
                   originally provided the client's addresses and [...]

  What about prefixes?  Same for REBIND, and there seem to be other
  cases where the integration of address assignment and prefix
  delegation isn't enough.

- Section 8.1

      link-address         An address that will be used by the server to
                           identify the link on which the client is
                           located.  This is typically global, site-
                           scoped or ULA [RFC4193], but see discussion
                           in Section 18.1.1.

  site-scope unicast address has been deprecated.  Also, the phrase
  "global or ULA" is awkward as ULA is a global (scoped) address.
  You might be interested in draft-carpenter-6man-whats-global-00.

- Section 10

   [...] The DUID is
   designed to be unique across all DHCP clients and servers, and stable
   for any specific client or server - that is, the DUID used by a
   client or server SHOULD NOT change over time if at all possible;

  I guess this property is now changing because of the privacy
  concerns.

- Section 12.1

         [...]  The link address field refers to the link-
         address field of the Relay-Forward message, and the link-
         address fields in any Relay-Forward messages that may be nested
         within the Relay-Forward message.

  I failed to understand this sentence (especially the part after
  "and").  If this is not a wording error, I guess some more
  explanation will be needed.

- Section 12.3

   [...] Each IA_TA
   option contains at most one temporary address for each of the
   prefixes on the link to which the client is attached.

- Section 14

   A client is not expected to listen for a response during the entire
   period between transmission of Solicit or Information-request
   messages.

  I don't understand what this (addition to the original 3315) tries
  to say.

- Section 15.11

   -  the message was not unicast to the client.

  I'm not sure why we bother to say this, and only for Reconfigure.
  Is there any case where a DHCPv6 message to a client isn't unicasted
  at all?

- Section 17.1.1

   [...] In
   the case of a Solicit message transmitted when DHCP is initiated by
   IPv6 Neighbor Discovery, the delay gives the amount of time to wait

  IPv6 ND would not "initiate" DHCP anymore (see also the comment on
  Section 3 above).

- Section 17.1.10.1

      [...] the requesting router
      MUST set the valid lifetime in those advertisements to be no later
      than the valid lifetime specified in the IA_PD Prefix option.

  "no later than" sounds awkward for these lifetimes (see also Sec
  5.4).

- Section 17.1.10.1

  This bullet:

   -  Sends a Request message if any of the IAs in the Reply message
      contains the NoBinding status code.  [...]

  and this sentence seem to contradict each other.

   [...]  This facilitates the client using a single state machine
   for all bindings.

  Specifically, the bullet description seems to lead to multiple
  separate state machines for different bindings.

- Section 17.1.12: why can't we simply use CONFIRM for this purpose?

- Section 17.2.2

   [...]  If the
   reconfigure mechanism is supported, the server is supposed to send
   Authentication option with Reconfigure Key (see Section 19.4 for
   details).

  What if we re-introduce securer authentication (whether it's
  sedhcpv6 or not)?  Should we still keep using Reconfigure Key, which
  contains a private key in plain text?  (see also comment on Section
  19.4)

- Section 17.2.9

   [...]  If the Option Request option includes a container option the
   server MUST include all the options that are eligible to be
   encapsulated in the container.

  Is the term "container option" defined somewhere?  If not maybe it
  should in the terminology section.

- Section 17.2.9: incomplete sentence (or perhaps just a missing period)

   server MUST NOT include this address or delegated prefix in the
   Advertise message

- Section 18.1.1

   If the relay agent received the message to be relayed from a client,
   the relay agent places a global, ULA [RFC4193] or site-scoped address
   with a prefix assigned to the link on which the client should be
   assigned an address in the link-address field.

  s/global, ULA [RFC4193] or site-scoped/global/ (see comment on Sec 8.1)

- Section 18.1.1

   [...]  If not addresses of
   other scopes are available the relay agent may fill in the link-
   address field with a link-local address from the interface the
   original message was received on.  That is not recommended as it

  s/If not/If no/ (?)
  Also, the term 'other scopes' sounds awkward with deprecation of
  unicast site-local.  I suggest: 'If no global address is available..."

- Section 18.1.2

   If the source address from the IP datagram header of the received
   message is a global or site-scoped address (and the device on which

 s/global or site-scoped/global/ (see above)

- Section 19.1

                           [...]  The information in DHCP messages is
                           not generally considered confidential, so
                           encryption need not be used (i.e., NULL
                           encryption can be used).

  This doesn't seem to reflect the our consensus accurately (always
  enabling encryption in sedhcpv6).  I'm not saying rfc3315bis should
  define DHCPv6 encryption, but I believe general statement like this
  should be consistent with our latest view (or at least not
  clearly inconsistent with it).

- Section 19.1

      Key management       Because the relay agents and servers are used
                           within an organization, public key schemes
                           are not necessary.  Because the relay agents

  This argument sounds weak.  With that logic we should also be able
  to say public key schemes are not necessary between clients and
  servers.  Perhaps the real intent is that both relay agents and
  servers tend to be managed by the same administrator (or admin
  group) so managing shared secret is acceptable?

- Section 19.4

   The Reconfigure Key protocol is used (initiated by the server) only
   if the client and server are not using any other authentication
   protocol and the client and server have negotiated to use Reconfigure
   messages.

  This statement now sounds awkward since this is now the only defined
  authentication protocol. (see also comment on Section 17.2.2)

- Section 20.4

      IAID                 [...] The number
                           space for IA_NA IAIDs is separate from the
                           number space for IA_TA IAIDs.

  This should also list IA_PD IAIDs.  Same for IAID of other types of
  IAs.

- Section 20.4

   In a message sent by a client to a server, the T1 and T2 fields
   SHOULD be set to 0.  The server MUST ignore any values in these
   fields in messages received from a client.

  With this, this doesn't make sense to me:

   If a server receives an IA_NA with T1 greater than T2, and both T1
   and T2 are greater than 0, the server ignores the invalid values of
   T1 and T2 and processes the IA_NA as though the client had set T1 and
   T2 to 0.

  Shouldn't the first para simply say the server MUST ignore these
  values whatever they are?  Then the second para is simply redundant;
  if not, and if the second para means the server can accept such
  non-0 T1/T2 as long as T1 <= T2, then it's not consistent with the
  first para.

- Section 20.6

      IPv6 address         An IPv6 address.

  Maybe we should note that no "associated prefix length" is implied
  for this address, and, in particular, that clients MUST NOT assume
  any length of prefix that matches this address is on-link, referring
  to RFC7421.

- Section 20.6

   [...]  A server [...]
   and ignores the values for T1 and T2 set by the client if
   those values are greater than the preferred lifetime.

  The 'if' condition seems unnecessary (see comment on 20.4) or
  perhaps the whole "and ignores..." part is unnecessary.

- Section 20.7

   encapsulated in the container MUST NOT by in the Option Request, see

  s/MUST NOT by/MUST NOT/ (?)
  s/Option Request/Option Request option/

- Section 20.21

   If a delegating router receives an IA_PD with T1 greater than T2, and
   both T1 and T2 are greater than 0, the delegating router ignores the
   invalid values of T1 and T2 and processes the IA_PD as though the
   requesting router had set T1 and T2 to 0.

  So is it okay for a delegating router to accept non-0 T1 or T2?  If
  so, why it's different from the "first para" I referred to in my
  comment on Section 20.4 (see above)?

- Section 20.22

   In a message sent by a delegating router the preferred and valid
   lifetimes should be set to the values of AdvPreferredLifetime and
   AdvValidLifetime as specified in section 6.2.1, "Router Configuration
   Variables" of [RFC2461], unless administratively configured.

This choice of valid/preferred lifetime in an IA prefix and the
(possible) relationship between them and those lifetimes advertised in
the delegated site do not make perfect sense to me.  Consider a
requesting router which has an upstream interface, I1, on which PD is
performed, and a downstream interface I2, to which it sends router
advertisements for end hosts.  Unless there's a specific reason to use
different values, I'd expect valid and preferred lifetimes in the
router advertisement sent out from I2 to be AdvValidLifetime (30 days)
and AdvPreferredLifetime.  I'd also expect they do not change in
subsequent RAs unless prefix renumbering is taking place.

But it's not impossible if we strictly honor the sense of the IA
prefix lifetimes, since the lifetimes are (effectively) decreasing to
0 until the next Renew-Reply exchange, and, logically, lifetimes of
the RA can't be larger than the lifetimes of the "site prefix".

So I think the recommended lifetimes of an IA prefix should at least
take into account some margin for the duration until the next renew.
It would also be better if we clarify the relationship between these
two types of lifetimes more explicitly, but one might think it's
beyond the scope of the base DHCPv6 protocol spec.

- Section 20.22

   A delegating router [...] and ignores the values
   for T1 and T2 set by the requesting router if those values are
   greater than the preferred lifetime.

Same comment as that for 20.21 applies.

- Section 20.23

   A DHCP client MUST include the SOL_MAX_RT option code in any Option
   Request option (see Section 20.7) it sends.

  I don't understand the need for this MUST.  If it's a MUST, can't
  the server simply assume as if it were actually included in an
  option request option and respond accordingly?  Or, perhaps it's for
  distinguishing legacy implementations that don't support the
  SOL_MAX_RT option from newer ones? (If so, I think it's worth noting
  explicitly; otherwise some other people may wonder the same point).

- Section 20.23

   If a DHCP client receives a message containing a SOL_MAX_RT option
   that has a valid value for SOL_MAX_RT, the client MUST set its
   internal SOL_MAX_RT parameter to the value contained in the
   SOL_MAX_RT option.

  The expected usage is not very clear to me here.  Is it intended to
  be used for Advertise and apply the value to the ongoing
  Solicit-Advertise exchange?  Or is it mainly intended to be used for
  a possible subsequent restart of a DHCPv6 session?

- Section 21

   Because a requesting router and delegating routers must each have at
   least one assigned IPv6 address, the routers may be able to use IPsec
   for authentication of DHCP messages.

  The statement in the "because" clause seems too strong to me.
  (Assuming a link-local address is not an "assigned IPv6 address" in
  this context) isn't it completely possible that a requesting router
  bootstraps just with a link-local address, starting a fresh DHCPv6
  session to get IAPD (and maybe IANA for its own address)?  Then
  "must each have at least one assigned IPv6 address" does not always
  hold.

- Section 22: s/It/In/

   [RFC7824].  It particular, Section 3 of said document discuss various

- Appendix A: I strongly suggest this be kept with substantial revise,
  instead of just instructing the RFC editor to remove it.
  See https://www.ietf.org/mail-archive/web/dhcwg/current/msg17524.html

--
JINMEI, Tatuya