Subject: [mdnsext] draft-lynn-mdnsext-requirements-00

From: Tim Chown <[email-masked]>
Date: Fri, 12 Oct 2012 12:28:30 +0100

Just a heads up:

http://tools.ietf.org/html/draft-lynn-mdnsext-requirements-00

Discussion on the problem statement is encouraged.

Tim

---

From: Tom Pusateri <[email-masked]>
Date: Sat, 27 Oct 2012 21:54:18 -0400

> Discussion on the problem statement is encouraged.

I've added some text to section 2.1 and section 5. Please feel free to use it or reject it.
My comments are prefaced with =>

2.1.  Multilink Naming and Discovery

   While DNS-SD/mDNS is well-suited for zero-configuration of naming and
   discovery of hosts and services on a local link, users are frustrated
   by the inability to discover services on other subnets.
                                                  ^^^
=> insert "IP" subnets
=>
=> Multicast DNS Queries (and often Responses) are sent to either the IPv4 multicast
=> address 224.0.0.251 or the IPv6 multicast address FF02::FB.
=> These IP multicast addresses are considered part of the link-local range and are not
=> intended to be forwarded onto another IP subnet by a multicast router.

   DNS-SD is a conventional use of existing DNS Resource Records and
   can, in practice, be deployed over unicast DNS.  However, this mode

Lynn & Cheshire          Expires April 13, 2013                 [Page 3]
Internet-Draft            MDNSEXT Requirements              October 2012

   is not commonly used.
   
=> However, this wide-area mode is not commonly used. Issues with wide-area bonjour include:
=> 1. deploying dynamic update capabilities for the main DNS domain or deploying parallel DNS infrastructure for a separate dynamic domain or sub-domain.
=> 2. familiarity with troubleshooting wide-area bonjour with existing tools.
=> 3. missing wide-area support in embedded devices and alternate implementations

5.  Security Considerations

   [TBD]
   
=> Extending service discovery across IP subnets, opens the door to new security threats.
=> Link-local threats are fairly well understood and typically isolated in scope. Wide-area
=> service discovery threats were mostly limited to dynamic DNS updates or the restrictions
=> placed on responses.
=> When service discovery is replicated across multiple IP subnets, forwarding restrictions are
=> more difficult to contain and verify. Queries and responses may be sent beyond administrative
=> boundaries. Cryptographic services may be needed to protect against leaks or malicious intent.

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 29 Oct 2012 10:57:50 -0400

Hi Tom,

Thanks for your comments.  Questions/comments inline...

>    by the inability to discover services on other subnets.
This may more precisely be "inability to discover services on other links".

> Is this not clear from multicast scoping rules?  I will add a reference to
make
that clear.  In the case of a multicast IPv6 query with a link-local source
address,
forwarding of the packet is of no use as the responses will be
un-routable.  However,
it might be possible e.g. for a name proxy running on a router to terminate
one LL
request and initiate a new one on a different link.

> => 1. deploying dynamic update capabilities for the main DNS domain or
> deploying parallel DNS infrastructure for a separate dynamic domain or
> sub-domain.

Do you know of problems with existing tools or are you saying that people
are generally
unfamiliar with PTR, SRV, and TXT RRs?

> This is likely with any service discovery protocol.  I think our viewpoint
is that to the
extent embedded devices will support DNS name resolution, mdnsext will be an
incremental change.

> => service discovery threats were mostly limited to dynamic DNS updates or

So here I think I'm missing your point.  Once DNS-SD records are inserted
in a global DNS
zone, why does this pose more or less of a security threat than any other
DNS record?  Do
you anticipate authentication issues outside those addressed by DNSSEC?
Restrictions
placed on responses other than those normally handled by split-horizon DNS?

Re: dynamic DNS updates, many current installations seem to rely on DHCP to
update
DNS records on behalf of end hosts.  That doesn't seem like a particularly
high bar for
authorization (of the records appearing in the zone in the first place)
unless there's some
L2 authentication of the host to the DHCP server (or VLAN containing the
DHCP server)
as a pre-condition to L3 enrollment.

I think the question of how to authorize mDNS services for incorporation
into a wide-area
DNS-SD zone is an interesting one if simply being present on the network is
deemed to
be insufficient from a trust perspective.

> Wide-area service discovery seems to me very similar to global name
resolution.
Granted, you do have more information about the host other than just its
address
(service port, for one thing) but the ability to mutually
authenticate/connect to the
service is surely an application issue.  Again, I think I may be missing
your point.

Regards, -K-

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

---

From: "Johnson, Neil M" <[email-masked]>
Date: Mon, 29 Oct 2012 17:58:17 +0000

"Do you know of problems with existing tools or are you saying that people are generally
unfamiliar with PTR, SRV, and TXT RRs?"

The problem is not knowing what those records are, the problem is that there very little documentation from vendors (Apple) about what to put in them (the TXT record specifically).

