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

[Tom Pusateri <[e-mail]>]

Thanks Ran. 

I think this is important input for the reCharter. 

Tom

> On Jul 20, 2018, at 12:44 PM, R. Atkinson <[e-mail]> wrote:
> 
> 
> 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
> 
> 
> 
> 
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd