Re: [dnssd] WGLC for draft-ietf-dnssd-requirements-03

[Tim Chown <[e-mail]>]

Hi,

On 23 Jul 2014, at 21:14, Douglas Otis <[e-mail]> wrote:

> Dear Tim,
> 
> See comments inline:
> 
> On Jul 22, 2014, at 5:35 PM, Tim Chown <[e-mail]> wrote:
> 
>> Hi,
>> 
>> Thanks for your comments Doug.
>> 
>> On 8 Jul 2014, at 01:47, Douglas Otis <[e-mail]> wrote:
>> 
>>> On Jul 7, 2014, at 2:46 AM, Tim Chown <[e-mail]> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> This email begins a two week WGLC on draft-ietf-dnssd-requirements-03, "Requirements for Scalable DNS-SD/mDNS Extensions”.
>>>> 
>>>> Ralph and I as chairs believe the authors have addressed the issues raised at IETF89 and on the list since. 
>>>> 
>>>> You can see the draft here:
>>>> http://tools.ietf.org/html/draft-ietf-dnssd-requirements-03
>>> 
>>> Dear dnssd-wg,
>>> 
>>> 1) Layer 2 solutions intentionally ignored.
>>> 
>>> One of the primary goals for extending mDNS per the Educause petition was to enable access to remote displays.  Unfortunately, layer 3 routing is generally prohibited with unlicensed nodes in conveyance of copyright media.  While layer 2 solutions are able to overcome multi-bridge limitations imposed by media compliance requirements, this has been ignored by the Scalable DNS-SD/mDNS requirements documentation to the point of being ruled out-of-scope for discussion because of an assumed need for layer 3 only solutions.  Nevertheless, layer 3 solutions are normally precluded when not licensed as a means to ensure constraint of media redistribution.  A quandary that could have been avoided by determining common strategies that could be used by either layer 2 or 3.  For example, many routers are able to handle GUA+ULA.  Layer 3 and 2 might be considered analogous when ULAs are mapped to MACs. 
>> 
>> You need to be more explicit at what you mean here.  The purpose of dnssd is to allow DNS-based service discovery in multi-subnet environments, such as campuses and future home networks (as defined in the homenet WG). If your network is a flat layer 2 network, that particular problem doesn’t exist.
>> 
>> In addition, REQ14 states:
>> REQ14:  SSD should operate over existing networks (as described by
>>         use cases A-F above) without requiring changes to the network
>>         technology or deployment.
>> 
>> Regarding ULAs, the homenet-arch text describes the use of ULAs alongside GUAs in multi-link home networks. ULAs can then be used for internal communications, regardless of the GUAs, or changes in the GUAs. GUAs are then used for external communications.
> 
> Agreed, but when a GUA is used and published, this should exclude devices unable to safely terminate a session from the Internet.  It is not safe to advertise such addresses in DNS, especially when security depends on address obscurity. 

There was recently quite a long thread in homenet about publishing home devices in the global DNS, and how the homenet naming service can be operated. You might want to look at that if you havent already.
The archive is at: http://www.ietf.org/mail-archive/web/homenet/current/maillist.html
The related draft is: http://datatracker.ietf.org/doc/draft-mglt-homenet-naming-architecture-dhc-options/
And the topic started here: http://www.ietf.org/mail-archive/web/homenet/current/msg03702.html

>> Not sure what you mean by ULAs being mapped to MACs.
> 
> After reading the latest HDCP specification, concerns related to routing limitations were misplaced and peer-to-peer changes further reduce the concerns.  Please ignore needing an alternative for Educause. 

Ah, OK.

>>> 2) Many devices within a typical network may announce routable addresses via mDNS but are nevertheless unable to authenticate the access permitted when these mDNS resources are conveyed in DNS.
>>> ,--
>>> The following is a summary of the technical requirements:
>>> ...
>>> o  It must be cost-effective to manage at up to enterprise scale.
>>> '--
>>> 
>>> Being unable to differentiate locality for those devices unable to handle Internet originating sessions, as in the printer example, means the Scalable DNS-SD/mDNS extension is NOT manageable at any scale.
>> 
>> The charter states that a user away from a network should be able to discover devices in their ‘home’ network, which implies a remote proxy discovery capability, and GUAs for reachability. We should distinguish discoverability (including across the potential range of discovery ‘scopes’) from reachability (e.g. whether ACLs may exist on the path) from accessability (e.g. access control on the device).
> 
> Normal practices depend on use of a gateway authenticating clients, such as use of VPNs.  In such cases, service discovery can return ULAs which permits router bridging within a multi-router home network.  It sounds like Ran wants to configure devices within a data-center.  It might be helpful to reinforce a need to exclude FD::/8 addresses over Internet access links.  Only devices able to terminate Internet sessions should be published globally.  Unfortunately, it is impossible to make such a determination based on mDNS resources.  This inability makes such a simplistic approach both unsafe and unmanageable.  

