From nobody Thu Mar 10 04:40:10 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9241112D707 for ; Thu, 10 Mar 2016 04:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVPHzIwbaB7B for ; Thu, 10 Mar 2016 04:40:04 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E556912D6CD for ; Thu, 10 Mar 2016 04:40:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1516; q=dns/txt; s=iport; t=1457613603; x=1458823203; h=from:to:subject:date:message-id:mime-version; bh=X6X86ZMWfQfkLPy+zbZeKAWVZ18SA5sTCO3umgEKfRE=; b=f77o7Tnt/29Mj71qQFwSFoFCiADogYrDAFnpG142gfCPIG3Tskbum/Bf xzlv9vlzpYZyaZ9IMYYFR3rxURpuQiPawwBAfQxy9kpE7x1/QfIfhp92D W57VfXB+E2a1dTIt8k/n3W6RFj8/+bkojtjZN4KBUddGwM6LrcSmDQa1l E=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A0BQA/auFW/4ENJK1egz6BRbhEgiGBb?= =?us-ascii?q?YdOOhIBAQEBAQEBZBwLhEgdbgGBACcEIYgWnkGfAgEBAQEBBQEBAQEBAQEBEAi?= =?us-ascii?q?GGIFzijSBDwWXPAGBJoFxgWWIe4FOARWER4hUjmkBJgE7g2SJP34BAQE?= X-IronPort-AV: E=Sophos;i="5.24,315,1454976000"; d="asc'?scan'208";a="79612819" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Mar 2016 12:40:03 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u2ACe32s002354 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 10 Mar 2016 12:40:03 GMT Received: from xch-aln-016.cisco.com (173.36.7.26) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 10 Mar 2016 06:40:02 -0600 Received: from xch-aln-016.cisco.com ([173.36.7.26]) by XCH-ALN-016.cisco.com ([173.36.7.26]) with mapi id 15.00.1104.009; Thu, 10 Mar 2016 06:40:02 -0600 From: "Ralph Droms (rdroms)" To: "dnssd@ietf.org" Thread-Topic: Call for agenda items, IETF 95 dnssd WG meeting Thread-Index: AQHResn2UbSEcxBapUStUp8xh1jnVA== Date: Thu, 10 Mar 2016 12:40:01 +0000 Message-ID: <5CFF7356-D10A-49A3-BAF2-667016DC5D1B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.250.216] Content-Type: multipart/signed; boundary="Apple-Mail=_910104FF-2C80-451A-8F22-78B391BAD081"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: [dnssd] Call for agenda items, IETF 95 dnssd WG meeting X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 10 Mar 2016 12:40:09 -0000 --Apple-Mail=_910104FF-2C80-451A-8F22-78B391BAD081 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The dnssd WG mill meet at IETF 95 in Buenos Aires. Our meeting slot is = Monday, 15:50-17:20. Please send e-mail to the chairs if you'd like a slot on the agenda. - Ralph --Apple-Mail=_910104FF-2C80-451A-8F22-78B391BAD081 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJW4WshAAoJEINeeBNmFjV5AzIP/jiFUfTOZwS2AUjrKUxLKJ4V r2Lpd3MZJlvwLsm7KnF2doW10zbNKOeynUXd5a7iidY0iyDSpLbCBViPV6K6kfQQ BWazy8SDHDGXn61LI0vUrc5CEJD1Vwi/11TBzG5rypIwpI/GY14BDVgjJR/b6sz8 /XCXK9TH0CmvpgZeC21p9jb73pxOngMHGs/lq62MU76CjyOCoghgNZa6Ikq4gH/K /S8mSajMi58h1rMzq2dNSJvxuHeUviCMR01koX2gJc+C+8mccWsEoni8gM0dEqG1 X2I1CXPpYZ2tVZdRqisoOPl98a3mZhXUigTp6+lUBGSX9Zjnd25i1q7AZJqXAuUW qMNcLJLewvfHIMPfIYKloNKftTK2BHbjAIHCaTqDyZ6MYoE+BeHZ2Lp0fmClzRlk q4JL42RYIGvBUsCVSsiXxBs9fYeasnvlutPrwMgpEhDLb8t41e7uJhJpfZP+8CPD 5/7wjNq9Bg5dWL39tZg3de4gdniCnw+xlh0Hk1KycWza10Hha36anTI7EMLoWC80 d/1qGG4KiF2P4TK200xVwL1TYO3XK1V+sFhbyhnUOKdVKl8ZVi9sdOL+OQb/T0Se Xxl4fgIP13FXsQXtRXBkstO9r4kN7nSadReSWQhd48/kxfoRGbkD1NIDMT+85vhj JR88tpxsrB902zxbeA45 =h6V2 -----END PGP SIGNATURE----- --Apple-Mail=_910104FF-2C80-451A-8F22-78B391BAD081-- From nobody Fri Mar 11 15:06:53 2016 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC1612DE09; Fri, 11 Mar 2016 15:05:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230533.15028.78505.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:33 -0800 Archived-At: Cc: dnssd@ietf.org, terry.manderson@icann.org Subject: [dnssd] dnssd - Requested session has been scheduled for IETF 95 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2016 23:05:34 -0000 Dear Ralph Droms, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dnssd Session 1 (1:30:00) Monday, Afternoon Session II 1550-1720 Room Name: Buen Ayre B size: 125 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Extensions for Scalable DNS Service Discovery Area Name: Internet Area Session Requester: Ralph Droms Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: 6man dnsop homenet dprive dbound dhc 6lo iccrg Second Priority: roll core t2trg irtfopen dane 6tisch Special Requests: --------------------------------------------------------- From nobody Thu Mar 17 13:20:22 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBCA12D555 for ; Thu, 17 Mar 2016 13:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulC9cD4C3ynd for ; Thu, 17 Mar 2016 13:20:19 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89F8112D1DC for ; Thu, 17 Mar 2016 13:20:19 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 1164A25CA249; Thu, 17 Mar 2016 20:20:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9m1Uvem7EYu; Thu, 17 Mar 2016 21:19:42 +0100 (CET) Received: from localhost.localdomain (p200300864F392BDEF2DEF1FFFE58C5D4.dip0.t-ipconnect.de [IPv6:2003:86:4f39:2bde:f2de:f1ff:fe58:c5d4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 8B04725CA029; Thu, 17 Mar 2016 21:19:42 +0100 (CET) References: <20160317201403.2551.19289.idtracker@ietfa.amsl.com> To: dnssd@ietf.org, ajs@shinkuro.com From: Hosnieh Rafiee X-Forwarded-Message-Id: <20160317201403.2551.19289.idtracker@ietfa.amsl.com> Message-ID: <56EB115D.6070406@rozanak.com> Date: Thu, 17 Mar 2016 21:19:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160317201403.2551.19289.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dnssd] Fwd: New Version Notification for draft-otis-dnssd-scalable-dns-sd-threats-03.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 17 Mar 2016 20:20:21 -0000 Dear All, we have uploaded new version of threat model. We would appreciate your comments to finalize this draft. @Andrew: would you please check it to see whether your comments were addressed. Thank you Best, Douglas und Hosnieh A new version of I-D, draft-otis-dnssd-scalable-dns-sd-threats-03.txt has been successfully submitted by Hosnieh Rafiee and posted to the IETF repository. Name: draft-otis-dnssd-scalable-dns-sd-threats Revision: 03 Title: Scalable DNS-SD (SSD) Threats Document date: 2016-03-17 Group: Individual Submission Pages: 21 URL: https://www.ietf.org/internet-drafts/draft-otis-dnssd-scalable-dns-sd-threats-03.txt Status: https://datatracker.ietf.org/doc/draft-otis-dnssd-scalable-dns-sd-threats/ Htmlized: https://tools.ietf.org/html/draft-otis-dnssd-scalable-dns-sd-threats-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-otis-dnssd-scalable-dns-sd-threats-03 Abstract: mDNS combined with Service Discovery (DNS-SD) extends network resource distribution beyond the reach of multicast normally limited by the MAC Bridge. Since related resources are often not authenticated, either local resources are inherently trustworthy or are subsequently verified by associated services. Resource distribution becomes complex when a hybrid scheme combines adjacent network resources into a common unicast DNS-SD structure. This document explores related security considerations. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Mar 17 15:27:34 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BE312DD5B for ; Thu, 17 Mar 2016 15:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.521 X-Spam-Level: X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ecs.soton.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 562WxwTc7Jbc for ; Thu, 17 Mar 2016 15:27:30 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DD1612DD61 for ; Thu, 17 Mar 2016 15:27:28 -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 u2HMRHE0027912; Thu, 17 Mar 2016 22:27:17 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk u2HMRHE0027912 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1458253638; bh=e2BzcamwBmktUpPBrZj/nArCnAg=; h=From:Subject:Date:Cc:To:Mime-Version:References; b=Zwkrl5zVyPKUKFtsfSQ1EvupGm8lQyJbtpp2s3/CVBqDpXsoxaqRVLLjEsEx39po+ x+LjChlNKLvOQeMmbhAUDj7y4NhVX9xhPQ7Lqy1yhS7uRx61is6Qi8zOBTjEsSiiC1 qyiPKVmQzg1pFtspbN5WEs9cdO/lndlaMfu4hiaw= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id s2GMRH3163415110Sj ret-id none; Thu, 17 Mar 2016 22:27:17 +0000 Received: from 20010a88d51011.ipv6.customer.clara.net (20010a88d51011.ipv6.customer.clara.net [IPv6:2001:a88:d510:1101:a97d:a893:346b:79a9] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u2HMR3Pa031960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Mar 2016 22:27:03 GMT From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_BD6C7CA4-CE2A-4169-BACE-E381DAE2E973" Date: Thu, 17 Mar 2016 22:27:01 +0000 Message-ID: To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=s2GMRH316341511000; tid=s2GMRH3163415110Sj; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 References: <258B939E-D88C-463A-B2F7-9888E30A482C@ecs.soton.ac.uk> X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: u2HMRHE0027912 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Cc: Christian Huitema , Ralph Droms Subject: [dnssd] IETF95 meeting agenda, and progressing dnssd WG drafts X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 17 Mar 2016 22:27:33 -0000 --Apple-Mail=_BD6C7CA4-CE2A-4169-BACE-E381DAE2E973 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, The dnssd WG has a 90 minute session arranged for IETF95 in BA. The = session runs from 3:50 - 5:20pm (local time) on Monday 4th April (6:50pm = to 8:20pm UTC). Ralph and I would welcome requests for agenda time. We would expect to = discuss a number of drafts, including at least: draft-ietf-dnssd-hybrid-03 draft-ietf-dnssd-mdns-dns-interop-02 draft-ietf-dnssd-push-05 draft-otis-dnssd-scalable-dns-sd-threats-03 draft-huitema-dnssd-privacy-00 (see https://datatracker.ietf.org/wg/dnssd/documents/ = for fuller details) Ralph and I have discussed status of these drafts, and as a result we = are initiating WGLCs for both draft-ietf-dnssd-hybrid-03 and = draft-ietf-dnssd-mdns-dns-interop-02 with a two-week window, which will = allow us to review the resulting comments raised in the BA meeting, and = determine the actions required to progress both items towards = publication. We will be soliciting comments from the dnsop WG on = draft-ietf-dnssd-push-05 in advance of the meeting, with a view to = deciding at the meeting whether we=E2=80=99re in a position to initiate = a WGLC for that draft. We=E2=80=99re aware of some potential overlap = with other dnsop work around DNS privacy and DNS over TLS, which we = would welcome comment on. We also anticipate that we may have feedback = from at least one implementation of DNS Push before the meeting. As Hosnieh just posted, there is a new update of the threats draft, = draft-otis-dnssd-scalable-dns-sd-threats-03. We would like to encourage = people to respond to Hosnieh's request for comments on this latest = version. We may also wish to discuss in BA whether to revisit = draft-aggarwal-dnssd-optimize-query-00 (perhaps as part of a wider = operational scalability discussion), and we note that = draft-ietf-dnssd-hybrid-03 suggests further work (in section 6.4) on = stitching together .local zones. Tim --Apple-Mail=_BD6C7CA4-CE2A-4169-BACE-E381DAE2E973 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

The = dnssd WG has a 90 minute session arranged for IETF95 in BA. The session = runs from 3:50 - 5:20pm (local time) on Monday 4th April (6:50pm to = 8:20pm UTC).

Ralph and I would welcome requests for agenda time.  We = would expect to discuss a number of drafts, including at = least:

