Subject: [mdnsext] mDNS relay agent idea

From: Eelco Chaudron <[email-masked]>
Date: Fri, 9 Nov 2012 21:46:50 +0100

Inline with the other emails send around, I would suggest using something similar to the bootp relay approach.
Where a relay agent can unicast forward the service request to other network segments. This should be done in such a way it will work with all the existing mDNS querier clients out there.

The mDNS relay service can run on a switch, router, or purposely build device/server, as long as it has connections to multiple network segments.
Here are some ideas that came to mind during my 8 hour flight back home:

- The relay agent will advertise it’s service on all the network segments connected using mDNS.
- All the relay agents on the same segment can than form adjacencies and determine the designated forwarded for the segment. The agent with the most interfaces has the highest priority, tie breaker could be the IP address.
- All relay agents in the domain can form adjacencies, and build a link state table, so they know all reachable segments (and their unicast DF address)
- Adjacencies should allow for packet signature option (MAC), but should be off by default
- The designated forwarded will build a cache of services for the segment it’s the designated forwarder for (others might also do this in case of failure of the DF, but they should not include the entries in a response to avoid duplicates).
- If a DF sees a DNS (service) query it will forward it as unicast to all known FRs. Who will reply on behave of the service using unicast.
- Note for this to work the services should be reachable trough the routed network. This should be verified if a relay agent is answering on behave of a service. It does not make sense to reply with link local addresses.

Note that these are all random thoughts, and I was not thinking clear, but it’s a nice discussion starter to get some activity on the mailing list ;)

//Eelco

DISCLAIMER:
This e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient.  If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed.

---

From: Matthew Gast <[email-masked]>
Date: Sat, 10 Nov 2012 03:46:11 +0000

Eelco,

I think many of the vendor-specific products mentioned on Tuesday do
something like kinda sorta like this, at least in terms of building a
cache of services that are specific to a link.  There needs to be a way of
building adjacencies across widely separated networks.  I don't think it's
a safe assumption that relay agents will exist on every IP subnet so there
will be a way to build a chain of relay agents across the network.  It's
possible that network administrators will want to take some services from
point A and put them at point B, and if points A & B are widely
distributed across the network, then using mDNS (link-local) adjacencies
will not share across multiple hops without configuration.  I don't think
that's a big problem since it's not hard to configure, but perhaps we
could define a well-known service to bootstrap the adjacency creation
process.

Caching services is probably not optimal, though, since services can come
and go and the DF may not get immediate updates.  Maintaining state at the
DF probably consumes some amount of network capacity; more importantly, DF
cache maintenance pinging away at the network may obstruct power-saving
operations.

In your sixth step, is the "DNS (service) query" an mDNS query or a
unicast query?  If the former, I like the implicit transformation of a
multicast query into a unicast response for wireless LAN operations, but
it may impede maintenance of link-local service lists on all other
listeners.

Matthew

On 11/9/12 12:46 PM, "Eelco Chaudron" <[email-masked]>
wrote:

>Where a relay agent can unicast forward the service request to other
>network segments. This should be done in such a way it will work with all
>the existing mDNS querier clients out there.
>
>The mDNS relay service can run on a switch, router, or purposely build
>device/server, as long as it has connections to multiple network segments.
>- The relay agent will advertise it¹s service on all the network segments
>connected using mDNS.
>- All the relay agents on the same segment can than form adjacencies and
>determine the designated forwarded for the segment. The agent with the
>most interfaces has the highest priority, tie breaker could be the IP
>address.
>- All relay agents in the domain can form adjacencies, and build a link
>state table, so they know all reachable segments (and their unicast DF
>address)
>- The designated forwarded will build a cache of services for the segment
>it¹s the designated forwarder for (others might also do this in case of
>failure of the DF, but they should not include the entries in a response
>to avoid duplicates).
>- If a DF sees a DNS (service) query it will forward it as unicast to all
>known FRs. Who will reply on behave of the service using unicast.
>- Note for this to work the services should be reachable trough the
>routed network. This should be verified if a relay agent is answering on
>behave of a service. It does not make sense to reply with link local
>addresses.
>
>
>Note that these are all random thoughts, and I was not thinking clear,
>but it¹s a nice discussion starter to get some activity on the mailing
>list ;)
>
>
>//Eelco
>
>
>DISCLAIMER:
>This e-mail and any attachments to it may contain confidential and
>proprietary material and is solely for the use of the intended recipient.
>Any review, use, disclosure, distribution or copying of this transmittal
>is prohibited except by or on behalf of the intended recipient.  If you
>have received this transmittal in error, please notify the sender and
>destroy this e-mail and any attachments and all copies, whether
>electronic or printed.
>_______________________________________________
>mdnsext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mdnsext

