[mif] AD review of MPVD Architecture

[Ted Lemon <[e-mail]>]

I'm sorry this has taken so long.   It got lost in the tracker, only to surface just as an unrelated cluster of documents was soaking up a lot of my time.   I am very excited to get this document to the IESG, so please don't take this delay as being indicative of a lack of interest.   On to the comments:

This is a bit hard to parse, and I suggest the following change:
OLD:
   3.  Usage of a particular network that is not consistent with the
       intent of the scenario or involved parties leading to
       connectivity failure and / or other undesired consequences.
NEW:
   3.  Use of a particular network that is not consistent with the
       intended use of the network, or the intent of the
       communicating parties, leading to connectivity failure
       and / or other undesired consequences.

What's the rationale for the third sentence in the paragraph below?

   In some network topologies, network infrastructure elements may need
   to advertise multiple PvDs.  Generally, the details of how this is
   performed will be defined in companion design documents.  However,
   where different design choices are possible, the choice that requires
   a smaller number of packets shall be preferred for efficiency.

I ask because I think this is DISCUSS fodder: someone is going to want details.   If it's important, let's keep it and defend it.   If it's more of an aside, let's get rid of it.

Difficult to parse:
OLD:
   For some time it is likely that there will be networks which do not
   advertise explicit PvD information as the deployment of new features
   in networking protocols is a relatively slow process.
NEW:
   For the foreseeable future, there will be networks which do not
   advertise explicit PvD information, because deployment of new
   features in networking protocols is a relatively slow process.

I think the last sentence in this paragraph serves two purposes, and would be better separated:
OLD:
   Through the use of implicit PvDs, PvD-aware nodes may still provide
   benefits to their users (when compared to non-PvD aware nodes) by
   following the best practices described in Section 5, using the
   network information from different interfaces separately to
   consistently serve network connection request.
NEW:
   Through the use of implicit PvDs, PvD-aware nodes may still provide
   benefits to their users (when compared to non-PvD aware nodes) by
   following the best practices described in Section 5.

   PvD-aware nodes shall treat betwork information from different
   interfaces, which is not identified as belonging explicitly to some
   PvD, as belonging to separate PvDs, one per interface.

The reason I propose this is that the last paragraph in the section imposes an explicit requirement on PvD-aware nodes that they separate out PvD-labeled and non-PvD-labeled information into explicit and implicit PvDs, but the section as a whole never explicitly states a requirement that information from different interfaces that is not labeled is treated as belonging to separate PvDs.   Whether this change as taken as I have made it, or done some other way, I think you need to state a requirement for both cases.

The last paragraph in the section also doesn't parse very well:
OLD:
   In mixed mode, i.e., where of multiple networks are available on an
   attached link only some of which advertise PvD information, the PvD-
   aware node shall create explicit PvDs from explicitly learned PvD
   information and associate other learned configuration (without an
   explicit PvD) with implicit PvD(s) created for that interface.
NEW:
   Implicit PvDs can also occur in a mixed mode, i.e., where of multiple
   networks that are available on an attached link, only some advertise
   PvD information.  In this case, the PvD-
   aware node shall create explicit PvDs from information explicitly 
   labeled as beloinging to PvDs.   It shall associate 
   configuration information not labeled with an explicit PvD with
   an implicit PvD created for that interface.

(Is there a case where two implicit PvDs would be created on the same interface?)

This seems a bit too definite to me:
OLD:
   Explicit PvDs, in practice will often also be scoped only for
   configuration related to a particular interface.  However, there are
   no such requirements or limitations defined in this architecture.
NEW:
   In the simplest case, explicit PvDs will be scoped for
   configuration related only to a specific interface.  However, 
   there is no requirement in this architecture for such a
   limitation.

I don't know what "generally" means here, suggest you delete it:
   generally, authentication of a PvD ID
   may be also required in scenarios involving only one connected
   interface and / or PvD

You could take out some equivocating here:
OLD:
   This architecture intends to support such scenarios, among others.
   Hence, it shall be noted that no hierarchical relationship exists
   between interfaces and PvDs: it is possible for multiple PvDs to be
   simultaneously accessible over one interface, as well as a single PvD
   to be simultaneously accessible over multiple interfaces.
NEW:
   This architecture supports such scenarios.
   Hence, no hierarchical relationship exists
   between interfaces and PvDs: it is possible for multiple PvDs to be
   simultaneously accessible over one interface, as well as a single PvD
   to be simultaneously accessible over multiple interfaces.

I think you need a signature, not an authorization token, here:
   To resolve this, there must be
   a mechanism for the PvD owner to attach some form of authorization
   token to the configuration information that is delivered.

I don't remember the details of the discussion we had anymore, but the issue with a token is that it doesn't actually solve the problem of proving that the PvD information supplied is actually associated with the named PvD.   Having said this, I know the working group thought about this, and I'm not proposing to change the consensus.   If the term "token" was preferred over "signature", it's fine to leave it that way and duke it out during IESG review. :)

This doesn't make sense:
   One way to
   restrict the propagation of information which is of no use to a
   specific host is for the host to indicate the PvD information they
   require within their configuration request.  One way this could be
   accomplished is by using a DHCPv6 ORO containing the PvDs that are of
   interest.  The configuration source can then respond with only the
   requested information.

The ORO just lists options.   There's no way to name a PvD.   I vaguely recall that the idea here was to provide a per-PvD ORO, not list PvDs in the ORO.

Do you really want to advocate the use of shared-secret authentication of PvD identities?   This would mean that any node that can authenticate the assertion of the PvD identity can also spoof it:

   One way to validate the trust relationship between a node and the
   source of a PvD is through the combination of cryptographic
   authentication and an identifier configured on the node.  In some
   cases, the two could be the same; for example, if authentication is
   by a shared secret, the secret would have to be associated with the
   PvD identifier.  Without a PvD Identifier / shared key tuple,
   authentication would be impossible, and hence authentication and
   authorization are combined.

Slight clarification called for here:
   Rogue configuration source: A compromised configuration source, such
      as a router or a DHCPv6 server, may advertise information about
      PvDs that it is not authorized to advertise.  e.g.  A coffee shop
      WLAN may advertise configuration information purporting to be from
      an enterprise and may try to attract enterprise related traffic.
      The only real way to prevent this is is for the PvD related
      configuration container to contain embedded authentication and
      authorization information from the owner of the PvD. This provides
      the client with a way of detecting the attack by verifying the
      authentication and authorization information provided inside the
      PvD container option, after verifying its trust of the PvD owner
      (e.g.  a certificate with a well-known / common trust anchor).

What prevents this attack is not the provision of authentication information, but an explicit configuration on the client to reject this PvD if it is _not_ authenticated.   The way you've stated it, it's fairly obvious that that's the case, but you don't actually say so.