Re: [mif-arch-dt] New Version Notification for draft-anipko-mif-mpvd-arch-00.txt

[Ted Lemon <[e-mail]>]

Observations about the document:

In section 2, I think you should say "classically" rather than "usually," because I think "usually" is true right now, but probably won't be in the future.   There's probably a better way to put it, but that's the point I think needs to be gotten across.

I think also that the beginning of section 2 doesn't quite capture the definition of PVD because of the classical approach.   It might be better not to focus on that, and just talk about it in terms of a collection of information.

So maybe something like this:

   Provisioning Domain: a consistent set of network configuration
   information.  Classically, the entire set available on a single interface
   is provided by a single source, such as network administrator, and
   can therefore be treated as a single provisioning domain.   In modern
   IPv6 networks, multihoming can result in more than one provisioning
   domain being present on a single link.

   Typical examples of information in a provisioning domain, learned
   from the network, are:
   source address prefixes used on the link, IP address of DNS
   server, name of HTTP proxy server if available, DNS suffixes
   associated with the network etc.

   In some cases, other sources, such as e.g.  node local
   policy, user input or other out of band mechanisms may be used to either
   construct a PVD entirely (analogously to static IP configuration of
   an interface), or supplement with particular elements all or some
   PVDs learned from the network.

   As an example, node administrator
   could inject a not ISP-specific DNS server into PVDs for any of the
   networks the node could become attached to.  Such creation /
   augmentation of PVD could be static or dynamic.  The particular
   implementation mechanisms are outside of the scope of this document.

   PVD-aware node: a node that supports association of network
   configuration information into PVDs, and using the resultant PVDs to
   serve requests for network connections in a way, consistent with
   recommendations of this architecture.

In 4.2.1, I suggest the following change:
OLD:
   In either case, by default the node shall use for the following
   connection request the PVD, where the lookup results were obtained.
NEW:
   In either case, by default the node uses information obtained in
   a name service lookup to establish connections only within the
   same PVD from which the lookup results were obtained.

   For simplicity, when we say that name service lookup results were
   obtained from a PVD, what we mean is that the name service query
   was issued against a name service the configuration of which is
   present in a particular PVD.   In that sense, the results are
   "from" that particular PVD.

In 5.1, maybe the following change?
OLD:
   Applications are not PVD-aware in any manner, and only submit
   connection requests.  The node performs PVD selection implicitly,
   without any otherwise applications participation, and based purely on
   policies and/or user choice.
NEW:
   Applications are not PVD-aware in any manner, and only submit
   connection requests.  The node performs PVD selection implicitly,
   without any otherwise applications participation, and based purely on
   node-specific administrative policies and/or choices made by the user
   in a user interface
   provided by the operating environment, not by the application.

I'd like to see more text talking about the user interface aspect of this.   Section 5.3 suggests that the information configured by local policy or user interface is not visible to the application.   This is probably correct, but needs to be explored in more detail, IMHO.

I would suggest the following for the trust section, since there's no text yet:

6.1 Untrusted PVDs

   Implicit and explicit PVDs for which no trust relationship exists
   are considered untrusted.   Only PVDs which meet the requirements in
   section 6.2 are trusted; any other PVD is untrusted.

   In order to avoid various forms of misinformation that can be asserted
   when PVDs are trusted, hosts that implement PVD separation cannot assume
   that two explicit PVDs with the same identifier are actually the same PVD.
   A node that did make this assumption would be vulnerable to attacks where
   for example an open Wifi hotspot might assert that it was part of a well
   known PVD, and thereby draw traffic intended for that PVD onto its own
   link.

   Since implicit PVD identifiers are synthesized by the node, this issue
   cannot arise with implicit PVDs.

   Mechanisms exist (for example [RFC6731]) whereby a PVD can
   provide configuration information that asserts special knowledge about
   the reachability of resources through that PVD.   Such assertions
   cannot be validated unless the node has a trust relationship with
   the PVD; assertions of this type therefore must be ignored by
   hosts that receive them from untrusted PVDs.   Failure to ignore
   such assertions could result in traffic being diverted from legitimate
   destinations to spoofed destinations.

6.2 Trusted PVDs

   Trusted PVDs are PVDs for which two conditions apply.   First, a trust
   relationship must exist between the node that is using the PVD configuration
   and the operator that provided that configuration; this is the authorization
   portion of the trust relationship.   Second, there must
   be some way to validate the trust relationship.   This is the authentication
   portion of the trust relationship.   Two mechanisms for
   validating the trust relationship are defined.

6.2.1 Authenticated PVDs

   One way to validate the trust relationship between a node and the
   operator 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
   done with 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.

   However, if authentication is done using
   some public key mechanism such as a TLS cert or DANE, authentication
   by itself isn't enough, since theoretically any PVD could be
   authenticated in this way.   In addition to authentication, the node
   would need to be configured to trust the identifier being authenticated.
   Validating the authenticated PVD name against a list of PVD names
   configured as trusted on the host would constitute the authorization
   step in this case.

6.2.2 PVDs trusted by attachment

   In some cases a trust relationship may be validated by some means
   other than described in 6.2.1, simply by virtue of the connection
   through which the PVD was obtained.   For instance, a handset connected
   to a mobile network will know through the mobile network infrastructure
   that it is connected to a trusted PVD, and whatever mechanism was used
   to validate that connection constitutes the authentication portion of
   the trust relationship.   Presumably such a handset would be configured
   from the factory, or else through user preference settings, to trust
   the PVD, and this would constitute the authorization portion of this
   type of trust relationship.

That's all I've got for today—I hope it helps.   Thanks for writing this up!