[mif] Comments on mif-pvd-arch

[Alper Yegin <[e-mail]>]

Helo folks,

I went over the draft, and here are my comments:

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

Default IP gateway deserves to be mentioned here.


   Implicit PVDs are limited to network configuration information
   received on a single interface.  Explicit PVDs, in practice will
   often also be scoped to a configuration related to a particular
   interface, however per this architecture there is no such requirement
   or limitation and as defined in this architecture, explicit PVDs may
   include information related to more than one interfaces, if the node
   learns presence of the same PVD on those interfaces and the
   authentication of the PVD ID meets the level required by the node
   policy.

This text mentions auth in the context of using PVD ID across multiple interfaces, as if the auth issue only arises in that case.
Auth/z issues arise even with single PVD over single interface case. 


   Possible extensions, where different sets of PVDs may be advertised
   by the networks to different connected nodes, are out of scope of
   this document.

Yes, we can declare this out-of scope for this document. But this (s/PVDs/configuration parameters) in fact is very doable, and commonly used in wireless networks.


   After the PvD information is provided to the host it may be outdated
   or updated with newer information before the hosts would normally
   request updates.  Thos would require the mchanism to be able to
   update and/or withdraw all (or some subset) of information related to
   a given PvD. For efficiency reasons, there should be a way to specify
   that all the information from the PvD needs to be reconfigured
   instead of individually updating each item associated with the PvD.

This is already available with RA and DHCP today.



   The node may pick multiple PVDs, if e.g., they are general purpose
   PVDs providing connectivity to the Internet, and the node desires to
   maximize chances for connectivity in Happy Eyeballs style.  In this
   case, the node could do the lookups in parallel, or in sequence.
   Alternatively, the node may use for the lookup only one PVD, based on
   the PVD connectivity properties, user choice of the preferred
   Internet PVD, etc.


This is not trivial. If using serial lookup, how is the order determined?
If using parallel lookup, one can get multiple answers, in which case how does the selection work?
In either case, are we not back to the original problem?


   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.

So, the DNS server used for lookup dictates where the rest of the config parameters come from.
Now, how we select the DNS server to use becomes the key issue…


   An attempt to use such PVD may lead to limited network connectivity
   or connection failures for applications.  To prevent the latter, a
   PVD-aware node may perform connectivity test for the PVD, before
   using it to serve network connection requests of the applications.
   In current implementations, some nodes do that, for instance, by
   trying to reach a dedicated web server (e.g., see [RFC6419]).


Given the current practices in the industry, do we still need something standardized?


6.1 Basic (API) is more of a "No API support" (as in legacy apps case).



6.2.  Intermediate

   Applications indirectly participate in selection of PVD by specifying
   hard requirements and soft preferences.  The node performs PVD
   selection, based on applications inputs and policies and/or user
   preferences.  Some / all properties of the resultant PVD may be
   exposed to applications.


Can someone provide examples of requirements/preferences, for the sake of discussion and also elaboration in the text?



7.2.2.  PVDs trusted by attachment

Not that I expect this to be written down in the draft, but I think this'd have more applicability than the PSK and CERT-based approaches. Even DHCP is secured this way today (not via DHCP AUTH).



      Tampering with configuration information provided An attacker may
      attempt to modify the information provided inside the PVD
      container option.

Is this exactly the same threat we are seeing today with the RA and DHCP, or is the introduction of PVD-ID making a difference?
I think there is a difference, because PVD-ID is making a claim that "the following parameters are coming from Operator X". Which can be leveraged for worse attacks.


      Replay attacks A compromised configuration source or an on-link
      attacker may try to capture advertised configuration information
      and replay it on a different link or at a future point in time.
      This can be avoided by including some replay protection mechanism
      such as a timestamp or a nonce inside the PvD container to ensure
      freshness of the provided information.

Or by a (crypto) binding between the L1/L2 and the configuration parameters.


Thank you Dmitry and the other folks who contributed to this I-D.

Cheers,

Alper