Subject: [dnssd] Example Use Cases (was Re: Rechartering)

From: "R. Atkinson" <[email-masked]>
Date: Fri, 20 Jul 2018 12:44:47 -0400

I’d like to talk a little bit about use cases relating to both mDNS & DNS-SD.

This is mostly prompted by the rechartering slides (which I read online,
although I have not been in Montreal for IETF this week).

These are partly baked thoughts, written in haste, so are incomplete
and probably have typing/editing errors in places.

1. ZeroConf / No Infrastructure Case

   In my experience as a user and as a consultant, is that most (non-IETF :-)
   residences and most small-businesses fundamentally want a zero 
   configuration network.  The outer limit of what they might view as 
   acceptable infrastructure is enabling a DHCP server (facing to the interior) 
   on a (small) site border router that uplinks to some ISP. 

   These sites have viewed the “magic” appearance of “it just works” 
   mDNS + DNS-SD as a huge win — a win that they really do not want
   to lose.  The main application benefit I see is printer discovery, but 
   there are other services that do get advertised and also get used
   via the existing widely deployed mDNS + DNS-SD combination.
   (Again, their preference is for a Zero Configuration network, even if
    that means a less secure interior network deployment.)
   
   In this environments, the site border router typically just learns its IP address
   and other configuration (e.g. ISP’s DNS resolvers) by running a DHCP/DHCPv6
   client on the exterior router interface and trusting the ISP’s DHCP reply.
   The same router runs a DHCP/DHCPv6 server on the interior interface,
   and the router’s DHCP replies carry along DNS resolver information learned
   from the DHCP client on its exterior interface.  The site does not itself
   have a DNS server or even its own DNS resolver.

   In these environments, I rarely see any servers within a small business.
   They might have a web site and email, but those often are outsourced
   to someone other than their ISP.  Email very often is really web-based email.
   If they happen to have their own domain name (example.com), they
   usually are NOT running the DNS name server for that and they are NOT
   using that domain name on internal machines.  Instead, their domain name
   is advertised by their (outsourced) web site hosting company, which often
   also is providing them with web-based email.
      
   Medical offices (in my neighborhood) seem to be migrating to “electronic
   records”.  In practice, this often means some deal with a local hospital.
   The servers are run at the hospital IT department and client-server type
   software is installed on the medical office computers (or a web application
   is used instead), but the servers are all offsite and run by someone else.
   Privacy laws/regulations on medical data are growing, even outside the EU,
   and a common belief is that it is better to outsource the implementation
   so that some other organization is responsible for privacy & security
   compliance (e.g. HIPAA).

   These sites LOVE the existing mDNS + DNS-SD solution.  Their only real
    wish is that if they have 2 or 3 subnets, they could somehow have a single
    operational mDNS environment (instead of having one mDNS environment
    per subnet).  At least some of my clients have enabled a non-standard mDNS
    proxy that is available from a well-known IP router vendor.  At their scale,
    they are happy with that router vendor’s approach.  I worry a bit that in a
    larger network environment too much bandwidth would be consumed 
    (as happened historically with SLP) by that vendor’s implementation approach.

    As I have mentioned to Stuart at least once in the past, these folks really
    want something that looks/feels/behaves like the old AppleTalk/EtherTalk
    system — although most clients don’t use that terminology (because they
    were not working age when those capabilities were widely deployed by sites
    with Apple products).

2.  Larger Enterprise / Campus / Building-sized Case

    Larger businesses usually do have their own internal mail servers, file
    servers, and DNS servers.  Often their authoritative DNS servers are
    different/separate from their DNS resolvers.  These often have 2 logically
    different WiFi networks, one for employees/internal-users and one for
    guests.  Sometimes the “guest” wireless is outside a corporate firewall
    and only sees the public Internet.   Other times the “guest” network is in
    a kind of DMZ environment, so that guest’s can discover printers and
    send out print jobs, but does NOT have unconstrained access to the
    organization’s internal network.

    In this environment, often there is more concern about “security”, which 
    seems to mean some combination of “access control” (about what a 
    given node can see) and “authentication” (for DNS updates) relative to 
    DNS service advertisements.  (In the extreme, I have a client who turns
    on every possible security feature, including use of things like 802.1x.
    This results in a more secure, if somewhat more brittle, deployment.)

    In this environment and for these users, there is MUCH more willingness
    to have IT staff configure “infrastructure” (e.g., routers, switches, servers, proxies)
    than in Case 1 at top of this email.  This customer type also is MUCH more
    interested in using access controls and/or cryptographic authentication for
    any service advertisements and for any kind of DNS update.  

    However, in my experience, these customers do NOT want to configure 
    the end-user devices — at least not beyond whatever DHCP (or DHCPv6
    + IPv6 ND) can provide by way of automatic configuration.

     Note that users in this category often want to see services for their
     (logical) organization, regardless of where they are within the campus
     (or which campus for multi-campus organizations).  Someone who works
     in “engineering” wants to see all of the “engineering” groups services
     plus whatever printers are geographically near the person’s current
     location.  In old AppleTalk this flexibility was pretty easily deployed and 
     also pretty easily used.

Postulate:

    My postulate, again based on my own non-scientific sample, is that there
    are at least 2 distinct use cases for DNS-SD (and mDNS).  One case is
    small scale, so scalability of solution is not as important.  The other case
    requires scalability.  The small sites are not usually very security conscious,
    while the larger sites usually are very security conscious.

    So it is conceivable that some potential products of this WG might apply
    to one use case, but not to the other use case.  I think we need to all keep
    both use cases in mind as the WG ponders current/future work in this WG.

Yours,

Ran

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 20 Jul 2018 14:03:57 -0400

Thanks Ran. 

I think this is important input for the reCharter. 

Tom

