Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A0C21F8586 for ; Wed, 31 Oct 2012 09:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctVe6XlV8XhL for ; Wed, 31 Oct 2012 09:27:39 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5227521F8518 for ; Wed, 31 Oct 2012 09:27:38 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so980409eek.31 for ; Wed, 31 Oct 2012 09:27:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=LdGHnb0vkQLh1BBbzXCluJ+ZRxJGSBv8MYoZieBVsmU=; b=MKjStISeHVY38+Y3e6jhMk99SyuEQ2rJaFHCqGrKecg8U6zwDpEUAmvE/yDPThHY+Z SwDL8wSFQA5nkWYQpBt4ZOeSgzoyBnorqJnqZ6xmZcoEORPwkDD36n9Q0t494kyZQ7gW 9kM1ju1q6OQXTmxPLKoH95d6052ynyDtwhYUZfjvrc4ZIdPFqTs4gVoLKPyBu0KL+sWg Q5kkQsIXhP7YyoECegH9LYiawLh7AkF0WuvWO3vG0teunb+fVXhTEm3eNZ6Q3VI4FhYa 3HEV0EpS6G4x7M9rcwu00i29OZuoi/v8rudYvXzP28YdQuimo+Y9TxDm5NvG+0VDSfyK OzAA== MIME-Version: 1.0 Received: by 10.14.184.2 with SMTP id r2mr86655638eem.43.1351700858260; Wed, 31 Oct 2012 09:27:38 -0700 (PDT) Received: by 10.14.28.136 with HTTP; Wed, 31 Oct 2012 09:27:38 -0700 (PDT) In-Reply-To: References: Date: Wed, 31 Oct 2012 12:27:38 -0400 Message-ID: From: Indtiny s To: Kerry Lynn , mdnsext@ietf.org Content-Type: multipart/alternative; boundary=047d7b3439347fcd9104cd5d6115 Subject: Re: [mdnsext] xmDNS support in mdnsresponder for homenet X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 16:27:40 -0000 --047d7b3439347fcd9104cd5d6115 Content-Type: text/plain; charset=ISO-8859-1 Hi, The document is almost concluded the basic status . http://tools.ietf.org/html/draft-lynn-homenet-site-mdns-01 Due to some urgent requirment I need to go with adding the basic ".site" domain ,i.e Any DNS query for a name ending with ".site." MUST be sent to the xmDNS multicast address (FF05::FB ) and its IPv4 equivalent to 239.255.255.239. Once the Future versions of this document specifies the method for creating zones under the ".site." , I will go with full implementation . Can you pls tell how to start this with apple mdnsresponder core module .. Rgds Indra On Mon, Oct 29, 2012 at 11:08 AM, Kerry Lynn wrote: > Hi Indra, > > First, please note the experimental status of this draft. It is not > recommended for > commercial deploymenat this time. > > Second, I have a patch set for an older version of Avahi but haven't tried > extending > mdnsresponder. I will probably have the Avahi patches ready for limited > distribution > by next week. > > Third, xmDNS assumes you have in place a multicast routing infrastructure > (like > PIM-xx) that can create a multicast tree and selectively forward > site-scoped > multicast messages. I do not think it will work well in the face of > routing loops. > > Regards, -K- > > > On Mon, Oct 29, 2012 at 10:42 AM, Indtiny s wrote: > >> Hi, >> >> I was using the mdnsresponder for my home net related application now I >> need to support the xmDNS support as dicussed in the below draft >> http://ietfreport.isoc.org/ids/draft-lynn-homenet-site-mdns-01.txt >> >> >> Can some body tell me how feasible is this to go and edit this in the >> mdnsreponder core code ..? >> >> >> Rgds >> Indra >> >> >> >> >> >> _______________________________________________ >> mdnsext mailing list >> mdnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/mdnsext >> >> > --047d7b3439347fcd9104cd5d6115 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,
The document is almost concluded the basic status . http://tools.ietf.or= g/html/draft-lynn-homenet-site-mdns-01

Due to some urgent requi= rment I need to go with adding the basic ".site"=A0 domain ,i.e A= ny DNS query for a name ending with ".site." MUST be sent to the = xmDNS multicast address (FF05::FB ) and its IPv4 equivalent to 239.255.255.= 239. Once the Future versions of this document specifies the=A0 method for = creating zones under the ".site." , I will go with full implement= ation .

Can you pls tell how to start this with apple mdnsresponder core module= ..

Rgds

Indra






On Mon, Oct 29, 2012 at 11:08 AM, Kerry Lynn <= kerlyn@ieee.org>= ; wrote:
Hi Indra,

First, please note the expe= rimental status of this draft.=A0 It is not recommended for
commercial d= eploymenat this time.

Second, I have a patch set for an older version of Avahi but haven'= t tried extending
mdnsresponder.=A0 I will probably have the Avahi patches ready for limited = distribution
by next week.

Third, xmDNS assumes you have in place= a multicast routing infrastructure (like
PIM-xx) that can create a mult= icast tree and selectively forward site-scoped
multicast messages.=A0 I do not think it will work well in the face of rout= ing loops.

Regards, -K-


<= div class=3D"h5">On Mon, Oct 29, 2012 at 10:42 AM, Indtiny s <indtiny@gmai= l.com> wrote:
Hi,

I was using the mdnsresponder for my home net related application=A0 no= w I need to support the xmDNS support as dicussed in the below draft
http://ietfreport.isoc.org/ids/draft-lynn-homenet-sit= e-mdns-01.txt=A0

Can some body tell=A0 me how feasible is this = to go and edit this in the mdnsreponder=A0 core code=A0 ..?


Rgds
Indra





_______________________________________________
mdnsext mailing list
mdnsext@ietf.org<= br> https://www.ietf.org/mailman/listinfo/mdnsext



--047d7b3439347fcd9104cd5d6115-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481B121F8646 for ; Mon, 29 Oct 2012 15:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aoci+ZgC96lB for ; Mon, 29 Oct 2012 15:27:10 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 40D4A21F8551 for ; Mon, 29 Oct 2012 15:27:09 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9TMR8we030525 for ; Mon, 29 Oct 2012 22:27:08 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9TMR8we030525 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1351549628; bh=RwsbMD5LxI7YR3zI2zcRjQ0udDM=; h=From:Mime-Version:Subject:Date:References:To:In-Reply-To; b=iWvMIhMSdzwKn0uVQOVD17GPSeBDYTrmS8V7GIts0fOvR1A55f3RnLuBFKY1HbqBp h0rU/UJkScP+Cvwghyx0GeN4y/2+DnPuQlC10oWdoETvX2fKR2DeA1molSPCc6ifpf giX2x9bJls51III5lpZag2FpZ6fpjgPSp5njFpso= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id o9SMR80430605538xQ ret-id none; Mon, 29 Oct 2012 22:27:08 +0000 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9TMR1Zg016948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 29 Oct 2012 22:27:02 GMT From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_DA68B80D-C54D-4D83-8416-AF4EE5BA8A8A" Message-ID: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Date: Mon, 29 Oct 2012 22:27:00 +0000 References: <9CA573D3-94D6-453A-B6C8-8FDE33E78AA6@ecs.soton.ac.uk> <0077A9B1-A5A9-4AEE-A20A-736F1E84365D@ecs.soton.ac.uk> To: "mdnsext@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o9SMR8043060553800; tid=o9SMR80430605538xQ; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9TMR8we030525 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [mdnsext] mdnsext BoF session at IETF 85 X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 22:27:11 -0000 --Apple-Mail=_DA68B80D-C54D-4D83-8416-AF4EE5BA8A8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Apologies, the dayshould read TUESDAY, November 6. Updated text below. Extensions of the Bonjour Protocol Suite (mdnsext) BoF TUESDAY, November 6, 2012=20 1520-1650 Afternoon Session II=20 Grand Ballroom C =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D *=20 * Administravia (10 mins) =20 Note Well =20 Agenda bashing (Chairs) * Goals of the BoF (10 mins) NB. RFC5434, Section 1 (Chairs) * Use cases for Bonjour in routed networks (15 mins) (Stuart Cheshire) * Requirements (25 mins) draft-lynn-mdnsext-requirements-00 (Kerry Lynn) * Open discussion (20 mins) Charter bashing * Conclusion (10 mins) Should a WG be formed? On 29 Oct 2012, at 20:55, Tim Chown wrote: > The BoF session at IETF85 has the following draft agenda. >=20 > Remote participation details can be found here: = http://www.ietf.org/meeting/85/remote-participation.html. Comments and = questions can be relayed via Jabber for those unable to be in Atlanta, = and of course comments in advance of the meeting on the charter and the = requirements draft are very welcome. >=20 > Tim >=20 > Extensions of the Bonjour Protocol Suite (mdnsext) BoF >=20 > THURSDAY, November 6, 2012=20 > 1520-1650 Afternoon Session II=20 >=20 > Grand Ballroom C >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D *=20 >=20 > * Administravia (10 mins) =20 > Note Well =20 > Agenda bashing > (Chairs) >=20 > * Goals of the BoF (10 mins) > NB. RFC5434, Section 1 > (Chairs) >=20 > * Use cases for Bonjour in routed networks (15 mins) > (Stuart Cheshire) >=20 > * Requirements (25 mins) > draft-lynn-mdnsext-requirements-00 > (Kerry Lynn) >=20 > * Open discussion (30 mins) > Charter bashing >=20 > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext --Apple-Mail=_DA68B80D-C54D-4D83-8416-AF4EE5BA8A8A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii tjc@ecs.soton.ac.uk> = wrote:
The = BoF session at IETF85 has the following draft = agenda.

Remote participation details can be found = here: http://w= ww.ietf.org/meeting/85/remote-participation.html. Comments and = questions can be relayed via Jabber for those unable to be in Atlanta, = and of course comments in advance of the meeting on the charter and the = requirements draft are very = welcome.

Tim

Extensions of =
the Bonjour Protocol Suite (mdnsext) BoF

THURSDAY, November 6, 2012=20
1520-1650 Afternoon Session II=20

Grand Ballroom C

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D  *=20

* Administravia (10 mins)  =20
  Note Well  =20
  Agenda bashing
  (Chairs)

* Goals of the BoF (10 mins)
  NB. RFC5434, Section 1
  (Chairs)

* Use cases for Bonjour in routed networks (15 mins)
  (Stuart Cheshire)

* Requirements (25 mins)
  draft-lynn-mdnsext-requirements-00
  (Kerry Lynn)

* Open discussion (30 mins)
  Charter bashing
=

_________________________________________= ______
mdnsext mailing list
mdnsext@ietf.org
https://www.ietf.= org/mailman/listinfo/mdnsext

= --Apple-Mail=_DA68B80D-C54D-4D83-8416-AF4EE5BA8A8A-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CA721F86EB for ; Mon, 29 Oct 2012 14:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.435 X-Spam-Level: X-Spam-Status: No, score=-0.435 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BW86IJj8-T5u for ; Mon, 29 Oct 2012 14:24:02 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) by ietfa.amsl.com (Postfix) with ESMTP id A6C6721F86EE for ; Mon, 29 Oct 2012 14:24:00 -0700 (PDT) Received: from [172.16.10.3] (cpe-071-070-157-071.nc.res.rr.com [71.70.157.71]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 64AF911348; Mon, 29 Oct 2012 17:21:57 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_73EA3631-63EB-430E-819D-ED544E16B117" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tom Pusateri In-Reply-To: Date: Mon, 29 Oct 2012 17:23:56 -0400 Message-Id: <1FE8C89F-D1DF-4691-B8BF-E62F1125E1A3@bangj.com> References: <514CF52A-F985-4D7B-8845-525189080423@ecs.soton.ac.uk> <1AD9C09A-7734-4895-93AC-EF7D12FBAE2A@bangj.com> To: Kerry Lynn X-Mailer: Apple Mail (2.1499) Cc: mdnsext@ietf.org, Tim Chown Subject: Re: [mdnsext] draft-lynn-mdnsext-requirements-00 X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 21:24:04 -0000 --Apple-Mail=_73EA3631-63EB-430E-819D-ED544E16B117 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Oct 29, 2012, at 10:57 AM, Kerry Lynn wrote: > Hi Tom, >=20 > Thanks for your comments. Questions/comments inline... >=20 > On Sat, Oct 27, 2012 at 9:54 PM, Tom Pusateri = wrote: >=20 > On Oct 12, 2012, at 7:28 AM, Tim Chown wrote: >=20 > > Just a heads up: > > > > http://tools.ietf.org/html/draft-lynn-mdnsext-requirements-00 > > > > Discussion on the problem statement is encouraged. > > > > Tim >=20 > 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 =3D> >=20 > 2.1. Multilink Naming and Discovery >=20 > 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. > ^^^ > =3D> insert "IP" subnets > =3D> > 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. > =20 > =3D> Multicast DNS Queries (and often Responses) are sent to either = the IPv4 multicast > =3D> address 224.0.0.251 or the IPv6 multicast address FF02::FB. > =3D> These IP multicast addresses are considered part of the = link-local range and are not > =3D> intended to be forwarded onto another IP subnet by a multicast = router. >=20 > 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. 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. >=20 > DNS-SD is a conventional use of existing DNS Resource Records and > can, in practice, be deployed over unicast DNS. However, this mode >=20 >=20 >=20 > Lynn & Cheshire Expires April 13, 2013 [Page = 3] > Internet-Draft MDNSEXT Requirements October = 2012 >=20 >=20 > is not commonly used. >=20 > =3D> However, this wide-area mode is not commonly used. Issues with = wide-area bonjour include: > =3D> 1. deploying dynamic update capabilities for the main DNS domain = or deploying parallel DNS infrastructure for a separate dynamic domain = or sub-domain. > =3D> 2. familiarity with troubleshooting wide-area bonjour with = existing tools. >=20 > Do you know of problems with existing tools or are you saying that = people are generally > 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. > =20 > =3D> 3. missing wide-area support in embedded devices and alternate = implementations >=20 > 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. 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. > =20 >=20 > 5. Security Considerations >=20 > [TBD] >=20 > =3D> Extending service discovery across IP subnets, opens the door to = new security threats. > =3D> Link-local threats are fairly well understood and typically = isolated in scope. Wide-area > =3D> service discovery threats were mostly limited to dynamic DNS = updates or the restrictions > =3D> placed on responses. >=20 > 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? >=20 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 > 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. >=20 > 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. > =20 > =3D> When service discovery is replicated across multiple IP subnets, = forwarding restrictions are > =3D> more difficult to contain and verify. Queries and responses may = be sent beyond administrative > =3D> boundaries. Cryptographic services may be needed to protect = against leaks or malicious intent. >=20 > 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. >=20 > Regards, -K- >=20 > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext >=20 > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext --Apple-Mail=_73EA3631-63EB-430E-819D-ED544E16B117 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 kerlyn@ieee.org> wrote:
Hi = Tom,

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

On Sat, Oct 27, 2012 at 9:54 = PM, Tom Pusateri <pusateri@bangj.com> wrote:

On Oct 12, 2012, at 7:28 AM, Tim Chown <tjc@ecs.soton.ac.uk> = wrote:

> Just a heads up:
>
> http://tools.ietf.org/html/draft-lynn-mdnsext-requiremen= ts-00
>
> Discussion on the problem statement is encouraged.
>
> Tim

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 =3D>

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.
                    =                     =           ^^^
=3D> insert "IP" subnets
=3D>
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.

 
=3D> Multicast DNS Queries (and often Responses) are sent to either = the IPv4 multicast
=3D> address 224.0.0.251 or the IPv6 multicast address FF02::FB.
=3D> These IP multicast addresses are considered part of the = link-local range and are not
=3D> intended to be forwarded onto another IP subnet by a multicast = router.

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.

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.


   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.

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

Do you know of problems with = existing tools or are you saying that people are generally
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.

 
=3D> 3. missing wide-area support in embedded devices and alternate = implementations

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.

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.

 

5.  Security Considerations

   [TBD]

=3D> Extending service discovery across IP subnets, opens the door to = new security threats.
=3D> Link-local threats are fairly well understood and typically = isolated in scope. Wide-area
=3D> service discovery threats were mostly limited to dynamic DNS = updates or the restrictions
=3D> placed on responses.

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?


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

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.
 
=3D> When service discovery is replicated across multiple IP subnets, = forwarding restrictions are
=3D> more difficult to contain and verify. Queries and responses may = be sent beyond administrative
=3D> boundaries. Cryptographic services may be needed to protect = against leaks or malicious intent.

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
mdnsext@ietf.org
https://www.ietf.org/mailman/listinfo/mdnsext

_______________________________________________
mdnsext mailing = list
mdnsext@ietf.org
https://www.ietf.= org/mailman/listinfo/mdnsext

= --Apple-Mail=_73EA3631-63EB-430E-819D-ED544E16B117-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAEB21F8678 for ; Mon, 29 Oct 2012 13:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZxlLkLclx8t for ; Mon, 29 Oct 2012 13:55:51 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 07B3621F866C for ; Mon, 29 Oct 2012 13:55:50 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9TKtiXE014771 for ; Mon, 29 Oct 2012 20:55:44 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9TKtiXE014771 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1351544144; bh=O4dLcVL/Z/X4YU0LPYyCXOjeC4I=; h=From:Subject:Date:To:Mime-Version:References; b=MW74vEq+yJqoKx4mJrgSHsW8aeeZxe6G8aSTjcYiwKxcGIFWb/oAT+wu4cEwCjKP7 VIwSey/z9Nt0T0Q8qUWdhjnbnla2n/mrG+Q0XEd3ikX/+GApWnrYuImg5IPefgGrVB A3cTdKQuIiBY98qspC6F2IbQ2mw8JbLRywBFGY70= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id o9SKyi0430605189Kg ret-id none; Mon, 29 Oct 2012 20:55:44 +0000 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9TKtcdt001205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 29 Oct 2012 20:55:38 GMT From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_36D9BCE3-815A-4064-81E1-4140596A44D9" Message-ID: Date: Mon, 29 Oct 2012 20:55:37 +0000 To: "mdnsext@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o9SKyi043060518900; tid=o9SKyi0430605189Kg; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: <9CA573D3-94D6-453A-B6C8-8FDE33E78AA6@ecs.soton.ac.uk> X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9TKtiXE014771 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: [mdnsext] mdnsext BoF session at IETF 85 X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 20:55:52 -0000 --Apple-Mail=_36D9BCE3-815A-4064-81E1-4140596A44D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The BoF session at IETF85 has the following draft agenda. Remote participation details can be found here: = http://www.ietf.org/meeting/85/remote-participation.html. Comments and = questions can be relayed via Jabber for those unable to be in Atlanta, = and of course comments in advance of the meeting on the charter and the = requirements draft are very welcome. Tim Extensions of the Bonjour Protocol Suite (mdnsext) BoF THURSDAY, November 6, 2012=20 1520-1650 Afternoon Session II=20 Grand Ballroom C =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D *=20 * Administravia (10 mins) =20 Note Well =20 Agenda bashing (Chairs) * Goals of the BoF (10 mins) NB. RFC5434, Section 1 (Chairs) * Use cases for Bonjour in routed networks (15 mins) (Stuart Cheshire) * Requirements (25 mins) draft-lynn-mdnsext-requirements-00 (Kerry Lynn) * Open discussion (30 mins) Charter bashing --Apple-Mail=_36D9BCE3-815A-4064-81E1-4140596A44D9 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii The BoF session at IETF85 has the following draft agenda.

Remote participation details can be found here: http://www.ietf.org/meeting/85/remote-participation.html. Comments and questions can be relayed via Jabber for those unable to be in Atlanta, and of course comments in advance of the meeting on the charter and the requirements draft are very welcome.

Tim

Extensions of the Bonjour Protocol Suite (mdnsext) BoF

THURSDAY, November 6, 2012 
1520-1650 Afternoon Session II 

Grand Ballroom C

=====================================================  * 

* Administravia (10 mins)   
  Note Well   
  Agenda bashing
  (Chairs)

* Goals of the BoF (10 mins)
  NB. RFC5434, Section 1
  (Chairs)

* Use cases for Bonjour in routed networks (15 mins)
  (Stuart Cheshire)

* Requirements (25 mins)
  draft-lynn-mdnsext-requirements-00
  (Kerry Lynn)

* Open discussion (30 mins)
  Charter bashing

--Apple-Mail=_36D9BCE3-815A-4064-81E1-4140596A44D9-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AD921F866C for ; Mon, 29 Oct 2012 13:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9E0Om1p2t61N for ; Mon, 29 Oct 2012 13:53:16 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 30C0F21F8669 for ; Mon, 29 Oct 2012 13:53:15 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9TKr9KT014412 for ; Mon, 29 Oct 2012 20:53:09 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9TKr9KT014412 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1351543989; bh=SJG1koqcoK/vhZ31a7c5DuXt6vk=; h=From:Subject:Date:To:Mime-Version:References; b=oY/Ju+2HgV3tz5hBaUpOqFibRSJIx0OmJBbmtSsvgQOwWKtNFQgz6iJAOnblj1jOL EXw9iESLIiUvS6jDpUV/e5MQb7RgIhTjI6tR/p3M9iXTuKX+Qa1Nr7zaa6w2T6Egtk XNc6/CH1CmzD+2wzgKcpLT4KSfyGy8gNwMzC0bzE= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id o9SKr9043060517578 ret-id none; Mon, 29 Oct 2012 20:53:09 +0000 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9TKr2JU000908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 29 Oct 2012 20:53:03 GMT From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_EEA01D24-D7FE-44B2-983B-52524D0786BB" Message-ID: Date: Mon, 29 Oct 2012 20:53:02 +0000 To: "mdnsext@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o9SKr9043060517500; tid=o9SKr9043060517578; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9TKr9KT014412 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: [mdnsext] Draft mdnsext WG charter X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 20:53:17 -0000 --Apple-Mail=_EEA01D24-D7FE-44B2-983B-52524D0786BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, The following text is the current draft charter for the prospective = mdnsext WG. Comments in advance of the BoF are very much welcomed. Tim =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D mdnsext draft charter Currently, zeroconf networking protocols are generally used to discover = services within the scope of a single link. In particular, the Bonjour = protocols suite, comprising mDNS (draft-cheshire-dnsext-multicastdns / = RFC 6762 in AUTH48) and DNS-SD (draft-cheshire-dnsext-dns-sd / RFC 6763 = in AUTH48), are widely used for discovery and resolution of services and = names on a single link.=20 Such discovery is commonly used in many scenarios, including home = networks, commercial and campus enterprise networks, and can be used in = certain mesh networks. However, the multicast zeroconf protocols are = constrained to link-local scope, so can only be used to discover = services on the same link. In a typical current home network, which is a = single link, users should experience the desired discovery behaviour. = However, in future multi-link home networks (as envisaged by the homenet = WG) and in routed campus or enterprise networks, devices and thus users = can only discover services on the same link, which is a significant = limitation. Such limitations have led to calls, such as those by the = Educause petition, to develop an appropriate solution to span multiple = links. In addition, the Zigbee Smart Energy Profile 2.0 commercial standard = currently under development has specified mDNS as its method of zero = configuration discovery. However, its use of multi-link wireless mesh = subnets (LLNs) and disparate physical layers will require extensions to = mDNS to allow it to operate across multiple links. In principle DNS-SD can be used with conventional unicast DNS for wide = area service discovery spanning multiple links, but in practice this = capability is not widely used. As a result, as demand for service = discovery across routed networks grows, some vendors are beginning to = ship their own early solutions. It is thus both timely and important = that efforts to develop improved, scalable service discovery solutions = for routed networks are coordinated towards producing a single, = standards-based solution. Goals To that end, the primary goals of the mdnsext WG are as follows: 1. To document a set of requirements for service discovery across = routed, multi-link networks in the following four scenarios: a) Commercial enterprise networks b) Academic/educational/university campus networks c) Multi-link home networks, such as those envisgaed by the HOMENET = WG d) Multi-link/single subnet (mesh) networks, such as ROLL/6LOWPAN = subnets 2. To develop an improved, scalable solution for wide-area service = discovery spanning multiple links, applicable to the scenarios above.=20 3. To develop a solution to seamlessly integrate zeroconf (mDNS) and = unicast (global DNS) name services, which should include consideration = of both the name resolution mechanism and the namespace. It is important that the mdnsext WG takes input from stakeholders in the = scenarios it is considering. For example, the homenet WG is currently = evaluating its own requirements for naming and service discovery; it is = up to the homenet WG as to whether it wishes to recommend adoption of = the solution developed in the mdsnext WG, and thus coordination between = the WGs is desirable.=20 Deliverables The WG will produce three documents: an Informational RFC on the = requirements for wide-area service discovery protocols; a Standards = Track RFC documenting a wide-area service discovery solution that is = applicable to those scenarios; and a Standards Track document describing = a solution to seamlessly integrate mDNS and global DNS name services. Milestones Jan 2013 Formation of the WG Apr 2013 Adopt requirements draft as WG document Aug 2013 Submit requirements draft to the IESG as an Informational RFC Aug 2013 Adopt wide-area service discovery solution draft as WG document Aug 2013 Adopt mDNS and global DNS integration solution draft as WG = document Dec 2013 Submit wide-area service discovery solution draft to the IESG = as Standards Track RFC Dec 2013 Submit mDNS and global DNS integration solution draft to the = IESG as Standards Track RFC =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= --Apple-Mail=_EEA01D24-D7FE-44B2-983B-52524D0786BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii he Bonjour protocols suite, comprising mDNS = (draft-cheshire-dnsext-multicastdns / RFC 6762 in AUTH48) and = DNS-SD (draft-cheshire-dnsext-dns-sd / RFC 6763 in AUTH48), are = widely used for discovery and resolution of services and names on a = single link. 