If you snoop the TXT record for the AppleTV, for instance, it contains the MAC address of the AppleTV, something that looks like the software version, plus other undocumented data.  This makes maintaing static DNS-SD records problematic (do you have to update DNS every time you do a software upgrade or swap hardware ?).

It appears vendors (Apple) are relying on the local-link to advertise dynamic data that can't be easily captured and maintained in static records, hence the need for some other mechanism to do updates.

-Neil

--
Neil Johnson
Network Engineer
The University of Iowa
Phone: 319 384-0938
Fax: 319 335-2951
Mobile: 319 540-2081
E-Mail: [email-masked]

From: Kerry Lynn <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 29, 2012 9:57 AM
To: Tom Pusateri <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Tim Chown <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mdnsext] draft-lynn-mdnsext-requirements-00

Hi Tom,

On Sat, Oct 27, 2012 at 9:54 PM, Tom Pusateri <[email-masked]<mailto:[email-masked]>> wrote:

Is this not clear from multicast scoping rules?  I will add a reference to make
that clear.  In the case of a multicast IPv6 query with a link-local source address,
forwarding of the packet is of no use as the responses will be un-routable.  However,
it might be possible e.g. for a name proxy running on a router to terminate one LL
request and initiate a new one on a different link.

   is not commonly used.

Do you know of problems with existing tools or are you saying that people are generally
unfamiliar with PTR, SRV, and TXT RRs?

This is likely with any service discovery protocol.  I think our viewpoint is that to the
extent embedded devices will support DNS name resolution, mdnsext will be an
incremental change.

   [TBD]

So here I think I'm missing your point.  Once DNS-SD records are inserted in a global DNS
zone, why does this pose more or less of a security threat than any other DNS record?  Do
you anticipate authentication issues outside those addressed by DNSSEC?  Restrictions
placed on responses other than those normally handled by split-horizon DNS?

Re: dynamic DNS updates, many current installations seem to rely on DHCP to update
DNS records on behalf of end hosts.  That doesn't seem like a particularly high bar for
authorization (of the records appearing in the zone in the first place) unless there's some
L2 authentication of the host to the DHCP server (or VLAN containing the DHCP server)
as a pre-condition to L3 enrollment.

I think the question of how to authorize mDNS services for incorporation into a wide-area
DNS-SD zone is an interesting one if simply being present on the network is deemed to
be insufficient from a trust perspective.

Wide-area service discovery seems to me very similar to global name resolution.
Granted, you do have more information about the host other than just its address
(service port, for one thing) but the ability to mutually authenticate/connect to the
service is surely an application issue.  Again, I think I may be missing your point.

Regards, -K-

_______________________________________________
mdnsext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mdnsext

---

From: Jens Alfke <[email-masked]>
Date: Mon, 29 Oct 2012 11:12:50 -0700

On Oct 29, 2012, at 10:58 AM, "Johnson, Neil M" <[email-masked]> wrote:

> If you snoop the TXT record for the AppleTV, for instance, it contains the MAC address of the AppleTV, something that looks like the software version, plus other undocumented data.  

This is valid behavior. The schema of a TXT record is specific to that service type, and there’s no requirement that all service types publicly document their schema.

> This makes maintaing static DNS-SD records problematic (do you have to update DNS every time you do a software upgrade or swap hardware ?).

mDNS service TXT records are by definition dynamic, and plenty of services take advantage of that. It would be inappropriate for an external agent to try to capture such a record and freeze it in a static DNS entry. It’s up to the owner of the record to update it.

—Jens

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 29 Oct 2012 17:23:56 -0400

> This may more precisely be "inability to discover services on other links".

Well, bridged "links" will propagate service discovery. "subnets" is generic enough that I thought it needed qualified.
IP subnets gives the distinction that link-local IP Multicast will not cross. Not a big deal though either way.

> request and initiate a new one on a different link.

You don't have to specify the addresses but I'm not sure that the average reader understands the fact that 224.0.0/24 destinations do not get forwarded by multicast routers but other 224/4 addresses will be forwarded. But if you think this is obvious, that's fine.

> unfamiliar with PTR, SRV, and TXT RRs?

I think both. Tools like dig are not well understood by users who can't see their apple tv on their ipad. Dynamic updates are still forbidden many places.

> extent embedded devices will support DNS name resolution, mdnsext will be an

Agreed. If wide-area bonjour was sufficient, we would not be having this BOF. I was just trying to summarize why wide-area bonjour doesn't appear to be sufficient. Adoption is relevant.

> placed on responses other than those normally handled by split-horizon DNS?

You are correct, DNS-SD dynamic updates are well understood. I think we understand the security implications of link-local mDNS and global DNS dynamic updates.
But once we try forwarding queries and responses across IP subnets, we've added a new threat. Maybe this isn't the right place for this since it isn't be proposed here.
It was merely a comment to solutions that are being used today as application gateways forward link-local queries and responses. It will only be a requirement if that solution is arrived at.

Therefore, you can just ignore this section.

Thanks for the feedback,
Tom