Subject: Re: [mif] next step for MIF PVD configuration

From: Margaret Cullen <[email-masked]>
Date: Wed, 2 Mar 2016 07:48:02 -0500

Hi Stepjan,

On Feb 29, 2016, at 8:26 AM, Stjepan Groš <[email-masked]> wrote:

> Hi all!
> 
> On 29.02.2016 11:21, Hui Deng wrote:
>> Hello all
>> 
>> We had the concensus already about droping DHCP MPVD ID document, 
>> based on this, here chairs would like to understand whether MIF WG
>> has achieved the concensus on below two steps to deliver MPVD conf.
>> 1) step 1: using RA to get MPVD ID information
>> 2) step 2: using DNS to get other MPVD configuration.

There has been previous mention on the list regarding this two-step approach, although it did not use that terminology -- in the minutes from Yokohama, it has been previous referred to as an "offline mechanism".  It was discussed in the minutes from Yokohama which were posted to the list.  During the meeting, we reached consensus of those int he room that we should use RAs to identify an explicit PVD, and that we should use an offline mechanism to get further PVD information.

The MIF WG minutes from the last meeting can be round here:
https://www.ietf.org/proceedings/94/minutes/minutes-94-mif) 

There is currently one proposal for an offline mechanism, the MPVD DNS proposal (draft-stenberg-mif-mpvd-dns).  It was also presented in Yokohama.  There seemed to be general agreement in the room that a DNS approach would be workable, but there were concerns raised about the specific proposal in this document (use of TXT records, etc.).

At this point we are trying to see if we can recharter the group to work on a two step proposal for PVD configuration using RAs and using DNS as the offline mechanism for further PVD configuration.  That is the "two-step approach" that is being referred to here.

> 
> Since I didn't saw any discussions on this list about those proposals I have few questions/comments:
> 
> 1. Is this only for IPv6, or it is for IPv4 too (step 2)?

A DNS lookup could be used for IPv4 or IPv6.  Right now, though, there has only really been discussion of how a host could get it's explicit PVD ID (which would most likely be needed for the lookup) from an IPv6 RA.  It is possible that we could define a way for an IPv4 host to get it's PVD ID, but the IPR on using DHCP for this makes that somewhat challenging.

> 2. Why only MPVD ID in RA? Why not other information too for which RA is a natural place to be?

There has been a great deal of concern expressed about adding all sorts of different configuration information into RAs.  In fact, currently RAs don't even contain enough information to do a secure DNS lookup, as they are missing an NTP configuration option.

There was consensus in the room that it would be better to get the PVD ID from an RA and use a second step to look up the full PVD configuration information.  the only current proposal for that second step is to do it via DNS.

> 3. Why turn DNS into a local network configuration protocol?

Well, there is an extent to which DNS is already used for these things via SRV records, TXT records, etc.  However, I do see your point to some extent…  What would you use propose that we use instead?

Margaret

---

From: Margaret Cullen <[email-masked]>
Date: Wed, 2 Mar 2016 07:50:06 -0500

Hi Stepjan,

Margaret

---

From: Stjepan Groš <[email-masked]>
Date: Thu, 3 Mar 2016 12:47:00 +0100

Hi Margaret,

Thank you for the clarification/answer. I read the documents you were
referring to and here are my comments.

> There is currently one proposal for an offline mechanism, the MPVD DNS proposal (draft-stenberg-mif-mpvd-dns).  It was also presented in Yokohama.  There seemed to be general agreement in the room…

In the given draft two use cases are mixed into one. The first one is
for the discovery of services available. It is a valid use case for a
DNS (side question, can DNS-SD already do what this draft describes,
could SDP be (re)used?). The other one is the configuration data that
the client should use to configure itself, this is IMHO not a valid use
case for DNS service. The additional reason why not is that, for
example, RA allows asynchronous notification about changes in the
network parameters, while DNS doesn't. This mixes TTL into the equation.
TTL values in RA are relatively large, larger that in DNS. I suspect
that there could be some tricky issues too.

