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

From: Tim Chown <[email-masked]>
Date: Mon, 7 Jul 2014 10:46:29 +0100

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

Please send your comments or feedback to the list.

The WGLC ends on Monday 21st July.

We will discuss/consider the result of the WGLC at the dnssd session at IETF90 in Toronto, which is scheduled for 3.20pm on Thursday 24th July.

Tim

---

From: Douglas Otis <[email-masked]>
Date: Mon, 7 Jul 2014 17:47:02 -0700

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

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.

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.

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.

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

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.

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

For example, it is not practical to expect a printer will ever be able to authenticate a client.

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.

For additional references see:
http://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-04

Regards,
Douglas Otis

---

From: Tim Chown <[email-masked]>
Date: Tue, 22 Jul 2014 22:19:13 +0100

Hi,

The two-week WGLC period for draft-ietf-dnssd-requirements-03 has completed.

The chairs would welcome any final comments in advance of Thursday afternoon’s dnssd session at IETF90, including from those who have read the draft and believe it’s ready to ship to the IESG.  

The draft, and the WGLC, will be reviewed and discussed in Thursday's session.

Tim

---

From: Tim Chown <[email-masked]>
Date: Tue, 22 Jul 2014 22:35:44 +0100

Hi,

Thanks for your comments Doug.

> 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 conve…

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.

Not sure what you mean by ULAs being mapped to MACs.

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

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

> 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 differentiatin…

The homenet arch postulates that ULAs can loosely be used as a hint of connection origin.

> 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 ze…

Not sure what you mean there - please expand.

>            technology or deployment.

Ah. So I think REQ6 should say “any other current service discovery protocols or deployments.”.

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

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.

> ‘--

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.

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

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

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.

> http://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-04

Thanks,
Tim

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 23 Jul 2014 12:55:08 -0700

On 7 Jul, 2014, at 17:47, Douglas Otis <[email-masked]> wrote:

> Layer 2 solutions intentionally ignored.

Correct. Organizations like IEEE tend to focus on flat single-link networks, which is fine. The IETF tries to develop inter-network solutions, building on the link-layer technologies IEEE provides. We already have a single-link solution -- mDNS. The goal of this WG is to develop a solution that goes beyond a single logical link, and works inter-network.

> it is not practical to expect a printer will ever be able to authenticate a client.

A Google search suggests otherwise. For example:

   My printer asks for a password. Where do I get it? (14850 Views)
<http://h30434.www3.hp.com/t5/Printer-Networking-and-Wireless/My-printer-asks-for-a-password-Where-do-I-get-it/td-p/1730245>

Similarly, when you use Printer Sharing on Mac OS X to make your USB printer available on the network, you have the option to restrict access to specified authenticated users if you desire.

Stuart Cheshire

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Jul 2014 16:14:46 -0400

Dear Tim,

See comments inline:

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

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. 

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

> 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 shoul…

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.  

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

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

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

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

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

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.

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

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

Regards,
Douglas Otis

---

From: Tim Chown <[email-masked]>
Date: Wed, 23 Jul 2014 23:40:39 +0100

Hi,

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

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

> 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 E…

Ah, OK.

> 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 n…

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.

> 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 essen…

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

> 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 consi…

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

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

RFC6950 certainly looks relevant.

> 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 a…

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.

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Jul 2014 10:37:21 -0400

> The chairs would welcome any final comments in advance of Thursday afternoon’s dnssd session at IETF90, including from those who have read the draft and believe it’s ready to ship to the IESG.  

     (F) Mesh networks such as RPL/6LoWPAN:

      Multi-link subnets with prefixes defined by one or more border
      routers.  May comprise any part of networks C, D, or E.

This is a very minor nit, and there may be nothing that is worth doing to address it, but I think that (F) applies to (B) as well, where (F) is the only other network on the homenet.   I mention this because I think it's likely that this configuration will be the most common homenet+IoT configuration.   One way to address this would be to say something like "May comprise any part of networks C, D or E.   Networks B may become networks C even in otherwise simple homenet deployments as a result of adding a network F."

   REQ11:  SSD must be scalable to thousands of nodes with minimal
           configuration and without degrading network performance.  A
           possible figure of merit is that, as the number of services
           increases, the amount of traffic due to SSD on a given link
           remains relatively constant.

Do you mean "remains relatively constant," or increases no more than linearly?  It seems unlikely for it to remain relatively constant, but I didn't follow the discussion that led to this requirement, so maybe I'm missing something.

   SSD should support rich internationalized labels within Service
   Instance Names, as DNS-SD/mDNS does today.  SSD must not negatively
   impact the global DNS namespace or infrastructure.

This sounds like a requirement, but it appears in the considerations section.   Any reason for this?

   If the scope of the discovery is not properly setup or constrained,
   then information leaks will happen outside the appropriate network.

This text is a bit awkward.   I think you mean something like this:

   If the scope of discovery is not properly constrained, either
   automatically or through configuration, then information will
   leak inappropriately to networks it is not intended to reach.

Or maybe you didn't mean that, but in any case I think the wording could be better.

   This is not likely to be the case in foreign
   networks.

The term "foreign networks" isn't defined, and probably should be.

The document looks really good.   None of the above comments would prevent me from taking it to IETF last call as is; any updates that the working group decides to do based on these comments could be done in conjunction with comments received during IETF last call and directorate review.