---

From: Eelco Chaudron <[email-masked]>
Date: Mon, 12 Nov 2012 13:26:46 +0100

> cache maintenance pinging away at the network may obstruct power-saving

Yes, this might be a bit cumbersome when services are instantly removed (power down of a printer). But I guess this issue exists with the wide area DNS approach because service will need to timeout also.

> it may impede maintenance of link-local service lists on all other

I meant to say mDNS, and yes the idea was to forward the multicast, unicast to the DFs.

DISCLAIMER:

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Nov 2012 12:57:50 -0500

In addition to caching the service discovery, do any of the various
products also provide proxying of the service itself, and/or providing
additional access control?

I'm thinking specifically of a case where the math department on
floor 4 want to print to the nice colour printer that belongs to the
history department on the same floor.  But, not only is service
discovery interrupted by routers/NAT/firewall, but so actually is
movement of packets.  (Of course, IPv6 changes this... a bit)

-- 
Michael Richardson
-on the road-

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 12 Nov 2012 10:12:05 -0800 (PST)

Hi Michael,

> additional access control?

  I'm unaware of a product that proxies the service itself but I
know that our (Aruba's) product provides additional access
control based on the (authenticated) identity of the discoverer
and the access rule for the device he or she is trying to discover.

  Dan.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 12 Nov 2012 15:18:17 -0500

Hi,

> Inline with the other emails send around, I would suggest using something similar to the bootp relay approach.

This assumes (as have several other messages) that "extend mDNS beyond
the local link" is the goal.  Given the features we want to suppport,
it is very far from clear to me that that is the right goal.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Evan Hunt <[email-masked]>
Date: Mon, 12 Nov 2012 21:20:17 +0000

On Mon, Nov 12, 2012 at 03:18:17PM -0500, Andrew Sullivan wrote:
> > Inline with the other emails send around, I would suggest using
> > something similar to the bootp relay approach.
> 
> the local link" is the goal.  Given the features we want to suppport, it
> is very far from clear to me that that is the right goal.

Not exactly; AIUI the suggestion here is to keep mDNS itself link-local,
but put an agent at the link boundary that can take (some configurable
subset of?) service information from one side and retransmit it to another,
just as DHCP is link-local but can be relayed across links.  I'm not sure
this requires any modification to mDNS at all.  It may be a minimally-
invasive way to meet the service-discovery requirements of EDUCAUSE etc,
if it scales well enough on large/complex networks.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Ron J <[email-masked]>
Date: Mon, 12 Nov 2012 16:50:50 -0500

I agree Andrew. While that is the goal for some things, I don't think merely extending mDNS in the ways currently discussed will serve all the concerns of the Educause members, but should thrill other Enterprise users.

It's easy enough to tweak routers currently to broadcast mDNS across different subnets (lots of companies are doing this). The bigger problem, as far as universities are concerned, seems to be user authentication (which the Aruba guy mentioned they have a solution for) and also binding a user's physical location to services physically near them (what Bonjour was designed to do in a home environment).

It seems like for mDNS to work as a University user might expect, you'd have to know 1) physically where the user is 2) require a user to specify where they are and then be able to authenticate either piece of information.

Unless there was a way to use the beam forming information from the 802.11ac specification, are there even protocol changes that would allow Bonjour to work as a user would expect in a University environment? I think Enterprise users would be thrilled, where the threat of being punished is enough to stop someone from printing 100 pages of black just to waste ink.

Once there is a standard on how the mDNS packets should route across subnets, what next? We still wouldn't be able to use something like that in a classroom for AppleTV without the potential chaos of having a hundred students highjack an AirPlay Mirroring session. It only takes 1 incident of the honor system going wrong for the system to be in serious jeopardy, administratively.

An ideal workflow for a university is this:
1) A student/teacher wants to use a printer
2) They log into a website, authenticate themselves, pick their printer, and it's broadcast to them, and only them
OR
2) Based on a RADIUS, etc., authentication, the system knows who they are; the user logs into a web interface that says exactly where they are, the system sanity checks this against which AP/LAN port they are on, and sends the services (registered with the network administrators) in their area directly to them
3) The student/teacher happily use their device

