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

From: Douglas Otis <[email-masked]>
Date: Tue, 1 Apr 2014 15:12:43 -0700

On Mar 28, 2014, at 7:27 AM, Ralph Droms (rdroms) <[email-masked]> wrote:

> I've posted minutes from th eLondon meeting; thanks to Stuart for preparing the notes and to everyone who contributed to the etherpad notes.
> 
> Please review the minutes and let us know if you need to suggest any additions/corrections/deletions.

Dear Ralph,

A few corrections were made. As said in a prior email, the Educause petition issue can and will soon be solved using Bluetooth. Homenet should also consider impacts of HDCP restrictions imposed on network enabled displays.  Allowing even one hop removes exceptions allowed for local sources.

UTF-8 alone will not solve look-alike attacks, but RBridge does.  As was said, there are existing VLAN and RBridge products offering safe solutions addressing the Educause petition as a means to filter those services that warrant being extended.  As such, this WG should also endeavor to define requisite data structures to implement these filters in a standardized manner.

It should also be noted RBridge plays well with mesh networks unlike spanning tree solutions cobbled together using Homenet's configuration strategy. 

Regards,
Douglas Otis

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 2 Apr 2014 01:26:12 +0300

On 2.4.2014, at 1.12, Douglas Otis <[email-masked]> wrote:
> It should also be noted RBridge plays well with mesh networks unlike spanning tree solutions cobbled together using Homenet’s configuration strategy. 

As far as I understand, rbridge == trill == ISIS; current homenet plan seems to be ISIS/OSPF/some other routing protocol. Please explain where spanning tree comes into the picture ;) (homenet I play with currently has Babel with prefixes assigned using ‘configuration strategy’.)

I’m curious what makes ISIS in rbridge (which isn’t really designed for meshy networks) superior to Babel, which is designed for meshy networks. 

Cheers,

-Markus

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 1 Apr 2014 19:04:23 -0400

> As was said, there are existing VLAN and RBridge products offering safe solutions addressing the Educause petition as a means to filter those services that warrant being extended.  As such, this WG should also endeavor to define requisite data structures to implement these filters in a standardized manner.
> 

Douglas,

I don't want to get into an argument about this but there are many routed networks that exist where RBridge is not a viable solution and your continual insistence that it is is wearing thin.

We are looking for a layer 2 agnostic solution that works across a layer 3 network.

I hope that you can focus your contributions to the WG with this in mind.

I don't believe the WG should generally be defining data structures. This is more commonly an implementation issue.

Thanks,
Tom

---

From: Douglas Otis <[email-masked]>
Date: Wed, 2 Apr 2014 01:16:48 -0700

> I don't believe the WG should generally be defining data structures. This is more commonly an implementation issue.

Dear Tom and Markus,

You can find an overview at http://en.wikipedia.org/wiki/TRILL_%28computing%29

There is more than one way to solve mDNS issues.  Ignoring layer 2 solutions such as VLAN or Rbridge transparent to IP routing protocols overlooks solutions better from security, performance, and functionality standpoints (offering use of link-local, HDCP, mesh support, name collision resolution, etc).  An approach similar to those offered in existing commercialized products.  With better scaling properties, Rbridge can be implemented by typical home networking equipment without introducing bottlenecks.  An important feature when handling an explosion of network nodes supported by constrained resources.

Forgive efforts made with http://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink's introductory description of a typical bridge.  Any such scheme forwards packets based on source MACs.  Since a typical bridge is unable to detect routing loops, unbeknownst perhaps, a spanning tree algorithm must block all but one possible intervening port. This path reduction causes otherwise unnecessary bottlenecks that can not be overcome by IP routing.

RBridge offers a means to secure devices in extensive deployments.  Incremental deployment is easier than VLANs without confronting scaling issues in typical home network environments.  This approach also works within large corporate environments when reasonable limits are placed on forwarded services.  Don't expect security will be maintained while permitting autonomous mDNS name publishing in DNS with link-local addresses reassigned or pinned to routable addresses as a means to satisfy IP based mDNS proxy schemes.