draft-ietf-dnssd-hybrid-03
draft-ietf-dnssd-mdns-dns-interop-02
draft-ietf-dnssd-push-05
draft-otis-dnssd-scalable-dns-sd-threats-03
draft-huitema-dnssd-privacy-00
(see https://datatracker.ietf.org/wg/dnssd/documents/ for = fuller details)

Ralph and I have discussed status of these drafts, and as a = result we are initiating WGLCs for both draft-ietf-dnssd-hybrid-03 and = draft-ietf-dnssd-mdns-dns-interop-02 with a two-week window, which will = allow us to review the resulting comments raised in the BA meeting, and = determine the actions required to progress both items towards = publication.

We = will be soliciting comments from the dnsop WG on = draft-ietf-dnssd-push-05 in advance of the meeting, with a view to = deciding at the meeting whether we=E2=80=99re in a position to initiate = a WGLC for that draft. We=E2=80=99re aware of some potential overlap = with other dnsop work around DNS privacy and DNS over TLS, which we = would welcome comment on. We also anticipate that we may have feedback = from at least one implementation of DNS Push before the = meeting.

As Hosnieh just posted, there is a = new update of the threats draft, = draft-otis-dnssd-scalable-dns-sd-threats-03. We would like to encourage = people to respond to Hosnieh's request for comments on this latest = version.

We may also wish to discuss in BA whether to = revisit draft-aggarwal-dnssd-optimize-query-00 (perhaps as part of = a wider operational scalability discussion), and we note that = draft-ietf-dnssd-hybrid-03 suggests further work (in section 6.4) on = stitching together .local zones.

Tim



= --Apple-Mail=_BD6C7CA4-CE2A-4169-BACE-E381DAE2E973-- From nobody Thu Mar 17 15:37:16 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C168712DD6D for ; Thu, 17 Mar 2016 15:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.521 X-Spam-Level: X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ecs.soton.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21gMaDuJb4TK for ; Thu, 17 Mar 2016 15:37:12 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A836E12DD70 for ; Thu, 17 Mar 2016 15:37:03 -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 u2HMb1oJ029958 for ; Thu, 17 Mar 2016 22:37:01 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk u2HMb1oJ029958 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1458254221; bh=90uAv+DhPRTeCV5lbvVhCOH5+S4=; h=From:Subject:Date:To:Mime-Version:References; b=VKXCsDWPtX20dMA+hr/b28iRt7NhYBaYPXrT7KxujowU8hBgViAtFEhX8PJTZFYrp kKQ6fbaQeWk+vA+BXF/buiaun/Wmii8EqpSBu1B7crR+VWNOHtdhXGEJH09ew1p/47 lZZbfKa9aRDmJ1YPN8YhBZsTtQrr55t0FAbI+JsI= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id s2GMb13163415178aA ret-id none; Thu, 17 Mar 2016 22:37:01 +0000 Received: from 20010a88d51011.ipv6.customer.clara.net (20010a88d51011.ipv6.customer.clara.net [IPv6:2001:a88:d510:1101:a97d:a893:346b:79a9] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u2HMam2m001845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Mar 2016 22:36:49 GMT From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_CDEC88D6-F37B-4138-8B79-D422B837C77F" Message-ID: Date: Thu, 17 Mar 2016 22:36:47 +0000 To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=s2GMb1316341517800; tid=s2GMb13163415178aA; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: <7274B55E-8A4D-4BEE-85F9-C19EC62EEF03@ecs.soton.ac.uk> X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: u2HMb1oJ029958 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Subject: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 17 Mar 2016 22:37:15 -0000 --Apple-Mail=_CDEC88D6-F37B-4138-8B79-D422B837C77F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear dnssd WG participants, We are initiating a WG Last Call today on draft-ietf-dnssd-hybrid-03, as = can be found at https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03 = . The call runs for two weeks, and will thus close on Thursday 31st March. Please send any comments (including indications of support for = progression of the document as is) to the dnssd@ietf.org list. This = draft will not be advanced for publication unless there is sufficient = response and support from the WG. And, of course, any substantive = comments on the draft are strongly encouraged as well. We are aware of a = small number of minor outstanding comments from the list, but will = consider these as part of the WGLC process. We will discuss the comments arising from the WGLC in the WG meeting in = BA on Monday 4th April. Abstract Performing DNS-Based Service Discovery using purely link-local Multicast DNS enables discovery of services that are on the local link, but not (without some kind of proxy or similar special support) discovery of services that are outside the local link. Using a very large local link with thousands of hosts facilitates service discovery, but at the cost of large amounts of multicast traffic. Performing DNS-Based Service Discovery using purely Unicast DNS is more efficient and doesn't require excessively large multicast domains, but requires that the relevant data be available in the Unicast DNS namespace. This can be achieved by manual DNS configuration (as has been done for many years at IETF meetings to advertise the IETF Terminal Room printer) but this is labor intensive, error prone, and requires a reasonable degree of DNS expertise. The Unicast DNS namespace can be populated with the required data automatically by the devices themselves, but that requires configuration of DNS Update keys on the devices offering the services, which has proven onerous and impractical for simple devices like printers and network cameras. Hence, to facilitate efficient and reliable DNS-Based Service Discovery, a compromise is needed that combines the ease-of-use of Multicast DNS with the efficiency and scalability of Unicast DNS. Thanks, Ralph and Tim dnssd WG co-chairs --Apple-Mail=_CDEC88D6-F37B-4138-8B79-D422B837C77F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear dnssd WG participants,

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

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

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

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

Abstract

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

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

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


Thanks,

Ralph and Tim
dnssd WG co-chairs




= --Apple-Mail=_CDEC88D6-F37B-4138-8B79-D422B837C77F-- From nobody Thu Mar 17 15:39:31 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB2412DD72 for ; Thu, 17 Mar 2016 15:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.521 X-Spam-Level: X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ecs.soton.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bh5hwnCk2Spl for ; Thu, 17 Mar 2016 15:39:22 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D18F012DD67 for ; Thu, 17 Mar 2016 15:39:21 -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 u2HMdHKB030214 for ; Thu, 17 Mar 2016 22:39:17 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk u2HMdHKB030214 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1458254357; bh=nKK1ETOnOZCKKEn0mue7Eih6ReI=; h=From:Subject:Date:To:Mime-Version:References; b=CESNdRxf4LidOxtjgLODlsAkkkywOtOEVSGuK+0ZV800odNUJ50XF+/v7eYwWc6bz 1fX53b5UYryAS1LzLF6wykP0GgSt2RQM4Bna7PkMlT7PaJ8l4Vph5S/QbNrOvX/mlR Hvb3hkd2d8u3CvtPzYgyLhMy/irgdqGyjFFqitVI= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id s2GMdH3163415193AH ret-id none; Thu, 17 Mar 2016 22:39:17 +0000 Received: from 20010a88d51011.ipv6.customer.clara.net (20010a88d51011.ipv6.customer.clara.net [IPv6:2001:a88:d510:1101:a97d:a893:346b:79a9] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u2HMdB7V002181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Mar 2016 22:39:11 GMT From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_F10ECF46-2D01-48A6-A78A-B1F6BD7FF8D0" Message-ID: Date: Thu, 17 Mar 2016 22:39:10 +0000 To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=s2GMdH316341519300; tid=s2GMdH3163415193AH; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: u2HMdHKB030214 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Subject: [dnssd] WGLC on draft-ietf-dnssd-mdns-dns-interop-02 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 17 Mar 2016 22:39:25 -0000 --Apple-Mail=_F10ECF46-2D01-48A6-A78A-B1F6BD7FF8D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear dnssd WG participants, We are initiating a WG Last Call today on = draft-ietf-dnssd-mdns-dns-interop-02, as can be found at = https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-02 = . The call runs for two weeks, and will thus close on Thursday 31st March. Please send any comments (including indications of support for = progression of the document as is) to the dnssd@ietf.org list. This = draft will not be advanced for publication unless there is sufficient = response and support from the WG. And, of course, any substantive = comments on the draft are strongly encouraged as well.=20 We will discuss the comments arising from the WGLC in the WG meeting in = BA on Monday 4th April. Abstract Despite its name, DNS-Based Service Discovery can use naming systems other than the Domain Name System when looking for services. Moreover, when it uses the DNS, DNS-Based Service Discovery uses the full capability of DNS, rather than using a subset of available octets. In order for DNS-SD to be used effectively in environments where multiple different name systems and conventions for their operation are in use, it is important to attend to differences in the underlying technology and operational environment. This memo presents an outline of the requirements for selection of labels for conventional DNS and other resolution systems when they are expected to interoperate in this manner. Thanks, Ralph and Tim dnssd WG co-chairs --Apple-Mail=_F10ECF46-2D01-48A6-A78A-B1F6BD7FF8D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear dnssd WG participants,

We are initiating a WG Last Call today on = draft-ietf-dnssd-mdns-dns-interop-02, as can be found at https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-0= 2.

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

Please send any comments (including indications of support = for progression of the document as is) to the dnssd@ietf.org list. This = draft will not be advanced for publication unless there is = sufficient response and support from the WG.  And, of course, = any substantive comments on the draft are strongly encouraged as = well. 

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

Abstract

   Despite its name, DNS-Based Service Discovery can use naming systems
   other than the Domain Name System when looking for services.
   Moreover, when it uses the DNS, DNS-Based Service Discovery uses the
   full capability of DNS, rather than using a subset of available
   octets.  In order for DNS-SD to be used effectively in environments
   where multiple different name systems and conventions for their
   operation are in use, it is important to attend to differences in the
   underlying technology and operational environment.  This memo
   presents an outline of the requirements for selection of labels for
   conventional DNS and other resolution systems when they are expected
   to interoperate in this manner.


Thanks,

Ralph and Tim
dnssd WG = co-chairs



= --Apple-Mail=_F10ECF46-2D01-48A6-A78A-B1F6BD7FF8D0-- From nobody Thu Mar 17 16:12:03 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762BC12DDBD for ; Thu, 17 Mar 2016 16:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.521 X-Spam-Level: X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ecs.soton.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGu23cZIZU2x for ; Thu, 17 Mar 2016 16:11:59 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B2AE12DDC1 for ; Thu, 17 Mar 2016 16:11:58 -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 u2HNBl3e004339; Thu, 17 Mar 2016 23:11:47 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk u2HNBl3e004339 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1458256307; bh=HwNTZxpOwWcblEg5kT7FEt3HKFE=; h=From:Mime-Version:Subject:Date:References:Cc:To; b=5V49hyeToRf0hj8xh3wPPmehFeAtd9N7DybSSQWC/uRkWjAEvhKuRA8zf3I3hHUhI ji9aQsNciGJ3hy73PZol1cQrjPBD6K2eQwwP+OtUsi4TBKiJvQPCqSFWJeRdGFKm56 4u9t1cHr1R7/7KagWBEMhgHtxR1wLUMYbmQbeiso= 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 s2GNBl3163415446x6 ret-id none; Thu, 17 Mar 2016 23:11:47 +0000 Received: from 20010a88d51011.ipv6.customer.clara.net (20010a88d51011.ipv6.customer.clara.net [IPv6:2001:a88:d510:1101:a97d:a893:346b:79a9] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u2HNBejP010142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Mar 2016 23:11:40 GMT From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_2C0FEA3C-412F-4DD5-A929-8ECAC8EE70C4" Message-ID: Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Date: Thu, 17 Mar 2016 23:11:39 +0000 References: <20160310013909.9336.65458.idtracker@ietfa.amsl.com> <7E27ED38-3858-4080-A31E-2116EA2DD436@ecs.soton.ac.uk> To: dnssd@ietf.org X-Mailer: Apple Mail (2.3112) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=s2GNBl316341544600; tid=s2GNBl3163415446x6; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: u2HNBl3e004339 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Cc: Christian Huitema Subject: [dnssd] Fwd: I-D Action: draft-huitema-dnssd-privacy-00.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 17 Mar 2016 23:12:01 -0000 --Apple-Mail=_2C0FEA3C-412F-4DD5-A929-8ECAC8EE70C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Ralph and I would welcome comments to the list on this draft. Tim > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: I-D Action: draft-huitema-dnssd-privacy-00.txt > Date: 10 March 2016 at 01:39:09 GMT > To: > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Privacy Extensions for DNS-SD > Author : Christian Huitema > Filename : draft-huitema-dnssd-privacy-00.txt > Pages : 12 > Date : 2016-03-09 >=20 > Abstract: > DNS-SD allows discovery of services published in DNS or MDNS. The > publication normally disclose information about the device = publishing > the services. There are use cases where devices want to communicate > without disclosing their identity, for example two mobile devices > visiting the same hotspot. We propose a method to obfuscate the > identification information published by DNS-SD. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-huitema-dnssd-privacy-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_2C0FEA3C-412F-4DD5-A929-8ECAC8EE70C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

Ralph = and I would welcome comments to the list on this draft.

Tim

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = I-D Action: = draft-huitema-dnssd-privacy-00.txt
Date: = 10 March 2016 at 01:39:09 = GMT
To: = <i-d-announce@ietf.org>
Reply-To: = internet-drafts@ietf.org


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.


=        Title =           : Privacy = Extensions for DNS-SD
=        Author =          : Christian = Huitema
Filename =        : = draft-huitema-dnssd-privacy-00.txt
Pages =           : 12
= Date =            : = 2016-03-09

Abstract:
=   DNS-SD allows discovery of services published in DNS or = MDNS.  The
  publication normally disclose = information about the device publishing
  the = services.  There are use cases where devices want to communicate
  without disclosing their identity, for example = two mobile devices
  visiting the same hotspot. =  We propose a method to obfuscate the
=   identification information published by DNS-SD.


The IETF datatracker status = page for this draft is:
https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/

There's also a htmlized version = available at:
https://tools.ietf.org/html/draft-huitema-dnssd-privacy-00


Please note that it may take a = couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

= --Apple-Mail=_2C0FEA3C-412F-4DD5-A929-8ECAC8EE70C4-- From nobody Mon Mar 21 16:58:46 2016 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8ABE12D183; Mon, 21 Mar 2016 16:58:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321235841.10905.16735.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 16:58:41 -0700 Archived-At: Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-06.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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, 21 Mar 2016 23:58:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery of the IETF. Title : DNS Push Notifications Authors : Tom Pusateri Stuart Cheshire Filename : draft-ietf-dnssd-push-06.txt Pages : 31 Date : 2016-03-21 Abstract: The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that is relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled. But there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnssd-push-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-push-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 21 19:54:22 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A238A12D0E8 for ; Mon, 21 Mar 2016 19:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.322 X-Spam-Level: X-Spam-Status: No, score=-104.322 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vObzmZrTThy6 for ; Mon, 21 Mar 2016 19:54:19 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 233C312D179 for ; Mon, 21 Mar 2016 19:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1458615258; x=2322528858; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=t1fsARNq1G8+nGmZRLpjm++UaTeh0QsV9iS/kOFv/Yk=; b=hMcUJo7fktxgwhNn0LUv1yXEQICSAovhCrD01gT1OvWnhgGojp/X0ZLB2KV2kNTS aUGW2xajSPliBipsG0B6P00/uKgKCD+cvNXfA47btw9PjrAwx0YoEgHOM7yncW5j HvRpJqCm6uBe45m4KzQUI9/80FYkHOcVD2DZsdu4Kh+jarUr2kRWbRRRQhZAWkHD u9r6U7n19WeiH25atVoUUdmVN4mBYEDdmu6nzvYaBJjwLSUxuynavQozQcyrP2fJ Ovw2jU+IT5/Q34WurQp1yDA0D7J3PC5RHKkNz4xOM72ixUTnhbb8k47+GpBUY5Dt R+n4wlfmYy0EBY8QTfqqsg==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id DC.DC.27179.AD3B0F65; Mon, 21 Mar 2016 19:54:18 -0700 (PDT) X-AuditID: 11973e15-f79686d000006a2b-3b-56f0b3dab3d2 Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 10.9F.25141.AD3B0F65; Mon, 21 Mar 2016 19:54:18 -0700 (PDT) Received: from [17.153.88.227] (unknown [17.153.88.227]) by kencur.apple.com (Oracle Communications Messaging Server 7.0.5.37.0 64bit (built Nov 11 2015)) with ESMTPSA id <0O4F00EU56QIDY00@kencur.apple.com>; Mon, 21 Mar 2016 19:54:18 -0700 (PDT) Sender: cheshire@apple.com From: Stuart Cheshire Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Date: Mon, 21 Mar 2016 19:54:17 -0700 Message-id: <5B929188-955A-46C5-B842-95406D4147EE@apple.com> To: Paul Wouters , Joe Abley , Sara Dickinson , Ray Bellis MIME-version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUi2FCYpntr84cwg32T9CzuvrnMYvF+6SxG ByaPJUt+MgUwRnHZpKTmZJalFunbJXBlTPzTxVTwUKuic8JG5gbGVqUuRg4OCQETidaVPl2M nECmmMSFe+vZuhi5OIQE9jFKvLh7ig0iYSKx9cosqEQvk8Tata9ZIZzfjBJtRz4zg1QJC0hJ vFoJYbMJaEm8+HyFDWQDs4C6xJQpuSBhZgFtiSfvLrCChIUF3CWa30aAhFkEVCXuLjvEDmLz CthIvGvZwQjRqSux60oYyCYRgUZGiVWb+6Bq9CT+XbjJDnGbrMS+DQvAbpMQmMAmcXrCaqYJ jEKzEDbPQrJ5FpL2BYzMqxiFchMzc3Qz88z0EgsKclL1kvNzNzGCgna6negOxjOrrA4xCnAw KvHwRqx5HybEmlhWXJl7iFGag0VJnPfjxA9hQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhd 9vfblN1ZGLzx/P7jASy2v+dWy7xVeV3to7Z6g9LtaR6B+sq/zonfvHXX4eihxZ/fHZ7+W9a6 8dkCQQOr/fwBqmV8zUs+3Dv/8ojriXAn33XNry+XWUim7Y4LK5qUxcRj0a8+zc0n0MLg3UT7 WWuCYldYbLSVXFkj5KTQn6Z//Wdr++/7298qsRRnJBpqMRcVJwIA9VtyazsCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUiON1OTffW5g9hBl9+aVncfXOZxeL90lmM DkweS5b8ZApgjOKySUnNySxLLdK3S+DKmPini6ngoVZF54SNzA2MrUpdjJwcEgImEluvzGKD sMUkLtxbD2RzcQgJ9DJJrF37mhXC+c0o0XbkMzNIlbCAlMSrlRA2m4CWxIvPV4A6ODiYBdQl pkzJBQkzC2hLPHl3gRUkLCzgLtH8NgIkzCKgKnF32SF2EJtXwEbiXcsORohOXYldV8JANokI NDJKrNrcB1WjJ/Hvwk12iNtkJfZtWMA2gZF/FsKyWUiWzULSsYCReRWjQFFqTmKlhV5iQUFO ql5yfu4mRlCYNRSm7WBsWm51iFGAg1GJhzdizfswIdbEsuLK3EOMEhzMSiK8vL0fwoR4UxIr q1KL8uOLSnNSiw8xJgPdP5FZSjQ5HxgDeSXxhiYmBibGxmbGxuYm5qQJK4nztkm/DhMSSE8s Sc1OTS1ILYLZwsTBKdXAyBLdyuWxa6FLg8uGK1G2nglhL1Xr7x4LCzh0V/iRWIr1tO2pjnrL 0tk2+YWbdCyO/fr0fqijukSJ2ekv9+v45zRXuB1bZcbe/7HobvsVhea0qfdkV90q4agort63 R6v0XJGSe3qw2UOJC3Ma9Q+WC60tu951VMl1baahyz3fiW13/3fK32VRYinOSDTUYi4qTgQA h9Ag63cCAAA= Archived-At: Cc: dnssd@ietf.org, dnsop WG Subject: [dnssd] Draft-ietf-dnsop-edns-tcp-keepalive and DNS Push Notifications X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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, 22 Mar 2016 02:54:20 -0000 Dear Keepalive authors, Draft-ietf-dnssd-push-06 (see below) references = draft-ietf-dnsop-edns-tcp-keepalive. However, at present, a more accurate title might be = =E2=80=9Cdraft-ietf-dnsop-edns-tcp-idle-timeout=E2=80=9D instead of = =E2=80=9Cdraft-ietf-dnsop-edns-tcp-keepalive=E2=80=9D, because while it = tells the client how to learn what the idle timeout is, it doesn=E2=80=99t= say anything about what the client does to actually keep a connection = alive. Draft-ietf-dnssd-push-06 currently has the text included below. 1. It states what actions reset the idle timer. 2. It states that the client should send keepalive traffic before the = idle timeout expires, but the server should not kill a connection until = 1.5x the idle timeout, to allow for clock rate differences and = propagation delays. 3. Particularly note the final paragraph, which calls for suggestions = for a specified keepalive action. At both servers and clients, the generation or reception of any request, response, update, or keepalive message resets the keepalive timer for that connection. In the absence of any requests, responses, or update messages on a connection, a client MUST generate keepalive traffic before the idle timeout expires, or the server is entitled to close the connection. If a client disconnects from the network abruptly, without closing its connection, the server learns of this after failing to receive further traffic from that client. If no requests, responses, update messages or keepalive traffic occurs on a connection for 1.5 times the idle timeout, then this indicates that the client is probably no longer on the network, and the server SHOULD abort the connection with a TCP RST. [We need to discuss the nature of "the required keepalives". Are they TCP-layer keepalives? DNS-layer keepalives? There is currently no DNS-layer keepalive or 'no-op' operation defined. What would that operation be? A DNS QUERY containing zero questions? A DNS SUBSCRIBE containing zero questions? An "empty" DNS message over the TCP connection (just a pair of zero bytes, signifying a zero-length message)? One benefit of TCP-layer keepalives is that they transmit fewer bytes, and involve less software overhead for processing those bytes. Another benefit is that it is more feasible to implement these in networking offload hardware, which can allow devices to meet their TCP keepalive obligations while sleeping. This is particularly important for battery-powered devices like mobile phones and tablets. On the other hand, using TCP-layer keepalives requires an API for a client to tell the networking stack at what frequency to perform TCP- layer keepalives, and an API for a server to request the networking stack to inform it when TCP-layer keepalives are not received by the required deadline. TCP-layer keepalives also only verify liveness of the remote networking stack, whereas DNS-layer keepalives provide higher assurance of liveness of the remote server application software -- though this a limited benefit, since there is no reason to expect that DNS Push Notification server software will routinely become wedged and unresponsive.] I could define this specified keepalive action in the DNS Push document, = but I think it would be better to have that specification in the = keepalive document. Thoughts? Stuart Cheshire Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-06.txt > Date: 21 March 2016 at 16:58:41 Pacific Daylight Time > To: i-d-announce@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Extensions for Scalable DNS Service = Discovery of the IETF. >=20 > Title : DNS Push Notifications > Authors : Tom Pusateri > Stuart Cheshire > Filename : draft-ietf-dnssd-push-06.txt > Pages : 31 > Date : 2016-03-21 >=20 > Abstract: > The Domain Name System (DNS) was designed to return matching records > efficiently for queries for data that is relatively static. When > those records change frequently, DNS is still efficient at returning > the updated results when polled. But there exists no mechanism for a > client to be asynchronously notified when these changes occur. This > document defines a mechanism for a client to be notified of such > changes to DNS records, called DNS Push Notifications. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dnssd-push-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnssd-push-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Mon Mar 21 20:02:49 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAF112D552; Mon, 21 Mar 2016 20:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8N0I7RcdW1Vt; Mon, 21 Mar 2016 20:02:46 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09D312D159; Mon, 21 Mar 2016 20:02:45 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qTcv802w5z1cN; Tue, 22 Mar 2016 04:02:44 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id SOJJBlzeb7kr; Tue, 22 Mar 2016 04:02:42 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 22 Mar 2016 04:02:42 +0100 (CET) Received: from [193.111.228.86] (unknown [193.111.228.86]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 0DF05600B97C; Mon, 21 Mar 2016 23:02:41 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 0DF05600B97C References: <5B929188-955A-46C5-B842-95406D4147EE@apple.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5B929188-955A-46C5-B842-95406D4147EE@apple.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <818B6C5F-8D1C-4581-98F1-E081C2723911@nohats.ca> X-Mailer: iPhone Mail (13D15) From: Paul Wouters Date: Mon, 21 Mar 2016 23:02:29 -0400 To: Stuart Cheshire Archived-At: Cc: dnssd@ietf.org, Joe Abley , Paul Wouters , Ray Bellis , Sara Dickinson , dnsop WG Subject: Re: [dnssd] [DNSOP] Draft-ietf-dnsop-edns-tcp-keepalive and DNS Push Notifications X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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, 22 Mar 2016 03:02:47 -0000 Our document is in AUTH48 already, so making those kind of changed there mig= ht be very difficult. Also, if you are so idle that you might run into tcp issues timing out, you p= robably should be nice to the other end and close your tcp session. Sent from my iPhone > On Mar 21, 2016, at 22:54, Stuart Cheshire wrote: >=20 > Dear Keepalive authors, >=20 > Draft-ietf-dnssd-push-06 (see below) references draft-ietf-dnsop-edns-tcp-= keepalive. >=20 > However, at present, a more accurate title might be =E2=80=9Cdraft-ietf-dn= sop-edns-tcp-idle-timeout=E2=80=9D instead of =E2=80=9Cdraft-ietf-dnsop-edns= -tcp-keepalive=E2=80=9D, because while it tells the client how to learn what= the idle timeout is, it doesn=E2=80=99t say anything about what the client d= oes to actually keep a connection alive. >=20 > Draft-ietf-dnssd-push-06 currently has the text included below. >=20 > 1. It states what actions reset the idle timer. >=20 > 2. It states that the client should send keepalive traffic before the idle= timeout expires, but the server should not kill a connection until 1.5x the= idle timeout, to allow for clock rate differences and propagation delays. >=20 > 3. Particularly note the final paragraph, which calls for suggestions for a= specified keepalive action. >=20 > At both servers and clients, the generation or reception of any > request, response, update, or keepalive message resets the keepalive > timer for that connection. >=20 > In the absence of any requests, responses, or update messages on a > connection, a client MUST generate keepalive traffic before the idle > timeout expires, or the server is entitled to close the connection. >=20 > If a client disconnects from the network abruptly, without closing > its connection, the server learns of this after failing to receive > further traffic from that client. If no requests, responses, update > messages or keepalive traffic occurs on a connection for 1.5 times > the idle timeout, then this indicates that the client is probably no > longer on the network, and the server SHOULD abort the connection > with a TCP RST. >=20 > [We need to discuss the nature of "the required keepalives". Are > they TCP-layer keepalives? DNS-layer keepalives? There is currently > no DNS-layer keepalive or 'no-op' operation defined. What would that > operation be? A DNS QUERY containing zero questions? A DNS > SUBSCRIBE containing zero questions? An "empty" DNS message over the > TCP connection (just a pair of zero bytes, signifying a zero-length > message)? One benefit of TCP-layer keepalives is that they transmit > fewer bytes, and involve less software overhead for processing those > bytes. Another benefit is that it is more feasible to implement > these in networking offload hardware, which can allow devices to meet > their TCP keepalive obligations while sleeping. This is particularly > important for battery-powered devices like mobile phones and tablets. > On the other hand, using TCP-layer keepalives requires an API for a > client to tell the networking stack at what frequency to perform TCP- > layer keepalives, and an API for a server to request the networking > stack to inform it when TCP-layer keepalives are not received by the > required deadline. TCP-layer keepalives also only verify liveness of > the remote networking stack, whereas DNS-layer keepalives provide > higher assurance of liveness of the remote server application > software -- though this a limited benefit, since there is no reason > to expect that DNS Push Notification server software will routinely > become wedged and unresponsive.] >=20 > I could define this specified keepalive action in the DNS Push document, b= ut I think it would be better to have that specification in the keepalive do= cument. >=20 > Thoughts? >=20 > Stuart Cheshire >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-06.txt >> Date: 21 March 2016 at 16:58:41 Pacific Daylight Time >> To: i-d-announce@ietf.org >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >> This draft is a work item of the Extensions for Scalable DNS Service Disc= overy of the IETF. >>=20 >> Title : DNS Push Notifications >> Authors : Tom Pusateri >> Stuart Cheshire >> Filename : draft-ietf-dnssd-push-06.txt >> Pages : 31 >> Date : 2016-03-21 >>=20 >> Abstract: >> The Domain Name System (DNS) was designed to return matching records >> efficiently for queries for data that is relatively static. When >> those records change frequently, DNS is still efficient at returning >> the updated results when polled. But there exists no mechanism for a >> client to be asynchronously notified when these changes occur. This >> document defines a mechanism for a client to be notified of such >> changes to DNS records, called DNS Push Notifications. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-dnssd-push-06 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnssd-push-06 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submiss= ion >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Mon Mar 21 21:16:21 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BFB12D196 for ; Mon, 21 Mar 2016 21:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.303 X-Spam-Level: X-Spam-Status: No, score=-104.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwUIJD5DodV4 for ; Mon, 21 Mar 2016 21:16:18 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1189512D122 for ; Mon, 21 Mar 2016 21:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1458620177; x=2322533777; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+XECw9iig/yjlFF+urxjaFq318Z+3AVvgROAa/yGCrc=; b=TVKr1wAWzfCmBBG8+SXBUl75HnROLNBOUHIbluZjfeqo+raUQBsTF9fqlfwxFky4 EppGSe8CBtoo7Brx5RvLVPA7WBTK8wx+xVvgV4fWns45T5ohJYRjNbsatPzVO1tN 088zZwwg+VvH6OL+wv1ZDUOKN4Bhq+EGHkc/i5ANDKfz+//4jQEaQ7msgzjrQKpk Yw9UEoNwqFt8/qQqjmvGg8o7GL6zvvDIjO3cVVOAhtmQ/KiB8ScnIfXXsXwbRKAZ OHOjOWaDCUzybAtCYHYT4XWGOtyC/7t3Yyw4ojH2/XPrsFcelnmLfVar3NjA9RfQ wOjjB/7mvJRzOppLpUVa9g==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 5C.C2.06427.117C0F65; Mon, 21 Mar 2016 21:16:17 -0700 (PDT) X-AuditID: 11973e11-f79646d00000191b-16-56f0c7118f51 Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 98.34.07991.117C0F65; Mon, 21 Mar 2016 21:16:17 -0700 (PDT) Received: from [17.153.88.227] (unknown [17.153.88.227]) by koseret.apple.com (Oracle Communications Messaging Server 7.0.5.37.0 64bit (built Nov 11 2015)) with ESMTPSA id <0O4F005JHAJ4RT70@koseret.apple.com>; Mon, 21 Mar 2016 21:16:17 -0700 (PDT) Sender: cheshire@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Stuart Cheshire In-reply-to: <818B6C5F-8D1C-4581-98F1-E081C2723911@nohats.ca> Date: Mon, 21 Mar 2016 21:16:17 -0700 Content-transfer-encoding: quoted-printable Message-id: References: <5B929188-955A-46C5-B842-95406D4147EE@apple.com> <818B6C5F-8D1C-4581-98F1-E081C2723911@nohats.ca> To: Paul Wouters X-Mailer: Apple Mail (2.3112) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUi2FAYrit4/EOYQd8bA4u7by6zWLxfOovR gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZ8/9/Ziv4yFmx4+Zs5gbGV+xdjJwcEgImEnsmLmOB sMUkLtxbz9bFyMUhJLCXUaJnYT8jTNGCNR2sILaQQD+TxMX1IhBFfxkldjafBUsIC0hJvFr5 mbmLkYODWUBdYsqUXJAwr4CexL8LN9khSmIllq6/C2azCWhJvPh8hQ3E5hSwlfiz4yETiM0i oCpx9+56ZpD5zALrGCU27vkPVsQsoC3x5N0FVoihNhK3d55iAtklJJAvMXtpFEhYREBRYtKZ R1DPyErs27AA7BkJgR42iUeP57BPYBSZhXDeLCTnzUKyYQEj8ypGodzEzBzdzDwjvcSCgpxU veT83E2MoDCfbie4g/H4KqtDjAIcjEo8vBP2fQgTYk0sK67MPcQozcGiJM77cSJQSCA9sSQ1 OzW1ILUovqg0J7X4ECMTB6dUA+OuuGpRTue2cywG6yodDnso+6e9nJ98rcN0cU312zA1zhff 1G9P3lfGZK19e/fnR5o+vh7J9+btt+kKZVi9MP7p8hWRDmJ502ZnlC3wSLoWkffy2YPkB1P1 QrQOJ2SpHt7KdUAyUvA47xUFjyg99dpD3hPX+EXeePzv39OHm5r/1J70vSe7+YUSS3FGoqEW c1FxIgA8VBOnVAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUiON1OXVfw+Icwg+9vdS3uvrnMYvF+6SxG ByaPJUt+MgUwRnHZpKTmZJalFunbJXBlzP//ma3gI2fFjpuzmRsYX7F3MXJySAiYSCxY08EK YYtJXLi3ng3EFhLoZ5K4uF6ki5ELyP7LKLGz+SxYkbCAlMSrlZ+Zuxg5OJgF1CWmTMkFCfMK 6En8u3CTHaIkVmLp+rtgNpuAlsSLz1fAZnIK2Er82fGQCcRmEVCVuHt3PTPIfGaBdYwSG/f8 BytiFtCWePLuAivEUBuJ2ztPMYHsEhLIl5i9NAokLCKgKDHpzCMWiJtlJfZtWMA2gVFwFsJF s5BcNAvJ0AWMzKsYBYpScxIrTfQSCwpyUvWS83M3MYLCsqEwfAfjv2VWhxgFOBiVeHgn7PsQ JsSaWFZcmXuIUYKDWUmE9+MRoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeNunXYUIC6Yklqdmp qQWpRTBZJg5OqQbG57w5WS4R35TTZYw5jFzyr6yerv/TuOwdA+M7t6S+jxe8a2LnLzBXvXRy hxaTe+5Mr0de1Z9+T9oT8PDoo5MZ9a/r37BcXs8gNWeW4qwXXPc/34trXMK/JOLaAqegu1s9 kt7/uXMv0qXn7qvCV9dunT9qc/ubqFzS/tlKmWETnq1tmx6Sy+3GrMRSnJFoqMVcVJwIALSD 25dHAgAA Archived-At: Cc: dnsop WG , Joe Abley , Paul Wouters , Ray Bellis , Sara Dickinson , dnssd@ietf.org Subject: Re: [dnssd] [DNSOP] Draft-ietf-dnsop-edns-tcp-keepalive and DNS Push Notifications X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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, 22 Mar 2016 04:16:19 -0000 On 21 Mar 2016, at 20:02, Paul Wouters wrote: > Our document is in AUTH48 already, so making those kind of changed = there might be very difficult. I didn=E2=80=99t realise that. I agree, it=E2=80=99s too late to make = substantive changes at this point. > Also, if you are so idle that you might run into tcp issues timing = out, you probably should be nice to the other end and close your tcp = session. The idea of DNS Push Notifications is for moderately long-standing = queries (on the order of 5-10 minutes) waiting to be notified of some = change. For example, you go to print, but the printer is turned off. You walk = down the hall and turn the printer on, and when you get back to your = office your computer has been notified that a new printer has become = available (without you having to repeatedly cancel and try again until = the printer shows up). It=E2=80=99s not something that would be useful for all DNS servers. = Think of it as a different protocol, that happens to leverage existing = DNS protocols and message formats instead of inventing new protocols and = message formats. The draft explains it in more detail. DNSOP feedback on the draft would be appreciated. Stuart Cheshire From nobody Mon Mar 21 21:42:43 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C5D12D685; Mon, 21 Mar 2016 21:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUuls9oSC0qp; Mon, 21 Mar 2016 21:42:38 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D515A12D680; Mon, 21 Mar 2016 21:42:37 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qTg6M24LSz37l; Tue, 22 Mar 2016 05:42:35 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id pP_yxfkEjxWI; Tue, 22 Mar 2016 05:42:33 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 22 Mar 2016 05:42:33 +0100 (CET) Received: from [193.111.228.86] (unknown [193.111.228.86]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 045F6600B97C; Tue, 22 Mar 2016 00:42:32 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 045F6600B97C References: <5B929188-955A-46C5-B842-95406D4147EE@apple.com> <818B6C5F-8D1C-4581-98F1-E081C2723911@nohats.ca> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (13D15) From: Paul Wouters Date: Tue, 22 Mar 2016 00:42:21 -0400 To: Stuart Cheshire Archived-At: Cc: dnssd@ietf.org, Joe Abley , Paul Wouters , Ray Bellis , Sara Dickinson , dnsop WG Subject: Re: [dnssd] [DNSOP] Draft-ietf-dnsop-edns-tcp-keepalive and DNS Push Notifications X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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, 22 Mar 2016 04:42:39 -0000 Sent from my iPhone > On Mar 22, 2016, at 00:16, Stuart Cheshire wrote: >=20 >> On 21 Mar 2016, at 20:02, Paul Wouters wrote: >>=20 >> Our document is in AUTH48 already, so making those kind of changed there m= ight be very difficult. >=20 > I didn=E2=80=99t realise that. I agree, it=E2=80=99s too late to make subs= tantive changes at this point. >=20 >> Also, if you are so idle that you might run into tcp issues timing out, y= ou probably should be nice to the other end and close your tcp session. >=20 > The idea of DNS Push Notifications is for moderately long-standing queries= (on the order of 5-10 minutes) waiting to be notified of some change. >=20 > For example, you go to print, but the printer is turned off. You walk down= the hall and turn the printer on, and when you get back to your office your= computer has been notified that a new printer has become available (without= you having to repeatedly cancel and try again until the printer shows up). >=20 Sound more like a match for xmpp than DNS? Paul > It=E2=80=99s not something that would be useful for all DNS servers. Think= of it as a different protocol, that happens to leverage existing DNS protoc= ols and message formats instead of inventing new protocols and message forma= ts. >=20 > The draft explains it in more detail. >=20 > DNSOP feedback on the draft would be appreciated. >=20 > Stuart Cheshire >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Tue Mar 22 21:27:57 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245D312D6F3 for ; Tue, 22 Mar 2016 21:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PluO5vdkhPyU for ; Tue, 22 Mar 2016 21:27:54 -0700 (PDT) Received: from xsmtp11.mail2web.com (xsmtp31.mail2web.com [168.144.250.234]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7575212D66A for ; Tue, 22 Mar 2016 21:27:54 -0700 (PDT) Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1aiaMc-0000Lx-4z for dnssd@ietf.org; Wed, 23 Mar 2016 00:27:53 -0400 Received: (qmail 21925 invoked from network); 23 Mar 2016 04:25:45 -0000 Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 23 Mar 2016 04:25:44 -0000 From: "Christian Huitema" To: "'Tim Chown'" , References: <20160310013909.9336.65458.idtracker@ietfa.amsl.com> <7E27ED38-3858-4080-A31E-2116EA2DD436@ecs.soton.ac.uk> In-Reply-To: Date: Tue, 22 Mar 2016 21:25:43 -0700 Message-ID: <055301d184bc$11a0e450$34e2acf0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIT3HtUSd1CzI+WTk3PSxCkI12h1wJZ1p8tAxB9ygCetmoE8A== Content-Language: en-us Archived-At: Subject: Re: [dnssd] I-D Action: draft-huitema-dnssd-privacy-00.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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, 23 Mar 2016 04:27:56 -0000 On Thursday, March 17, 2016 4:12 PM, Tim Chown wrote: > > Hi, > > Ralph and I would welcome comments to the list on this draft. > > Tim Yep. Me too. This draft (https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/) is the continuation of the work to minimize metadata disclosure went moving to random locations, and in particular when connecting to Wi-Fi hot spots. The first big disclosure comes with the MAC address, and can be addressed with MAC address randomization. The next big disclosure are the DHCP messages, which use to disclose things like DNS name of the node, and the DNS traffic, which would happily pass a full log of visited URL to the DNS server chosen by the hot spot manager. The IETF has been working on that with the DHCP anonymity profile, and with the DNS Privacy work in DPRIVE. Which means we have to look at the next big disclosure source, which happens to be DNS-SD. The draft proposes essentially to obfuscate the names used in DNS-SD so that cooperating parties understand them, but they look like gibberish to casual observers. I am sure that DNS-SD WG members have opinions about that. -- Christian Huitema From nobody Wed Mar 23 16:54:11 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B492512D62E for ; Wed, 23 Mar 2016 16:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4XithE2-_4D for ; Wed, 23 Mar 2016 16:54:08 -0700 (PDT) Received: from octans.istumbler.net (octans.istumbler.net [45.79.75.197]) by ietfa.amsl.com (Postfix) with ESMTP id 177D912D5BE for ; Wed, 23 Mar 2016 16:54:08 -0700 (PDT) Received: from [192.168.29.219] (c-24-5-43-153.hsd1.ca.comcast.net [24.5.43.153]) by octans.istumbler.net (Postfix) with ESMTPSA id 68E3627CF8; Wed, 23 Mar 2016 23:54:05 +0000 (UTC) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.7 at octans.istumbler.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alf Watt X-Mailer: iPhone Mail (13E234) In-Reply-To: <055301d184bc$11a0e450$34e2acf0$@huitema.net> Date: Wed, 23 Mar 2016 16:54:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <620719BD-01B1-426C-8FAC-09C615DFBF7C@istumbler.net> References: <20160310013909.9336.65458.idtracker@ietfa.amsl.com> <7E27ED38-3858-4080-A31E-2116EA2DD436@ecs.soton.ac.uk> <055301d184bc$11a0e450$34e2acf0$@huitema.net> To: Christian Huitema Archived-At: Cc: dnssd@ietf.org Subject: Re: [dnssd] I-D Action: draft-huitema-dnssd-privacy-00.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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, 23 Mar 2016 23:54:10 -0000 Just looking over the paper titles for DPRIV it seems like the solution is g= oing to be TLS or DTLS of the DNS server to client connection, which should e= ncapsulate the unicast DNS-SD as well as the usual A and AAAA lookups. Is the concern about information disclosure from devices using DNS-SD and mD= NS for multicast advertising and discovery? Best, Alf > On Mar 22, 2016, at 9:25 PM, Christian Huitema wrote= : >=20 >> On Thursday, March 17, 2016 4:12 PM, Tim Chown wrote: >>=20 >> Hi, >>=20 >> Ralph and I would welcome comments to the list on this draft. >>=20 >> Tim >=20 > Yep. Me too. This draft > (https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/) is the > continuation of the work to minimize metadata disclosure went moving to > random locations, and in particular when connecting to Wi-Fi hot spots. >=20 > The first big disclosure comes with the MAC address, and can be addressed > with MAC address randomization. The next big disclosure are the DHCP > messages, which use to disclose things like DNS name of the node, and the > DNS traffic, which would happily pass a full log of visited URL to the DNS= > server chosen by the hot spot manager. The IETF has been working on that > with the DHCP anonymity profile, and with the DNS Privacy work in DPRIVE. > Which means we have to look at the next big disclosure source, which happe= ns > to be DNS-SD. >=20 > The draft proposes essentially to obfuscate the names used in DNS-SD so th= at > cooperating parties understand them, but they look like gibberish to casua= l > observers. I am sure that DNS-SD WG members have opinions about that. >=20 > -- Christian Huitema >=20 >=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Wed Mar 23 17:27:06 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5743F12D115 for ; Wed, 23 Mar 2016 17:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwwOCpSGx-lA for ; Wed, 23 Mar 2016 17:27:03 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B43D128874 for ; Wed, 23 Mar 2016 17:27:03 -0700 (PDT) Received: from [172.16.10.140] (cpe-174-109-142-205.nc.res.rr.com [174.109.142.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 5431F1DAB1; Wed, 23 Mar 2016 20:26:09 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C083F45E-F06E-467E-877D-0A97E78F56A1"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Tom Pusateri In-Reply-To: <620719BD-01B1-426C-8FAC-09C615DFBF7C@istumbler.net> Date: Wed, 23 Mar 2016 20:27:00 -0400 Message-Id: References: <20160310013909.9336.65458.idtracker@ietfa.amsl.com> <7E27ED38-3858-4080-A31E-2116EA2DD436@ecs.soton.ac.uk> <055301d184bc$11a0e450$34e2acf0$@huitema.net> <620719BD-01B1-426C-8FAC-09C615DFBF7C@istumbler.net> To: Alf Watt X-Mailer: Apple Mail (2.3124) Archived-At: Cc: dnssd@ietf.org, Christian Huitema Subject: Re: [dnssd] I-D Action: draft-huitema-dnssd-privacy-00.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 24 Mar 2016 00:27:05 -0000 --Apple-Mail=_C083F45E-F06E-467E-877D-0A97E78F56A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I was thinking the same thing. There won=E2=80=99t always be a hybrid = proxy present but if there is one, it would be the perfect intermediary = for unicast TLS connections to each client and service provider. Tom > On Mar 23, 2016, at 7:54 PM, Alf Watt wrote: >=20 > Just looking over the paper titles for DPRIV it seems like the = solution is going to be TLS or DTLS of the DNS server to client = connection, which should encapsulate the unicast DNS-SD as well as the = usual A and AAAA lookups. >=20 > Is the concern about information disclosure from devices using DNS-SD = and mDNS for multicast advertising and discovery? >=20 > Best, > Alf >=20 >> On Mar 22, 2016, at 9:25 PM, Christian Huitema = wrote: >>=20 >>> On Thursday, March 17, 2016 4:12 PM, Tim Chown wrote: >>>=20 >>> Hi, >>>=20 >>> Ralph and I would welcome comments to the list on this draft. >>>=20 >>> Tim >>=20 >> Yep. Me too. This draft >> (https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/) is = the >> continuation of the work to minimize metadata disclosure went moving = to >> random locations, and in particular when connecting to Wi-Fi hot = spots. >>=20 >> The first big disclosure comes with the MAC address, and can be = addressed >> with MAC address randomization. The next big disclosure are the DHCP >> messages, which use to disclose things like DNS name of the node, and = the >> DNS traffic, which would happily pass a full log of visited URL to = the DNS >> server chosen by the hot spot manager. The IETF has been working on = that >> with the DHCP anonymity profile, and with the DNS Privacy work in = DPRIVE. >> Which means we have to look at the next big disclosure source, which = happens >> to be DNS-SD. >>=20 >> The draft proposes essentially to obfuscate the names used in DNS-SD = so that >> cooperating parties understand them, but they look like gibberish to = casual >> observers. I am sure that DNS-SD WG members have opinions about that. >>=20 >> -- Christian Huitema >>=20 >>=20 >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_C083F45E-F06E-467E-877D-0A97E78F56A1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJW8zRUAAoJEPk0GMVmUuYMmy4H+wUt9oR2CZDvRnIZjus4yB0I ZbHfQbYnFzTwBzTfSBi66lfu/Zcza5Ov81y2dScRhmuZITY6xJ55Fta7cbYzHBPB mq2bPIczfUcUKf7q5XuoOViABpekxON5fkUBUTrQ45WhByHqa0r+QGBVmABmWfmz 2xsbwFEwqlzPKvNdW6WRBx763zN5nlMdsHfGQ+wRTrScRt8tyS0zkwNPKFvc8TKY 50Fo8vusRfSG3qW466xOinZ605X7Pm+E3aUHflqw7GKteoWv/wsrNRFb/E53FiU7 2qg9ENP3+smdES4TiMH6AOle72CLKCTuTVb87KmB8nG/Nn1DHNjFZMToIPlVpRQ= =wm+3 -----END PGP SIGNATURE----- --Apple-Mail=_C083F45E-F06E-467E-877D-0A97E78F56A1-- From nobody Wed Mar 23 17:36:57 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281D112D0FD for ; Wed, 23 Mar 2016 17:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1qf8iBu120T for ; Wed, 23 Mar 2016 17:36:54 -0700 (PDT) Received: from octans.istumbler.net (octans.istumbler.net [IPv6:2600:3c01::f03c:91ff:fe26:b456]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD27128874 for ; Wed, 23 Mar 2016 17:36:54 -0700 (PDT) Received: from [192.168.29.219] (c-24-5-43-153.hsd1.ca.comcast.net [24.5.43.153]) by octans.istumbler.net (Postfix) with ESMTPSA id 0B70127CFD; Thu, 24 Mar 2016 00:36:51 +0000 (UTC) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.7 at octans.istumbler.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alf Watt X-Mailer: iPhone Mail (13E234) In-Reply-To: <620719BD-01B1-426C-8FAC-09C615DFBF7C@istumbler.net> Date: Wed, 23 Mar 2016 17:36:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160310013909.9336.65458.idtracker@ietfa.amsl.com> <7E27ED38-3858-4080-A31E-2116EA2DD436@ecs.soton.ac.uk> <055301d184bc$11a0e450$34e2acf0$@huitema.net> <620719BD-01B1-426C-8FAC-09C615DFBF7C@istumbler.net> To: huitema@huitema.ne Archived-At: Cc: dnssd@ietf.org Subject: Re: [dnssd] I-D Action: draft-huitema-dnssd-privacy-00.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 24 Mar 2016 00:36:56 -0000 Notes after I RTFD: For most users a single security posture or group membership won't be adequa= te. Some services may be private (synch with a phone, for e.g.), some shared= with work mates (file and screen sharing), some with family (game and conte= nt sharing), while others are public, the service advertising stack will hav= e to keep track of the difference and advertise and browse as appropriate. - Yes, the concern is privacy in multicast environments, so I suggest the ti= tle change to reflect that. Strictly speaking any kind of DNS message send o= ver mDNS is leaking information, but we only expect to see the SD, name and a= ddress resolution messages associated with DNS-SD - 4.1: if the party is concerned they MAY use a random host name, if privacy= is required they MUST - the goal is to advertise services in such a way that hosts not implementin= g the updated protocol will not see them, this suggests using a new protocol= and port to differentiate traffic, allow for a secure protocol design and a= void obfuscation and name mangling - as you are proposing a shared key solution, there should be some proposal f= or key sharing and exchange - this moves the solution towards Bluetooth style link-key exchange pairing m= odel of security for local services. It's probably worth reviewing those pro= tocols to see if one can be reused for this purpose. - as suggested, only a single key and therefore a single 'kin' group[1] per d= evice would be supported - consider using a one-time key to protect the payload of an mDNS packet, an= d wrapping that key in one or more 'kin' group keys to allow a single servic= e to be advertised to multiple groups: [mDNS message encrypted with K] [K encrypted with G1] [K encrypted with G2] [etc.] - note that this allows for privately advertising the true host name and mak= es browsing requests private as well (only a kin will be able to unwrap the o= n-time-key and see the service type requested).=20 Best, Alf [1] apologies to any former Danger Inc. employees > On Mar 23, 2016, at 4:54 PM, Alf Watt wrote: >=20 > Just looking over the paper titles for DPRIV it seems like the solution is= going to be TLS or DTLS of the DNS server to client connection, which shoul= d encapsulate the unicast DNS-SD as well as the usual A and AAAA lookups. >=20 > Is the concern about information disclosure from devices using DNS-SD and m= DNS for multicast advertising and discovery? >=20 > Best, > Alf >=20 >>> On Mar 22, 2016, at 9:25 PM, Christian Huitema wro= te: >>>=20 >>> On Thursday, March 17, 2016 4:12 PM, Tim Chown wrote: >>>=20 >>> Hi, >>>=20 >>> Ralph and I would welcome comments to the list on this draft. >>>=20 >>> Tim >>=20 >> Yep. Me too. This draft >> (https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/) is the >> continuation of the work to minimize metadata disclosure went moving to >> random locations, and in particular when connecting to Wi-Fi hot spots. >>=20 >> The first big disclosure comes with the MAC address, and can be addressed= >> with MAC address randomization. The next big disclosure are the DHCP >> messages, which use to disclose things like DNS name of the node, and the= >> DNS traffic, which would happily pass a full log of visited URL to the DN= S >> server chosen by the hot spot manager. The IETF has been working on that >> with the DHCP anonymity profile, and with the DNS Privacy work in DPRIVE.= >> Which means we have to look at the next big disclosure source, which happ= ens >> to be DNS-SD. >>=20 >> The draft proposes essentially to obfuscate the names used in DNS-SD so t= hat >> cooperating parties understand them, but they look like gibberish to casu= al >> observers. I am sure that DNS-SD WG members have opinions about that. >>=20 >> -- Christian Huitema >>=20 >>=20 >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Wed Mar 23 22:46:29 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8341512D775 for ; Wed, 23 Mar 2016 22:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cB0le6pCJrAA for ; Wed, 23 Mar 2016 22:46:25 -0700 (PDT) Received: from xsmtp02.mail2web.com (xsmtp02.mail2web.com [168.144.250.215]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 856DC12D52F for ; Wed, 23 Mar 2016 22:46:25 -0700 (PDT) Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1aiy67-0005LK-Kj for dnssd@ietf.org; Thu, 24 Mar 2016 01:46:24 -0400 Received: (qmail 31754 invoked from network); 24 Mar 2016 05:46:18 -0000 Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 24 Mar 2016 05:46:17 -0000 From: "Christian Huitema" To: "'Alf Watt'" References: <20160310013909.9336.65458.idtracker@ietfa.amsl.com> <7E27ED38-3858-4080-A31E-2116EA2DD436@ecs.soton.ac.uk> <055301d184bc$11a0e450$34e2acf0$@huitema.net> <620719BD-01B1-426C-8FAC-09C615DFBF7C@istumbler.net> In-Reply-To: Date: Wed, 23 Mar 2016 22:46:16 -0700 Message-ID: <020c01d18590$7c59a690$750cf3b0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIT3HtUSd1CzI+WTk3PSxCkI12h1wJZ1p8tAxB9ygAB+k+JcwIVaXVYAo4RXfqegx+gUA== Content-Language: en-us Archived-At: Cc: dnssd@ietf.org Subject: Re: [dnssd] I-D Action: draft-huitema-dnssd-privacy-00.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 24 Mar 2016 05:46:27 -0000 On Wednesday, March 23, 2016 5:37 PM, Alf Watt wrote: > ... > For most users a single security posture or group membership won't be > adequate. Some services may be private (synch with a phone, for e.g.), some > shared with work mates (file and screen sharing), some with family (game and > content sharing), while others are public, the service advertising stack will > have to keep track of the difference and advertise and browse as appropriate. Fair point. I am mostly concerned with the use case of several devices roaming together, typically phone and laptop or tablet, and then of work mates travelling together. We certainly need to work on the usage scenario and the UI implications. > - Yes, the concern is privacy in multicast environments, so I suggest the title > change to reflect that. Strictly speaking any kind of DNS message send over > mDNS is leaking information, but we only expect to see the SD, name and > address resolution messages associated with DNS-SD Multicast is certainly the first concern. I do not believe that people are actually using server-based resolution in Wi-Fi hot spots. > - 4.1: if the party is concerned they MAY use a random host name, if privacy is > required they MUST Yes. The MAY is my awkward attempt at providing 2 ways of doing that. > - the goal is to advertise services in such a way that hosts not implementing > the updated protocol will not see them, this suggests using a new protocol > and port to differentiate traffic, allow for a secure protocol design and avoid > obfuscation and name mangling That's certainly an option. But at the same time, there is value in reusing as much infrastructure as possible. > - as you are proposing a shared key solution, there should be some proposal > for key sharing and exchange Agreed. I wanted to have first a discussion of the concept. > - this moves the solution towards Bluetooth style link-key exchange pairing > model of security for local services. It's probably worth reviewing those > protocols to see if one can be reused for this purpose. Bluetooth style pairing is certainly one way. I should really have added a link to the BT LE spec, and its address obfuscation mechanism. But then, pairing is certainly not the only way to do that. We could also use "cloud based" mechanism, of the kind used to synchronize multiple device with the same owner. > - as suggested, only a single key and therefore a single 'kin' group[1] per > device would be supported That would be adequate for the "laptop and phone" scenario. Not so much for the "work mates" scenario. > - consider using a one-time key to protect the payload of an mDNS packet, > and wrapping that key in one or more 'kin' group keys to allow a single > service to be advertised to multiple groups: > > [mDNS message encrypted with K] > [K encrypted with G1] > [K encrypted with G2] > [etc.] Yes, that's the other possible design -- running encrypted MDNS on a separate port. It is a different tradeoff. Obfuscation allows reuse of the "low level" mechanisms, and places the burden entirely at the user interface. Encryption makes the interface implementation easier, but requires different ports, sending systems, etc. I believe the user-interface solution is easier to implement and less error prone. > - note that this allows for privately advertising the true host name and makes > browsing requests private as well (only a kin will be able to unwrap the on- > time-key and see the service type requested). That would work, as long as the names do not leak from the "encrypted MDNS" to the "clear text MDNS." If MDNS is configured with an obfuscated host name, it will not leak when if an active attacker does an active search for the clear-text name. -- Christian Huitema From nobody Fri Mar 25 07:54:08 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E38712DAFB for ; Fri, 25 Mar 2016 07:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrB0AIw5pArN for ; Fri, 25 Mar 2016 07:54:04 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 29E8A12DAFA for ; Fri, 25 Mar 2016 07:54:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E9B4840340; Fri, 25 Mar 2016 15:54:01 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cNcHYescX2s; Fri, 25 Mar 2016 15:53:59 +0100 (CET) Received: from Rays-MacBook-Pro.local (178-84-244-32.dynamic.upc.nl [178.84.244.32]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPA id CABD1402CE; Fri, 25 Mar 2016 15:53:58 +0100 (CET) Message-ID: <56F55105.4050809@globis.net> Date: Fri, 25 Mar 2016 15:53:57 +0100 From: "Ray Hunter (v6ops)" User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: draft-ietf-dnssd-hybrid@tools.ietf.org Content-Type: multipart/alternative; boundary="------------030705000807030408090702" Archived-At: Cc: dnssd@ietf.org Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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, 25 Mar 2016 14:54:06 -0000 This is a multi-part message in MIME format. --------------030705000807030408090702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have read this draft. I find the work interesting, although I'm not yet convinced of the chosen compromises with respect to use of this draft in Homenet. Specifically: 1. I'm concerned that there's a hard coded tie between a "zone" and a "link" which might lead to a lot of noise. Zone enumeration appears to be performed by retransmission of queries to the relevant proxy on the remote link. If a specialised end node that is a member of particular zone e.g. "A3 printers" moves to another building, there's no mechanism to say that the associated enumeration zone should also move with the device. In other words, the default is that all queries for all zones are probably going to have to be forwarded to ALL links in the (common) namespace. That could lead to a lot of unnecessary noise on an enterprise scale network, and which could also be killing for Homenet devices that are trying to be energy efficient. If I look back at the source of inspiration of zeroconf networking, Appletalk II, there was a ZIP (Zone Information Protocol) to enable a logical clustering of services, that was independent of network numbers and links. 2. I'm concerned at the potential for protocol storms. AFAICS There's no dedicated field in the protocol that tracks the ultimate source and destination of forwarded queries and replies. If a device is placed somewhere in the network that does not adequately understand how the hybrid mechanism works, and either queries or replies are inappropriately "leaked" between hybrid proxies, this could cause incorrect re-transmission of queries and responses and ultimately a packet storm. I also don't see how if two hybrid proxies are present and active on a link, they are going to be able to distinguish between original multicast requests from an end node on this link, and forwarded requests (potentially also using mulitcast) received from off-link via the other hybrid proxy. That suggess to me the hybrid proxies have to be "topology aware" which is a tall order. Unless of course I've misunderstood the forwarding mechanism. As a comparison, when DHCPv6 messages are relayed (by a DHCPv6 relay) a new explicit relay forwarding option is pushed onto the front of the message, and popped off the reply. That ensures that the forward (via RELAY-FORW) and reverse path (via RELAY-REPL) are respected at all times. 3. There doesn't seem to be any mechanism to be able to track replies with respect to queries. Multicast queries appear to result in unicast responses, and vice versa. It isn't clear from the draft if this may cause a security issue. How can the recipient of a unicast reply validate that it is a valid reply to a query sent via this proxy? So for example, could a rogue node on bldgd2 could answer on behalf of a node on bldg1? regards, -- regards, RayH --------------030705000807030408090702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have read this draft.

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

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

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

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

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

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

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

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

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

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

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

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

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

regards,

--
--------------030705000807030408090702-- From nobody Sat Mar 26 12:25:03 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E014512D59D for ; Sat, 26 Mar 2016 12:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEiTPomaYkRH for ; Sat, 26 Mar 2016 12:25:00 -0700 (PDT) Received: from octans.istumbler.net (octans.istumbler.net [IPv6:2600:3c01::f03c:91ff:fe26:b456]) by ietfa.amsl.com (Postfix) with ESMTP id C6F1F12D532 for ; Sat, 26 Mar 2016 12:25:00 -0700 (PDT) Received: from [IPv6:2601:645:4201:4a00:c1c3:8bec:db42:4a47] (unknown [IPv6:2601:645:4201:4a00:c1c3:8bec:db42:4a47]) by octans.istumbler.net (Postfix) with ESMTPSA id 6BFA827DC5; Sat, 26 Mar 2016 19:24:58 +0000 (UTC) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.7 at octans.istumbler.net Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alf Watt In-Reply-To: <020c01d18590$7c59a690$750cf3b0$@huitema.net> Date: Sat, 26 Mar 2016 12:24:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160310013909.9336.65458.idtracker@ietfa.amsl.com> <7E27ED38-3858-4080-A31E-2116EA2DD436@ecs.soton.ac.uk> <055301d184bc$11a0e450$34e2acf0$@huitema.net> <620719BD-01B1-426C-8FAC-09C615DFBF7C@istumbler.net> <020c01d18590$7c59a690$750cf3b0$@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3124) Archived-At: Cc: dnssd@ietf.org Subject: Re: [dnssd] I-D Action: draft-huitema-dnssd-privacy-00.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 26 Mar 2016 19:25:03 -0000 Christian, Some specifics below, but generally this is something I=92ve given a lot = of though to and consider an important problem to solve. It=92s particularly thorny = because when applied to any use case we can conceive of today, it means having several devices = on a public=20 Wi-Fi network. Unfortunately, the multicast environment in most public Wi-Fi networks = is either intentionally or unintentionally hostile. When APs and controllers for larger Wi-Fi = deployments are wiling to relay multicast frames (or any frames; along with =93Disable = Multicast=94 you will also see =93Client Isolation=94 enabled) between Wi-Fi clients, they often do so = with least effort and=20 always, by necessity, at the lowest data rate, so that everyone can = reliably hear it. In busy public hotspots many devices sending broadcast frames (including DHCP = and IPv6 router requests as well as multicast service discovery) will quickly fill up = available airtime and degrade multicast traffic. On larger managed Wi-Fi networks we=92re starting to see selective = routing of multicast messages from one broadcast domain to another via "Bonjour Gateways=94 = and more recently from multicast to unicast using =93hybrid proxy=94 services, and the = question of how we route multicast traffic across a large Wi-Fi network is an open discussion (a = trivial example would be to restrict multicast service discovery traffic to a single AP, then = neighboring APs). We can expect to see the broadcast and multicast domains become more and = more distinct in deployments until they are both supplanted by some putative =93Undirected = Multihop over Mesh=94 service discovery protocol. Despite these present challenges and future uncertainties around = multicast traffic, solving the service discovery advertising and browsing privacy problem, in a way = that reflects the way people and groups communicate with each other and between devices, = enables some genuine improvements in networking security and user experience, = starting with the use case you propose and adding the ones which I=92ve suggested to the list: 1. Discovering obfuscated devices which have been out-of-band paired = are on the local network 2. Resolving services with assurances that the advertising entity is = responding 3. Security exchanging credentials to create device pairs or join = groups 4. Selectively advertising services to particular groups 5. Selectively browsing services from particular groups 6. Browsing for public services from trustworthy local hosts (with = signed certs) 1) Could be implemented in existing mDNS/DNS-SD protocol stacks using = new service types, and potentially different rules on the encoding of TXT records to make = their contents private, which could all be implemented at the UI layer. 2) it should be relatively straightforward in principal to provide = authenticity of mDNS responses, insomuch as a client can be assured that the same entity which = advertised a service resolved it. Essentially; each response is signed by the same key to assure a client = that they are talking to the same entity and that the response has not been forged by using = existing DNSSEC records in the appropirate responses. 3-6) Are an expansion on the features you propose, but I think they are = worthwhile to consider as the use cases made possible by them include yours as well as some = other useful ones which I=92ve already mentioned: - pairing of a phone and laptop for local communication - creation of a temporary group for: - trading of contact information - file =91drop=92 from device to device - game or other interactive session - creation of a long-term group for: - family services like presence and location, media sharing - business services like security, directory and document sharing - conference attendees, association members or any other = organization I think a draft laying out all the requirements and intended use cases = for private, local service discovery would help us to evaluate any proposed solutions. And we = should carefully consider the existing protocols for doing peer-to-peer discovery at proximity, = across network boundaries: besides Bluetooth, for low-bitrate PAN networks, the Wi-Fi Direct = standard and Apple=92s AirDrop operate at close range and provide high bandwidth. Both the Wi-Fi based protocols evolved in response to the multicast = problems outlined above;=20 two devices in proximity, even on the same Wi-Fi network in many cases, = could not reliably perform service discovery due to network policy or traffic levels, so = these direct connection=20 protocols developed to work around the lack of support from the network = infrastructure. Best, Alf > On Mar 23, 2016, at 10:46 PM, Christian Huitema = wrote: >=20 > On Wednesday, March 23, 2016 5:37 PM, Alf Watt wrote: >> ... >> For most users a single security posture or group membership won't be >> adequate. Some services may be private (synch with a phone, for = e.g.), > some >> shared with work mates (file and screen sharing), some with family = (game > and >> content sharing), while others are public, the service advertising = stack > will >> have to keep track of the difference and advertise and browse as > appropriate. >=20 > Fair point. I am mostly concerned with the use case of several devices > roaming together, typically phone and laptop or tablet, and then of = work > mates travelling together. We certainly need to work on the usage = scenario > and the UI implications. >=20 >> - Yes, the concern is privacy in multicast environments, so I suggest = the > title >> change to reflect that. Strictly speaking any kind of DNS message = send > over >> mDNS is leaking information, but we only expect to see the SD, name = and >> address resolution messages associated with DNS-SD >=20 > Multicast is certainly the first concern. I do not believe that people = are > actually using server-based resolution in Wi-Fi hot spots. >=20 >> - 4.1: if the party is concerned they MAY use a random host name, if > privacy is >> required they MUST >=20 > Yes. The MAY is my awkward attempt at providing 2 ways of doing that.=20= >=20 >> - the goal is to advertise services in such a way that hosts not > implementing >> the updated protocol will not see them, this suggests using a new = protocol >> and port to differentiate traffic, allow for a secure protocol design = and > avoid >> obfuscation and name mangling >=20 > That's certainly an option. But at the same time, there is value in = reusing > as much infrastructure as possible. >=20 >> - as you are proposing a shared key solution, there should be some > proposal >> for key sharing and exchange >=20 > Agreed. I wanted to have first a discussion of the concept. >=20 >> - this moves the solution towards Bluetooth style link-key exchange > pairing >> model of security for local services. It's probably worth reviewing = those >> protocols to see if one can be reused for this purpose. >=20 > Bluetooth style pairing is certainly one way. I should really have = added a > link to the BT LE spec, and its address obfuscation mechanism. But = then, > pairing is certainly not the only way to do that. We could also use = "cloud > based" mechanism, of the kind used to synchronize multiple device with = the > same owner. >=20 >> - as suggested, only a single key and therefore a single 'kin' = group[1] > per >> device would be supported >=20 > That would be adequate for the "laptop and phone" scenario. Not so = much for > the "work mates" scenario. >=20 >> - consider using a one-time key to protect the payload of an mDNS = packet, >> and wrapping that key in one or more 'kin' group keys to allow a = single >> service to be advertised to multiple groups: >>=20 >> [mDNS message encrypted with K] >> [K encrypted with G1] >> [K encrypted with G2] >> [etc.] >=20 > Yes, that's the other possible design -- running encrypted MDNS on a > separate port. It is a different tradeoff. Obfuscation allows reuse of = the > "low level" mechanisms, and places the burden entirely at the user > interface. Encryption makes the interface implementation easier, but > requires different ports, sending systems, etc. I believe the = user-interface > solution is easier to implement and less error prone. >=20 >> - note that this allows for privately advertising the true host name = and > makes >> browsing requests private as well (only a kin will be able to unwrap = the > on- >> time-key and see the service type requested). >=20 > That would work, as long as the names do not leak from the "encrypted = MDNS" > to the "clear text MDNS." If MDNS is configured with an obfuscated = host > name, it will not leak when if an active attacker does an active = search for > the clear-text name. >=20 > -- Christian Huitema >=20 >=20 >=20 >=20 >=20 From nobody Sun Mar 27 13:29:28 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF07212D140 for ; Sun, 27 Mar 2016 13:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMF9cJ7skWaj for ; Sun, 27 Mar 2016 13:29:25 -0700 (PDT) Received: from mirix.in-vpn.de (mirix.in-vpn.de [IPv6:2001:67c:1407:a0::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BA4412D0F7 for ; Sun, 27 Mar 2016 13:29:23 -0700 (PDT) Received: from [::1] (helo=localhost.localdomain) by mirix.in-vpn.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) id 1akHIV-0007Vk-Sf for dnssd@ietf.org; Sun, 27 Mar 2016 20:28:32 +0000 To: dnssd@ietf.org From: Matthias-Christian Ott Message-ID: <56F8429D.3070402@mirix.org> Date: Sun, 27 Mar 2016 22:29:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [dnssd] DNS UPDATE access control in DNS-SD X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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, 27 Mar 2016 20:29:26 -0000 Using DNS UPDATE for updating DNS-SD and SRV RRs in general requires multiple hosts to be able to update a shared domain name. If you want to limit the damage of a single host to itself, a DNS server that handles updates for the domain name would have to examine the RDATA section in order to decide whether to allow an update or not. Assume for example that there a two hosts a.example.com. and b.example.com. Both hosts provide IMAP services and therefore would need to be able to update RRs _imap._tcp.example.com. (either PTR RRs or SRV RRs depening on whether you use DNS-SD or plain SRV RRs). If you grant both hosts access to update _imap._tcp.example.com. and the update credentials (TSIG or SIG(0) key) of one of the hosts is compromised, it would be possible to remove the other host from _imap._tcp.example.com. and therefore to deny service for that host. Besides that I'm not aware of any DNS server that would support examining the DNS RDATA section (not even even the "external" access control mechanism of BIND does). Was that a scenario that was considered in the architecture of DNS-SD? Is there a way to handle this scenario without examining the RDATA section? - Matthias-Christian From nobody Mon Mar 28 14:21:42 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A02E12D0A1 for ; Mon, 28 Mar 2016 14:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keMsX5MTDIjz for ; Mon, 28 Mar 2016 14:21:40 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78A4A12D163 for ; Mon, 28 Mar 2016 14:21:40 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id c67so85823049qgc.1 for ; Mon, 28 Mar 2016 14:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:message-id:to:mime-version; bh=AZSXzyhOJkWMhBYj127ElsunTVDU6AezXvokeOgs9YA=; b=T0Hk5yWyhNJgHlfcxoopOy0yg5/IfdS09kWXivIr5psDbQK+ri7k8iBZI7gfRZMpzb 09wRv+AoX7nXNrl8otu60e1oYFl2Sd6HxcrHxY8L9ZeM1ou9T4pvgOgS5owj0xdl/Zhj 1skj6dEyjEO51TcKbbTasURtrS2zjMo+38lBToTRPCfM0ptN6Uh52gEfu8nzeK5UzyK9 ybUVC8F0Z9hI97ReD4Yzoik+VpcfO4ILne0XwZUFN1Fnq2RxT0S4SDpMe4AWhpUpxyfM ZfZHM8lpFejJS7kJ4qVZSQ3bnUANpsvOxQpYtMFohOGq2oBsLVZLn1qwwjWbA/gdxfXH rylg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:message-id:to:mime-version; bh=AZSXzyhOJkWMhBYj127ElsunTVDU6AezXvokeOgs9YA=; b=FCMwRNeUAHrBAbkh9eBetUrQA+qNecnYmaeDjLKJLu3Z4cJw0V9LEMJ7zcvOevX2/d SsqgzqhmZNDu5wp/q0vE5pu3U13p2bq9zVGubsiAkZgS2OFW0s6eXWsB9Lbf8KzGgZNE QA4IgvZqsoXy0EyplQvzumY9hkbp+SJ6UdWUrvosjLnMNtY7Ia5PWrFCWHZdgX9wrSEn dq/OkK+ZmraxyjOWLk7n6QrIIIY4IitvAPNu6ykm4OrXs7SYl0Hifc2xkbLGJmKuid1Z PjjI4JHwbslDOhzv0GCz9gzxOIaD64bBDNqpW5A+ZemGiBuN9aFf/AKiV5wzF/HAtF0N qETw== X-Gm-Message-State: AD7BkJKuQVSJfVSlnJTp1+RN+zQB53r/NPX1/g7ukN4jemFbpwxNWVqlzS4rH7R8vIfYvg== X-Received: by 10.140.131.6 with SMTP id 6mr38530747qhd.67.1459200099496; Mon, 28 Mar 2016 14:21:39 -0700 (PDT) Received: from ?IPv6:2001:420:c0c4:1006::a9? ([2001:420:c0c4:1006::a9]) by smtp.gmail.com with ESMTPSA id d6sm12651860qkb.13.2016.03.28.14.21.38 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 28 Mar 2016 14:21:38 -0700 (PDT) From: Ralph Droms X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_2023FB44-F644-4A2F-AB41-70846FDED454"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Mon, 28 Mar 2016 17:21:36 -0400 Message-Id: <24DBB074-51D0-421A-B0BA-ADF24D7A0A3E@gmail.com> To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [dnssd] WG last calls X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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, 28 Mar 2016 21:21:42 -0000 --Apple-Mail=_2023FB44-F644-4A2F-AB41-70846FDED454 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We have two WG last calls in progress: draft-ietf-dnssd-mdns-dns-interop-02 draft-ietf-dnssd-hybrid-03 Both of these last calls are scheduled to conclude on March 31. To = date, only one review of these documents has been posted. Please review = and post comments to dnssd@ietf.org by March 31. Results of the WG last = calls will be reviewed at the dnssd WG meeting in Buenos Aires. - Ralph and Tim --Apple-Mail=_2023FB44-F644-4A2F-AB41-70846FDED454 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJW+aBgAAoJEINeeBNmFjV5dfcP/16tBByxx2yfetiiqJv0Qt9U i+fSHu+vLpsd7ZVBiZY1QA+bHICm0nitxnHJyZUm5VHaohfuwvc0meY+znSQuiax IdiAMxpBnuO14kITcuu2+rzDRvAejO2hx4WdNQ0LV60HrLyf9d8ICl0BPya5OYOn WDV0jwkg/jx/3xrJBEGIqVZ0EsgKQd/aSwuEwIRoHQJZpZU4y3bHs1wcoqIML5QF KRasNt1+67S+csVSNm6c4r52Xjci44PCYWgz4Y4Gn3YvFB/slvZNq8Zy+qPe6szP 4sdW09C+O1iiVsrOdNl7R7xy/gNruME2tTOVd/52+TPKrUWdfJC841M9SC+/Nz9j Z/QR2BKyJPIiDI0mxisGh2c+D49oRS1koCtBVpUPLmFEpYMhmiuLW+bOBps/v9Xg 32x9MGD1agTw999bB6VyNxDtlutcSqggOf168Qxru/fG/IU0zy2nEMP1Hf00GaQH Juc+DeLYUpdFm2POHlvEhqifzC9fLYskt5A6kUNlo194onY5J/UQxhkQJnYmkXXK UEmEVRZj7glzrAw9N7HlHiwAwQ2tJ7MAVDPN4vhYg359WQ0hiqu+8wKllMeDZ5zL pmEcE3PTWIqfNMDCa2dUMaf3+WVlCROyaKCetPfuu8ap9HoS5mA2O5KIimry7nth XpD9TiPEBlGKP8nISNRV =8b3T -----END PGP SIGNATURE----- --Apple-Mail=_2023FB44-F644-4A2F-AB41-70846FDED454-- From nobody Mon Mar 28 14:55:03 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB7712D565 for ; Mon, 28 Mar 2016 14:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJu1UZCwPgte for ; Mon, 28 Mar 2016 14:55:00 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF6312D19E for ; Mon, 28 Mar 2016 14:55:00 -0700 (PDT) Received: from [192.168.200.17] (64.203.245.220.static-pool-10.pool.hargray.net [64.203.245.220]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id DE9A61D38B; Mon, 28 Mar 2016 17:53:47 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B31FA097-74E6-4D79-A971-55FA8C04D5CF"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Tom Pusateri In-Reply-To: <24DBB074-51D0-421A-B0BA-ADF24D7A0A3E@gmail.com> Date: Mon, 28 Mar 2016 17:54:59 -0400 Message-Id: References: <24DBB074-51D0-421A-B0BA-ADF24D7A0A3E@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.3124) Archived-At: Cc: dnssd@ietf.org Subject: Re: [dnssd] WG last calls X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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, 28 Mar 2016 21:55:02 -0000 --Apple-Mail=_B31FA097-74E6-4D79-A971-55FA8C04D5CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 28, 2016, at 5:21 PM, Ralph Droms = wrote: >=20 > We have two WG last calls in progress: >=20 > draft-ietf-dnssd-mdns-dns-interop-02 > draft-ietf-dnssd-hybrid-03 >=20 > Both of these last calls are scheduled to conclude on March 31. To = date, only one review of these documents has been posted. Please review = and post comments to dnssd@ietf.org by March 31. Results of the WG last = calls will be reviewed at the dnssd WG meeting in Buenos Aires. >=20 > - Ralph and Tim There has been multiple reviews of both drafts before the last call from = Markus, Douglas, Andrew, myself, and many others. Are you asking for us = to chime in during the last call and voice affirmative positions? Thanks, Tom --Apple-Mail=_B31FA097-74E6-4D79-A971-55FA8C04D5CF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJW+agzAAoJEPk0GMVmUuYM84QIANUlr+qEsyccUzo8WKKjHJ05 YwxZjThzBltEzDpRUk+/WrKcpjju775G3kmCEFyufB2oFtxlAiXAE71iNSe4Xle9 532nd7E12UveXCcGa4pC+jc+vscAUzt+X0GICiOr6QFG2FMihdZ2A6prsCUECvef eyhku3q6FfyqGR/3YNuP8H1jHjikyyEA7cV6gR9Wo9uHsZd3JJn4ITxcZX8pQkoR 57XMz4gkOYvdrWhACH/xmRbDTdR30Cws8xFRs5Kg5pOqWg9BHLiSVmvNpqgZ17IO YULlU9r2Rp1pnljy3fJV1Rj3q6c20GzUtTTY95vHeURux8YKcl0YvijOmoR8vJA= =Gx00 -----END PGP SIGNATURE----- --Apple-Mail=_B31FA097-74E6-4D79-A971-55FA8C04D5CF-- From nobody Mon Mar 28 14:56:09 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDF612D19E for ; Mon, 28 Mar 2016 14:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muWbj9t0BPMM for ; Mon, 28 Mar 2016 14:56:05 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7EC12D565 for ; Mon, 28 Mar 2016 14:56:05 -0700 (PDT) Received: by mail-qg0-x231.google.com with SMTP id y89so120224759qge.2 for ; Mon, 28 Mar 2016 14:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=xyqkhDqUGwa1ggvVxz47iYkzlZcjkFdAZheU0wLD/BM=; b=iKqzL3KNhflZeI0dFRpcgBdTI9UnQyXZknThx1+zeRi+U9oZjbYO9SBWUvvh8jA5BC r8l7MRhTj46+jT2VwByEfsAF9Qhqd3LgLVG1OjOptpPwAldvkx6hQA+3Unmivjja5Jg7 ySOm/u+5vX3d2k8avR/zR4f1yEDphUaFM9Us2L/aTZ4XIwRYtGjaDRIVNLPKJBLMKTtg IlR/49OWWcE3ZZ2fG9F2VKEGfcybrluE7WVZytMOOiEggr0wrTXoIwY7oiSIIilKAvFH gHeGhvEqRa3s1HjAx8UW0cVmVUZ6AVPulxKpWG3WwgOVATjjnI0K5AGKHgCf0YGAKzIp LPfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=xyqkhDqUGwa1ggvVxz47iYkzlZcjkFdAZheU0wLD/BM=; b=GmKNR5IKYEhw8FBBMNX9OesZrsMLV1HS4lm7LP8fpNrLcvIEqZ5c689T7E1gdVVIYN A+CXx1/oryAfI2vwVe9wDbqg+GRdcrjoctw2twctYIqWN6njX+lt714LXGBgfHmKdGEE roY/ifDdgtmsiopcfdh6sYgr88sihsHky2ctuPVYuHGfDUbiTQaLsg8iVwBo0r30evnI WX+FVo1MZz0r+78lIYjJ7/N1h6yzYgSXLAvG8cfrrCdukL9AIgpH2qNKA+Lhh5PkCRgq P80Y9xOZ2cP3vsXvF+OnGcEH4Z/GSoeLOuHmyrKyDshYJJHMfn1mSScct3uYICo1uEXa JwoQ== X-Gm-Message-State: AD7BkJKNtGl6OZn4D8XGpvydy2Wac1l920mbi3zZ1gjJLSLajHtDRRMzfhBOXqu8aYEMLA== X-Received: by 10.140.159.69 with SMTP id f66mr41765879qhf.18.1459202164875; Mon, 28 Mar 2016 14:56:04 -0700 (PDT) Received: from ?IPv6:2001:420:c0c4:1006::a9? ([2001:420:c0c4:1006::a9]) by smtp.gmail.com with ESMTPSA id b74sm1665955qge.22.2016.03.28.14.56.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 28 Mar 2016 14:56:04 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BC42DBA3-9B40-4951-8BE9-C751CCFA72D5"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Ralph Droms In-Reply-To: Date: Mon, 28 Mar 2016 17:56:02 -0400 Message-Id: <310C90F3-297D-4E98-AC7E-89EE5711DEF6@gmail.com> References: <24DBB074-51D0-421A-B0BA-ADF24D7A0A3E@gmail.com> To: Tom Pusateri X-Mailer: Apple Mail (2.3124) Archived-At: Cc: dnssd@ietf.org Subject: Re: [dnssd] WG last calls X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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, 28 Mar 2016 21:56:08 -0000 --Apple-Mail=_BC42DBA3-9B40-4951-8BE9-C751CCFA72D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 28, 2016, at 5:54 PM 3/28/16, Tom Pusateri = wrote: >=20 >=20 >> On Mar 28, 2016, at 5:21 PM, Ralph Droms = wrote: >>=20 >> We have two WG last calls in progress: >>=20 >> draft-ietf-dnssd-mdns-dns-interop-02 >> draft-ietf-dnssd-hybrid-03 >>=20 >> Both of these last calls are scheduled to conclude on March 31. To = date, only one review of these documents has been posted. Please review = and post comments to dnssd@ietf.org by March 31. Results of the WG last = calls will be reviewed at the dnssd WG meeting in Buenos Aires. >>=20 >> - Ralph and Tim >=20 > There has been multiple reviews of both drafts before the last call = from Markus, Douglas, Andrew, myself, and many others. Are you asking = for us to chime in during the last call and voice affirmative positions? Yes, please - confirming that any final changes made in response to = earlier reviews now have consensus as ready for publication. - Ralph >=20 > Thanks, > Tom >=20 >=20 >=20 --Apple-Mail=_BC42DBA3-9B40-4951-8BE9-C751CCFA72D5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJW+ahzAAoJEINeeBNmFjV56zoQALNKwQyV4jg1bxcnKg4cW7iS ic0g5paa4ZzTyF+flZ2dIJYDpDl+bvSabMF0eh57WVHs75avCiDkBb/V1i8Bh03G wD0x5UtSdClv3ASyNfvc7aTsAaed9PTXmmU7SQEZgBi4zoJuVtc9aPnrV+3fBPyw w0EKoTpZoN/gAkkTIJgHGICF0a9e53YaG9DrbLjUXuTyDcawK8ylt9JWWjjrXcRC RPUg48XRgt9lmXYjIxy71uY5/QifoocxNi5J3PlQZCoLvtKZSHY3C1BAVpxGvpj+ g0iSflClpX9Zp4LexxCQp7Sbm1j+KZWGecAXSWI8xbrAES0CbiDEiuq+mvwp2uF3 1meKUEBKgiAsSN/n2NKFFXUYPztCP1VMm+1EEC8cB5JeJCi90Lz7EAF+5Ohu9NcR A4ifCKS2qrxuyb3ssKlCVfpP7U9QfZ/GP8ofcTiuRYBzDudLmEnAqlFFFBJxB2Yy 7nHNfQwAZkaeluzKR9jHil8cEJk0YuG4tIHUtFjCG7jgJ6t6CPaN7vG+uV7iek14 fU22Mo/kqhVQ5aHSLDgsseLzQ2LoF11U+RI5z2CXMhBR2px9MadBMyZ2C9zhc30Z hlq+IB8uZhfsxaTbtzWh5Ke1NUPYblUbcZoLI/7xaGpQ1cZsGgJoJl+Ww1lFt9HB y0j0DKcpUO+g6lc05NUu =oIBw -----END PGP SIGNATURE----- --Apple-Mail=_BC42DBA3-9B40-4951-8BE9-C751CCFA72D5-- From nobody Thu Mar 31 17:38:53 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A970512D917 for ; Thu, 31 Mar 2016 17:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FN5pXztoMIsw for ; Thu, 31 Mar 2016 17:38:49 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360FE12D15C for ; Thu, 31 Mar 2016 17:38:49 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id DE6177400E4 for ; Fri, 1 Apr 2016 00:38:48 +0000 (UTC) Received: from mbx-03.WIN.NOMINUM.COM ([169.254.4.19]) by CAS-03.WIN.NOMINUM.COM ([64.89.235.66]) with mapi id 14.03.0224.002; Thu, 31 Mar 2016 17:38:48 -0700 From: Ted Lemon To: "dnssd@ietf.org" Thread-Topic: Last call comments on draft-ietf-dnssd-hybrid-03 Thread-Index: AQHRi67RNg7IG9b6vUeHmOFOnsaIqQ== Date: Fri, 1 Apr 2016 00:38:48 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630797A43137@mbx-03.WIN.NOMINUM.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [107.16.24.110] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [dnssd] Last call comments on draft-ietf-dnssd-hybrid-03 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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, 01 Apr 2016 00:38:51 -0000 I=92ve tried to do a thorough review of the mdns-dnssd-hybrid document--sor= ry it=92s taken so long. My general feeling about the document is that it=92s the wrong way to solve= the problem, but also the expedient way to solve the problem. So I don= =92t want to stand in the way of its publication, but there are some things= I=92d like to see done differently if it=92s possible. I am not clear on = exactly what has seen widespread implementation, so some of my comments may= require overcoming a lot of inertia, but I suspect not. What I would really like to see in the long run is a clean DNS-based soluti= on with as much of the mDNS stuff hidden or eliminated as possible. I do = not know what the feeling of the working group is on this--maybe I=92m out = in left field and everybody else is happy with the proposed model. But he= re=92s a high level summary of what I would change: First, the current document assumes that there is no mechanism for stateful= ly publishing information. This is not something that is, as far as I kno= w, a requirement--it's just a result of the approach that the hybrid draft = takes. This approach has a couple of results. First, it means that you have to na= me every link, because you have to have a delegation for every link. This= is just not going to work for homenet. Homenet users won=92t necessarily= be able to cognize the thing that the word =93link=94 refers to, and won= =92t be able to assign names to links, so the homenet would have to generat= e names, and those names wouldn=92t make sense either. So this model can= =92t actually support a homenet in practice, despite Markus and Steven's no= doubt excellent proof-of-concept implementation. Unfortunately, the model as currently described doesn=92t offer a way out o= f this. In principle, there=92s no reason that you can=92t have an mDNS h= ybrid on every wire all of which update the same DNS primary, and let servi= ces on the local wire that support DNS update as well as mDNS do the update= themselves, through the mDNS proxy so that off-link attacks can be rejecte= d. You could just do mDNS only for publication, but my reason for not wanting = that is that ideally we=92d like to wean ourselves off of mDNS to the exten= t possible--it doesn=92t scale, as this document says, and some of the text= in this document tries but IMHO fails to effectively rate-limit it. This= will be a particular problem if we expose the DNSSD tree to off-site queri= es, which we would have to do to allow legitimate off-site use of services:= if you restrict queries to 20 per second, it's not that hard to imagine ru= nning up against that limit in practice when nobody's doing anything bad. = This is particularly the case because the link-naming strategy is going to= tend to push sites to use larger links than they might otherwise have done= . I think it may be possible to tweak this specification so that it _allows_ = for the DNS model I just described but doesn=92t require it. Essentially = whether you implement the hybrids as a cache or as a primary name server an= d a bunch of secondaries that will relay updates from the local network is = an implementation choice, isn=92t it? But if we did that, I think it woul= d have to be the case that the whole section on disallowing zone transfers = goes away, since they could now be supported. This is what I=92d like to see happen, but I will not be deeply surprised i= f the working group throws rotten tomatoes at me for proposing this now. = That said, I=92m hoping Stuart will do me the kindness of a sit-down this w= eekend or sometime on Monday before the meeting to see if there=92s a middl= e ground to be reached. The one thing that I=92m fairly sure could be done painlessly, and that I t= hink would make the document a lot less complicated and a lot less difficul= t to explain, and would also simplify implementation, would be to get rid o= f the two-subdomains hack. The point of this hack as far as I can tell is= to allow each wire to have a UI-presentable name. But this is totally unn= ecessary--since the multilink DNSSD model is new, why not just have a well-= known name under the single per-link (or whatever) subdomain that has a TXT= record hanging off of it with the presentation name for the subdomain? T= hen you can have a unified domain with all the presentable and non-presenta= ble names in it, and bob=92s your uncle. This also saves you having to de= al with the A-label problem for link (or shall we say "zone"?) names. E.g., using the example in 4.3, and assuming the WKN is _textname: _textname.bldg1.example.com TXT =93Building 1=94 My Printer._ipp._tcp.bldg1.example.com. SRV 0 0 631 prnt.bldg1.example.com. prnt.bldg1.example.com. A 10.0.1.2 On to more detailed comments: The abstract is way too wordy. You=92re trying to explain to someone who = is searching why they should read the document, not explain the entirety of= what the document says. Suggestion: This document describes a method for extending Multicast DNS Service Discovery so that it can support automatic service announcement and discovery across multiple links. This is accomplished using a hybrid DNS model, where services are discovered using Multicast DNS if required, and published using DNS if possible, and Multicast DNS otherwise. The other text should be moved to the Introduction if it isn=92t already th= ere. Document doesn=92t appear to talk about how resolution happens in a homenet= (which is sort of okay, since that the the HNSDA=92s job). However, the = text in 4.1p3 says that normal delegation is used, and that won=92t work in= a homenet that doesn=92t have a global name. It may be worth clarifying = this. Also, what if the reverse tree for IPv4 is some kind of RFC1918 add= ress space? Is the process of delegating this address space discussed els= ewhere in the document? 4.2.1 seems to be recapitulating RFC 6763 section 11. Can this be streaml= ined by simply referencing that section? Regarding 4.2.2, what is the prevalence of DNSSD clients that only support = mDNS? That is, how badly would it suck to not provide multicast browsing = services? Quoting: If a given link is using the IPv4 subnet 10.1/16, then the domain "1.10.in-addr.arpa" is delegated to the Hybrid Proxy for that link. How is this accomplished? 10.in-addr.arpa is delegated to itself. This = section also does not mention how ULAs are supported, but it seems like the= y should be. I think the answer to this question is that the local caching resolver that= is returned by DHCP and ND should answer for all private zones, either wit= h information or with the appropriate error, so in principle this is manage= able, but of course not using DNSSEC. It appears that the author agrees a= t least regarding suppression, and I suspect also with the rest, but it sho= uld be stated explicitly in the document, since what the document currently= says isn=92t actually possible. This document doesn=92t make any reference to the idea of using DNS update = to publish DNSSD services, which is something that the original DNSSD RFC d= oes describe (although it doesn=92t explain it in detail). I think this i= s an unfortunate omission, because it means that there is no recommended pa= th forward for fixing mdns=92 chattiness. Is there any reason not to use TTL=3D0 for all DNS responses? Another way to deal with embedded .local names would be to allow resolution= of .local names on other links if there is no conflict. Arguably this is= better than diving into TXT records, since in general it should always wor= k. Seems like Stuart=92s already thinking about this. I don=92t disagree with the use of LLQ as a way to improve UI responsivenes= s, but I think that the concern about caching on an institutional network i= s probably overblown. Would be interesting to see real numbers. We care= a lot about multicast; not so much about unicast. You shouldn=92t recapitulate the procedure for discovering push/LLQ servers= , and shouldn=92t reference LLQ unless you intend to publish it. It=92s in= teresting historically, but is deader than a doornail, not work =93in progr= ess=94! SOA increment could happen whenever the cache is changed as a result of an = update. You should definitely update the serial number at least that often= , don=92t use zero. From nobody Thu Mar 31 17:54:02 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E93012D51D for ; Thu, 31 Mar 2016 17:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiIux_FvM4ES for ; Thu, 31 Mar 2016 17:53:56 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8573C12D508 for ; Thu, 31 Mar 2016 17:53:56 -0700 (PDT) Received: from [172.18.99.179] (unknown [70.158.101.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 3DA821D9D5; Thu, 31 Mar 2016 20:52:31 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_113BA719-D247-49A2-9ADC-6A16D8290CEA"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Tom Pusateri In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630797A43137@mbx-03.WIN.NOMINUM.COM> Date: Thu, 31 Mar 2016 20:53:52 -0400 Message-Id: References: <8D23D4052ABE7A4490E77B1A012B630797A43137@mbx-03.WIN.NOMINUM.COM> To: Ted Lemon X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "dnssd@ietf.org" Subject: Re: [dnssd] Last call comments on draft-ietf-dnssd-hybrid-03 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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, 01 Apr 2016 00:54:01 -0000 --Apple-Mail=_113BA719-D247-49A2-9ADC-6A16D8290CEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 There=92s a lot in here to go over but at first glance, I don=92t think = you should get hung up on naming the subnets. This is mostly = transparent. Say you have a domain foobar.com: You create a bunch of names for each link and make them browse-able in = the zone. These ones are generated using a simple hex algorithm of the = IP subnet: b._dns-sd._udp IN PTR netac100a00.foobar.com. b._dns-sd._udp IN PTR netac100b00.foobar.com. b._dns-sd._udp IN PTR netac106400.foobar.com. b._dns-sd._udp IN PTR netac101500.foobar.com. b._dns-sd._udp IN PTR netac101600.foobar.com. b._dns-sd._udp IN PTR netac101900.foobar.com. b._dns-sd._udp IN PTR netac120100.foobar.com. b._dns-sd._udp IN PTR netac120200.foobar.com. You delegate these to the hybrid proxies: netac101500.hypd.info. IN NS proxy1.foobar.com. netac101600.hypd.info. IN NS proxy2.foobar.com. netac100a00.hypd.info. IN NS proxy3.foobar.com. netac100b00.hypd.info. IN NS proxy3.foobar.com. netac106400.hypd.info. IN NS proxy4.foobar.com. netac101900.hypd.info. IN NS proxy4.foobar.com. netac120100.hypd.info. IN NS proxy4.foobar.com. Then, in the client, you add foobar.com to the search domain. It finds = the browse-able subdomain names and browses them by going to the = delegated hybrid proxies. The client never directly deals with the = subdomain names (only indirectly). You don=92t really even care what = they are. In a future version, my implementation will generate them automatically = and update the parent zone if it supports dynamic updates so there=92s = no configuration at all. Thanks, Tom > On Mar 31, 2016, at 8:38 PM, Ted Lemon wrote: >=20 > I=92ve tried to do a thorough review of the mdns-dnssd-hybrid = document--sorry it=92s taken so long. >=20 > My general feeling about the document is that it=92s the wrong way to = solve the problem, but also the expedient way to solve the problem. So = I don=92t want to stand in the way of its publication, but there are = some things I=92d like to see done differently if it=92s possible. I am = not clear on exactly what has seen widespread implementation, so some of = my comments may require overcoming a lot of inertia, but I suspect not. >=20 > What I would really like to see in the long run is a clean DNS-based = solution with as much of the mDNS stuff hidden or eliminated as = possible. I do not know what the feeling of the working group is on = this--maybe I=92m out in left field and everybody else is happy with the = proposed model. But here=92s a high level summary of what I would = change: >=20 > First, the current document assumes that there is no mechanism for = statefully publishing information. This is not something that is, as = far as I know, a requirement--it's just a result of the approach that = the hybrid draft takes. >=20 > This approach has a couple of results. First, it means that you have = to name every link, because you have to have a delegation for every = link. This is just not going to work for homenet. Homenet users = won=92t necessarily be able to cognize the thing that the word =93link=94 = refers to, and won=92t be able to assign names to links, so the homenet = would have to generate names, and those names wouldn=92t make sense = either. So this model can=92t actually support a homenet in practice, = despite Markus and Steven's no doubt excellent proof-of-concept = implementation. >=20 > Unfortunately, the model as currently described doesn=92t offer a way = out of this. In principle, there=92s no reason that you can=92t have = an mDNS hybrid on every wire all of which update the same DNS primary, = and let services on the local wire that support DNS update as well as = mDNS do the update themselves, through the mDNS proxy so that off-link = attacks can be rejected. >=20 > You could just do mDNS only for publication, but my reason for not = wanting that is that ideally we=92d like to wean ourselves off of mDNS = to the extent possible--it doesn=92t scale, as this document says, and = some of the text in this document tries but IMHO fails to effectively = rate-limit it. This will be a particular problem if we expose the = DNSSD tree to off-site queries, which we would have to do to allow = legitimate off-site use of services: if you restrict queries to 20 per = second, it's not that hard to imagine running up against that limit in = practice when nobody's doing anything bad. This is particularly the = case because the link-naming strategy is going to tend to push sites to = use larger links than they might otherwise have done. >=20 > I think it may be possible to tweak this specification so that it = _allows_ for the DNS model I just described but doesn=92t require it. = Essentially whether you implement the hybrids as a cache or as a primary = name server and a bunch of secondaries that will relay updates from the = local network is an implementation choice, isn=92t it? But if we did = that, I think it would have to be the case that the whole section on = disallowing zone transfers goes away, since they could now be supported. >=20 > This is what I=92d like to see happen, but I will not be deeply = surprised if the working group throws rotten tomatoes at me for = proposing this now. That said, I=92m hoping Stuart will do me the = kindness of a sit-down this weekend or sometime on Monday before the = meeting to see if there=92s a middle ground to be reached. >=20 > The one thing that I=92m fairly sure could be done painlessly, and = that I think would make the document a lot less complicated and a lot = less difficult to explain, and would also simplify implementation, would = be to get rid of the two-subdomains hack. The point of this hack as = far as I can tell is to allow each wire to have a UI-presentable name. = But this is totally unnecessary--since the multilink DNSSD model is new, = why not just have a well-known name under the single per-link (or = whatever) subdomain that has a TXT record hanging off of it with the = presentation name for the subdomain? Then you can have a unified = domain with all the presentable and non-presentable names in it, and = bob=92s your uncle. This also saves you having to deal with the = A-label problem for link (or shall we say "zone"?) names. >=20 > E.g., using the example in 4.3, and assuming the WKN is _textname: >=20 > _textname.bldg1.example.com TXT =93Building 1=94 > My Printer._ipp._tcp.bldg1.example.com. > SRV 0 0 631 prnt.bldg1.example.com. > prnt.bldg1.example.com. A 10.0.1.2 >=20 > On to more detailed comments: >=20 > The abstract is way too wordy. You=92re trying to explain to someone = who is searching why they should read the document, not explain the = entirety of what the document says. Suggestion: >=20 > This document describes a method for extending Multicast DNS Service > Discovery so that it can support automatic service announcement > and discovery across multiple links. This is accomplished using > a hybrid DNS model, where services are discovered using Multicast > DNS if required, and published using DNS if possible, and Multicast > DNS otherwise. >=20 > The other text should be moved to the Introduction if it isn=92t = already there. >=20 > Document doesn=92t appear to talk about how resolution happens in a = homenet (which is sort of okay, since that the the HNSDA=92s job). = However, the text in 4.1p3 says that normal delegation is used, and that = won=92t work in a homenet that doesn=92t have a global name. It may be = worth clarifying this. Also, what if the reverse tree for IPv4 is some = kind of RFC1918 address space? Is the process of delegating this = address space discussed elsewhere in the document? >=20 > 4.2.1 seems to be recapitulating RFC 6763 section 11. Can this be = streamlined by simply referencing that section? >=20 > Regarding 4.2.2, what is the prevalence of DNSSD clients that only = support mDNS? That is, how badly would it suck to not provide = multicast browsing services? >=20 > Quoting: > If a given link is using the IPv4 subnet 10.1/16, then the domain > "1.10.in-addr.arpa" is delegated to the Hybrid Proxy for that link. >=20 > How is this accomplished? 10.in-addr.arpa is delegated to itself. = This section also does not mention how ULAs are supported, but it seems = like they should be. >=20 > I think the answer to this question is that the local caching resolver = that is returned by DHCP and ND should answer for all private zones, = either with information or with the appropriate error, so in principle = this is manageable, but of course not using DNSSEC. It appears that = the author agrees at least regarding suppression, and I suspect also = with the rest, but it should be stated explicitly in the document, since = what the document currently says isn=92t actually possible. >=20 > This document doesn=92t make any reference to the idea of using DNS = update to publish DNSSD services, which is something that the original = DNSSD RFC does describe (although it doesn=92t explain it in detail). = I think this is an unfortunate omission, because it means that there is = no recommended path forward for fixing mdns=92 chattiness. >=20 > Is there any reason not to use TTL=3D0 for all DNS responses? >=20 > Another way to deal with embedded .local names would be to allow = resolution of .local names on other links if there is no conflict. = Arguably this is better than diving into TXT records, since in general = it should always work. Seems like Stuart=92s already thinking about = this. >=20 > I don=92t disagree with the use of LLQ as a way to improve UI = responsiveness, but I think that the concern about caching on an = institutional network is probably overblown. Would be interesting to = see real numbers. We care a lot about multicast; not so much about = unicast. >=20 > You shouldn=92t recapitulate the procedure for discovering push/LLQ = servers, and shouldn=92t reference LLQ unless you intend to publish it. = It=92s interesting historically, but is deader than a doornail, not work = =93in progress=94! >=20 > SOA increment could happen whenever the cache is changed as a result = of an update. You should definitely update the serial number at least = that often, don=92t use zero. >=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_113BA719-D247-49A2-9ADC-6A16D8290CEA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJW/cahAAoJEPk0GMVmUuYMo8IH/j4w6QH5nZIBYgRuAQA9rh/A v754E0KPdj8UjS4w+3A7tAYshd52V5x6z2ydZ2AeZ9fNACxy7Bs9jZ86dHYTOEs6 VtkSbeaYBh8xDRhMksjQtmZhhjJ1sueKzV9ZDbvCjRsydS+4kNat45lSqnRhRQob zHELPe+dJWlGfPYG7nzCiljFozlSqMrlT6z98oSu/TV4lURXWqdVTJ96gz5F9lEe kpx/LfA7vmzhkLt6ykMuHD3SBfsghjiN5SLF5OAHYjrQXQ043mVlrD2ou0JnxItL NYdKo3IYgzagEvWHbUW74Hs7jphl0Ny27KLBzgMsud+ByXxyQqzKbjaaSxllj1I= =Tiei -----END PGP SIGNATURE----- --Apple-Mail=_113BA719-D247-49A2-9ADC-6A16D8290CEA-- From nobody Thu Mar 31 18:06:59 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D5112D91A for ; Thu, 31 Mar 2016 18:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Njqtm0wAkgH2 for ; Thu, 31 Mar 2016 18:06:53 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3DA812D0AF for ; Thu, 31 Mar 2016 18:06:52 -0700 (PDT) Received: from [172.18.99.179] (unknown [70.158.101.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id D0ED61D9DB; Thu, 31 Mar 2016 21:05:27 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_52293C0A-493F-4970-A671-FA60C02AD5C7"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Tom Pusateri In-Reply-To: Date: Thu, 31 Mar 2016 21:06:49 -0400 Message-Id: <383FF82C-98CA-4612-B355-FD02FDA962F3@bangj.com> References: <8D23D4052ABE7A4490E77B1A012B630797A43137@mbx-03.WIN.NOMINUM.COM> To: Ted Lemon X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "dnssd@ietf.org" Subject: Re: [dnssd] Last call comments on draft-ietf-dnssd-hybrid-03 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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, 01 Apr 2016 01:06:57 -0000 --Apple-Mail=_52293C0A-493F-4970-A671-FA60C02AD5C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 That example would have made more sense if I had changed all the domain = names from hypd.info to foobar.com. The proxies should be: netac101500.foobar.com. IN NS proxy1.foobar.com netac101600.foobar.com. IN NS proxy2.foobar.com netac100a00.foobar.com. IN NS proxy3.foobar.com netac100a00.foobar.com. IN NS proxy3.foobar.com netac106400.foobar.com. IN NS proxy4.foobar.com netac101900.foobar.com. IN NS proxy4.foobar.com netac120100.foobar.com. IN NS proxy4.foobar.com Sorry for the confusion. Tom > On Mar 31, 2016, at 8:53 PM, Tom Pusateri wrote: >=20 > There=92s a lot in here to go over but at first glance, I don=92t = think you should get hung up on naming the subnets. This is mostly = transparent. >=20 > Say you have a domain foobar.com: >=20 > You create a bunch of names for each link and make them browse-able in = the zone. These ones are generated using a simple hex algorithm of the = IP subnet: >=20 > b._dns-sd._udp IN PTR netac100a00.foobar.com. > b._dns-sd._udp IN PTR netac100b00.foobar.com. > b._dns-sd._udp IN PTR netac106400.foobar.com. > b._dns-sd._udp IN PTR netac101500.foobar.com. > b._dns-sd._udp IN PTR netac101600.foobar.com. > b._dns-sd._udp IN PTR netac101900.foobar.com. > b._dns-sd._udp IN PTR netac120100.foobar.com. > b._dns-sd._udp IN PTR netac120200.foobar.com. >=20 > You delegate these to the hybrid proxies: >=20 > netac101500.hypd.info. IN NS proxy1.foobar.com. > netac101600.hypd.info. IN NS proxy2.foobar.com. > netac100a00.hypd.info. IN NS proxy3.foobar.com. > netac100b00.hypd.info. IN NS proxy3.foobar.com. > netac106400.hypd.info. IN NS proxy4.foobar.com. > netac101900.hypd.info. IN NS proxy4.foobar.com. > netac120100.hypd.info. IN NS proxy4.foobar.com. >=20 > Then, in the client, you add foobar.com to the search domain. It finds = the browse-able subdomain names and browses them by going to the = delegated hybrid proxies. The client never directly deals with the = subdomain names (only indirectly). You don=92t really even care what = they are. >=20 > In a future version, my implementation will generate them = automatically and update the parent zone if it supports dynamic updates = so there=92s no configuration at all. >=20 > Thanks, > Tom >=20 >=20 >> On Mar 31, 2016, at 8:38 PM, Ted Lemon wrote: >>=20 >> I=92ve tried to do a thorough review of the mdns-dnssd-hybrid = document--sorry it=92s taken so long. >>=20 >> My general feeling about the document is that it=92s the wrong way to = solve the problem, but also the expedient way to solve the problem. So = I don=92t want to stand in the way of its publication, but there are = some things I=92d like to see done differently if it=92s possible. I am = not clear on exactly what has seen widespread implementation, so some of = my comments may require overcoming a lot of inertia, but I suspect not. >>=20 >> What I would really like to see in the long run is a clean DNS-based = solution with as much of the mDNS stuff hidden or eliminated as = possible. I do not know what the feeling of the working group is on = this--maybe I=92m out in left field and everybody else is happy with the = proposed model. But here=92s a high level summary of what I would = change: >>=20 >> First, the current document assumes that there is no mechanism for = statefully publishing information. This is not something that is, as = far as I know, a requirement--it's just a result of the approach that = the hybrid draft takes. >>=20 >> This approach has a couple of results. First, it means that you have = to name every link, because you have to have a delegation for every = link. This is just not going to work for homenet. Homenet users = won=92t necessarily be able to cognize the thing that the word =93link=94 = refers to, and won=92t be able to assign names to links, so the homenet = would have to generate names, and those names wouldn=92t make sense = either. So this model can=92t actually support a homenet in practice, = despite Markus and Steven's no doubt excellent proof-of-concept = implementation. >>=20 >> Unfortunately, the model as currently described doesn=92t offer a way = out of this. In principle, there=92s no reason that you can=92t have = an mDNS hybrid on every wire all of which update the same DNS primary, = and let services on the local wire that support DNS update as well as = mDNS do the update themselves, through the mDNS proxy so that off-link = attacks can be rejected. >>=20 >> You could just do mDNS only for publication, but my reason for not = wanting that is that ideally we=92d like to wean ourselves off of mDNS = to the extent possible--it doesn=92t scale, as this document says, and = some of the text in this document tries but IMHO fails to effectively = rate-limit it. This will be a particular problem if we expose the = DNSSD tree to off-site queries, which we would have to do to allow = legitimate off-site use of services: if you restrict queries to 20 per = second, it's not that hard to imagine running up against that limit in = practice when nobody's doing anything bad. This is particularly the = case because the link-naming strategy is going to tend to push sites to = use larger links than they might otherwise have done. >>=20 >> I think it may be possible to tweak this specification so that it = _allows_ for the DNS model I just described but doesn=92t require it. = Essentially whether you implement the hybrids as a cache or as a primary = name server and a bunch of secondaries that will relay updates from the = local network is an implementation choice, isn=92t it? But if we did = that, I think it would have to be the case that the whole section on = disallowing zone transfers goes away, since they could now be supported. >>=20 >> This is what I=92d like to see happen, but I will not be deeply = surprised if the working group throws rotten tomatoes at me for = proposing this now. That said, I=92m hoping Stuart will do me the = kindness of a sit-down this weekend or sometime on Monday before the = meeting to see if there=92s a middle ground to be reached. >>=20 >> The one thing that I=92m fairly sure could be done painlessly, and = that I think would make the document a lot less complicated and a lot = less difficult to explain, and would also simplify implementation, would = be to get rid of the two-subdomains hack. The point of this hack as = far as I can tell is to allow each wire to have a UI-presentable name. = But this is totally unnecessary--since the multilink DNSSD model is new, = why not just have a well-known name under the single per-link (or = whatever) subdomain that has a TXT record hanging off of it with the = presentation name for the subdomain? Then you can have a unified = domain with all the presentable and non-presentable names in it, and = bob=92s your uncle. This also saves you having to deal with the = A-label problem for link (or shall we say "zone"?) names. >>=20 >> E.g., using the example in 4.3, and assuming the WKN is _textname: >>=20 >> _textname.bldg1.example.com TXT =93Building 1=94 >> My Printer._ipp._tcp.bldg1.example.com. >> SRV 0 0 631 prnt.bldg1.example.com. >> prnt.bldg1.example.com. A 10.0.1.2 >>=20 >> On to more detailed comments: >>=20 >> The abstract is way too wordy. You=92re trying to explain to = someone who is searching why they should read the document, not explain = the entirety of what the document says. Suggestion: >>=20 >> This document describes a method for extending Multicast DNS Service >> Discovery so that it can support automatic service announcement >> and discovery across multiple links. This is accomplished using >> a hybrid DNS model, where services are discovered using Multicast >> DNS if required, and published using DNS if possible, and Multicast >> DNS otherwise. >>=20 >> The other text should be moved to the Introduction if it isn=92t = already there. >>=20 >> Document doesn=92t appear to talk about how resolution happens in a = homenet (which is sort of okay, since that the the HNSDA=92s job). = However, the text in 4.1p3 says that normal delegation is used, and that = won=92t work in a homenet that doesn=92t have a global name. It may be = worth clarifying this. Also, what if the reverse tree for IPv4 is some = kind of RFC1918 address space? Is the process of delegating this = address space discussed elsewhere in the document? >>=20 >> 4.2.1 seems to be recapitulating RFC 6763 section 11. Can this be = streamlined by simply referencing that section? >>=20 >> Regarding 4.2.2, what is the prevalence of DNSSD clients that only = support mDNS? That is, how badly would it suck to not provide = multicast browsing services? >>=20 >> Quoting: >> If a given link is using the IPv4 subnet 10.1/16, then the domain >> "1.10.in-addr.arpa" is delegated to the Hybrid Proxy for that link. >>=20 >> How is this accomplished? 10.in-addr.arpa is delegated to itself. = This section also does not mention how ULAs are supported, but it seems = like they should be. >>=20 >> I think the answer to this question is that the local caching = resolver that is returned by DHCP and ND should answer for all private = zones, either with information or with the appropriate error, so in = principle this is manageable, but of course not using DNSSEC. It = appears that the author agrees at least regarding suppression, and I = suspect also with the rest, but it should be stated explicitly in the = document, since what the document currently says isn=92t actually = possible. >>=20 >> This document doesn=92t make any reference to the idea of using DNS = update to publish DNSSD services, which is something that the original = DNSSD RFC does describe (although it doesn=92t explain it in detail). = I think this is an unfortunate omission, because it means that there is = no recommended path forward for fixing mdns=92 chattiness. >>=20 >> Is there any reason not to use TTL=3D0 for all DNS responses? >>=20 >> Another way to deal with embedded .local names would be to allow = resolution of .local names on other links if there is no conflict. = Arguably this is better than diving into TXT records, since in general = it should always work. Seems like Stuart=92s already thinking about = this. >>=20 >> I don=92t disagree with the use of LLQ as a way to improve UI = responsiveness, but I think that the concern about caching on an = institutional network is probably overblown. Would be interesting to = see real numbers. We care a lot about multicast; not so much about = unicast. >>=20 >> You shouldn=92t recapitulate the procedure for discovering push/LLQ = servers, and shouldn=92t reference LLQ unless you intend to publish it. = It=92s interesting historically, but is deader than a doornail, not work = =93in progress=94! >>=20 >> SOA increment could happen whenever the cache is changed as a result = of an update. You should definitely update the serial number at least = that often, don=92t use zero. >>=20 >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_52293C0A-493F-4970-A671-FA60C02AD5C7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJW/cmqAAoJEPk0GMVmUuYMBQoH/0NsSi6MAjF4rm7d1JubdJ3a CCeX99DGoSNXHP44rJnvW36I1LsFhYHVYxbaHZp8oUDqVl828G7YpNERdEakMXAr 1+SmZGOEjKXBlu2TEQkFvkD5YJ/WHZP6LKAKHjIrIp7arwcZ8uWwj3zYalz/jzzQ KIAVBr/iEtBfpep5XgwGOM/29smvCFU2wM1Hb+h8O+LEkjRmWePKPJXnOctozAw/ qggHfB9Xf82wuPEVBciaI4QyMKShmQHVpqo83VWJ4yi17HnGHFeCG7GBbyBTcjLP +aHm4iI0eYUDKTG8FWIBzGm18pYkVwFNtWrmQ2VMQfQJHXiFg1oR0yEKQKcoFT0= =9VUM -----END PGP SIGNATURE----- --Apple-Mail=_52293C0A-493F-4970-A671-FA60C02AD5C7-- From nobody Thu Mar 31 18:14:14 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43A712D91A for ; Thu, 31 Mar 2016 18:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWK9OaEpw7ki for ; Thu, 31 Mar 2016 18:14:12 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44AC612D112 for ; Thu, 31 Mar 2016 18:14:12 -0700 (PDT) Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 23F767400E6; Fri, 1 Apr 2016 01:14:12 +0000 (UTC) Received: from mbx-03.WIN.NOMINUM.COM ([169.254.4.19]) by CAS-04.WIN.NOMINUM.COM ([64.89.235.67]) with mapi id 14.03.0224.002; Thu, 31 Mar 2016 18:14:12 -0700 From: Ted Lemon To: Tom Pusateri Thread-Topic: [dnssd] Last call comments on draft-ietf-dnssd-hybrid-03 Thread-Index: AQHRi67RNg7IG9b6vUeHmOFOnsaIqZ90v+YAgAADnoD//4vuig== Date: Fri, 1 Apr 2016 01:14:11 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630797A43167@mbx-03.WIN.NOMINUM.COM> References: <8D23D4052ABE7A4490E77B1A012B630797A43137@mbx-03.WIN.NOMINUM.COM> , <383FF82C-98CA-4612-B355-FD02FDA962F3@bangj.com> In-Reply-To: <383FF82C-98CA-4612-B355-FD02FDA962F3@bangj.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [107.16.24.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dnssd@ietf.org" Subject: Re: [dnssd] Last call comments on draft-ietf-dnssd-hybrid-03 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 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, 01 Apr 2016 01:14:13 -0000 > That example would have made more sense if I had changed all the domain n= ames from hypd.info to foobar.com. No worries. However, I don't think this really helps. Yes, the host wil= l browse all those domains, but no, the user will still be confused, becaus= e the host will present a bunch of confusing _locations_ along with the nam= es. As far as the user is concerned there aren't a bunch of locations (pr= obably)--there's just one. And if there are multiple locations in the use= r's mental model of the network, you won't be able to say anything to them = that makes sense, because in that case half the links will be transit links= , or will all appear to the network to be in the same location (if they are= wired and go through a hub).