For either of these scenarios to work (outside of the other server/router configurations required), mDNSResponder would need to have a mechanism to handle service registrations NOT sent via a broadcast (so that a server could tell a specific client where a service lives) and authenticate these service registrations (so that a malicious application can't register bogus services on a P2P basis).

OR

Another option that wouldn't require network administrators to manually approve devices to is specify a PhysicalLocation attribute as part of the TXT record. The routers forward mDNS broadcasts that have the PhysicalLocation tags as DNS SRV records. When a client device connects to a network, it gets a PhysicalLocation tag pushed to it from the router, configured by the Administrator. When mDNS queries for services, if a PhysicalLocation is configured (which it wouldn't be in a home environment), the routers then query the DNS server for the services, then only returns what matches the client's PhysicalLocation. It would also be critical for a client to manually be able to set its PhysicalLocation, it would also be possible for a client to be associated with multiple physical locations (it could be determined by Administrator policy what to do in these situations).

(if i've mixed up my networking terminology, please excuse me -- i'm not quite a network guru, hopefully you understand what i mean)

- Ron J
NCSU, OIT ClassTech

---

From: "Johnson, Neil M" <[email-masked]>
Date: Mon, 12 Nov 2012 22:16:56 +0000

I don't think we should be mixing AAA and service discovery at the network
level.  It should be up to the device/service to authenticate users, check
their authorization, and keep an audit trail.

As for locating services, some sort of flexible hierarchal name space
should suffice (like DNS). Say  "printer-1 in room333.building.uiowa.edu"
would suffice. Users should be able to search the name space (i.e. "search
for all the printers in building X").

-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]

On 11/12/12 3:50 PM, "Ron J" <[email-masked]> wrote:

>I agree Andrew. While that is the goal for some things, I don't think
>merely extending mDNS in the ways currently discussed will serve all the
>concerns of the Educause members, but should thrill other Enterprise
>users.
>
>It's easy enough to tweak routers currently to broadcast mDNS across
>different subnets (lots of companies are doing this). The bigger problem,
>as far as universities are concerned, seems to be user authentication
>(which the Aruba guy mentioned they have a solution for) and also binding
>a user's physical location to services physically near them (what Bonjour
>was designed to do in a home environment).
>
>It seems like for mDNS to work as a University user might expect, you'd
>have to know 1) physically where the user is 2) require a user to specify
>where they are and then be able to authenticate either piece of
>information.
>
>Unless there was a way to use the beam forming information from the
>802.11ac specification, are there even protocol changes that would allow
>Bonjour to work as a user would expect in a University environment? I
>think Enterprise users would be thrilled, where the threat of being
>punished is enough to stop someone from printing 100 pages of black just
>to waste ink.
>
>Once there is a standard on how the mDNS packets should route across
>subnets, what next? We still wouldn't be able to use something like that
>in a classroom for AppleTV without the potential chaos of having a
>hundred students highjack an AirPlay Mirroring session. It only takes 1
>incident of the honor system going wrong for the system to be in serious
>jeopardy, administratively.
>
>2) They log into a website, authenticate themselves, pick their printer,
>and it's broadcast to them, and only them
>OR
>2) Based on a RADIUS, etc., authentication, the system knows who they
>are; the user logs into a web interface that says exactly where they are,
>the system sanity checks this against which AP/LAN port they are on, and
>sends the services (registered with the network administrators) in their
>area directly to them
>For either of these scenarios to work (outside of the other server/router
>configurations required), mDNSResponder would need to have a mechanism to
>handle service registrations NOT sent via a broadcast (so that a server
>could tell a specific client where a service lives) and authenticate
>these service registrations (so that a malicious application can't
>register bogus services on a P2P basis).
>
>OR
>
>Another option that wouldn't require network administrators to manually
>approve devices to is specify a PhysicalLocation attribute as part of the
>TXT record. The routers forward mDNS broadcasts that have the
>PhysicalLocation tags as DNS SRV records. When a client device connects
>to a network, it gets a PhysicalLocation tag pushed to it from the
>router, configured by the Administrator. When mDNS queries for services,
>if a PhysicalLocation is configured (which it wouldn't be in a home
>environment), the routers then query the DNS server for the services,
>then only returns what matches the client's PhysicalLocation. It would
>also be critical for a client to manually be able to set its
>PhysicalLocation, it would also be possible for a client to be associated
>with multiple physical locations (it could be determined by Administrator
>policy what to do in these situations).
>
>
>(if i've mixed up my networking terminology, please excuse me -- i'm not
>quite a network guru, hopefully you understand what i mean)
>
>- Ron J
>NCSU, OIT ClassTech
>
>