As a side note, when we talk about QoS characteristics of discovered
services, the draft offers one possible approach. But it is an
interesting question would this be enough. IMHO, for some it would, for
others it won't. For example, draft anticipates user visible PvD name
but this doesn't mean a lot. Maybe some service provider wants to
provide more elaborate description or something else. Also, there is a
problem of a composition of different access methods. If both say they
are fast, it might easily be that they aren't identical but due to the
shortcomings of the description "language" they can not be
differentiated. And if you include security into the mix, things start
to complicate quickly. Anyway, one possible solution would be to provide
URL that might be used to fetch description of a service/PvD which can
be in different forms (depending on one's particular needs) and thus
more likely to satisfy (almost) everyone. Also, this URL based access
might be a better in case you want to do a per-user configuration
because in the higher layers you have user's identity on your disposal
which might not be available to DNS server and/or resolver code.

And while we are at access control, DNS servers usually serve all data
from their databases to any client that asks them. If you introduce
local network specific information into DNS, how would you restrict
access to this data? Of course, it can be solved, almost everything can,
but needles to say, it complicates things.

Finally, obviously this solution assumes a single DNS server from one
ISP will provide all the data about PvDs. If you have two or more ISPs
and expect them to be collaborative is nice thing to hope for, but in
case they don't user is stuck. And even if they collaborate, that
neither scales nor is responsive.

> A DNS lookup could be used for IPv4 or IPv6.  Right now, though, there has only really been discussion of how a host could get it's explicit PVD ID (which would most likely be needed for the lookup…

IMHO, having only PVD ID in DHCP is _much_ closer to what IPR claim is
about than to have all the configuration data.

But, isn't this something that DHC WG should discuss and decide?

Actually, DHC WG should also solve a problem of two or more _concurrent_
DHCP servers on a local network. And by solving that use case, it might
also get around IPR claim (if its an issue at all).

> There has been a great deal of concern expressed about adding all sorts of different configuration information into RAs.  In fact, currently RAs don't even contain enough information to do a secure…

Maybe I'm missing something, but IMHO not much is necessary in terms of
options when we talk about PvDs: one option, PvD CO (which can be PvD ID
in the same time) and that's it. Of course, distinction has to be kept
between node configuration (for which RA is used) and service discovery
(for which RA isn't appropriate and which might explode number of
necessary options).

Note that there is also possibility to use RS to explicitly ask for PvDs
(specific one or all available), i.e. they aren't sent in "regular" RAs.
I don't know if this was explored, but in NDP draft it isn't mentioned.

As for the missing information to make DNSSEC to work, I suppose that's
something that's not the problem this WG should solve.

> There was consensus in the room that it would be better to get the PVD ID from an RA and use a second step to look up the full PVD configuration information.  the only current proposal for that sec…

There is already a second step for RA, it is DHCP and it is already
implemented and works for years now.

Not to mention that into already complex mix of configuration mechanisms
(from operational perspective) additional one is introduced which has a
host of its own problems (security issues, and slow adoption of DNSSEC).

And while I'm talking about OP perspective, there are host of other
configuration protocols already (RADIUS, DIAMETER, PPP, VPN specific
ones). Is it really necessary to introduce yet another one into the mix?

> Well, there is an extent to which DNS is already used for these things via SRV records, TXT records, etc.  However, I do see your point to some extent…  What would you use propose that we use inste…

SRV as I said, is for service discovery, not node configuration. So its
not good analogy. The same goes for DNS-SD, which is also for service
discovery as the name implies.

DHCP was designed to do a local network configuration and I think that
DHC WG should be asked to solve the IPR problem. There are already some
options that might invalidate, or at least work around IPR claim, like
DHCPv4-over-DHCPv6 which encapsulates all configuration parameters
within a single option, different domain names (NIS, KRB), etc.

In the end, let mi conclude that I somehow suspect that my opinion will
change anything, but I'm nevertheless strongly opposed to the direction
WG is taking.

SG

P.S. I tried to ask on NetworkManager list for their opinion about all
this, but unfortunately received no answer.  That would be very valuable
input.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Mar 2016 13:48:14 +0100 (CET)

> neither scales nor is responsive.

I re-read draft-stenberg-mif-mpvd-dns-00 . It's not obvious to me if the 
PvD information is globally available for anyone to ask (or not), or if 
there is a requirement for some kind of split horizon DNS view where you 
need to ask from an address within the PvD to actually get an answer back 
regarding the PvD.

I have doubts about the DNS method, and I would prefer to have some kind 
of other mechanism to distribute the PvD information.

What about having one more level of indirection (yeah, yeah, I know, RFC 
1915 6a), and instead find the configuration resource via some kind of SRV 
record either available via DNSSD or via PTR .arpa lookup, or via DHCP 
option? Then the information could be fetched using HTTPS or some other 
mechanism.

draft-ietf-netconf-zerotouch-04 uses these kinds of mechanisms to provide 
data, where you instead sign the configuration data that can be downloaded 
through insecure means, but you won't use it until you've verified its 
authenticity (for instance by doing lookups using DNSSEC to get 
certificate ID or similar).

I also would like to separate the mechanism(s) how the information is 
transmitted and what information we want to transmit. These discussions 
are very different, and the mechanism how to transmit the information is 
probably not going to be changed that much, whereas we might want to add 
information we want to transmit more frequently.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Margaret Cullen <[email-masked]>
Date: Sat, 12 Mar 2016 19:10:00 -0500

Hi Mikael,

I agree with some of the issues you have raised about the current draft for DNS lookups of PVD information.  I think that if we go with a DNS-based approach, we will need to do some work on the DNS mechanism to fix these sorts of issues.

Do you have time to write a draft for the mechanism you have suggested, so that we can discuss it in the group?

Margaret

On Mar 4, 2016, at 7:48 AM, Mikael Abrahamsson <[email-masked]> wrote:

>> Finally, obviously this solution assumes a single DNS server from one ISP will provide all the data about PvDs. If you have two or more ISPs and expect them to be collaborative is nice thing to hope for, but in case they don't user is stuck. And even if they collaborate, that neither scales nor is responsive.
> 
> I re-read draft-stenberg-mif-mpvd-dns-00 . It's not obvious to me if the PvD information is globally available for anyone to ask (or not), or if there is a requirement for some kind of split horizon DNS view where you need to ask from an address within the PvD to actually get an answer back regarding the PvD.
> 
> I have doubts about the DNS method, and I would prefer to have some kind of other mechanism to distribute the PvD information.
> 
> What about having one more level of indirection (yeah, yeah, I know, RFC 1915 6a), and instead find the configuration resource via some kind of SRV record either available via DNSSD or via PTR .arpa lookup, or via DHCP option? Then the information could be fetched using HTTPS or some other mechanism.
> 
> draft-ietf-netconf-zerotouch-04 uses these kinds of mechanisms to provide data, where you instead sign the configuration data that can be downloaded through insecure means, but you won't use it until you've verified its authenticity (for instance by doing lookups using DNSSEC to get certificate ID or similar).
> 
> I also would like to separate the mechanism(s) how the information is transmitted and what information we want to transmit. These discussions are very different, and the mechanism how to transmit the information is probably not going to be changed that much, whereas we might want to add information we want to transmit more frequently.
> 
> --
> Mikael Abrahamsson    email: [email-masked]
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif