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

[Ralph Droms <[e-mail]>]

> 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, [...]"

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."

>> 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.
 
> 
>> 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?

> 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?

>  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.  The current text in the document represents WG consensus for the description of the potential problem.

>> 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.  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.

> 
>> 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?


> 
> Regards,
> Douglas Otis
>