Re: [mif] Comments on mif-pvd-arch

[Dmitry Anipko <[e-mail]>]

Hello Alper,

Thank you for the comments.

>> Default IP gateway deserves to be mentioned here.

I believe this topic was raised during the last meeting (in the context of single RA having info on multiple PVDs), and it seems to me there was an agreement that it is a valid requirement, though not fully clear to me, whether it can be implemented w/o protocol changes / new options (but perhaps, the latter doesn't have to be discussed in the arch doc). I can add this text in the next revision, though I want to note, that it might re-open the controversy of "DHCP route option".

>> 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.

I'll clarify this.

>> 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.

If you're referring to the advertisement of different info to different nodes, is there a specific text you'd suggest to be included as opposed to the current out-of-scope?

>> This is already available with RA and DHCP today.

Can you suggest a specific reference to the corresponding mechanisms in RA/DHCP?

>> 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?

There is at least one way, in which the host could avoid ambiguity - use a specific PVD, per configured policy, for particular destinations, and use one at a time for generic Internet (for example, based on available connectivity cost information)****. I can add a reference to that as an example, if you think that helps.  Outside of that, I think we won't converge in this document, if we try to prescribe a particular host behavior, to fully cover complicated cases, because different hosts may have different business needs.

The original problem had multiple parts. One part is that w/o information from the network, it's generally not  possible to know, which network configuration elements are OK to be used together, and which aren't. The explicit MPVDs, in my opinion, first of all solve this problem. After that it is still up to the host, how exactly they want to use the multiple connections that they have - but now they can do it in a more structured way.

>> 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...

Not necessarily, in some cases, it could be a proxy server, or a policy, which prescribes, that for a VOIP app, the particular network should be used. DNS is just an example (which would be the common case). In those cases, where DNS is relevant, the PVD, from which the DNS server is taken, could be selected based on the mechanism such as above (see ****).

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

Do you believe the specific mechanisms would belong to the arch doc? If there are particular examples, which are common, we could mention them as examples.

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

It is expected that ~80% of apps, if not more, would fall into this category, and hence it is important to call out the category.

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

I'll add a couple of sentences with example requirements.

>> 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.

IMO, PVD makes a difference, because the original source of PVD info is potentially different from the router/DHCP server. So I agree with you, and I think this is an open issue, for which I personally don't know a good solution at this time.

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

Can you provide a bit more elaborated text?

-Dmitry

From: mif [mailto:[e-mail]] On Behalf Of Alper Yegin
Sent: Monday, March 24, 2014 3:02 AM
To: [e-mail]
Subject: [mif] Comments on mif-pvd-arch

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