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

[Douglas Otis <[e-mail]>]

Dear Ralph,

> On Mar 17, 2015, at 1:11 PM, Ralph Droms <[e-mail]> wrote:
> 
>> On Mar 17, 2015, at 3:32 PM 3/17/15, Douglas Otis <[e-mail]> wrote:
>> 
>> Dear Ralph,
>> 
>>> On Mar 17, 2015, at 10:58 AM, Ralph Droms <[e-mail]> wrote:
>>> 
>>> Doug - Here is my summary of what I understand to be your concerns with
>>> draft-ietf-dnssd-requirements-05:
>>> 
>>> 1) A change from link-scope mDNS SD to a larger scope may result in the
>>> existence and address of a device being made more widely available than
>>> currently expected.
>> 
>> Of course.
>> 
>>> 2) Some devices and networks are incapable of defending themselves
>>> against unwanted access or other attacks once the address of the device
>>> to be attacked is known.
>> 
>> When the _wrong_ address is published within DNS that then permits direct
>> Internet access, this may evade desired protections. Although many mDNS
>> devices report all such options, such reporting is only seen on the local 
>> network.
> 
> I need to parse your response carefully so that we can understand each other.
> In what sense is an address that permits direct address a "_wrong_" address?
> Is this sentence equivalent: "When an address (such as a globally routable
> address) is published within DNS that then permits direct Internet access,
> [...]"

Many SOHO routers are unable to selectively block IPv6 session initiation from 
the Internet causing an all-or-none situation.  Necessary exceptions become 
practical when RFC1918 or RFC4193 addressing conventions are used in conjunction 
with various protocols or when they are exceptionally permitted between routers.

For example, a user with an Apple Airport Extreme router has the choice of 
allowing ALL inbound IPv6 connections, or allowing NO inbound IPv6 connections.  
There are no other options.  Similar conventions are present on virtually all 
low end routers - they simply don’t have the memory, CPU, or configuration 
capacity to allow for IPv6 access lists.  Further, with the ability for 
devices to change IPv6 addresses using the privacy extensions RFC4941, 
filtering at the router becomes impractical.  Publishing the IPv6 globally 
reachable address in DNS invites trouble, particularly for devices unsuitable
for direct internet connection (such as printers, cameras, scanners, and other
gear).

> To make sure I understand the second sentence, is this sentence equivalent:
> "Although many mDNS implementations advertise all of the addresses available
> for a device, those advertisements are restricted to the local link and,
> therefore, don't advertise globally routable addresses to the Internet."

mDNS traffic is not visible beyond the local network.  However, when globally 
routed addresses are published in DNS, exposure of this addressing might permit
malefactors access due to practical firewall limitations.  Exploits for doing 
so are many.

>>> 3) Use of RFC 4193 is a way to protect against attacks enabled by the
>>> increased scope of discovery envisioned by extended DNS-SD.
>> 
>> Use of RFC4193 is used to protect Homenet as well as various enterprise
>> environments.  It is also used by Apple in their Back-To-My-Mac scheme.
> 
> To be clear, you agree with my point 3 and you cite two examples of the
> use of RFC 4193.  My understanding is that Homenet does not mandate the
> use of RFC 4193, perhaps because of the difficulties in mandating such
> usage; from section 2.4 of RFC 7368: "Devices in a homenet may be given
> only a ULA as a means to restrict reachability from outside the homenet."  
> My understanding is that RFC 4913 addresses are used in Back-To-My-Mac
> as an identifier if no other IPv6 address is available, rather than to
> restrict reachability.  Back-To-My-Mac uses an array of other security
> mechanisms to protect devices using the technology.

This overview is not correct.  ULA is NOT optional with this scheme. See:
https://tools.ietf.org/html/rfc6281

This scheme generates an IPv6 ULA for each host as its identifier.  This allows 
reuse of existing IPv6 support where end-to-end data security then depends
on IPsec to protect communications and Kerberos for end-to-end authentication.
Similar secure schemes, such as VLANs or VPNs, could also make use of these 
conventions.

