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

["Ray Hunter (v6ops)" <[e-mail]>]

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>