---

From: Ron J <[email-masked]>
Date: Mon, 12 Nov 2012 17:21:28 -0500

If i'm not mistaken, this mixing already is supported by mDNS isn't it?

http://www.dns-sd.org/ServerStaticSetup.html
http://www.dns-sd.org/ClientBrowseOnly.html

- Ron J
NCSU, OIT ClassTech

---

From: "Johnson, Neil M" <[email-masked]>
Date: Mon, 12 Nov 2012 22:50:43 +0000

No, I don't believe so, the links you mentioned just allow browsing static
DNS-SD entries. There is no authentication involved.

One of the problems with static entries is there is a lot of additional
embedded dynamic data in the mDNS records that make it impossible to keep
the static DNS-SD records up-to-date.

-Neil

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Nov 2012 18:47:21 -0500

>>>>> "Dan" == Dan Harkins <[email-masked]> writes:
    >> 

    Dan> I'm unaware of a product that proxies the service itself but I
    Dan> know that our (Aruba's) product provides additional access
    Dan> control based on the (authenticated) identity of the discoverer
    Dan> and the access rule for the device he or she is trying to discover.

I'm trying to understand how the mdns proxy authenticates the user.
Does this also mean that if my host already knows about yonder printer,
that my host could bypass the security of the proxy?

-- 
Michael Richardson
-on the road-

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Nov 2012 18:51:49 -0500

>>>>> "Ron" == Ron J <[email-masked]> writes:
    Ron> Unless there was a way to use the beam forming information from
    Ron> the 802.11ac specification, are there even protocol changes
    Ron> that would allow Bonjour to work as a user would expect in a
    Ron> University environment? I think Enterprise users would be
    Ron> thrilled, where the threat of being punished is enough to stop
    Ron> someone from printing 100 pages of black just to waste ink. 

Most universities that I've visited have locks on the printers,
such that you have to pay for the paper/printing before the print server
releases the job from the print queue.

So, I'm not really sure that *that* issue is as big a deal as you think.

    Ron> Once there is a standard on how the mDNS packets should route
    Ron> across subnets, what next? We still wouldn't be able to use
    Ron> something like that in a classroom for AppleTV without the
    Ron> potential chaos of having a hundred students highjack an
    Ron> AirPlay Mirroring session. It only takes 1 incident of the
    Ron> honor system going wrong for the system to be in serious
    Ron> jeopardy, administratively. 

AirPlay either has user authentication, or it doesn't.
Finding the TV or not doesn't change that.
 
-- 
Michael Richardson
-on the road-

---

From: Adam Burns <[email-masked]>
Date: Tue, 13 Nov 2012 09:43:51 +0000

> put an agent at the link boundary that can take service information
> from one side and retransmit it to another

If I am not mistaken, avahi already does this.

> just as DHCP is link-local but can be relayed across links

I get what you're saying but DHCP is broadcast, mDNS is multicast.