Subject: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03

From: Tim Chown <[email-masked]>
Date: Thu, 17 Mar 2016 22:36:47 +0000

Dear dnssd WG participants,

We are initiating a WG Last Call today on draft-ietf-dnssd-hybrid-03, as can be found at https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03 <https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03>.

The call runs for two weeks, and will thus close on Thursday 31st March.

Please send any comments (including indications of support for progression of the document as is) to the [email-masked] list. This draft will not be advanced for publication unless there is sufficient response and support from the WG.  And, of course, any substantive comments on the draft are strongly encouraged as well. We are aware of a small number of minor outstanding comments from the list, but will consider these as part of the WGLC process.

We will discuss the comments arising from the WGLC in the WG meeting in BA on Monday 4th April.

Abstract

   Performing DNS-Based Service Discovery using purely link-local
   Multicast DNS enables discovery of services that are on the local
   link, but not (without some kind of proxy or similar special support)
   discovery of services that are outside the local link.  Using a very
   large local link with thousands of hosts facilitates service
   discovery, but at the cost of large amounts of multicast traffic.

   Performing DNS-Based Service Discovery using purely Unicast DNS is
   more efficient and doesn't require excessively large multicast
   domains, but requires that the relevant data be available in the
   Unicast DNS namespace.  This can be achieved by manual DNS
   configuration (as has been done for many years at IETF meetings to
   advertise the IETF Terminal Room printer) but this is labor
   intensive, error prone, and requires a reasonable degree of DNS
   expertise.  The Unicast DNS namespace can be populated with the
   required data automatically by the devices themselves, but that
   requires configuration of DNS Update keys on the devices offering the
   services, which has proven onerous and impractical for simple devices
   like printers and network cameras.

   Hence, to facilitate efficient and reliable DNS-Based Service
   Discovery, a compromise is needed that combines the ease-of-use of
   Multicast DNS with the efficiency and scalability of Unicast DNS.

Thanks,

Ralph and Tim
dnssd WG co-chairs

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Fri, 25 Mar 2016 15:53:57 +0100

I have read this draft.

I find the work interesting, although I'm not yet convinced of the 
chosen compromises with respect to use of this draft in Homenet.

Specifically:
1. I'm concerned that there's a hard coded tie between a "zone" and a 
"link" which might lead to a lot of noise.

Zone enumeration appears to be performed by retransmission of queries to 
the relevant proxy on the remote link.

If a specialised end node that is a member of particular zone e.g. "A3 
printers" moves to another building, there's no mechanism to say that 
the associated enumeration zone should also move with the device. In 
other words, the default is that all queries for all zones are probably 
going to have to be forwarded to ALL links in the (common) namespace.

That could lead to a lot of unnecessary noise on an enterprise scale 
network, and which could also be killing for Homenet devices that are 
trying to be energy efficient.

If I look back at the source of inspiration of zeroconf networking, 
Appletalk II, there was a ZIP (Zone Information Protocol) to enable a 
logical clustering of services, that was independent of network numbers 
and links.

2. I'm concerned at the potential for protocol storms.

AFAICS There's no dedicated field in the protocol that tracks the 
ultimate source and destination of forwarded queries and replies.

If a device is placed somewhere in the network that does not adequately 
understand how the hybrid mechanism works, and either queries or replies 
are inappropriately "leaked" between hybrid proxies, this could cause 
incorrect re-transmission of queries and responses and ultimately a 
packet storm.

I also don't see how if two hybrid proxies are present and active on a 
link, they are going to be able to distinguish between original 
multicast requests from an end node on this link, and forwarded requests 
(potentially also using mulitcast) received from off-link via the other 
hybrid proxy.

That suggess to me the hybrid proxies have to be "topology aware" which 
is a tall order. Unless of course I've misunderstood the forwarding 
mechanism.

As a comparison, when DHCPv6 messages are relayed (by a DHCPv6 relay) a 
new explicit relay forwarding option is pushed onto the front of the 
message, and popped off the reply. That ensures that the forward (via 
RELAY-FORW) and reverse path (via RELAY-REPL) are respected at all times.

3. There doesn't seem to be any mechanism to be able to track replies 
with respect to queries. Multicast queries appear to result in unicast 
responses, and vice versa. It isn't clear from the draft if this may 
cause a security issue. How can the recipient of a unicast reply 
validate that it is a valid reply to a query sent via this proxy? So for 
example, could a rogue node on bldgd2 could answer on behalf of a node 
on bldg1?

regards,

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>