> On Jul 20, 2018, at 12:44 PM, R. Atkinson <[email-masked]> wrote:
> 
> 
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: Michael Richardson <[email-masked]>
Date: Fri, 20 Jul 2018 19:07:51 -0400

> In these environments, I rarely see any servers within a small

So, no (surveillance) cameras, scanners and no shared folders?
It's just printers, which are passive until you need them.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "R. Atkinson" <[email-masked]>
Date: Sat, 21 Jul 2018 14:40:30 -0400

> On Jul 20, 2018, at 19:07, Michael Richardson <[email-masked]> wrote:
> 
> 

With respect to small businesses, 
— I sometimes see scanners.  Sometimes this is an all-in-one printer
    with integrated fax and scanner.

— Often, particularly if there is no (brand-name omitted here) servers,
     then there are no shared folders, just USB sticks and email to move files.

— Printers predominate.

With respect to residential,
— There are a wider range of mDNS devices, such as streaming media
     players, OTA TV DVRs that can stream media, (surveillance) cameras, 
     and what not.
— Scanners might appear also, of course, as might fax machines.

Ran

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Jul 2018 08:47:26 -0400

Of course, one reason that there are no servers is that setting them up and
having reliable access to them is punitively difficult.   In a world where
service discovery and enrollment are easy, we might see a softening of the
borders between those two use cases.   I'm also not convinced that there's
a huge difference between them from our perspective.   ISTM that the second
model is just the first model with more features enabled.  And, by the way,
you didn't talk about the model of the corporation that has an IT staff
running their network, which AFAIK is still pretty common for larger
enterprises.   Is that contradicted by your experience?

---

From: "R. Atkinson" <[email-masked]>
Date: Mon, 23 Jul 2018 11:11:54 -0400

> On Jul 23, 2018, at 08:47, Ted Lemon <[email-masked]> wrote:
> 
> Of course, one reason that there are no servers is that setting them up
> and having reliable access to them is punitively difficult.  

Yes, but the killer part of this is that none of the “enterprise servers”
(for whatever network services seem to be common) are really easy 
to configure and deploy, as near as I can tell.  All of them require
some kind of IT staff (or at least a reasonably technical person).  

Typical residences (again, not IETF participants) and small businesses
generally don’t have even one technical person.  I expect % of technical
folks with complex residences will vary in some geographies 
(e.g. Silicon Valley, RTP NC, Kanata ON), of course.

> In a world where service discovery and enrollment are easy, we might see
> a softening of the borders between those two use cases.  

We could.  I’m not so sure since my 2nd use case (Large Enterprise) has
IT staff and deploys various kinds of servers already, while the 1st use case
lacks IT staff and doesn’t today deploy servers.    

From what I am seeing, I think the big barrier to local server deployment
is the knowledge required to correctly deploy a local server.  This is a big
issue whether its a DNS server or some other kind of server (e.g. SMTP/POP).

Some company could make good money by creating an IT server that
is MUCH MUCH easier to deploy, configure, and update/maintain.

If I were still building routers, I’d be looking at DNS-SD as a differentiation
opportunity for enterprise customers.  Adding some kind of DNS-SD
cache/proxy/enrollment capability likely would sell well and should be
practical to implement.  Some existing enterprise routers already have 
a (traditional / unicast) DNS proxy / DNS resolver built-in, so adding 
support for mDNS caching/proxying and/or DNS-SD enrollment 
would not be a huge leap.

For residences or small businesses, that sort of capability likely would need 
to be added into a CPE router provided by the ISP before it would become 
much easier to deploy inside the home or small business.  Even if this happened,
due to CPE router enhancements, it is not clear that the deployment would go 
beyond “.local” or similar.  Put another way, it still would be unlikely to include 
a global-scope DNS FQDN.

> I'm also not convinced that there's a huge difference between them from our perspective.   ISTM that the second model is just the first model with more features enabled.  

What is the meaning of "ISTM" ??

The two cases quoted below both fall into the 1st case for my note
from 20 July 2018 @ 12:44 US EDT.

> And, by the way, you didn't talk about the model of the corporation that has an
> IT staff running their network, which AFAIK is still pretty common for larger 
> enterprises.  

Yes, I did.  It is Case 2 in my note from 20 July 2018 @ 12:44 US EDT.
For example, note my use of the phrase “IT staff” in the 3rd paragraph 
of Case 2. 

From where I sit, I doubt very much that Case 1 and Case 2 from my
note of 20 July will converge anytime soon, which is a good part of
why I enumerated them as separate use cases.

(Of course, other folks data might vary from mine, so other folks’ 
perspectives also might vary. :-)

Yours,

Ran

> Is that contradicted by your experience?
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Jul 2018 12:15:23 -0400

ISTM means "It seems to me."

I think a global-scope FQDN for the local network that includes the
corporation's domain name is quite unlikely, but it's easy to imagine that
if it were *useful*, an ISP or a third party might offer it as a service
(as with dyndns.org, but delegating a zone rather than just allowing a name
to be updated).  The benefit for this is simply external reachability of
services, so it may be that a better solution would just be a DoH tunnel or
VPN tunnel that you could access with the right credentials that would
allow you to query home.arpa.   It would be nice if this sort of thing
could be more automatic, with less user IT fu required.

> is MUCH MUCH easier to deploy, configure, and update/maintain.

We've seen devices like this—they just aren't typical.   Your printer is
like this.   If you have an Apple Time Machine or Homekit, it's like this.
 Making devices findable in this way isn't that hard, and enrollment really
isn't that hard either.   The issue is that right now for most use cases
nobody's making devices that work this way.   I think that's the barrier to
adoption.   I don't think that the level of knowledge in the deployment
environment is going to up.   I hope that the level of knowledge required
to deploy will go down.