Subject: [dnssd] Threat model - answer to questions

From: Hosnieh Rafiee <[email-masked]>
Date: Fri, 14 Nov 2014 15:08:46 +0000

All,

Thanks folks for taking your time to listen to my presentation. I do not know how was the quality. Since on my side I didn't see any face to react based on the faces of people. Probably if I was onsite and I could see the faces with big question mark during presenting the tables, I could clarify everything. 

I would like to answer some of unanswered questions/comments that raised during my presentation and any aspects that confused folks. 
(The names might not be accurate as I might confused the discussion of one person with another) 

1- There was discussion about privacy in local links (I think raised by Dave)

Answer: I agree that privacy in general is really important. What I wanted to point out during my presentation by my (confusing table) was that for DNS-SD when the scope is only local link ,privacy might not be a big issue because
 - service provider (a printer) needs to publicly advertise its service inside the local link. Nothing can be hide without this multicast or broadcast messages
In other word, service provider cannot hide any information 

 - MAC addresses are also known to other nodes and hiding any IP address or names of service providers does not much help to increase privacy in local link. But this might be a big issue if the scope is larger and we are talking the privacy inside enterprise network consisting on several local link.

2- DNSSD uses both unicast DNS and multicast DNS (I think raised by Cheshire) 

Answer: This is true. In first slide I explained the differences of unicast DNS with DNS-SD. Therefore I only talked about sending multicast messages
In second slide I discussed about the similarities of these two. Therefore, I only talked about both sending unicast messages. This was also as a part of slides' title. If I passed on it very quickly then someone should ask me to slow down as I received no feedback during presentation :-| and could not see your faces to know when I should explain something more or when I should just skip a slide.

3- Why we need to compare unicast DNS with DNSSD? (I think raised by Cheshire)

Answer: The comparison is just because to find out the threat scope. As folks already know, there are lists of known threats that is applicable to unicast DNS. When there is any similarities between the FUNCTIONS of two protocols, all of these threats can be applicable to DNSSD the same way as it is applicable to unicast DNS. Then there is possibility to check the current available mechanisms and check to see whether with current requirements that exist in DNSSD, whether or not we need another security mechanism or whether or not we need to any extension to current available security mechanism or whether or not we can use them as it is.  

4- Not agree that DNSSEC cannot be in solution space (Dave)

Answer: I just explained in the draft it cannot be a solution space when we are talking about zero configuration or plug and play solutions or minimal configuration. If you are also talking about DANE + DNSSEC, the list of trusted anchors need to be introduced to your clients and also service advertiser (that I called it service provider).  IMO this is not minimum configuration. Since it is a requirement for each single nodes. This is almost not feasible for public wireless networks. There might be different ways to propagate this trusted lists to all nodes but probably there are other requirements such as all nodes are inside one ADs domains or subdomains. 
But configuration of middle boxes, routers and switches, IMO, is considered minimal configuration since it is only limited to certain number of devices. It is also possible to simplify this if the network supports software defined networking (SDN) based approaches as I explained in my last slide but as a new use case for SSD. However It can be also a helpful solution for minimum configuration. 

Any thought?

5- overlay networks and SSD (Douglas)

Answer: I still do not understand what is the relationship of overlay networks to SSD. This was the case I did not know what to answer to your question. Why should we consider this? What will happen if we do not consider this?

6- what is the relationship between spoofing and privacy (Dave)

Answer: the rows in the table did not have any relationship to eachother. I just used the rows to separate two different threats in one column but it was nothing to do with the relationship of, e.g., group  of threats in column 1 row 1 to column 3 row 1. I guess I had to remove the lines between rows so that people did not have this misinterpretation of my tables. I only had 3 groups (each in one columns) that the first group of threats was shared between both, e.g., SSD and DNS-SD. One was only specific to DNS-SD and the last one was specific to SSD. This is also true for other table, i.e, unicast DNS vs DNS-SD.

Please share your thoughts.

Thanks,
Best,
Hosnieh

---

From: Douglas Otis <[email-masked]>
Date: Wed, 19 Nov 2014 15:48:47 -0800

> Answer: I still do not understand what is the relationship of overlay networks to SSD. This was the case I did not know what to answer to your question. Why should we consider this? What will happe…

Dear Hosnieh,

For resource constrained devices, security is best enforced by use of ULA address space defined by RFC4193.  Few CPE devices conforming with RFC7084 permit address specific exceptions for externally initiated sessions.  This limitation makes external exposure either a default accept or deny setting.  ULAs offer a means for resource constrained devices to make exceptions for traffic within its domain.  Otherwise, exclusion of all external initiated sessions might inhibit domain connectivity.

ULA is not an IPv6 version of RFC1918 address space normally combined with NAT/NAPT for Internet connectivity.  ULAs do not require translations since first hop communications can leverage IPv6’s default support of multiple-addresses-per-interface.  This permits network overlays rather than address translation techniques.  An overlay can be achieved by using centrally or locally assigned ULA prefixes (FC00::/8 or FD00::/8).  Apple currently represents the largest deployment of locally assigned ULA prefixes in their Back-to-My-Mac feature by making use of L2TP tunneling.

A ULA prefix is not to be advertised outside a given domain used by agreement of those networked within the domain. Administrators need to clearly set the scope of the ULAs and configure ACLs on relevant border routers to enforce their scope. If internal DNS is used, administrators should use internal-only DNS names for ULAs and might need to use split horizon DNS to ensure internal names do not resolve on the Internet as described in RFC6950.

To maintain security, address preference rules employed by a proxy device should properly consider use of ULAs as described by RFC7368.  Per section 2.4, a device should only use its ULA address within its domain. Even where multiple /48 ULA prefixes are in use within a single domain, as may occur when there are multiple Internet uplinks, utilizing a ULA source address and a ULA destination address from two disjoint internal ULA prefixes should still be preferred over use of GUAs.  When a device has not been specifically enabled to be externally accessible, mDNS proxy into DNS should not publish associated GUAs.

Omitting proper address selection rules is unlikely to obtain the desired security.  This consideration was omitted in both the Hybrid Proxy and Security Threat documents.  

Note: Last hop security depends on header compliance with RA Guard RFC7113. 

Regards,
Douglas Otis