Subject: Re: [dnssd] [homenet] IETF-89 WG meeting minutes

From: Douglas Otis <[email-masked]>
Date: Thu, 3 Apr 2014 16:52:04 -0700

On Apr 2, 2014, at 2:30 PM, RJ Atkinson <[email-masked]> wrote:

> 
> I concur with Tom Pusateri, Markus Stenberg, Ted Lemon, and others:
>  - A layer-2 solution is not deployable in the full range of HomeNet
>    environments.
>  - Many link layers do not use any form of IEEE 802.  So RBRIDGE and
>    TRILL and similar are not deployable over many applicable link layers.
>  - We need a solution that is agnostic to the type of link layer.
>  - Further, we have a range of on-the-shelf IETF security mechanisms
>    that operate at Layer-3 and higher.  There is no security magic
>    to a Layer-2-only approach to HomeNet.
> 
> Bottom Line:
>   Not all links are (wired, wireless) Ethernet or based on IEEE 802.*

Dear Ran,

Of course home networks may involve networking protocols such as Zigbee, Z-Wave, HomePlug/IEEE 1901, ITU-T G.9972 that might not be suitable candidates for TRILL extensions.  TRILL was proposed as a means to extend the functional use of AppleTVs that impose HDCP requirements.  Making adjacent network multicast traffic visible through automated processes of publishing translated routable addresses in local DNS profoundly and negatively changes home network security.  While mDNS does not offer enhanced security, it does not also expose devices to threats from other networks and prohibit use of link-local addressing.

Most mDNS related problems can be addressed through the use of TRILL with specific service filters without introducing a wide array of security exposures.  There are many home devices that implement some level of home automation using an OS that can not be updated by their owners.  The proposed homenet using the mDNS to DNS proxy will make these devices visible to browsers for example and significantly challenge the effectiveness of existing firewall strategies.  In an ideal world, all devices should be secure when exposed to the Internet.  Our world is not ideal.

Please consider the security aspects, and how we might be able to aid deployment (even in the form of a BCP).

Regards,
Douglas Otis

---

From: Don Sturek <[email-masked]>
Date: Fri, 04 Apr 2014 06:10:27 -0700

Hi Douglas,

As one who follows the WG and having a keen interest in homenet solutions,
I fail to see how TRILL addresses the homenet problem set.

Producing a flat L2 architecture and then trying to set up specific
service filters to contain the traffic seems like an L3 problem to me.

Claiming that L3 does not address "security threats" is not a reason to
use TRILL since I would imagine setting "specific service filters" in
TRILL would have the same issues (and without the existing IETF L3
security solutions we already have)

Don

On 4/3/14 4:52 PM, "Douglas Otis" <[email-masked]> wrote:

>Of course home networks may involve networking protocols such as Zigbee,
>Z-Wave, HomePlug/IEEE 1901, ITU-T G.9972 that might not be suitable
>candidates for TRILL extensions.  TRILL was proposed as a means to extend
>the functional use of AppleTVs that impose HDCP requirements.  Making
>adjacent network multicast traffic visible through automated processes of
>publishing translated routable addresses in local DNS profoundly and
>negatively changes home network security.  While mDNS does not offer
>enhanced security, it does not also expose devices to threats from other
>networks and prohibit use of link-local addressing.
>
>Most mDNS related problems can be addressed through the use of TRILL with
>specific service filters without introducing a wide array of security
>exposures.  There are many home devices that implement some level of home
>automation using an OS that can not be updated by their owners.  The
>proposed homenet using the mDNS to DNS proxy will make these devices
>visible to browsers for example and significantly challenge the
>effectiveness of existing firewall strategies.  In an ideal world, all
>devices should be secure when exposed to the Internet.  Our world is not
>ideal.
>
>_______________________________________________
>homenet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/homenet

---

From: Douglas Otis <[email-masked]>
Date: Fri, 4 Apr 2014 08:08:20 -0700

> security solutions we already have)

Dear Don,

Typical home networks could use link-local addresses for all internal devices without the filtering concern that effects enterprise level deployments.  In addition, the mDNS to DNS proxy scheme expects routable addresses and rather ugly name conversion and base domain assignments ignored in proposed specifications.

In comparison, Rbridge which can be introduced incrementally, permits continued use of link-local addressing and firewalls to avoid a difficult task of assessing network boundaries.  Devices using default mDNS names would not suddenly become indirectly visible and various network enabled displays that handle HDCP media still function within the home.