Well, within a multi-link network you have to expose an address with scope greater than link-local to the querier for them to be able to reach the service they are discovering. So yes, ULAs wiithin the home could make sense, so you discover services with addresses you know you can use regardless of the external connectivity status (or at least that’s the same argument as using ULAs in parallel with GUAs in homenet to give session survivability etc in the presence of addess ‘disruption’ by the ISP.

I don’t think there’s any assumption in homenet that you’d VPN to the home, or via some home proxy, to access internal services.  There has been a lot of discussion in v6ops and opsec (I think) about default home CER filtering settings.

>>> Since different network realms are expected to permit device access behind different bridges based on their "routable" mDNS resources published in DNS, this circumvents a strategy of differentiating local origination.  This becomes particularly problematic when different IPv6 prefixes are dynamically in use.
>> 
>> The homenet arch postulates that ULAs can loosely be used as a hint of connection origin.
> 
> Agreed. But none of the related wg drafts clarify essential roles ULAs have in securing a Hybrid mDNS to DNS approach.  Within a dynamic multiple-prefix environment, ULA and RFC1981 space are essential in establishing stable and identifiable network perimeters.  Such perimeters defend devices that don't expect direct access from the Internet or split-horizon DNS, as some have suggested.  

Let’s see what the WG says in the session.

>>> In the Security Consideration Section, the union of DNS-SD and mDNS would be zero since DNS-SD claims it to be a data structure creating no security concerns.  The union of zero with anything is zero.
>> 
>> Not sure what you mean there - please expand.
> 
> Sorry, a mistake was made confusing union with intersection. Nevertheless, the security consideration statement misrepresents security concerns being a combination of mDNS and DNS-SD security considerations.  DNS-SD security considerations specification claims it adds no new security concerns.  Such a view implies SSD security consideration are limited to those affecting mDNS.  However, mDNS is confined to the bridge, whereas DNS removes this constraint.  Such a change has a tremendous, albeit ignored, security impact.

Right, potentially, and Hosnieh will talk to that in her slot, I think.  You’re right it’s important.  And privacy too.

>>> Does REQ6 have priority over that of REQ14?
>>> ,--
>>> REQ6:   SSD must not adversely affect or break any other current
>>>            protocols or deployments.
>>> '--
>>> ,--
>>> REQ14:  SSD should operate over existing networks (as described by
>>>            use cases A-F above) without requiring changes to the network
>>>            technology or deployment.
>> 
>> Ah. So I think REQ6 should say “any other current service discovery protocols or deployments.”.
> 
> The follow-on sentence attempted to clarify a paradox created by the simplified view when REQ14 is not seen in conflict with REQ6. 
> 
>>> mDNS is restricted to a single link.  The envisioned multi-link configuration affects the discovery and scope of the related services which may break current protocols and/or substantially increase their vulnerabilities.
>> 
>> Well, I agree there’s certainly privacy and security issues if devices become discoverable over a wider ’scope', which I believe Hosnieh is going to talk about.
> 
> Disagree.  Significant issues are related to erosion of network permitters not being considered.  For example, this draft could have included a reference to RFC6950 to expand on relevant DNS issues related to securing the proposed automatic publication by SSD that only excludes link-local and RFC1918.  Although posted on the mailing-list, my review failed to include this reference.  Two reasons for me to blush, but in essence security considerations ignored Internet originating threats permitted by obfuscation of network perimeters by promoting mDNS into DNS. 

RFC6950 certainly looks relevant.

>>> 6.4.  Authentication
>>> ...
>>> was:
>>> ,--
>>> If there is a risk that clients may be fooled by the deployment of
>>> rogue services, then application layer authentication should be
>>> considered as part of any security solution.  Authentication of any
>>> particular service is outside the scope of this document.
>>> '--
>>> 
>>> should be:
>>> ,--
>>> When there is risk that either clients or devices may be spoofed
>>> by malefactors, then a network overlay or application layer 
>>> authentication strategy should be considered. Authentication of
>>> or by any particular service is outside the scope of this document.
>>> ‘--
>> 
>> What you’re hinting at I think is to use ULAs as a hint of connection origin, to distinguish from external access. A question is whether a device that is only intended to be used internally should be published, and thus discoverable, externally.
> 
> Default behaviors should be secure.  At minimum, there should be a means to recognize whether a device can be directly discoverable and accessible from the Internet.  This DMZ determination should be considered limited to manual configuration.
> 
>>> For example, it is not practical to expect a printer will ever be able to authenticate a client.
>> 
>> Many home network devices certainly do support authentication. Although often they’re left with default factory settings….
> 
> In the case of most consumer printers employing IPv6, they often make use of SLAAC or DHCP and report routable IPv6 addresses in mDNS resources.  While these devices may support authentication in administrative configuration functions, only MAC filters constrain sending a fax, printing, scanning, etc.  Such constraints can't be used and still permit router bridging.  In other words, there is no protection and no logging to even permit effective monitoring.

A home device may have a link-local, ULA and GUA - we should be clear on how/whether/when the ULA and/or GUA are used in any proxy scheme. There is also the question of what the proxy then effectively publishes externally. Stuart is recapping the Hybrid Proxy proposal tomorrow.

>>> An overlay network can consist of GUA+ULA without change to network technology or deployment.  ULAs can limit access to trusted users having immediate access to the local network realms.  ULAs also avoid DNS deployment that attempt to merge local with global using complex and risky split-horizon configurations.  ULAs already serve as the basis for BTMM configurations which avoids publishing resources for devices like printers unable to authenticate an external session.
>> 
>> So ULAs could be used in a home, and they might be used in an enterprise - whether there that’s alongside GUAs or with NPTv6 is another question.
> 
> It seems reasonable for ULAs to be used in both environments, with only selected devices moved manually into the DMZ.  In both environments use of VPNs or secure tunneling is increasingly common. 

There is probably different behaviour/practice in home and enterprise/campus networks. But I have no data to support that.

Tim

> 
> Regards,
> Douglas Otis
> 
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd