Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT)

[Douglas Otis <[e-mail]>]

> On Mar 16, 2015, at 12:52 PM, Tom Pusateri <[e-mail]> wrote:
> 
>> On Mar 13, 2015, at 10:08 PM, Douglas Otis <[e-mail]> wrote:
>> 
>>> On Mar 13, 2015, at 1:41 PM, Kerry Lynn <[e-mail]> wrote:
>>> 
>>> On Thu, Mar 12, 2015 at 2:24 PM, Douglas Otis <[e-mail]> wrote:
>>> 
>>> Dear Stephen,
>>> 
>>> I agree with your statement and, based on our tests, these concerns are very real!
>>> 
>>> IPv6 can not be defended in the same manner as with IPv4.  With Homenet, an
>>> effort was made to ensure address selection preferences critical when
>>> publishing addresses within DNS but omitted from the requirements documents.
>>> 
>>> <KEL> Doug, can your concern be addressed by specifically stating a requirement
>>> that advertising a service in the global internet should be an opt-in decision of the
>>> user, as suggested by Benoit?
> 
> I'm not sure how practical this is. In order to work with
> existing service advertisements, these decisions should be
> made in the device that translates the mDNS advertisements
> not the device that originates the advertisement. But there
> is plenty of room for policy controls in the translation device
> to filter and provide access control based on local criteria.

Dear Tom,

Automatic publishing of mDNS as DNS-SD introduces concerns NOT 
adequately covered by either mDNS or DNS-SD respective security
sections.  When either RFC1918 or RFC4193 host addresses are 
present, there is no need to expose other address categories.  After
all, mDNS is bound to local networks by limitation of multicast.  
RFC4193 offers local network containment strategies not dependent on
multicast.

Offering routable IP addresses introduces unwarranted and unnecessary
exposure when enabled beyond the local network, and it is clear such
limitations are not imposed by hosts supporting mDNS since such
exposure is expected limited by multicast constraints.  However, the
effort to automatically publish mDNS in DNS-SD form removes these
constraints and creates new risk not yet properly addressed.
    
>> Dear Kerry,
>> 
>> Thank you for you comments.  See reply below.
>> 
>>> The statement made in Section 6.1 is poorly considered.
>>> ,--
>>> Section 6.1
>>> ...
>>> Note that discovery of a service does not necessarily imply that the
>>> service is reachable by, or can be connected to, or can be used by, a
>>> given client.  Specific access control mechanisms are out of scope of
>>> this document.
>>> '---
>>> 
>>> <KEL> Let's take these "poorly considered" assertions one-by-one:
>>> - reachable (a route may not exist to the advertised address)
>>> - connected to (the device may be offline)
>>> - used by (the user of the service may lack authorization)
>>> - access control is out of scope (not in our charter)
>>> Which of these do you specifically have an issue with?
>> 
>> Controlling access becomes unmanageable with automatic expansion of --
>> 
>> a) discovery of all network details reported by mDNS beyond local networks
>> 
>> b) routing beyond local networks using all mDNS details conveyed to DNS
>> 
>> For example, an older Mac Book excluded from receiving security updates
>> fixing an NTP DDOS vulnerability, a concern that applies equally to any
>> consumer device placed at risk by unwarrantedly increased discovery.
>> Examples might include printers or a baby monitors heavily depending
>> on access limited to local networks which conflicts with a goal of
>> reduced dependence on multi-cast discovery.
> 
> I don't agree. Controlling access is perfectly manageable and done
> by a variety of institutions across a broad array of services. Do not
> incorrectly equate discovery with access.

Since IPv6 permits dynamic network prefixes, this makes it relatively
impractical to exclude traffic from the Internet while allowing traffic
from isolated bridges without reliance on conventions established by
RFC4193 as used by Homenet and various enterprise deployments.

>> A typical IPv6 router is unable to differentiate hosts given a routable
>> address published in DNS by an mDNS proxy.  To safely bridge this gap,
>> address preferences MUST USE the smallest practical scope available.  The
>> ability to do so MUST BE a requirement.  As such, direct Internet
>> access would require other methods be used.  This means there MUST BE a
>> requirement to understand address scope differentiation. A requirement
>> related to mDNS --> DNS publication that is missing.
> 
> While a device translating multicast DNS services to a unicast DNS
> infrastructure MAY choose to limit the scope of the addresses it
> advertises, this is not a MUST and the smallest scope MAY NOT be
> the correct scope. This decision is best left to the administrator
> of the translating device and we should not limit the applicability
> of the protocol meeting these requirements.

RFC4193 avoids network translations by use of a network overlay.  A
technique that leverages IPv6's ability to support multiple IP addresses
per network adapter.  Many different network boundaries can be safely
established through an address category selection made in a publication
process.  The ability to establish publication preferences MUST BE a
requirement for any proposed publications of mDNS into DNS.  Publishing
a host on the Internet SHOULD NEVER be automatic, nor depend on
administrative intervention.  The selection process using _stable_
prefixes is thereby better able to select the smallest _practical_ realm
based on administrative policy.

>> Once a malefactor discovers addresses having global scope not uniquely
>> identifiable at a firewall, an entire class of devices immediately become
>> vulnerable.
> 
> These devices are vulnerable regardless and to pretend otherwise is
> just an attempt to derail this effort. There are many ways to discover
> internal devices without DNS-SD service advertisements.

An RFC4193 address better isolates sensitive devices having limited resources
from direct Internet access, while still enabling various authenticated
tunneling methods.  It is also wrong to suggest such devices are not far 
better protected by such schemes.

>> As with Homenet, mDNS to DNS proxy should prefer the most conservative scope
>> that meets the desired goals.
> 
> This is a good recommendation but it SHOULD be up to the administrator of the
> translating device.

Before an administrator is able to isolate a network realm, basic support methods
must be made available as a protocol requirement.  A requirement that remains
missing in the form of address publication selection.

>> When done correctly, this should not require an Internet Opt-in mechanism
>> that is impractical for hosts assigned global IPv6 addresses.
> 
> Agreed. Opt-in or Opt-out mechanisms are not practical when considering
> existing services.
> 
>>> Or the false statement:
>>> ,--
>>> 6.5.  Access Control
>>> ...
>>> While controlling access to an advertised service is outside the
>>> scope of DNS-SD, we note that access control today often is provided
>>> by existing site infrastructure (e.g., router access control lists,
>>> firewalls) and/or by service-specific mechanisms (e.g., user
>>> authentication to the service).  For example, networked printers can
>>> control access via a user-id and password.  Apple's software supports
>>> such access control for USB printers shared via Mac OS X Printer
>>> Sharing, as do many networked printers themselves.  So the reliance
>>> on existing service-specific security mechanisms (i.e. outside the
>>> scope of DNS-SD) does not create new security considerations.
>>> '---
>>> 
>>> Most printers DO NOT offer user-id/password access mechanisms and often
>>> IPv6 support removes access control lists.  Homenet and Apples BTMM
>>> make use of an important overlay approach being ignored both here and with
>>> the the insecure UPnP. For this protocol to safely interoperate, an
>>> overlay approach must be supported.  This approach might use ULAs, for
>>> example. For this to work properly, locally defined addresses must be
>>> preferred when publishing in DNS.
>>> 
>>> As previously presented, it is minor fix to correct this oversight.
>>> 
>>> <KEL> Doug, you have had ample opportunity to argue your position before
>>> the WG and again during WGLC.  Your concern has been duly noted, but it
>>> is not the consensus of the WG to mandate a particular solution in an
>>> *informative* requirements draft.
>> 
>> The suggestion was to consider Homenet and to leverage their consensus.
>> 
>> There was very little discussion within this WG, other than to deny concerns at
>> the beginning and final hours.  A point in time which excluded my participation due
>> to momentary health issues.
> 
> There was ample discussion of this topic in the working group including
> your participation. This text accurately represents the consensus of the
> working group. Stuart described how these services could be secured with
> user authentication today and products that are vulnerable are vulnerable
> with or without service discovery advertisements.

Nevertheless, a few key statements were factually in error and challenged,
but never adequately discussed on a rather quiet WG.

>>> To your point about specific devices lacking access control mechanisms, my
>>> personal response would be to a) mitigate that problem with an appliance (such
>>> as described in http://spectrum.ieee.org/telecom/security/how-to-build-a-safer-internet-of-things),
>>> b) put it behind a device that implements access control (e.g. a Mac- or PC-to-
>>> USB print server), c) get a printer that supports access control (yes, they do exist),
>>> or d) don't advertise the service beyond the local link.
>> 
>> Firewall policies white-listing specific IPv6 addresses is not practical.  This is why
>> such a feature is often excluded in IPv6 supported devices, yet present with IPv4.
> 
> Same as above. DNS-SD can't be responsible for broken products that are
> vulnerable with or without service discovery advertisements. Policy at the
> translating device is no different for IPv6 as it is for IPv4. NAT is not a
> security solution.

This is not about use of a NAT.  With IPv6, it is about use of overlays.
These might be in the form of VLANs or VPNs for example.  Methods that are 
able to offer very strong security. 

>>> Note that in the topologies we're specifically targeting (enterprise, higher ed)
>>> implementing an overlay is no guarantee that an adversary with access to the
>>> network won't be able to use your consumables (ink & paper).
>> 
>> Doing this for higher education is great.  However, there is
>> no reason this can't be done in a safer manner by requiring a
>> few basic functional requirements still missing.
>> 
>> See:
>> RFC7368 Section 3.6.6.  ULAs as a Hint of Connection Origin
>> RFC7084 Section 4.1  General Requirements
>> RFC7068 Section 4.3.  LAN-Side Configuration
>> RFC4864 Section 3.2.  Unique Local Addresses
>> 
>> Omitting proper address selection rules will not ensure basic
>> deployments offer desired security.  This consideration was
>> omitted in both the Hybrid Proxy and the requirements documents.
>> Threat related documents should also include header compliance
>> requirements as specified by RA Guard RFC7113 also omitted by
>> this draft to better ensure administrative control of host naming
>> conventions in lieu of IDNA naming restrictions.
>> 
>> Again, the issue is to get ahead of security threats.  We have
>> the opportunity to do this correctly - and at virtually no cost.
>> If we wait, it will be deployed, and exploited at great cost.
> 
> These are good recommendations for an administrator but again I don't see
> the need to force it as a requirement.  That will restrict the use cases.

Not imposing a MUST requirement on an address selection ability prevents
safer deployment possibilities.  Security will be significantly weakened
by this address selection requirement oversight!  This scheme should also
ensure of the integrity of basic configurations being published, since
IDNA is also being ignored.

> The use case you are thinking of MAY benefit from this approach and you
> may even want to make defaults that guide the administrator in this way
> but by no means will it apply to every use case.

The current attitude is all devices inadvertently exposed by mDNS -> 
DNS-SD automatic publishing schemes will be able to cope with direct
Internet access or will be administratively excluded.  Similar attitudes
have been expressed in the past, many of which later proved recklessly
optimistic.  A few simple changes can and will significantly enhance
the ease and stability of the desired security. 

Regards,
Douglas Otis