Even if Rbridge is not a viable solution, I would still request that we look at the security impact of any proposal - even if it is just in the form of a BCP that would be useful for deployment.

Regards,
Douglas Otis

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 4 Apr 2014 11:25:18 -0400

> Even if Rbridge is not a viable solution, I would still request that we look at the security impact of any proposal - even if it is just in the form of a BCP that would be useful for deployment.

Douglas,

The security impact of any proposal will be evaluated against the security section of the requirements draft found here:

http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/

If you feel as though there are additional security requirements to evaluate the solution space against that are not found in the requirements document, please contribute text to this section.

The documents generated by this WG (such as BCPs) are in response to the milestones in the WG charter found here:

http://datatracker.ietf.org/wg/dnssd/charter/

If you feel that additional documents need to be written and those documents are not covered in the current milestones, then you can propose changes to the charter for approval by the WG.

Thanks,
Tom

---

From: Don Sturek <[email-masked]>
Date: Fri, 04 Apr 2014 09:45:17 -0700

Hi Douglas,

I fail to see how turning all devices in a home into a flat link
local-addressed architecture meets the requirments in the homenet charter
(http://datatracker.ietf.org/wg/homenet/charter/), particularly around
home/guest networks plus a few other areas of the charter.

I also fail to see how turning all devices in a dnssd-type deployment into a
flat link local-addressed architecture meets the requirements in the dnssd
charter (http://datatracker.ietf.org/wg/dnssd/charter/) particularly around
enterprise networks (eg campus networks) or mesh networks.

Don

From:  Douglas Otis <[email-masked]>
Date:  Friday, April 4, 2014 8:08 AM
To:  Don Sturek <[email-masked]>
Cc:  <[email-masked]>, <[email-masked]>
Subject:  Re: [homenet] [dnssd] IETF-89 WG meeting minutes

Dear Don,

Typical home networks could use link-local addresses for all internal
devices without the filtering concern that effects enterprise level
deployments.  In addition, the mDNS to DNS proxy scheme expects routable
addresses and rather ugly name conversion and base domain assignments
ignored in proposed specifications.

In comparison, Rbridge which can be introduced incrementally, permits
continued use of link-local addressing and firewalls to avoid a difficult
task of assessing network boundaries.  Devices using default mDNS names
would not suddenly become indirectly visible and various network enabled
displays that handle HDCP media still function within the home.

Even if Rbridge is not a viable solution, I would still request that we look
at the security impact of any proposal - even if it is just in the form of a
BCP that would be useful for deployment.

Regards,
Douglas Otis

_______________________________________________ homenet mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/homenet

---

From: joel jaeggli <[email-masked]>
Date: Fri, 04 Apr 2014 09:54:34 -0700

> enterprise networks (eg campus networks) or mesh networks.

afaik dnssd wg/charter wouldn't need to exist if we were to constrain
the problem space to a single L2 domain. So i think we can stipulate
that the purpose is to work on a routed network.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 4 Apr 2014 11:17:31 -0700

The charter of the dnssd WG is "to develop a solution for extended, scalable DNS-SD."  The charter mentions routed networks several times, implying that any solution enveloped by the WG must be applicable to a routed network.

The use of TRILL and RBridges for the WG DNS-SD solution has been discussed at length on the mailing list.  Technically, this solution is not within the WG charter, as it implies a single L2 domain with no routing.  Pragmatically, the solution is undeployable, as it would require a complete reorganization of existing networks to solve the DNS-SD problem.

Therefore, TRILL/RBridges is out of scope for the dnssd WG, and will not be further discussed on the dnssd WG mailing list.

- Ralph

---

From: Douglas Otis <[email-masked]>
Date: Fri, 4 Apr 2014 11:41:09 -0700

> that the purpose is to work on a routed network.

Dear Joel,

Thank you for you feedback.  I am sure they represent what could be described as naive wishful desires.  Careful review of the Educause petition indicates their specific desires are NOT satisfied with layer 3 solutions due to additional constraints not within the vendor's purview of which they seem unaware.

The constraint limiting the scope of mDNS is due to typical bridge operation.  This constraint is better resolved using an _incremental_ layer 2 solution offering TLV table based MAC exchanges to permit routing at this level rather than use of layer 3 IP routing which has the effect of disabling desired services. 

Within our organization at a similar scale, this issue has been resolved using enterprise grade switches and non-trival configuration.  Use of Rbridge, as an example, eliminates complexity without weakening security where network boundaries become indeterminate.  At the home scale, no service filters should be needed.

At the Educause scale, filters for desired services will be needed.  In good conscience, this additional requirement should be part of a DNSSD work product!  Apple currently offers global DNS to locate devices based on Kerberos individual account authentications before publishing.  There is no reason a similar strategy can't be used within the home network by bundling requisite services to explicitly authenticate devices made visible via DNS.  This would also likely satisfy needs of networks unable to support mDNS.

Placement of translated mDNS resources MUST NOT be published into DNS due to many security considerations never reasonably satisfied.  mDNS should not be considered a safe method to publish internal resources when it impairs network boundary detection and potentially lists devices having default names indirectly accessible by remote actors.

Please consider security implications for deployers as part of this thought process.  Even if only published as a BCP, it would be most helpful.

Regards,
Douglas Otis

---

From: "Stephen Orr (sorr)" <[email-masked]>
Date: Fri, 4 Apr 2014 18:49:57 +0000

Hi Doug,

We currently have a draft published:
https://datatracker.ietf.org/doc/draft-bhandari-dnssd-mdns-gateway/

That addresses the service filtering component that you reference.

On 4/4/14, 2:41 PM, "Douglas Otis" <[email-masked]> wrote:

>Thank you for you feedback.  I am sure they represent what could be
>described as naive wishful desires.  Careful review of the Educause
>petition indicates their specific desires are NOT satisfied with layer 3
>solutions due to additional constraints not within the vendor's purview
>of which they seem unaware.
>
>The constraint limiting the scope of mDNS is due to typical bridge
>operation.  This constraint is better resolved using an _incremental_
>layer 2 solution offering TLV table based MAC exchanges to permit routing
>at this level rather than use of layer 3 IP routing which has the effect
>of disabling desired services.
>
>Within our organization at a similar scale, this issue has been resolved
>using enterprise grade switches and non-trival configuration.  Use of
>Rbridge, as an example, eliminates complexity without weakening security
>where network boundaries become indeterminate.  At the home scale, no
>service filters should be needed.
>
>At the Educause scale, filters for desired services will be needed.  In
>good conscience, this additional requirement should be part of a DNSSD
>work product!  Apple currently offers global DNS to locate devices based
>on Kerberos individual account authentications before publishing.  There
>is no reason a similar strategy can't be used within the home network by
>bundling requisite services to explicitly authenticate devices made
>visible via DNS.  This would also likely satisfy needs of networks unable
>to support mDNS.
>
>Placement of translated mDNS resources MUST NOT be published into DNS due
>to many security considerations never reasonably satisfied.  mDNS should
>not be considered a safe method to publish internal resources when it
>impairs network boundary detection and potentially lists devices having
>default names indirectly accessible by remote actors.
>
>Please consider security implications for deployers as part of this
>thought process.  Even if only published as a BCP, it would be most
>helpful.
>
>Regards,
>Douglas Otis  
>
>
>
>  
>
>
>  
>
>dnssd mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnssd

---

From: Kerry Lynn <[email-masked]>
Date: Sun, 6 Apr 2014 13:35:53 -0400

On Fri, Apr 4, 2014 at 11:25 AM, Tom Pusateri <[email-masked]> wrote:

>
> Dear Don,
>
> Even if Rbridge is not a viable solution, I would still request that we
> look at the security impact of any proposal - even if it is just in the
> form of a BCP that would be useful for deployment.
>
> Regards,
> Douglas Otis
>
>
> Douglas,
>
> The security impact of any proposal will be evaluated against the security
> section of the requirements draft found here:
>
> If you feel as though there are additional security requirements to
> evaluate the solution space against that are not found in the requirements
> document, please contribute text to this section.
>
> If you feel that additional documents need to be written and those
> documents are not covered in the current milestones, then you can propose
> changes to the charter for approval by the WG.
>
> Thanks,
> Tom
>
>
>

As I hope to get a WGLC-worthy draft of the Requirements doc out for review
in the next
few days, I would appreciate any text you can contribute to security
requirements.

Regards, -K-

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 6 Apr 2014 19:54:19 +0200

Hi Kerry,

I am preparing a threat model for this purpose as I was volunteer to do this
during the DNSSD meeting in London.
I am still in the mid of writing it and will soon publish it here.

Best,
Hosnieh

From: dnssd [mailto:[email-masked]] On Behalf Of Kerry Lynn
Sent: Sunday, April 06, 2014 7:36 PM
To: Tom Pusateri
Cc: [email-masked]; [email-masked] Group; Don Sturek; Douglas Otis
Subject: Re: [dnssd] [homenet] IETF-89 WG meeting minutes

Dear Don,

Regards,
Douglas Otis

Douglas,

If you feel as though there are additional security requirements to evaluate
the solution space against that are not found in the requirements document,
please contribute text to this section.

The documents generated by this WG (such as BCPs) are in response to the
milestones in the WG charter found here:

If you feel that additional documents need to be written and those documents
are not covered in the current milestones, then you can propose changes to
the charter for approval by the WG.

Thanks,
Tom

---

From: joel jaeggli <[email-masked]>
Date: Sun, 06 Apr 2014 21:13:10 -0700

On 4/4/14, 11:41 AM, Douglas Otis wrote:
>>> local-addressed architecture meets the requirments in the homenet
>>> charter (http://datatracker.ietf.org/wg/homenet/charter/),
>>> particularly around home/guest networks plus a few other areas of
>>> the charter.
>>> 
>>> I also fail to see how turning all devices in a dnssd-type
>>> deployment into a flat link local-addressed architecture meets
>>> the requirements in the dnssd charter
>>> (http://datatracker.ietf.org/wg/dnssd/charter/) particularly
>>> around enterprise networks (eg campus networks) or mesh
>>> networks.
>> 
>> afaik dnssd wg/charter wouldn't need to exist if we were to
>> constrain the problem space to a single L2 domain. So i think we
>> can stipulate that the purpose is to work on a routed network.
> 
> Dear Joel,
> 
> petition indicates their specific desires are NOT satisfied with
> layer 3 solutions due to additional constraints not within the
> vendor's purview of which they seem unaware.

Afaik we're operating under a wg charter not the educause petition and I
see no reason the discussion should be lititgated on basis of the later.

> layer 2 solution offering TLV table based MAC exchanges to permit
> routing at this level rather than use of layer 3 IP routing which has
> the effect of disabling desired services.

That would seem to arbirarily constrain the diameter to an l2 domain.
Sure you can build your topology that way, many if not most
organizations do not. They have good reasons for doing so.

> Within our organization at a similar scale, this issue has been
> resolved using enterprise grade switches and non-trival
> configuration.  Use of Rbridge, as an example, eliminates complexity
> without weakening security where network boundaries become
> indeterminate.  At the home scale, no service filters should be
> needed.
> 
> At the Educause scale, filters for desired services will be needed.
> In good conscience, this additional requirement should be part of a
> DNSSD work product!  Apple currently offers global DNS to locate
> devices based on Kerberos individual account authentications before
> publishing.  There is no reason a similar strategy can't be used
> within the home network by bundling requisite services to explicitly
> authenticate devices made visible via DNS.  This would also likely
> satisfy needs of networks unable to support mDNS.
> 
> Placement of translated mDNS resources MUST NOT be published into DNS
> due to many security considerations never reasonably satisfied.  mDNS
> should not be considered a safe method to publish internal resources
> when it impairs network boundary detection and potentially lists
> devices having default names indirectly accessible by remote actors.
> 
> Regards, Douglas Otis

---

From: Dave Taht <[email-masked]>
Date: Sun, 6 Apr 2014 21:32:18 -0700

On Fri, Apr 4, 2014 at 8:08 AM, Douglas Otis <[email-masked]> wrote:
> deployments.

The day that spanning tree or trill works well over wireless 802.11,
802.14, lte, etc will be the day that I start thinking it's suitable
for home use.

If the DCB folk were to try implementing their stuff on 802.11 in
particular, with it's 1mbit/sec
multicast rate, perhaps we would come to a meeting of the minds.

> In addition, the mDNS to DNS proxy scheme expects routable

They are, at least, consistent.

> displays that handle HDCP media still function within the home.

Service discovery and service access are different things. I don't mind
(that much) if some larger subset of people than I really want can
see that a resource such as "TRACI LORDS PR0N COLLECTION"
exists on the network, so long only the right people can actually
access it. [1]

But others may.

The scope of announcing that something exists may well need to be restricted
somehow.

> BCP that would be useful for deployment.

I agree that security needs to be looked at harder in homenet and dnssd.

I fail to see how rbridge solves anything from a security perspective
if you have home/guest lans, or any other natural division of link
layer technologies.

Please implement rbridge support over a busy wireless lan and
get back to us.

> Douglas Otis

[1] Yes, I've seen a resource announced like this. When mounted,
it contained an admonishment to not do illegal things, and a
bunch of pointers to things like: http://en.wikipedia.org/wiki/Great_Tit

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Douglas Otis <[email-masked]>
Date: Thu, 10 Apr 2014 16:53:10 -0700

> multicast rate, perhaps we would come to a meeting of the minds.

Dear Dave,

Sorry for the delay.  I am currently working on a security consideration update.

Data Center Bridging (for FCoE, etc), LTE (mobile wireless), 802.14 (multiple services over Cable-TV systems using ATM QOS), or Shortest Path Bridging (SPB per RFC6329) implemented with two ethernet encapsulating data paths -- 802.1ad (Provider Bridges) and 802.1ah (Provider Backbone Bridges).  These technologies are within providers' purview and not directly relevant to CPE.  Nevertheless, within a home or small office environment, Rbridge remains a viable incremental solution for combining disparate technologies. 

mDNS is not easily deployed at large scale over wireless without filtering.  Wifi has improved by offering mitigation strategies like multicast queuing per N beacons and multicast specific filters.  Even so, these strategies are unlikely needed at home.  I make extensive use of mDNS within a dense wireless spectrum containing dozens of nearby access points without difficulty while transferring multiple HD+ streams.  I would be interested in knowing what problems you are experiencing within your home.

Homenet documentation has largely ignored layer 2 protocols essential for defining network boundaries and for offering typical services such as remote displays.  These essential functions can not be replaced by any layer 3 strategy.  As such, layer 2 must be included in any homenet relevant security and operational consideration.

> They are, at least, consistent.

In expressing desires? 

> exists on the network, so long only the right people can actually

If a local printer is made available via proxy mDNS exposure, there is no way to secure it.   Many devices cannot be updated, cannot be secured, and do not offer authenticated or authorized-only access.  These are the kinds of issues that should be raised and discussed, even if only in a BCP document.  By using automatically assigned routable IP addresses, thwarting stateful firewall protections becomes far easier.  Many devices not suitable for Internet exposure will suddenly lack the benefit of only having the typical link-local address.  For mDNS, a service proves it resides on a local link by answering link-local multicast queries.  A proxy mDNS resource can never offer that assurance nor can it be expected to.

> if you have home/guest lans, or any other natural division of link

The point of a guest LAN is to impose access barriers except to the Internet.  There are plenty of Internet services able to bridge between two different realms.  Such as cleaning up infected systems with only access via a satellite link using UDP communications, for example. :^)

> Please implement rbridge support over a busy wireless lan and

We have implemented network enabled display access by using non-trivial VLAN configurations well beyond what would be reasonable within a home.  Rbridge would have greatly eased configuration efforts.  Recently non-backward compatible changes have been implemented in Rbridge extensions to better facilitate such efforts.

Regards,
Douglas Otis

---

From: Henning Rogge <[email-masked]>
Date: Fri, 11 Apr 2014 08:41:29 +0200

> mDNS is not easily deployed at large scale over wireless without filtering.  Wifi has improved by offering mitigation strategies like multicast queuing per N beacons and multicast specific filters.…

Its not only mDNS, its also ARP, ICMPv6 and other "linklocal
multicast" protocols that work badly over large Wifi linklayer
domains. Linklocal normally means "fast, cheap, atomic, in-order"...
if you replace it with a large wireless layer-2 domain, it becomes
something very different.

Henning Rogge

---

From: "Guangqing Deng" <[email-masked]>
Date: Thu, 17 Apr 2014 14:37:28 +0800

Nowadays, since people are always keen to look for so called "cheap, fast, ...," wifi access points in public places like restaurant, it is reported that some forged access points appear to attract people to access Internet network through them where the private information like credit card number and password may be collected by those bad access points, which may be an issue needing consideration when deploying mDNS.

Guangqing Deng
CNNIC 
 
From: Henning Rogge
Date: 2014-04-11 14:41
To: Douglas Otis
CC: dnssd; HOMENET; Don Sturek; Dave Taht
Subject: Re: [dnssd] [homenet] IETF-89 WG meeting minutes

Henning Rogge