From nobody Fri Jul 4 10:05:16 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1608E1B2A81; Fri, 4 Jul 2014 10:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 75mgSAJDnYd5; Fri, 4 Jul 2014 10:05:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E40A11B29C0; Fri, 4 Jul 2014 10:05:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704170512.10433.4621.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 10:05:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/j03Gmc7PCQTnib7G2CJ6dL0hbJo Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-ietf-dnssd-requirements-03.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jul 2014 17:05:14 -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 Working Group of the IETF. Title : Requirements for Scalable DNS-SD/mDNS Extensions Authors : Kerry Lynn Stuart Cheshire Marc Blanchet Daniel Migault Filename : draft-ietf-dnssd-requirements-03.txt Pages : 12 Date : 2014-07-04 Abstract: DNS-SD/mDNS is widely used today for discovery and resolution of services and names on a local link, but there are use cases to extend DNS-SD/mDNS to enable service discovery beyond the local link. This document provides a problem statement and a list of requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnssd-requirements-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-requirements-03 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 Jul 7 02:46:44 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149A01B27FB for ; Mon, 7 Jul 2014 02:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 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, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=ham 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 pzEaFZBTfxJS for ; Mon, 7 Jul 2014 02:46:39 -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 B91AC1B27F6 for ; Mon, 7 Jul 2014 02:46:38 -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 s679kUUg021110; Mon, 7 Jul 2014 10:46:30 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s679kUUg021110 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1404726392; bh=NbNbCKD5Bq8y10mgnbcUJqEM8dw=; h=From:Date:Subject:To:Mime-Version:References; b=AP/gxbZySz9rzLTVHX7UG/N8Zcy8LKOqclV3LPwcVsAlHjXKoFxcBvPKjddFGeTZ/ nThHynWi4TeSCJpxaM/suY9hRTwTFYiAq6SY3Fins8V6BqRCxvokS982riL8m2vnZA 1ODlRb8zvtf6frnpZElHBSE1mwBSJhg7YsN7baWk= 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 q66AkU16224001106a ret-id none; Mon, 07 Jul 2014 10:46:32 +0100 Received: from [IPv6:2001:630:d0:ed04:99a3:a1f8:a4c7:7e05] ([IPv6:2001:630:d0:ed04:99a3:a1f8:a4c7:7e05]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s679kTQ9029446 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Jul 2014 10:46:29 +0100 From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_11589503-505A-4F33-8240-164878B31613" Date: Mon, 7 Jul 2014 10:46:29 +0100 To: dnssd@ietf.org Message-ID: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-smtpf-Report: sid=q66AkU162240011000; tid=q66AkU16224001106a; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 References: <10DC3A23-5ABF-4D01-97AE-17C5E488F664@ecs.soton.ac.uk> X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s679kUUg021110 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/p0sYgQZBmj9XTK1BMJ6gp_f877Q Subject: [dnssd] WGLC for draft-ietf-dnssd-requirements-03 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jul 2014 09:46:42 -0000 --Apple-Mail=_11589503-505A-4F33-8240-164878B31613 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, This email begins a two week WGLC on draft-ietf-dnssd-requirements-03, = "Requirements for Scalable DNS-SD/mDNS Extensions=94. Ralph and I as chairs believe the authors have addressed the issues = raised at IETF89 and on the list since.=20 You can see the draft here: http://tools.ietf.org/html/draft-ietf-dnssd-requirements-03 Please send your comments or feedback to the list. The WGLC ends on Monday 21st July. We will discuss/consider the result of the WGLC at the dnssd session at = IETF90 in Toronto, which is scheduled for 3.20pm on Thursday 24th July. Tim --Apple-Mail=_11589503-505A-4F33-8240-164878B31613 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi,

This email begins a two week = WGLC on draft-ietf-dnssd-requirements-03, "Requirements for = Scalable DNS-SD/mDNS Extensions=94.

Ralph and I as chairs believe the authors = have addressed the issues raised at IETF89 and on the list = since. 

You can see the draft here:

Please send your comments or feedback to = the list.

The WGLC ends on Monday 21st = July.

We will discuss/consider the result of the = WGLC at the dnssd session at IETF90 in Toronto, which is scheduled for = 3.20pm on Thursday 24th July.

Tim

= --Apple-Mail=_11589503-505A-4F33-8240-164878B31613-- From nobody Mon Jul 7 17:47:10 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264F71B29A1 for ; Mon, 7 Jul 2014 17:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 szCqINeyt6NP for ; Mon, 7 Jul 2014 17:47:07 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154F81B29A2 for ; Mon, 7 Jul 2014 17:47:07 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id rd3so6345755pab.3 for ; Mon, 07 Jul 2014 17:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=/s8IiHHWTp461L1HuJJo9fmMtCMVR1sTdUlR2+DY5YU=; b=iOxFW1e95IvRDw7IdxaOczgvgKbOMYbOo990WU0ez13QU7qqg9Im7KoL9bNccOc4CQ id8v/Q2UmbsWf0LjqZEtNGwcFhed8msBpqEmhD3FpmWzVCfDro1no6DorhCVzmAxeZ2v LP40AE2i6J9QASQZ2wB/I7bd8rbUFbMFMJLgHRGml83JtovrFG/pC46/WRgkN5jVacgM gy6JnJ8EPgB0dn3LUdwY0bxScgCnYaNzDinXlt4+/nLrlQ3HtEoks8KQ/OOAYFrPF3Rm f/hB1mtU3hBusvsL2tWWY5J1/743YMccCluNiBESxQ9yCU2cpnKpbvaeo1rgBI6D6mLf Rh9A== X-Received: by 10.66.102.102 with SMTP id fn6mr32434958pab.6.1404780425675; Mon, 07 Jul 2014 17:47:05 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id qm11sm21954075pdb.85.2014.07.07.17.47.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 17:47:04 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_BFA8E516-857E-471D-BCAE-1509541A40FF" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: Date: Mon, 7 Jul 2014 17:47:02 -0700 Message-Id: <0022F0DD-AEC8-4222-8F74-E38399B6B02D@gmail.com> References: <10DC3A23-5ABF-4D01-97AE-17C5E488F664@ecs.soton.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/fNbNBsA_VJnOq8Wm1HyAoMgT5eQ Cc: dnssd@ietf.org Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-requirements-03 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jul 2014 00:47:10 -0000 --Apple-Mail=_BFA8E516-857E-471D-BCAE-1509541A40FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 7, 2014, at 2:46 AM, Tim Chown wrote: > Hi, >=20 > This email begins a two week WGLC on draft-ietf-dnssd-requirements-03, = "Requirements for Scalable DNS-SD/mDNS Extensions=94. >=20 > Ralph and I as chairs believe the authors have addressed the issues = raised at IETF89 and on the list since.=20 >=20 > You can see the draft here: > http://tools.ietf.org/html/draft-ietf-dnssd-requirements-03 Dear dnssd-wg, 1) Layer 2 solutions intentionally ignored. One of the primary goals for extending mDNS per the Educause petition = was to enable access to remote displays. Unfortunately, layer 3 routing = is generally prohibited with unlicensed nodes in conveyance of copyright = media. While layer 2 solutions are able to overcome multi-bridge = limitations imposed by media compliance requirements, this has been = ignored by the Scalable DNS-SD/mDNS requirements documentation to the = point of being ruled out-of-scope for discussion because of an assumed = need for layer 3 only solutions. Nevertheless, layer 3 solutions are = normally precluded when not licensed as a means to ensure constraint of = media redistribution. A quandary that could have been avoided by = determining common strategies that could be used by either layer 2 or 3. = For example, many routers are able to handle GUA+ULA. Layer 3 and 2 = might be considered analogous when ULAs are mapped to MACs.=20 2) Many devices within a typical network may announce routable addresses = via mDNS but are nevertheless unable to authenticate the access = permitted when these mDNS resources are conveyed in DNS. ,-- The following is a summary of the technical requirements: ... o It must be cost-effective to manage at up to enterprise scale. '-- Being unable to differentiate locality for those devices unable to = handle Internet originating sessions, as in the printer example, means = the Scalable DNS-SD/mDNS extension is NOT manageable at any scale. Since different network realms are expected to permit device access = behind different bridges based on their "routable" mDNS resources = published in DNS, this circumvents a strategy of differentiating local = origination. This becomes particularly problematic when different IPv6 = prefixes are dynamically in use. In the Security Consideration Section, the union of DNS-SD and mDNS = would be zero since DNS-SD claims it to be a data structure creating no = security concerns. The union of zero with anything is zero. Does REQ6 have priority over that of REQ14? ,-- REQ6: SSD must not adversely affect or break any other current protocols or deployments. '-- ,-- REQ14: SSD should operate over existing networks (as described by use cases A-F above) without requiring changes to the network technology or deployment. '-- mDNS is restricted to a single link. The envisioned multi-link = configuration affects the discovery and scope of the related services = which may break current protocols and/or substantially increase their = vulnerabilities. 6.4. Authentication ... was: ,-- If there is a risk that clients may be fooled by the deployment of rogue services, then application layer authentication should be considered as part of any security solution. Authentication of any particular service is outside the scope of this document. '-- should be: ,-- When there is risk that either clients or devices may be spoofed by malefactors, then a network overlay or application layer=20 authentication strategy should be considered. Authentication of or by any particular service is outside the scope of this document. '-- For example, it is not practical to expect a printer will ever be able = to authenticate a client. An overlay network can consist of GUA+ULA without change to network = technology or deployment. ULAs can limit access to trusted users having = immediate access to the local network realms. ULAs also avoid DNS = deployment that attempt to merge local with global using complex and = risky split-horizon configurations. ULAs already serve as the basis for = BTMM configurations which avoids publishing resources for devices like = printers unable to authenticate an external session. For additional references see: http://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-04 Regards, Douglas Otis =20 --Apple-Mail=_BFA8E516-857E-471D-BCAE-1509541A40FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jul 7, 2014, at 2:46 AM, Tim Chown = <tjc@ecs.soton.ac.uk> = wrote:

Hi,

This email begins a two week = WGLC on draft-ietf-dnssd-requirements-03, "Requirements for = Scalable DNS-SD/mDNS Extensions=94.

Ralph and I as chairs believe the authors = have addressed the issues raised at IETF89 and on the list = since. 

You can see the draft here:

Dear = dnssd-wg,

1) Layer 2 solutions intentionally = ignored.

One of the primary goals for extending = mDNS per the Educause petition was to enable access to remote displays. =  Unfortunately, layer 3 routing is generally prohibited with = unlicensed nodes in conveyance of copyright media.  While layer 2 = solutions are able to overcome multi-bridge limitations imposed by media = compliance requirements, this has been ignored by the Scalable = DNS-SD/mDNS requirements documentation to the point of being ruled = out-of-scope for discussion because of an assumed need for layer 3 only = solutions.  Nevertheless, layer 3 solutions are normally precluded = when not licensed as a means to ensure constraint of media = redistribution.  A quandary that could have been avoided by = determining common strategies that could be used by either layer 2 or 3. =  For example, many routers are able to handle GUA+ULA.  Layer = 3 and 2 might be considered analogous when ULAs are mapped to = MACs. 

2) Many devices within a typical = network may announce routable addresses via mDNS but are nevertheless = unable to authenticate the access permitted when these mDNS resources = are conveyed in DNS.
,--
The following is a summary of the = technical requirements:
...
o  It must be cost-effective to = manage at up to enterprise scale.
'--

Being unable to = differentiate locality for those devices unable to handle Internet = originating sessions, as in the printer example, means the Scalable = DNS-SD/mDNS extension is NOT manageable at any = scale.

Since different network realms are = expected to permit device access behind different bridges based on their = "routable" mDNS resources published in DNS, this circumvents a strategy = of differentiating local origination.  This becomes particularly = problematic when different IPv6 prefixes are dynamically in = use.

In the Security Consideration Section, the = union of DNS-SD and mDNS would be zero since DNS-SD claims it to be a = data structure creating no security concerns.  The union of zero = with anything is zero.

Does REQ6 have priority = over that of REQ14?
,--
REQ6:   SSD must = not adversely affect or break any other current
    =        protocols or = deployments.
'--
,--
REQ14:  SSD should = operate over existing networks (as described by
    =        use cases A-F above) without requiring = changes to the network
          =  technology or deployment.
'--

mDNS is = restricted to a single link.  The envisioned multi-link = configuration affects the discovery and scope of the related services = which may break current protocols and/or substantially increase their = vulnerabilities.


6.4. =  Authentication
...
was:
,--
=
If there is a risk that clients may be fooled by the deployment = of
rogue services, then application layer authentication = should be
considered as part of any security solution. =  Authentication of any
particular service is outside the = scope of this = document.
'--

should = be:
,--
When there is risk that either clients = or devices may be spoofed
by malefactors, then a network = overlay or application layer 
authentication strategy = should be considered. Authentication of
or by any particular = service is outside the scope of this = document.
'--

For example, it = is not practical to expect a printer will ever be able to authenticate a = client.

An overlay network can consist of = GUA+ULA without change to network technology or deployment.  ULAs = can limit access to trusted users having immediate access to the local = network realms.  ULAs also avoid DNS deployment that attempt to = merge local with global using complex and risky split-horizon = configurations.  ULAs already serve as the basis for BTMM = configurations which avoids publishing resources for devices like = printers unable to authenticate an external = session.

For additional references = see:

Regards,
Douglas = Otis









 




= --Apple-Mail=_BFA8E516-857E-471D-BCAE-1509541A40FF-- From nobody Wed Jul 9 06:54:45 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F841A0A86 for ; Wed, 9 Jul 2014 06:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 sS4FUe8IZTRB for ; Wed, 9 Jul 2014 06:54:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A9421A0233 for ; Wed, 9 Jul 2014 06:54:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJU27532; Wed, 09 Jul 2014 13:54:30 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id 14.03.0158.001; Wed, 9 Jul 2014 14:54:25 +0100 From: Hosnieh Rafiee To: "dnssd@ietf.org" Thread-Topic: New version of Threat Model Thread-Index: Ac+bfUopwQ3ZrF6FR1S11dk1jd7Pxg== Date: Wed, 9 Jul 2014 13:54:23 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A0D165@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/nyfCJQgI6d5YeYSPLqu-PG92Sng Subject: [dnssd] New version of Threat Model X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jul 2014 13:54:40 -0000 Folks, Unfortunately I didn't have a chance to upload this version before deadline= . This is why I share it again on the following link until the IETF servers= are open again and accepts upload There one important question that I also raised it offlist to the chairs - Do we want to have a separate document for Threat model and solutions or = you plan to merge this document to Requirement document? I have not received any serious request for helping to improve this documen= t. The two that asked me off-list and I gave them access did not really con= tribute. If anybody would like to be a co-author or contribute, please contact me. I also read the requirement document and I think only we need to be careful= with the edge devices and how to filter mDNS/DNS-SD messages to avoid prop= agating these messages over the enterprise networks and to the internet! Thank you, Best, Hosnieh From nobody Wed Jul 9 15:22:20 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01C11A0109 for ; Wed, 9 Jul 2014 15:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 UPzjqkBOcfDx for ; Wed, 9 Jul 2014 15:22:11 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 992161A0065 for ; Wed, 9 Jul 2014 15:22:11 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id eu11so9891170pac.19 for ; Wed, 09 Jul 2014 15:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jE/wW9oyeT30gdoR/NxqPMJVhI2uzbHvvMYbU34guGg=; b=nvL3RVkyaMrb4Pq48zWnNU1CAe642IsYQPkyFBJEvohYqo4bCBe/2mMJzpeclSmgyX xhAqLQwbcbcU2QgZq57btIYPYDXckPXq/btJp3swPjipZL1etXp8haw+K+ncqvhiop21 FXNqbFB0y7bsxBSsSMh9E6fVOry3QwcosLoB2F65SiH8vz8KzASOxmw7nCks/lNlqsW6 AKuFFmbbEYK+Ry/nBTuk+vS6GbxtILPkj11YIpgH2Lgr8ZIkpU+MIMYEKnbqwV8bndjW KAVmVqiqWa8kg0BvCEOc2eZNJkzry5sp7crcR7zqWpzbIiSKDeZlEF75gcARUYr4EcjA RNJw== X-Received: by 10.70.38.1 with SMTP id c1mr13522738pdk.108.1404944531306; Wed, 09 Jul 2014 15:22:11 -0700 (PDT) Received: from ?IPv6:2601:9:7300:1510:d57b:5816:46c0:de58? ([2601:9:7300:1510:d57b:5816:46c0:de58]) by mx.google.com with ESMTPSA id nw13sm220163670pab.37.2014.07.09.15.22.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 15:22:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A0D165@lhreml513-mbb.china.huawei.com> Date: Wed, 9 Jul 2014 15:22:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3CB835F8-DE4C-4A35-B730-F9FEBF3876C9@gmail.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A0D165@lhreml513-mbb.china.huawei.com> To: Hosnieh Rafiee X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/uzocWczZ4qUYAmVfjfVzyg_TzCE Cc: "dnssd@ietf.org" , Douglas Otis Subject: Re: [dnssd] New version of Threat Model X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jul 2014 22:22:17 -0000 On Jul 9, 2014, at 6:54 AM, Hosnieh Rafiee = wrote: > Folks, >=20 > Unfortunately I didn't have a chance to upload this version before = deadline. This is why I share it again on the following link until the = IETF servers are open again and accepts upload >=20 > >=20 > There one important question that I also raised it offlist to the = chairs > - Do we want to have a separate document for Threat model and = solutions or you plan to merge this document to Requirement document? >=20 > I have not received any serious request for helping to improve this = document. The two that asked me off-list and I gave them access did not = really contribute. > If anybody would like to be a co-author or contribute, please contact = me. >=20 > I also read the requirement document and I think only we need to be = careful with the edge devices and how to filter mDNS/DNS-SD messages to = avoid propagating these messages over the enterprise networks and to the = internet! Dear Hosnieh, In general, you raise valid concerns. Use of DNS-SD to merge isolated = links expects layer 3 routing while permitting use of multiple prefixes. = Routable rather than link-local addresses is to be used in support of = the currently defined hybrid scheme. While I would like to collaborate, = your review still misses the fundamental threats created by the hybrid = scheme beyond those where internal spoofing occurs. The basis for mDNS = is to leverage the relative security of restricted access to local-link = where control of hosted systems are assumed. Some suggest a = split-horizon DNS configuration can secure information contained that = can otherwise permit malefactors direct access from the Internet. By = ignoring a ULA overlay, this prevents a means to algorithmically confirm = source locality. As such simply securing a printer remains impractical. = Issues you raise seems to be of a secondary concern. Regards, Douglas Otis From aaggarwa@qce.qualcomm.com Wed Jul 9 14:02:49 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D771B27A9 for ; Wed, 9 Jul 2014 14:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 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, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 8Q8X4wPtjZ4E for ; Wed, 9 Jul 2014 14:02:48 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9F01A0007 for ; Wed, 9 Jul 2014 14:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qce.qualcomm.com; i=@qce.qualcomm.com; q=dns/txt; s=qcdkim; t=1404939769; x=1436475769; h=from:to:cc:subject:date:message-id:mime-version; bh=0bGMt74Ysn0D1M88y4IsLCCsox8YGTVGhQ9YnE0v17c=; b=QMEqcGUwyihqUIfTbFzlGR2thkujSOMLNl5cdNd6CGJc/6rDCMkFX3Zb TCji8tnbA8H1RHr12+CN8xSNMKyALT39anyfU/52VIjuPejd0N48hg2EI q+VKDfCNMoLV1r6aVyUyub0/QrrqkJTmgOOHv/gEDjoQGvZXRS9lxR/tT k=; X-IronPort-AV: E=McAfee;i="5600,1067,7494"; a="69363866" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP; 09 Jul 2014 14:02:49 -0700 X-IronPort-AV: E=Sophos;i="5.01,633,1400050800"; d="scan'208,217";a="763990882" Received: from nasanexhc11.na.qualcomm.com ([172.30.39.6]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 09 Jul 2014 14:02:47 -0700 Received: from NASANEXD02B.na.qualcomm.com ([169.254.2.249]) by nasanexhc11.na.qualcomm.com ([172.30.39.6]) with mapi id 14.03.0181.006; Wed, 9 Jul 2014 14:02:47 -0700 From: "Aggarwal, Ashutosh" To: "dnssd@ietf.org" Thread-Topic: LF comments on a new document Thread-Index: Ac+buSKBjw6KylVcT8y7xxWlLWNetg== Date: Wed, 9 Jul 2014 21:02:46 +0000 Message-ID: <4ADFCA4A44B18946883BA96F64773E0150E101EB@NASANEXD02B.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.230.6] Content-Type: multipart/alternative; boundary="_000_4ADFCA4A44B18946883BA96F64773E0150E101EBNASANEXD02Bnaqu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/5ntLPMrLVvgT4YJe6M1kKO4Cj4A X-Mailman-Approved-At: Thu, 10 Jul 2014 03:59:46 -0700 Cc: "Resnick, Pete" Subject: [dnssd] LF comments on a new document X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jul 2014 21:06:06 -0000 --_000_4ADFCA4A44B18946883BA96F64773E0150E101EBNASANEXD02Bnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear members, I have submitted a new draft document proposing an optimization to the DNS-= SD query mechanism to make it more scalable. I have been in discussions wit= h Dave Thaler during the formulation of the draft and would like to request= for comments from the community. Abstract: DNS-SD allows a client to find a list of named instances of a service name over a particular transport within a domain of interest using standard DNS queries. As the number of potential responders increases, DNS-SD based discovery doesn't scale well. To mitigate the scaling issues, schemes to narrow down the search context would be needed. The document proposes to include key/value pairs in the form of a DNS TXT record along with the service name in the DNS query to assist with the discovery process. The DNS TXT record can be placed in the additional section of the query without requiring any changes to the structure of DNS messages. Link to the document: http://datatracker.ietf.org/doc/draft-aggarwal-dnssd-optimize-query/ Thanks, Ashutosh --_000_4ADFCA4A44B18946883BA96F64773E0150E101EBNASANEXD02Bnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear members,

 

I have submitted a new draft document proposing an o= ptimization to the DNS-SD query mechanism to make it more scalable. I have = been in discussions with Dave Thaler during the formulation of the draft an= d would like to request for comments from the community.

 

Abstract:

DNS-SD allows a client to find a list of named insta= nces of a service

 name over a particular transport within a doma= in of interest using

 standard DNS queries.  As the number of p= otential responders

 increases, DNS-SD based discovery doesn't scal= e well.  To mitigate

 the scaling issues, schemes to narrow down the= search context would

 be needed.  The document proposes to incl= ude key/value pairs in the

 form of a DNS TXT record along with the servic= e name in the DNS query

 to assist with the discovery process.  Th= e DNS TXT record can be

 placed in the additional section of the query = without requiring any

 changes to the structure of DNS messages.=

 

Link to the document:

http://datatracker.ietf.org/doc/draft-aggarwal= -dnssd-optimize-query/

 

Thanks,

Ashutosh

 

--_000_4ADFCA4A44B18946883BA96F64773E0150E101EBNASANEXD02Bnaqu_-- From nobody Mon Jul 14 19:57:27 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0FE1B2803 for ; Mon, 14 Jul 2014 19:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 9pKPNwk7Q2bZ for ; Mon, 14 Jul 2014 19:57:23 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 9517E1B2802 for ; Mon, 14 Jul 2014 19:57:21 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: dengguangqing@cnnic.cn Received: from unknown127.0.0.1 (HELO user-think) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 15 Jul 2014 10:57:17 +0800 Date: Tue, 15 Jul 2014 10:57:10 +0800 From: "Guangqing Deng" To: =?utf-8?B?QWdnYXJ3YWwsIEFzaHV0b3No?= References: <4ADFCA4A44B18946883BA96F64773E0150E101EB@NASANEXD02B.na.qualcomm.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 140[cn] Mime-Version: 1.0 Message-ID: <201407151057089455024@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart371562627105_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/MX6fQgs3TVVTSR-Zk4NZDq7Op8Q Cc: dnssd Subject: Re: [dnssd] LF comments on a new document X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jul 2014 02:57:25 -0000 This is a multi-part message in MIME format. ------=_001_NextPart371562627105_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2luY2UgdGhlIG51bWJlciBvZiBzbyBjYWxsZWQga2V5L3ZhbHVlcyBtYXkgYmUgdmVyeSBsYXJn ZSBhbmQgbm90IGFsbCBvZiB0aGVtIGNvbnRhaW4gcmljaCBpbmZvcm1hdGlvbiBmb3IgbmFycm93 aW5nIGRvd24gc2VhcmNoIGNvbnRleHQsIGl0IHNlZW1zIHRoYXQgd2Ugc2hvdWxkIGZ1cnRoZXIg c3BlY2lmeSB3aGljaCBrZXkvdmFsdWVzIGFyZSBtYW5kYXRvcnkgYW5kIHdoaWNoIGFyZSBqdXN0 IG9wdGlvbmFsLg0KIA0KDQoNCkd1YW5ncWluZyBEZW5nDQpDTk5JQyANCiANCkZyb206IEFnZ2Fy d2FsLCBBc2h1dG9zaA0KRGF0ZTogMjAxNC0wNy0xMCAwNTowMg0KVG86IGRuc3NkQGlldGYub3Jn DQpDQzogUmVzbmljaywgUGV0ZQ0KU3ViamVjdDogW2Ruc3NkXSBMRiBjb21tZW50cyBvbiBhIG5l dyBkb2N1bWVudA0KRGVhciBtZW1iZXJzLA0KIA0KSSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBkcmFm dCBkb2N1bWVudCBwcm9wb3NpbmcgYW4gb3B0aW1pemF0aW9uIHRvIHRoZSBETlMtU0QgcXVlcnkg bWVjaGFuaXNtIHRvIG1ha2UgaXQgbW9yZSBzY2FsYWJsZS4gSSBoYXZlIGJlZW4gaW4gZGlzY3Vz c2lvbnMgd2l0aCBEYXZlIFRoYWxlciBkdXJpbmcgdGhlIGZvcm11bGF0aW9uIG9mIHRoZSBkcmFm dCBhbmQgd291bGQgbGlrZSB0byByZXF1ZXN0IGZvciBjb21tZW50cyBmcm9tIHRoZSBjb21tdW5p dHkuDQogDQpBYnN0cmFjdDoNCkROUy1TRCBhbGxvd3MgYSBjbGllbnQgdG8gZmluZCBhIGxpc3Qg b2YgbmFtZWQgaW5zdGFuY2VzIG9mIGEgc2VydmljZQ0KIG5hbWUgb3ZlciBhIHBhcnRpY3VsYXIg dHJhbnNwb3J0IHdpdGhpbiBhIGRvbWFpbiBvZiBpbnRlcmVzdCB1c2luZw0KIHN0YW5kYXJkIERO UyBxdWVyaWVzLiAgQXMgdGhlIG51bWJlciBvZiBwb3RlbnRpYWwgcmVzcG9uZGVycw0KIGluY3Jl YXNlcywgRE5TLVNEIGJhc2VkIGRpc2NvdmVyeSBkb2Vzbid0IHNjYWxlIHdlbGwuICBUbyBtaXRp Z2F0ZQ0KIHRoZSBzY2FsaW5nIGlzc3Vlcywgc2NoZW1lcyB0byBuYXJyb3cgZG93biB0aGUgc2Vh cmNoIGNvbnRleHQgd291bGQNCiBiZSBuZWVkZWQuICBUaGUgZG9jdW1lbnQgcHJvcG9zZXMgdG8g aW5jbHVkZSBrZXkvdmFsdWUgcGFpcnMgaW4gdGhlDQogZm9ybSBvZiBhIEROUyBUWFQgcmVjb3Jk IGFsb25nIHdpdGggdGhlIHNlcnZpY2UgbmFtZSBpbiB0aGUgRE5TIHF1ZXJ5DQogdG8gYXNzaXN0 IHdpdGggdGhlIGRpc2NvdmVyeSBwcm9jZXNzLiAgVGhlIEROUyBUWFQgcmVjb3JkIGNhbiBiZQ0K IHBsYWNlZCBpbiB0aGUgYWRkaXRpb25hbCBzZWN0aW9uIG9mIHRoZSBxdWVyeSB3aXRob3V0IHJl cXVpcmluZyBhbnkNCiBjaGFuZ2VzIHRvIHRoZSBzdHJ1Y3R1cmUgb2YgRE5TIG1lc3NhZ2VzLg0K IA0KTGluayB0byB0aGUgZG9jdW1lbnQ6DQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWFnZ2Fyd2FsLWRuc3NkLW9wdGltaXplLXF1ZXJ5Lw0KIA0KVGhhbmtzLA0KQXNodXRv c2gNCiANCg== ------=_001_NextPart371562627105_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A=0A= =0A
Since the number of so called key/values may be very large and not all= of them contain rich information for narrowing down search context, it se= ems that we should further specify which key/values are mandatory and whic= h are just optional.
=0A
 
=0A
=0A
=0A
Guangqing =0ADeng=0A
CNNIC 
&nbs= p;
Date: 2014-07-10 05:= 02
Subject: [dnssd] LF comments on a new document
=0A

In offline email that Kerry Lynn and I exchanged, = I sent what I wrote up some

time ago about what I believe applications want = from service discovery in

general, based on experience and customer feedback = over the past two

decades, to provide additional context/input for = the dnssd requirements

discussion.  He then recommended I also send = it to the list, so here it is.

If folks think it would be useful in I-D format, I = could do that.


Thanks = for this Dave, it=92s a useful perspective on the work in hand. =  

Some initial comments = below.

1      = Introduction

=93Service = Discovery=94 encompasses discovery of various types of services, such = as  devices, servers, application instances, etc.   All = of these have some common aspects, including:

1)      Three levels of identifiers:

a.     &= nbsp; A =93service=94 (e.g.., a type of device, server, or = application) to discover instances of.

b.      = A particular =93instance=94 of a service running on a specific = network node, potentially reachable via multiple endpoints.  There = can be multiple instances per service.

c.     &= nbsp; A particular endpoint (e.g., IP address + port) at which an = instance can be reached.  There might be multiple endpoints (e.g., = IPv4 and IPv6) per = instance.


Agreed, and useful to = differentiate.

2)      The following are some typical application = operations:

a.     &= nbsp; Enumerate all instances with minimal delay, and be = immediately notified of changes.

b.      = Get additional properties of a given instance (e.g., whether a = printer supports color).

c.     &= nbsp; Reconnect to a given instance, even if the endpoint has = changed.

The existing requirements draft doesn=92t talk about specifics of = what may be discovered, rather the characteristics of how an extended = multi-link protocol should operate. But from the application = perspective, these are very valid points.

3)      Multiple zones of interest (sometimes called =93scopes=94) within = which to do discovery, such as: Local subnet, Physical proximity, = Services the user has used before, Organization-specific, = etc.    =

Or =93my home=94 (whether I=92m in it or not), = etc...

4)      The following characteristics are important in how results are = ordered/used.   The relative order of importance of the = characteristics is often a choice made by a user or application = developer.

a.     &= nbsp; Features: an instance that supports a particular feature = (e.g., color) may be more useful than one that does = not.

b.      = Live-ness: a currently reachable instance is typically more = useful than an unreachable one.

c.     &= nbsp; Proximity: an instance nearby is typically more useful than = one farther = away.


So a couple of things = here.

One is following the =91stale information = does not persist=92 principle, unreachable information should not be = retained.

Another is that we should probably = distinguish discoverable (that the service is there) from reachable = (e.g. it=92s not firewalled from where I am) from usable (I can = access/authenticate and use). 

2      = Background

There are a = number of key issues today that need to be addressed.

Guest access: An increasingly common scenario is that of guest = access, both within homes as well as within business = environments.   This makes the concept of zones of interest = more complicated.   Guests might or might not be permitted to = discover and access a home printer for example, so might require a separate zone of = interest for discovery.   Often guest access is implemented as = a separate local subnet, which leads to the next = problem.

In the homenet model, there are =91realms=92 and borders, and = there=92s an assumption of default policies being applied at borders, = which may be overridden.

But there may be a = =91zone of interest=92 of =91devices in my home that a guest can use=92, = wherever they happen to be topologically.

Multiple subnets: Many service discovery mechanisms today are = designed for =93local subnet=94 being the zone of interest.   = However local subnet is not a user-visible concept and is becoming more = and more at odds (e.g., due to guest access, mobile broadband, etc.) with typical consumer scenarios such as =93within my = house=94.   That is, users care more about tangible Physical = Proximity than a nebulous =93local subnet=94 they don=92t = understand.   This makes link-scoped multicast solutions a = poor match for such = scenarios.

Indeed. 

Efficient filtering: In many scenarios a client has a set of = specific properties with which it wants to constrain the answers, such = as only discovering color printers that can print = double-sided.   This can be implemented by using a simple = query to enumerate all service instances, getting the properties of them, and then = filtering the results, OR by a complex query to enumerate all service = instances that fit the criteria.   Although the latter would = be more efficient, the complexity proved to be a problem and as a result the widely deployed protocols all use fairly simple = queries.   The filtering is thus typically done by an API = layer on top of the protocol, allowing applications to submit complex = queries while using simple protocol queries = underneath.

I believe this issue is the subject of tomorrow=92s TXT = discussion, see http://tools.ietf.org/html/draft-aggarwal-dnssd-optimize-query-00.

Power-efficiency: Power conservation is becoming increasingly = important.   With this trend comes the need to support = discovery of services that are in a low-power state.   This = requires either offload support in the network adapters at the service = instances (as is available in some cases for mDNS for example), or a directory in = another server.

Live-ness detection: Determining live-ness of a service instance = can be an issue when using a directory in another server, or when the = zone of interest is =93Services the user has used before=94 for = instance.   Increasingly there are cases where it is expensive to determine whether a device is online or offline (e.g., if it went = into a low power mode).  Furthermore, live-ness of a service is = different from live-ness of the device hosting the service.   = For example, the printer may be reachable but if it is jammed, it is less live than one in the ready-to-print state.  Another = aspect of liveness is notification of changes when a device becomes = online or offline while a client is in a user experience showing the = available instances from which to = choose.

Agreed, and your pointer to DNS LLQ at IETF89 was very useful in = this regard.

Managed environments: Managed environments use various types of = directories (e.g., DNS servers, LDAP servers, etc.) for service = discovery. Updating such directories requires certain privileges = however, which may not be available to all services.  For example, in many networks, DNS updates are only permitted from DHCP = servers.  Such permission constraints present obstacles to = discovering unmanaged device and application instances.

3      = Requirements

=

#

Requiremen= t

1

An app can = enumerate available zones of interest

2

An app can = discover instances of a given service within a specified zone of = interest

3

An app can = determine whether an enumerated service instance is = online

4

An app can = be notified whenever a service instance is added or removed

5

An app can = advertise a service instance within a specified zone of = interest

6

Advertised = endpoints match the endpoints actually being listened on

7

Support = zones of interest that may be larger than single subnet but smaller than = =93everything=94

8

Identify a = service instance in a way that is not tied to any endpoint so that if it = is discovered multiple times with different endpoints (such as in two = zones of interest at the same time), the app can tell they are the same service = instance

9

Enumeration = must include service instances that could be in a low power = state

10

Discovery = should require zero configuration by a human on an unmanaged = device

11

Support = zero configuration for advertisement on unmanaged = networks
So it would be interesting to map these to REQs in the existing = requirements text - are there any explicit and important gaps to = catch?

The = following are NOT requirements.

=B7     &= nbsp;   It is not required that one be able to advertise within any = arbitrary zone of interest an instance that has no trust = relationship. 

=B7     &= nbsp;   It is not required that enumeration only return a set of online = instances.  It is acceptable to return some offline instances as = long as there is a way to determine whether an enumerated instance is = online.  This is consistent with the fact that an instance may change its online/offline state at any time, such as immediately = after being = enumerated.


The existing requirements draft is more focused = on the networking aspects of scalability. So, given this is a nice = initial stab at an application perspective on SSD, I personally think it = would be worth capturing it in an I-D (whether we then move to publish = it or not) and pushing it towards application area people for = comment.

Tim
= --Apple-Mail=_5C14BF11-0AA8-4918-90ED-1FFD290C7699-- From nobody Wed Jul 23 12:39:13 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9BFD1A014F for ; Wed, 23 Jul 2014 12:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.301 X-Spam-Level: X-Spam-Status: No, score=-104.301 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_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 x1AAJ6pie5sH for ; Wed, 23 Jul 2014 12:39:08 -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 010701A01D6 for ; Wed, 23 Jul 2014 12:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1406144347; x=2270057947; 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=DmZd4J4y2XqW4hjhb83BjFRX8vbt48BALEvfgz8+ZBY=; b=2OQTpmi9QatBx+jUIn/gPeBuicHLiACvgq5qbfsZ1pAghjVjqsGoyMNKvblczPzR jPuLHA1/gu6jfVfWRZ8tCpnye/0xxqw9tcrGLt69PghVOv7tMADcq3aLA/5NGV6c ionz/+0KvVsDQ/IG/0v+sekaaZb3D7oS0jRYLHDQPhjFKnI/d86Ksgf3J1HBpxBY PCzw04whi0zJb7b5htZ7Lno77kt9xVwgav3ZKZX8DdScHbbXrYhfyXG7EfX8TwCM +62UN12IzMFS4oRnyTITICLcTijEv6ztb7TrFvYk1j4ZMKfNmVT+ajnosYdxS3yU LYRKMpzsPHZgmxmFd7n8nA==; Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 07.30.32596.B5F00D35; Wed, 23 Jul 2014 12:39:07 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_37cz0znDy5hx6N+oJ48vqg)" Received: from relay8.apple.com ([17.128.113.102]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N9600DVFJX1LUF0@local.mail-out.apple.com> for dnssd@ietf.org; Wed, 23 Jul 2014 12:39:07 -0700 (PDT) X-AuditID: 11973e15-f79d66d000007f54-7b-53d00f5b3b49 Received: from russet (russet.apple.com [17.171.2.67]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id F5.79.11638.B5F00D35; Wed, 23 Jul 2014 12:39:07 -0700 (PDT) Received: from dhcp-a58b.meeting.ietf.org ([31.133.165.139]) by russet.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0N96003YKJX5XE20@russet.apple.com> for dnssd@ietf.org; Wed, 23 Jul 2014 12:39:06 -0700 (PDT) From: Stuart Cheshire Message-id: <86ECD248-6479-42B8-80C6-9657D51449DA@apple.com> Date: Wed, 23 Jul 2014 12:39:04 -0700 To: "dnssd@ietf.org" X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUiON3OSDea/0KwweVTshbvl85idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRvvSU0wFVycwViyfLd3AuKOui5GTQ0LAROLRqjVsELaYxIV7 64FsLg4hgZlMEv2d01lBErwCghI/Jt9jAbGZBcIk/q/dzwRiCwlMY5KYtscMZtDs1QehmhuZ JFZteccMUTSFSeL5nzgQm01AS+LF5ytg24QFrCTOX/gOZHMALbCR+Pa8FMRkEVCV+PCUC6RC BMjsnXOKCWK8vMSHD8fZQcZLCNxnlWhdfo11AqPALCTnzUJy3iygUcwCehL3L2pBhLUlnry7 wAph60p8ntzPiCy+gJFtFaNQbmJmjm5mnpleYkFBTqpecn7uJkZICIvuYDyzyuoQowAHoxIP b+fe88FCrIllxZW5hxilOViUxHm5LgCFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MKrn1MZb rnnW84xnok+jzWeBdSeNpNR+BmSk868Tl7ukbLPSTWDvfguLb8J39Y18j25lY/D7+u9/zRrX riZ+pXru3XoPMhVTzBqb2R9Wv+8sTG9/+6nl7uyp5gcL5tTLm65TfP1oceSarer1vu+WdBzS 6DC79uqs0ZmZXWF1E/6pnllTa3tukRJLcUaioRZzUXEiALkBf3tCAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUiuJrJWTea/0Kwwdt+G4v3S2cxOjB6LFny kymAMYrLJiU1J7MstUjfLoEr48queYwFfycwVnzruc3YwHinrouRk0NCwERi9uqDbBC2mMSF e+uBbC4OIYFGJolvJ88ygySEBKYwSTz/EwdiswloSbz4fAWsgVkgSWLHs9NgNcICVhLnL3wH inNw8ArYSHx7XgpisgioSnx4ygVSIQJk9s45xQRi8woYSLz6+ZgZYq28xIcPx9knMPLMQjJ0 FpIyiLi2xLKFr6FsA4mnna9YMcX1Jd68m8O0gJFtFaNAUWpOYqWFXmJBQU6qXnJ+7iZGUHg1 FKbtYGxabnWIUYCDUYmHt2Pv+WAh1sSy4srcQ4wSHMxKIrx/vgOFeFMSK6tSi/Lji0pzUosP MUpzsCiJ8y6bdDZYSCA9sSQ1OzW1ILUIJsvEwSnVwBh879OJ9U8X9Zw9PePfq6qqNKuf7zev jeY5U7H6ToN7ZMGsr9HyR9kkSrSL5vndWJe0eIGf6zHhldveMbsdUsnbIWw62TVno3ebyiYe /42rJ9ZmSwjI1swyczjdlpt6/XXKnt59e4JYlmXPf5x04Uev7tac7axHpDZtknv5J3jjRTmh Peyt258qsRRnJBpqMRcVJwIACQhIwSsCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/1uZGmS-_4NY5yO26yuy09Sdu56A Subject: [dnssd] Wide Area DNS-Based Service Discovery walkthrough X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 19:39:11 -0000 --Boundary_(ID_37cz0znDy5hx6N+oJ48vqg) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable In preparation for discussion tomorrow of = I=92m = re-sending this walkthrough of how Wide Area DNS-Based Service Discovery = works. Here at the IETF meeting we=92re using manually-entered DNS = records; the Hybrid Proxy would automate the importation of the = necessary records into the unicast DNS namespace, to make this = accessible to people who don=92t have highly talented IETF volunteers = running their network. When you tap the AirPrint button on your iPad and give no second thought = to how it magically knew about the IETF Terminal Room printer, this is = what is going on behind the scenes, starting with DHCP, and ending with = a TCP connection sending the data to the printer. Since most people = don=92t have a shell login on their iPad, I=92m going to illustrate this = using examples on Mac OS X, which works the same way. First, let=92s see what my Mac learned from the local DHCP server: > % scutil > > list > ... > subKey [74] =3D = State:/Network/Service/21B5304C-C227-4932-BFCF-54B28F4CA1D2/DHCP > ... >=20 > > show = State:/Network/Service/21B5304C-C227-4932-BFCF-54B28F4CA1D2/DHCP > { > Option_15 : 0x6d656574696e672e696574662e6f7267 > ... > } Option_15 is Domain Name. What domain name? > % echo 6d656574696e672e696574662e6f7267 0A | xxd -r -p > meeting.ietf.org Great. Does meeting.ietf.org recommend we look in any Wide Area Service = Discovery domains? > % dig lb._dns-sd._udp.meeting.ietf.org. ptr >=20 > ; <<>> DiG 9.6-ESV-R4-P3 <<>> lb._dns-sd._udp.meeting.ietf.org. ptr > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35624 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: = 4 >=20 > ;; QUESTION SECTION: > ;lb._dns-sd._udp.meeting.ietf.org. IN PTR >=20 > ;; ANSWER SECTION: > lb._dns-sd._udp.meeting.ietf.org. 3600 IN PTR meeting.ietf.org. >=20 > ... >=20 > ;; Query time: 8 msec > ;; SERVER: 130.129.5.6#53(130.129.5.6) > ;; WHEN: Wed Mar 13 10:16:40 2013 > ;; MSG SIZE rcvd: 188 In this case the PTR is self-referential =97 meeting.ietf.org is = advising us to look in meeting.ietf.org, but it could easily be set up = to direct us elsewhere. Note, I can ask any DNS server this question and I will get the same = answer. Let=92s ask Google DNS instead: > % dig @8.8.8.8 lb._dns-sd._udp.meeting.ietf.org. ptr >=20 > ; <<>> DiG 9.6-ESV-R4-P3 <<>> @8.8.8.8 = lb._dns-sd._udp.meeting.ietf.org. ptr > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24571 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 >=20 > ;; QUESTION SECTION: > ;lb._dns-sd._udp.meeting.ietf.org. IN PTR >=20 > ;; ANSWER SECTION: > lb._dns-sd._udp.meeting.ietf.org. 1532 IN PTR meeting.ietf.org. >=20 > ;; Query time: 21 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Wed Mar 13 10:18:27 2013 > ;; MSG SIZE rcvd: 64 I still get the same answer. The DNS server I ask doesn=92t have to be = =93on=94 my =93local=94 network (whatever that means). I=92m in Toronto. = Google DNS is I-don=92t-know-where, 11 hops away, but it still gives the = right answer. > % traceroute -q 1 8.8.8.8 > traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets > 1 rtra (31.133.160.2) 1.032 ms > 2 207.219.102.241 (207.219.102.241) 4.453 ms > 3 nycmny83ci01.bb.telus.com (75.154.223.250) 20.588 ms > 4 72.14.194.122 (72.14.194.122) 20.018 ms > 5 209.85.248.180 (209.85.248.180) 11.793 ms > 6 72.14.236.208 (72.14.236.208) 11.868 ms > 7 72.14.239.93 (72.14.239.93) 20.319 ms > 8 66.249.95.231 (66.249.95.231) 29.761 ms > 9 209.85.250.223 (209.85.250.223) 24.389 ms > 10 * > 11 google-public-dns-a.google.com (8.8.8.8) 35.995 ms (For the rest of this example I'll use Google DNS for all the queries.) The PTR is suggesting we look for services in meeting.ietf.org, so let=92s= do that: A Mac will look for this service: > % dig +short @8.8.8.8 _pdl-datastream._tcp.meeting.ietf.org. ptr > term-printer._pdl-datastream._tcp.meeting.ietf.org. There=92s one printing service available here, called =93term-printer=94. = That=92s what you see when you press the =93+=94 button in the Print & = Fax Preference Pane on Mac OS X. To actually use it, the client uses this: > % dig +short @8.8.8.8 = term-printer._pdl-datastream._tcp.meeting.ietf.org. srv > 0 0 9100 term-printer.meeting.ietf.org. >=20 > % dig +short @8.8.8.8 term-printer.meeting.ietf.org. AAAA > 2001:67c:370:128:a65d:36ff:fe32:44ba So, to use this printer, the Mac connects to = [2001:67c:370:128:a65d:36ff:fe32:44ba]:9100, and uses the installed = printer driver, which speaks the appropriate vendor-specific printing = protocol for that printer. If you=92re using an iPhone then you don=92t have vendor-specific = printer drivers installed; instead it uses this generic IPP-based = printing service: > % dig +short @8.8.8.8 _universal._sub._ipp._tcp.meeting.ietf.org. ptr > term-printer._ipp._tcp.meeting.ietf.org. There=92s one IPP-based printing service available here, called = =93term-printer=94. Same name as the pdl-datastream printing service, = and same physical hardware, but a different printing protocol, listening = on a different port. To actually use it, the client uses this: > % dig +short @8.8.8.8 term-printer._ipp._tcp.meeting.ietf.org. srv > 0 0 631 term-printer.meeting.ietf.org. >=20 > % dig +short @8.8.8.8 term-printer.meeting.ietf.org. aaaa > 2001:67c:370:128:a65d:36ff:fe32:44ba Note: Same address as before, but different port number. To use this printer, the iPhone connects to = [2001:67c:370:128:a65d:36ff:fe32:44ba]:631, and uses IPP to print. And that, ladies and gentlemen, is how automatic Wide Area DNS-Based = Service Discovery works. Here at IETF, the records are added to the DNS manually by our capable = network volunteers. The idea of the Hybrid Proxy is to populate the DNS = namespace automatically, making Wide Area DNS-Based Service Discovery = available to a broader community of users. Stuart Cheshire --Boundary_(ID_37cz0znDy5hx6N+oJ48vqg) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable
In preparation for discussion tomorrow of = <http://= tools.ietf.org/html/draft-cheshire-dnssd-hybrid-01> I=92m = re-sending this walkthrough of how Wide Area DNS-Based Service Discovery = works. Here at the IETF meeting we=92re using manually-entered DNS = records; the Hybrid Proxy would automate the importation of the = necessary records into the unicast DNS namespace, to make this = accessible to people who don=92t have highly talented IETF volunteers = running their network.

When you tap the = AirPrint button on your iPad and give no second thought to how it = magically knew about the IETF Terminal Room printer, this is what is = going on behind the scenes, starting with DHCP, and ending with a = TCP connection sending the data to the printer. Since most people = don=92t have a shell login on their iPad, I=92m going to illustrate this = using examples on Mac OS X, which works the same = way.

First, let=92s see what my Mac = learned from the local DHCP server:

% = scutil
> = list
 ...
 subKey [74] =3D = State:/Network/Service/21B5304C-C227-4932-BFCF-54B28F4CA1D2/DHCP
 ...

> show = State:/Network/Service/21B5304C-C227-4932-BFCF-54B28F4CA1D2/DHCP
<dictionary> = {
 Option_15 : = <data> 0x6d656574696e672e696574662e6f7267
=
 ...
}

Option_15 is Domain Name. What = domain name?

% echo 6d656574696e672e696574662e6f7267 0A | xxd -r = -p
meeting.ietf.org

= Great. Does meeting.ietf.org = recommend we look in any Wide Area Service Discovery = domains?

% dig lb._dns-sd._udp.meeting.ietf.org. = ptr

; <<>> DiG 9.6-ESV-R4-P3 <<>> = lb._dns-sd._udp.meeting.ietf.org. = ptr
;; global options: = +cmd
;; Got = answer:
;; = ->>HEADER<<- opcode: QUERY, status: NOERROR, id: = 35624
;; flags: qr aa rd ra; = QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: = 4

;; QUESTION SECTION:
;lb._dns-sd._udp.meeting.ietf.org. IN = PTR

;; ANSWER = SECTION:
lb._dns-sd._udp.meeting.ietf.org. 3600 IN = PTR meeting.ietf.org.
=

...

;; Query time: = 8 msec
;; SERVER: = 130.129.5.6#53(130.129.5.6)
;; = WHEN: Wed Mar 13 10:16:40 2013
;; MSG SIZE  rcvd: 188

In this = case the PTR is self-referential =97 meeting.ietf.org is advising = us to look in meeting.ietf.org, but it = could easily be set up to direct us = elsewhere.

Note, I can ask any DNS = server this question and I will get the same answer. Let=92s ask Google = DNS instead:

% dig @8.8.8.8 = lb._dns-sd._udp.meeting.ietf.org. = ptr

; <<>> DiG 9.6-ESV-R4-P3 <<>> = @8.8.8.8 lb._dns-sd._udp.meeting.ietf.org. = ptr
; (1 server = found)
;; global options: = +cmd
;; Got = answer:
;; = ->>HEADER<<- opcode: QUERY, status: NOERROR, id: = 24571
;; flags: qr rd ra; = QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: = 0

;; QUESTION SECTION:
;lb._dns-sd._udp.meeting.ietf.org. IN = PTR

;; ANSWER = SECTION:
lb._dns-sd._udp.meeting.ietf.org. 1532 IN = PTR meeting.ietf.org.
=

;; = Query time: 21 msec
;; SERVER: = 8.8.8.8#53(8.8.8.8)
;; WHEN: = Wed Mar 13 10:18:27 2013
;; = MSG SIZE  rcvd: 64

I still get the same answer. = The DNS server I ask doesn=92t have to be =93on=94 my =93local=94 = network (whatever that means). I=92m in Toronto. Google DNS is = I-don=92t-know-where, 11 hops away, but it still gives the right = answer.

% traceroute -q 1 8.8.8.8
traceroute to 8.8.8.8 = (8.8.8.8), 64 hops max, 52 byte packets
 1  rtra = (31.133.160.2)  1.032 ms
 2  207.219.102.241 = (207.219.102.241)  4.453 ms
 3  nycmny83ci01.bb.telus.com = (75.154.223.250)  20.588 = ms
 4  72.14.194.122 (72.14.194.122)  20.018 = ms
 5  209.85.248.180 = (209.85.248.180)  11.793 = ms
 6  72.14.236.208 (72.14.236.208)  11.868 = ms
 7  72.14.239.93 (72.14.239.93)  20.319 = ms
 8  66.249.95.231 (66.249.95.231)  29.761 = ms
 9  209.85.250.223 = (209.85.250.223)  24.389 = ms
10  *
11  google-public-dns-a.google.= com (8.8.8.8)  35.995 ms

(For = the rest of this example I'll use Google DNS for all the = queries.)

The PTR is suggesting we look for services = in meeting.ietf.org, so let=92s = do that:

A Mac will look for this service:

% dig +short @8.8.8.8 _pdl-datastream._tcp.meeting.ietf.org. = ptr
term-printer._pdl-datastream._tcp.meeting.ietf.org.

There=92s one printing service available here, called = =93term-printer=94. That=92s what you see when you press the =93+=94 = button in the Print & Fax Preference Pane on Mac OS = X.

To actually use it, the client uses this:

% dig +short @8.8.8.8 term-printer._pdl-datastream._tcp.meeting.ietf.org. = srv
0 0 9100 term-printer.meeting.ietf.or= g.

% dig +short @8.8.8.8 term-printer.meeting.ietf.or= g. AAAA
2001:67c:370:128:a65d:36ff:fe32:44ba

So, = to use this printer, the Mac connects to = [2001:67c:370:128:a65d:36ff:fe32:44ba]:9100, and uses the installed = printer driver, which speaks the appropriate vendor-specific = printing protocol for that printer.

If you=92re using an iPhone = then you don=92t have vendor-specific printer drivers installed; instead = it uses this generic IPP-based printing service:

% dig +short @8.8.8.8 _universal._sub._ipp._tcp.meeting.ietf.org. = ptr
term-printer._ipp._tcp.meeting.ietf.org.

There=92s one IPP-based printing service available here, called = =93term-printer=94. Same name as the pdl-datastream printing service, = and same physical hardware, but a different printing protocol, = listening on a different port.

To actually use it, the client = uses this:

% dig +short @8.8.8.8 = term-printer._ipp._tcp.meeting.ietf.org. = srv
0 0 631 term-printer.meeting.ietf.or= g.

% dig +short @8.8.8.8 term-printer.meeting.ietf.or= g. aaaa
2001:67c:370:128:a65d:36ff:fe32:44ba

Note: = Same address as before, but different port number.

To use this = printer, the iPhone connects to = [2001:67c:370:128:a65d:36ff:fe32:44ba]:631, and uses IPP to = print.

And that, ladies and gentlemen, is how automatic Wide Area = DNS-Based Service Discovery works.

Here at IETF, the records are = added to the DNS manually by our capable network volunteers. The idea of = the Hybrid Proxy is to populate the DNS namespace automatically, = making Wide Area DNS-Based Service Discovery available to a broader = community of users.

Stuart = Cheshire

= --Boundary_(ID_37cz0znDy5hx6N+oJ48vqg)-- From nobody Wed Jul 23 12:47:18 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B001A036F for ; Wed, 23 Jul 2014 12:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham 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 LGNvKfoGgmpO for ; Wed, 23 Jul 2014 12:47:16 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A873A1A014F for ; Wed, 23 Jul 2014 12:47:16 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2010C20012; Wed, 23 Jul 2014 15:48:58 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D8FEE63B0E; Wed, 23 Jul 2014 15:47:15 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BEC4463B0A; Wed, 23 Jul 2014 15:47:15 -0400 (EDT) From: Michael Richardson To: Dave Thaler In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/v1ppzlTIxmKjlJOMWnfxkb7KvWQ Cc: "dnssd@ietf.org" Subject: Re: [dnssd] Generalized service discovery requirements/goals X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 19:47:17 -0000 --=-=-= Dave Thaler wrote: > 1) Three levels of identifiers: > a. A "service" (e.g.., a type of device, server, or application) to > discover instances of. So, "printer"? > b. A particular "instance" of a service running on a specific network > node, potentially reachable via multiple endpoints. There can be > multiple instances per service. So, does this mean that the printer has multiple trays with different colours of paper, or rather that maybe it is really a print server that has multiple queues for different physical devices? > c. A particular endpoint (e.g., IP address + port) at which an > instance can be reached. There might be multiple endpoints (e.g., IPv4 > and IPv6) per instance. So the print server is attached to both the wired and wireless networks with different addresses? > b. Live-ness: a currently reachable instance is typically more useful > than an unreachable one. Of course, you might also want to find the one that is less reachable, because maybe that's the one you want to fix? > simple protocol queries underneath. Power-efficiency: Power > conservation is becoming increasingly important. With this trend comes > the need to support discovery of services that are in a low-power > state. Is finding a printer that has been recently used, and is therefore still warm and powered on interesting as well? So, it's not just that you want to discover it even if it is off, but you also want to know when it was last discovered? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU9ARQYCLcPvd0N1lAQI0bwgAwMcrcnUDGjJtFWsBoaKNyhMWQwbvljT9 4NUn0GVmbnx1Q39UM1a2oMzoNj+FiEWRuxC/39WKihRA/85PRdFY9Zxw+54rFUUp vOpmmCP4QcJJYrQ8D+1GlQk9IMqt3U8raY0U6dGsemvPt/fHrIriX2WF4lysgF5o WWQnjp1765IB4PwWb+CtoSSuqZi4TiKSk73jmv7J3DRVwEMuvBQQ5aLXYLu8tjZl LyGtmPEtMDezMK5L5MzzmYq9lMEJcv7c0k2TW6sG8+l4DR7whNxQVKEw/43X8ZBZ 9jHtSFenU4eKrTVbqMJPSTekeCpD1nurBnqWwO6eMX1+VD8U8eFQuw== =/5Ah -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 23 12:55:19 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D21B1B2822 for ; Wed, 23 Jul 2014 12:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.302 X-Spam-Level: X-Spam-Status: No, score=-104.302 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 uoGgU0yeqDiT for ; Wed, 23 Jul 2014 12:55:12 -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 8FC301A014F for ; Wed, 23 Jul 2014 12:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1406145312; x=2270058912; 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=yB/B+TNaoyL74cZAK+sj3IdeOcSV8/1kHtBd+QkH3SQ=; b=XBS/KdaN6gNvKp1Leg5iHIj8sFn5pxYzPQR1++HSETcMZB8JEakoE1NMPP3wsIfD xt89Z50dksi42VfrU3Dlu9ldaew4oWwfx+tNYzW+/kB1wjG4uAFnPPzhH6Ay5D0e KzJ6T30Bzj75oc4w9PDkA47Xa5nKtZspqBe4z2Hp9r/Y6DL9fMLDkr/8AOwO34nJ BWyj0LZPVzMjoXHXgw1459t8g0DDICa5akGTYdDUHWdivOWjSPOOXUw+tEo+XrLm vgODwYH+QkV6ABqVsSo0PbR6+AfE2U1pxudDhW5rXi66r+L9zXJ5jE4Vl2UcNv1H 12F+OtyaPdzBr+BFEteUFw==; Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 01.45.32596.02310D35; Wed, 23 Jul 2014 12:55:12 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay4.apple.com ([17.128.113.87]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N9600KV4KNONZD0@local.mail-out.apple.com> for dnssd@ietf.org; Wed, 23 Jul 2014 12:55:12 -0700 (PDT) X-AuditID: 11973e15-f79d66d000007f54-3b-53d01320d850 Received: from russet (russet.apple.com [17.171.2.67]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 7C.20.03493.32310D35; Wed, 23 Jul 2014 12:55:15 -0700 (PDT) Received: from dhcp-a58b.meeting.ietf.org ([31.133.165.139]) by russet.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0N960038BKNYXE30@russet.apple.com> for dnssd@ietf.org; Wed, 23 Jul 2014 12:55:10 -0700 (PDT) From: Stuart Cheshire In-reply-to: <0022F0DD-AEC8-4222-8F74-E38399B6B02D@gmail.com> Date: Wed, 23 Jul 2014 12:55:08 -0700 Message-id: <57DBCF5D-CFE6-4538-AC94-7C8BB574F4DD@apple.com> References: <10DC3A23-5ABF-4D01-97AE-17C5E488F664@ecs.soton.ac.uk> <0022F0DD-AEC8-4222-8F74-E38399B6B02D@gmail.com> To: dnssd@ietf.org X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUiON3OSFdB+EKwQds/Pov3S2cxOjB6LFny kymAMYrLJiU1J7MstUjfLoEr49uziawFbRwVk1+9Z2tgvM7WxcjBISFgItG0yL2LkRPIFJO4 cG89G4gtJDCTSWJBlxaIzSsgKPFj8j0WkHJmAXmJg+dlQcLMAloS3x+1AoW5gMqnMklM7PjA BDHHRKL981tGiEQjk8TppktQVVOYJDYc2cAIUiUsYCfxcMU0dhCbDWjUi89XwDZzCthKfD+6 A2wSi4CqxOGlu9hBNvMK2Eh8mGYKcdwHRolfvRYgtoiAkMTSuYfYIRbLS3z4cJwdZJeEwGtW ic/LN7NPYBSeheSJWQhPzELyxAJG5lWMQrmJmTm6mXlmeokFBTmpesn5uZsYISEsuoPxzCqr Q4wCHIxKPLyde88HC7EmlhVX5h5ilOZgURLn5boAFBJITyxJzU5NLUgtii8qzUktPsTIxMEp 1cBosXlnZN/3OxePPTwR4PJNvnD/Bbbkx/51M0xfae/f4Kk96ca2pkjxmu1ClTI5PTxG71hV 9p5lmzjdpsYts71t1Yt66emPUzztf6yMr1qw81TvzxillcZZmYd4LKo4wrYcjzrIZSt2qob7 ZdS+TRaTXzD6WQVEvNwyfbH+t+uhui3PWs64BuYosRRnJBpqMRcVJwIAw88oSEICAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUiuJrJWVdZ+EKwwfVdWhbvl85idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuldO9gLlnBUvDn2jbmB8SFbFyMnh4SAiUT757eMELaYxIV7 64HiXBxCAo1MEt1/T7NAOFOYJDYc2QBUxcHBLKAncf+iFkgDr4CBxKufj5lBbGEBO4mHK6ax g9hsAloSLz5fAVvAKWAr8f3oDiYQm0VAVeLw0l1gNcwC2hJP3l1gBRnJK2Aj8WGaKUhYSOAD o8SvXgsQW0RASGLp3EPsELfJS3z4cJx9AiP/LIQjZiE5YhaSoQsYmVcxChSl5iRWmuglFhTk pOol5+duYgQFV0Nh+A7Gf8usDjEKcDAq8fB27D0fLMSaWFZcmXuIUYKDWUmE9893oBBvSmJl VWpRfnxRaU5q8SFGaQ4WJXHelZPOBgsJpCeWpGanphakFsFkmTg4pRoYlU32ZJUs0q8ImTf/ UPQP880dFROOzZomc+WT2vFaJbsNNXIL6jRsZRTesm2b2iJzdR3nfFejKzLXWKfd+rnt8gnH iUduS9k9LTGY+KRq/X351X6ev0vMuoXD3vzeMYXn8d6zXssndmatlRTLLt8xLdbzc9iPdZ6d myzvuc1Sdgu6pbD4z5QnhkosxRmJhlrMRcWJAOTlCtQqAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/DZKQo8t3ZR0XIgdVRd9x2hwyFL0 Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-requirements-03 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 19:55:14 -0000 On 7 Jul, 2014, at 17:47, Douglas Otis wrote: > Layer 2 solutions intentionally ignored. Correct. Organizations like IEEE tend to focus on flat single-link networks, which is fine. The IETF tries to develop inter-network solutions, building on the link-layer technologies IEEE provides. We already have a single-link solution -- mDNS. The goal of this WG is to develop a solution that goes beyond a single logical link, and works inter-network. > it is not practical to expect a printer will ever be able to authenticate a client. A Google search suggests otherwise. For example: My printer asks for a password. Where do I get it? (14850 Views) Similarly, when you use Printer Sharing on Mac OS X to make your USB printer available on the network, you have the option to restrict access to specified authenticated users if you desire. Stuart Cheshire From nobody Wed Jul 23 12:58:38 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6671A01E4 for ; Wed, 23 Jul 2014 12:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=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 2TownlVUKe4Q for ; Wed, 23 Jul 2014 12:58:30 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E154C1A01D9 for ; Wed, 23 Jul 2014 12:58:29 -0700 (PDT) Received: from mx1.yitter.info (dhcp-bcbc.meeting.ietf.org [31.133.188.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id EF75A8A031 for ; Wed, 23 Jul 2014 19:58:28 +0000 (UTC) Date: Wed, 23 Jul 2014 15:58:27 -0400 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20140723195826.GC21570@mx1.yitter.info> References: <86ECD248-6479-42B8-80C6-9657D51449DA@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86ECD248-6479-42B8-80C6-9657D51449DA@apple.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/yzxXPhLs0CRnDuGDqaOSTpePSg8 Subject: Re: [dnssd] Wide Area DNS-Based Service Discovery walkthrough X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 19:58:31 -0000 On Wed, Jul 23, 2014 at 12:39:04PM -0700, Stuart Cheshire wrote: > > Note, I can ask any DNS server this question and I will get the same answer. s/any DNS server this/any DNS server that supports recursion this/ Stuart knows this, of course. My point is that if you have a recursor and the relevant data is in the public DNS, then you get it just like any other DNS record. Nothing is magic or special about the way this all works. It's bog standard DNS when it uses DNS. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Jul 23 13:02:04 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B65D1A0537 for ; Wed, 23 Jul 2014 13:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 H5nK4_OVhU_V for ; Wed, 23 Jul 2014 13:01:55 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F3D1A033D for ; Wed, 23 Jul 2014 13:01:51 -0700 (PDT) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB409.namprd03.prod.outlook.com (10.141.141.11) with Microsoft SMTP Server (TLS) id 15.0.990.7; Wed, 23 Jul 2014 20:01:48 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0990.007; Wed, 23 Jul 2014 20:01:48 +0000 From: Dave Thaler To: Michael Richardson Thread-Topic: [dnssd] Generalized service discovery requirements/goals Thread-Index: Ac+mjIxNU3J2npVCT5W254yc78juRgAIlreAAABMbTA= Date: Wed, 23 Jul 2014 20:01:48 +0000 Message-ID: <52bc206bb04d43dd8db054ace2744c29@BY2PR03MB412.namprd03.prod.outlook.com> References: <2586.1406144835@sandelman.ca> In-Reply-To: <2586.1406144835@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.161.166] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(24454002)(377454003)(13464003)(51704005)(189002)(199002)(85306003)(19580395003)(95666004)(80022001)(76576001)(99286002)(107046002)(85852003)(83322001)(106356001)(83072002)(105586002)(19580405001)(110136001)(92566001)(20776003)(46102001)(4396001)(21056001)(64706001)(86362001)(50986999)(2656002)(99396002)(76176999)(54356999)(101416001)(76482001)(87936001)(74502001)(31966008)(66066001)(74316001)(77982001)(33646002)(86612001)(79102001)(81542001)(81342001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB409; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/g2nBi6-rVKn9sv7RK4VRJOvAje4 Cc: "dnssd@ietf.org" Subject: Re: [dnssd] Generalized service discovery requirements/goals X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 20:02:02 -0000 > -----Original Message----- > From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of Michael > Richardson > Sent: Wednesday, July 23, 2014 3:47 PM > To: Dave Thaler > Cc: dnssd@ietf.org > Subject: Re: [dnssd] Generalized service discovery requirements/goals >=20 >=20 > Dave Thaler wrote: > > 1) Three levels of identifiers: >=20 > > a. A "service" (e.g.., a type of device, server, or application) t= o > > discover instances of. >=20 > So, "printer"? Yes. > > b. A particular "instance" of a service running on a specific netw= ork > > node, potentially reachable via multiple endpoints. There can be > > multiple instances per service. >=20 > So, does this mean that the printer has multiple trays with different col= ours > of paper, or rather that maybe it is really a print server that has multi= ple > queues for different physical devices? More likely the latter, but there may be more than one way to expose "printers" so I'm trying to keep this more abstract. But for clarity, sure a specific printer or print server queue is usually a service instance. I= t may have multiple endpoints (e.g. IPv4 vs IPv6). > > c. A particular endpoint (e.g., IP address + port) at which an > > instance can be reached. There might be multiple endpoints (e.g., = IPv4 > > and IPv6) per instance. >=20 > So the print server is attached to both the wired and wireless networks w= ith > different addresses? Right. Or just on one dual-stack network, thus having both IPv4 and IPv6 endpoints. > > b. Live-ness: a currently reachable instance is typically more use= ful > > than an unreachable one. >=20 > Of course, you might also want to find the one that is less reachable, be= cause > maybe that's the one you want to fix? Sure. The 'typically' just refers to the common case. Point is there's no one-size-fits-all ordering. > > simple protocol queries underneath. Power-efficiency: Power > > conservation is becoming increasingly important. With this trend c= omes > > the need to support discovery of services that are in a low-power > > state. >=20 > Is finding a printer that has been recently used, and is therefore still = warm > and powered on interesting as well? So, it's not just that you want to > discover it even if it is off, but you also want to know when it was last > discovered? I haven't heard of that desire before, but it's possible there may be desires for that sort of thing too. To generalize a bit into a possibly more common case, "devices that are already in a higher powered state might be more desirable than devices that are in a low power state". That would usually come due to either of two desires: a) A policy to minimize power costs across the service, or b) A desire to talk to the device as soon as possible, where there may be latency added if the device first has to come back into a high powered state. -Dave From nobody Wed Jul 23 13:14:58 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB5C1A0309 for ; Wed, 23 Jul 2014 13:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 745UiYSpVMXV for ; Wed, 23 Jul 2014 13:14:52 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B616F1A00B7 for ; Wed, 23 Jul 2014 13:14:52 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id ey11so2403185pad.10 for ; Wed, 23 Jul 2014 13:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=6499P2wrDK1jIFl6m/5Vm+sSI4tfPkN04YzQ1Xy1b3U=; b=y1gIrew+3Hjt0jroyJh3/BhvRIyp0PpYN3Au7svQgqddFXoDo8x+WqPD9Yf4DkgL7X QQkmXuZ4VFeEmFDmL2abTvisk52NitBvdr9aPBbLiFvmsqcdQ7NV0aZHsIjSOQOKLfLC i9qMbNqmCKBy3SrZPC2JSTNB4y1j4MPGgnGE71RB1ZbXuuiqv/TeOmmVV/oYQZKzAgaN xdv9n0e7MOOK/8DOUY5kPoBxTFfaq+98BW12n+SgPKpdFDdfjmoyM1JtL9UHOGK+/cCS TqHFIHr0/L+o2Rd2fZW9LU1mLxBz/mjEzCFNhi+BE2QoWIHhuu07zE137KFXoqkXhTAt EE0A== X-Received: by 10.66.227.170 with SMTP id sb10mr5121217pac.56.1406146492229; Wed, 23 Jul 2014 13:14:52 -0700 (PDT) Received: from [192.168.2.235] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id fe3sm3254710pbd.66.2014.07.23.13.14.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 13:14:51 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_07E19639-70F7-40CA-8CA2-CE4CFC766522" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: Date: Wed, 23 Jul 2014 16:14:46 -0400 Message-Id: <94FE061A-51FF-4F18-906F-703D16E9F303@gmail.com> References: <10DC3A23-5ABF-4D01-97AE-17C5E488F664@ecs.soton.ac.uk> <0022F0DD-AEC8-4222-8F74-E38399B6B02D@gmail.com> <609AC6B1-C544-4CF1-A1D9-0468D72C963B@ecs.soton.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/WNDLmweiV_wkFfpluWLE0YpoJVs Cc: dnssd@ietf.org, Douglas Otis Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-requirements-03 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 20:14:56 -0000 --Apple-Mail=_07E19639-70F7-40CA-8CA2-CE4CFC766522 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear Tim, See comments inline: On Jul 22, 2014, at 5:35 PM, Tim Chown wrote: > Hi, >=20 > Thanks for your comments Doug. >=20 > On 8 Jul 2014, at 01:47, Douglas Otis wrote: >=20 >> On Jul 7, 2014, at 2:46 AM, Tim Chown wrote: >>=20 >>> Hi, >>>=20 >>> This email begins a two week WGLC on = draft-ietf-dnssd-requirements-03, "Requirements for Scalable DNS-SD/mDNS = Extensions=94. >>>=20 >>> Ralph and I as chairs believe the authors have addressed the issues = raised at IETF89 and on the list since.=20 >>>=20 >>> You can see the draft here: >>> http://tools.ietf.org/html/draft-ietf-dnssd-requirements-03 >>=20 >> Dear dnssd-wg, >>=20 >> 1) Layer 2 solutions intentionally ignored. >>=20 >> One of the primary goals for extending mDNS per the Educause petition = was to enable access to remote displays. Unfortunately, layer 3 routing = is generally prohibited with unlicensed nodes in conveyance of copyright = media. While layer 2 solutions are able to overcome multi-bridge = limitations imposed by media compliance requirements, this has been = ignored by the Scalable DNS-SD/mDNS requirements documentation to the = point of being ruled out-of-scope for discussion because of an assumed = need for layer 3 only solutions. Nevertheless, layer 3 solutions are = normally precluded when not licensed as a means to ensure constraint of = media redistribution. A quandary that could have been avoided by = determining common strategies that could be used by either layer 2 or 3. = For example, many routers are able to handle GUA+ULA. Layer 3 and 2 = might be considered analogous when ULAs are mapped to MACs.=20 >=20 > You need to be more explicit at what you mean here. The purpose of = dnssd is to allow DNS-based service discovery in multi-subnet = environments, such as campuses and future home networks (as defined in = the homenet WG). If your network is a flat layer 2 network, that = particular problem doesn=92t exist. >=20 > In addition, REQ14 states: > REQ14: SSD should operate over existing networks (as described by > use cases A-F above) without requiring changes to the network > technology or deployment. >=20 > Regarding ULAs, the homenet-arch text describes the use of ULAs = alongside GUAs in multi-link home networks. ULAs can then be used for = internal communications, regardless of the GUAs, or changes in the GUAs. = GUAs are then used for external communications. Agreed, but when a GUA is used and published, this should exclude = devices unable to safely terminate a session from the Internet. It is = not safe to advertise such addresses in DNS, especially when security = depends on address obscurity.=20 > Not sure what you mean by ULAs being mapped to MACs. After reading the latest HDCP specification, concerns related to routing = limitations were misplaced and peer-to-peer changes further reduce the = concerns. Please ignore needing an alternative for Educause.=20 >> 2) Many devices within a typical network may announce routable = addresses via mDNS but are nevertheless unable to authenticate the = access permitted when these mDNS resources are conveyed in DNS. >> ,-- >> The following is a summary of the technical requirements: >> ... >> o It must be cost-effective to manage at up to enterprise scale. >> '-- >>=20 >> Being unable to differentiate locality for those devices unable to = handle Internet originating sessions, as in the printer example, means = the Scalable DNS-SD/mDNS extension is NOT manageable at any scale. >=20 > The charter states that a user away from a network should be able to = discover devices in their =91home=92 network, which implies a remote = proxy discovery capability, and GUAs for reachability. We should = distinguish discoverability (including across the potential range of = discovery =91scopes=92) from reachability (e.g. whether ACLs may exist = on the path) from accessability (e.g. access control on the device). Normal practices depend on use of a gateway authenticating clients, such = as use of VPNs. In such cases, service discovery can return ULAs which = permits router bridging within a multi-router home network. It sounds = like Ran wants to configure devices within a data-center. It might be = helpful to reinforce a need to exclude FD::/8 addresses over Internet = access links. Only devices able to terminate Internet sessions should = be published globally. Unfortunately, it is impossible to make such a = determination based on mDNS resources. This inability makes such a = simplistic approach both unsafe and unmanageable. =20 >> Since different network realms are expected to permit device access = behind different bridges based on their "routable" mDNS resources = published in DNS, this circumvents a strategy of differentiating local = origination. This becomes particularly problematic when different IPv6 = prefixes are dynamically in use. >=20 > The homenet arch postulates that ULAs can loosely be used as a hint of = connection origin. Agreed. But none of the related wg drafts clarify essential roles ULAs = have in securing a Hybrid mDNS to DNS approach. Within a dynamic = multiple-prefix environment, ULA and RFC1981 space are essential in = establishing stable and identifiable network perimeters. Such = perimeters defend devices that don't expect direct access from the = Internet or split-horizon DNS, as some have suggested. =20 >> In the Security Consideration Section, the union of DNS-SD and mDNS = would be zero since DNS-SD claims it to be a data structure creating no = security concerns. The union of zero with anything is zero. >=20 > Not sure what you mean there - please expand. Sorry, a mistake was made confusing union with intersection. = Nevertheless, the security consideration statement misrepresents = security concerns being a combination of mDNS and DNS-SD security = considerations. DNS-SD security considerations specification claims it = adds no new security concerns. Such a view implies SSD security = consideration are limited to those affecting mDNS. However, mDNS is = confined to the bridge, whereas DNS removes this constraint. Such a = change has a tremendous, albeit ignored, security impact. >> Does REQ6 have priority over that of REQ14? >> ,-- >> REQ6: SSD must not adversely affect or break any other current >> protocols or deployments. >> '-- >> ,-- >> REQ14: SSD should operate over existing networks (as described by >> use cases A-F above) without requiring changes to the = network >> technology or deployment. >=20 > Ah. So I think REQ6 should say =93any other current service discovery = protocols or deployments.=94. The follow-on sentence attempted to clarify a paradox created by the = simplified view when REQ14 is not seen in conflict with REQ6.=20 >> mDNS is restricted to a single link. The envisioned multi-link = configuration affects the discovery and scope of the related services = which may break current protocols and/or substantially increase their = vulnerabilities. >=20 > Well, I agree there=92s certainly privacy and security issues if = devices become discoverable over a wider =92scope', which I believe = Hosnieh is going to talk about. Disagree. Significant issues are related to erosion of network = permitters not being considered. For example, this draft could have = included a reference to RFC6950 to expand on relevant DNS issues related = to securing the proposed automatic publication by SSD that only excludes = link-local and RFC1918. Although posted on the mailing-list, my review = failed to include this reference. Two reasons for me to blush, but in = essence security considerations ignored Internet originating threats = permitted by obfuscation of network perimeters by promoting mDNS into = DNS.=20 >> 6.4. Authentication >> ... >> was: >> ,-- >> If there is a risk that clients may be fooled by the deployment of >> rogue services, then application layer authentication should be >> considered as part of any security solution. Authentication of any >> particular service is outside the scope of this document. >> '-- >>=20 >> should be: >> ,-- >> When there is risk that either clients or devices may be spoofed >> by malefactors, then a network overlay or application layer=20 >> authentication strategy should be considered. Authentication of >> or by any particular service is outside the scope of this document. >> =91-- >=20 > What you=92re hinting at I think is to use ULAs as a hint of = connection origin, to distinguish from external access. A question is = whether a device that is only intended to be used internally should be = published, and thus discoverable, externally. Default behaviors should be secure. At minimum, there should be a means = to recognize whether a device can be directly discoverable and = accessible from the Internet. This DMZ determination should be = considered limited to manual configuration. >> For example, it is not practical to expect a printer will ever be = able to authenticate a client. >=20 > Many home network devices certainly do support authentication. = Although often they=92re left with default factory settings=85. In the case of most consumer printers employing IPv6, they often make = use of SLAAC or DHCP and report routable IPv6 addresses in mDNS = resources. While these devices may support authentication in = administrative configuration functions, only MAC filters constrain = sending a fax, printing, scanning, etc. Such constraints can't be used = and still permit router bridging. In other words, there is no = protection and no logging to even permit effective monitoring. >> An overlay network can consist of GUA+ULA without change to network = technology or deployment. ULAs can limit access to trusted users having = immediate access to the local network realms. ULAs also avoid DNS = deployment that attempt to merge local with global using complex and = risky split-horizon configurations. ULAs already serve as the basis for = BTMM configurations which avoids publishing resources for devices like = printers unable to authenticate an external session. >=20 > So ULAs could be used in a home, and they might be used in an = enterprise - whether there that=92s alongside GUAs or with NPTv6 is = another question. It seems reasonable for ULAs to be used in both environments, with only = selected devices moved manually into the DMZ. In both environments use = of VPNs or secure tunneling is increasingly common.=20 Regards, Douglas Otis --Apple-Mail=_07E19639-70F7-40CA-8CA2-CE4CFC766522 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = Tim,

See comments inline:

On = Jul 22, 2014, at 5:35 PM, Tim Chown <tjc@ecs.soton.ac.uk> = wrote:

Hi,

Thanks for your comments Doug.
On 8 Jul 2014, at 01:47, Douglas = Otis <doug.mtview@gmail.com> = wrote:

On Jul 7, 2014, at 2:46 AM, Tim Chown <tjc@ecs.soton.ac.uk> = wrote:

Hi,

This email begins a two week = WGLC on draft-ietf-dnssd-requirements-03, "Requirements for = Scalable DNS-SD/mDNS Extensions=94.

Ralph and I as chairs believe the authors = have addressed the issues raised at IETF89 and on the list = since. 

You can see the draft here:

Dear = dnssd-wg,

1) Layer 2 solutions intentionally = ignored.

One of the primary goals for extending = mDNS per the Educause petition was to enable access to remote displays. =  Unfortunately, layer 3 routing is generally prohibited with = unlicensed nodes in conveyance of copyright media.  While layer 2 = solutions are able to overcome multi-bridge limitations imposed by media = compliance requirements, this has been ignored by the Scalable = DNS-SD/mDNS requirements documentation to the point of being ruled = out-of-scope for discussion because of an assumed need for layer 3 only = solutions.  Nevertheless, layer 3 solutions are normally precluded = when not licensed as a means to ensure constraint of media = redistribution.  A quandary that could have been avoided by = determining common strategies that could be used by either layer 2 or 3. =  For example, many routers are able to handle GUA+ULA.  Layer = 3 and 2 might be considered analogous when ULAs are mapped to = MACs. 

You need to be more = explicit at what you mean here.  The purpose of dnssd is to allow = DNS-based service discovery in multi-subnet environments, such as = campuses and future home networks (as defined in the homenet WG). If = your network is a flat layer 2 network, that particular problem doesn=92t = exist.

In addition, REQ14 = states:
REQ14:  =
SSD should operate over existing networks (as described by
        use cases A-F above) without requiring changes to the network
        technology or =
deployment.

Regarding ULAs, the = homenet-arch text describes the use of ULAs alongside GUAs in multi-link = home networks. ULAs can then be used for internal communications, = regardless of the GUAs, or changes in the GUAs. GUAs are then used for = external = communications.

Agreed, but = when a GUA is used and published, this should exclude devices unable to = safely terminate a session from the Internet.  It is not safe to = advertise such addresses in DNS, especially when security depends on = address obscurity. 

Not sure what you mean by = ULAs being mapped to = MACs.

After reading the = latest HDCP specification, concerns related to routing limitations were = misplaced and peer-to-peer changes further reduce the concerns. =  Please ignore needing an alternative for = Educause. 

2) Many devices = within a typical network may announce routable addresses via mDNS but = are nevertheless unable to authenticate the access permitted when these = mDNS resources are conveyed in DNS.
,--
The following is a = summary of the technical requirements:
...
o  It must be = cost-effective to manage at up to enterprise scale.
'--

Being = unable to differentiate locality for those devices unable to handle = Internet originating sessions, as in the printer example, means the = Scalable DNS-SD/mDNS extension is NOT manageable at any = scale.

The charter states that a = user away from a network should be able to discover devices in their = =91home=92 network, which implies a remote proxy discovery capability, = and GUAs for reachability. We should distinguish discoverability = (including across the potential range of discovery =91scopes=92) from = reachability (e.g. whether ACLs may exist on the path) from = accessability (e.g. access control on the = device).

Normal practices = depend on use of a gateway authenticating clients, such as use of VPNs. =  In such cases, service discovery can return ULAs which permits = router bridging within a multi-router home network.  It sounds like = Ran wants to configure devices within a data-center.  It might be = helpful to reinforce a need to exclude FD::/8 addresses over Internet = access links.  Only devices able to terminate Internet sessions = should be published globally.  Unfortunately, it is impossible to = make such a determination based on mDNS resources.  This inability = makes such a simplistic approach both unsafe and unmanageable. =  

Since different network = realms are expected to permit device access behind different bridges = based on their "routable" mDNS resources published in DNS, this = circumvents a strategy of differentiating local origination.  This = becomes particularly problematic when different IPv6 prefixes are = dynamically in use.

The homenet arch = postulates that ULAs can loosely be used as a hint of connection = origin.

Agreed. But none of = the related wg drafts clarify essential roles ULAs have in securing a = Hybrid mDNS to DNS approach.  Within a dynamic multiple-prefix = environment, ULA and RFC1981 space are essential in establishing stable = and identifiable network perimeters.  Such perimeters defend = devices that don't expect direct access from the Internet or = split-horizon DNS, as some have suggested.  

In the Security = Consideration Section, the union of DNS-SD and mDNS would be zero since = DNS-SD claims it to be a data structure creating no security concerns. =  The union of zero with anything is = zero.

Not sure what you mean there - = please expand.

Sorry, a = mistake was made confusing union with intersection. Nevertheless, the = security consideration statement misrepresents security concerns being a = combination of mDNS and DNS-SD security considerations.  DNS-SD = security considerations specification claims it adds no new security = concerns.  Such a view implies SSD security consideration are = limited to those affecting mDNS.  However, mDNS is confined to the = bridge, whereas DNS removes this constraint.  Such a change has a = tremendous, albeit ignored, security = impact.

Does REQ6 have = priority over that of REQ14?
,--
REQ6:   = SSD must not adversely affect or break any other = current
           protocols or = deployments.
'--
,--
REQ14:  SSD should = operate over existing networks (as described by
    =        use cases A-F above) without requiring = changes to the network
          =  technology or = deployment.

Ah. So I think = REQ6 should say =93any other current service discovery protocols or = deployments.=94.

The = follow-on sentence attempted to clarify a paradox created by the = simplified view when REQ14 is not seen in conflict with = REQ6. 

mDNS is restricted to a single = link.  The envisioned multi-link configuration affects the = discovery and scope of the related services which may break current = protocols and/or substantially increase their = vulnerabilities.

Well, = I agree there=92s certainly privacy and security issues if devices = become discoverable over a wider =92scope', which I believe Hosnieh is = going to talk = about.

Disagree. =  Significant issues are related to erosion of network permitters = not being considered.  For example, this draft could have included = a reference to RFC6950 to expand on relevant DNS issues related to = securing the proposed automatic publication by SSD that only excludes = link-local and RFC1918.  Although posted on the mailing-list, my = review failed to include this reference.  Two reasons for me to = blush, but in essence security considerations ignored Internet = originating threats permitted by obfuscation of network perimeters by = promoting mDNS into DNS. 

6.4. =  Authentication
...
was:
,--
=
If there is a risk that clients may be fooled by the deployment = of
rogue services, then application layer authentication = should be
considered as part of any security solution. =  Authentication of any
particular service is outside the = scope of this = document.
'--

should = be:
,--
When there is risk that either clients = or devices may be spoofed
by malefactors, then a network = overlay or application layer 
authentication strategy = should be considered. Authentication of
or by any particular = service is outside the scope of this = document.
=91--

Wha= t you=92re hinting at I think is to use ULAs as a hint of connection = origin, to distinguish from external access. A question is whether a = device that is only intended to be used internally should be published, = and thus discoverable, = externally.

Default = behaviors should be secure.  At minimum, there should be a means to = recognize whether a device can be directly discoverable and accessible = from the Internet.  This DMZ determination should be considered = limited to manual configuration.

For example, it is not = practical to expect a printer will ever be able to authenticate a = client.

Many home network devices = certainly do support authentication. Although often they=92re left with = default factory = settings=85.

In the case of = most consumer printers employing IPv6, they often make use of SLAAC or = DHCP and report routable IPv6 addresses in mDNS resources.  While = these devices may support authentication in administrative configuration = functions, only MAC filters constrain sending a fax, printing, scanning, = etc.  Such constraints can't be used and still permit router = bridging.  In other words, there is no protection and no logging to = even permit effective monitoring.

An overlay network can = consist of GUA+ULA without change to network technology or deployment. =  ULAs can limit access to trusted users having immediate access to = the local network realms.  ULAs also avoid DNS deployment that = attempt to merge local with global using complex and risky split-horizon = configurations.  ULAs already serve as the basis for BTMM = configurations which avoids publishing resources for devices like = printers unable to authenticate an external = session.

So ULAs could be used in a = home, and they might be used in an enterprise - whether there that=92s = alongside GUAs or with NPTv6 is another = question.

It seems = reasonable for ULAs to be used in both environments, with only selected = devices moved manually into the DMZ.  In both environments use of = VPNs or secure tunneling is increasingly = common. 

Regards,
Douglas = Otis

= --Apple-Mail=_07E19639-70F7-40CA-8CA2-CE4CFC766522-- From nobody Wed Jul 23 13:51:15 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73601B2888 for ; Wed, 23 Jul 2014 13:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 rEA9O16ZAyrL for ; Wed, 23 Jul 2014 13:51:13 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9FEE1A041A for ; Wed, 23 Jul 2014 13:51:12 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id x13so1734328wgg.31 for ; Wed, 23 Jul 2014 13:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=aa6cfw+dGK0ApEMmHWyYAXFMHNq8XNSy9Tv36rh1C/0=; b=s47iq5jBU4D5QyOU1yxihP4ZYm45SVqQ7RyFTSP9PVxoDInO90TN2whQT+4aEz6mKQ xmxHyULQeuk5lk+a8q/7phNZAGieA+N9ScwDjyM2dBkqVvdkeeI6924x6/VrNOKWr+J2 6SHOpo83AQ+K+s4/1jCXEvdGEYaTzQj/J38hArJQvMLqv8P9hwRjU8FQSfoi5gXSyo5k Z6AD1Q4b4bEZpNDg6gnjQTH8d3paWgt+b399AEx8Z7kPaIN+fNMtrHMUU5Ri1l7sNosj Pl8oKjfFwoT+Z7wLaMIUyBobQw4g9SUT68w3ZOqGG8yEHp5KacU6t25dEh5Zn9hihMxF VLiQ== X-Received: by 10.180.97.129 with SMTP id ea1mr6326432wib.71.1406148670934; Wed, 23 Jul 2014 13:51:10 -0700 (PDT) Received: from dhcp-b535.meeting.ietf.org (dhcp-b535.meeting.ietf.org. [31.133.181.53]) by mx.google.com with ESMTPSA id 19sm9334465wjz.3.2014.07.23.13.51.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 13:51:10 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 23 Jul 2014 16:51:05 -0400 Message-Id: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> To: dnssd@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/su3-z8peUcJV9EDu958raarOudA Subject: [dnssd] Security through Obscurity X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 20:51:14 -0000 (NOTE WELL: I am not a WG Chair, IESG member, IAB member, or authorised spokesperson for anyone other than myself.) Earlier Doug Otis wrote: > It is not safe to advertise such addresses in DNS, > especially when security depends on address obscurity. I believe that the the vast majority of security folks would object to the notion that obscurity is a mechanism capable of providing any meaningful security. If a client were to ask me for advice on protecting their interior services or interior devices from the global Internet, I would suggest at least a firewall (ranging from router ACLs to an air-gap: depending upon their local needs and threat model) and possibly also other measures (again, depending upon local needs and threat model). Operational security is not one-size-fits-all, in my experience, but relying upon security-through-obscurity seems unwise to me. > It sounds like Ran wants to configure devices within a data-center. Incorrect. To be very clear, my post to DNS-SD WG from earlier this week definitely was NOT focused on data centre environments. Yours, Ran From nobody Wed Jul 23 13:57:25 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63D11A0033 for ; Wed, 23 Jul 2014 13:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham 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 QZJFIRrcj2B4 for ; Wed, 23 Jul 2014 13:57:21 -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 DC1571A0377 for ; Wed, 23 Jul 2014 13:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1406149041; x=2270062641; 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=+tDk7Q74sWmRe+SnNKPakjVXCbbs8SzhqknA4UI+KwE=; b=uMn5mGnO4eDN4Oc6BojRJ8a+rBt4mhhPXn0koWkX6A2zPvwOcBM5PZTH57LdH0w8 lH18NRBdz+tUtDfre3EHHg8uGzVUu/gYISlOg/hf9kLvpD7p7q2sEtCiO8qhXUdo CSrAwr8zFLGkf0sZWj5M/1ohH4MTSZlY764HpbEe6HcwqzWpl6Hr+qLevZ/cqw7I MwI9zgJZxnP/7ChrUcclFecIYUteXaS/eCx4bJZQA0Xtx2g40yLLwtBcTwPKA7jU ufdWSTqvzfRav1pxU/Px18FlaPH3Dn5GivbBz4ay4riGMvvI63DMmAOlfLKUTIwz Ve5iMT7Dcxhw0ys6sV0aqQ==; Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id C6.43.09894.1B120D35; Wed, 23 Jul 2014 13:57:21 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay3.apple.com ([17.128.113.83]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N96002EXNJEB1D0@local.mail-out.apple.com> for dnssd@ietf.org; Wed, 23 Jul 2014 13:57:21 -0700 (PDT) X-AuditID: 11973e11-f79256d0000026a6-aa-53d021b132af Received: from [17.153.43.124] (Unknown_Domain [17.153.43.124]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 39.DD.08757.2B120D35; Wed, 23 Jul 2014 13:57:23 -0700 (PDT) From: Michael Sweet In-reply-to: <2586.1406144835@sandelman.ca> Date: Wed, 23 Jul 2014 16:57:17 -0400 Message-id: References: <2586.1406144835@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUiON3OWHej4oVgg7t/ZC3eL53F6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDm7zrAWdAlXbGvoZmlg3MPfxcjJISFgItHadIIRwhaTuHBv PVsXIxeHkMAcJok3004ygSR4BQQlfky+x9LFyMHBLCAvcfC8LEiYWUBL4vujVhYQW0hgKpPE kmMCMDNXHN/BAjGnl0ni46c/rCAJYQFXianHN4E1sAmoSfye1AcW5xTQltg07zqYzSKgKvH6 yyQWiAVeEq2np4Dt5RWwkZh6swpiV4XE4x972EBsEQE9ieVHnkHdLy/x4cNxdpC9EgLT2CSO r2tmmcAoPAvJC7MQXpiF5IUFjMyrGIVyEzNzdDPzjPQSCwpyUvWS83M3MUJCWHAH4/FVVocY BTgYlXh4O/aeDxZiTSwrrsw9xCjNwaIkzstxASgkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB 0VDqoNCn84qrJ/peuzS3a3+41PQX+WefGVxedPaFlBB70yH1OusTpZn3ru+432E67dXi24YW n1Jm/FVzOLnXck+I5kI2O+kwMc2XJ3u8Ku2KZ/n1+bMmHZx59kXLpfWhmxMczNYFNJQuTuZz s9GU0v599znDredveYP+HqpUeSRlcefBD1UrJiWW4oxEQy3mouJEAMWdYyFCAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUiOFO7Rnez4oVggyv/VS3eL53FaHFpxRFW i55D/ewWR77FOrB4bD35g81jyZKfTB6tO/6ye7TM2cMcwBLFZZOSmpNZllqkb5fAlbHjwTbG gvPCFWtmfGVqYHzI38XIySEhYCKx4vgOFghbTOLCvfVsXYxcHEICvUwSG45+YARJCAu4Skw9 vgmsiFfAQGLJrk3MIDazgJbEjX8vmUBsNgE1id+T+lhBbE4BbYnL87+xgdgsAqoSr79MAurl AKr3kWg/4QvRqi2xbOFrZoiRNhKzjhwDWyUkUCKx7UkH2EgRAT2J5UeeMULcJi/x4cNx9gmM /LOQXDELyRWzkIxdwMi8ilGgKDUnsdJYL7GgICdVLzk/dxMjKDAbCoN3MP5ZZnWIUYCDUYmH t2Pv+WAh1sSy4srcQ4wSHMxKIrx/vgOFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8y6fdDZYSCA9 sSQ1OzW1ILUIJsvEwSnVwLgg7OdFuTXm17zSPDw+P9rHU2n4tXm/p9ifcJs7W84935G0arFT +vRn7sorrVKLl57cP/9jj5vBwynJ/NktL7MmRKd/PtH5qPHq7ZXLOPfHeVc+y277/sB4b/6V 1Mi6e6cvzmNKlT9WYO+W6cPXW3m6vv7zYvGQK6XbReKOPHbVXqD55/vTzG1KLMUZiYZazEXF iQCHEX0ZSAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/8RhtbcamAa-JY72gKF0Pi3xJshk Cc: "dnssd@ietf.org" , Dave Thaler Subject: Re: [dnssd] Generalized service discovery requirements/goals X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 20:57:24 -0000 Michael, On Jul 23, 2014, at 3:47 PM, Michael Richardson wrote: > Dave Thaler wrote: >> 1) Three levels of identifiers: > >> a. A "service" (e.g.., a type of device, server, or application) to >> discover instances of. > > So, "printer"? > >> b. A particular "instance" of a service running on a specific network >> node, potentially reachable via multiple endpoints. There can be >> multiple instances per service. > > So, does this mean that the printer has multiple trays with different colours > of paper, or rather that maybe it is really a print server that has multiple > queues for different physical devices? In the context of Bonjour, LDAP, and SLP, the instance represents the printer. For IPP we advertise the primary/default print service, and have supplemental information pointing to any fax or scan services on the same printer. Things like the embedded web interface on the printer use parallel HTTP service registrations (same instance name, different type). (there is also a bunch of "flagship service/protocol" stuff that happens for Bonjour printers, but let's not muddy the waters too much...) A single print server that represents multiple physical printers will register/advertise a separate print service (and instance) for each printer. >> c. A particular endpoint (e.g., IP address + port) at which an >> instance can be reached. There might be multiple endpoints (e.g., IPv4 >> and IPv6) per instance. > > So the print server is attached to both the wired and wireless networks with > different addresses? Or even just a single network with multiple IPv4 and IPv6 addresses. > ... >> simple protocol queries underneath. Power-efficiency: Power >> conservation is becoming increasingly important. With this trend comes >> the need to support discovery of services that are in a low-power >> state. > > Is finding a printer that has been recently used, and is therefore still warm > and powered on interesting as well? So, it's not just that you want to > discover it even if it is off, but you also want to know when it was last > discovered? This is actually not particularly useful. Knowing which printer the user last used on a particular network is often what you want. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair From nobody Wed Jul 23 15:40:58 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCAF1B2936 for ; Wed, 23 Jul 2014 15:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 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, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=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 V5aW81vf9hZ4 for ; Wed, 23 Jul 2014 15:40:54 -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 1C73A1B28CE for ; Wed, 23 Jul 2014 15:40:52 -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 s6NMei0u005606; Wed, 23 Jul 2014 23:40:44 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s6NMei0u005606 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1406155245; bh=kpScY+Np4Griuu70gJ6ilIvQf8w=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=fgTxe/poJAHmy1fCw1UTfqHLm/XnKTRb+v9PowDkliVCUhztU7Albqbg7s58ZhPi1 zdp0DaADBFkkwyXE+hzjsFkiUne22a7PI+lMujQks1JWR86jqoZxlt3UFDzQcgiUaL xEERTAmeb5WsN6tA+nILxnU/PDFp7dVGEuodS0s4= 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 q6MNei04221073484Y ret-id none; Wed, 23 Jul 2014 23:40:44 +0100 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s6NMeewm016671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Jul 2014 23:40:41 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_93E39B07-AD2F-47EF-AA8D-2DC46545699E" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Chown In-Reply-To: <94FE061A-51FF-4F18-906F-703D16E9F303@gmail.com> Date: Wed, 23 Jul 2014 23:40:39 +0100 Message-ID: References: <10DC3A23-5ABF-4D01-97AE-17C5E488F664@ecs.soton.ac.uk> <0022F0DD-AEC8-4222-8F74-E38399B6B02D@gmail.com> <609AC6B1-C544-4CF1-A1D9-0468D72C963B@ecs.soton.ac.uk> <94FE061A-51FF-4F18-906F-703D16E9F303@gmail.com> To: Douglas Otis X-Mailer: Apple Mail (2.1878.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q6MNei042210734800; tid=q6MNei04221073484Y; 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: s6NMei0u005606 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/Qinns9cADTifpcwApmr58rk3PyA Cc: dnssd@ietf.org Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-requirements-03 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 22:40:57 -0000 --Apple-Mail=_93E39B07-AD2F-47EF-AA8D-2DC46545699E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, On 23 Jul 2014, at 21:14, Douglas Otis wrote: > Dear Tim, >=20 > See comments inline: >=20 > On Jul 22, 2014, at 5:35 PM, Tim Chown wrote: >=20 >> Hi, >>=20 >> Thanks for your comments Doug. >>=20 >> On 8 Jul 2014, at 01:47, Douglas Otis wrote: >>=20 >>> On Jul 7, 2014, at 2:46 AM, Tim Chown wrote: >>>=20 >>>> Hi, >>>>=20 >>>> This email begins a two week WGLC on = draft-ietf-dnssd-requirements-03, "Requirements for Scalable DNS-SD/mDNS = Extensions=94. >>>>=20 >>>> Ralph and I as chairs believe the authors have addressed the issues = raised at IETF89 and on the list since.=20 >>>>=20 >>>> You can see the draft here: >>>> http://tools.ietf.org/html/draft-ietf-dnssd-requirements-03 >>>=20 >>> Dear dnssd-wg, >>>=20 >>> 1) Layer 2 solutions intentionally ignored. >>>=20 >>> One of the primary goals for extending mDNS per the Educause = petition was to enable access to remote displays. Unfortunately, layer = 3 routing is generally prohibited with unlicensed nodes in conveyance of = copyright media. While layer 2 solutions are able to overcome = multi-bridge limitations imposed by media compliance requirements, this = has been ignored by the Scalable DNS-SD/mDNS requirements documentation = to the point of being ruled out-of-scope for discussion because of an = assumed need for layer 3 only solutions. Nevertheless, layer 3 = solutions are normally precluded when not licensed as a means to ensure = constraint of media redistribution. A quandary that could have been = avoided by determining common strategies that could be used by either = layer 2 or 3. For example, many routers are able to handle GUA+ULA. = Layer 3 and 2 might be considered analogous when ULAs are mapped to = MACs.=20 >>=20 >> You need to be more explicit at what you mean here. The purpose of = dnssd is to allow DNS-based service discovery in multi-subnet = environments, such as campuses and future home networks (as defined in = the homenet WG). If your network is a flat layer 2 network, that = particular problem doesn=92t exist. >>=20 >> In addition, REQ14 states: >> REQ14: SSD should operate over existing networks (as described by >> use cases A-F above) without requiring changes to the network >> technology or deployment. >>=20 >> Regarding ULAs, the homenet-arch text describes the use of ULAs = alongside GUAs in multi-link home networks. ULAs can then be used for = internal communications, regardless of the GUAs, or changes in the GUAs. = GUAs are then used for external communications. >=20 > Agreed, but when a GUA is used and published, this should exclude = devices unable to safely terminate a session from the Internet. It is = not safe to advertise such addresses in DNS, especially when security = depends on address obscurity.=20 There was recently quite a long thread in homenet about publishing home = devices in the global DNS, and how the homenet naming service can be = operated. You might want to look at that if you havent already. The archive is at: = http://www.ietf.org/mail-archive/web/homenet/current/maillist.html The related draft is: = http://datatracker.ietf.org/doc/draft-mglt-homenet-naming-architecture-dhc= -options/ And the topic started here: = http://www.ietf.org/mail-archive/web/homenet/current/msg03702.html >> Not sure what you mean by ULAs being mapped to MACs. >=20 > After reading the latest HDCP specification, concerns related to = routing limitations were misplaced and peer-to-peer changes further = reduce the concerns. Please ignore needing an alternative for Educause.=20= Ah, OK. >>> 2) Many devices within a typical network may announce routable = addresses via mDNS but are nevertheless unable to authenticate the = access permitted when these mDNS resources are conveyed in DNS. >>> ,-- >>> The following is a summary of the technical requirements: >>> ... >>> o It must be cost-effective to manage at up to enterprise scale. >>> '-- >>>=20 >>> Being unable to differentiate locality for those devices unable to = handle Internet originating sessions, as in the printer example, means = the Scalable DNS-SD/mDNS extension is NOT manageable at any scale. >>=20 >> The charter states that a user away from a network should be able to = discover devices in their =91home=92 network, which implies a remote = proxy discovery capability, and GUAs for reachability. We should = distinguish discoverability (including across the potential range of = discovery =91scopes=92) from reachability (e.g. whether ACLs may exist = on the path) from accessability (e.g. access control on the device). >=20 > Normal practices depend on use of a gateway authenticating clients, = such as use of VPNs. In such cases, service discovery can return ULAs = which permits router bridging within a multi-router home network. It = sounds like Ran wants to configure devices within a data-center. It = might be helpful to reinforce a need to exclude FD::/8 addresses over = Internet access links. Only devices able to terminate Internet sessions = should be published globally. Unfortunately, it is impossible to make = such a determination based on mDNS resources. This inability makes such = a simplistic approach both unsafe and unmanageable. =20 Well, within a multi-link network you have to expose an address with = scope greater than link-local to the querier for them to be able to = reach the service they are discovering. So yes, ULAs wiithin the home = could make sense, so you discover services with addresses you know you = can use regardless of the external connectivity status (or at least = that=92s the same argument as using ULAs in parallel with GUAs in = homenet to give session survivability etc in the presence of addess = =91disruption=92 by the ISP. I don=92t think there=92s any assumption in homenet that you=92d VPN to = the home, or via some home proxy, to access internal services. There = has been a lot of discussion in v6ops and opsec (I think) about default = home CER filtering settings. >>> Since different network realms are expected to permit device access = behind different bridges based on their "routable" mDNS resources = published in DNS, this circumvents a strategy of differentiating local = origination. This becomes particularly problematic when different IPv6 = prefixes are dynamically in use. >>=20 >> The homenet arch postulates that ULAs can loosely be used as a hint = of connection origin. >=20 > Agreed. But none of the related wg drafts clarify essential roles ULAs = have in securing a Hybrid mDNS to DNS approach. Within a dynamic = multiple-prefix environment, ULA and RFC1981 space are essential in = establishing stable and identifiable network perimeters. Such = perimeters defend devices that don't expect direct access from the = Internet or split-horizon DNS, as some have suggested. =20 Let=92s see what the WG says in the session. >>> In the Security Consideration Section, the union of DNS-SD and mDNS = would be zero since DNS-SD claims it to be a data structure creating no = security concerns. The union of zero with anything is zero. >>=20 >> Not sure what you mean there - please expand. >=20 > Sorry, a mistake was made confusing union with intersection. = Nevertheless, the security consideration statement misrepresents = security concerns being a combination of mDNS and DNS-SD security = considerations. DNS-SD security considerations specification claims it = adds no new security concerns. Such a view implies SSD security = consideration are limited to those affecting mDNS. However, mDNS is = confined to the bridge, whereas DNS removes this constraint. Such a = change has a tremendous, albeit ignored, security impact. Right, potentially, and Hosnieh will talk to that in her slot, I think. = You=92re right it=92s important. And privacy too. >>> Does REQ6 have priority over that of REQ14? >>> ,-- >>> REQ6: SSD must not adversely affect or break any other current >>> protocols or deployments. >>> '-- >>> ,-- >>> REQ14: SSD should operate over existing networks (as described by >>> use cases A-F above) without requiring changes to the = network >>> technology or deployment. >>=20 >> Ah. So I think REQ6 should say =93any other current service discovery = protocols or deployments.=94. >=20 > The follow-on sentence attempted to clarify a paradox created by the = simplified view when REQ14 is not seen in conflict with REQ6.=20 >=20 >>> mDNS is restricted to a single link. The envisioned multi-link = configuration affects the discovery and scope of the related services = which may break current protocols and/or substantially increase their = vulnerabilities. >>=20 >> Well, I agree there=92s certainly privacy and security issues if = devices become discoverable over a wider =92scope', which I believe = Hosnieh is going to talk about. >=20 > Disagree. Significant issues are related to erosion of network = permitters not being considered. For example, this draft could have = included a reference to RFC6950 to expand on relevant DNS issues related = to securing the proposed automatic publication by SSD that only excludes = link-local and RFC1918. Although posted on the mailing-list, my review = failed to include this reference. Two reasons for me to blush, but in = essence security considerations ignored Internet originating threats = permitted by obfuscation of network perimeters by promoting mDNS into = DNS.=20 RFC6950 certainly looks relevant. >>> 6.4. Authentication >>> ... >>> was: >>> ,-- >>> If there is a risk that clients may be fooled by the deployment of >>> rogue services, then application layer authentication should be >>> considered as part of any security solution. Authentication of any >>> particular service is outside the scope of this document. >>> '-- >>>=20 >>> should be: >>> ,-- >>> When there is risk that either clients or devices may be spoofed >>> by malefactors, then a network overlay or application layer=20 >>> authentication strategy should be considered. Authentication of >>> or by any particular service is outside the scope of this document. >>> =91-- >>=20 >> What you=92re hinting at I think is to use ULAs as a hint of = connection origin, to distinguish from external access. A question is = whether a device that is only intended to be used internally should be = published, and thus discoverable, externally. >=20 > Default behaviors should be secure. At minimum, there should be a = means to recognize whether a device can be directly discoverable and = accessible from the Internet. This DMZ determination should be = considered limited to manual configuration. >=20 >>> For example, it is not practical to expect a printer will ever be = able to authenticate a client. >>=20 >> Many home network devices certainly do support authentication. = Although often they=92re left with default factory settings=85. >=20 > In the case of most consumer printers employing IPv6, they often make = use of SLAAC or DHCP and report routable IPv6 addresses in mDNS = resources. While these devices may support authentication in = administrative configuration functions, only MAC filters constrain = sending a fax, printing, scanning, etc. Such constraints can't be used = and still permit router bridging. In other words, there is no = protection and no logging to even permit effective monitoring. A home device may have a link-local, ULA and GUA - we should be clear on = how/whether/when the ULA and/or GUA are used in any proxy scheme. There = is also the question of what the proxy then effectively publishes = externally. Stuart is recapping the Hybrid Proxy proposal tomorrow. >>> An overlay network can consist of GUA+ULA without change to network = technology or deployment. ULAs can limit access to trusted users having = immediate access to the local network realms. ULAs also avoid DNS = deployment that attempt to merge local with global using complex and = risky split-horizon configurations. ULAs already serve as the basis for = BTMM configurations which avoids publishing resources for devices like = printers unable to authenticate an external session. >>=20 >> So ULAs could be used in a home, and they might be used in an = enterprise - whether there that=92s alongside GUAs or with NPTv6 is = another question. >=20 > It seems reasonable for ULAs to be used in both environments, with = only selected devices moved manually into the DMZ. In both environments = use of VPNs or secure tunneling is increasingly common.=20 There is probably different behaviour/practice in home and = enterprise/campus networks. But I have no data to support that. Tim >=20 > Regards, > Douglas Otis >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_93E39B07-AD2F-47EF-AA8D-2DC46545699E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi,

On 23 Jul 2014, at 21:14, Douglas Otis = <doug.mtview@gmail.com>= wrote:

Dear = Tim,

See comments inline:

On = Jul 22, 2014, at 5:35 PM, Tim Chown <tjc@ecs.soton.ac.uk> = wrote:

Hi,

Thanks for your comments Doug.
On 8 Jul 2014, at 01:47, Douglas = Otis <doug.mtview@gmail.com> = wrote:

On Jul 7, 2014, at 2:46 AM, Tim Chown <tjc@ecs.soton.ac.uk> = wrote:

Hi,

This email begins a two week = WGLC on draft-ietf-dnssd-requirements-03, "Requirements for = Scalable DNS-SD/mDNS Extensions=94.

Ralph and I as chairs believe the authors = have addressed the issues raised at IETF89 and on the list = since. 

You can see the draft here:

Dear = dnssd-wg,

1) Layer 2 solutions intentionally = ignored.

One of the primary goals for extending = mDNS per the Educause petition was to enable access to remote displays. =  Unfortunately, layer 3 routing is generally prohibited with = unlicensed nodes in conveyance of copyright media.  While layer 2 = solutions are able to overcome multi-bridge limitations imposed by media = compliance requirements, this has been ignored by the Scalable = DNS-SD/mDNS requirements documentation to the point of being ruled = out-of-scope for discussion because of an assumed need for layer 3 only = solutions.  Nevertheless, layer 3 solutions are normally precluded = when not licensed as a means to ensure constraint of media = redistribution.  A quandary that could have been avoided by = determining common strategies that could be used by either layer 2 or 3. =  For example, many routers are able to handle GUA+ULA.  Layer = 3 and 2 might be considered analogous when ULAs are mapped to = MACs. 

You need to be more = explicit at what you mean here.  The purpose of dnssd is to allow = DNS-based service discovery in multi-subnet environments, such as = campuses and future home networks (as defined in the homenet WG). If = your network is a flat layer 2 network, that particular problem doesn=92t = exist.

In addition, REQ14 = states:
REQ14:  =
SSD should operate over existing networks (as described by
        use cases A-F above) without requiring changes to the network
        technology or =
deployment.

Regarding ULAs, the = homenet-arch text describes the use of ULAs alongside GUAs in multi-link = home networks. ULAs can then be used for internal communications, = regardless of the GUAs, or changes in the GUAs. GUAs are then used for = external = communications.

Agreed, but = when a GUA is used and published, this should exclude devices unable to = safely terminate a session from the Internet.  It is not safe to = advertise such addresses in DNS, especially when security depends on = address = obscurity. 

There = was recently quite a long thread in homenet about publishing home = devices in the global DNS, and how the homenet naming service can be = operated. You might want to look at that if you havent = already.
The archive is at: http://www.ietf.org/mail-archive/web/homenet/current/maillist.html
And the topic started = here: http://www.ietf.org/mail-archive/web/homenet/current/msg03702.html

Not sure what you mean by ULAs = being mapped to MACs.

After = reading the latest HDCP specification, concerns related to routing = limitations were misplaced and peer-to-peer changes further reduce the = concerns.  Please ignore needing an alternative for = Educause. 

Ah, = OK.

2) Many devices within a = typical network may announce routable addresses via mDNS but are = nevertheless unable to authenticate the access permitted when these mDNS = resources are conveyed in DNS.
,--
The following is a = summary of the technical requirements:
...
o  It must be = cost-effective to manage at up to enterprise scale.
'--

Being = unable to differentiate locality for those devices unable to handle = Internet originating sessions, as in the printer example, means the = Scalable DNS-SD/mDNS extension is NOT manageable at any = scale.

The charter states that a = user away from a network should be able to discover devices in their = =91home=92 network, which implies a remote proxy discovery capability, = and GUAs for reachability. We should distinguish discoverability = (including across the potential range of discovery =91scopes=92) from = reachability (e.g. whether ACLs may exist on the path) from = accessability (e.g. access control on the = device).

Normal practices depend = on use of a gateway authenticating clients, such as use of VPNs. =  In such cases, service discovery can return ULAs which permits = router bridging within a multi-router home network.  It sounds like = Ran wants to configure devices within a data-center.  It might be = helpful to reinforce a need to exclude FD::/8 addresses over Internet = access links.  Only devices able to terminate Internet sessions = should be published globally.  Unfortunately, it is impossible to = make such a determination based on mDNS resources.  This inability = makes such a simplistic approach both unsafe and unmanageable. =  

Well, within a = multi-link network you have to expose an address with scope greater than = link-local to the querier for them to be able to reach the service they = are discovering. So yes, ULAs wiithin the home could make sense, so you = discover services with addresses you know you can use regardless of the = external connectivity status (or at least that=92s the same argument as = using ULAs in parallel with GUAs in homenet to give session = survivability etc in the presence of addess =91disruption=92 by the = ISP.

I don=92t think there=92s any assumption = in homenet that you=92d VPN to the home, or via some home proxy, to = access internal services.  There has been a lot of discussion in = v6ops and opsec (I think) about default home CER filtering = settings.

Since different network realms = are expected to permit device access behind different bridges based on = their "routable" mDNS resources published in DNS, this circumvents a = strategy of differentiating local origination.  This becomes = particularly problematic when different IPv6 prefixes are dynamically in = use.

The homenet arch postulates that = ULAs can loosely be used as a hint of connection = origin.

Agreed. But none of the = related wg drafts clarify essential roles ULAs have in securing a Hybrid = mDNS to DNS approach.  Within a dynamic multiple-prefix = environment, ULA and RFC1981 space are essential in establishing stable = and identifiable network perimeters.  Such perimeters defend = devices that don't expect direct access from the Internet or = split-horizon DNS, as some have suggested. =  

Let=92s see = what the WG says in the session.

In the Security = Consideration Section, the union of DNS-SD and mDNS would be zero since = DNS-SD claims it to be a data structure creating no security concerns. =  The union of zero with anything is = zero.

Not sure what you mean there - = please expand.

Sorry, a mistake = was made confusing union with intersection. Nevertheless, the security = consideration statement misrepresents security concerns being a = combination of mDNS and DNS-SD security considerations.  DNS-SD = security considerations specification claims it adds no new security = concerns.  Such a view implies SSD security consideration are = limited to those affecting mDNS.  However, mDNS is confined to the = bridge, whereas DNS removes this constraint.  Such a change has a = tremendous, albeit ignored, security = impact.

Right, = potentially, and Hosnieh will talk to that in her slot, I think. =  You=92re right it=92s important.  And privacy = too.

Does REQ6 have priority = over that of REQ14?
,--
REQ6:   SSD must = not adversely affect or break any other current
    =        protocols or = deployments.
'--
,--
REQ14:  SSD should = operate over existing networks (as described by
    =        use cases A-F above) without requiring = changes to the network
          =  technology or = deployment.

Ah. So I think = REQ6 should say =93any other current service discovery protocols or = deployments.=94.

The follow-on = sentence attempted to clarify a paradox created by the simplified view = when REQ14 is not seen in conflict with = REQ6. 

mDNS is restricted to a = single link.  The envisioned multi-link configuration affects the = discovery and scope of the related services which may break current = protocols and/or substantially increase their = vulnerabilities.

Well, I = agree there=92s certainly privacy and security issues if devices become = discoverable over a wider =92scope', which I believe Hosnieh is going to = talk about.

Disagree. =  Significant issues are related to erosion of network permitters = not being considered.  For example, this draft could have included = a reference to RFC6950 to expand on relevant DNS issues related to = securing the proposed automatic publication by SSD that only excludes = link-local and RFC1918.  Although posted on the mailing-list, my = review failed to include this reference.  Two reasons for me to = blush, but in essence security considerations ignored Internet = originating threats permitted by obfuscation of network perimeters by = promoting mDNS into = DNS. 

RFC6950 = certainly looks relevant.

6.4. =  Authentication
...
was:
,--
=
If there is a risk that clients may be fooled by the deployment = of
rogue services, then application layer authentication = should be
considered as part of any security solution. =  Authentication of any
particular service is outside the = scope of this = document.
'--

should = be:
,--
When there is risk that either clients = or devices may be spoofed
by malefactors, then a network = overlay or application layer 
authentication strategy = should be considered. Authentication of
or by any particular = service is outside the scope of this = document.
=91--

Wha= t you=92re hinting at I think is to use ULAs as a hint of connection = origin, to distinguish from external access. A question is whether a = device that is only intended to be used internally should be published, = and thus discoverable, = externally.

Default behaviors = should be secure.  At minimum, there should be a means to recognize = whether a device can be directly discoverable and accessible from the = Internet.  This DMZ determination should be considered limited to = manual configuration.

For example, it is not practical = to expect a printer will ever be able to authenticate a = client.

Many home network devices = certainly do support authentication. Although often they=92re left with = default factory settings=85.

In = the case of most consumer printers employing IPv6, they often make use = of SLAAC or DHCP and report routable IPv6 addresses in mDNS resources. =  While these devices may support authentication in administrative = configuration functions, only MAC filters constrain sending a fax, = printing, scanning, etc.  Such constraints can't be used and still = permit router bridging.  In other words, there is no protection and = no logging to even permit effective = monitoring.

A home = device may have a link-local, ULA and GUA - we should be clear on = how/whether/when the ULA and/or GUA are used in any proxy scheme. There = is also the question of what the proxy then effectively publishes = externally. Stuart is recapping the Hybrid Proxy proposal = tomorrow.

An overlay network can consist = of GUA+ULA without change to network technology or deployment. =  ULAs can limit access to trusted users having immediate access to = the local network realms.  ULAs also avoid DNS deployment that = attempt to merge local with global using complex and risky split-horizon = configurations.  ULAs already serve as the basis for BTMM = configurations which avoids publishing resources for devices like = printers unable to authenticate an external = session.

So ULAs could be used in a = home, and they might be used in an enterprise - whether there that=92s = alongside GUAs or with NPTv6 is another = question.

It seems reasonable for = ULAs to be used in both environments, with only selected devices moved = manually into the DMZ.  In both environments use of VPNs or secure = tunneling is increasingly = common. 

There = is probably different behaviour/practice in home and enterprise/campus = networks. But I have no data to support = that.

Tim


Regards,
Dougl= as = Otis

_______________________________= ________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/= mailman/listinfo/dnssd

= --Apple-Mail=_93E39B07-AD2F-47EF-AA8D-2DC46545699E-- From nobody Wed Jul 23 15:43:44 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1692B1B29CC for ; Wed, 23 Jul 2014 15:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.222 X-Spam-Level: X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=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 KKSCL2i3WuaW for ; Wed, 23 Jul 2014 15:43:41 -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 6A0DB1B2942 for ; Wed, 23 Jul 2014 15:43:41 -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 s6NMhcuL006108; Wed, 23 Jul 2014 23:43:38 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s6NMhcuL006108 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1406155419; bh=bCDv1n48j/guaL8Si4kv+kJZ8Vk=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=fy6g5ZfXYBuP19eWcRmwnQJSJbFIYzMdYtG9BU/Ca0nneZL0TiBNSSsXwEXL8LeIY 5ilBL56aS8WxMAYdxpeF+wLeOGz6hjp+xFzLWMyB8XhppML0fDgPV/7VBGhXFyWpqT 7p6PXa6z5yATWxkos9zXmXmPig3rjn2QQNjM3SMk= 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 q6MNhc0422107364XF ret-id none; Wed, 23 Jul 2014 23:43:39 +0100 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s6NMhYgF017048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Jul 2014 23:43:35 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Chown In-Reply-To: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> Date: Wed, 23 Jul 2014 23:43:34 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> <4FDF75D1-28F0-47DA-ABA9-8B4B36F7CD0B@ecs.soton.ac.uk> To: RJ Atkinson X-Mailer: Apple Mail (2.1878.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q6MNhc042210736400; tid=q6MNhc0422107364XF; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s6NMhcuL006108 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/0tvN_PYKDsnMROHOpkKRwsFXipU Cc: dnssd@ietf.org Subject: Re: [dnssd] Security through Obscurity X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 22:43:43 -0000 On 23 Jul 2014, at 21:51, RJ Atkinson wrote: >=20 > (NOTE WELL: I am not a WG Chair, IESG member, IAB member, > or authorised spokesperson for anyone other than myself.) >=20 >=20 > Earlier Doug Otis wrote: >> It is not safe to advertise such addresses in DNS,=20 >> especially when security depends on address obscurity. >=20 >=20 > I believe that the the vast majority of security folks > would object to the notion that obscurity is a mechanism=20 > capable of providing any meaningful security. >=20 > If a client were to ask me for advice on protecting their > interior services or interior devices from the global Internet,=20 > I would suggest at least a firewall (ranging from router ACLs=20 > to an air-gap: depending upon their local needs and threat model)=20 > and possibly also other measures (again, depending upon local > needs and threat model). Operational security is not=20 > one-size-fits-all, in my experience, but relying upon=20 > security-through-obscurity seems unwise to me. Indeed. Though I=92d argue that work such as RFC 7217 still has value. >> It sounds like Ran wants to configure devices within a data-center. >=20 >=20 > Incorrect. To be very clear, my post to DNS-SD WG from earlier=20 > this week definitely was NOT focused on data centre environments.=20 I certainly didn=92t take it that way. Tim >=20 > Yours, >=20 > Ran >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Wed Jul 23 15:48:01 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07501B2942 for ; Wed, 23 Jul 2014 15:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 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, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=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 25qU1P-gryar for ; Wed, 23 Jul 2014 15:47:58 -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 9D5171B28BA for ; Wed, 23 Jul 2014 15:47:58 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s6NMlqvU007439 for ; Wed, 23 Jul 2014 23:47:52 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s6NMlqvU007439 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1406155673; bh=7+BuTzF9e30my2o4vkv3FNxzQJg=; h=From:Subject:Date:To:Mime-Version:References; b=YPlVuLwUixlVXM2a8ttITLzl4sYap1TGulbxZEST3QSactgz4o5BeVuWxQPiwmlJH C5tnXuKYWBAkxCqvgJ87U7pYmg5uRWXG2DgVFmPaygt0kSOkGjiWg7YBe7BnyqFZHx 5tyH24lPFed3j2tMvM2sw18Zmz23pD/9TEknScAc= 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 q6MNlq0422107379Yv ret-id none; Wed, 23 Jul 2014 23:47:52 +0100 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s6NMlmI3018038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 23 Jul 2014 23:47:49 +0100 From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_CD856E78-98D8-416A-87F7-2D9FD1285874" Message-ID: Date: Wed, 23 Jul 2014 23:47:48 +0100 To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q6MNlq042210737900; tid=q6MNlq0422107379Yv; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: <8ECA5661-D36E-4C7E-A168-7CCCB1173B34@ecs.soton.ac.uk> X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s6NMlqvU007439 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/dc1WvBnyUDW5ImcKosKpf-OgNB4 Subject: [dnssd] Pre-session info for dnssd WG meeting X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 22:47:59 -0000 --Apple-Mail=_CD856E78-98D8-416A-87F7-2D9FD1285874 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 IETF90 dnssd meeting 3.20pm EDT, 24th July, Canadian room Meeting Agenda: https://datatracker.ietf.org/meeting/90/agenda/dnssd/ Meeting Materials (slides): https://datatracker.ietf.org/meeting/90/materials.html#dnssd Charter: https://datatracker.ietf.org/wg/dnssd/charter/ WG-related drafts: https://datatracker.ietf.org/wg/dnssd/documents/ Remote participation: http://www.ietf.org/meeting/90/remote-participation.html (noting room is Canadian, channel 2) Meetecho is available and being used for remote presentation The main goals of this session are to: 1) Review the WGLC of the requirements draft, and if appropriate send = the document to the IESG for publication 2) Better understand dnssd security and privacy issues 3) Check where we are on =91things we need to standardise=92, as = originally discussed at the previous IETF 4) Review the Hybrid Proxy draft against the requirements, with = potential to adopt as a candidate WG solution item All WG participants are thus urged to read at least http://tools.ietf.org/html/draft-ietf-dnssd-requirements-03 in advance of the session. Best wishes, Tim --Apple-Mail=_CD856E78-98D8-416A-87F7-2D9FD1285874 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
IETF90 dnssd = meeting
3.20pm EDT, 24th July, = Canadian room

Meeting Agenda:

Meeting = Materials (slides):

Charter:

WG-related = drafts:

Remote = participation:
(noting room is Canadian, channel 2)
Meetecho is available and being used for remote = presentation

The main goals of this = session are to:
1) Review the WGLC of = the requirements draft, and if appropriate send the document to the IESG = for publication
2) Better understand = dnssd security and privacy issues
3) = Check where we are on =91things we need to standardise=92, as originally = discussed at the previous IETF
4) = Review the Hybrid Proxy draft against the requirements, with potential = to adopt as a candidate WG solution item

All WG = participants are thus urged to read at least
in advance of the session.

Best wishes,
Tim

= --Apple-Mail=_CD856E78-98D8-416A-87F7-2D9FD1285874-- From nobody Wed Jul 23 18:27:38 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C226C1A026A for ; Wed, 23 Jul 2014 18:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 qHsbhUtXtIZU for ; Wed, 23 Jul 2014 18:27:36 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E8BD1A019A for ; Wed, 23 Jul 2014 18:27:36 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t60so2032464wes.34 for ; Wed, 23 Jul 2014 18:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=F2cdt3Q+e8Miws/TPAzYxrnOzrgtMZCdljcX2bYncsE=; b=yapf7KPEjod9G8nwMdYzhwEPlxs8259joq75RVQXxzSY1myCFcv9ZfR8+HnNkJVQ/l Gldki8XGjZvgTuEktbUgDxZqJSgabTWbyLnaUwyoOtCwtafk3ZLXM7o+VdbzLewbYktX mFdihyU7U4gMOvD3YN1DYG29LsfWOkiJY4tpudQofU63LG8ZX+4lgyd8rvgy1Nl5OYt2 D0XRC0JkPm7b1tHyl/j4Ah3uvwKQ9D7Stkb/Zlk0EfP+8gzZncYQHOjpaVU8SpzAxM9e 5POfXp8qUvyx6ai9bSxsocddOrMyZvzKyvRN/RaRFNG1EqRV+xwps6b1UJ/BwUwIEhgI ULpQ== X-Received: by 10.194.62.140 with SMTP id y12mr7138673wjr.27.1406165255109; Wed, 23 Jul 2014 18:27:35 -0700 (PDT) Received: from [192.168.11.129] (dhcp-8b54.meeting.ietf.org. [31.133.139.84]) by mx.google.com with ESMTPSA id ub11sm16279558wib.1.2014.07.23.18.27.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 18:27:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> Date: Wed, 23 Jul 2014 21:27:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <20E4ED19-12BD-45D4-B690-8629B552B23B@gmail.com> References: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/AuGpseayQDPLWr8RxKE1cd3ln7I Cc: dnssd@ietf.org, Douglas Otis Subject: Re: [dnssd] Security through Obscurity X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 01:27:37 -0000 On Jul 23, 2014, at 4:51 PM, RJ Atkinson wrote: >=20 > (NOTE WELL: I am not a WG Chair, IESG member, IAB member, > or authorised spokesperson for anyone other than myself.) >=20 >=20 > Earlier Doug Otis wrote: >> It is not safe to advertise such addresses in DNS,=20 >> especially when security depends on address obscurity. >=20 >=20 > I believe that the the vast majority of security folks > would object to the notion that obscurity is a mechanism=20 > capable of providing any meaningful security. >=20 > If a client were to ask me for advice on protecting their > interior services or interior devices from the global Internet,=20 > I would suggest at least a firewall (ranging from router ACLs=20 > to an air-gap: depending upon their local needs and threat model)=20 > and possibly also other measures (again, depending upon local > needs and threat model). Operational security is not=20 > one-size-fits-all, in my experience, but relying upon=20 > security-through-obscurity seems unwise to me. I agree with that statement, but at the same time some of these devices = are assigned routable addresses by the vendors. When assigned out of a = 48 bit space, it might be possible to guess the device based on common = manufacturers. When randomly assigned by the owner, it is highly = unlikely such an address will ever be guessed. Add rate limiting, and = this unknown should work well at mitigating attack. But as I said, I = agree with your statement and why I think mDNS should be working with = ULAs. Regards, Douglas Otis= From nobody Wed Jul 23 18:43:13 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95BEC1A036E for ; Wed, 23 Jul 2014 18:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 0pUCUi_lBnIL for ; Wed, 23 Jul 2014 18:43:07 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 400901A0305 for ; Wed, 23 Jul 2014 18:43:07 -0700 (PDT) Received: from dhcp-8415.meeting.ietf.org (dhcp-8415.meeting.ietf.org [31.133.132.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 9D17C13386; Wed, 23 Jul 2014 21:43:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1971.5\)) From: Tom Pusateri In-Reply-To: <20E4ED19-12BD-45D4-B690-8629B552B23B@gmail.com> Date: Wed, 23 Jul 2014 21:43:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <15473CC1-E1C2-4AF1-AD2B-542AA138B0F2@bangj.com> References: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> <20E4ED19-12BD-45D4-B690-8629B552B23B@gmail.com> To: Douglas Otis X-Mailer: Apple Mail (2.1971.5) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/Kq5wwb0oGOYNrKlhoXVxT9Eg3qo Cc: dnssd@ietf.org, RJ Atkinson Subject: Re: [dnssd] Security through Obscurity X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 01:43:08 -0000 > On Jul 23, 2014, at 9:27 PM, Douglas Otis = wrote: >=20 >=20 > On Jul 23, 2014, at 4:51 PM, RJ Atkinson wrote: >>=20 >> If a client were to ask me for advice on protecting their >> interior services or interior devices from the global Internet,=20 >> I would suggest at least a firewall (ranging from router ACLs=20 >> to an air-gap: depending upon their local needs and threat model)=20 >> and possibly also other measures (again, depending upon local >> needs and threat model). Operational security is not=20 >> one-size-fits-all, in my experience, but relying upon=20 >> security-through-obscurity seems unwise to me. >=20 > I agree with that statement, but at the same time some of these = devices are assigned routable addresses by the vendors. When assigned = out of a 48 bit space, it might be possible to guess the device based on = common manufacturers. When randomly assigned by the owner, it is highly = unlikely such an address will ever be guessed. Add rate limiting, and = this unknown should work well at mitigating attack. But as I said, I = agree with your statement and why I think mDNS should be working with = ULAs. >=20 mDNS advertisements are link-local. Whether mDNS uses GUAs, ULAs, or = link-local addresses is irrelevant. I'll assume you meant the broader term DNS-SD. If so, then the scope of = the address is a matter best left up to the particular use case. There are arguments for all of them and a mix of them depending on what = you're trying to achieve. Bots operate inside private networks and can = do as much damage with ULAs as with GUAs. We need to stop thinking about an internal network and an external = network. There is just THE network. Your security should reflect the = fact that malfeasants will try to break into every one of your devices = and they all need the appropriate level of protection from this. If a = device is susceptible, that's not an DNS-SD problem, that's a device = problem. Tom From nobody Thu Jul 24 03:37:28 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AE31A01AE for ; Thu, 24 Jul 2014 03:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 KfWhlYnNUIvj for ; Thu, 24 Jul 2014 03:37:23 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A91B1A01A9 for ; Thu, 24 Jul 2014 03:37:23 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id bs8so3696838wib.2 for ; Thu, 24 Jul 2014 03:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=Gn0tPNydSqU6aUB5ppF0rryhpi2OrjaTgayB6E5C2r4=; b=XnzSuGYAhHVdF5N43tZZx7sQa9DL6hFwpD+fXENM5lXquMAmqst1yZv6xKQo9bDjJq E4suQrqVoUk9Hoi7Y7wUO+/AHJRNPAG+UvHXQJ+dDSqaX4367A4GWjqtMalmVJniiCW4 1ZLfsZIpvncVjmfkFXjFK9rLCSfVowqzwb6gLEzFJCgYhVYjRDB5Yqrs+AnqCMqmp4DF dNyCz4F8pE4AEjzyji8Z0Pj5JvUHqpVh/+Wxdzsu/MpJapYXuzyPszg0WambT75YskgB Tiv5o6eOHcgoNnC+rH5SCmgnaCfOhmU/6nH2+/NvpK19CSxN0CSXn7oaLLITvw4W2C/P ysjw== X-Received: by 10.194.222.230 with SMTP id qp6mr10853772wjc.23.1406198240360; Thu, 24 Jul 2014 03:37:20 -0700 (PDT) Received: from dhcp-92f8.meeting.ietf.org (dhcp-92f8.meeting.ietf.org. [31.133.146.248]) by mx.google.com with ESMTPSA id o12sm21433995wiw.5.2014.07.24.03.37.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 03:37:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: RJ Atkinson In-Reply-To: <15473CC1-E1C2-4AF1-AD2B-542AA138B0F2@bangj.com> Date: Thu, 24 Jul 2014 06:37:17 -0400 Content-Transfer-Encoding: 7bit Message-Id: <63C12F9B-63BD-4DC6-83C5-A6608FDA7568@gmail.com> References: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> <20E4ED19-12BD-45D4-B690-8629B552B23B@gmail.com> <15473CC1-E1C2-4AF1-AD2B-542AA138B0F2@bangj.com> To: dnssd@ietf.org X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/dLBqkEoLJzCVeEZjnMwIfJSn3MI Subject: [dnssd] Site deployment options X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 10:37:25 -0000 On 23 Jul 2014, at 21:43 , Tom Pusateri wrote: > mDNS advertisements are link-local. Agreed. > Whether mDNS uses GUAs, ULAs, or link-local addresses is irrelevant. > > I'll assume you meant the broader term DNS-SD. If so, then the scope > of the address is a matter best left up to the particular use case. > There are arguments for all of them and a mix of them depending on > what you're trying to achieve. Yes. There are a range of use cases. These use cases will vary in multiple dimensions, not just in choice of IP addressing model. For example, separate from the question of which types of IP addresses a particular operational domain uses internally, there will be variation in whether/how the ordinary (unicast) DNS is deployed. Considering the DNS axis of variation, one can imagine reasonable deployments where the operational domain might fall into one of several very different use cases: A) has no deployment of (unicast) DNS B) has a single (unicast) DNS instance of example.com, where the internal view is identical to the external view C) has a split-horizon DNS deployment of example.com D) other reasonable use cases probably exist Case (A) probably describes a large number of home networks and a fair number of small enterprise networks (e.g. dentist's office). Further, for case (B), a small site with its own domain name (e.g. example.com) might not have any full-time IT staff and might not have direct configuration control over the contents of its DNS. It might, for example, have outsourced its DNS to a service-provider, which in turn provides a web portal and a (very) limited set of configuration options (e.g. ability to specify IP addresses for a very small number of pre-defined network services such as inbound mail-relay and public web server). Case (C) probably is done most often at larger sites where full-time IT staff exist and the organisation's DNS instances are directly managed by their IT staff. Note well that any of these DNS deployment cases (A-D above) might use any combination of private-scope IPv4 addresses, IPv6 ULAs, and global-scope IP addresses for their unicast IP addressing deployments. As near as I can tell, addressing options are orthogonal to the DNS deployment options. > Bots operate inside private networks and can do as much damage > with ULAs as with GUAs. Yes. This means that defense-in-depth usually is the best option, where one has a firewall and also has other measures. However, general operational security concerns properly are topics for the IETF's OPsec WG. Bottom-Line: ------------ DNS-SD needs to work well regardless of the unicast IP addressing used and regardless of the (unicast) DNS deployment model used. I believe this is entirely possible -- without changing the large installed base of systems that support (mDNS + DNS-SD) today. Yours, Ran From nobody Thu Jul 24 06:08:38 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2147F1A011C for ; Thu, 24 Jul 2014 06:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 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, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=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 3UVn8hkzDy_l for ; Thu, 24 Jul 2014 06:08: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 771271A023E for ; Thu, 24 Jul 2014 06:08:29 -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 s6OD8Qlh009762; Thu, 24 Jul 2014 14:08:26 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s6OD8Qlh009762 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1406207306; bh=bWJk+cwuELQboJ+N2mW6AKK7v/g=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=N34yol/gkx9Jq6Mfc8y7mBwFkYD7+ZRO964J5e0vHXWxxY67glGhTBe7N0gM45p/2 2ybFhBsJDZ9cvY4NOCSQXaS//ktDqmnfTM0ED09LaQ68vo8/O5pnzzr/KFMa4Z5IxT vM0SVHcevZ7uz4S5ZXEej/xSSadyGsZMFGu31JY0= 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 q6NE8Q0176703795zK ret-id none; Thu, 24 Jul 2014 14:08:26 +0100 Received: from wireless-v6.meeting.ietf.org (wireless-v6.meeting.ietf.org [IPv6:2001:67c:370:160:dc56:20ab:e644:c208] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s6OD74AM000777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Jul 2014 14:07:06 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_543442ED-9830-47BE-BAF1-F6BC15412E04" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Chown In-Reply-To: <20E4ED19-12BD-45D4-B690-8629B552B23B@gmail.com> Date: Thu, 24 Jul 2014 14:07:03 +0100 Message-ID: References: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> <20E4ED19-12BD-45D4-B690-8629B552B23B@gmail.com> <0E0BC226-E68E-4BC2-99EA-AFF1AF96A5EC@ecs.soton.ac.uk> To: Douglas Otis X-Mailer: Apple Mail (2.1878.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q6NE8Q017670379500; tid=q6NE8Q0176703795zK; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s6OD8Qlh009762 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/yZlZZ5ECgLNs93pF-9ER2vOsZp0 Cc: dnssd@ietf.org, RJ Atkinson Subject: Re: [dnssd] Security through Obscurity X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 13:08:32 -0000 --Apple-Mail=_543442ED-9830-47BE-BAF1-F6BC15412E04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 24 Jul 2014, at 02:27, Douglas Otis wrote: >=20 > On Jul 23, 2014, at 4:51 PM, RJ Atkinson wrote: >=20 >>=20 >> (NOTE WELL: I am not a WG Chair, IESG member, IAB member, >> or authorised spokesperson for anyone other than myself.) >>=20 >>=20 >> Earlier Doug Otis wrote: >>> It is not safe to advertise such addresses in DNS,=20 >>> especially when security depends on address obscurity. >>=20 >>=20 >> I believe that the the vast majority of security folks >> would object to the notion that obscurity is a mechanism=20 >> capable of providing any meaningful security. >>=20 >> If a client were to ask me for advice on protecting their >> interior services or interior devices from the global Internet,=20 >> I would suggest at least a firewall (ranging from router ACLs=20 >> to an air-gap: depending upon their local needs and threat model)=20 >> and possibly also other measures (again, depending upon local >> needs and threat model). Operational security is not=20 >> one-size-fits-all, in my experience, but relying upon=20 >> security-through-obscurity seems unwise to me. >=20 > I agree with that statement, but at the same time some of these = devices are assigned routable addresses by the vendors. When assigned = out of a 48 bit space, it might be possible to guess the device based on = common manufacturers. When randomly assigned by the owner, it is highly = unlikely such an address will ever be guessed. Add rate limiting, and = this unknown should work well at mitigating attack. But as I said, I = agree with your statement and why I think mDNS should be working with = ULAs. Doug, if you mean a 48-bit MAC address being embedded in the IPv6 = address, see http://tools.ietf.org/html/rfc7217. I agree with Tom=92s comments. A question to discuss in your slot today = is when a device has a LL, ULA and GUA, which of those should be = advertised via the SD protocol and whether/how that choice can/should be = influenced.=20 Tim --Apple-Mail=_543442ED-9830-47BE-BAF1-F6BC15412E04 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On 24 = Jul 2014, at 02:27, Douglas Otis <doug.mtview@gmail.com> = wrote:


On Jul 23, 2014, at 4:51 PM, RJ Atkinson <rja.lists@gmail.com> = wrote:


(NOTE WELL: I am not a WG = Chair, IESG member, IAB member,
or authorised spokesperson for anyone = other than myself.)


Earlier Doug Otis wrote:
It is not safe to advertise such addresses in DNS, =
especially when security depends on address = obscurity.


I believe that the the vast majority = of security folks
would object to the notion that obscurity is a = mechanism
capable of providing any meaningful security.

If a = client were to ask me for advice on protecting their
interior = services or interior devices from the global Internet,
I would = suggest at least a firewall (ranging from router ACLs
to an air-gap: = depending upon their local needs and threat model)
and possibly also = other measures (again, depending upon local
needs and threat model). =  Operational security is not
one-size-fits-all, in my = experience, but relying upon
security-through-obscurity seems unwise = to me.

I agree with that statement, but at the same = time some of these devices are assigned routable addresses by the = vendors.  When assigned out of a 48 bit space, it might be possible = to guess the device based on common manufacturers.  When randomly = assigned by the owner, it is highly unlikely such an address will ever = be guessed.  Add rate limiting, and this unknown should work well = at mitigating attack.  But as I said, I agree with your statement = and why I think mDNS should be working with = ULAs.

Doug, if you mean a 48-bit MAC = address being embedded in the IPv6 address, see http://tools.ietf.org/html/rfc= 7217.

I agree with Tom=92s comments. A = question to discuss in your slot today is when a device has a LL, ULA = and GUA, which of those should be advertised via the SD protocol and = whether/how that choice can/should be = influenced. 

Tim

= = --Apple-Mail=_543442ED-9830-47BE-BAF1-F6BC15412E04-- From nobody Thu Jul 24 06:50:43 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA9C1A035B for ; Thu, 24 Jul 2014 06:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 96BedZ9oGSsM for ; Thu, 24 Jul 2014 06:50:27 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD871A0343 for ; Thu, 24 Jul 2014 06:49:37 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id n12so2824995wgh.9 for ; Thu, 24 Jul 2014 06:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=PhjSwsGBqrM/+i9aBak7R2yz+meFElSyC1MD+B0rQps=; b=WdGv++p6lYUgWhLza4ehDjdVaz1ECVdivR4CPCkB60XDLF+qAd0P7jEqkZNl5WaCP3 bkINXwCgbxmvVCEAyTOIRi/xNXZVQDa/OEGyRlwy5LrBcyDrveMnDmDyBKyFBtGabzg6 JMkyWX6i24DxAHVdk6eUmucPgawNwwvn2j0v4KyJ/QYH3oVyOVJcEJIcrsBWNWpA9i1I BFxnv6BcBiT0ECrEEvXJUXF4drvCRJRtSG2NzmkuMAKpqABBttHXZ6OIjDwun7TXdLpr FvvwZwSzP+S3qfuE2XEwEfqtQd9eQpnPNZ6X8soSom1XBUxP04cNRZYa2Z2wrWxgMlay WNJw== X-Received: by 10.180.108.1 with SMTP id hg1mr35776312wib.25.1406209776261; Thu, 24 Jul 2014 06:49:36 -0700 (PDT) Received: from dhcp-b535.meeting.ietf.org (dhcp-b535.meeting.ietf.org. [31.133.181.53]) by mx.google.com with ESMTPSA id lb3sm16056612wjc.30.2014.07.24.06.49.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 06:49:35 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1283) From: RJ Atkinson In-Reply-To: Date: Thu, 24 Jul 2014 09:49:31 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> <20E4ED19-12BD-45D4-B690-8629B552B23B@gmail.com> <0E0BC226-E68E-4BC2-99EA-AFF1AF96A5EC@ecs.soton.ac.uk> To: dnssd@ietf.org X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/r5ZgEHcvhrsyrVcIpYaiOxs2GQ0 Subject: Re: [dnssd] Security through Obscurity X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 13:50:32 -0000 On 24 Jul 2014, at 09:07 , Tim Chown wrote: > Doug, if you mean a 48-bit MAC address being embedded in the IPv6 address, > see http://tools.ietf.org/html/rfc7217. All, I think the notion of predictability of IPv6 Interface IDs is not germane to the DNS-SD discussions, for the reasons that various folks (e.g. Stuart Cheshire, Tim Chown, and Tom Pusateri) have explained already. Separately, in many environments, predictability of IP addressing of printers (or file servers or ...) is operationally DESIRABLE. However, just for the record, there also are a range of other RFCs, long predating RFC-7217, for generating IPv6 Interface IDs, going back for more than a decade. [References at bottom] I believe these various alternative IPv6 IID algorithms are widely implemented and deployed today, and that they have been widely implemented and deployed for many years now. Note, in some environments, especially business environments, the use of DHCP(v6) is operationally preferable to SLAAC because it provides PREDICTABILITY in IP address assignment. Also, in many environments where DHCP is NOT used, for example due to the costs associated with DHCP, it is STILL operationally DESIRABLE for an IPv6-capable device (e.g. network printer) to have the SAME PREDICTABLE IPv6 address each and every time the printer (re)boots. IPv6 SLAAC with an embedded MAC address thus is DESIRED in many environments -- especially for devices providing services that would be advertised using DNS-SD (e.g. network printer). Can we PLEASE get past individual hangups over *solved* problems that belong to other IETF WGs (e.g. IPv6 Ops, IPv6 Maint, OPsec) and instead stay on-topic for DNS-SD ? Thanks, Ran Atkinson REFERENCES: RFC-3041 January 2001 Privacy Extensions for Stateless IPv6 Address Auto-config RFC-3972 March 2005 Cryptographically Generated Addresses (CGAs) RFC-4941 September 2007 Revision of RFC-3041 RFC-4942 July 2007 Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs) RFC-5535 June 2009 Hash-based Addresses RFC-7217 April 2014 Generating Opaque Interface IDs with IPv6 SLAAC From nobody Thu Jul 24 07:37:41 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421561A01FF for ; Thu, 24 Jul 2014 07:37:39 -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 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 2XkCKsh0JbTf for ; Thu, 24 Jul 2014 07:37:31 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE7A1A000E for ; Thu, 24 Jul 2014 07:37:31 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id ADFD21B845A for ; Thu, 24 Jul 2014 07:37:31 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id A42D9190052; Thu, 24 Jul 2014 07:37:31 -0700 (PDT) Received: from [192.168.0.10] (99.232.25.196) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Jul 2014 07:37:25 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Thu, 24 Jul 2014 10:37:21 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <637BF7DE-8AA6-455B-853B-DDF0678C4D14@nominum.com> References: <10DC3A23-5ABF-4D01-97AE-17C5E488F664@ecs.soton.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [99.232.25.196] Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/3AZd4XAJ4U5Uve2XJl4x0ZFC26g Cc: dnssd@ietf.org Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-requirements-03 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 14:37:39 -0000 On Jul 22, 2014, at 5:19 PM, Tim Chown wrote: > The chairs would welcome any final comments in advance of Thursday = afternoon=92s dnssd session at IETF90, including from those who have = read the draft and believe it=92s ready to ship to the IESG. =20 (F) Mesh networks such as RPL/6LoWPAN: Multi-link subnets with prefixes defined by one or more border routers. May comprise any part of networks C, D, or E. This is a very minor nit, and there may be nothing that is worth doing = to address it, but I think that (F) applies to (B) as well, where (F) is = the only other network on the homenet. I mention this because I think = it's likely that this configuration will be the most common homenet+IoT = configuration. One way to address this would be to say something like = "May comprise any part of networks C, D or E. Networks B may become = networks C even in otherwise simple homenet deployments as a result of = adding a network F." REQ11: SSD must be scalable to thousands of nodes with minimal configuration and without degrading network performance. A possible figure of merit is that, as the number of services increases, the amount of traffic due to SSD on a given link remains relatively constant. Do you mean "remains relatively constant," or increases no more than = linearly? It seems unlikely for it to remain relatively constant, but I = didn't follow the discussion that led to this requirement, so maybe I'm = missing something. SSD should support rich internationalized labels within Service Instance Names, as DNS-SD/mDNS does today. SSD must not negatively impact the global DNS namespace or infrastructure. This sounds like a requirement, but it appears in the considerations = section. Any reason for this? If the scope of the discovery is not properly setup or constrained, then information leaks will happen outside the appropriate network. This text is a bit awkward. I think you mean something like this: If the scope of discovery is not properly constrained, either automatically or through configuration, then information will leak inappropriately to networks it is not intended to reach. Or maybe you didn't mean that, but in any case I think the wording could = be better. This is not likely to be the case in foreign networks. The term "foreign networks" isn't defined, and probably should be. The document looks really good. None of the above comments would = prevent me from taking it to IETF last call as is; any updates that the = working group decides to do based on these comments could be done in = conjunction with comments received during IETF last call and directorate = review. From nobody Thu Jul 24 07:53:34 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C451A03AF for ; Thu, 24 Jul 2014 07:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 uk1DwytQwrGB for ; Thu, 24 Jul 2014 07:53:26 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84DC81A03EA for ; Thu, 24 Jul 2014 07:53:23 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so9851620wiv.7 for ; Thu, 24 Jul 2014 07:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=jHarN15f3eC9n38W405qd/JwfEqm5PdxlKI1Mlwmmsw=; b=SWkTIXsztnAelqdLD2kH6z8hz2p6dB8vK4WSXiBzSi9F/Y0Ujee4zv0cYp4EYFyzZJ NmRX9MHYNcZ/gxaFnfAj2MKhR1kSCVceGqeZsIRQ+DsgIB42bSrH1whS9PVmqSedd3pF jZlyuU3ei+Fc84ftiFv7e5OSwOVRfH91p/euWKpMfdt9N9tNl/W7guo68dxcpu8jSM6V hFMKwpMMhJHzfDaqBHcO+PGXDWc+HN6q0YbpFkJ28jQ2txNmVdEnqg/k1zmbf4EJ/UMJ emZPt3P9d5ltDVQeMaI3DlLh60eL6blp5faP9SBFn0Y7CcMcq8H7teWx0XW6mHIqB+nb jjQA== X-Received: by 10.181.9.104 with SMTP id dr8mr13860222wid.26.1406213602207; Thu, 24 Jul 2014 07:53:22 -0700 (PDT) Received: from dhcp-b535.meeting.ietf.org (dhcp-b535.meeting.ietf.org. [31.133.181.53]) by mx.google.com with ESMTPSA id de5sm23604451wib.18.2014.07.24.07.53.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 07:53:21 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 24 Jul 2014 10:53:19 -0400 Message-Id: <331F9173-DB56-4D9A-B09F-956FF6D8DA2B@gmail.com> To: dnssd@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/YHyhmmf7DjWbHrU8x5j3KAT1aTc Subject: [dnssd] multicast over wireless links X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 14:53:29 -0000 All, While IEEE 802.11 has known specific issues with IP multicasting, most radio links (including SATCOM) actually are natively broadcast links, hence perform multicasting efficiently. As an example, for my clients with IP/VSAT deployments or other IP/RF deployments (for RF != 802.11), multicast is the MOST EFFICIENT way to communicate and unicast is the LEAST EFFICIENT way to communicate. As I've said in other IETF working groups, it would be a mistake to optimise an upper-layer protocol for a specific link-technology. Instead, folks ought to engage with IEEE 802.11 to help them find ways to more effectively support IP multicast traffic. So I object to any proposal to "optimise" DNS-SD for 802.11, because the issues with 802.11 are unique to the design of its MAC/LLC layer protocols. Yours, Ran Atkinson From nobody Thu Jul 24 07:58:27 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED191A0380 for ; Thu, 24 Jul 2014 07:58:23 -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 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 JeMrVkdk4uLz for ; Thu, 24 Jul 2014 07:58:15 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CE9C1A02D5 for ; Thu, 24 Jul 2014 07:58:08 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E95581B8540 for ; Thu, 24 Jul 2014 07:58:07 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id DC284190052; Thu, 24 Jul 2014 07:58:07 -0700 (PDT) Received: from [192.168.0.10] (99.232.25.196) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Jul 2014 07:58:07 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <331F9173-DB56-4D9A-B09F-956FF6D8DA2B@gmail.com> Date: Thu, 24 Jul 2014 10:58:02 -0400 Content-Transfer-Encoding: 7bit Message-ID: References: <331F9173-DB56-4D9A-B09F-956FF6D8DA2B@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [99.232.25.196] Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/qRgA99jrLhVqJ8mdgKYpn3Q2cNo Cc: dnssd@ietf.org Subject: Re: [dnssd] multicast over wireless links X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 14:58:23 -0000 On Jul 24, 2014, at 10:53 AM, RJ Atkinson wrote: > So I object to any proposal to "optimise" DNS-SD for 802.11, > because the issues with 802.11 are unique to the design of > its MAC/LLC layer protocols. Do you envision DNS-SD being used on satellite networks? From nobody Thu Jul 24 08:54:59 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2BA1A03EB for ; Thu, 24 Jul 2014 08:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 SAY8krFrgd-F for ; Thu, 24 Jul 2014 08:54:46 -0700 (PDT) Received: from g4t3425.houston.hp.com (g4t3425.houston.hp.com [15.201.208.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90911A03E2 for ; Thu, 24 Jul 2014 08:54:46 -0700 (PDT) Received: from G9W0364.americas.hpqcorp.net (g9w0364.houston.hp.com [16.216.193.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t3425.houston.hp.com (Postfix) with ESMTPS id 132B823C for ; Thu, 24 Jul 2014 15:54:46 +0000 (UTC) Received: from G4W6305.americas.hpqcorp.net (16.210.26.230) by G9W0364.americas.hpqcorp.net (16.216.193.45) with Microsoft SMTP Server (TLS) id 14.3.169.1; Thu, 24 Jul 2014 15:54:04 +0000 Received: from G4W3298.americas.hpqcorp.net ([169.254.4.87]) by G4W6305.americas.hpqcorp.net ([16.210.26.230]) with mapi id 14.03.0169.001; Thu, 24 Jul 2014 15:54:04 +0000 From: "Kennedy, Smith (Wireless Architect)" To: RJ Atkinson Thread-Topic: [dnssd] Security through Obscurity Thread-Index: AQHPprfZeGKEsBCMn020p8uMqL4n0Juub3CAgADDcoCAAAvegIAAIsoA Date: Thu, 24 Jul 2014 15:54:03 +0000 Message-ID: <8465FD60-84CD-41B3-BBE3-1BDB52DF0DDB@hp.com> References: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> <20E4ED19-12BD-45D4-B690-8629B552B23B@gmail.com> <0E0BC226-E68E-4BC2-99EA-AFF1AF96A5EC@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [15.201.58.30] Content-Type: multipart/signed; boundary="Apple-Mail=_B6AD405F-C77F-47EB-AD0F-1A416E49EBDC"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/Wiv9tXZTHaOB3M_DinqkPQ35H88 Cc: "dnssd@ietf.org" Subject: Re: [dnssd] Security through Obscurity X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 15:54:58 -0000 --Apple-Mail=_B6AD405F-C77F-47EB-AD0F-1A416E49EBDC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Ran, Where you say: > Also, in many environments where DHCP is NOT used, for example > due to the costs associated with DHCP, it is STILL operationally=20 > DESIRABLE for an IPv6-capable device (e.g. network printer)=20 > to have the SAME PREDICTABLE IPv6 address each and every time=20 > the printer (re)boots. =20 Why in your opinion is it =93operationally desirable=94 for the printer = to have a predictable IPv6 address? I have my own thoughts on this = subject but I want to hear yours, hopefully with examples. Smith /** Smith Kennedy Hewlett-Packard Co. */ On 2014-07-24, at 7:49 AM, RJ Atkinson wrote: >=20 > On 24 Jul 2014, at 09:07 , Tim Chown wrote: >> Doug, if you mean a 48-bit MAC address being embedded in the IPv6 = address, >> see http://tools.ietf.org/html/rfc7217. >=20 >=20 > All, >=20 > I think the notion of predictability of IPv6 Interface IDs > is not germane to the DNS-SD discussions, for the reasons > that various folks (e.g. Stuart Cheshire, Tim Chown, and=20 > Tom Pusateri) have explained already. =20 >=20 > Separately, in many environments, predictability of IP > addressing of printers (or file servers or ...) is=20 > operationally DESIRABLE. >=20 > However, just for the record, there also are a range of other=20 > RFCs, long predating RFC-7217, for generating IPv6 Interface IDs,=20 > going back for more than a decade. [References at bottom] >=20 > I believe these various alternative IPv6 IID algorithms are=20 > widely implemented and deployed today, and that they have been=20 > widely implemented and deployed for many years now. >=20 > Note, in some environments, especially business environments, > the use of DHCP(v6) is operationally preferable to SLAAC > because it provides PREDICTABILITY in IP address assignment.=20 >=20 > Also, in many environments where DHCP is NOT used, for example > due to the costs associated with DHCP, it is STILL operationally=20 > DESIRABLE for an IPv6-capable device (e.g. network printer)=20 > to have the SAME PREDICTABLE IPv6 address each and every time=20 > the printer (re)boots. IPv6 SLAAC with an embedded MAC address=20 > thus is DESIRED in many environments -- especially for devices > providing services that would be advertised using DNS-SD > (e.g. network printer). >=20 > Can we PLEASE get past individual hangups over *solved* problems=20 > that belong to other IETF WGs (e.g. IPv6 Ops, IPv6 Maint, OPsec) > and instead stay on-topic for DNS-SD ? >=20 > Thanks, >=20 > Ran Atkinson >=20 >=20 >=20 > REFERENCES: >=20 > RFC-3041 January 2001 > Privacy Extensions for Stateless IPv6=20 > Address Auto-config >=20 > RFC-3972 March 2005 > Cryptographically Generated Addresses (CGAs) >=20 >=20 > RFC-4941 September 2007 > Revision of RFC-3041 >=20 > RFC-4942 July 2007 > Support for Multiple Hash Algorithms in > Cryptographically Generated Addresses (CGAs) >=20 > RFC-5535 June 2009 > Hash-based Addresses >=20 > RFC-7217 April 2014 > Generating Opaque Interface IDs with IPv6 SLAAC > =09 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_B6AD405F-C77F-47EB-AD0F-1A416E49EBDC Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOQDCCBmEw ggVJoAMCAQICEFHz5uyygZHVFZ4pmbCHOnswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDkwMjAwMDAwMFoXDTE0MDkwMTIzNTk1OVowgfcxCzAJ BgNVBAYTAlVTMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBMTEwLwYDVQQDEyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRp b24gQXV0aG9yaXR5IEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp2FraNquqoVk DEvLUMsw6HMhjon+yi1v/kajA27jIrdyhRMj4g+PBveBTHrtA7w97Rx1UKPP6CvOaAE5xUtoW9aj YZtO5kdiUFyzWHsbUgSjKy+yNO4QoHeEzaQi/JWUOYev/AV5YYJoEDIysosEELS1/M64iE2Utzr+ LxiWhdaqSRE4jigbm4Dy4ayLzqAv5f7oILrJNZ6ShqLiGGCpP+7relTyRgFXmEX/SKN/a39JwZoK SNUdIkYyr7wmNI9+zylheDJghuk+kZDAD3NXv4EGVMUfOg5UEdhAJ0Lw40D4pqKa2ej1H0UipK1E EdRTm94RzfE8z8vDP8+dcgOqCwIDAQABo4ICEjCCAg4wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNV HSAEaTBnMGUGC2CGSAGG+EUBBxcCMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWdu LmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNV HR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWczLmNybDAOBgNVHQ8B Af8EBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0OC0xNDIw HQYDVR0OBBYEFCJ906SrV6xWf6l/QUQalbxb+KvuMIHwBgNVHSMEgegwgeWhgdCkgc0wgcoxCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9y aXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEB BQUAA4IBAQAvUbxneMj/3SU5WlUKapv9ZGIeeNSf6/t6gKUUsCT2A1KQMlZmK7/gn4ndrXWdch7U afl6WkPlBcunYRGvJ6YkJCP4uV86Lwv68mK6REwJFMiKHy/qFnRaoI+pLfaIlMQ9l7Q2DRnNLSyC Bl9b02PaGzX+XQQxGhLiE89Z1E+ajicWG1zRzBUbPx46ptQUjfjYPNyP4cLWT5rJ7olc9/mRyfIO 4nGU8lRjGcuKwxZhOP+TftJgd/fRYf68Kf2Bkue4cdrI2UUgYD02GBL/S8E8FBsOrAoJ5N6cEYac wT2BZgHzYrxTC5ZyxzY9TWtGldxEH/moJ5OLtF+KauJWhaACMIIH1zCCBr+gAwIBAgIQPOXfUUI6 ovNsyP+l8ouxZTANBgkqhkiG9w0BAQUFADCB9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xl dHQtUGFja2FyZCBDb21wYW55MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1 MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAv BgNVBAMTKENvbGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIwHhcNMTIxMTI2 MDAwMDAwWhcNMTQxMTI2MjM1OTU5WjCBmDEgMB4GA1UEChQXSGV3bGV0dC1QYWNrYXJkIENvbXBh bnkxJjAkBgNVBAsUHUVtcGxveW1lbnQgU3RhdHVzIC0gRW1wbG95ZWVzMQ8wDQYDVQQLEwZTL01J TUUxFjAUBgNVBAMTDVNtaXRoIEtlbm5lZHkxIzAhBgkqhkiG9w0BCQEWFHNtaXRoLmtlbm5lZHlA aHAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuageabAIyTS0JIjXDq1iml4l fdgg3AULnBQiEK3wdxFb8Cyz2fsHE/UykFRJyZilpA6MUj6fom56o02WYfKxb3AUbwWJLGjAB/YL pw36SatXUw7OmuumNllMH3v2WpEP9QblEKjgE3LdpNO2owWTsmSsvVAfzItrkg6BR3fo3tsrf6dL PpbdfeOjkbwRrHnEm/AKKg5DPOZyVEqmgNEoVPflsem1QIPRVHshjvj0iTv4DhEGnnbDvMpiuzo3 n0fLQ/HETM6xAiZQLv76aFEm2DkB1fvnAApvrrm/dvhFmMkExCGNh1TwCXd7+KrfradSomasVs2G kz0tJqmOlsKbsQIDAQABo4IDujCCA7YwHwYDVR0RBBgwFoEUc21pdGgua2VubmVkeUBocC5jb20w DAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29u c2l0ZWNybC52ZXJpc2lnbi5jb20vSGV3bGV0dFBhY2thcmRDb21wYW55U01JTUVHMi9MYXRlc3RD UkwuY3JsMB8GA1UdIwQYMBaAFCJ906SrV6xWf6l/QUQalbxb+KvuMB0GA1UdDgQWBBTa6BzKTU+H dS93ruL/3n7ZMTXvgjCCATIGCCsGAQUFBwEBBIIBJDCCASAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9o cC1vY3NwLnZlcmlzaWduLmNvbTCB9AYIKwYBBQUHMAKkgecwgeQxMTAvBgNVBAMTKENvbGxhYm9y YXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIxMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRl IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTE6MDgGA1UECxMxVGVybXMgb2YgdXNlIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEoYykwOTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkwggE9BgNVHSAEggE0MIIBMDCC ASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYTCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1 dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJlc3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vz c2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQgdG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0 aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29ycC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0 ZC4gKGMpOTcgVmVyaVNpZ24wFgYDVR0lAQH/BAwwCgYIKwYBBQUHAwQwSwYJKoZIhvcNAQkPBD4w PDAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwICAgBAMA4GCCqGSIb3DQMEAgIAgDAKBggqhkiG 9w0DBzANBgkqhkiG9w0BAQUFAAOCAQEAibIOTCm5SdtOxug7ClAA9DgzWNtmR9ZL+YujqiPpc5YC mr0hDWOTCjAJbDAIDcXfAJspAamEnwd0tpUZj0DOc4RCiLEsfH2uchNqr2UV5qAJmKq0Wrr+Lfd6 1ZFvp1encVlif2KSFi/vgTCKX+57rVWpb284BmrnVa30nOcuZVKQk3XUDignE0vz+OIrza1JcyRQ d7TtVtlRQX63rT0P3v2u9UrryzDo/5wN77jqDLqgz0se0g23wVyWuj/jmFB7QV1bUDV2bLHh3Ipb 9JtEri7DlzSde9pmfRauWerZHGb/AI0qcbEC2nSKvv/u5tHoaMHfG58GM0unnsmBu4UiDjGCBN4w ggTaAgEBMIIBDDCB9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21w YW55MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xhc3Mg MiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENvbGxhYm9y YXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzICEDzl31FCOqLzbMj/pfKLsWUwCQYFKw4D AhoFAKCCAqUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwNzI0 MTU1NDAzWjAjBgkqhkiG9w0BCQQxFgQURb1EeNY5lzUkOGq0WxvgloZP7BgwggEfBgkrBgEEAYI3 EAQxggEQMIIBDDCB9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21w YW55MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xhc3Mg MiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENvbGxhYm9y YXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzICEDzl31FCOqLzbMj/pfKLsWUwggEhBgsq hkiG9w0BCRACCzGCARCgggEMMIH3MQswCQYDVQQGEwJVUzEgMB4GA1UEChMXSGV3bGV0dC1QYWNr YXJkIENvbXBhbnkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRl cm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MTUwMwYDVQQL EyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTExMC8GA1UEAxMo Q29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBHMgIQPOXfUUI6ovNsyP+l8oux ZTANBgkqhkiG9w0BAQEFAASCAQC0mSLezbU6Y/0W/tl6ayVR9aVWxoyJ9Ue97uKPIGDYEyINiNR8 p3scUqhfUw4cCIAEEtRhw/6JCgWajOrXK32gYVUbUqUETr1F7C95m1LK/ukPlcoR6eBmnZpl6sjO CjDgIMu8TxQqHgZuyVpSmnZPevUq9uk61t8ezH2MQhj+zXgia5RiE1XGqB4+1ZaPyDBq/5khf/TJ boWrJOzJocWwZF75BVqkFdSxp6AsJvDj6LpEpRJVj78QQrwfo+tD4Ff25f8DyhqCt+xQH3iNXei5 6tR33OF/CuJbu5IABRVhnKsLCAXr0+jFa2AaF4toKBeclQ2CgDbGMu2aL39t1YKVAAAAAAAA --Apple-Mail=_B6AD405F-C77F-47EB-AD0F-1A416E49EBDC-- From nobody Thu Jul 24 09:21:55 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765ED1A0058 for ; Thu, 24 Jul 2014 09:21:53 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 yHzX98ZDQ7hD for ; Thu, 24 Jul 2014 09:21:50 -0700 (PDT) Received: from polaris.istumbler.net (polaris.istumbler.net [66.116.108.178]) by ietfa.amsl.com (Postfix) with ESMTP id 75E9B1A0173 for ; Thu, 24 Jul 2014 09:21:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by polaris.istumbler.net (Postfix) with ESMTP id 521DA26C11CA; Thu, 24 Jul 2014 09:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at example.com Received: from polaris.istumbler.net ([127.0.0.1]) by localhost (polaris.istumbler.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHFRd8EwxK6n; Thu, 24 Jul 2014 09:21:19 -0700 (PDT) Received: from [IPv6:2601:9:5900:158a:b9a7:c7c9:6618:6a2a] (unknown [IPv6:2601:9:5900:158a:b9a7:c7c9:6618:6a2a]) by polaris.istumbler.net (Postfix) with ESMTPSA id A077B26C11BB; Thu, 24 Jul 2014 09:21:19 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_113707A1-AB3B-4580-8CFB-F82D4091F02B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alf Watt In-Reply-To: <331F9173-DB56-4D9A-B09F-956FF6D8DA2B@gmail.com> Date: Thu, 24 Jul 2014 09:21:50 -0700 Message-Id: References: <331F9173-DB56-4D9A-B09F-956FF6D8DA2B@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/ycH0x4XdQ4hBjCwfYoN89swECQs Cc: "dnssd@ietf.org" Subject: Re: [dnssd] multicast over wireless links X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 16:21:53 -0000 --Apple-Mail=_113707A1-AB3B-4580-8CFB-F82D4091F02B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii RJ, The particulars of 802.11 multicasting are significant to the mDNS & = DNS-SD community for a few of reasons: - the overwhelming popularity of Wi-Fi devices and networks for internet = and service access - the specific behavior of 802.11 radios transmitting at their lowest = common rate for broadcast and multicast - the overwhelming popularity of Apple's devices which rely heavily on = these technologies on Wi-Fi networks There is, in my opinion, a gap between the perceived impact of mDNS on = network link performance and the reality, but perception is important as = I know AP vendors who have imposed despotic multicast queuing regimes in = order to 'manage' mDNS traffic on large networks, effectively breaking = service discovery for large numbers of users. It's certainly possible to use mDNS over other types of radio link, = bluetooth PAN for e.g. so I agree that focusing solely on 802.11 would = be misguided and that we should take other scenarios into account (the = ZigBee Alliance for e.g uses mDNS and DNS-SD as well and has different = multicast issues than 802.11 due to it's multicast forwarding = architecture). So, I think it's fair to say that we need to carefully consider the = impact of mDNS and DNS-SD when used on a number of RF MAC/LLC protocols = and make sure we have solutions which makes sense for the scenarios in = which we want to support service browsing. Best, Alf On Jul 24, 2014, at 7:53 AM, RJ Atkinson wrote: > All, >=20 > While IEEE 802.11 has known specific issues with IP multicasting, > most radio links (including SATCOM) actually are natively > broadcast links, hence perform multicasting efficiently. >=20 > As an example, for my clients with IP/VSAT deployments or=20 > other IP/RF deployments (for RF !=3D 802.11), multicast is=20 > the MOST EFFICIENT way to communicate and unicast is the=20 > LEAST EFFICIENT way to communicate. >=20 > As I've said in other IETF working groups, it would be a=20 > mistake to optimise an upper-layer protocol for a specific=20 > link-technology. Instead, folks ought to engage with=20 > IEEE 802.11 to help them find ways to more effectively > support IP multicast traffic. >=20 > So I object to any proposal to "optimise" DNS-SD for 802.11, > because the issues with 802.11 are unique to the design of > its MAC/LLC layer protocols. >=20 > Yours, >=20 > Ran Atkinson >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_113707A1-AB3B-4580-8CFB-F82D4091F02B 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 - https://gpgtools.org iQIcBAEBCgAGBQJT0TKeAAoJEALE6jSCCRPcS0QQAIAq9Z7SLaEpczJ5oD6QFwAn g0a997xBOcq5wNs+LKlU2Tixf/e1Vq5H5bHahuWHOQAfJlcdXGL4NeUX244t6gbf MYS7ibA2e1191mM3d5FPhICaH2v9TN8wjYP25Dios9ofHh+HnEA9NSYl9nzdto5b RpFuRBO71OApJNXE9nD7dXu4CuD2r5zy8UAc7gISpuL5P/K5MbBL0DYhbuWcll5s UNVCAv6IUiX8ftznUF2yhvFVVcMJ67WHE08VsrdkFnbmYj6t/3xZCCggakqMv/qo DHsHwnCYxTSfEAS/4tQSVD/4i4QfM9on2VehSmrUUHLlkTRQao0zhjVYREVOKoW4 oPqcuBkW44DW47CZwPPGwijubwvxIbTM/MkXC8WZRPyo+81e3ovZSPNMo5p1yOjf AfCgMpXDGmesRhbtawgKADZxOwaKfVtSuZfJV/bAOAlfzA0AbHfcsVk1++AAFUOo GVXFykzMxw4aUsIEFCEsYvvxuhoBQMORKomNzPRfqKfXhJNTFBEizdw5YsRyIIVa 9iQyLKDjKBzVvyxFP+PE/Y+/RLQp+n/itXWRNe3L82nJ/G7Z+G8OIY0ggsESoQnD oK7fdGU3vglBI/xb46ubLtyjW4B4gOmNaaKJxhnMTVcqlWo/TP4FQ5RHgMzHusf9 YGT1Dj7WlREla9bns3Xl =sOXY -----END PGP SIGNATURE----- --Apple-Mail=_113707A1-AB3B-4580-8CFB-F82D4091F02B-- From nobody Thu Jul 24 09:22:31 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D291A03AF for ; Thu, 24 Jul 2014 09:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 TLRtWKtYu819 for ; Thu, 24 Jul 2014 09:22:13 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFCC01A0173 for ; Thu, 24 Jul 2014 09:22:12 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id l18so2975655wgh.25 for ; Thu, 24 Jul 2014 09:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=iQOJdKWa4qV0203ef6CFbGAQ1iqV4AYXPiHRMSO79vs=; b=0PFCdpkCmAqS8rPRAfL7s9fNt1G7mXi/7Va9rpKLF3tbOU7sHSvTsv7zEJLtUPrTVR Ki3CCbkFL79CL5iPocdifnQk/MwLYTgHqwQwkfNk7f285ezr5+wQDFG869OdgKd2fJzH jAQTay5rvM41ZFyhaZcUoY4i3oRWjK1cA3gG6Qcn+Amb0ym11DLISoMbT2C5g2StA6hm 5DZmZ9e2apNEOWkD6lYxNfFNBa3m2a/1wh/tiHsMkD2BPD0mldyj/SYlwCknth7JD3SS adLD1i1D9K3n8XCAVxPCLAGNbDEuOQJy3HA00lt+o0Ct2qY+RBfkM8gcNTsyssiUppVo G/dQ== X-Received: by 10.180.80.225 with SMTP id u1mr14008879wix.69.1406218931459; Thu, 24 Jul 2014 09:22:11 -0700 (PDT) Received: from dhcp-93fd.meeting.ietf.org (dhcp-93fd.meeting.ietf.org. [31.133.147.253]) by mx.google.com with ESMTPSA id dj2sm24726612wib.11.2014.07.24.09.22.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 09:22:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: RJ Atkinson In-Reply-To: Date: Thu, 24 Jul 2014 12:22:06 -0400 Content-Transfer-Encoding: 7bit Message-Id: <1F1E6B22-5FF2-41DF-BA86-20A9D57E74CC@gmail.com> References: <331F9173-DB56-4D9A-B09F-956FF6D8DA2B@gmail.com> To: dnssd@ietf.org X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/kRUXaGWP72zG8Kn3_KOmEK9rE5A Subject: Re: [dnssd] multicast over wireless links X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 16:22:20 -0000 On 24 Jul 2014, at 10:58 , Ted Lemon wrote: > Do you envision DNS-SD being used on satellite networks? Yes. I know of many IP/RF networks, including IP/SATCOM but also other IP/RF other than 802.11, where DNS-SD both is desired and would be useful. IP/SATCOM is commonly used today within a single administrative domain to connect different sites together. Yours, Ran From nobody Thu Jul 24 09:27:10 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6791A03E7 for ; Thu, 24 Jul 2014 09:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 cYCoG4ZNv4Ja for ; Thu, 24 Jul 2014 09:27:06 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C361A03EB for ; Thu, 24 Jul 2014 09:27:05 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id f8so10016560wiw.6 for ; Thu, 24 Jul 2014 09:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=4E+Du+3+qfXcOsX8qFlKGYEXV+LMdqFYWcL5o1RdfZc=; b=xtD0PCmSUSQC9VAfP7pzVs5gE+EHB+0h1951zLkNz32mZzcOA4MO98A+7YU1JTzIhS YbpiA7Xy05fEsM8+i+LVdn3geZGMMdEJ1ImY4vUXx7GkL6GXUQID+DqALhHaGGjtAkrl NpFQ4WQQTVGCpTpS1K8/X2vQxfQh8xXsDU8vd4Ykq6S8rpRDpiDvfpozsTaO5PAzLWEW uOXbaLO3H5gARXAM0KxdK6UNEXCKq1y+4LTQ403ceZT3bk9fJgM5LsMaISOnk8MewxIS PbxBKe90Sm7qEzLmzfjmSW5KoHjl2kYG2LNZ8x5LI0CxMHphoE21aMhiTCB6F0/sOQNI 7Mgg== X-Received: by 10.180.211.101 with SMTP id nb5mr36735328wic.53.1406219223488; Thu, 24 Jul 2014 09:27:03 -0700 (PDT) Received: from wireless-a-1x-v6.meeting.ietf.org ([2001:67c:370:184:1d29:e3f1:96d7:1d60]) by mx.google.com with ESMTPSA id sa4sm17120488wjb.45.2014.07.24.09.27.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 09:27:02 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_DCF9738A-7894-4F80-9A42-8984919FE7BB" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: Date: Thu, 24 Jul 2014 12:26:59 -0400 Message-Id: References: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> <20E4ED19-12BD-45D4-B690-8629B552B23B@gmail.com> <0E0BC226-E68E-4BC2-99EA-AFF1AF96A5EC@ecs.soton.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/WfwL8-CSavLwVAIzPNoR_1hS3hE Cc: dnssd@ietf.org, RJ Atkinson , Douglas Otis Subject: Re: [dnssd] Security through Obscurity X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 16:27:08 -0000 --Apple-Mail=_DCF9738A-7894-4F80-9A42-8984919FE7BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 24, 2014, at 9:07 AM, Tim Chown wrote: > On 24 Jul 2014, at 02:27, Douglas Otis wrote: >=20 >>=20 >> On Jul 23, 2014, at 4:51 PM, RJ Atkinson wrote: >>=20 >>>=20 >>> (NOTE WELL: I am not a WG Chair, IESG member, IAB member, >>> or authorised spokesperson for anyone other than myself.) >>>=20 >>>=20 >>> Earlier Doug Otis wrote: >>>> It is not safe to advertise such addresses in DNS,=20 >>>> especially when security depends on address obscurity. >>>=20 >>>=20 >>> I believe that the the vast majority of security folks >>> would object to the notion that obscurity is a mechanism=20 >>> capable of providing any meaningful security. >>>=20 >>> If a client were to ask me for advice on protecting their >>> interior services or interior devices from the global Internet,=20 >>> I would suggest at least a firewall (ranging from router ACLs=20 >>> to an air-gap: depending upon their local needs and threat model)=20 >>> and possibly also other measures (again, depending upon local >>> needs and threat model). Operational security is not=20 >>> one-size-fits-all, in my experience, but relying upon=20 >>> security-through-obscurity seems unwise to me. >>=20 >> I agree with that statement, but at the same time some of these = devices are assigned routable addresses by the vendors. When assigned = out of a 48 bit space, it might be possible to guess the device based on = common manufacturers. When randomly assigned by the owner, it is highly = unlikely such an address will ever be guessed. Add rate limiting, and = this unknown should work well at mitigating attack. But as I said, I = agree with your statement and why I think mDNS should be working with = ULAs. >=20 > Doug, if you mean a 48-bit MAC address being embedded in the IPv6 = address, see http://tools.ietf.org/html/rfc7217. >=20 > I agree with Tom=92s comments. A question to discuss in your slot = today is when a device has a LL, ULA and GUA, which of those should be = advertised via the SD protocol and whether/how that choice can/should be = influenced. Dear Tim, The comment was focused on typical operating modes regarding newer IPv6 = ready printers in typical home networks. There are ways to improve upon = SLACC, as noted in RFC7217. When a printer is assigned a globally = routable IP address, publishing this address in a way that can be seen = by malefactors outside the network would be a bad practice. In home = environments, SLAAC rather than DHCP often provides the printer's IPv6 = address. Where there is no overlay network in a home network having multiple = routers, publishing the printer's address would be detrimental. Testing = determined, that when not using an overlay network, these devices were = highly vulnerable to exploits that allows malefactors an ability to = remotely fax, scan, print, from anywhere in the Internet without any = logging being generated. As such, it would be a bad practice to place a = printer's mDNS resources into DNS. =20 Answering your specific question, the address functional for DNS-SD = would be the ULA address, which should be the prefix announced to the = printer. In essence, this represents a security consideration for the = use of SSD and not directly an SSD mode of operation. Regards, Douglas Otis=20 --Apple-Mail=_DCF9738A-7894-4F80-9A42-8984919FE7BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jul 24, 2014, at 9:07 AM, Tim Chown = <tjc@ecs.soton.ac.uk> = wrote:

On 24 = Jul 2014, at 02:27, Douglas Otis <doug.mtview@gmail.com> = wrote:


On Jul 23, 2014, at 4:51 PM, RJ Atkinson <rja.lists@gmail.com> = wrote:


(NOTE WELL: I am not a WG = Chair, IESG member, IAB member,
or authorised spokesperson for anyone = other than myself.)


Earlier Doug Otis wrote:
It is not safe to advertise such addresses in DNS, =
especially when security depends on address = obscurity.


I believe that the the vast majority = of security folks
would object to the notion that obscurity is a = mechanism
capable of providing any meaningful security.

If a = client were to ask me for advice on protecting their
interior = services or interior devices from the global Internet,
I would = suggest at least a firewall (ranging from router ACLs
to an air-gap: = depending upon their local needs and threat model)
and possibly also = other measures (again, depending upon local
needs and threat model). =  Operational security is not
one-size-fits-all, in my = experience, but relying upon
security-through-obscurity seems unwise = to me.

I agree with that statement, but at the same = time some of these devices are assigned routable addresses by the = vendors.  When assigned out of a 48 bit space, it might be possible = to guess the device based on common manufacturers.  When randomly = assigned by the owner, it is highly unlikely such an address will ever = be guessed.  Add rate limiting, and this unknown should work well = at mitigating attack.  But as I said, I agree with your statement = and why I think mDNS should be working with = ULAs.

Doug, if you mean a 48-bit MAC = address being embedded in the IPv6 address, see http://tools.ietf.org/html/rfc= 7217.

I agree with Tom=92s comments. A = question to discuss in your slot today is when a device has a LL, ULA = and GUA, which of those should be advertised via the SD protocol and = whether/how that choice can/should be = influenced.

Dear = Tim,

The comment was focused on typical = operating modes regarding newer IPv6 ready printers in typical home = networks.  There are ways to improve upon SLACC, as noted in = RFC7217. When a printer is assigned a globally routable IP address, = publishing this address in a way that can be seen by malefactors outside = the network would be a bad practice.  In home environments, SLAAC = rather than DHCP often provides the printer's IPv6 = address.

Where there is no overlay network in a = home network having multiple routers, publishing the printer's address = would be detrimental. Testing determined, that when not using an overlay = network, these devices were highly vulnerable to exploits that allows = malefactors an ability to remotely fax, scan, print, from anywhere in = the Internet without any logging being generated.  As such, it = would be a bad practice to place a printer's mDNS resources into DNS. =  

Answering your specific question, the = address functional for DNS-SD would be the ULA address, which should be = the prefix announced to the printer.  In essence, this represents a = security consideration for the use of SSD and not directly an SSD mode = of operation.

Regards,
Douglas = Otis 





= --Apple-Mail=_DCF9738A-7894-4F80-9A42-8984919FE7BB-- From nobody Thu Jul 24 09:28:39 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BCD1A03ED for ; Thu, 24 Jul 2014 09:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 KL6yi1e-Ro2j for ; Thu, 24 Jul 2014 09:28:37 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF00F1A03E7 for ; Thu, 24 Jul 2014 09:28:36 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id k48so3070760wev.27 for ; Thu, 24 Jul 2014 09:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=OKDsoZkuKZFYQ9Yujw1zGjQ6d9j1oQwXbQNEIrTRpR4=; b=xQnjBKIEP7TQiTLqJ9aU0qbIuMkBVKmTcjQAWWWqD/iSIo8VIynR+CAqzaKhqHSoeJ p8i7wE8lQUMNXlSRhfW67bKFMJsmOAIsXIlbG0L7448q9i1nIXd1PiNXqEmMB1FmvzY7 PTKvTTx+8pwiNnN9Zoo9D5S1oTzqlTyRH7gMubVXGjduDpcHcYhgnsNYkIoPfhunvJoV GdmrRxqsmpT7QqFULqcKiPcmpoBSzsMR99jO++W39HaRa/RYTM5uzMAnvyO5VW53khal unVm6fqVS4iIX3tLh+Dx4XqyjBuye7InV0+eLt6KkYZHF03GIWMQvgtJZOmhlwGQ2D11 ma+g== X-Received: by 10.194.221.6 with SMTP id qa6mr13563491wjc.39.1406219315554; Thu, 24 Jul 2014 09:28:35 -0700 (PDT) Received: from dhcp-93fd.meeting.ietf.org (dhcp-93fd.meeting.ietf.org. [31.133.147.253]) by mx.google.com with ESMTPSA id ut2sm17126205wjc.49.2014.07.24.09.28.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 09:28:34 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1283) From: RJ Atkinson In-Reply-To: <8465FD60-84CD-41B3-BBE3-1BDB52DF0DDB@hp.com> Date: Thu, 24 Jul 2014 12:28:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <364AAF85-5FB4-4828-A5A4-11160E747BC9@gmail.com> References: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> <20E4ED19-12BD-45D4-B690-8629B552B23B@gmail.com> <0E0BC226-E68E-4BC2-99EA-AFF1AF96A5EC@ecs.soton.ac.uk> <8465FD60-84CD-41B3-BBE3-1BDB52DF0DDB@hp.com> To: dnssd@ietf.org X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/iSz9KbintBQDGCq-zhp8a_5fyfo Subject: Re: [dnssd] Security through Obscurity X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 16:28:38 -0000 On 24 Jul 2014, at 11:54 , Kennedy, Smith (Wireless Architect) wrote: > Why in your opinion is it =93operationally desirable=94 for the = printer > to have a predictable IPv6 address? =20 The most common reason that my clients give me is that=20 predictable/deterministic IP addressing lowers their=20 operating costs. Larger enterprises often use DHCP=20 to obtain this. Smaller enterprises find DHCP complex to deploy/configure, but they still want predictable addressing in their IP network deployments. And this is not just for printers, but also for other devices offering shared services -- file servers or whatever else. Yours, Ran From nobody Thu Jul 24 10:26:23 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F871A0AD5 for ; Thu, 24 Jul 2014 10:26: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 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 B4_njaf6a7b1 for ; Thu, 24 Jul 2014 10:26:19 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16E51A0AF5 for ; Thu, 24 Jul 2014 10:25:14 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6B52AF805A for ; Thu, 24 Jul 2014 10:25:14 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 65028190052; Thu, 24 Jul 2014 10:25:14 -0700 (PDT) Received: from nat64.meeting.ietf.org (31.130.238.127) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Jul 2014 10:25:14 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <1F1E6B22-5FF2-41DF-BA86-20A9D57E74CC@gmail.com> Date: Thu, 24 Jul 2014 13:25:11 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <7414908D-B2A9-4935-912F-EF3E4995065F@nominum.com> References: <331F9173-DB56-4D9A-B09F-956FF6D8DA2B@gmail.com> <1F1E6B22-5FF2-41DF-BA86-20A9D57E74CC@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [31.130.238.127] Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/lQaHxPbsdTrXKB-twFCr9Q-XvII Cc: dnssd@ietf.org Subject: Re: [dnssd] multicast over wireless links X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 17:26:21 -0000 On Jul 24, 2014, at 12:22 PM, RJ Atkinson wrote: > IP/SATCOM is commonly used today within a single > administrative domain to connect different sites > together. Forgive me, but this doesn't sound like a valid use case for DNSSD. It = sounds like you are trying to use DNSSD to solve a problem that is = actually out of scope, because you are attracted to the benefits that a = multicast DNSSD solution would provide (which I agree exist). But I think that this is a very specialized use case, and that the WiFi = use case is a _much_ more important use case. Asking IEEE to fix WiFi = is not really a good approach to addressing the problem of inefficient = multicast for existing deployments, and this work is intended to address = existing deployments. Therefore, I think that if we want to address this use case, the right = way to do it is to come up with a mechanism for doing multicast = distribution of DNSSD updates on broadcast-friendly networks, and not to = just make this the default operational mode for DNSSD. From nobody Thu Jul 24 11:01:48 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288861A0AF5 for ; Thu, 24 Jul 2014 11:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 ntdHoYmWhc2J for ; Thu, 24 Jul 2014 11:01:40 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30F531ABB2C for ; Thu, 24 Jul 2014 11:01:34 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id w61so3080775wes.37 for ; Thu, 24 Jul 2014 11:01:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=aOla7wCNj0XUrX5ecU7xVaycWwYCzULSSRLc6Hx4c/4=; b=yIE2QmFEMmr0ZQxCRlMRJ0+THAAs2W3jtCsBZaWEED7o/aVM95okrWUcLmwuousnhH 5OUgkSiDFicW6nJF8jV0Y8u3nFbDBeNarFbz9XZVYtDio7khTGd6dbFYFuSlDl+uIE9k q3GoimtwQOmkbfHhedqkjDwDSrdZk8wIfskYKq6l/ly/DcfkhXVcavOx2154TNYCDWP+ 1uAADAqI/8I1GO7zDE2fwyQpbtQN1+jc9YFHxAiKv0IEpRN7FHRbpN6i509qtswAUrWX IrxrVK90TZ8i2PieVOxgXgDxouMhAQ9MIrJLpfYSXSU+0Mj1OsZhvmmUplv1xhqeqFZL fxQw== X-Received: by 10.194.133.42 with SMTP id oz10mr14171270wjb.40.1406224891519; Thu, 24 Jul 2014 11:01:31 -0700 (PDT) Received: from dhcp-93fd.meeting.ietf.org (dhcp-93fd.meeting.ietf.org. [31.133.147.253]) by mx.google.com with ESMTPSA id rw4sm17771282wjb.44.2014.07.24.11.01.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 11:01:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: RJ Atkinson In-Reply-To: <7414908D-B2A9-4935-912F-EF3E4995065F@nominum.com> Date: Thu, 24 Jul 2014 14:01:28 -0400 Content-Transfer-Encoding: 7bit Message-Id: <6700E395-EC53-4726-B04E-633AF0306913@gmail.com> References: <331F9173-DB56-4D9A-B09F-956FF6D8DA2B@gmail.com> <1F1E6B22-5FF2-41DF-BA86-20A9D57E74CC@gmail.com> <7414908D-B2A9-4935-912F-EF3E4995065F@nominum.com> To: dnssd@ietf.org X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/SI2YnWdtgRqmJ5ptyRoHBt9XAmA Subject: Re: [dnssd] multicast over wireless links X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 18:01:42 -0000 On 24 Jul 2014, at 13:25 , Ted Lemon wrote: > On Jul 24, 2014, at 12:22 PM, RJ Atkinson wrote: >> IP/SATCOM is commonly used today within a single >> administrative domain to connect different sites >> together. > > Forgive me, but this doesn't sound like a valid use case > for DNSSD. It sounds like you are trying to use DNSSD > to solve a problem that is actually out of scope, ... I totally disagree with your conclusion. Perhaps I have not been adequately clear about the deployments ? I'm happy to chat further in the hallway if you're around IETF. Other than some links being made by VSAT terminals, the deployments are just like any other multiple IP subnet enterprise deployment or just like a typical university deployment. > Asking IEEE to fix WiFi is not really a good approach > to addressing the problem of inefficient multicast > for existing deployments, and this work is intended > to address existing deployments. Well, in both 6MAN and v6ops, roughly the same issue with the IEEE 802.11 MAC design has come up (e.g., in the context of IPv6 ND) and there has been a lot of pushback from multiple quarters on the idea that IPv6 ND ought to change to use less multicast -- and multiple suggestions from multiple parties that we need to engage with 802.11 to help them optimise their multicast support, rather than go change IPv6's current utter dependence on multicasting just because of a MAC design issue in one link technology. > Therefore, I think that if we want to address this use case, > the right way to do it is to come up with a mechanism > for doing multicast distribution of DNSSD updates on > broadcast-friendly networks, ...most deployed IP networks are broadcast-friendly and IPv6 is designed around the belief that multicasting is available and works reasonably well... > and not to just make this the default operational mode for DNSSD. I'd invert your suggestion. I'd say that by default we ought to stick with existing IP multicasting, in the ways it is used today (including, for example, IPv4 mast, IPv6 mast, IPv6 ND, and mDNS), but that we could document an optional-to-implement & optional-to-use link-specific optimisation that 802.11 implementers could support to reduce the multicast use over the air. The key, in my mind at least, is that any optimisations for 802.11 issues ought to be localised/isolated into the 802.11 devices -- rather than being imposed on everyone. In the IPv6 world, there has been some discussion (I think the idea goes back to Fred Baker during 6MAN earlier this week, but perhaps I've got the attribution wrong) that perhaps 802.11 base stations would cache and coordinate their ND transmissions, sending them periodically in a burst, for example. Something similar likely could help for mDNS/UDP/IP/802.11; after all, mDNS traffic is easy to identify for special treatment isolated *inside the wireless base station* -- and without adversely affecting everyone else. Yours, Ran Atkinson From nobody Thu Jul 24 11:09:56 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B581A0195 for ; Thu, 24 Jul 2014 11:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 OVp2K6dxbFbS for ; Thu, 24 Jul 2014 11:09:47 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B576A1A01F2 for ; Thu, 24 Jul 2014 11:09:36 -0700 (PDT) Received: from dhcp-a545.meeting.ietf.org (dhcp-a545.meeting.ietf.org [31.133.165.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 24CD713455 for ; Thu, 24 Jul 2014 14:09:37 -0400 (EDT) From: Tom Pusateri Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 24 Jul 2014 14:09:35 -0400 To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1971.5\)) X-Mailer: Apple Mail (2.1971.5) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/fq7WFqdh8u5z7RZIKWYyRlthbHM Subject: [dnssd] draft-aggarwal-dnssd-optimize-query-00 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 18:09:50 -0000 Ashutosh, Interesting draft. I have a few comments. 1. In section 3, you describe the TXT record filters in the additional = section. But you don't exactly specify what is in the query section. = Does this apply only for queries to instances of TXT records or does = this also apply to PTR queries for instances of services or for PTR = queries for just the service itself or all three? 2. There would seem to be a tradeoff in requesting too much or too = little. If you apply TXT filters and then don't get any responses, you = will have to query again with a broader filter. The optimal case will = depend on the service you're looking for. In some cases you would have = been better off without the filter. In other cases, knowing there is no = match is useful too. Each application will have to make that tradeoff = when it queries. 3. With your implied logical operations of TXT attribute filters, things = could get confusing when there are multiple records queried at once. You = should expand on section 3 to explain this after clarifying from = question #1 which record types are in the query section. It's perfectly = legal to query the PTR record for _printer._tcp.local and the TXT and = SRV records for HP OfficeJet._printer._tcp.local in the same query. Will = the TXT record in the additional records section have to be for an = instance like HP OfficeJet._printer._tcp.local or does it apply to the = PTR query for _printer._tcp.local? If the TXT record can be for a = service and not a specific instance, this changes who responds. When there are multiple TXT records in the additional section, it gets = more confusing on how to apply the logical operations. Thanks, Tom= From nobody Thu Jul 24 11:10:15 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86111A0195 for ; Thu, 24 Jul 2014 11:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 u9wmGfyiZEHC for ; Thu, 24 Jul 2014 11:10:02 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 476301A028B for ; Thu, 24 Jul 2014 11:09:57 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id k48so3112106wev.13 for ; Thu, 24 Jul 2014 11:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=A1vpUkR6vOiBrnrmOB/QzBpVYFdF5Hx10RkbPlfx/DA=; b=mivMKJXTPXbyS/RfIcICaqYntwmZxSweB+hOQxql2Ee4MfZ8HpzuP9rXPMl6Rt32Fo EDbFwSKCsd+oaXeM833KQgQ1pRu3sblmIUvFc24KqAiZmYDcAyrMSFQiK9nFMkoalfsR /CwyuKI7OiAt8SILVSCEfh+XzjzKVYgb1sxzU2Ga4Ra3Xu44hFE6Al5Qk9Ey+rIGTIhc VEkqyDX0KnEhsTbvKq57Yz2o+ssa3rMNNb+40s1dKKDEu+Hx6EcgukxeMQMOevlLKaEu DJkq5ul8a1mfZzAOPOYXVdBBywIo+BoxDjUy+28FcNPEot4dWr5ZRfov5FHAwfATvuID 7AKA== X-Received: by 10.194.133.1 with SMTP id oy1mr14519528wjb.87.1406225395961; Thu, 24 Jul 2014 11:09:55 -0700 (PDT) Received: from dhcp-93fd.meeting.ietf.org (dhcp-93fd.meeting.ietf.org. [31.133.147.253]) by mx.google.com with ESMTPSA id h3sm17863780wjn.10.2014.07.24.11.09.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 11:09:55 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 24 Jul 2014 14:09:52 -0400 Message-Id: To: dnssd@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/oC1IQ5ovBOxQrXP55QkVZkounwA Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-requirements-03 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 18:10:04 -0000 Tim, I apologise, but I would really appreciate it if the DNS-SD WG Last Call deadline for this draft were slightly extended, perhaps to 23:59 UK time on July 31st. That would permit folks to see today's presentations and discussions, re-read the draft based on today's meeting contents, and possibly provide additional review and feedback. I don't think such an extension would slow WG progress much. It possibly would lead to minor edits to the requirements draft. I do think it would increase the review coverage, not just from me, but also from other folks based on today's discussions. I regret that other matters kept me from providing timely feedback during the WG Last Call on this draft. Yours, Ran Atkinson From nobody Thu Jul 24 11:11:44 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F201A00F4 for ; Thu, 24 Jul 2014 11:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham 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 9_kzlr0ZZ8iz for ; Thu, 24 Jul 2014 11:11:33 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6E81B279E for ; Thu, 24 Jul 2014 11:11:32 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A425920012 for ; Thu, 24 Jul 2014 14:13:16 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3A0F563B0E; Thu, 24 Jul 2014 14:11:31 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2161763B0A for ; Thu, 24 Jul 2014 14:11:31 -0400 (EDT) From: Michael Richardson To: dnssd@ietf.org In-Reply-To: <364AAF85-5FB4-4828-A5A4-11160E747BC9@gmail.com> References: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> <20E4ED19-12BD-45D4-B690-8629B552B23B@gmail.com> <0E0BC226-E68E-4BC2-99EA-AFF1AF96A5EC@ecs.soton.ac.uk> <8465FD60-84CD-41B3-BBE3-1BDB52DF0DDB@hp.com> <364AAF85-5FB4-4828-A5A4-11160E747BC9@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/hPZ_W0HLolLqTFJgFZFVuXd_rS0 Subject: Re: [dnssd] Security through Obscurity X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 18:11:43 -0000 --=-=-= RJ Atkinson wrote: > The most common reason that my clients give me is that > predictable/deterministic IP addressing lowers their > operating costs. Larger enterprises often use DHCP > to obtain this. Smaller enterprises find DHCP complex > to deploy/configure, but they still want predictable > addressing in their IP network deployments. Three printers on the floor. One is reporting it is broken, so broken that you can't do much more than see that it exists. Which one is it? Match address to mac address on bottom of unit. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU9FMUICLcPvd0N1lAQJM9wgAsWzWZxzxyuAHHoQjZ4SfI6aYi13pq0Z0 2kuUJLBTYX/hE4rS+Wvz+xY7zGp95Z4kmSVFNUf9M0zGfRGy0S2sWIEQaabRN1wK YQ84VH10+mBs9soqxx51IcwXa9X9Q5c89Zz0FRtFlcpFMnrDo8Cfla5UXTchy9Zv 52YT6LwGfldFCI9ueDhiVehY7Yk4AcYFd1EJ9ATUQzVVOhjViE8VyKJxQcO9X2Xd xSGvOhQFie2VNG1MJyt5Z9gfOtdtz/RQoJHK5d8Q+xcT2a1L3jF9k7Z4zs8fGWsl wtqoHkR+Chuz9aVJMTgFypAi9EzXgtD/xsKAsCCLnxMPlZmZ05Hvkw== =sk73 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 24 11:24:19 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5701B27B5 for ; Thu, 24 Jul 2014 11:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 2XlNC7APMakZ for ; Thu, 24 Jul 2014 11:24:06 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB11F1A00DC for ; Thu, 24 Jul 2014 11:24:05 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ho1so4438497wib.10 for ; Thu, 24 Jul 2014 11:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=7ok6oz17PJxg1BSrxAGvaryZ/K8CWeuoWw9FvnGX27A=; b=0PZVAFwIDtI2r6fmH5j1eB+Bz7l59lU7QTGgtkV/CJvuonMas37y2OOQWAgdmJzfVP KXs0VfHjr8Zyd0K2hFTeL3Ub2pa4KTN5IAbw18KU7boc37AlPqvp43PwRlXApTAUFkwL G3reYWqzYKXpyHQiWdkNU9KX43twpf012EKe55EHjZyRcbSHQBz/HyMxQJoquOYPZbb3 AoMV6OEvo+6421Lmitz+W8Zwbq2leGbvJ9fF1Ev2xQkCh4U+1CVz+DDOAqWc1BgSvW3Y IyiwA7H3Ybwhk/qxNmrY8g6NGlDMzLjiJ7jKZ24zXj1CEOTGkdkYhoP6JFRlLVDOtQeq r4Kg== X-Received: by 10.194.5.103 with SMTP id r7mr14955697wjr.41.1406226242990; Thu, 24 Jul 2014 11:24:02 -0700 (PDT) Received: from dhcp-93fd.meeting.ietf.org (dhcp-93fd.meeting.ietf.org. [31.133.147.253]) by mx.google.com with ESMTPSA id di7sm17935846wjb.34.2014.07.24.11.24.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 11:24:02 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 24 Jul 2014 14:23:59 -0400 Message-Id: <421C934C-F0CB-4FBF-83ED-04A48526D5F2@gmail.com> To: dnssd@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/2QcJHKm2qoSSvg7h0YG3-Kl8uTk Subject: [dnssd] multicast over wireless links X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 18:24:12 -0000 Ted, When IP multicasting originated, wired Ethernet was a shared medium using CSMA/CD. A single IP/Ethernet frame would reach all nodes on that IP subnet. I still remember vampire taps and the big yellow Coax cable in my office from back then. In the 1990s, switched Ethernet became commonplace and (as deployed) the wire to the desktop was not a shared medium, but instead was a solo link back to the Ethernet switch. This meant that the IP/Ethernet frame did not automatically get seen by all nodes on that Ethernet (bridged) link. The IETF didn't drop IP multicasting, or discourage use of IP multicasting. Instead, Ethernet switch vendors made various optimisations inside their Ethernet switch products (e.g. IGMP snooping) to make IP multicasting work well over wired switched Ethernet. IETF folks were involved in helping the Ethernet vendors understand some implementation options for those optimisations in those Ethernet products. The situation today with 802.11 is entirely analogous to that previous situation with wired Ethernet moving from shared CSMA/CD to switched dedicated links, and the IETF community should have the same response -- don't drop the use of IP multicasting, don't discourage use of IP multicasting -- instead engage with others so that a link-specific optimisation can be put into use only for -- and only within -- those link-specific vendor devices (e.g., wireless access point, 802.11 radio, or whatever term one prefers). Yours, Ran From nobody Thu Jul 24 11:33:52 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3691B27EC for ; Thu, 24 Jul 2014 11:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 AnTKj9pEWIoO for ; Thu, 24 Jul 2014 11:33:40 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan20.extendcp.co.uk [176.32.226.66]) (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 B5EC51A0194 for ; Thu, 24 Jul 2014 11:33:40 -0700 (PDT) Received: from lb1.hi.local ([10.0.1.197] helo=mailscan2.extendcp.co.uk) by mailscan-g64.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1XANpj-0003Ht-4i for dnssd@ietf.org; Thu, 24 Jul 2014 19:33:39 +0100 Received: from lb1.hi.local ([10.0.1.197] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1XANpg-0000rS-Et for dnssd@ietf.org; Thu, 24 Jul 2014 19:33:39 +0100 Received: from host86-163-16-160.range86-163.btcentralplus.com ([86.163.16.160] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1XANpg-0002pw-1q for dnssd@ietf.org; Thu, 24 Jul 2014 19:33:36 +0100 Message-ID: <53D15182.1040307@gridmerge.com> Date: Thu, 24 Jul 2014 19:33:38 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dnssd@ietf.org References: <421C934C-F0CB-4FBF-83ED-04A48526D5F2@gmail.com> In-Reply-To: <421C934C-F0CB-4FBF-83ED-04A48526D5F2@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050100040905090000050503" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/neX7E43B2WkrpTVy3mc8DDWeO80 Subject: Re: [dnssd] multicast over wireless links X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com 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 Jul 2014 18:33:45 -0000 This is a cryptographically signed message in MIME format. --------------ms050100040905090000050503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable But as Alf said earlier, there are other wireless technologies which are = not well suited to IP multicast traffic. 802.15.4-based mesh networks=20 are a very good example and there is certainly a use case for DNS-SD in=20 these type of networks. Robert On 24/07/2014 7:23 PM, RJ Atkinson wrote: > Ted, > > When IP multicasting originated, wired Ethernet was a shared > medium using CSMA/CD. A single IP/Ethernet frame would reach > all nodes on that IP subnet. I still remember vampire taps > and the big yellow Coax cable in my office from back then. > > In the 1990s, switched Ethernet became commonplace and > (as deployed) the wire to the desktop was not a shared > medium, but instead was a solo link back to the Ethernet > switch. This meant that the IP/Ethernet frame did not > automatically get seen by all nodes on that Ethernet > (bridged) link. The IETF didn't drop IP multicasting, > or discourage use of IP multicasting. Instead, Ethernet > switch vendors made various optimisations inside their > Ethernet switch products (e.g. IGMP snooping) to make > IP multicasting work well over wired switched Ethernet. > IETF folks were involved in helping the Ethernet vendors > understand some implementation options for those optimisations > in those Ethernet products. > > The situation today with 802.11 is entirely analogous > to that previous situation with wired Ethernet moving > from shared CSMA/CD to switched dedicated links, and the > IETF community should have the same response -- don't drop > the use of IP multicasting, don't discourage use of > IP multicasting -- instead engage with others so that a > link-specific optimisation can be put into use only for > -- and only within -- those link-specific vendor devices > (e.g., wireless access point, 802.11 radio, or whatever > term one prefers). > > Yours, > > Ran > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --------------ms050100040905090000050503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNDA3MjQxODMzMzhaMCMGCSqGSIb3DQEJBDEWBBRdo338iMD7a8Y+Ufjpx9gKXMiuqzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAF6nMiIVCMGRj89NrLI4yM8ZevXdLZP37v+v7gnaM3ky5uqc iauxb0MmpBikLB1TarU1KYK7fIcUKsTWFU+09OtOshu8iLawKcr3c0aiEiShq7HjhEMRw0pn JQT2yzUkfK9Kwae8e7C0H+wxSWlFc4kHdQky+VHCxEs7TbTAhEPhCdQCqDk89WGoBm37SWgC 6yuNhcDod0xnXF0TF4B60hBDhdQrTWh52TTSvBigNqEilo6yVdBVdSRJSP6k6vR/A+q8MtST DRLi01hlIt8nvcs4f3WFFzYRlDFTPRUEksuvcAxpYCULlfzZjTc8g0QFtadr/9BISO8NNGSJ mOKvPJwAAAAAAAA= --------------ms050100040905090000050503-- From nobody Thu Jul 24 11:44:01 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E722D1A0AD2 for ; Thu, 24 Jul 2014 11:43:59 -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 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 0R9Tz7SD2AEL for ; Thu, 24 Jul 2014 11:43:58 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B821A03E4 for ; Thu, 24 Jul 2014 11:43:58 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 877871B85FD for ; Thu, 24 Jul 2014 11:43:58 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 75D32190052; Thu, 24 Jul 2014 11:43:58 -0700 (PDT) Received: from nat64.meeting.ietf.org (31.130.238.225) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Jul 2014 11:43:58 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <53D15182.1040307@gridmerge.com> Date: Thu, 24 Jul 2014 14:43:54 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <324FDCE8-C812-45A4-BA47-D35ACC896A36@nominum.com> References: <421C934C-F0CB-4FBF-83ED-04A48526D5F2@gmail.com> <53D15182.1040307@gridmerge.com> To: X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [31.130.238.225] Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/N0XPrLoudQsGpjRM7kk-XtUMP5M Cc: dnssd@ietf.org Subject: Re: [dnssd] multicast over wireless links X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 18:44:00 -0000 On Jul 24, 2014, at 2:33 PM, Robert Cragie = wrote: > But as Alf said earlier, there are other wireless technologies which = are not well suited to IP multicast traffic. 802.15.4-based mesh = networks are a very good example and there is certainly a use case for = DNS-SD in these type of networks. Broadcast is a good idea when the information being distributed is = needed by all receivers, and when receivers' connections are persistent. = But newcomers to the network don't have the information until the next = broadcast, or have incomplete information until the next broadcast, or = have to trigger a new broadcast. In practice, in my experience, what this means is that multicast winds = up producing much more traffic than would a non-multicast solution. So = that's why I suggest that it's better to rely heavily on multicast only = in environments where multicast really is cheaper than unicast. (Of course, clearly DNSSD will use multicast to some extent; the = question is how much.) From nobody Thu Jul 24 11:58:28 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3EA1B27CD for ; Thu, 24 Jul 2014 11:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 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, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=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 uhPAiLSVfV8K for ; Thu, 24 Jul 2014 11:58:21 -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 4E2D21A0146 for ; Thu, 24 Jul 2014 11:58: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 s6OIwEUD014043; Thu, 24 Jul 2014 19:58:14 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s6OIwEUD014043 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1406228295; bh=2yVwtj23FscpVLhjppMYh8AucqY=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=THPRXo4c927rt69uT5p/IrKx5aYy+qLh1EZi2abEPKOk+mLHbjBMuy5k6C97KTs21 q0C2a/ATUqdnQfGygfZw19SgjkcSybz7vf5DZUMXwOeWKsupVZPAv/v2XUnL9mfFQA 0IiedWgCpQyE4ysIKU+q03dgupOLwwMN33/Fmn0M= 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 q6NJwE01767060803p ret-id none; Thu, 24 Jul 2014 19:58:14 +0100 Received: from eduroam-v6.meeting.ietf.org (eduroam-v6.meeting.ietf.org [IPv6:2001:67c:370:152:e189:b9ca:8222:7094] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s6OIvtul022045 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Jul 2014 19:57:58 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_F8F5F519-99DC-42CB-B1CA-F7A4EE267DAA" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Chown In-Reply-To: <6700E395-EC53-4726-B04E-633AF0306913@gmail.com> Date: Thu, 24 Jul 2014 19:57:55 +0100 Message-ID: References: <331F9173-DB56-4D9A-B09F-956FF6D8DA2B@gmail.com> <1F1E6B22-5FF2-41DF-BA86-20A9D57E74CC@gmail.com> <7414908D-B2A9-4935-912F-EF3E4995065F@nominum.com> <6700E395-EC53-4726-B04E-633AF0306913@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1878.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q6NJwE017670608000; tid=q6NJwE01767060803p; 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: s6OIwEUD014043 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/nvBkl-TOko2W19uJPOfeJpQNYy8 Cc: dnssd@ietf.org Subject: Re: [dnssd] multicast over wireless links X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 18:58:23 -0000 --Apple-Mail=_F8F5F519-99DC-42CB-B1CA-F7A4EE267DAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 24 Jul 2014, at 19:01, RJ Atkinson wrote: > > In the IPv6 world, there has been some discussion (I think > the idea goes back to Fred Baker during 6MAN earlier this week,=20 > but perhaps I've got the attribution wrong) that perhaps=20 > 802.11 base stations would cache and coordinate their ND=20 > transmissions, sending them periodically in a burst, for example. =20 > Something similar likely could help for mDNS/UDP/IP/802.11;=20 > after all, mDNS traffic is easy to identify for special treatment=20 > isolated *inside the wireless base station* -- and without=20 > adversely affecting everyone else. =20 So for those who want to look at this, what was discussed in intarea and = v6ops (we=92ve had no 6man at this IETF) was based on presentations on = the following draft: = http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-0= 0 My personal view is that what we design here should be consdirate of the = multicast messaging load it may generate, but for those messages that = are generated we may see lower layer optimisations being made for = specific link types (for example the =91bundling=92 suggested above for = 802.11) and those optimisations may (for example) affect the timeliness = of delivery. The latter may reinforce the desirability of mechanisms = such as DNS LLQ. =20 Tim= --Apple-Mail=_F8F5F519-99DC-42CB-B1CA-F7A4EE267DAA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On 24 = Jul 2014, at 19:01, RJ Atkinson <rja.lists@gmail.com> = wrote:

<snip>
In the IPv6 world, there has been some = discussion (I think
the idea goes back to Fred Baker during 6MAN = earlier this week,
but perhaps I've got the attribution wrong) that = perhaps
802.11 base stations would cache and coordinate their ND =
transmissions, sending them periodically in a burst, for example. =  
Something similar likely could help for mDNS/UDP/IP/802.11; =
after all, mDNS traffic is easy to identify for special treatment =
isolated *inside the wireless base station* -- and without =
adversely affecting everyone else. =  

So for those who want to look at = this, what was discussed in intarea and v6ops (we=92ve had no 6man at = this IETF) was based on presentations on the following = draft:


My personal view is that what = we design here should be consdirate of the multicast messaging load it = may generate, but for those messages that are generated we may see lower = layer optimisations being made for specific link types (for example the = =91bundling=92 suggested above for 802.11) and those optimisations may = (for example) affect the timeliness of delivery. The latter may = reinforce the desirability of mechanisms such as DNS = LLQ.
 
Tim
= --Apple-Mail=_F8F5F519-99DC-42CB-B1CA-F7A4EE267DAA-- From nobody Thu Jul 24 11:59:32 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FA81A0146 for ; Thu, 24 Jul 2014 11:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 BxnWmeJLtVWX for ; Thu, 24 Jul 2014 11:59:19 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 923C31A002A for ; Thu, 24 Jul 2014 11:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qce.qualcomm.com; i=@qce.qualcomm.com; q=dns/txt; s=qcdkim; t=1406228359; x=1437764359; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NUd6+lg9pyUq6dr4TjqXmWAW7MSxLFcQKnMKU7NJeiw=; b=bc0SVOwHt82o3bTdvaII8sxwkkmu8SCnHlBOnABMYVbMZ7OwjeW8yZwv KD4MXxZyuA0TMKmvfBMR6zBMdP/kb4hT89NFVEfJNkx7is7gEOwQz8vjB MD6vDdV4NMc3+Z01ONK7jRXne6dcvL/U6Cgw2AZ7zjD15qk7YxMVUj99S 8=; X-IronPort-AV: E=McAfee;i="5600,1067,7509"; a="71717997" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth02.qualcomm.com with ESMTP; 24 Jul 2014 11:58:57 -0700 X-IronPort-AV: E=Sophos;i="5.01,725,1400050800"; d="scan'208";a="719020047" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 24 Jul 2014 11:58:57 -0700 Received: from NASANEXD02B.na.qualcomm.com ([169.254.2.117]) by nasanexhc04.na.qualcomm.com ([172.30.48.17]) with mapi id 14.03.0181.006; Thu, 24 Jul 2014 11:58:57 -0700 From: "Aggarwal, Ashutosh" To: Tom Pusateri , "dnssd@ietf.org" Thread-Topic: [dnssd] draft-aggarwal-dnssd-optimize-query-00 Thread-Index: AQHPp2p5gpdN6b7aTkawAnlhIRp6sJuvjI7Q Date: Thu, 24 Jul 2014 18:58:56 +0000 Message-ID: <4ADFCA4A44B18946883BA96F64773E0150E2CF31@NASANEXD02B.na.qualcomm.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/9oQ30Rw5Szgs_ZE-0ZN_GeyrM4g Cc: "Dave Thaler \(dthaler@microsoft.com\)" Subject: Re: [dnssd] draft-aggarwal-dnssd-optimize-query-00 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 18:59:26 -0000 Thanks for your comments. Please see below: -----Original Message----- From: dnssd [mailto:dnssd-bounces@ietf.org] On Behalf Of Tom Pusateri Sent: Thursday, July 24, 2014 11:10 AM To: dnssd@ietf.org Subject: [dnssd] draft-aggarwal-dnssd-optimize-query-00 Ashutosh, Interesting draft. I have a few comments. 1. In section 3, you describe the TXT record filters in the additional sect= ion. But you don't exactly specify what is in the query section. Does this = apply only for queries to instances of TXT records or does this also apply = to PTR queries for instances of services or for PTR queries for just the se= rvice itself or all three? [Aggarwal, Ashutosh]=20 This contribution was written to optimize the DNS-SD query scenario when th= e client application issues the PTR query with the service name. The contri= bution proposes to add DNS TXT records for such queries.=20 2. There would seem to be a tradeoff in requesting too much or too little. = If you apply TXT filters and then don't get any responses, you will have to= query again with a broader filter. The optimal case will depend on the ser= vice you're looking for. In some cases you would have been better off witho= ut the filter. In other cases, knowing there is no match is useful too. Eac= h application will have to make that tradeoff when it queries. [Aggarwal, Ashutosh]=20 You are absolutely correct regarding trade-offs. The pre-condition is that = the client application knows what constraints or filters it is looking to a= pply and it should specify them in the initial query. It would be better th= an querying for the service name and then establishing a connection with ea= ch service instance for subsequent negotiation. If the client application d= oesn't need to apply any filter, it can send the query with the service nam= e only. The decision regarding which keys/filters to apply is application s= pecific as you mention. Just like DNS-SD has the provision for the responde= r to add key/value pairs in the DNS response message, the contribution prop= oses to enable the use of DNS TXT records in the PTR queries for the servic= e name. 3. With your implied logical operations of TXT attribute filters, things co= uld get confusing when there are multiple records queried at once. You shou= ld expand on section 3 to explain this after clarifying from question #1 wh= ich record types are in the query section. It's perfectly legal to query th= e PTR record for _printer._tcp.local and the TXT and SRV records for HP Off= iceJet._printer._tcp.local in the same query. Will the TXT record in the ad= ditional records section have to be for an instance like HP OfficeJet._prin= ter._tcp.local or does it apply to the PTR query for _printer._tcp.local? I= f the TXT record can be for a service and not a specific instance, this cha= nges who responds. When there are multiple TXT records in the additional section, it gets more= confusing on how to apply the logical operations. [Aggarwal, Ashutosh]=20 [Aggarwal, Ashutosh]=20 I added multiple TXT records details if we want to allow for complex filter= criteria. I can add some examples to clarify for sure. We can discuss if w= e can summarize the desired filter criteria using a single TXT record. The = filtering scheme was proposed for PTR query with the service name. Hope this answers your comments, Ashutosh Thanks, Tom _______________________________________________ dnssd mailing list dnssd@ietf.org https://www.ietf.org/mailman/listinfo/dnssd From nobody Thu Jul 24 12:08:56 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7501A0A98 for ; Thu, 24 Jul 2014 12:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.222 X-Spam-Level: X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=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 zFfNmSTPZMqB for ; Thu, 24 Jul 2014 12:08:45 -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 3FD1A1B27A7 for ; Thu, 24 Jul 2014 12:07:48 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s6OJ7IRV016376; Thu, 24 Jul 2014 20:07:18 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s6OJ7IRV016376 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1406228838; bh=0q+SujoXfca0Y+tjjTB+EndJY2o=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=WyQ8zhZcsHANXi4ZAIzJ5UN0baZ2CUIQw4aqxKrqJ0KDqZarF9beNpEFjEwjsWj7E PUJzBhHMulfn7FuL1K7KJuulSRlcV4vcplmaPs+9f9ZJ7mR/zBgnmMkVbDyLxtWK0A vgkAK7pjd2MwmjDAArbWAquQdThIW5Gv7BjSzU4g= 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 q6NK7I0176706116nm ret-id none; Thu, 24 Jul 2014 20:07:18 +0100 Received: from eduroam-v6.meeting.ietf.org (eduroam-v6.meeting.ietf.org [IPv6:2001:67c:370:152:e189:b9ca:8222:7094] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s6OJ6vRn024016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Jul 2014 20:07:00 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Chown In-Reply-To: Date: Thu, 24 Jul 2014 20:06:57 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <74C6BD68-F8EA-45D2-8B8D-B38F726E5075@ecs.soton.ac.uk> To: RJ Atkinson X-Mailer: Apple Mail (2.1878.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q6NK7I017670611600; tid=q6NK7I0176706116nm; 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: s6OJ7IRV016376 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/y6FBfUWvzcnBSJQ1PivQqfHS_1U Cc: dnssd@ietf.org Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-requirements-03 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 19:08:47 -0000 Hi Ran, =20 On 24 Jul 2014, at 19:09, RJ Atkinson wrote: > Tim, >=20 > I apologise, but I would really appreciate it if the DNS-SD WG=20 > Last Call deadline for this draft were slightly extended,=20 > perhaps to 23:59 UK time on July 31st. >=20 > That would permit folks to see today's presentations and discussions, > re-read the draft based on today's meeting contents, and possibly=20 > provide additional review and feedback. >=20 > I don't think such an extension would slow WG progress much. > It possibly would lead to minor edits to the requirements draft. > I do think it would increase the review coverage, not just > from me, but also from other folks based on today's discussions. >=20 > I regret that other matters kept me from providing timely > feedback during the WG Last Call on this draft. We have already received a number of useful comments after the formal = WGLC deadline, which I believe we should incorporate. Those comments seem to be relatively minor, but are ones worth = incorporating in a revved ID before we pass it up to Ted (who has also = reviewed the text and made a small number of - again fairly minor - = useful suggestions). I=92ll be working with the authors to address the comments = appropriately. I=92m not sure yet that we need or should formally extend = the WGLC. I=92ll happily take Ted=92s input on that. For now, I suggest = if you have comments, please continue to make them. It also seems Ted = plans an IETF Last Call, but it would be desirable to iron out any = comments prior to that, so long as we=92re following due process. Tim= From nobody Thu Jul 24 12:09:33 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708411A002A for ; Thu, 24 Jul 2014 12:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 19ZgKKodE5m3 for ; Thu, 24 Jul 2014 12:09:27 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B01A1B2830 for ; Thu, 24 Jul 2014 12:08:50 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9766920012 for ; Thu, 24 Jul 2014 15:10:34 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2FBB563B0E; Thu, 24 Jul 2014 15:08:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 160F663B0A for ; Thu, 24 Jul 2014 15:08:48 -0400 (EDT) From: Michael Richardson cc: dnssd@ietf.org In-Reply-To: <24377.1406225491@sandelman.ca> References: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> <20E4ED19-12BD-45D4-B690-8629B552B23B@gmail.com> <0E0BC226-E68E-4BC2-99EA-AFF1AF96A5EC@ecs.soton.ac.uk> <8465FD60-84CD-41B3-BBE3-1BDB52DF0DDB@hp.com> <364AAF85-5FB4-4828-A5A4-11160E747BC9@gmail.com> <24377.1406225491@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/UOm60pMLvjk_P16TZKype8RFzLE Subject: Re: [dnssd] Security through Obscurity X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 19:09:28 -0000 RJ Atkinson wrote: > The most common reason that my clients give me is that > predictable/deterministic IP addressing lowers their > operating costs. Larger enterprises often use DHCP > to obtain this. Smaller enterprises find DHCP complex > to deploy/configure, but they still want predictable > addressing in their IP network deployments. Three printers on the floor. One is reporting it is broken, so broken that you can't do much more than see that it exists. If the IP(v6) address is predictable, and related in some way to the EUI-64, then you can find the right unit. The printer has little privacy concerns, seldom visits internet cafes, and is never found it airport lounges. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Thu Jul 24 12:55:37 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FF81A0ACF for ; Thu, 24 Jul 2014 12:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 008EplCx5cc8 for ; Thu, 24 Jul 2014 12:55:32 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan15.extendcp.co.uk [79.170.45.26]) (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 628831A0AC8 for ; Thu, 24 Jul 2014 12:55:32 -0700 (PDT) Received: from lb1.hi.local ([10.0.1.197] helo=mailscan2.extendcp.co.uk) by mailscan-g64.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1XAP6x-0007zK-5R for dnssd@ietf.org; Thu, 24 Jul 2014 20:55:31 +0100 Received: from lb1.hi.local ([10.0.1.197] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1XAP6t-0002hh-SC for dnssd@ietf.org; Thu, 24 Jul 2014 20:55:30 +0100 Received: from host86-163-16-160.range86-163.btcentralplus.com ([86.163.16.160] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1XAP6t-0006Tq-HH for dnssd@ietf.org; Thu, 24 Jul 2014 20:55:27 +0100 Message-ID: <53D164B1.3000909@gridmerge.com> Date: Thu, 24 Jul 2014 20:55:29 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dnssd@ietf.org References: <421C934C-F0CB-4FBF-83ED-04A48526D5F2@gmail.com> <53D15182.1040307@gridmerge.com> <324FDCE8-C812-45A4-BA47-D35ACC896A36@nominum.com> In-Reply-To: <324FDCE8-C812-45A4-BA47-D35ACC896A36@nominum.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010100070400050809030701" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/hb6FwOO4WM34ehJUd0YgHiDOIH8 Subject: Re: [dnssd] multicast over wireless links X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com 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 Jul 2014 19:55:34 -0000 This is a cryptographically signed message in MIME format. --------------ms010100070400050809030701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable +1. Of course 802.15.4-based mesh networks have to cope with multicast=20 traffic but its use should be carefully considered. Robert On 24/07/2014 7:43 PM, Ted Lemon wrote: > On Jul 24, 2014, at 2:33 PM, Robert Cragie wrote: >> But as Alf said earlier, there are other wireless technologies which a= re not well suited to IP multicast traffic. 802.15.4-based mesh networks = are a very good example and there is certainly a use case for DNS-SD in t= hese type of networks. > Broadcast is a good idea when the information being distributed is need= ed by all receivers, and when receivers' connections are persistent. Bu= t newcomers to the network don't have the information until the next broa= dcast, or have incomplete information until the next broadcast, or have t= o trigger a new broadcast. > > In practice, in my experience, what this means is that multicast winds = up producing much more traffic than would a non-multicast solution. So = that's why I suggest that it's better to rely heavily on multicast only i= n environments where multicast really is cheaper than unicast. > > (Of course, clearly DNSSD will use multicast to some extent; the questi= on is how much.) > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --------------ms010100070400050809030701 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNDA3MjQxOTU1MjlaMCMGCSqGSIb3DQEJBDEWBBR8pfsDd75ooQUXfYOfFrtCqOxUuzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAKcdVXZGjlXZ/LIyhuc37jNHG28D27M4L5N4O5xqQUrGgBH9 xqwY1lDkT+eMr7VkJ6wnbQkqY0FQy6gSNL+nVArNpzzDoNjOTpZtNYjJL5wyHfCVzjqrvrqA +pnoYBP6Nn1+aqdOVKy7q8gyzqaUa8if2W+3xoH/aVayoucWAEC15is7CCV3nEbk5v2jI0b2 nAsINu3PryUua/hpf1q9bSpUWd7aIlcLnGa+20CagsqTY5QXFPGDeedqp6fQ8DCM0X3nkA6q NN+IE94kJLLhh+2e3ncPjIhfGfZWYHewFVYjj0n0xAufiqdGpzkKon7jKTPNejfzOv+5h+3/ pm7GL5EAAAAAAAA= --------------ms010100070400050809030701-- From nobody Thu Jul 24 13:08:55 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16BC1A01E8 for ; Thu, 24 Jul 2014 13:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 VPoDaii-aqvM for ; Thu, 24 Jul 2014 13:08:53 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3891A0194 for ; Thu, 24 Jul 2014 13:08:53 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so4656465wiv.9 for ; Thu, 24 Jul 2014 13:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=9rpKzLGkux2viNf6I6fOIy8CfEzlpej+cC6KtOkGlyw=; b=GuGL053D96YH1C29lYzlOXS/7mHGKj1RBu8lnTviSBna+7wkkBkd6k/1ry3WugL3jI 2+QtwePMVQAeCaLGgQulfXyNaLo6N/Z65oeNNXD/SY63kT/QxpmTHq5IgLO+oyHYFuxp qmepfF5P/VEFpDxV6MekbcwxjVyTUYf2JhliVPwlp912ZpSnthD3QWNCbTgibPWwf/Y+ llBYtOyKWJUNKy9/gG21hZ53j+FnOhVJ/sRd1mHjSaowZ062qWBj/FdQwMpIQ4uG9Z9v TV3jxZDZfVyQDreqCfEtIU0fmVw9TgEKtCXKu3uzdjru98ghMLm1rPPFHvw6JkNohcIb 8LZg== X-Received: by 10.194.133.42 with SMTP id oz10mr15126043wjb.40.1406232531972; Thu, 24 Jul 2014 13:08:51 -0700 (PDT) Received: from dhcp-b535.meeting.ietf.org (dhcp-b535.meeting.ietf.org. [31.133.181.53]) by mx.google.com with ESMTPSA id rw4sm18623787wjb.44.2014.07.24.13.08.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 13:08:50 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 24 Jul 2014 16:08:47 -0400 Message-Id: <194DD0CC-89B3-4FE6-AFE4-1B7A3E064942@gmail.com> To: dnssd@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/mtUHrT3CDXevnKq2n-j6H10aoVk Subject: [dnssd] Requirement #9: Proposed Edit X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 20:08:54 -0000 Existing text from today's slides: SSD should operate efficiently in all networks, with particular consideration for potentially lossy or multicast-challenged wireless networks. Proposed revised text from today's microphone: SSD should operate efficiently in all networks. Rationale: (1) The text to be deleted is superfluous given the phrase "all networks" that precedes it. (2) We ought NOT be trying to optimise IP services for particular link layers (see previous discussion about how the IETF handled IP multicasting when Ethernet switches first appeared). (3) The current text appears to discourage use of widely-deployed, well-accepted IETF technology (i.e., IP multicasting). Yours, Ran Atkinson From nobody Thu Jul 24 13:14:35 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1B91A0AD2 for ; Thu, 24 Jul 2014 13:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 l_vDEAu26Ij6 for ; Thu, 24 Jul 2014 13:14:32 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9731A0B02 for ; Thu, 24 Jul 2014 13:14:32 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id k14so3284818wgh.20 for ; Thu, 24 Jul 2014 13:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uqDQLA/ECEkuBBGuZ/GKKJ0NebaP/3G/tWbTjfaa5Ow=; b=b8rZi5w/nbQiZUh0rvX6vMoEmboOjvR5L0PZiNJdfg1uCYTSe8FA7oCURhvlOauyN/ Nnfb3cquzzpC8BCXkQxieUUsE50odfRQghErWiFq5lsBZ2Sm5EcFdEJ8cNkga6HkFH7b IesWKx3rq5ralB8JDfJakuKG7fmjQLef9+VcG8gJJb8MzQG/hX0c58OlPZnMvLfgPUv5 Qjc3fukEWTc6HFxHIffCyR96HYetYGO14iKFLOGj/4zVHWubSks9Gdyr6vj0i7c1KOZm zSpkBWY0oL9D7siLEV0cODfhxS8bzZstgc0wfhOctGXFk0tbeiHZneqChf7Ntm+PCDxo g0FQ== X-Received: by 10.180.19.200 with SMTP id h8mr38914991wie.32.1406232870512; Thu, 24 Jul 2014 13:14:30 -0700 (PDT) Received: from dhcp-b535.meeting.ietf.org (dhcp-b535.meeting.ietf.org. [31.133.181.53]) by mx.google.com with ESMTPSA id m3sm26701198wik.7.2014.07.24.13.14.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 13:14:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: RJ Atkinson In-Reply-To: Date: Thu, 24 Jul 2014 16:14:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <173A86B2-0F54-4A99-A8F1-9706B1E49404@gmail.com> References: <331F9173-DB56-4D9A-B09F-956FF6D8DA2B@gmail.com> <1F1E6B22-5FF2-41DF-BA86-20A9D57E74CC@gmail.com> <7414908D-B2A9-4935-912F-EF3E4995065F@nominum.com> <6700E395-EC53-4726-B04E-633AF0306913@gmail.com> To: Tim Chown X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/k4iqwyVbkYjNQ7Xp1BTMQIRmB3g Cc: dnssd@ietf.org Subject: Re: [dnssd] multicast over wireless links X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 20:14:34 -0000 On 24 Jul 2014, at 14:57 , Tim Chown wrote: > (we=92ve had no 6man at this IETF) Tim, My apologies for having an unclear antecedent. This topic was discussed during 6MAN at IETF/London,=20 for example with respect to the proposal by Erik Nordmark=20 et alia to modify IPv6 ND to better suit 802.11 links. Cheers, Ran From nobody Thu Jul 24 13:21:24 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAFA1B27D7 for ; Thu, 24 Jul 2014 13:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 PrLl22Oi9XND for ; Thu, 24 Jul 2014 13:21:20 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB33A1B2802 for ; Thu, 24 Jul 2014 13:21:15 -0700 (PDT) Received: from dhcp-a545.meeting.ietf.org (dhcp-a545.meeting.ietf.org [31.133.165.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 2273A1348D; Thu, 24 Jul 2014 16:21:16 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1971.5\)) From: Tom Pusateri In-Reply-To: <4ADFCA4A44B18946883BA96F64773E0150E2CF31@NASANEXD02B.na.qualcomm.com> Date: Thu, 24 Jul 2014 16:21:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8242FDC4-4763-47B5-A205-E41C23A0367B@bangj.com> References: <4ADFCA4A44B18946883BA96F64773E0150E2CF31@NASANEXD02B.na.qualcomm.com> To: "Aggarwal, Ashutosh" X-Mailer: Apple Mail (2.1971.5) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/K4bPQMJ9jVyAS8-8BtyrUFFdORo Cc: "dnssd@ietf.org" , "Dave Thaler \(dthaler@microsoft.com\)" Subject: Re: [dnssd] draft-aggarwal-dnssd-optimize-query-00 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 20:21:23 -0000 > On Jul 24, 2014, at 2:58 PM, Aggarwal, Ashutosh = wrote: >=20 > Thanks for your comments. Please see below: >=20 > -----Original Message----- > From: dnssd [mailto:dnssd-bounces@ietf.org] On Behalf Of Tom Pusateri > Sent: Thursday, July 24, 2014 11:10 AM > To: dnssd@ietf.org > Subject: [dnssd] draft-aggarwal-dnssd-optimize-query-00 >=20 > Ashutosh, > Interesting draft. I have a few comments. >=20 > 1. In section 3, you describe the TXT record filters in the additional = section. But you don't exactly specify what is in the query section. = Does this apply only for queries to instances of TXT records or does = this also apply to PTR queries for instances of services or for PTR = queries for just the service itself or all three? >=20 > [Aggarwal, Ashutosh]=20 > This contribution was written to optimize the DNS-SD query scenario = when the client application issues the PTR query with the service name. = The contribution proposes to add DNS TXT records for such queries.=20 >=20 Ok, but a TXT record is for an instance of a service. So your proposal = is now changing what is expected in a TXT record. Let's clarify to be sure. You are suggesting this: ---------------------------------------- Query Section: _printer._tcp.local. IN PTR Additional Records Section: _printer._tcp.local. IN TXT "color=3DTrue" ---------------------------------------- An mDNS participant that isn't aware of your draft, would expect the TXT = record in the AR Section to be an actual instance of a service. = Something like this would be more expected: HP OfficeJet._printer._tcp.local. IN TXT "color=3DTrue" and the recipient wouldn't know what to do with _printer._tcp.local. IN TXT "color=3DTrue" since it is not an instance of a service. Thanks, Tom > 2. There would seem to be a tradeoff in requesting too much or too = little. If you apply TXT filters and then don't get any responses, you = will have to query again with a broader filter. The optimal case will = depend on the service you're looking for. In some cases you would have = been better off without the filter. In other cases, knowing there is no = match is useful too. Each application will have to make that tradeoff = when it queries. > [Aggarwal, Ashutosh]=20 > You are absolutely correct regarding trade-offs. The pre-condition is = that the client application knows what constraints or filters it is = looking to apply and it should specify them in the initial query. It = would be better than querying for the service name and then establishing = a connection with each service instance for subsequent negotiation. If = the client application doesn't need to apply any filter, it can send the = query with the service name only. The decision regarding which = keys/filters to apply is application specific as you mention. Just like = DNS-SD has the provision for the responder to add key/value pairs in the = DNS response message, the contribution proposes to enable the use of DNS = TXT records in the PTR queries for the service name. >=20 > 3. With your implied logical operations of TXT attribute filters, = things could get confusing when there are multiple records queried at = once. You should expand on section 3 to explain this after clarifying = from question #1 which record types are in the query section. It's = perfectly legal to query the PTR record for _printer._tcp.local and the = TXT and SRV records for HP OfficeJet._printer._tcp.local in the same = query. Will the TXT record in the additional records section have to be = for an instance like HP OfficeJet._printer._tcp.local or does it apply = to the PTR query for _printer._tcp.local? If the TXT record can be for a = service and not a specific instance, this changes who responds. > When there are multiple TXT records in the additional section, it gets = more confusing on how to apply the logical operations. >=20 > [Aggarwal, Ashutosh]=20 > [Aggarwal, Ashutosh]=20 > I added multiple TXT records details if we want to allow for complex = filter criteria. I can add some examples to clarify for sure. We can = discuss if we can summarize the desired filter criteria using a single = TXT record. The filtering scheme was proposed for PTR query with the = service name. >=20 > Hope this answers your comments, > Ashutosh >=20 >=20 > Thanks, > Tom > _______________________________________________ > 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 Thu Jul 24 13:27:29 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43A91B2896 for ; Thu, 24 Jul 2014 13:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 olqB5d2I2AEe for ; Thu, 24 Jul 2014 13:27:25 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 442611B289B for ; Thu, 24 Jul 2014 13:27:16 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id bs8so10352570wib.3 for ; Thu, 24 Jul 2014 13:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=tpV55QxRxOMRGH4urLTB1aUIcFYPqHRFu2BtGwRFGlU=; b=gZDnEWeD02F20awHvyZXMnN9qmL2aM+BUZ8MHe06SGMO8H47RieHZjqumrNLjVgIOe 1uu2KmzQHGb1He3Rr5Upwxp04n2Jc0gwr5fXdrRtzH9Zqf+v6MQcnGpYafbmWTuydDqR oz2Rhkx51/ANUONy9Spk4UQf7w+1wfbE90IAs1UijTfUi/XHXgpDTGVU229Ph3CBLsq0 +Bg3NgX0qZnxNKLXVk2084IH9jZtZYHKDoNTvZ6zbSk3k0HPWW/ty1JdRlkQbO+2rUSB wV7HzfCaJrJn07iuQLaW54KRIy4t2FVQULfXUzOEFm8haaESP36PUc2CRNzXlU7FOOq5 J4SA== X-Received: by 10.180.85.162 with SMTP id i2mr16353609wiz.53.1406233634877; Thu, 24 Jul 2014 13:27:14 -0700 (PDT) Received: from dhcp-a22c.meeting.ietf.org ([2001:67c:370:160:e012:44d9:f97f:5ba9]) by mx.google.com with ESMTPSA id bx2sm18743153wjb.47.2014.07.24.13.27.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Jul 2014 13:27:14 -0700 (PDT) Message-ID: <53D16C1F.1030902@gmail.com> Date: Thu, 24 Jul 2014 16:27:11 -0400 From: Tim Wicinski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Thunderbird/32.0a2 MIME-Version: 1.0 To: Tom Pusateri , "Aggarwal, Ashutosh" References: <4ADFCA4A44B18946883BA96F64773E0150E2CF31@NASANEXD02B.na.qualcomm.com> <8242FDC4-4763-47B5-A205-E41C23A0367B@bangj.com> In-Reply-To: <8242FDC4-4763-47B5-A205-E41C23A0367B@bangj.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/_L1UuZLKY6E_xOMWQy-6RLi9oks Cc: "dnssd@ietf.org" , "Dave Thaler \(dthaler@microsoft.com\)" Subject: Re: [dnssd] draft-aggarwal-dnssd-optimize-query-00 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 20:27:27 -0000 Additionally, since TXT records are incredibly overloaded at this point in time that the creation of a TXT Registry draft was both useful and sad at the same time. tim On 7/24/14 4:21 PM, Tom Pusateri wrote: > >> On Jul 24, 2014, at 2:58 PM, Aggarwal, Ashutosh wrote: >> >> Thanks for your comments. Please see below: >> >> -----Original Message----- >> From: dnssd [mailto:dnssd-bounces@ietf.org] On Behalf Of Tom Pusateri >> Sent: Thursday, July 24, 2014 11:10 AM >> To: dnssd@ietf.org >> Subject: [dnssd] draft-aggarwal-dnssd-optimize-query-00 >> >> Ashutosh, >> Interesting draft. I have a few comments. >> >> 1. In section 3, you describe the TXT record filters in the additional section. But you don't exactly specify what is in the query section. Does this apply only for queries to instances of TXT records or does this also apply to PTR queries for instances of services or for PTR queries for just the service itself or all three? >> >> [Aggarwal, Ashutosh] >> This contribution was written to optimize the DNS-SD query scenario when the client application issues the PTR query with the service name. The contribution proposes to add DNS TXT records for such queries. >> > > Ok, but a TXT record is for an instance of a service. So your proposal is now changing what is expected in a TXT record. > > Let's clarify to be sure. You are suggesting this: > > ---------------------------------------- > Query Section: > > _printer._tcp.local. IN PTR > > Additional Records Section: > > _printer._tcp.local. IN TXT "color=True" > ---------------------------------------- > > An mDNS participant that isn't aware of your draft, would expect the TXT record in the AR Section to be an actual instance of a service. Something like this would be more expected: > > HP OfficeJet._printer._tcp.local. IN TXT "color=True" > > and the recipient wouldn't know what to do with > > _printer._tcp.local. IN TXT "color=True" > > since it is not an instance of a service. > > > Thanks, > Tom From nobody Thu Jul 24 16:47:38 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEA21A0648 for ; Thu, 24 Jul 2014 16:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 pvbdu6-445u2 for ; Thu, 24 Jul 2014 16:47:35 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 745BD1A0537 for ; Thu, 24 Jul 2014 16:47:34 -0700 (PDT) Received: from dhcp-8c7d.meeting.ietf.org (dhcp-8c7d.meeting.ietf.org [31.133.140.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id AC32F134B3; Thu, 24 Jul 2014 19:47:34 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1971.5\)) From: Tom Pusateri In-Reply-To: <7414908D-B2A9-4935-912F-EF3E4995065F@nominum.com> Date: Thu, 24 Jul 2014 19:47:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0696C085-C817-44F1-8CC1-2355A9704623@bangj.com> References: <331F9173-DB56-4D9A-B09F-956FF6D8DA2B@gmail.com> <1F1E6B22-5FF2-41DF-BA86-20A9D57E74CC@gmail.com> <7414908D-B2A9-4935-912F-EF3E4995065F@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1971.5) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/fJFHHx3-nCUvdvD7CmznrgYX9Gc Cc: dnssd@ietf.org, RJ Atkinson Subject: Re: [dnssd] multicast over wireless links X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 23:47:36 -0000 > On Jul 24, 2014, at 1:25 PM, Ted Lemon wrote: >=20 > Asking IEEE to fix WiFi is not really a good approach to addressing = the problem of inefficient multicast for existing deployments, and this = work is intended to address existing deployments. >=20 > Therefore, I think that if we want to address this use case, the right = way to do it is to come up with a mechanism for doing multicast = distribution of DNSSD updates on broadcast-friendly networks, and not to = just make this the default operational mode for DNSSD. >=20 Having spent a good portion of my career on IP multicast (from Token = Ring to IP Multicast VPNs), it baffles me how a radio can have such a = difficult time doing IP multicast. The 802.11 link layer clearly needs = improvement in this area. Access points regularly fall over dead when = bridging an ethernet wired connection to wireless when there is a high = data rate multicast stream (actually 4Mbps isn't that high). This is = just unacceptable. With most radios, multicast is the most efficient form of transmission. = But in 802.11, every receiver in range currently receives N copies of = the multicast to their antenna before throwing all of them but one away. = Surely, this can be improved. Multi-unicast over radio broadcast has to = be the least efficient mechanism to achieve this. With so many wireless devices now, streaming live sports events over = multicast should be ultra efficient but this isn't the case on 802.11. There is work to be done in the IEEE and I think that the PIM and MBONED = WGs would be pleased to see us open a dialog with IEEE to improve this = deficiency. Optimizing for a single link layer is a rathole that we should avoid if = you can take a step back and look at things from a long term = perspective. Coming up with an optimization or work-around for a single = link layer is fine as a short term solution. Tom From nobody Thu Jul 24 19:05:16 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9340A1A0ACF for ; Thu, 24 Jul 2014 19:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 NLeoS4bZyDa4 for ; Thu, 24 Jul 2014 19:05:03 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3511A0AC8 for ; Thu, 24 Jul 2014 19:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qce.qualcomm.com; i=@qce.qualcomm.com; q=dns/txt; s=qcdkim; t=1406253903; x=1437789903; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TUgqNkzLPHA5pP+7uo038zjVS37FXFUo0/IMLFprA+A=; b=vGHrhfBsYt5g6EMrSxP7vMqqUT19cFa6uc3+I+x8/gk717bFHpnjxFPl HA6Bo4khncK7tdz4oXVbr9zHzBiFdGO3K3nj3WX9I/LqPh3GqJ4WAPZ7G 5JOJ8YiI0lWYn445Eb02d4PotuqkGFKUlk6GLvfSTVRXzRXr5LHGGaH32 c=; X-IronPort-AV: E=McAfee;i="5600,1067,7509"; a="145282516" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by wolverine02.qualcomm.com with ESMTP; 24 Jul 2014 19:05:02 -0700 X-IronPort-AV: E=Sophos;i="5.01,727,1400050800"; d="scan'208";a="30190493" Received: from nasanexhc01.na.qualcomm.com ([10.46.57.53]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 24 Jul 2014 19:05:03 -0700 Received: from NASANEXD02B.na.qualcomm.com ([169.254.2.117]) by NASANEXHC01.na.qualcomm.com ([10.46.57.53]) with mapi id 14.03.0181.006; Thu, 24 Jul 2014 19:05:01 -0700 From: "Aggarwal, Ashutosh" To: Tom Pusateri Thread-Topic: [dnssd] draft-aggarwal-dnssd-optimize-query-00 Thread-Index: AQHPp2p5gpdN6b7aTkawAnlhIRp6sJuvjI7QgACTlwD//+b6wA== Date: Fri, 25 Jul 2014 02:05:00 +0000 Message-ID: <4ADFCA4A44B18946883BA96F64773E0150E2D6F7@NASANEXD02B.na.qualcomm.com> References: <4ADFCA4A44B18946883BA96F64773E0150E2CF31@NASANEXD02B.na.qualcomm.com> <8242FDC4-4763-47B5-A205-E41C23A0367B@bangj.com> In-Reply-To: <8242FDC4-4763-47B5-A205-E41C23A0367B@bangj.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/2_oCU1dtCZbJEd8ZYn2YugjPAIg Cc: "dnssd@ietf.org" , "Dave Thaler \(dthaler@microsoft.com\)" Subject: Re: [dnssd] draft-aggarwal-dnssd-optimize-query-00 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 02:05:10 -0000 Yes, your example below (between the dotted lines) captures what the draft = is proposing.=20 Btw, when you say the TXT record is for an instance of service that is cert= ainly true in the current DNS-SD scope when the service instance is populat= ing the TXT records in the response. At the time of query, querier only kno= ws about the service name and hence the TXT record in the additional sectio= n can only represent the service and not the service instance. With this ch= ange, there is implied behavior for the responders who choose to filter the= response based on the keys and they can process the TXT records as propose= d (that was my thinking).=20 Thanks, Ashutosh=20 -----Original Message----- From: Tom Pusateri [mailto:pusateri@bangj.com]=20 Sent: Thursday, July 24, 2014 1:21 PM To: Aggarwal, Ashutosh Cc: dnssd@ietf.org; Dave Thaler (dthaler@microsoft.com) Subject: Re: [dnssd] draft-aggarwal-dnssd-optimize-query-00 > On Jul 24, 2014, at 2:58 PM, Aggarwal, Ashutosh wrote: >=20 > Thanks for your comments. Please see below: >=20 > -----Original Message----- > From: dnssd [mailto:dnssd-bounces@ietf.org] On Behalf Of Tom Pusateri > Sent: Thursday, July 24, 2014 11:10 AM > To: dnssd@ietf.org > Subject: [dnssd] draft-aggarwal-dnssd-optimize-query-00 >=20 > Ashutosh, > Interesting draft. I have a few comments. >=20 > 1. In section 3, you describe the TXT record filters in the additional se= ction. But you don't exactly specify what is in the query section. Does thi= s apply only for queries to instances of TXT records or does this also appl= y to PTR queries for instances of services or for PTR queries for just the = service itself or all three? >=20 > [Aggarwal, Ashutosh]=20 > This contribution was written to optimize the DNS-SD query scenario when = the client application issues the PTR query with the service name. The cont= ribution proposes to add DNS TXT records for such queries.=20 >=20 Ok, but a TXT record is for an instance of a service. So your proposal is n= ow changing what is expected in a TXT record. Let's clarify to be sure. You are suggesting this: ---------------------------------------- Query Section: _printer._tcp.local. IN PTR Additional Records Section: _printer._tcp.local. IN TXT "color=3DTrue" ---------------------------------------- An mDNS participant that isn't aware of your draft, would expect the TXT re= cord in the AR Section to be an actual instance of a service. Something lik= e this would be more expected: HP OfficeJet._printer._tcp.local. IN TXT "color=3DTrue" and the recipient wouldn't know what to do with _printer._tcp.local. IN TXT "color=3DTrue" since it is not an instance of a service. Thanks, Tom > 2. There would seem to be a tradeoff in requesting too much or too little= . If you apply TXT filters and then don't get any responses, you will have = to query again with a broader filter. The optimal case will depend on the s= ervice you're looking for. In some cases you would have been better off wit= hout the filter. In other cases, knowing there is no match is useful too. E= ach application will have to make that tradeoff when it queries. > [Aggarwal, Ashutosh]=20 > You are absolutely correct regarding trade-offs. The pre-condition is tha= t the client application knows what constraints or filters it is looking to= apply and it should specify them in the initial query. It would be better = than querying for the service name and then establishing a connection with = each service instance for subsequent negotiation. If the client application= doesn't need to apply any filter, it can send the query with the service n= ame only. The decision regarding which keys/filters to apply is application= specific as you mention. Just like DNS-SD has the provision for the respon= der to add key/value pairs in the DNS response message, the contribution pr= oposes to enable the use of DNS TXT records in the PTR queries for the serv= ice name. >=20 > 3. With your implied logical operations of TXT attribute filters, things = could get confusing when there are multiple records queried at once. You sh= ould expand on section 3 to explain this after clarifying from question #1 = which record types are in the query section. It's perfectly legal to query = the PTR record for _printer._tcp.local and the TXT and SRV records for HP O= fficeJet._printer._tcp.local in the same query. Will the TXT record in the = additional records section have to be for an instance like HP OfficeJet._pr= inter._tcp.local or does it apply to the PTR query for _printer._tcp.local?= If the TXT record can be for a service and not a specific instance, this c= hanges who responds. > When there are multiple TXT records in the additional section, it gets mo= re confusing on how to apply the logical operations. >=20 > [Aggarwal, Ashutosh]=20 > [Aggarwal, Ashutosh]=20 > I added multiple TXT records details if we want to allow for complex filt= er criteria. I can add some examples to clarify for sure. We can discuss if= we can summarize the desired filter criteria using a single TXT record. Th= e filtering scheme was proposed for PTR query with the service name. >=20 > Hope this answers your comments, > Ashutosh >=20 >=20 > Thanks, > Tom > _______________________________________________ > 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 Fri Jul 25 00:21:30 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990841A00C2 for ; Fri, 25 Jul 2014 00:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 YbzVvB88SBFL for ; Fri, 25 Jul 2014 00:21:20 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A2DA1ABB2A for ; Fri, 25 Jul 2014 00:21:19 -0700 (PDT) Received: from mail2.sbs.de (localhost [127.0.0.1]) by david.siemens.de (8.14.3/8.14.3) with ESMTP id s6P7LHUS007831; Fri, 25 Jul 2014 09:21:17 +0200 Received: from DEFTHW99ERGMSX.ww902.siemens.net (defthw99ergmsx.ww902.siemens.net [139.22.70.132]) by mail2.sbs.de (8.14.3/8.14.3) with ESMTP id s6P7LGRA010576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jul 2014 09:21:16 +0200 Received: from DENBGAT9ER1MSX.ww902.siemens.net (139.22.70.87) by DEFTHW99ERGMSX.ww902.siemens.net (139.22.70.132) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 25 Jul 2014 09:21:16 +0200 Received: from DEFTHW99EK5MSX.ww902.siemens.net ([169.254.6.253]) by DENBGAT9ER1MSX.ww902.siemens.net ([139.22.70.87]) with mapi id 14.03.0195.001; Fri, 25 Jul 2014 09:21:16 +0200 From: "Albrecht, Harald" To: Michael Richardson Thread-Topic: [dnssd] Security through Obscurity Thread-Index: AQHPprfbeCMVdoWCv0+IRw2l+oT97JuuTemAgADDcoCAAAvegIAAIsuAgAAJowCAABzGgIAAEAEAgADpzzA= Date: Fri, 25 Jul 2014 07:21:15 +0000 Message-ID: References: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> <20E4ED19-12BD-45D4-B690-8629B552B23B@gmail.com> <0E0BC226-E68E-4BC2-99EA-AFF1AF96A5EC@ecs.soton.ac.uk> <8465FD60-84CD-41B3-BBE3-1BDB52DF0DDB@hp.com> <364AAF85-5FB4-4828-A5A4-11160E747BC9@gmail.com> <24377.1406225491@sandelman.ca> <3949.1406228928@sandelman.ca> In-Reply-To: <3949.1406228928@sandelman.ca> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.31] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/ZCHPgvEvjg8pk0IX-4n5VtrSjHQ Cc: "dnssd@ietf.org" Subject: Re: [dnssd] Security through Obscurity X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 07:21:27 -0000 > Von: dnssd [mailto:dnssd-bounces@ietf.org] Im Auftrag von Michael > Richardson > Gesendet: Donnerstag, 24. Juli 2014 21:09 > Cc: dnssd@ietf.org > Betreff: Re: [dnssd] Security through Obscurity >=20 > Three printers on the floor. > One is reporting it is broken, so broken that you can't do much more than= see > that it exists. > If the IP(v6) address is predictable, and related in some way to the EUI-= 64, > then you can find the right unit. > The printer has little privacy concerns, seldom visits internet cafes, an= d is > never found it airport lounges. In which form do the reporting come in? I would assume that these printers = have some labels sticking on them that identify them in a more human-friend= ly way? Or am I wrong here and missing something? I'm trying to figure out = how the reporting process and troubleshooting process will benefit from pre= -assigned static LLAs, but I have problems doing so. By the way -- my home printer has global IPv6 addresses (yes, it has two as= Deutsche Telekom assigns temporary PA prefixes). But it has a snuggly fire= wall in front of it so it is of no concern to me; this printer can't be rea= ched from the outside. These two additional GUAs don't eat up significantly= resources, so why do I need to bother? I'm using ULA and LLA internally, s= o that's what I'm caring about. The GUAs aren't bad in any way ... unless t= here is general suspicion that GUAs are bad in any case...? With best regards, Harald From nobody Fri Jul 25 05:51:16 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6531B27F3 for ; Fri, 25 Jul 2014 05:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham 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 gKbsx7ma0fc8 for ; Fri, 25 Jul 2014 05:51:12 -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 847471A0242 for ; Fri, 25 Jul 2014 05:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1406292671; x=2270206271; 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=TtLF+YPnb82rs8xLWvIYkqclT3JU3hL53YDL81KUiUY=; b=pDoFV86o7VkG073JzUC86RdY0lTPc45fTS/rECt7Ix/ThXGTfAFksVuNE9y+NPZR b6Km/WtJ/oL6GGbmHX5ufgKDrl++mSsVqTdmV+ca82+5hja8L/e/x8r/nKBW0auX +b3h90JjBFJI4pUMrGFGjrWwQ8hU40sCgCK4RBXBBs5AUOvkG9MoCnclW+IlbUhS IL5oK6SYyJA7sZIXX/HB5pMjmaWPDJi0oSOAsHqsRZ2cAUw83sOj8g1cRH8/fCuz QbHs+1989WZC5f2e/gkewS0Sn1PFjLmHL4Df8iI4ti0DWbodjMypvTvuoJ4DGzkg WTsHCaPQ7rT7cwKmGyMoog==; Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 06.12.32596.EB252D35; Fri, 25 Jul 2014 05:51:10 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay8.apple.com ([17.128.113.102]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N9900LY6QDAE5J0@local.mail-out.apple.com> for dnssd@ietf.org; Fri, 25 Jul 2014 05:51:10 -0700 (PDT) X-AuditID: 11973e15-f79d66d000007f54-d9-53d252becfa3 Received: from [17.153.48.127] (Unknown_Domain [17.153.48.127]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id C3.9A.11638.DB252D35; Fri, 25 Jul 2014 05:51:11 -0700 (PDT) From: Michael Sweet In-reply-to: Date: Fri, 25 Jul 2014 08:51:07 -0400 Message-id: <16D98342-BBF4-4EA1-A206-70D6053A7D57@apple.com> References: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> <20E4ED19-12BD-45D4-B690-8629B552B23B@gmail.com> <0E0BC226-E68E-4BC2-99EA-AFF1AF96A5EC@ecs.soton.ac.uk> <8465FD60-84CD-41B3-BBE3-1BDB52DF0DDB@hp.com> <364AAF85-5FB4-4828-A5A4-11160E747BC9@gmail.com> <24377.1406225491@sandelman.ca> <3949.1406228928@sandelman.ca> To: "Albrecht, Harald" X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUiON3OSHdf0KVgg0dTbCzeL53F6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKl3TzIWnBGs+Pf+HFsD4ya+LkZODgkBE4knS36zQdhiEhfu rQeyuTiEBGYySTSePcQMkuAVEJT4MfkeSxcjBwezgLzEwfOyIGFmAS2J749aWUBsIYFpTBJ7 J/jDzDy46T8jxJxeJolVx3rBioQF9CWWXtvODmKzCahJ/J7UxwpicwpESbz6MR+shkVAVaK7 v5EdYpePxJGb1hAn2EgsWn+fFWLmCRaJy4f3gd0mArRs2+UHLBCL5SU+fDjODmH3sUnMmVo0 gVF4FpIXZiG8MAvJCwsYmVcxCuUmZuboZuaZ6SUWFOSk6iXn525ihISw6A7GM6usDjEKcDAq 8fB21F8MFmJNLCuuzD3EKM3BoiTOey4cKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoExPTEs dRL/m6tnckWvXl5fb8d7xHHWxc8CrffNPjuvUtjVaPnqNmf/zhwlmVOVPOzTt+yKmK7v/2bp hekTsyQtjn9LkBEPlBHeearQ4B1/tHKZn+Sdu/O2HPh78+vmVF5r0/DaD+GXp7030mLW7GOf 3/fm4PGJh5TnVB5xCGzakjOZ59+clgtxSizFGYmGWsxFxYkAahJTKUICAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUiONOgXnd/0KVgg45DChbvl85itPh68g+7 xbyGy0wWR77FOrB4bD35g81jyZKfTB4tc/Ywe2w/OYkpgCWKyyYlNSezLLVI3y6BK2PJvDnM BROFKlq2zWdqYLzO18XIySEhYCJxcNN/RghbTOLCvfVsXYxcHEICvUwSi5ZcZgZJCAvoSyy9 tp0dxOYVMJBYsmsTWJxZQEvixr+XTCA2m4CaxO9JfawgNqdAhMTF/1PA4iwCqhLd/Y3sEPV+ Em1PGlghbG2JZQtfM0PMtJE4N2clO8TiHSwSeyfuAGsQAbpu2+UHLBDXyUt8+HCcfQIj/ywk d8xCcscsJHMXMDKvYhQoSs1JrLTQSywoyEnVS87P3cQICs6GwrQdjE3LrQ4xCnAwKvHwRphd ChZiTSwrrsw9xCjBwawkwpsUABTiTUmsrEotyo8vKs1JLT7EKM3BoiTOu6PuQrCQQHpiSWp2 ampBahFMlomDU6qBUWrtb5MnS0vE/YsmKs0s/PVe702Jrr8fh6fwYzfrY3nRD7K7gmzeXooR jA+cGa574csxJuEG3nuOd44YpQVv1vp0mu/rc/upoavlHvksn+lif1xzs+xb+1ThxU1lOTU7 4jUOlL8R2Lbm0uG94hfem71fHHQ6eBNnHqt1Z822SVabivf835F4TImlOCPRUIu5qDgRAE3g mXFKAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/weQHbUga-lFio42K-MUNvBdoiCQ Cc: "dnssd@ietf.org" , Michael Richardson Subject: Re: [dnssd] Security through Obscurity X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 12:51:14 -0000 FWIW, many recent (within the last 4 years or so) printers support IPP and an operation called "Identify-Printer" which makes the printer beep or flash to aid in identifying which printer you are talking to... But more generally most people don't have multiple (identical) printers, and most organizations stick a label on the printer with its name on the network... Crude but effective... :) On Jul 25, 2014, at 3:21 AM, Albrecht, Harald wrote: >> Von: dnssd [mailto:dnssd-bounces@ietf.org] Im Auftrag von Michael >> Richardson >> Gesendet: Donnerstag, 24. Juli 2014 21:09 >> Cc: dnssd@ietf.org >> Betreff: Re: [dnssd] Security through Obscurity >> >> Three printers on the floor. >> One is reporting it is broken, so broken that you can't do much more than see >> that it exists. >> If the IP(v6) address is predictable, and related in some way to the EUI-64, >> then you can find the right unit. >> The printer has little privacy concerns, seldom visits internet cafes, and is >> never found it airport lounges. > > In which form do the reporting come in? I would assume that these printers have some labels sticking on them that identify them in a more human-friendly way? Or am I wrong here and missing something? I'm trying to figure out how the reporting process and troubleshooting process will benefit from pre-assigned static LLAs, but I have problems doing so. > > By the way -- my home printer has global IPv6 addresses (yes, it has two as Deutsche Telekom assigns temporary PA prefixes). But it has a snuggly firewall in front of it so it is of no concern to me; this printer can't be reached from the outside. These two additional GUAs don't eat up significantly resources, so why do I need to bother? I'm using ULA and LLA internally, so that's what I'm caring about. The GUAs aren't bad in any way ... unless there is general suspicion that GUAs are bad in any case...? > > With best regards, > Harald > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair From nobody Fri Jul 25 06:01:35 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A821A010C for ; Fri, 25 Jul 2014 06:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 jonE4kM4cAG2 for ; Fri, 25 Jul 2014 06:01:25 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B181B2833 for ; Fri, 25 Jul 2014 06:01:25 -0700 (PDT) Received: from dhcp-a545.meeting.ietf.org (dhcp-a545.meeting.ietf.org [31.133.165.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id E33D213538; Fri, 25 Jul 2014 09:01:25 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1971.5\)) From: Tom Pusateri In-Reply-To: <4ADFCA4A44B18946883BA96F64773E0150E2D6F7@NASANEXD02B.na.qualcomm.com> Date: Fri, 25 Jul 2014 09:01:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4ADFCA4A44B18946883BA96F64773E0150E2CF31@NASANEXD02B.na.qualcomm.com> <8242FDC4-4763-47B5-A205-E41C23A0367B@bangj.com> <4ADFCA4A44B18946883BA96F64773E0150E2D6F7@NASANEXD02B.na.qualcomm.com> To: "Aggarwal, Ashutosh" X-Mailer: Apple Mail (2.1971.5) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/sVYOcHiHdDLHJWsbEjb2_O413LQ Cc: "dnssd@ietf.org" , "Dave Thaler \(dthaler@microsoft.com\)" Subject: Re: [dnssd] draft-aggarwal-dnssd-optimize-query-00 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 13:01:33 -0000 Ok, you should probably say in the draft that the TTL of the TXT record = in the AR section should be set to 0 so it won't be cached. Thanks, Tom > On Jul 24, 2014, at 10:05 PM, Aggarwal, Ashutosh = wrote: >=20 > Yes, your example below (between the dotted lines) captures what the = draft is proposing.=20 >=20 > Btw, when you say the TXT record is for an instance of service that is = certainly true in the current DNS-SD scope when the service instance is = populating the TXT records in the response. At the time of query, = querier only knows about the service name and hence the TXT record in = the additional section can only represent the service and not the = service instance. With this change, there is implied behavior for the = responders who choose to filter the response based on the keys and they = can process the TXT records as proposed (that was my thinking).=20 >=20 > Thanks, > Ashutosh=20 >=20 > -----Original Message----- > From: Tom Pusateri [mailto:pusateri@bangj.com]=20 > Sent: Thursday, July 24, 2014 1:21 PM > To: Aggarwal, Ashutosh > Cc: dnssd@ietf.org; Dave Thaler (dthaler@microsoft.com) > Subject: Re: [dnssd] draft-aggarwal-dnssd-optimize-query-00 >=20 >=20 >> On Jul 24, 2014, at 2:58 PM, Aggarwal, Ashutosh = wrote: >>=20 >> Thanks for your comments. Please see below: >>=20 >> -----Original Message----- >> From: dnssd [mailto:dnssd-bounces@ietf.org] On Behalf Of Tom Pusateri >> Sent: Thursday, July 24, 2014 11:10 AM >> To: dnssd@ietf.org >> Subject: [dnssd] draft-aggarwal-dnssd-optimize-query-00 >>=20 >> Ashutosh, >> Interesting draft. I have a few comments. >>=20 >> 1. In section 3, you describe the TXT record filters in the = additional section. But you don't exactly specify what is in the query = section. Does this apply only for queries to instances of TXT records or = does this also apply to PTR queries for instances of services or for PTR = queries for just the service itself or all three? >>=20 >> [Aggarwal, Ashutosh]=20 >> This contribution was written to optimize the DNS-SD query scenario = when the client application issues the PTR query with the service name. = The contribution proposes to add DNS TXT records for such queries.=20 >>=20 >=20 > Ok, but a TXT record is for an instance of a service. So your proposal = is now changing what is expected in a TXT record. >=20 > Let's clarify to be sure. You are suggesting this: >=20 > ---------------------------------------- > Query Section: >=20 > _printer._tcp.local. IN PTR >=20 > Additional Records Section: >=20 > _printer._tcp.local. IN TXT "color=3DTrue" > ---------------------------------------- >=20 > An mDNS participant that isn't aware of your draft, would expect the = TXT record in the AR Section to be an actual instance of a service. = Something like this would be more expected: >=20 > HP OfficeJet._printer._tcp.local. IN TXT "color=3DTrue" >=20 > and the recipient wouldn't know what to do with >=20 > _printer._tcp.local. IN TXT "color=3DTrue" >=20 > since it is not an instance of a service. >=20 >=20 > Thanks, > Tom >=20 >> 2. There would seem to be a tradeoff in requesting too much or too = little. If you apply TXT filters and then don't get any responses, you = will have to query again with a broader filter. The optimal case will = depend on the service you're looking for. In some cases you would have = been better off without the filter. In other cases, knowing there is no = match is useful too. Each application will have to make that tradeoff = when it queries. >> [Aggarwal, Ashutosh]=20 >> You are absolutely correct regarding trade-offs. The pre-condition is = that the client application knows what constraints or filters it is = looking to apply and it should specify them in the initial query. It = would be better than querying for the service name and then establishing = a connection with each service instance for subsequent negotiation. If = the client application doesn't need to apply any filter, it can send the = query with the service name only. The decision regarding which = keys/filters to apply is application specific as you mention. Just like = DNS-SD has the provision for the responder to add key/value pairs in the = DNS response message, the contribution proposes to enable the use of DNS = TXT records in the PTR queries for the service name. >>=20 >> 3. With your implied logical operations of TXT attribute filters, = things could get confusing when there are multiple records queried at = once. You should expand on section 3 to explain this after clarifying = from question #1 which record types are in the query section. It's = perfectly legal to query the PTR record for _printer._tcp.local and the = TXT and SRV records for HP OfficeJet._printer._tcp.local in the same = query. Will the TXT record in the additional records section have to be = for an instance like HP OfficeJet._printer._tcp.local or does it apply = to the PTR query for _printer._tcp.local? If the TXT record can be for a = service and not a specific instance, this changes who responds. >> When there are multiple TXT records in the additional section, it = gets more confusing on how to apply the logical operations. >>=20 >> [Aggarwal, Ashutosh]=20 >> [Aggarwal, Ashutosh]=20 >> I added multiple TXT records details if we want to allow for complex = filter criteria. I can add some examples to clarify for sure. We can = discuss if we can summarize the desired filter criteria using a single = TXT record. The filtering scheme was proposed for PTR query with the = service name. >>=20 >> Hope this answers your comments, >> Ashutosh >>=20 >>=20 >> Thanks, >> Tom >> _______________________________________________ >> 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 >=20 From nobody Fri Jul 25 06:15:57 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4E81B2869 for ; Fri, 25 Jul 2014 06:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=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 tcTR_HpBdxAN for ; Fri, 25 Jul 2014 06:15:49 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9AD1A028A for ; Fri, 25 Jul 2014 06:15:49 -0700 (PDT) Received: from mx1.yitter.info (dhcp-bcbc.meeting.ietf.org [31.133.188.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 9FA8F8A031 for ; Fri, 25 Jul 2014 13:15:38 +0000 (UTC) Date: Fri, 25 Jul 2014 09:15:34 -0400 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20140725131533.GA23528@mx1.yitter.info> References: <4ADFCA4A44B18946883BA96F64773E0150E2CF31@NASANEXD02B.na.qualcomm.com> <8242FDC4-4763-47B5-A205-E41C23A0367B@bangj.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8242FDC4-4763-47B5-A205-E41C23A0367B@bangj.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/yVKCnST0WbCwNQ8-t7x2dGHgGSA Subject: Re: [dnssd] draft-aggarwal-dnssd-optimize-query-00 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 13:15:55 -0000 On Thu, Jul 24, 2014 at 04:21:14PM -0400, Tom Pusateri wrote: > > _printer._tcp.local. IN TXT "color=True" > ---------------------------------------- > > An mDNS participant that isn't aware of your draft, would expect the TXT record in the AR Section to be an actual instance of a service. Something like this would be more expected: > Just to be perfectly clear, an mDNS participant that isn't aware of the draft isn't anyway allowed to have a theory of what might appear in a TXT record. This is the problem with overloading TXT records. You're just not allowed to make assumptions about what might appear there, underscore labels or not, because the DNS permits approximately anything at all in the RDATA of a TXT record and mDNS follows the semantics of DNS RRTYPEs. So any implementation _has to_ be able to cope with these records it isn't expecting, or it is already broken. But I agree that it's not ideal to overload the underscore-labelled TXT record if one can avoid it. Given the goal in the draft, however, I don't think it can be avoided. Just to be clear, I think it is clear that this is an mDNS-only trick: given DNSSEC, you can't do anything with the DNS. (I worry also about caches in the DNS and these additional records, if you did filtering. That's another reason not to do this in DNS.) Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Jul 25 08:06:47 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2721A0314 for ; Fri, 25 Jul 2014 08:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 uthOaCqg_K1i for ; Fri, 25 Jul 2014 08:06:33 -0700 (PDT) Received: from g4t3425.houston.hp.com (g4t3425.houston.hp.com [15.201.208.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DA771A033A for ; Fri, 25 Jul 2014 08:06:33 -0700 (PDT) Received: from G9W0364.americas.hpqcorp.net (g9w0364.houston.hp.com [16.216.193.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t3425.houston.hp.com (Postfix) with ESMTPS id 8339C277; Fri, 25 Jul 2014 15:06:32 +0000 (UTC) Received: from G4W6304.americas.hpqcorp.net (16.210.26.229) by G9W0364.americas.hpqcorp.net (16.216.193.45) with Microsoft SMTP Server (TLS) id 14.3.169.1; Fri, 25 Jul 2014 15:05:45 +0000 Received: from G4W3298.americas.hpqcorp.net ([169.254.4.87]) by G4W6304.americas.hpqcorp.net ([16.210.26.229]) with mapi id 14.03.0169.001; Fri, 25 Jul 2014 15:05:45 +0000 From: "Kennedy, Smith (Wireless Architect)" To: "Albrecht, Harald" Thread-Topic: [dnssd] Security through Obscurity Thread-Index: AQHPprfZeGKEsBCMn020p8uMqL4n0Juub3CAgADDcoCAAAvegIAAIsoAgAAJpACAABzGgIAAEAEAgADMpYCAAIHGAA== Date: Fri, 25 Jul 2014 15:05:44 +0000 Message-ID: <4CCB4658-8B54-460B-AC4B-8230EEEF54CA@hp.com> References: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> <20E4ED19-12BD-45D4-B690-8629B552B23B@gmail.com> <0E0BC226-E68E-4BC2-99EA-AFF1AF96A5EC@ecs.soton.ac.uk> <8465FD60-84CD-41B3-BBE3-1BDB52DF0DDB@hp.com> <364AAF85-5FB4-4828-A5A4-11160E747BC9@gmail.com> <24377.1406225491@sandelman.ca> <3949.1406228928@sandelman.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [15.201.58.18] Content-Type: multipart/signed; boundary="Apple-Mail=_70FBEF0B-A5D9-45C1-A208-D718EA82FDB0"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/X8zsXw6zOfOr2McCt3tj9WK7ytg Cc: "dnssd@ietf.org" , Michael Richardson Subject: Re: [dnssd] Security through Obscurity X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 15:06:38 -0000 --Apple-Mail=_70FBEF0B-A5D9-45C1-A208-D718EA82FDB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I=92m struggling to see how this is a practical example that justifies = pre-assigned / predictable IPv6 addresses. My primary worry is that this will give people a pseudo-legitimate = rationale to continue their tragic antiquated habit of using raw network = addresses for things like printer queue creation, which is still all too = prevalent today. Smith On 2014-07-25, at 1:21 AM, Albrecht, Harald = wrote: >> Von: dnssd [mailto:dnssd-bounces@ietf.org] Im Auftrag von Michael >> Richardson >> Gesendet: Donnerstag, 24. Juli 2014 21:09 >> Cc: dnssd@ietf.org >> Betreff: Re: [dnssd] Security through Obscurity >>=20 >> Three printers on the floor. >> One is reporting it is broken, so broken that you can't do much more = than see >> that it exists. >> If the IP(v6) address is predictable, and related in some way to the = EUI-64, >> then you can find the right unit. >> The printer has little privacy concerns, seldom visits internet = cafes, and is >> never found it airport lounges. >=20 > In which form do the reporting come in? I would assume that these = printers have some labels sticking on them that identify them in a more = human-friendly way? Or am I wrong here and missing something? I'm trying = to figure out how the reporting process and troubleshooting process will = benefit from pre-assigned static LLAs, but I have problems doing so. >=20 > By the way -- my home printer has global IPv6 addresses (yes, it has = two as Deutsche Telekom assigns temporary PA prefixes). But it has a = snuggly firewall in front of it so it is of no concern to me; this = printer can't be reached from the outside. These two additional GUAs = don't eat up significantly resources, so why do I need to bother? I'm = using ULA and LLA internally, so that's what I'm caring about. The GUAs = aren't bad in any way ... unless there is general suspicion that GUAs = are bad in any case...? >=20 > With best regards, > Harald >=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_70FBEF0B-A5D9-45C1-A208-D718EA82FDB0 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOQDCCBmEw ggVJoAMCAQICEFHz5uyygZHVFZ4pmbCHOnswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDkwMjAwMDAwMFoXDTE0MDkwMTIzNTk1OVowgfcxCzAJ BgNVBAYTAlVTMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBMTEwLwYDVQQDEyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRp b24gQXV0aG9yaXR5IEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp2FraNquqoVk DEvLUMsw6HMhjon+yi1v/kajA27jIrdyhRMj4g+PBveBTHrtA7w97Rx1UKPP6CvOaAE5xUtoW9aj YZtO5kdiUFyzWHsbUgSjKy+yNO4QoHeEzaQi/JWUOYev/AV5YYJoEDIysosEELS1/M64iE2Utzr+ LxiWhdaqSRE4jigbm4Dy4ayLzqAv5f7oILrJNZ6ShqLiGGCpP+7relTyRgFXmEX/SKN/a39JwZoK SNUdIkYyr7wmNI9+zylheDJghuk+kZDAD3NXv4EGVMUfOg5UEdhAJ0Lw40D4pqKa2ej1H0UipK1E EdRTm94RzfE8z8vDP8+dcgOqCwIDAQABo4ICEjCCAg4wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNV HSAEaTBnMGUGC2CGSAGG+EUBBxcCMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWdu LmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNV HR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWczLmNybDAOBgNVHQ8B Af8EBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0OC0xNDIw HQYDVR0OBBYEFCJ906SrV6xWf6l/QUQalbxb+KvuMIHwBgNVHSMEgegwgeWhgdCkgc0wgcoxCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9y aXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEB BQUAA4IBAQAvUbxneMj/3SU5WlUKapv9ZGIeeNSf6/t6gKUUsCT2A1KQMlZmK7/gn4ndrXWdch7U afl6WkPlBcunYRGvJ6YkJCP4uV86Lwv68mK6REwJFMiKHy/qFnRaoI+pLfaIlMQ9l7Q2DRnNLSyC Bl9b02PaGzX+XQQxGhLiE89Z1E+ajicWG1zRzBUbPx46ptQUjfjYPNyP4cLWT5rJ7olc9/mRyfIO 4nGU8lRjGcuKwxZhOP+TftJgd/fRYf68Kf2Bkue4cdrI2UUgYD02GBL/S8E8FBsOrAoJ5N6cEYac wT2BZgHzYrxTC5ZyxzY9TWtGldxEH/moJ5OLtF+KauJWhaACMIIH1zCCBr+gAwIBAgIQPOXfUUI6 ovNsyP+l8ouxZTANBgkqhkiG9w0BAQUFADCB9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xl dHQtUGFja2FyZCBDb21wYW55MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1 MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAv BgNVBAMTKENvbGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIwHhcNMTIxMTI2 MDAwMDAwWhcNMTQxMTI2MjM1OTU5WjCBmDEgMB4GA1UEChQXSGV3bGV0dC1QYWNrYXJkIENvbXBh bnkxJjAkBgNVBAsUHUVtcGxveW1lbnQgU3RhdHVzIC0gRW1wbG95ZWVzMQ8wDQYDVQQLEwZTL01J TUUxFjAUBgNVBAMTDVNtaXRoIEtlbm5lZHkxIzAhBgkqhkiG9w0BCQEWFHNtaXRoLmtlbm5lZHlA aHAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuageabAIyTS0JIjXDq1iml4l fdgg3AULnBQiEK3wdxFb8Cyz2fsHE/UykFRJyZilpA6MUj6fom56o02WYfKxb3AUbwWJLGjAB/YL pw36SatXUw7OmuumNllMH3v2WpEP9QblEKjgE3LdpNO2owWTsmSsvVAfzItrkg6BR3fo3tsrf6dL PpbdfeOjkbwRrHnEm/AKKg5DPOZyVEqmgNEoVPflsem1QIPRVHshjvj0iTv4DhEGnnbDvMpiuzo3 n0fLQ/HETM6xAiZQLv76aFEm2DkB1fvnAApvrrm/dvhFmMkExCGNh1TwCXd7+KrfradSomasVs2G kz0tJqmOlsKbsQIDAQABo4IDujCCA7YwHwYDVR0RBBgwFoEUc21pdGgua2VubmVkeUBocC5jb20w DAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29u c2l0ZWNybC52ZXJpc2lnbi5jb20vSGV3bGV0dFBhY2thcmRDb21wYW55U01JTUVHMi9MYXRlc3RD UkwuY3JsMB8GA1UdIwQYMBaAFCJ906SrV6xWf6l/QUQalbxb+KvuMB0GA1UdDgQWBBTa6BzKTU+H dS93ruL/3n7ZMTXvgjCCATIGCCsGAQUFBwEBBIIBJDCCASAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9o cC1vY3NwLnZlcmlzaWduLmNvbTCB9AYIKwYBBQUHMAKkgecwgeQxMTAvBgNVBAMTKENvbGxhYm9y YXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIxMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRl IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTE6MDgGA1UECxMxVGVybXMgb2YgdXNlIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEoYykwOTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkwggE9BgNVHSAEggE0MIIBMDCC ASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYTCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1 dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJlc3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vz c2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQgdG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0 aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29ycC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0 ZC4gKGMpOTcgVmVyaVNpZ24wFgYDVR0lAQH/BAwwCgYIKwYBBQUHAwQwSwYJKoZIhvcNAQkPBD4w PDAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwICAgBAMA4GCCqGSIb3DQMEAgIAgDAKBggqhkiG 9w0DBzANBgkqhkiG9w0BAQUFAAOCAQEAibIOTCm5SdtOxug7ClAA9DgzWNtmR9ZL+YujqiPpc5YC mr0hDWOTCjAJbDAIDcXfAJspAamEnwd0tpUZj0DOc4RCiLEsfH2uchNqr2UV5qAJmKq0Wrr+Lfd6 1ZFvp1encVlif2KSFi/vgTCKX+57rVWpb284BmrnVa30nOcuZVKQk3XUDignE0vz+OIrza1JcyRQ d7TtVtlRQX63rT0P3v2u9UrryzDo/5wN77jqDLqgz0se0g23wVyWuj/jmFB7QV1bUDV2bLHh3Ipb 9JtEri7DlzSde9pmfRauWerZHGb/AI0qcbEC2nSKvv/u5tHoaMHfG58GM0unnsmBu4UiDjGCBN4w ggTaAgEBMIIBDDCB9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21w YW55MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xhc3Mg MiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENvbGxhYm9y YXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzICEDzl31FCOqLzbMj/pfKLsWUwCQYFKw4D AhoFAKCCAqUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwNzI1 MTUwNTQ1WjAjBgkqhkiG9w0BCQQxFgQUWTPv6tey/dQPVeAF+Gw77GRu3z4wggEfBgkrBgEEAYI3 EAQxggEQMIIBDDCB9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21w YW55MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xhc3Mg MiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENvbGxhYm9y YXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzICEDzl31FCOqLzbMj/pfKLsWUwggEhBgsq hkiG9w0BCRACCzGCARCgggEMMIH3MQswCQYDVQQGEwJVUzEgMB4GA1UEChMXSGV3bGV0dC1QYWNr YXJkIENvbXBhbnkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRl cm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MTUwMwYDVQQL EyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTExMC8GA1UEAxMo Q29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBHMgIQPOXfUUI6ovNsyP+l8oux ZTANBgkqhkiG9w0BAQEFAASCAQBne7sgoBC89pu+lZ+K/2JQga5ReBr6SE5nvOPjHPctmR838cEk Q6pFmDJBFpQzUaczT+POLxldy5o9h5tsk67ruMkQX3Jv58K3ce0xZHdp2TUe3YGYkn/xZdiU6kuO mx2XEVrY6LtjfT176BAgWMRm62GycsWPwnZuAtTMVFGv1raUp3gbU6d6PLnSkHnafwLoGh9vnTGb c2HAsIAzPAqUrlot9XkNfMf5r59FThHa5D6AOuGZ/eFqqtGUf36PcRIiZ2oC4lupfHh1emd6mj7Q 45dxbhc6wo6ZcJ8u9lQ2DB/SROw4DeMA0enw6arwdDBK9IlQrlw4IC26wiISiNQMAAAAAAAA --Apple-Mail=_70FBEF0B-A5D9-45C1-A208-D718EA82FDB0-- From nobody Fri Jul 25 16:37:18 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3AC1A04CA for ; Fri, 25 Jul 2014 16:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 7yg1NgPDnHO3 for ; Fri, 25 Jul 2014 16:37:14 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4567B1A04B7 for ; Fri, 25 Jul 2014 16:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qce.qualcomm.com; i=@qce.qualcomm.com; q=dns/txt; s=qcdkim; t=1406331434; x=1437867434; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CxNzrCyWy5lRazkdX7j5a5CbOqS1kERwuPh+qTD2yzE=; b=xdVdkgAUvo4drCO+clH4oLKqvxZYjlBc777eD1JdhqaGlRa+02YqkrBH LKPvD3CX3LnhV3LsUQrAhHkWzYb4Ry4ZKArCPr4ssVRUyzCKELNlSOWWN beVExSOCCdOK7mfKVU1RaHuseMtTbIGqyI00zaLCNyM1i871OFW/AemdX w=; X-IronPort-AV: E=McAfee;i="5600,1067,7510"; a="54063189" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 25 Jul 2014 16:37:13 -0700 X-IronPort-AV: E=Sophos;i="5.01,733,1400050800"; d="scan'208";a="705549683" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 25 Jul 2014 16:37:13 -0700 Received: from NASANEXD02B.na.qualcomm.com ([169.254.2.117]) by nasanexhc08.na.qualcomm.com ([172.30.39.7]) with mapi id 14.03.0181.006; Fri, 25 Jul 2014 16:37:13 -0700 From: "Aggarwal, Ashutosh" To: Tom Pusateri Thread-Topic: [dnssd] draft-aggarwal-dnssd-optimize-query-00 Thread-Index: AQHPp2p5gpdN6b7aTkawAnlhIRp6sJuvjI7QgACTlwD//+b6wIABMHaAgAA8BFA= Date: Fri, 25 Jul 2014 23:37:12 +0000 Message-ID: <4ADFCA4A44B18946883BA96F64773E0150E2E755@NASANEXD02B.na.qualcomm.com> References: <4ADFCA4A44B18946883BA96F64773E0150E2CF31@NASANEXD02B.na.qualcomm.com> <8242FDC4-4763-47B5-A205-E41C23A0367B@bangj.com> <4ADFCA4A44B18946883BA96F64773E0150E2D6F7@NASANEXD02B.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/lGFCHk7OgOXj8dKj_E8dCiNWpW4 Cc: "dnssd@ietf.org" , "Dave Thaler \(dthaler@microsoft.com\)" Subject: Re: [dnssd] draft-aggarwal-dnssd-optimize-query-00 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 23:37:17 -0000 Sure, I will reflect that in the next set of updates. Thanks, Ashutosh -----Original Message----- From: Tom Pusateri [mailto:pusateri@bangj.com]=20 Sent: Friday, July 25, 2014 6:01 AM To: Aggarwal, Ashutosh Cc: dnssd@ietf.org; Dave Thaler (dthaler@microsoft.com) Subject: Re: [dnssd] draft-aggarwal-dnssd-optimize-query-00 Ok, you should probably say in the draft that the TTL of the TXT record in = the AR section should be set to 0 so it won't be cached. Thanks, Tom > On Jul 24, 2014, at 10:05 PM, Aggarwal, Ashutosh wrote: >=20 > Yes, your example below (between the dotted lines) captures what the draf= t is proposing.=20 >=20 > Btw, when you say the TXT record is for an instance of service that is ce= rtainly true in the current DNS-SD scope when the service instance is popul= ating the TXT records in the response. At the time of query, querier only k= nows about the service name and hence the TXT record in the additional sect= ion can only represent the service and not the service instance. With this = change, there is implied behavior for the responders who choose to filter t= he response based on the keys and they can process the TXT records as propo= sed (that was my thinking).=20 >=20 > Thanks, > Ashutosh=20 >=20 > -----Original Message----- > From: Tom Pusateri [mailto:pusateri@bangj.com]=20 > Sent: Thursday, July 24, 2014 1:21 PM > To: Aggarwal, Ashutosh > Cc: dnssd@ietf.org; Dave Thaler (dthaler@microsoft.com) > Subject: Re: [dnssd] draft-aggarwal-dnssd-optimize-query-00 >=20 >=20 >> On Jul 24, 2014, at 2:58 PM, Aggarwal, Ashutosh wrote: >>=20 >> Thanks for your comments. Please see below: >>=20 >> -----Original Message----- >> From: dnssd [mailto:dnssd-bounces@ietf.org] On Behalf Of Tom Pusateri >> Sent: Thursday, July 24, 2014 11:10 AM >> To: dnssd@ietf.org >> Subject: [dnssd] draft-aggarwal-dnssd-optimize-query-00 >>=20 >> Ashutosh, >> Interesting draft. I have a few comments. >>=20 >> 1. In section 3, you describe the TXT record filters in the additional s= ection. But you don't exactly specify what is in the query section. Does th= is apply only for queries to instances of TXT records or does this also app= ly to PTR queries for instances of services or for PTR queries for just the= service itself or all three? >>=20 >> [Aggarwal, Ashutosh]=20 >> This contribution was written to optimize the DNS-SD query scenario when= the client application issues the PTR query with the service name. The con= tribution proposes to add DNS TXT records for such queries.=20 >>=20 >=20 > Ok, but a TXT record is for an instance of a service. So your proposal is= now changing what is expected in a TXT record. >=20 > Let's clarify to be sure. You are suggesting this: >=20 > ---------------------------------------- > Query Section: >=20 > _printer._tcp.local. IN PTR >=20 > Additional Records Section: >=20 > _printer._tcp.local. IN TXT "color=3DTrue" > ---------------------------------------- >=20 > An mDNS participant that isn't aware of your draft, would expect the TXT = record in the AR Section to be an actual instance of a service. Something l= ike this would be more expected: >=20 > HP OfficeJet._printer._tcp.local. IN TXT "color=3DTrue" >=20 > and the recipient wouldn't know what to do with >=20 > _printer._tcp.local. IN TXT "color=3DTrue" >=20 > since it is not an instance of a service. >=20 >=20 > Thanks, > Tom >=20 >> 2. There would seem to be a tradeoff in requesting too much or too littl= e. If you apply TXT filters and then don't get any responses, you will have= to query again with a broader filter. The optimal case will depend on the = service you're looking for. In some cases you would have been better off wi= thout the filter. In other cases, knowing there is no match is useful too. = Each application will have to make that tradeoff when it queries. >> [Aggarwal, Ashutosh]=20 >> You are absolutely correct regarding trade-offs. The pre-condition is th= at the client application knows what constraints or filters it is looking t= o apply and it should specify them in the initial query. It would be better= than querying for the service name and then establishing a connection with= each service instance for subsequent negotiation. If the client applicatio= n doesn't need to apply any filter, it can send the query with the service = name only. The decision regarding which keys/filters to apply is applicatio= n specific as you mention. Just like DNS-SD has the provision for the respo= nder to add key/value pairs in the DNS response message, the contribution p= roposes to enable the use of DNS TXT records in the PTR queries for the ser= vice name. >>=20 >> 3. With your implied logical operations of TXT attribute filters, things= could get confusing when there are multiple records queried at once. You s= hould expand on section 3 to explain this after clarifying from question #1= which record types are in the query section. It's perfectly legal to query= the PTR record for _printer._tcp.local and the TXT and SRV records for HP = OfficeJet._printer._tcp.local in the same query. Will the TXT record in the= additional records section have to be for an instance like HP OfficeJet._p= rinter._tcp.local or does it apply to the PTR query for _printer._tcp.local= ? If the TXT record can be for a service and not a specific instance, this = changes who responds. >> When there are multiple TXT records in the additional section, it gets m= ore confusing on how to apply the logical operations. >>=20 >> [Aggarwal, Ashutosh]=20 >> [Aggarwal, Ashutosh]=20 >> I added multiple TXT records details if we want to allow for complex fil= ter criteria. I can add some examples to clarify for sure. We can discuss i= f we can summarize the desired filter criteria using a single TXT record. T= he filtering scheme was proposed for PTR query with the service name. >>=20 >> Hope this answers your comments, >> Ashutosh >>=20 >>=20 >> Thanks, >> Tom >> _______________________________________________ >> 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 >=20 From nobody Mon Jul 28 17:02:30 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17CD1A03A2 for ; Mon, 28 Jul 2014 17:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 YmHs_V1p98kL for ; Mon, 28 Jul 2014 17:02:26 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FEE61A0298 for ; Mon, 28 Jul 2014 17:02:26 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id hz1so11298008pad.22 for ; Mon, 28 Jul 2014 17:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lJC60rwGcOuvb/pictQseVZU2IhRT19vo3WatMbT2kk=; b=qcPMByF4IoRTpgZ/XhFSf/kF2/qp+ln0sbwZXMmZoPHsBlsNUy3lpscs39Tih5Z4Fu yj/rJxRL9gKd2G3pJ+1dC61XtmTPxEaSMfH4lQKlQKsWeY4PcIdtbImNoGXDi5KKJS9c uP+WRp8lTDq+zO7ARpByEdUQH7A7nMIZ8burmflVQd+SsRZfqaSh6pnh2p2ek3OUqsEO oUtc70IRiWo1IzfFQgqGTv9TmN5Zm+FsFN9pG9qZhfHT7lhRw4Of9XGptbZecuvtViOg L+Mlg4smOhv69J2liVmDhpP9INQ7QvSWSlkun/RVTD9CrohV2b+W1/HwYIitLhIoemy2 bF4Q== X-Received: by 10.68.245.100 with SMTP id xn4mr6344896pbc.152.1406592145900; Mon, 28 Jul 2014 17:02:25 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id ph6sm18873169pbc.38.2014.07.28.17.02.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 17:02:25 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: <4CCB4658-8B54-460B-AC4B-8230EEEF54CA@hp.com> Date: Mon, 28 Jul 2014 17:02:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> <20E4ED19-12BD-45D4-B690-8629B552B23B@gmail.com> <0E0BC226-E68E-4BC2-99EA-AFF1AF96A5EC@ecs.soton.ac.uk> <8465FD60-84CD-41B3-BBE3-1BDB52DF0DDB@hp.com> <364AAF85-5FB4-4828-A5A4-11160E747BC9@gmail.com> <24377.1406225491@sandelman.ca> <3949.1406228928@sandelman.ca> <4CCB4658-8B54-460B-AC4B-8230EEEF54CA@hp.com> To: "Kennedy, Smith (Wireless Architect)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/vxgq4GnyyRfPbzk7GjO73mycZqQ Cc: "dnssd@ietf.org" , "Albrecht, Harald" , Douglas Otis , Michael Richardson Subject: Re: [dnssd] Security through Obscurity X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jul 2014 00:02:29 -0000 On Jul 25, 2014, at 8:05 AM, Kennedy, Smith (Wireless Architect) = wrote: > I=92m struggling to see how this is a practical example that justifies = pre-assigned / predictable IPv6 addresses. >=20 > My primary worry is that this will give people a pseudo-legitimate = rationale to continue their tragic antiquated habit of using raw network = addresses for things like printer queue creation, which is still all too = prevalent today. Dear Smith, Agreed. For example, most printers do not offer user specific security = measures for their basic operation. Such user specific secure printing = is normally done indirectly by accessing shared OS resources offered by = a server able to establish TLS connections. The indirectly accessed = devices do not themselves authenticate for scanning, printing, or faxing = in most cases. This means publishing their IPv6 public addresses will = invite abuse. This is only one example of devices never intended to be = directly accessible on the Internet, and which may be subject to abuse = when DNS-SD is used indiscriminately. This has become a bit muddled, since DNS-SD offers predictable domain = assignments conveying IP addresses. Unless a device is able to = authenticate Internet originating sessions, it should not be published = in DNS having directly accessible IP addresses. It=92s not a matter of = using raw IP addresses - regardless how the address is characterized - = it=92s a matter of not allowing globally _reachable_ addresses to be = published for such devices. IPv6 firewalls in todays routers are unable = to cope with filtering ranges of IPv6 addresses, and devices expected to = only connect to a local network will likely have no means of protecting = themselves from the large-I Internet. Insecurely assigned prefixes and randomly assigned Interface-IDs never = being publicly published still offers weak security. Multiple = off-the-shelf home routers should be expected to use dynamically = assigned prefixes, since some insist dynamic prefix assignment improves = privacy. (Some providers bind prefix assignments with the MACs used by = the modem where any MAC change necessitates an approval process.) = Without use of ULA overlay addressing in such a home network, firewalls = will remain susceptible when unable to recognize internal IP addresses, = and hence unable to block externally initiated sessions. On the other hand, enterprise networks likely have statically assigned = prefixes. While static assignment or known router prefix assignment = information allows greater use of GUA addressing, exploits may still = defeat stateful src/dst firewall protections. Use of tunneling or VPNs = into ULA space still provides greater security. Those who find using = ULAs within an Enterprise environment difficult are also likely ill = equipped at setting up overlays. This inability likely means = renumbering will be more difficult as well when a prefix nevertheless = changes. Regards, Douglas Otis > On 2014-07-25, at 1:21 AM, Albrecht, Harald = wrote: >=20 >>> Von: dnssd [mailto:dnssd-bounces@ietf.org] Im Auftrag von Michael >>> Richardson >>> Gesendet: Donnerstag, 24. Juli 2014 21:09 >>> Cc: dnssd@ietf.org >>> Betreff: Re: [dnssd] Security through Obscurity >>>=20 >>> Three printers on the floor. >>> One is reporting it is broken, so broken that you can't do much more = than see >>> that it exists. >>> If the IP(v6) address is predictable, and related in some way to the = EUI-64, >>> then you can find the right unit. >>> The printer has little privacy concerns, seldom visits internet = cafes, and is >>> never found it airport lounges. >>=20 >> In which form do the reporting come in? I would assume that these = printers have some labels sticking on them that identify them in a more = human-friendly way? Or am I wrong here and missing something? I'm trying = to figure out how the reporting process and troubleshooting process will = benefit from pre-assigned static LLAs, but I have problems doing so. >>=20 >> By the way -- my home printer has global IPv6 addresses (yes, it has = two as Deutsche Telekom assigns temporary PA prefixes). But it has a = snuggly firewall in front of it so it is of no concern to me; this = printer can't be reached from the outside. These two additional GUAs = don't eat up significantly resources, so why do I need to bother? I'm = using ULA and LLA internally, so that's what I'm caring about. The GUAs = aren't bad in any way ... unless there is general suspicion that GUAs = are bad in any case...? >>=20 >> With best regards, >> Harald >>=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 Tue Jul 29 00:26:23 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76881AD6B0 for ; Tue, 29 Jul 2014 00:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 ig3VUJeL4r0g for ; Tue, 29 Jul 2014 00:26:19 -0700 (PDT) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC1A31AD62C for ; Tue, 29 Jul 2014 00:26:18 -0700 (PDT) Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.14.3/8.14.3) with ESMTP id s6T7QDKE013025; Tue, 29 Jul 2014 09:26:13 +0200 Received: from DEFTHW99ERMMSX.ww902.siemens.net (defthw99ermmsx.ww902.siemens.net [139.22.70.142]) by mail1.sbs.de (8.14.3/8.14.3) with ESMTP id s6T7QDFj009939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 09:26:13 +0200 Received: from DEFTHW99EK5MSX.ww902.siemens.net ([169.254.6.83]) by DEFTHW99ERMMSX.ww902.siemens.net ([139.22.70.142]) with mapi id 14.03.0195.001; Tue, 29 Jul 2014 09:26:12 +0200 From: "Albrecht, Harald" To: Douglas Otis , "Kennedy, Smith (Wireless Architect)" Thread-Topic: [dnssd] Security through Obscurity Thread-Index: AQHPprfbeCMVdoWCv0+IRw2l+oT97JuuTemAgADDcoCAAAvegIAAIsuAgAAJowCAABzGgIAAEAEAgADpzzCAAGScAIAFTO+AgACYA1A= Date: Tue, 29 Jul 2014 07:26:12 +0000 Message-ID: References: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> <20E4ED19-12BD-45D4-B690-8629B552B23B@gmail.com> <0E0BC226-E68E-4BC2-99EA-AFF1AF96A5EC@ecs.soton.ac.uk> <8465FD60-84CD-41B3-BBE3-1BDB52DF0DDB@hp.com> <364AAF85-5FB4-4828-A5A4-11160E747BC9@gmail.com> <24377.1406225491@sandelman.ca> <3949.1406228928@sandelman.ca> <4CCB4658-8B54-460B-AC4B-8230EEEF54CA@hp.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.31] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/iNSRt8A1P8TZVXYbK1flZOVZYg8 Cc: "dnssd@ietf.org" , Michael Richardson Subject: Re: [dnssd] Security through Obscurity X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jul 2014 07:26:21 -0000 Hello, could it be, per chance, that there are different views on what "publishing= " a device's IP address to DNS means? Maybe about what to publish where? I have problems understanding what publishing a devices " IPv6 public addre= ss" (cit) really means? I have learnt that there are GUAs, ULA, LLAs, but w= hat are public addresses? One could argue that publishing an address in its= elf constitutes public addresses, but that's most probably not helping eith= er. I don't see that publishing an address also automatically constitute it= s accessibility. To me, a RR dictionary does not constitute security either= . If it would, then something would be severely broken. > -----Urspr=FCngliche Nachricht----- > Von: Douglas Otis [mailto:doug.mtview@gmail.com] > Gesendet: Dienstag, 29. Juli 2014 02:02 > An: Kennedy, Smith (Wireless Architect) > Cc: Douglas Otis; Albrecht, Harald; dnssd@ietf.org; Michael Richardson > Betreff: Re: [dnssd] Security through Obscurity >=20 > Agreed. For example, most printers do not offer user specific security > measures for their basic operation. Such user specific secure printing i= s > normally done indirectly by accessing shared OS resources offered by a > server able to establish TLS connections. The indirectly accessed device= s do > not themselves authenticate for scanning, printing, or faxing in most cas= es. > This means publishing their IPv6 public addresses will invite abuse. Are you talking about abuse by internal users, the users that are connected= to the same network? If yes, then this is not even remotely an issue of DN= S-SD, this is a network design problem. Either the devices are not suitable= for the requirements of safety or the network design is not suitable to co= pe for end-device misdesign. Either way, DNS-SD and global addresses are wr= ong trees to bark up. > This is > only one example of devices never intended to be directly accessible on t= he > Internet, and which may be subject to abuse when DNS-SD is used > indiscriminately. This is mixing things. Having a global address does not imply global access= ability! What does you make believing so? As I'm typing this, my computer h= as its very own global IPv4 address (ups, shame on me!), yet you won't be e= ver able to reach it. Yes, I use a unique global IPv4 address ... inside th= e company intranet. And it's not a private address. So there clearly are se= cure setups that use global addresses and use DNS-SD and no one drops dead. > Insecurely assigned prefixes and randomly assigned Interface-IDs never > being publicly published still offers weak security. Multiple off-the-sh= elf > home routers should be expected to use dynamically assigned prefixes, sin= ce > some insist dynamic prefix assignment improves privacy. (Some providers > bind prefix assignments with the MACs used by the modem where any MAC > change necessitates an approval process.) Without use of ULA overlay > addressing in such a home network, firewalls will remain susceptible when > unable to recognize internal IP addresses, and hence unable to block > externally initiated sessions. You are mixing different things here, so it's difficult to understand what = your point actually is. First, what are insecurely assigned prefixes?? And = yes, IIDs are not for security ... they have one clear purpose: to identify= a particular IPv6 interface in a given subnet. So this is as obvious as sa= ying that assigning your subnet routers IPv4 addresses that don't end in .1= or .254 improves security. ULA addresses are not for security, please show me the RFC that does claim = so. Over time, people have come to understand that ULAs offer stable intran= et addressing. But what does stable addressing has to do with security? I c= an't understand why you are mixing up all these different things, it's real= ly hard to understand for me. > On the other hand, enterprise networks likely have statically assigned > prefixes. While static assignment or known router prefix assignment > information allows greater use of GUA addressing, exploits may still defe= at > stateful src/dst firewall protections. Should I read this as a plea to move to end-to-end transport security and a= uthentification? If you are arguing for this, then yes, this offers better = security. But from your current wording I'm really not clear about what you= are trying to argue for. But again, please don't kill the GUAs for somethi= ng they didn't do. LG, Harald From nobody Tue Jul 29 01:48:15 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2ED51A00DB for ; Tue, 29 Jul 2014 01:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 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, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=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 sMHYF-r-sNp3 for ; Tue, 29 Jul 2014 01:48:11 -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 EC0381A0086 for ; Tue, 29 Jul 2014 01:48:10 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s6T8lsSL006857; Tue, 29 Jul 2014 09:47:54 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s6T8lsSL006857 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1406623675; bh=yPJQmuNEB7opw2bodd15EmKSbQ8=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=OxrtVTL0mUXOD945qiTxVNgVBBshgJYQ85hw7HMUJCIrfKYNrK3nGjSpBL+8BJiTM xKfCqjYB8GTWA9N2GidundPG6PcdpkNv1OS3bhMWRSIN+oyh6KPE2TxDf5KixPGt7t 77Pbk+VGPYb3Ko+yy8cuAQjngyAFCLzjglpQ0neo= 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 q6S9lr2128501212Qn ret-id none; Tue, 29 Jul 2014 09:47:55 +0100 Received: from [IPv6:2001:630:d0:ed04:3cb1:18b1:6bbe:774] ([IPv6:2001:630:d0:ed04:3cb1:18b1:6bbe:774]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s6T8lod4007330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 29 Jul 2014 09:47:51 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_423E54D9-E531-4A76-A019-5C4DBF1C2AA1" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Chown In-Reply-To: Date: Tue, 29 Jul 2014 09:47:51 +0100 Message-ID: References: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> <20E4ED19-12BD-45D4-B690-8629B552B23B@gmail.com> <0E0BC226-E68E-4BC2-99EA-AFF1AF96A5EC@ecs.soton.ac.uk> <8465FD60-84CD-41B3-BBE3-1BDB52DF0DDB@hp.com> <364AAF85-5FB4-4828-A5A4-11160E747BC9@gmail.com> <24377.1406225491@sandelman.ca> <3949.1406228928@sandelman.ca> <4CCB4658-8B54-460B-AC4B-8230EEEF54CA@hp.com> To: "Albrecht, Harald" X-Mailer: Apple Mail (2.1878.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q6S9lr212850121200; tid=q6S9lr2128501212Qn; client=relay,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s6T8lsSL006857 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/E9TSf6VoYAsuKyUsze9V0NZYaEM Cc: "Kennedy, Smith \(Wireless Architect\)" , "dnssd@ietf.org" , Douglas Otis , Michael Richardson Subject: Re: [dnssd] Security through Obscurity X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jul 2014 08:48:13 -0000 --Apple-Mail=_423E54D9-E531-4A76-A019-5C4DBF1C2AA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, There is some interesting discussion happening here, but we do need to = focus the discussion on the elements that are important to defining = scalable DNS-based service discovery, as per our group=92s charter. Of = course if there are related topics that people think are important, = those can be progressed elsewhere, such as 6man or v6ops, though we = should remember that dnssd=92s charter is IP version agnostic. It would be useful therefore to capture what is of direct relevance to = dnssd from this discussion. One point is that a comment was made at IETF90 that dnssd should not = explictly care about stability of addresses, and it should work however = frequently a device is renumbered or changes address. So if someone = implements the =91press a button to renumber my home network=92 idea = discussed elsewhere, dnnsd should be able to react, and, as per REQ13 = should ensure information is up to date and not stale. It was also said that we should note the distinction between a service = running on a device being discoverable (via dnssd), reachable (dependent = on ACLs etc) and usable (via authentication). We don=92t want to rathole = here on default home network CPE firewall settings, or the merits of = RFC7217, take that to v6ops.=20 There is some discussion of handling the scopes of discoverable devices = in draft-cheshire-dnssd-hybrid-01, in Section 3.1. I suspect Stuart = would be happy to receive thoughts on that text. ULAs have been = discussed for homenet (in parallel to GUAs), and RFC1918 addresses are = of course in wide use for IPv4 homes and enterprises. Tim --Apple-Mail=_423E54D9-E531-4A76-A019-5C4DBF1C2AA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi,

There is some interesting = discussion happening here, but we do need to focus the discussion on the = elements that are important to defining scalable DNS-based service = discovery, as per our group=92s charter.  Of course if there are = related topics that people think are important, those can be progressed = elsewhere, such as 6man or v6ops, though we should remember that dnssd=92s= charter is IP version agnostic.

It would be useful = therefore to capture what is of direct relevance to dnssd from this = discussion.

One = point is that a comment was made at IETF90 that dnssd should not = explictly care about stability of addresses, and it should work however = frequently a device is renumbered or changes address. So if someone = implements the =91press a button to renumber my home network=92 idea = discussed elsewhere, dnnsd should be able to react, and, as per REQ13 = should ensure information is up to date and not stale.

It was also said that we should note the = distinction between a service running on a device being discoverable = (via dnssd), reachable (dependent on ACLs etc) and usable (via = authentication). We don=92t want to rathole here on default home network = CPE firewall settings, or the merits of RFC7217, take that to = v6ops. 

There is some discussion of handling the = scopes of discoverable devices in draft-cheshire-dnssd-hybrid-01, = in Section 3.1. I suspect Stuart would be happy to receive thoughts on = that text.  ULAs have been discussed for homenet (in parallel to = GUAs), and RFC1918 addresses are of course in wide use for IPv4 homes = and enterprises.

Tim

= --Apple-Mail=_423E54D9-E531-4A76-A019-5C4DBF1C2AA1-- From nobody Tue Jul 29 01:50:52 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECAA1A00DB for ; Tue, 29 Jul 2014 01:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 dr97_uKXzor7 for ; Tue, 29 Jul 2014 01:50:47 -0700 (PDT) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BC3F1A00E7 for ; Tue, 29 Jul 2014 01:50:47 -0700 (PDT) Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.14.3/8.14.3) with ESMTP id s6T8oYWG017034; Tue, 29 Jul 2014 10:50:34 +0200 Received: from DEFTHW99ERKMSX.ww902.siemens.net (defthw99erkmsx.ww902.siemens.net [139.22.70.147]) by mail2.sbs.de (8.14.3/8.14.3) with ESMTP id s6T8oYD3028214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 10:50:34 +0200 Received: from DENBGAT9ERBMSX.ww902.siemens.net (139.22.70.93) by DEFTHW99ERKMSX.ww902.siemens.net (139.22.70.147) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 29 Jul 2014 10:50:34 +0200 Received: from DEFTHW99EK5MSX.ww902.siemens.net ([169.254.6.83]) by DENBGAT9ERBMSX.ww902.siemens.net ([139.22.70.93]) with mapi id 14.03.0195.001; Tue, 29 Jul 2014 10:50:33 +0200 From: "Albrecht, Harald" To: Tim Chown Thread-Topic: [dnssd] Security through Obscurity Thread-Index: AQHPprfbeCMVdoWCv0+IRw2l+oT97JuuTemAgADDcoCAAAvegIAAIsuAgAAJowCAABzGgIAAEAEAgADpzzCAAGScAIAFTO+AgACYA1D///rNgIAAIhPg Date: Tue, 29 Jul 2014 08:50:32 +0000 Message-ID: References: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> <20E4ED19-12BD-45D4-B690-8629B552B23B@gmail.com> <0E0BC226-E68E-4BC2-99EA-AFF1AF96A5EC@ecs.soton.ac.uk> <8465FD60-84CD-41B3-BBE3-1BDB52DF0DDB@hp.com> <364AAF85-5FB4-4828-A5A4-11160E747BC9@gmail.com> <24377.1406225491@sandelman.ca> <3949.1406228928@sandelman.ca> <4CCB4658-8B54-460B-AC4B-8230EEEF54CA@hp.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.31] Content-Type: multipart/alternative; boundary="_000_E36F274013087B4EA05E08EB503750390BEE6605DEFTHW99EK5MSXw_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/SwpxCg3w_KCmaF6CSn3D3r-pBPA Cc: "Kennedy, Smith \(Wireless Architect\)" , "dnssd@ietf.org" , Douglas Otis , Michael Richardson Subject: Re: [dnssd] Security through Obscurity X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jul 2014 08:50:50 -0000 --_000_E36F274013087B4EA05E08EB503750390BEE6605DEFTHW99EK5MSXw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is also exactly my understanding, thanks for clarifying this. Von: dnssd [mailto:dnssd-bounces@ietf.org] Im Auftrag von Tim Chown Gesendet: Dienstag, 29. Juli 2014 10:48 An: Albrecht, Harald Cc: Kennedy, Smith (Wireless Architect); dnssd@ietf.org; Douglas Otis; Mich= ael Richardson Betreff: Re: [dnssd] Security through Obscurity Hi, There is some interesting discussion happening here, but we do need to focu= s the discussion on the elements that are important to defining scalable DN= S-based service discovery, as per our group's charter. Of course if there = are related topics that people think are important, those can be progressed= elsewhere, such as 6man or v6ops, though we should remember that dnssd's c= harter is IP version agnostic. It would be useful therefore to capture what is of direct relevance to dnss= d from this discussion. One point is that a comment was made at IETF90 that dnssd should not explic= tly care about stability of addresses, and it should work however frequentl= y a device is renumbered or changes address. So if someone implements the '= press a button to renumber my home network' idea discussed elsewhere, dnnsd= should be able to react, and, as per REQ13 should ensure information is up= to date and not stale. It was also said that we should note the distinction between a service runn= ing on a device being discoverable (via dnssd), reachable (dependent on ACL= s etc) and usable (via authentication). We don't want to rathole here on de= fault home network CPE firewall settings, or the merits of RFC7217, take th= at to v6ops. There is some discussion of handling the scopes of discoverable devices in = draft-cheshire-dnssd-hybrid-01, in Section 3.1. I suspect Stuart would be h= appy to receive thoughts on that text. ULAs have been discussed for homene= t (in parallel to GUAs), and RFC1918 addresses are of course in wide use fo= r IPv4 homes and enterprises. Tim --_000_E36F274013087B4EA05E08EB503750390BEE6605DEFTHW99EK5MSXw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is al= so exactly my understanding, thanks for clarifying this.<= /p>

 

Von: dnssd [ma= ilto:dnssd-bounces@ietf.org] Im Auftrag von Tim Chown
Gesendet: Dienstag, 29. Juli 2014 10:48
An: Albrecht, Harald
Cc: Kennedy, Smith (Wireless Architect); dnssd@ietf.org; Douglas Oti= s; Michael Richardson
Betreff: Re: [dnssd] Security through Obscurity

 

Hi,

 

There is some interesting discussion happening here,= but we do need to focus the discussion on the elements that are important = to defining scalable DNS-based service discovery, as per our group’s = charter.  Of course if there are related topics that people think are important, those can be progressed elsewhere,= such as 6man or v6ops, though we should remember that dnssd’s charte= r is IP version agnostic.

 

It would be useful therefore to capture what is of d= irect relevance to dnssd from this discussion.

 

One point is that a comment was made at IETF90 that = dnssd should not explictly care about stability of addresses, and it should= work however frequently a device is renumbered or changes address. So if s= omeone implements the ‘press a button to renumber my home network’ idea discussed elsewhere, dnnsd should = be able to react, and, as per REQ13 should ensure information is up to date= and not stale.

 

It was also said that we should note the distinction= between a service running on a device being discoverable (via dnssd), reac= hable (dependent on ACLs etc) and usable (via authentication). We don’= ;t want to rathole here on default home network CPE firewall settings, or the merits of RFC7217, take that to v6op= s. 

 

There is some discussion of handling the scopes of d= iscoverable devices in draft-cheshire-dnssd-hybrid-01, in Section 3.1.= I suspect Stuart would be happy to receive thoughts on that text.  UL= As have been discussed for homenet (in parallel to GUAs), and RFC1918 addresses are of course in wide use for IPv4 homes a= nd enterprises.


Tim

 

--_000_E36F274013087B4EA05E08EB503750390BEE6605DEFTHW99EK5MSXw_-- From nobody Thu Jul 31 20:55:09 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672821A035B for ; Thu, 31 Jul 2014 20:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.496 X-Spam-Level: ** X-Spam-Status: No, score=2.496 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 Djvj3ZvAUG6y for ; Thu, 31 Jul 2014 20:55:06 -0700 (PDT) Received: from mail.ccgs.wa.edu.au (io.ccgs.wa.edu.au [203.135.184.6]) by ietfa.amsl.com (Postfix) with ESMTP id 920BC1A03BA for ; Thu, 31 Jul 2014 20:55:05 -0700 (PDT) Received: by mail.ccgs.wa.edu.au (Postfix, from userid 108) id 9D391118085; Fri, 1 Aug 2014 11:55:03 +0800 (WST) X-CCGS-ID: 20140801115500-619 X-CCGS-ARGS: jandrewartha@ccgs.wa.edu.au dnssd@ietf.org Received: from atlas.ad.ccgs.wa.edu.au (atlas.ad.ccgs.wa.edu.au [10.20.10.4]) by mail.ccgs.wa.edu.au (Postfix) with ESMTP id 29436118067 for ; Fri, 1 Aug 2014 11:55:00 +0800 (WST) Received: from [10.10.20.21] (10.10.20.21) by atlas.ad.ccgs.wa.edu.au (10.20.10.4) with Microsoft SMTP Server id 8.2.255.0; Fri, 1 Aug 2014 11:55:00 +0800 Message-ID: <53DB0F93.2070509@ccgs.wa.edu.au> Date: Fri, 1 Aug 2014 11:54:59 +0800 From: James Andrewartha Organization: Christ Church Grammar School User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: References: <331F9173-DB56-4D9A-B09F-956FF6D8DA2B@gmail.com> <1F1E6B22-5FF2-41DF-BA86-20A9D57E74CC@gmail.com> <7414908D-B2A9-4935-912F-EF3E4995065F@nominum.com> <0696C085-C817-44F1-8CC1-2355A9704623@bangj.com> In-Reply-To: <0696C085-C817-44F1-8CC1-2355A9704623@bangj.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/6M_eDORpxQ8o-LCwuboJeYE7mTI Subject: Re: [dnssd] multicast over wireless links X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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 Aug 2014 03:55:08 -0000 Hi Tom, On 25/07/14 07:47, Tom Pusateri wrote: > Having spent a good portion of my career on IP multicast (from Token Ring to IP Multicast VPNs), it baffles me how a radio can have such a difficult time doing IP multicast. The 802.11 link layer clearly needs improvement in this area. Access points regularly fall over dead when bridging an ethernet wired connection to wireless when there is a high data rate multicast stream (actually 4Mbps isn't that high). This is just unacceptable. > > With most radios, multicast is the most efficient form of transmission. But in 802.11, every receiver in range currently receives N copies of the multicast to their antenna before throwing all of them but one away. Surely, this can be improved. Multi-unicast over radio broadcast has to be the least efficient mechanism to achieve this. I don't know how familiar you are with 802.11, but the core problem is the methods used to increase the data rates to clients mean each client can speak to the AP at a different rate. In short, multicast is inefficient for 802.11 because it must speak at the slowest rate the AP allows clients to connect to it at. This can be as low as 1Mbps if 802.11b clients are allowed to connect. The multicast to unicast conversion you speak of is an optimisation implemented by some vendors, and works because if there are say 5 clients connected at say 300Mbps, and one client at 12Mbps, they can all receive the transmission in unicast faster than if it were sent out as multicast at 1Mbps for all clients to receive. Another optimisation some vendors implement is to broadcast/multicast at the minimum rate of the connected clients, which in this case would allow transmission at 12Mbps. Also note that multicast/broadcast traffic will only ever use one spatial stream as that is the minimum required by 802.11n/ac, while some clients suport two or three spatial streams for higher data rates. So again multicast to unicast translation will result in more efficient transmission. 802.11ac MU-MIMO will further complicate things, as it will allow higher unicast data rates and simultaneous transmission of possibly different data streams to different clients at the same time. Thanks, -- James Andrewartha Network & Projects Engineer Christ Church Grammar School Claremont, Western Australia Ph. (08) 9442 1757 Mob. 0424 160 877