Such discovery is = commonly used in many scenarios, including home networks, commercial and = campus enterprise networks, and can be used in certain mesh networks. = However, the multicast zeroconf protocols are constrained to link-local = scope, so can only be used to discover services on the same link. In a = typical current home network, which is a single link, users should = experience the desired discovery behaviour. However, in future = multi-link home networks (as envisaged by the homenet WG) and in routed = campus or enterprise networks, devices and thus users can only discover = services on the same link, which is a significant limitation. Such = limitations have led to calls, such as those by the Educause petition, = to develop an appropriate solution to span multiple = links.

In addition, the Zigbee Smart Energy Profile = 2.0
In principle DNS-SD can be used with conventional unicast = DNS for wide area service discovery spanning multiple = links,  X-Mailer: Apple Mail (2.1499) Cc: "mdnsext@ietf.org" , Kerry Lynn , Tom Pusateri , Tim Chown Subject: Re: [mdnsext] draft-lynn-mdnsext-requirements-00 X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 18:12:50 -0000 On Oct 29, 2012, at 10:58 AM, "Johnson, Neil M" = wrote: > 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. =20 This is valid behavior. The schema of a TXT record is specific to that = service type, and there=92s 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 ?). > 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. 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=92s up to the owner of the record to update it. =97Jens= Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDA421F8737 for ; Mon, 29 Oct 2012 10:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2memEb-ACvJ for ; Mon, 29 Oct 2012 10:58:19 -0700 (PDT) Received: from ITSNT447.iowa.uiowa.edu (itsnt447.iowa.uiowa.edu [128.255.67.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB6421F8734 for ; Mon, 29 Oct 2012 10:58:19 -0700 (PDT) Received: from ITSNT441.iowa.uiowa.edu ([169.254.3.228]) by ITSNT447.iowa.uiowa.edu ([128.255.67.11]) with mapi id 14.02.0318.001; Mon, 29 Oct 2012 12:58:17 -0500 From: "Johnson, Neil M" To: Kerry Lynn , Tom Pusateri Thread-Topic: [mdnsext] draft-lynn-mdnsext-requirements-00 Thread-Index: AQHNtK81/rHZ8WiGZEWWNUP24hTse5fQtfoA///elYA= Date: Mon, 29 Oct 2012 17:58:17 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.255.6.15] Content-Type: multipart/alternative; boundary="_000_D0A9B5406A554144909209825980D37E1CAF1E62ITSNT441iowauio_" MIME-Version: 1.0 Cc: "mdnsext@ietf.org" , Tim Chown Subject: Re: [mdnsext] draft-lynn-mdnsext-requirements-00 X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 17:58:20 -0000 --_000_D0A9B5406A554144909209825980D37E1CAF1E62ITSNT441iowauio_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "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 ther= e 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 dynam= ic data that can't be easily captured and maintained in static records, hen= ce 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: neil-johnson@uiowa.edu From: Kerry Lynn > Date: Monday, October 29, 2012 9:57 AM To: Tom Pusateri > Cc: "mdnsext@ietf.org" >, Tim Chown > Subject: Re: [mdnsext] draft-lynn-mdnsext-requirements-00 Hi Tom, Thanks for your comments. Questions/comments inline... On Sat, Oct 27, 2012 at 9:54 PM, Tom Pusateri > wrote: On Oct 12, 2012, at 7:28 AM, Tim Chown > wrote: > Just a heads up: > > http://tools.ietf.org/html/draft-lynn-mdnsext-requirements-00 > > Discussion on the problem statement is encouraged. > > Tim 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 =3D> 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. ^^^ =3D> insert "IP" subnets =3D> This may more precisely be "inability to discover services on other links". =3D> Multicast DNS Queries (and often Responses) are sent to either the IPv= 4 multicast =3D> address 224.0.0.251 or the IPv6 multicast address FF02::FB. =3D> These IP multicast addresses are considered part of the link-local ran= ge and are not =3D> intended to be forwarded onto another IP subnet by a multicast router. 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. 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. =3D> However, this wide-area mode is not commonly used. Issues with wide-ar= ea bonjour include: =3D> 1. deploying dynamic update capabilities for the main DNS domain or de= ploying parallel DNS infrastructure for a separate dynamic domain or sub-do= main. =3D> 2. familiarity with troubleshooting wide-area bonjour with existing to= ols. Do you know of problems with existing tools or are you saying that people a= re generally unfamiliar with PTR, SRV, and TXT RRs? =3D> 3. missing wide-area support in embedded devices and alternate impleme= ntations 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 a= n incremental change. 5. Security Considerations [TBD] =3D> Extending service discovery across IP subnets, opens the door to new s= ecurity threats. =3D> Link-local threats are fairly well understood and typically isolated i= n scope. Wide-area =3D> service discovery threats were mostly limited to dynamic DNS updates o= r the restrictions =3D> placed on responses. So here I think I'm missing your point. Once DNS-SD records are inserted i= n a global DNS zone, why does this pose more or less of a security threat than any other D= NS record? Do you anticipate authentication issues outside those addressed by DNSSEC? Re= strictions 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) unl= ess there's some L2 authentication of the host to the DHCP server (or VLAN containing the DH= CP server) as a pre-condition to L3 enrollment. I think the question of how to authorize mDNS services for incorporation in= to 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. =3D> When service discovery is replicated across multiple IP subnets, forwa= rding restrictions are =3D> more difficult to contain and verify. Queries and responses may be sen= t beyond administrative =3D> boundaries. Cryptographic services may be needed to protect against le= aks or malicious intent. Wide-area service discovery seems to me very similar to global name resolut= ion. Granted, you do have more information about the host other than just its ad= dress (service port, for one thing) but the ability to mutually authenticate/conn= ect to the service is surely an application issue. Again, I think I may be missing yo= ur point. Regards, -K- _______________________________________________ mdnsext mailing list mdnsext@ietf.org https://www.ietf.org/mailman/listinfo/mdnsext --_000_D0A9B5406A554144909209825980D37E1CAF1E62ITSNT441iowauio_ Content-Type: text/html; charset="us-ascii" Content-ID: <9665ADCF6A6E28449F2CC0D7EB145FEA@mailhost6.uiowa.edu> Content-Transfer-Encoding: quoted-printable
"Do you know of problems with existing tools or are you saying th= at 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 ver= sion, plus other undocumented data.  This makes maintaing static DNS-S= D 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: neil-johnson@uiowa.edu


From: Kerry Lynn <kerlyn@ieee.org>
Date: Monday, October 29, 2012 9:57= AM
To: Tom Pusateri <pusateri@bangj.com>
Cc: "mdnsext@ietf.org" <mdnsext@ietf.org>, Tim Chown <tjc@ecs.soton.ac.uk>
Subject: Re: [mdnsext] draft-lynn-m= dnsext-requirements-00

Hi Tom,

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

On Sat, Oct 27, 2012 at 9:54 PM, Tom Pusateri <pusateri@bangj.= com> wrote:

On Oct 12, 2012, at 7:28 AM, Tim Chown <tjc@ecs.soton.ac.uk> wrote:

> Just a heads up:
>
> http://tools.ietf.org/html/draft-lynn-mdnsext-requirements-00
>
> Discussion on the problem statement is encouraged.
>
> Tim

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 =3D>

2.1.  Multilink Naming and Discovery

   While DNS-SD/mDNS is well-suited for zero-configuration of nam= ing and
   discovery of hosts and services on a local link, users are fru= strated
   by the inability to discover services on other subnets.
                     = ;                     &nb= sp;       ^^^
=3D> insert "IP" subnets
=3D>
This may more precisely be "inability to discover services on oth= er links".
 
=3D> Multicast DNS Queries (and often Responses) are sent to either the = IPv4 multicast
=3D> address 224.0.0.251 or the IPv6 multicast address FF02::FB.
=3D> These IP multicast addresses are considered part of the link-local = range and are not
=3D> intended to be forwarded onto another IP subnet by a multicast rout= er.

Is this not clear from multicast scoping rules?  I will add a ref= erence to make
that clear.  In the case of a multicast IPv6 query with a link-local s= ource 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.

   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, 201= 3                 [Page 3]
Internet-Draft            MDNSEXT Requirement= s              October 2012


   is not commonly used.

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

Do you know of problems with existing tools or are you saying that people a= re generally
unfamiliar with PTR, SRV, and TXT RRs?
 
=3D> 3. missing wide-area support in embedded devices and alternate impl= ementations

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 a= n
incremental change.
 

5.  Security Considerations

   [TBD]

=3D> Extending service discovery across IP subnets, opens the door to ne= w security threats.
=3D> Link-local threats are fairly well understood and typically isolate= d in scope. Wide-area
=3D> service discovery threats were mostly limited to dynamic DNS update= s or the restrictions
=3D> placed on responses.

So here I think I'm missing your point.  Once DNS-SD records are inser= ted in a global DNS
zone, why does this pose more or less of a security threat than any other D= NS record?  Do
you anticipate authentication issues outside those addressed by DNSSEC?&nbs= p; 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 particul= arly high bar for
authorization (of the records appearing in the zone in the first place) unl= ess there's some
L2 authentication of the host to the DHCP server (or VLAN containing the DH= CP server)
as a pre-condition to L3 enrollment.

I think the question of how to authorize mDNS services for incorporation in= to 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.
 
=3D> When service discovery is replicated across multiple IP subnets, fo= rwarding restrictions are
=3D> more difficult to contain and verify. Queries and responses may be = sent beyond administrative
=3D> boundaries. Cryptographic services may be needed to protect against= leaks or malicious intent.

Wide-area service discovery seems to me very similar to global name re= solution.
Granted, you do have more information about the host other than just its ad= dress
(service port, for one thing) but the ability to mutually authenticate/conn= ect to the
service is surely an application issue.  Again, I think I may be missi= ng your point.

Regards, -K-

_______________________________________________
mdnsext mailing list
mdnsext@ietf.org
https://www.ietf.org/mailman/listinfo/mdnsext

 --_000_D0A9B5406A554144909209825980D37E1CAF1E62ITSNT441iowauio_-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0094521F84EC for ; Mon, 29 Oct 2012 07:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGTZzs2QthLp for ; Mon, 29 Oct 2012 07:57:52 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 87ADB21F84E1 for ; Mon, 29 Oct 2012 07:57:51 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so3484468lbo.31 for ; Mon, 29 Oct 2012 07:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=B647q83LlAzlc08czAsw+SVT7aao4JIvGzcUrTBXOfw=; b=nJUilp6AggLe2dL6sAPQyZfxIDP3PBpx1V6lKyjxo1ys0ziWTjiaTgx9PzFrYHXj/4 ugGYiK+AGjJgI7+3WxgB7/rP4MYLfh2y+VOyZ6kQHThg31T549SIcsmsjvq2+6IzR3GE 2kQWEcQYXjbaTvt+5zpLwou/eCw25D9ntfr4uQrs4hIh+4eOyygfQTJQGdpTG5Y+Io2w 19xdGtXNblxiUPO8hfsmovdogSgRV6E+N3PMHcbOblpQn3tIARb8dfEfCmxMCDkZuGBf Dz5wUT9aNWOteoHBr5OD87JAjv9fzorqr/rqxY+7FUtNO7GP5LEYz/HSN52GQFfPjPu1 zkqg== MIME-Version: 1.0 Received: by 10.112.45.231 with SMTP id q7mr11970533lbm.133.1351522670509; Mon, 29 Oct 2012 07:57:50 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.112.20.71 with HTTP; Mon, 29 Oct 2012 07:57:50 -0700 (PDT) In-Reply-To: <1AD9C09A-7734-4895-93AC-EF7D12FBAE2A@bangj.com> References: <514CF52A-F985-4D7B-8845-525189080423@ecs.soton.ac.uk> <1AD9C09A-7734-4895-93AC-EF7D12FBAE2A@bangj.com> Date: Mon, 29 Oct 2012 10:57:50 -0400 X-Google-Sender-Auth: UOQSK0k4ofrimZQRiNxKMbdf3Tg Message-ID: From: Kerry Lynn To: Tom Pusateri Content-Type: multipart/alternative; boundary=bcaec554df5aae7d4704cd33e493 Cc: mdnsext@ietf.org, Tim Chown Subject: Re: [mdnsext] draft-lynn-mdnsext-requirements-00 X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 14:57:53 -0000 --bcaec554df5aae7d4704cd33e493 Content-Type: text/plain; charset=ISO-8859-1 Hi Tom, Thanks for your comments. Questions/comments inline... On Sat, Oct 27, 2012 at 9:54 PM, Tom Pusateri wrote: > > On Oct 12, 2012, at 7:28 AM, Tim Chown wrote: > > > Just a heads up: > > > > http://tools.ietf.org/html/draft-lynn-mdnsext-requirements-00 > > > > Discussion on the problem statement is encouraged. > > > > Tim > > 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 > => > This may more precisely be "inability to discover services on other links". > => 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. > > 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. 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. > Do you know of problems with existing tools or are you saying that people are generally unfamiliar with PTR, SRV, and TXT RRs? > => 3. missing wide-area support in embedded devices and alternate > implementations > > 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. > > 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. > 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. > => 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. > > 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 > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext > --bcaec554df5aae7d4704cd33e493 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tom,

Thanks for your comments.=A0 Questions/comments inline...
On Sat, Oct 27, 2012 at 9:54 PM, Tom Pusate= ri <pusateri@bangj.com> wrote:

On Oct 12, 2012, at 7:28 AM, Tim Chown <tjc@ecs.soton.ac.uk> wrote:

> Just a heads up:
>
> http://tools.ietf.org/html/draft-lynn-mdnsext-require= ments-00
>
> Discussion on the problem statement is encouraged.
>
> Tim

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

2.1. =A0Multilink Naming and Discovery

=A0 =A0While DNS-SD/mDNS is well-suited for zero-configuration of naming an= d
=A0 =A0discovery of hosts and services on a local link, users are frustrate= d
=A0 =A0by the inability to discover services on other subnets.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 ^^^
=3D> insert "IP" subnets
=3D>
This may more precisely be "inability to = discover services on other links".
=A0
=3D> Multicast DNS Queries (and often Responses) are sent to either the = IPv4 multicast
=3D> address 224.0.0.251 or the IPv6 multicast address FF02::FB.
=3D> These IP multicast addresses are considered part of the link-local = range and are not
=3D> intended to be forwarded onto another IP subnet by a multicast rout= er.

Is this not clear from multicast scoping rules?=A0 I = will add a reference to make
that clear.=A0 In the case of a multicast I= Pv6 query with a link-local source address,
forwarding of the packet is = of no use as the responses will be un-routable.=A0 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.

=A0 =A0DNS-SD is a conventional use of existing DNS Resource Records and =A0 =A0can, in practice, be deployed over unicast DNS. =A0However, this mod= e



Lynn & Cheshire =A0 =A0 =A0 =A0 =A0Expires April 13, 2013 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 [Page 3]
Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0MDNSEXT Requirements =A0 =A0 =A0 =A0 = =A0 =A0 =A0October 2012


=A0 =A0is not commonly used.

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

Do you know of problems with existing tool= s or are you saying that people are generally
unfamiliar with PTR, SRV, = and TXT RRs?
=A0
=3D> 3. missing wide-area support in embedded devices and alternate impl= ementations

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

5. =A0Security Considerations

=A0 =A0[TBD]

=3D> Extending service discovery across IP subnets, opens the door to ne= w security threats.
=3D> Link-local threats are fairly well understood and typically isolate= d in scope. Wide-area
=3D> service discovery threats were mostly limited to dynamic DNS update= s or the restrictions
=3D> placed on responses.

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

Re: dynamic DNS updates, many current installations= seem to rely on DHCP to update
DNS records on behalf of end hosts.=A0 That doesn't seem like a particu= larly high bar for
authorization (of the records appearing in the zone i= n 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 i= s an interesting one if simply being present on the network is deemed to be insufficient from a trust perspective.
=A0
=3D> When service discovery is replicated across multiple IP subnets, fo= rwarding restrictions are
=3D> more difficult to contain and verify. Queries and responses may be = sent beyond administrative
=3D> boundaries. Cryptographic services may be needed to protect against= leaks or malicious intent.

W= ide-area service discovery seems to me very similar to global name resoluti= on.
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/conn= ect to the
service is surely an application issue.=A0 Again, I think I m= ay be missing your point.

Regards, -K-

_______________________________________________
mdnsext mailing list
mdnsext@ietf.org
https://www.ietf.org/mailman/listinfo/mdnsext

--bcaec554df5aae7d4704cd33e493-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90C621F870A for ; Mon, 29 Oct 2012 07:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLus8dpjIEpa for ; Mon, 29 Oct 2012 07:42:17 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF2421F8722 for ; Mon, 29 Oct 2012 07:42:17 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so5246154obq.31 for ; Mon, 29 Oct 2012 07:42:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jQiCa51d2VbmyDwQ5MGv94Qp3/M/NsCw08PERMRwtCQ=; b=cy+t+wiOuX0edo7RtfxczXGIwN8ZJalH7RBWPHKG1UbYoxf2Lb3MN7F3HYP+2+Bp2m HudrwbHnIxrmS5tFAVzj9Vq8yBV90b89m6M8Wdh2nAzU5RB4nZVUBHj0FV97y/UTTMMA k0ivJ8tZnzK23z5JPDsDzFZNgy+BbI+1Rg6bUJjpN3BljkOZXUwAnDRHhnBTe2LujVwF TxLmOdgIxkggkDGOcxElrt6cnS9wTPPibczFRABzBBmO6NLO/qfTO22KGjEy0ZE0i5JX 49PIP7bm39bw+6hxMXpDIxCo1GB+ZtIaKeQH6QaNIzdIGBMyNISNa4gy0J+BH8zKA4wg aC5w== MIME-Version: 1.0 Received: by 10.60.172.171 with SMTP id bd11mr27014461oec.4.1351521731017; Mon, 29 Oct 2012 07:42:11 -0700 (PDT) Received: by 10.182.217.8 with HTTP; Mon, 29 Oct 2012 07:42:10 -0700 (PDT) Date: Mon, 29 Oct 2012 10:42:10 -0400 Message-ID: From: Indtiny s To: mdnsext@ietf.org Content-Type: multipart/alternative; boundary=bcaec54b4e94aefa5f04cd33ac30 Subject: [mdnsext] xmDNS support in mdnsresponder for homenet X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 14:42:19 -0000 --bcaec54b4e94aefa5f04cd33ac30 Content-Type: text/plain; charset=ISO-8859-1 Hi, I was using the mdnsresponder for my home net related application now I need to support the xmDNS support as dicussed in the below draft http://ietfreport.isoc.org/ids/draft-lynn-homenet-site-mdns-01.txt Can some body tell me how feasible is this to go and edit this in the mdnsreponder core code ..? Rgds Indra --bcaec54b4e94aefa5f04cd33ac30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I was using the mdnsresponder for my h= ome net related application=A0 now I need to support the xmDNS support as d= icussed in the below draft
http://ietfreport.isoc.org/ids/draft-lynn-homenet-sit= e-mdns-01.txt=A0

Can some body tell=A0 me how feasible is this = to go and edit this in the mdnsreponder=A0 core code=A0 ..?


Rgds
Indra




--bcaec54b4e94aefa5f04cd33ac30-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A9421F867E for ; Sat, 27 Oct 2012 18:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.865 X-Spam-Level: X-Spam-Status: No, score=0.865 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8J1RrRu080Y for ; Sat, 27 Oct 2012 18:54:22 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) by ietfa.amsl.com (Postfix) with ESMTP id C2F6621F867D for ; Sat, 27 Oct 2012 18:54:22 -0700 (PDT) Received: from [172.16.10.3] (cpe-071-070-157-071.nc.res.rr.com [71.70.157.71]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 0B531111D3; Sat, 27 Oct 2012 21:52:22 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tom Pusateri In-Reply-To: Date: Sat, 27 Oct 2012 21:54:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1AD9C09A-7734-4895-93AC-EF7D12FBAE2A@bangj.com> References: <514CF52A-F985-4D7B-8845-525189080423@ecs.soton.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.1499) Cc: mdnsext@ietf.org Subject: Re: [mdnsext] draft-lynn-mdnsext-requirements-00 X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 01:54:23 -0000 On Oct 12, 2012, at 7:28 AM, Tim Chown wrote: > Just a heads up: >=20 > http://tools.ietf.org/html/draft-lynn-mdnsext-requirements-00 >=20 > Discussion on the problem statement is encouraged. >=20 > Tim 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 =3D> 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. ^^^ =3D> insert "IP" subnets =3D> =3D> Multicast DNS Queries (and often Responses) are sent to either the = IPv4 multicast =3D> address 224.0.0.251 or the IPv6 multicast address FF02::FB. =3D> These IP multicast addresses are considered part of the link-local = range and are not =3D> 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. =20 =3D> However, this wide-area mode is not commonly used. Issues with = wide-area bonjour include: =3D> 1. deploying dynamic update capabilities for the main DNS domain or = deploying parallel DNS infrastructure for a separate dynamic domain or = sub-domain. =3D> 2. familiarity with troubleshooting wide-area bonjour with existing = tools. =3D> 3. missing wide-area support in embedded devices and alternate = implementations 5. Security Considerations [TBD] =20 =3D> Extending service discovery across IP subnets, opens the door to = new security threats. =3D> Link-local threats are fairly well understood and typically = isolated in scope. Wide-area =3D> service discovery threats were mostly limited to dynamic DNS = updates or the restrictions =3D> placed on responses. =3D> When service discovery is replicated across multiple IP subnets, = forwarding restrictions are =3D> more difficult to contain and verify. Queries and responses may be = sent beyond administrative =3D> boundaries. Cryptographic services may be needed to protect against = leaks or malicious intent. Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B26121F879E for ; Wed, 17 Oct 2012 07:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.768 X-Spam-Level: X-Spam-Status: No, score=-102.768 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNmNzewHu6GN for ; Wed, 17 Oct 2012 07:12:30 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2F54521F8794 for ; Wed, 17 Oct 2012 07:12:30 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hm2so653898wib.1 for ; Wed, 17 Oct 2012 07:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=mtywNzWMdW5xEhTThusUsri2QP61WDJLj5puGFNdOUA=; b=l8sKuxgLF3rX1MIuFFL2Uvt+dNPt3O1wpejmuyBdDuIQtpfXLTiBx1oeWJ6X8DNhIV FvXiOqRcbAgLlK1gB0Hh5dswopmi9j06yp/eZHedqRtGo4/XTTg2C52awB4drzQQKGa8 KwqPrsWfyBg1GB3yYaDISIxEA8vS0FmDqj71BAVaXPAgQEZr27+305VLFxsQ/0q2NnyY D//qWL+59JwRXkJ2V65XED1MYiNz1mJ8KmfrmvsR9lnsLTqeIPjqsQ+D0jI5DsJFguP3 suf+ipBJkuIvqOVNc3/e048+lz2m+ltwyYNeSPvHwU8FPQOsWNFKKYF46gghMxyM9IOA /kKg== MIME-Version: 1.0 Received: by 10.216.53.204 with SMTP id g54mr9868458wec.122.1350483146283; Wed, 17 Oct 2012 07:12:26 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.194.0.178 with HTTP; Wed, 17 Oct 2012 07:12:26 -0700 (PDT) Date: Wed, 17 Oct 2012 10:12:26 -0400 X-Google-Sender-Auth: m3vDAAD089t-Qn4UTTNz08uWn4c Message-ID: From: Kerry Lynn To: mdnsext@ietf.org Content-Type: multipart/alternative; boundary=0016e6dab4da3599b804cc41dc16 Subject: [mdnsext] Announce X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 14:12:37 -0000 --0016e6dab4da3599b804cc41dc16 Content-Type: text/plain; charset=ISO-8859-1 Greetings, With the (hopefully) imminent approval of DNS-SD and mDNS as Proposed Standards, the time appears to be right to begin discussing extensions to these widely deployed protocols. This list now has over 100 subscribers; there are significant communities of interest, including the signatories to the Educause petition https://www.change.org/petitions/from-educause-higher-ed-wireless-networking-admin-group ; and vendors are bringing ad-hoc mDNS extensions to market in response to this demand. A BoF has been approved for IETF 85 (see "Extensions to the Bonjour protocol suite" at http://wiki.tools.ietf.org/bof/trac/) and it is hoped we have enough critical mass to begin working on DNS-SD/mDNS extensions as a community. The BoF is scheduled for Tuesday, 6 Nov, 1520 - 1650 in Grand Ballroom C and we hope to see you there. The draft charter/scope of work is very high level at this point: The MDNSEXT working group will develop extensions to DNS-SD/mDNS suitable for: 1. Enterprise networks 2. Academic/Educational/University networks 3. Multi-link home networks, such as those envisaged by HOMENET* 4. Multi-link/single subnet (mesh) networks, such as ROLL/6LoWPAN subnets * It is the intention that MDNSEXT develop a DNS-based solution that is suitable for these four network environments, including the HOMENET case. Of course the HOMENET WG is free to evaluate whether or not to adopt the MDNSEXT solution, or develop an alternative. Your comments on this and the draft problem statement/requirements in http://tools.ietf.org/html/draft-ietf-lynn-mdnsext-requirements are appreciated. -K- --0016e6dab4da3599b804cc41dc16 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Greetings,

With the (hopefully) imminent approval of DNS= -SD and mDNS as Proposed
Standards, the time appears to be right = to begin discussing extensions to
these widely deployed protocols= .

This list now has over 100 subscribers;=A0there are sig= nificant communities
of interest, including the signatories to th= e Educause petition
https://www.change.= org/petitions/from-educause-higher-ed-wireless-networking-admin-group;<= /div>
and vendors are bringing ad-hoc mDNS extensions to market in response<= /div>
to this demand.

A BoF has been approved = for IETF 85 (see "Extensions to the Bonjour
protocol suite&q= uot;=A0at=A0http://wiki.to= ols.ietf.org/bof/trac/) and it is hoped we have
enough critical mass to begin working on DNS-SD/mDNS extensions as
a community. =A0The BoF is scheduled for Tuesday, 6 Nov, 1520 - 1650=
in Grand Ballroom C and we hope to see you there.


The draft charter/scope of work is very high leve= l at this point:

The MDNSEXT working group wi= ll develop extensions to DNS-SD/mDNS
suitable for:

1. Enterprise networks
2. Academic/Educational/Uni= versity networks
3. Multi-link home networks, such as those envis= aged by HOMENET*
4. Multi-link/single subnet (mesh) networks, suc= h as ROLL/6LoWPAN subnets

* It is the intention that MDNSEXT develop a DNS-based = solution that
=A0 is suitable for these four network environments= , including the
=A0 HOMENET case. =A0Of course the HOMENET WG is = free to evaluate whether
=A0 or not to adopt the MDNSEXT solution, or develop an alternative.


Your comments on this and the = draft problem statement/requirements in
appreciated.

-K-

--0016e6dab4da3599b804cc41dc16-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBA921F874F for ; Wed, 17 Oct 2012 06:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.144 X-Spam-Level: X-Spam-Status: No, score=-102.144 tagged_above=-999 required=5 tests=[AWL=-0.834, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zx1jHWnFubhC for ; Wed, 17 Oct 2012 06:16:13 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 469B921F8741 for ; Wed, 17 Oct 2012 06:16:13 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so5658911lam.31 for ; Wed, 17 Oct 2012 06:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=vrxmG6IkVfO9haQN9vq+hAsaOoU7/vy6odEoafFUYyw=; b=hBOJ4Z4qNJjp56LG07mts4kwg3bBy2lDksS222A1NBGWjkTYyhYiRDwHkQLRrXwRFX RZzOciLC8sfnJ2QPooBWf2vCkipbrgWPHG8du9T/oL3JbfVK4WL3vHHSgOMaKU9ZKBFO SncEDe/RgeWfHN6KK7gDCWBGd236wVs8Y8ASlsnXrH9jUAI2EBv0tG6UyQuS5Vc+djw8 lauHaBwYpDzzqFOextQigVRZIWs+UjxTHHNRShUlY6ZHkwMWzsnrcQx74IT54ksy9mMs PwXrc0eQfqId8M32x9EWBIVKgA4l0lEozemvQOf3RpscJft7jSI3ie+g5rW6tTGtjRau RJ/Q== MIME-Version: 1.0 Received: by 10.112.14.9 with SMTP id l9mr2624075lbc.78.1350479772154; Wed, 17 Oct 2012 06:16:12 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.112.82.9 with HTTP; Wed, 17 Oct 2012 06:16:12 -0700 (PDT) In-Reply-To: <8c4619c1ff0ad7b8b67211bd434d3b05@xs4all.nl> References: <8c4619c1ff0ad7b8b67211bd434d3b05@xs4all.nl> Date: Wed, 17 Oct 2012 09:16:12 -0400 X-Google-Sender-Auth: lItRoPxlAQJ2fBT3QNFvyz6HYjk Message-ID: From: Kerry Lynn To: consultancy@vanderstok.org Content-Type: multipart/alternative; boundary=f46d0401fe75187ada04cc411394 Cc: mdnsext@ietf.org Subject: Re: [mdnsext] mdnsext requirements X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 13:16:18 -0000 --f46d0401fe75187ada04cc411394 Content-Type: text/plain; charset=ISO-8859-1 Peter, Thank you for your comments; see below... On Wed, Oct 17, 2012 at 3:15 AM, peter van der Stok wrote: > > Dear Stuart and Kerry, > > The requirements are quite high level and seem to cover the subject > reasonably well. > > However, the subject of network join and network partition does not seem > to be covered. > I agree that this topic should be explicitly in scope. The question of what is meant by "join" should be addressed. I expect it will apply to L3 (adding new subnets) as well as L2. Note that in a strictly L2 scenario, mDNS does attempt to mitigate this issue (see "Passive Conflict Detection" in the mDNS draft). However, simply flooding mDNS queries and responses across routed links is problematic in the face of routing loops, which we must assume to be present. The joining of local networks can have an impact on the names which may be > ambiguous after the join. > I have ideas on this, but I typically think in "solution space" so a new thread is probably warranted. > The joining of a local network to global also has an impact on the naming. > Iff one expects the instance part of the DNS name to be unique in all scopes, which may be desirable but practically very difficult. > I would appreciate if the requirements could reflect that rules for > handling the (re)naming of nodes during these joins and partitions are > necessary. > > Not to mention how to detect the topology change in the first place. > Although scalability is explicitly mentioned, it may help me if mention is > made of the introduction of a directory to mDNS. > > The final requirements may inevitably lead to this conclusion. However, I'll leave it to the list to decide whether this should be in the requirements I-D or in the charter/scope. I'll post the draft charter in a new thread. Regards, -K- > > Greetings, > > peter > > -- > Peter van der Stok > mailto: consultancy@vanderstok.org > www: www.vanderstok.org > tel NL: +31(0)492474673 F: +33(0)966015248 > ______________________________**_________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/**listinfo/mdnsext > --f46d0401fe75187ada04cc411394 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Peter,

Thank you for your comments; see below...

=
On Wed, Oct 17, 2012 at 3:15 AM, peter van der S= tok <stokcons@xs4all.nl> wrote:

Dear Stuart and Kerry,

The requirements are quite high level and seem to cover the subject reasona= bly well.

However, the subject of network join and network partition does not seem to= be covered.

I agree that this topic sh= ould be explicitly in scope. =A0The question of what is meant
by "join" should be addressed. =A0I expect it will apply to L3 (a= dding new subnets) as
well as L2.

Note t= hat in a strictly L2 scenario, mDNS does attempt to mitigate this issue (se= e
"Passive Conflict Detection" i= n the mDNS draft). =A0However, simply flooding mDNS
queries and responses across routed links is proble= matic in the face of routing
loops, which we must assume to be presen= t.

The joining of local networks can have an impact on the names which may be = ambiguous after the join.

I have ideas = on this, but I typically think in "solution space" so a new threa= d is
probably warranted.
=A0
The joining of a local network to global also has an impact on the naming.<= br>

Iff one expects the instance part of th= e DNS name to be unique in all scopes,
which may be desirable but= practically very difficult.
=A0
I would appreciate if the requirements could reflect that rules for handlin= g the (re)naming of nodes during these joins and partitions are necessary.<= br>
Not to mention how to detect the topology change in t= he first place.
=A0
Although scalability is explicitly mentioned, it may help me if mention is = made of the introduction of a directory to mDNS.

The final requirements may inevitably lead to this co= nclusion. =A0However, I'll
leave it to the list to decide whe= ther this should be in the requirements I-D
or in the charter/sco= pe. =A0I'll post the draft charter in a new thread.

Regards, -K-=A0

Greetings,

peter

--
Peter van der Stok
mailto: con= sultancy@vanderstok.org
www: www.vanderstok= .org
tel NL: +31(0)492474673 =A0 =A0 F: +33(0)966015248
_______________________________________________
mdnsext mailing list
mdnsext@ietf.org<= br> https://www.ietf.org/mailman/listinfo/mdnsext

--f46d0401fe75187ada04cc411394-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E305921F86BA for ; Wed, 17 Oct 2012 00:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.053 X-Spam-Level: * X-Spam-Status: No, score=1.053 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0v1-NE73UxLH for ; Wed, 17 Oct 2012 00:16:11 -0700 (PDT) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by ietfa.amsl.com (Postfix) with ESMTP id BFC5421F8793 for ; Wed, 17 Oct 2012 00:16:10 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube3.xs4all.net [194.109.20.199]) by smtp-vbr4.xs4all.nl (8.13.8/8.13.8) with ESMTP id q9H7FdE7006596 for ; Wed, 17 Oct 2012 09:15:39 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-135-8.w90-0.abo.wanadoo.fr ([90.0.94.8]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 17 Oct 2012 09:15:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 17 Oct 2012 09:15:38 +0200 From: peter van der Stok To: Organization: vanderstok consultancy Mail-Reply-To: Message-ID: <8c4619c1ff0ad7b8b67211bd434d3b05@xs4all.nl> X-Sender: stokcons@xs4all.nl (i2TdZ1WlPuRSuDsPdZT+Z0nqXxa3n5v9) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [mdnsext] mdnsext requirements X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 07:16:12 -0000 Dear Stuart and Kerry, The requirements are quite high level and seem to cover the subject reasonably well. However, the subject of network join and network partition does not seem to be covered. The joining of local networks can have an impact on the names which may be ambiguous after the join. The joining of a local network to global also has an impact on the naming. I would appreciate if the requirements could reflect that rules for handling the (re)naming of nodes during these joins and partitions are necessary. Although scalability is explicitly mentioned, it may help me if mention is made of the introduction of a directory to mDNS. Greetings, peter -- Peter van der Stok mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C18521F844C for ; Fri, 12 Oct 2012 04:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4g2XbeUPadU for ; Fri, 12 Oct 2012 04:28:32 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 4E89221F8445 for ; Fri, 12 Oct 2012 04:28:32 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9CBSUVl016875 for ; Fri, 12 Oct 2012 12:28:31 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9CBSUVl016875 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1350041311; bh=S0SsmLLPtir1AY5wAT/GXWfIyKc=; h=From:Subject:Date:To:Mime-Version:References; b=raAF7guDgqRh9bYocDz+hq0UaQxpw5U0pzTsaGf90ZD4WnNmKXNoOsoq2GRapDav+ /OK+RMz1QxKo8g8aQ8HcCngDVfFvBYIgBtcXmkNV17MakScBOM2gD5SikdK8rTf7h7 IzJjhvngesrSUjjS2CUEkYPybkeEkVkBA84u+RB0= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id o9BCSU0430607995eO ret-id none; Fri, 12 Oct 2012 12:28:31 +0100 Received: from ip-205-015.eduroam.soton.ac.uk (ip-205-015.eduroam.soton.ac.uk [152.78.205.15]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9CBSUrS003974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 12 Oct 2012 12:28:30 +0100 From: Tim Chown Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Fri, 12 Oct 2012 12:28:30 +0100 To: mdnsext@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-smtpf-Report: sid=o9BCSU043060799500; tid=o9BCSU0430607995eO; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: <514CF52A-F985-4D7B-8845-525189080423@ecs.soton.ac.uk> X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9CBSUVl016875 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: [mdnsext] draft-lynn-mdnsext-requirements-00 X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 11:28:33 -0000 Just a heads up: http://tools.ietf.org/html/draft-lynn-mdnsext-requirements-00 Discussion on the problem statement is encouraged. Tim Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D095A1F041C for ; Tue, 9 Oct 2012 13:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9A1eqO16dexq for ; Tue, 9 Oct 2012 13:39:21 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 47EBD1F040A for ; Tue, 9 Oct 2012 13:39:18 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j40so3460448qab.10 for ; Tue, 09 Oct 2012 13:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=BDriaSaeHB3kBJpEFC4+efWhYUfBLB44eVwQGuprOAA=; b=cD8Y82ZwXQ20cX2tS4lUXl7SDK4yAmdVAmGK5/2K91LrWcrpXtvUdmOSPIp3GcjjfU EeSr/vvFztdVZBp6J73yI1nbqz4tiprxY8KTaRaLVLZ6Iw6j6mkJ879rLa28fct4x4cl HO3n3d4jBuYCsOTE5/7DkSRREAfjqD8FG4JGzay7mpBs+7RL0AKORVA4EqbvxW0wyfVV g2v3HlMklFqNN0IQJykxwCErW/JHX79gNTk0ps0Aj/xZMjKo6e8Gc8Iy9cPdrxMZmoD4 ZYGzWOR1eV2t6gDe4plQbLyP39nJVjUIK278+30yfkqe9OZ3zfPrsBGBfQD+oE21ha// FaTA== Received: by 10.49.48.111 with SMTP id k15mr51198809qen.28.1349815157794; Tue, 09 Oct 2012 13:39:17 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id x19sm21409011qeq.12.2012.10.09.13.39.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Oct 2012 13:39:17 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 9 Oct 2012 16:39:15 -0400 Message-Id: <2056835F-AD6B-4E41-9D90-6DCB29F3F42F@gmail.com> To: mdnsext@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [mdnsext] Test - please ignore X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 20:39:22 -0000 Is this list operational? - Ralph