Proposed mDNS proxy extensions also overlook serious visual and domain name encoding issues.  On the other hand, layer 2 solutions retain the integrity of firewall rules and can resolve naming conflicts within local networks by relying on existing conflict resolution strategies without affecting DNS or link-local addressing.  This approach also avoids consulting public suffix lists to establish encoding boundaries between DNS and mDNS.

It seems inappropriate to prematurely conclude solutions should be limited to IP just because doing so appears to represent a component within a currently incomplete and underdeveloped strategy.

Regards,
Douglas Otis

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 2 Apr 2014 11:43:53 +0300

> You can find an overview at http://en.wikipedia.org/wiki/TRILL_%28computing%29

Dear Douglas,

<SARCASM[1]>

How wonderful! Thank you so much! How did you find this? This internet is so confusing..
Why didn’t they provide pointers to it in the {trill,dnssd,<some other>} WG when I was there? 

</SARCASM[1]>

I think the whole point of the exercise is to discuss cases where single subnet is not applicable, and as (from L3 point of view) TRILL network is a single subnet, I don’t really see where you are going with this. I would hope that by now anyone knows that on L2, STP or almost anything works for small network. TRILL works for larger network too, which is nice. 

What charter says, is among other things, mixed link types, routed networks, etc. TRILL is L2 routing of sorts, and as traditional routing is in L3. I don’t think you can seriously argue that _every_ link type is going to be run by RBridges with TRILL, or if you do, I have some things I could sell you..