>>> You expressed these concerns during WG development and review of
>>> draft-ietf-dnssd-requirements.  Tim and I judged the consensus of the
>>> WG to be in support of advancing the document to the IESG, based in part
>>> on the following analysis:
>>> 
>>> Points 1 and 2 are answered by the third paragraph of section 6.1.  For
>>> completeness, the last sentence of that paragraph might be extended to
>>> include "and protection against other forms of attack".
>> 
>> Address selection preferences represent critical security aspects that 
>> MUST BE supported by the protocol.
> 
> Do you mean selection of which among several available addresses are
> advertised through DNS-SD?

Yes, when deciding which addresses are published.

>> If RFC1918 or RFC4193 addresses are 
>> reported via mDNS to the  DNS-SD proxy, there MUST be a requirement for 
>> these addresses to be used over any Internet routable address.
> 
> Used where or by what devices?  Where are these restrictions enforced?

This REQUIRES mDNS to DNS proxy components to enforce these selections. 

>> It is 
>> important these requirements make it clear mDNS is not suitable for 
>> publishing hosts on the Internet.  Where safer alternatives exist, such 
>> publication MUST REQUIRE administrative intervention.  Otherwise 
>> organizations making use of such schemes will be placed at great risk.
> 
> In my opinion, there is not consensus in the WG to support your concern.

Really?

mDNS offers a secure basis for publishing RRset data in DNS?  It seems even
the requirements document warns against such use.

> The current text in the document represents WG consensus for the
> description of the potential problem.

The current text incorrectly assumes mDNS can safely be used to 
automatically publish addresses in DNS.  This is both wrong and unsafe.

> 
>>> Point 3 tries to mandate a solution through a specific deployment
>>> mechanism and is, therefore, out of scope for a requirements document.
>>> It may also be more broadly out of scope of the dnssd charter, which
>>> addresses just DNS-based service discovery and does not include mandating
>>> network deployment requirements as part of a solution.
>> 
>> This point offers an example strategy (address preferences) that MUST be 
>> supported.  Ensuring support is not the same as making this a mandate!  
>> It seems clear this group failed to develop schemes to protect devices 
>> that normally limit access to that of the local network, as provided by 
>> constraints imposed by mDNS.  As such, there should have been greater 
>> review of those offered by Homenet or even Back-To-My-Mac.
> 
> "example strategy [...] that MUST be supported" sounds like a mandate to me.

An ability to prefer one category of addressing over another is not a mandate
for any specific use.  It simply ensures support exists for secure methods for 
handling otherwise poorly vetted mDNS information.  These provisions can prevent
rampant abuse of a scheme based on unqualified UDP multicast announcements.

> This is a requirements document, not a final design, and therefore this
> document does not need to develop a solution to the problem you are
> concerned with.

It is also important reasonable _minimum_ requirements are established before
too much time and money is been spent heading in unsafe directions.

>>> If you do not agree that your concerns have been answered by this
>>> analysis, please state the basis for your continued concern, so that we
>>> can judge rough consensus on support for publication of the document.
>> 
>> The requirements document remains critically flawed without justification. 
>> Ensuring an ability to offer safe deployment unfortunately does not prevent 
>> less safe schemes. Nevertheless, supporting a safe scheme should be a basic 
>> requirement. 
> 
> Can you give a specific requirement or requirements that could be added to
> the document to satisfy your concerns?

1)
Devices publishing addresses related to mDNS/DNS-SD should support configurations 
that prefer use of ULA addressing.  Per RFC7084, the role of the router is to prevent 
these addresses from going beyond or to have originated from the WAN interface.  
Similarly, when an ULA address is not present, similar configurations should support
similar preferences for RFC1918 addressing.

2)
The collection of DNS related information should also ensure header compliance
requirements as specified by RA Guard RFC7113.  This provision is to better ensure
administrative control of host naming conventions in lieu of IDNA naming restrictions.

Regards,
Douglas Otis