Your marketing-ese arguments for security, scalability, and anything else can be applied to flying pigs too - given sufficient thrust, they can fly, but should they? There are reasons why we try to keep different layers in the network stack (despite the random violations that occur, and sticking everything in L2 and assuming everyone uses same one sounds highly optimistic.

Cheers,

-Markus

P.S. I’d love to see your component with complete and developed strategy! Marketing makes me buzz with joy!

[1] http://en.wiktionary.org/wiki/sarcasm

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 Apr 2014 10:19:28 -0400

Douglas, forgive me if this is a naive question, but isn't the problem of doing DNSSD on flat LANs already solved with plain old mDNS?  If you are satisfied with this solution, I don't think you need what this working group is working on.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 2 Apr 2014 13:21:01 -0700

> Your marketing-ese arguments for security, scalability, and anything else can be applied to flying pigs too - given sufficient thrust, they can fly, but should they? There are reasons why we try to…

Dear Markus,

If you have already decided the only solutions for solving issues similar to those expressed in the Educause petition can only be achieved at layer 3, then you are correct.  In that case RBRIDGE is not required, however I will oppose a L3 solution on security grounds.

I would, however, ask you to please take a closer look at RBRIDGE and TRILL.  Some of your statements are not correct, and I do think that this will offer a good solution for Educause and other problems.

Regards,
Douglas Otis

---

From: Douglas Otis <[email-masked]>
Date: Wed, 2 Apr 2014 13:55:01 -0700

> Douglas, forgive me if this is a naive question, but isn't the problem of doing DNSSD on flat LANs already solved with plain old mDNS?  If you are satisfied with this solution, I don't think you ne…

Dear Ted,

Rbridge does not represent a single network segment nor a flat LAN.  Within larger deployments it is common find mDNS filtering.  In particular, we should look at mDNS filtering as a security enhancement.  Discussing some default rules, or at least guideline (BCP), would be appreciated by the community I think.

Regards,
Douglas Otis

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Thu, 3 Apr 2014 00:08:56 +0000

Douglas - As I understand trill and a trill deployment, it would provide a flat layer-2 domain, avoiding any routing and allowing DNS-SD/mDNS to extend between all network devices.

If I have that right, it doesn’t represent a viable solution for the work the dnssd WG is chartered to complete.  Any solution has to accommodate layer-3 interconnections, specifically operating between devices that are interconnected through routers.

If I’m not understanding your proposed architecture, I hope you’ll give me some more detailed explanation so I can get it.

- Ralph

---

From: James Andrewartha <[email-masked]>
Date: Thu, 3 Apr 2014 10:31:17 +0800

> I would, however, ask you to please take a closer look at RBRIDGE and TRILL.  Some of your statements are not correct, and I do think that this will offer a good solution for Educause and other pro…

So what should those of us whose switch vendor has committed to SPB
instead of TRILL do? Forklift replace every single switch just so we can
have mDNS working?

-- 
James Andrewartha
Network & Projects Engineer
Christ Church Grammar School
Claremont, Western Australia
Ph. (08) 9442 1757
Mob. 0424 160 877

---

From: Garret Peirce <[email-masked]>
Date: Wed, 2 Apr 2014 23:43:15 -0400

As a participant in the Educause petition, I wanted to comment to disagree
with the statement mentioning:
"....the Educause petition issue can and will soon be solved using
Bluetooth."

The groups charter directly references the Educause petition.
Consider the simple case of a wireless host trying to locate a wired device
on a different IP subnet.
Any adoption of the comment above minimalizes the petitions concerns and
is unfortunate to see.
As an aside, I feel the use of bluetooth could create more managed service
support issues than it solves.

Garry Peirce
University of Maine System

On Wed, Apr 2, 2014 at 8:08 PM, Ralph Droms (rdroms) <[email-masked]>wrote:

> Douglas - As I understand trill and a trill deployment, it would provide a
> flat layer-2 domain, avoiding any routing and allowing DNS-SD/mDNS to
> extend between all network devices.
>
> If I have that right, it doesn't represent a viable solution for the work
> the dnssd WG is chartered to complete.  Any solution has to accommodate
> layer-3 interconnections, specifically operating between devices that are
> interconnected through routers.
>
> If I'm not understanding your proposed architecture, I hope you'll give me
> some more detailed explanation so I can get it.
>
> - Ralph
>
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd
>

-- 
Garry Peirce
Network Architect
Networkmaine, University of Maine System

---

From: Douglas Otis <[email-masked]>
Date: Thu, 3 Apr 2014 14:08:53 -0700

On Apr 2, 2014, at 8:43 PM, Garret Peirce <[email-masked]> wrote:

> As a participant in the Educause petition, I wanted to comment to disagree with the statement mentioning:
> "....the Educause petition issue can and will soon be solved using Bluetooth."
> 
> Consider the simple case of a wireless host trying to locate a wired device on a different IP subnet.
> Any adoption of the comment above minimalizes the petitions concerns and is unfortunate to see.
> As an aside, I feel the use of bluetooth could create more managed service support issues than it solves.

Dear Garret,

Thank you for your thoughtful response.

As a reference for others, here is a link to the petition:
https://www.change.org/petitions/from-educause-higher-ed-wireless-networking-admin-group

In condensed summary (modifying vendor specifics) this requests:
 - support for enterprise wireless encryption and authentication (WPA2-Enterprise)
 - to utilize enterprise Authentication, Authorization, and Accounting (AAA) services
 - for HDCP networked displays be accessible by client devices across multiple IPv4 and IPv6 sub-nets 
 - be scalable over thousands of mDNS clients and devices
 - work across wired and wireless networks from different vendors
 - not significantly impact network traffic (wired and wireless) 
 - be manageable at enterprise scale 
 - upgrades with enterprise level equipment is permitted

In essence, a strategy for consumer products to meet enterprise needs after minimal upgrade.

Our organization's facilities support thousands of employees making extensive use of these products. Fortunately they were deployed on enterprise grade VLAN capable switches which enable _all_ requisite solutions. :^)

Here is a reference to some media provider's restrictions:
http://www.digital-cp.com/files/static_page_files/DE68907C-1A4B-B294-D034F42A37680F2A/HDCP%202_2_IIA_Errata_v2%20(2).pdf

In condensed summary, requirements include:
 - authentication of HDCP Receivers to their _immediate_ upstream connection to an HDCP Transmitter
 - link-visible behavior of HDCP Devices implementing specified state machine be identical

If interpreted correctly, HDCP allows up to four licensed repeaters.  This suggests two licensed repeaters may exist between client and display counting the licensed client and display network interface.

Note: The bluetooth extensions being added must be enabled.  This clearly addresses consumer markets without any hardware upgrade.  HDCP is a significant concern not met by interposing generic routers and layer 3 solutions.  The same is true for Airprint (due to restrictions imposed by Apple and not a consortium of media providers.)

Also commercial products offering functional solutions for these requirements introduce specific mDNS filters that remain ignored.  

> On Wed, Apr 2, 2014 at 8:08 PM, Ralph Droms (rdroms) <[email-masked]> wrote: