From nobody Wed Apr 1 10:16:33 2015 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 2DDED1A005B for ; Wed, 1 Apr 2015 10:16:32 -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 rp0-YkNNu-33 for ; Wed, 1 Apr 2015 10:16:30 -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 D1B8A1A0030 for ; Wed, 1 Apr 2015 10:16:30 -0700 (PDT) Received: from [172.16.10.140] (gw.mountain2sea.com [71.70.135.90]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id E6D281D2B for ; Wed, 1 Apr 2015 13:11:21 -0400 (EDT) From: Tom Pusateri X-Pgp-Agent: GPGMail 2.5b6 Content-Type: multipart/signed; boundary="Apple-Mail=_9AC08A0B-47AA-4022-96E5-E6B3F9A6A500"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Wed, 1 Apr 2015 13:16:28 -0400 Message-Id: To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [dnssd] Hybrid Proxy configuration & deployment draft 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, 01 Apr 2015 17:16:32 -0000 --Apple-Mail=_9AC08A0B-47AA-4022-96E5-E6B3F9A6A500 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As promised in the working group meeting, I put together a draft of = configuration parameters and some deployment advice for the Hybrid = Proxy. http://tools.ietf.org/html/draft-pusateri-hybridproxy-impl-00 I'd love to get some feedback on this. If you're working on an = implementation and have come across other necessary or optional = parameters, let me know. Thanks, Tom --Apple-Mail=_9AC08A0B-47AA-4022-96E5-E6B3F9A6A500 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJVHCfsAAoJEPk0GMVmUuYM+jwH/Rw8zyUaTRhpD21JUs+8i+Dt bxqhl/icjTGx1BFyse9XsdnZTkNBKEyc/F/SRrV1UxPPwK8KSaGWRi5gX9MrxmSp x3EgfKtAsc+EgBubMzRoAEJQyZjR3Sr1ROn/ndVasVBc+dmnjJ2cBCoZquvosH8l N3TmzqkVEI4Pc5PIUcXG+nmnfWv441JGNM5Bl2UfDvGkPXBddiT+L31ns4YeTSfl 9iqJ4byI4qrniZ+77f4eqi1DGelLtu2xFwa3EhICZXO0j1PVtkRhIcMRfkXl/sO+ XySM9j0VTPpayVfG73bkTNmprjgeOtJxMDNEZjUzTrJTWbo42N3neROB+4mMxW0= =RSZ5 -----END PGP SIGNATURE----- --Apple-Mail=_9AC08A0B-47AA-4022-96E5-E6B3F9A6A500-- From nobody Thu Apr 2 03:48:45 2015 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 2CF3C1B2C4E for ; Thu, 2 Apr 2015 03:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 kpFeAy3O6LoR for ; Thu, 2 Apr 2015 03:48:40 -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 A52241A9047 for ; Thu, 2 Apr 2015 03:48:39 -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 t32AmZi9015921; Thu, 2 Apr 2015 12:48:35 +0200 Received: from DEFTHW99ERLMSX.ww902.siemens.net (defthw99erlmsx.ww902.siemens.net [139.22.70.136]) by mail2.sbs.de (8.14.3/8.14.3) with ESMTP id t32AmZr0006756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Apr 2015 12:48:35 +0200 Received: from DEFTHW99EK5MSX.ww902.siemens.net ([169.254.6.44]) by DEFTHW99ERLMSX.ww902.siemens.net ([139.22.70.136]) with mapi id 14.03.0235.001; Thu, 2 Apr 2015 12:48:34 +0200 From: "Albrecht, Harald" To: Tom Pusateri , "dnssd@ietf.org" Thread-Topic: [dnssd] Hybrid Proxy configuration & deployment draft Thread-Index: AQHQbJ+d1k3Siaf6aECl3Jn51LE4WZ05iaDw Date: Thu, 2 Apr 2015 10:48:34 +0000 Message-ID: References: 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.30] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dnssd] Hybrid Proxy configuration & deployment draft 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, 02 Apr 2015 10:48:45 -0000 Helllo Tom, in section 3.1, list item #2 you mention: "As an example, this could be foo.example.com where example.com is the domain name distributed through DHCP or SLAAC and foo is the assigned subdomain." While I'm aware of the FQDN options in DHCPv4 and DHCPv6, I'm not aware of = SLAAC being able to distribute a FQDN or domain name in general. Or am I mi= ssing something possibly obvious here? To my limited knowledge I'm aware of the DNS configuration options for ICMP= v6 Router Advertisements (RAs). One such option is for DNSSL(?), the DNS se= arch lists. Do you have some idea in mind how to make use of this existing = DNSSL option which isn't yet spelled out in the draft? Or do you intend to = define a new RA option that would carry a domain name for completing local = device names, such as the mDNS device (host) names? With best regards, Harald Siemens AG Digital Factory Division Factory Automation DF FA TIP DH NBG Gleiwitzer Str. 555 90475 Nuernberg, Germany=20 Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Crom= me; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Off= icer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Siegfried Rus= swurm, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Comm= ercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE= -Reg.-No. DE 23691322 -----Urspr=FCngliche Nachricht----- Von: dnssd [mailto:dnssd-bounces@ietf.org] Im Auftrag von Tom Pusateri Gesendet: Mittwoch, 1. April 2015 19:16 An: dnssd@ietf.org Betreff: [dnssd] Hybrid Proxy configuration & deployment draft As promised in the working group meeting, I put together a draft of configu= ration parameters and some deployment advice for the Hybrid Proxy. http://tools.ietf.org/html/draft-pusateri-hybridproxy-impl-00 I'd love to get some feedback on this. If you're working on an implementati= on and have come across other necessary or optional parameters, let me know= . Thanks, Tom From nobody Thu Apr 2 05:42:19 2015 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 200201A8A0B for ; Thu, 2 Apr 2015 05:42:18 -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 LyXoYcWZXg2D for ; Thu, 2 Apr 2015 05:42:16 -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 408E11A1A9C for ; Thu, 2 Apr 2015 05:42:16 -0700 (PDT) Received: from [172.16.10.140] (gw.mountain2sea.com [71.70.135.90]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id BB4FF1E49; Thu, 2 Apr 2015 08:37:03 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_344249C8-359E-4944-9473-2BEA8872760E"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Tom Pusateri In-Reply-To: Date: Thu, 2 Apr 2015 08:42:14 -0400 Message-Id: <4FC4A565-7442-4024-91BC-5A34A475EE34@bangj.com> References: To: "Albrecht, Harald" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "dnssd@ietf.org" Subject: Re: [dnssd] Hybrid Proxy configuration & deployment draft 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, 02 Apr 2015 12:42:18 -0000 --Apple-Mail=_344249C8-359E-4944-9473-2BEA8872760E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Harald, You are correct. I was thinking of the ICMPv6 Router = Advertisement Options (RFC 6106) and iterating over the search list but = mistakenly thought that was classified as a part of SLAAC. I will fix = this. Thanks, Tom > On Apr 2, 2015, at 6:48 AM, Albrecht, Harald = wrote: >=20 > Helllo Tom, >=20 > in section 3.1, list item #2 you mention: >=20 > "As an example, this could be foo.example.com where example.com is > the domain name distributed through DHCP or SLAAC and foo is the > assigned subdomain." >=20 > While I'm aware of the FQDN options in DHCPv4 and DHCPv6, I'm not = aware of SLAAC being able to distribute a FQDN or domain name in = general. Or am I missing something possibly obvious here? >=20 > To my limited knowledge I'm aware of the DNS configuration options for = ICMPv6 Router Advertisements (RAs). One such option is for DNSSL(?), the = DNS search lists. Do you have some idea in mind how to make use of this = existing DNSSL option which isn't yet spelled out in the draft? Or do = you intend to define a new RA option that would carry a domain name for = completing local device names, such as the mDNS device (host) names? >=20 > With best regards, > Harald >=20 > Siemens AG > Digital Factory Division > Factory Automation > DF FA TIP DH NBG > Gleiwitzer Str. 555 > 90475 Nuernberg, Germany >=20 > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard = Cromme; Managing Board: Joe Kaeser, Chairman, President and Chief = Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina = Kugel, Siegfried Russwurm, Ralf P. Thomas; Registered offices: Berlin = and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB = 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 >=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: dnssd [mailto:dnssd-bounces@ietf.org] Im Auftrag von Tom Pusateri > Gesendet: Mittwoch, 1. April 2015 19:16 > An: dnssd@ietf.org > Betreff: [dnssd] Hybrid Proxy configuration & deployment draft >=20 > As promised in the working group meeting, I put together a draft of = configuration parameters and some deployment advice for the Hybrid = Proxy. >=20 >=20 > http://tools.ietf.org/html/draft-pusateri-hybridproxy-impl-00 >=20 >=20 > I'd love to get some feedback on this. If you're working on an = implementation and have come across other necessary or optional = parameters, let me know. >=20 > Thanks, > Tom >=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_344249C8-359E-4944-9473-2BEA8872760E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJVHTkmAAoJEPk0GMVmUuYMMlUIAMxjoucZ0fRFlN+/Eu/zIFaq 2AIoCp+ZbAQzqcz9p+4qmn6XM/LxnQ4FEnSjpZQAknrEQcKIddtlFA+rhxHhlkK1 ZInYKrNft9sz19DtH89+e/FMVJBFX5HrvJ07pyDYOqiZfqkzDss9b0mvSSHEaTNW haWthLSbXNv9bVcul3Eo628LXZ4w5qq3Nkt2WsmGB/CnL649a2IPKenvKpGpjR8j oBSbVerQMb2Nnl+8uHKjiN7Dd0X/3Cpl/x+cfrwUwNWJ4sKFZvRTsILs0rzFPrHv IRg9pI3N80NvXWOS+lRvEBHKQaDmPH3bVE7nGd2ZUX70+Z9XBrIanTFz1Dml6vc= =Kyvp -----END PGP SIGNATURE----- --Apple-Mail=_344249C8-359E-4944-9473-2BEA8872760E-- From nobody Wed Apr 8 01:49:18 2015 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 A2F2B1A079D for ; Wed, 8 Apr 2015 01:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 lu_NkHwaIiZA for ; Wed, 8 Apr 2015 01:49:14 -0700 (PDT) Received: from kirsi2.inet.fi (mta-out1.inet.fi [62.71.2.203]) by ietfa.amsl.com (Postfix) with ESMTP id D42DB1A0687 for ; Wed, 8 Apr 2015 01:49:13 -0700 (PDT) Received: from poro.lan (80.220.64.126) by kirsi2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 5511FF6A001B2A9A; Wed, 8 Apr 2015 11:49:09 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Markus Stenberg In-Reply-To: Date: Wed, 8 Apr 2015 11:49:08 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tom Pusateri X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: dnssd@ietf.org, Markus Stenberg Subject: Re: [dnssd] Hybrid Proxy configuration & deployment draft 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, 08 Apr 2015 08:49:16 -0000 On 1.4.2015, at 20.16, Tom Pusateri wrote: >=20 > As promised in the working group meeting, I put together a draft of = configuration parameters and some deployment advice for the Hybrid = Proxy. >=20 >=20 > http://tools.ietf.org/html/draft-pusateri-hybridproxy-impl-00 >=20 > I'd love to get some feedback on this. If you=E2=80=99re working on an = implementation and have come across other necessary or optional = parameters, let me know. In section 2, I would also like to see legacy browse ptr option (not = necessarily for all domains); early on in our hybrid proxy = implementation experience, we noted that many clients require that to be = functional (and expecting them all to be fixed is wistful thinking I = think). Whether that would be option under 2.2, or separate 2.3, I do = not know. I think 3.1 #2 was somewhat controversial? At least I vaguely remember = that from Dallas. Perhaps mentioning something about that would be = useful. In section 3.1, how about the new =E2=80=98host subdomain=E2=80=99 <> = =E2=80=99service subdomain=E2=80=99 that showed up in some later version = of hybrid draft? (disclaimer: we do not implement the separation.) I = believe the idea was there to have a zone that had ASCII hostname-ish = names for A/AAAs, and have the SRV records in potentially UTF-8 zone = pointing there or something. BTW, 3.1 #3 is cool idea ;) And in IPv6 case, you can be actually more = clever if you know the site-wide prefix in use; just use the bits that = distinguish the local prefix from the delegated prefix the whole site = has. (I guess same could be done in IPv4 too, given configuration about = what the local prefix is.) Section 3.4, #2/#3: Are those actually officially required? (I am not = sure we do this currently) So not sure they are =E2=80=98minimum=E2=80=99 = requirements at least. Section 3.5, UDP port - can that be actually be expressedin a NS record? = If not, then not really relevant unless colocated or somehow transmitted = outside DNS (we do this in colocated case to keep our hybrid proxy = implementation from ever being connected remotely and use local dns = forwarder to forward requests to it, but it is implementation choice and = therefore not sure it applies here _in general_) Section 4.1: Not sure this is relevant. If it is, then we should also = mention that DNS server address(es) has to be provided to client too = (using DHCP, DHCPv6 or ICMPv6). Cheers, -Markus= From nobody Fri Apr 10 14:14:30 2015 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 D23B91A8A0E for ; Fri, 10 Apr 2015 14:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.038 X-Spam-Level: X-Spam-Status: No, score=-3.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-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 x-pMg0jwr-v6 for ; Fri, 10 Apr 2015 14:14:25 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E0C1A8A0B for ; Fri, 10 Apr 2015 14:14:25 -0700 (PDT) Received: from [192.168.200.14] (67.20.128.85.dyn-e120.pool.hargray.net [67.20.128.85]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 5522B186E8 for ; Fri, 10 Apr 2015 17:14:05 -0400 (EDT) From: Tom Pusateri X-Pgp-Agent: GPGMail 2.5b6 Content-Type: multipart/signed; boundary="Apple-Mail=_EE3CED0E-212F-44B0-9107-AC16B8A7FC6E"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Fri, 10 Apr 2015 17:14:25 -0400 Message-Id: To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [dnssd] Review of draft-ietf-dnssd-hybrid-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, 10 Apr 2015 21:14:29 -0000 --Apple-Mail=_EE3CED0E-212F-44B0-9107-AC16B8A7FC6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I thought before a new version was released, I would go ahead and do = another detailed review of the hybrid proxy draft. Abstract 2nd paragraph =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "Performing DNS-Based Service Discovery using purely Unicast DNS = is more efficient=E2=80=9D I=E2=80=99m sure it is more efficient in some ways and not as = efficient in other ways. Also, it obviously depends on the underlying = link layer and the transport protocol and security layers. I don=E2=80=99t= think a general statement of unicast being more efficient than = multicast is possible. Introduction 3rd paragraph =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Similarly, "since even on a single link multicast traffic is = expensive=E2=80=9D. Again, it is expensive in some ways and more = efficient in other ways. Section 2 3rd paragraph =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There is a pointer to [802.5] with no matching reference. Add = http://xml2rfc.ietf.org/public/rfc/bibxml2/reference.IEEE.802-5.1995.xml Section 3 1st paragraph =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D After describing in the previous section what is meant by =E2=80=9C= on the same link=E2=80=9D, Section 3 says unicast DNS domain names are = assigned to "each physical link=E2=80=9D. The word physical should be = removed. Another way to say this may to use =E2=80=9Ceach IP subnet=E2=80=9D= which could be included in section 2 as well. Section 3 2nd paragraph =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "This Hybrid Proxy function could be performed by a router on = that link, or, with appropriate VLAN configuration, a single Hybrid = Proxy could have a logical presence on, and serve as the Hybrid Proxy = for, many links=E2=80=9D This wording is a little awkward and makes it seem as though = multiple VLANs are required for a Hybrid Proxy to serve many links. Section 3.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The acronym LDH (Letter, Digit, Hyphen) is not defined or referenced = anywhere. A reference to Section 2.2 of RFC 5890 should be included. Section 3.3 2nd paragraph =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= The example IP addresses should use documentation IPv4 address ranges as = specified in RFC 5737. Section 3.3 4th paragraph =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= "(In the Apple "/usr/include/dns_sd.h" APIs, using = ForceMulticast indicates that the DNSServiceQueryRecord() call should = perform the query using Multicast DNS.)=E2=80=9D The significance of this reference is not apparent. Section 3.4.1 2nd paragraph =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D needs updating for DNS Push Notifications Section 3.4.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Since hybrid proxies can never know all of the possible records = in the subdomain, it is not possible to build NSEC next record = relations. Therefore, all NSEC records learned over mDNS (typically in = the Additional Section) should be filtered in unicast DNS responses sent = by the hybrid proxy. Section 3.4.3 4th paragraph =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D "violations optional=E2=80=9D should be "violations are = optional" Section 3.5 2nd paragraph =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= needs updating for DNS Push Notifications Section 3.5.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D If the hybrid proxy implements LLQ or DNS Push, it should = advertise its own SRV records for LLQ and/or DNS Push through mDNS on = the shared IP subnet. Section 3.5 5th paragraph, 2nd bullet =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "No LLQ option; at least one answer in cache: Send response = right away to minimize delay. (Reasoning: Given RRSet TTL harmonisation, if the proxy has one = Multicast DNS answer in its cache, it can reasonably assume that it has = all of them.)=E2=80=9D Because of Probing (section 8.1) and Announcing (section 8.3) in = RFC 6762, isn=E2=80=99t it possible that a hybrid proxy could have one = answer in its cache but not all answers? Section 4.2 2nd paragraph =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= needs updating for DNS Push Notifications Section 4.3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Since stitching together multiple .local domains isn=E2=80=99t = specified, it seems premature to say it=E2=80=99s not implemented, both = in the same paragraph. Section 5 1st paragraph =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "For this reason, each physical link may have *two* unrelated = ".local." zones, one for IPv4 and one for IPv6.=E2=80=9D The word =E2=80=9Cphysical=E2=80=9D is used again here but I = would prefer to see IP subnet or just link without the =E2=80=9Cphysical=E2= =80=9D since you defined what link meant. Section 5 2nd paragraph =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Although this section doesn=E2=80=99t specifically say so, it = seems to be saying do not use the same subdomain name for IPv4 and IPv6 = on the same link. Since we want to encourage IPv6 proliferation and yet = it will be difficult to withdraw IPv4, I would rather say it is assumed = that if you assign the same subdomain name to both IPv4 and IPv6 subnets = on the same link, you are assuming that the clients on the link can = handle this scenario. If you have IPv4-only hosts or IPv6-only hosts, = then assign different names to prevent learning about services that you = won=E2=80=99t be able to reach. This leaves the choice up to the = administrator. Section 6.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "If greater security is desired, then the Hybrid Proxy mechanism = should not be used, and something with stronger security should be used = instead, such as authenticated secure DNS Update=E2=80=9D It would seem that there are other ways to provide greater = security with the hybrid proxy including DNSSEC record signatures of the = service records, as an example, and so the hybrid proxy could still be = used if greater security is desired. Section 6.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "The privacy of this information may be protected using = techniques like firewalls and split-view DNS, as are customarily used = today to protect the privacy of corporate DNS information.=E2=80=9D The hybrid proxy could also only provide sensitive records to = authenticated users. But this is a general DNS problem and not a problem = specific to the hybrid proxy. A reference to the work in DPRIVE that = outlines DNS privacy issues might be appropriate: = draft-ietf-dprive-problem-statement-04 Section 6.3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "Multicast traffic is expensive=E2=80=9D I would like this to either say "Multicast traffic can be = expensive=E2=80=9D or =E2=80=9CMulticast DNS is expensive=E2=80=9D. Multicast traffic is not always expensive. Also, since multicast can mean link-layer multicast, link-local = IP multicast, or routed IP multicast, the document should be more = specific here and with other uses of multicast. "For Wi-Fi links the Multicast DNS subsystem SHOULD NOT issue = more than 20 Multicast DNS query packets per second.=E2=80=9D On a campus with lots of unicast queries, this number seems = arbitrary. Is there some justification or maybe a rule of thumb here? Missing =3D=3D=3D=3D=3D=3D=3D The hybrid proxy should respond to SOA requests for the = subdomain in order for LLQ and DNS Push discovery to work correctly. However, if there are multiple hybrid proxies providing answers = for the same IP subnet, only one of them can be the SOA and so a method = is needed for coordination between the proxies. As mentioned above in 3.5.1, multiple hybrid proxies can = discover each other if they implement LLQ or DNS Push and so the one = with the lowest IP address could be the SOA or some similar tie-breaking = mechanism without having to configure a priority that has to be = exchanged. Other =3D=3D=3D=3D=3D If no DNS server is present (like in a home network), but there = are multiple IP subnets connected to the home gateway, and only mDNS = queries are made on each subnet, is this scenario covered by the hybrid = proxy? Or is this just a form of mDNS translation that is not currently = documented by any IETF standard? --Apple-Mail=_EE3CED0E-212F-44B0-9107-AC16B8A7FC6E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJVKD0xAAoJEPk0GMVmUuYMfR8IAN03YyFGp32VSd7zobIPG3N2 ByMLpn2n4YS1EiSESIsegmr26kYHOIS4dRh7NFQN06DLuPtkTgNFRRta3228Ekwr 3+oF3HZM0QkNk1mGXMul8Di1ADpfspkBrbXI7NHHuYzuY/Y2jWEWROVdpX4rvG/o Y1sg1Nlq5aw7au/yjTezBBo3PgGxWZaaLERg4vwAxpZXvRlrlV8BG3oXl7Yp65pU t65G3hEwdqT7lG83pPPFvClhSn+7ZeE64gMgWw1KIlPX9/hnBFxFKihDc76h23gW bUbH4JcRlm+dindzTo55lAngxGnYLnuTj2Q97M193BIWf0O7tXBgwACYT33eBMQ= =Cdas -----END PGP SIGNATURE----- --Apple-Mail=_EE3CED0E-212F-44B0-9107-AC16B8A7FC6E-- From nobody Fri Apr 10 18:54:02 2015 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 446E71A86FE for ; Fri, 10 Apr 2015 18:54:01 -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 ZmHEG9liU1G1 for ; Fri, 10 Apr 2015 18:53:59 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A0181A86E2 for ; Fri, 10 Apr 2015 18:53:59 -0700 (PDT) Received: from [172.16.21.162] (cpe-98-122-46-16.sc.res.rr.com [98.122.46.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id DE6AD18714; Fri, 10 Apr 2015 21:53:37 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A164E47D-BB2D-4C28-837A-D23788DC5642"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Tom Pusateri In-Reply-To: Date: Fri, 10 Apr 2015 21:53:55 -0400 Message-Id: References: To: Markus Stenberg X-Mailer: Apple Mail (2.2098) Archived-At: Cc: dnssd@ietf.org Subject: Re: [dnssd] Hybrid Proxy configuration & deployment draft 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: Sat, 11 Apr 2015 01:54:01 -0000 --Apple-Mail=_A164E47D-BB2D-4C28-837A-D23788DC5642 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 8, 2015, at 4:49 AM, Markus Stenberg = wrote: >=20 > In section 2, I would also like to see legacy browse ptr option (not = necessarily for all domains); early on in our hybrid proxy = implementation experience, we noted that many clients require that to be = functional (and expecting them all to be fixed is wistful thinking I = think). Whether that would be option under 2.2, or separate 2.3, I do = not know. >=20 Can you recall which clients need this? The hybrid proxy spec recommends = only a single legacy browse domain PTR record for the parent domain. = I=E2=80=99ll add this and a single default browse domain. > I think 3.1 #2 was somewhat controversial? At least I vaguely remember = that from Dallas. Perhaps mentioning something about that would be = useful. Yes, Andrew Sullivan mentioned at the microphone that reverse records = have fallen out of favor. =46rom the context, I gathered he was = referring to PTR records for hostnames (the inverse of A and AAAA = records). This is certainly true for AAAA. But I=E2=80=99m not sure this = applies to specialized PTR records for infrastructure such as the hybrid = proxy. This is specified in section 11 of RFC 6763 and is simply a way = to configure things for a campus all in one place and I don=E2=80=99t = think the same negative connotation of PTR records applies in all cases. = Maybe Andrew could chime in and expand? > In section 3.1, how about the new =E2=80=98host subdomain=E2=80=99 <> = =E2=80=99service subdomain=E2=80=99 that showed up in some later version = of hybrid draft? (disclaimer: we do not implement the separation.) I = believe the idea was there to have a zone that had ASCII hostname-ish = names for A/AAAs, and have the SRV records in potentially UTF-8 zone = pointing there or something. Yes, I forgot about section 3.2 of the hybrid proxy draft. I will add = this. > BTW, 3.1 #3 is cool idea ;) And in IPv6 case, you can be actually more = clever if you know the site-wide prefix in use; just use the bits that = distinguish the local prefix from the delegated prefix the whole site = has. (I guess same could be done in IPv4 too, given configuration about = what the local prefix is.) There is also the possibility of needing separate subdomain names for = IPv4 and IPv6 if IPv4-only or IPv6-only hosts exist. I need to add this. >=20 > Section 3.4, #2/#3: Are those actually officially required? (I am not = sure we do this currently) So not sure they are =E2=80=98minimum=E2=80=99 = requirements at least. I thought they were but after re-reading section 11 of RFC 6763, I=E2=80=99= m not sure. I=E2=80=99ll have to experiment some more. >=20 > Section 3.5, UDP port - can that be actually be expressedin a NS = record? If not, then not really relevant unless colocated or somehow = transmitted outside DNS (we do this in colocated case to keep our hybrid = proxy implementation from ever being connected remotely and use local = dns forwarder to forward requests to it, but it is implementation choice = and therefore not sure it applies here _in general_) Yes, you are correct. For a delegated subdomain, UDP and TCP must listen = on port 53. But I should add optional TLS and DTLS ports. The TLS port = will probably be the same as the tcp_push_port but DNS Push may not be = implemented so a direct TLS port without STARTTLS could be specified. >=20 > Section 4.1: Not sure this is relevant. If it is, then we should also = mention that DNS server address(es) has to be provided to client too = (using DHCP, DHCPv6 or ICMPv6). You are right again. I think I can remove the client configuration info. Thanks, Tom --Apple-Mail=_A164E47D-BB2D-4C28-837A-D23788DC5642 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJVKH60AAoJEPk0GMVmUuYMJHwIAMzG4FGa2uenZuKt2aGF+JBE wfyRuOS9tOlJpRzON5UYZD9E3zPl27NILACVnpPoc+k9M9NdytEAZdyiW93vk8gd TcsNmOf1T/67esB+7fUXcU8Zvr7ALtUhhd6Qll9T7ro38YNRkiVo2qb3App2rc4n cjmaVQq7czhwJ5TBcIBzxBXoxK4Fk9WkJF94K6t2tce0BLJR2G+B4VC0tOmRfi53 SetoNDNKVXj36KEw6E58+MPyY7wbFDK5yXFak9mktTyhdcH1TRExtrgcwdFPntMg AfXPXsn6j5+R9in3m3kcUEXrkYoIQ4XOHcQERHUQiiDBzTVHcygGmVr9UZCZN5U= =Bi9U -----END PGP SIGNATURE----- --Apple-Mail=_A164E47D-BB2D-4C28-837A-D23788DC5642-- From nobody Mon Apr 13 01:06:36 2015 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 E11CF1A8F43 for ; Mon, 13 Apr 2015 01:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 4MUDBrdGKZ6U for ; Mon, 13 Apr 2015 01:06:31 -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 10C241A8F49 for ; Mon, 13 Apr 2015 01:06:30 -0700 (PDT) Received: from mail1.sbs.de (localhost [127.0.0.1]) by david.siemens.de (8.14.3/8.14.3) with ESMTP id t3D86P0q032147; Mon, 13 Apr 2015 10:06:26 +0200 Received: from DEFTHW99ERKMSX.ww902.siemens.net (defthw99erkmsx.ww902.siemens.net [139.22.70.147]) by mail1.sbs.de (8.14.3/8.14.3) with ESMTP id t3D86PSF019326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Apr 2015 10:06:25 +0200 Received: from DEFTHW99ER2MSX.ww902.siemens.net (139.22.70.75) by DEFTHW99ERKMSX.ww902.siemens.net (139.22.70.147) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 13 Apr 2015 10:06:24 +0200 Received: from DEFTHW99EK5MSX.ww902.siemens.net ([169.254.6.44]) by DEFTHW99ER2MSX.ww902.siemens.net ([139.22.70.75]) with mapi id 14.03.0235.001; Mon, 13 Apr 2015 10:06:24 +0200 From: "Albrecht, Harald" To: Tom Pusateri , "dnssd@ietf.org" Thread-Topic: [dnssd] Review of draft-ietf-dnssd-hybrid-00 Thread-Index: AQHQc9NY983zp1nlA06PXmWeLxJBpJ1Klv5A Date: Mon, 13 Apr 2015 08:06:23 +0000 Message-ID: References: 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.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dnssd] Review of draft-ietf-dnssd-hybrid-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: Mon, 13 Apr 2015 08:06:33 -0000 SnVzdCBhIG1pbm9yIG5vdGUsIHBsZWFzZSBzZWUgYmVsb3c6DQoNCi0tLS0tVXJzcHLDvG5nbGlj aGUgTmFjaHJpY2h0LS0tLS0NClZvbjogZG5zc2QgW21haWx0bzpkbnNzZC1ib3VuY2VzQGlldGYu b3JnXSBJbSBBdWZ0cmFnIHZvbiBUb20gUHVzYXRlcmkNCg0KKysrKw0KU2VjdGlvbiAzIDFzdCBw YXJhZ3JhcGgNCj09PT09PT09PT09PT09PT09PT09PT09DQoJQWZ0ZXIgZGVzY3JpYmluZyBpbiB0 aGUgcHJldmlvdXMgc2VjdGlvbiB3aGF0IGlzIG1lYW50IGJ5IOKAnG9uIHRoZSBzYW1lIGxpbmvi gJ0sIFNlY3Rpb24gMyBzYXlzIHVuaWNhc3QgRE5TIGRvbWFpbiBuYW1lcyBhcmUgYXNzaWduZWQg dG8gImVhY2ggcGh5c2ljYWwgbGlua+KAnS4gVGhlIHdvcmQgcGh5c2ljYWwgc2hvdWxkIGJlIHJl bW92ZWQuIEFub3RoZXIgd2F5IHRvIHNheSB0aGlzIG1heSB0byB1c2Ug4oCcZWFjaCBJUCBzdWJu ZXTigJ0gd2hpY2ggY291bGQgYmUgaW5jbHVkZWQgaW4gc2VjdGlvbiAyIGFzIHdlbGwuDQorKysr DQoNCkZyb20gdGhlIElQdjYgcGVyc3BlY3RpdmUgSSB3b3VsZCBsaWtlIHRvIHBvaW50IG91dCB0 aGF0IG9uIGEgZ2l2ZW4gSVB2NiBsaW5rIHRoZXJlIGFyZSB0eXBpY2FsbHkgbWFueSBJUCBzdWJu ZXRzIHNpbXVsdGFuZW91c2x5LiBJbiBteSBob21lIG5ldHdvcmsgY29ubmVjdGVkIHZpYSBicm9h ZGJhbmQgdG8gYSBiaWcgVGVsQ28gSSBoYXZlIGZvdXIgSVB2NiBzdWJuZXQgc2ltdWxhdGVub3Vz bHk6IGZpcnN0LCB0aGUgb2J2aW91cyBmZTgwOjovMTAgbGluay1sb2NhbCBzdWJuZXQ7IG5leHQs IG15IG93biBpbnRlcm5hbGx5IHN0YWJsZSBhZGRyZXNzZXMgY29taW5nIGZyb20gb25lIG9mIHRo ZSBtYW55IGZkMDA6Oi84IFVMQSBzdWJuZXRzOyB0aGVuIGEgZ2xvYmFsIHByZWZlcnJlZCBJUHY2 IHN1Ym5ldDsgYW5kIGZpbmFsbHkgYSBkZXByZWNhdGVkIElQdjYgc3VibmV0IHRoYXQgaXMgZHVl IHRvIHRoZSBvdmVybGFwcGluZyByb2xsaW5nIHN1Ym5ldCBhZGRyZXNzZXMgd2UgZ2V0IG92ZXIg aGVyZSB3aXRoIHRob3NlICJBbGwtSVAiIGJyb2FkYmFuZCBhY2Nlc3MuDQoNClNvIGluIElQdjYg dGVycml0b3J5IHdlIG9mdGVuIGNhbiBzZWUgbXVsdGlwbGUgSVB2NiBzdWJuZXRzIGJvdW5kIHRv IHRoZSBzYW1lIElQdjYgbGluay4gQWdyZWVkLCAicGh5c2ljYWwiIGRvZXNuJ3QgbmVlZCB0byBh cHBseSwgYXMgdGhlc2UgbWF5IGJlIHZpcnR1YWwgbGlua3MsIHN1Y2ggYXMgSUVFRSA4MDIgVkxB TnMuDQoNCisrKysNClNlY3Rpb24gNSAxc3QgcGFyYWdyYXBoDQo9PT09PT09PT09PT09PT09PT09 PT09PQ0KCSJGb3IgdGhpcyByZWFzb24sIGVhY2ggcGh5c2ljYWwgbGluayBtYXkgaGF2ZSAqdHdv KiB1bnJlbGF0ZWQgIi5sb2NhbC4iIHpvbmVzLCBvbmUgZm9yIElQdjQgYW5kIG9uZSBmb3IgSVB2 Ni7igJ0NCglUaGUgd29yZCDigJxwaHlzaWNhbOKAnSBpcyB1c2VkIGFnYWluIGhlcmUgYnV0IEkg d291bGQgcHJlZmVyIHRvIHNlZSBJUCBzdWJuZXQgb3IganVzdCBsaW5rIHdpdGhvdXQgdGhlIOKA nHBoeXNpY2Fs4oCdIHNpbmNlIHlvdSBkZWZpbmVkIHdoYXQgbGluayBtZWFudC4NCisrKysNCg0K SSB3b3VsZCBsaWtlIHRvIGFzayBmb3IgImxpbmsiIChhcyBpbiAiSVB2NiBsaW5rIiBhcyB3ZSBo YXZlIGEgZGVmaW5pdGlvbiBmb3IgdGhhdCB0ZXJtIGluIHRoZSBSRkNzKSBmb3IgdGhlIHJlYXNv bnMgb3V0bGluZWQgYWJvdmUuDQoNCg0KV2l0IGJlc3QgcmVnYXJkcywNCkhhcmFsZA0KDQpTaWVt ZW5zIEFHDQpHbGVpd2l0emVyIFN0ci4gNTU1DQo5MDQ3NSBOdWVybmJlcmcsIEdlcm1hbnkgDQoN ClNpZW1lbnMgQWt0aWVuZ2VzZWxsc2NoYWZ0OiBDaGFpcm1hbiBvZiB0aGUgU3VwZXJ2aXNvcnkg Qm9hcmQ6IEdlcmhhcmQgQ3JvbW1lOyBNYW5hZ2luZyBCb2FyZDogSm9lIEthZXNlciwgQ2hhaXJt YW4sIFByZXNpZGVudCBhbmQgQ2hpZWYgRXhlY3V0aXZlIE9mZmljZXI7IFJvbGFuZCBCdXNjaCwg TGlzYSBEYXZpcywgS2xhdXMgSGVsbXJpY2gsIEphbmluYSBLdWdlbCwgU2llZ2ZyaWVkIFJ1c3N3 dXJtLCBSYWxmIFAuIFRob21hczsgUmVnaXN0ZXJlZCBvZmZpY2VzOiBCZXJsaW4gYW5kIE11bmlj aCwgR2VybWFueTsgQ29tbWVyY2lhbCByZWdpc3RyaWVzOiBCZXJsaW4gQ2hhcmxvdHRlbmJ1cmcs IEhSQiAxMjMwMCwgTXVuaWNoLCBIUkIgNjY4NDsgV0VFRS1SZWcuLU5vLiBERSAyMzY5MTMyMg0K DQoNCg== From nobody Wed Apr 15 01:36:31 2015 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 1326D1B3304 for ; Wed, 15 Apr 2015 01:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 nGqrHRDYGn3Q for ; Wed, 15 Apr 2015 01:36:25 -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 B21A01B331E for ; Wed, 15 Apr 2015 01:34:39 -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 t3F8YbjQ012401 for ; Wed, 15 Apr 2015 10:34:38 +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 t3F8YZTP022501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 15 Apr 2015 10:34:37 +0200 Received: from DEFTHW99ERDMSX.ww902.siemens.net (139.22.70.69) by DEFTHW99ERGMSX.ww902.siemens.net (139.22.70.132) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 15 Apr 2015 10:34:35 +0200 Received: from DEFTHW99EK5MSX.ww902.siemens.net ([169.254.6.44]) by DEFTHW99ERDMSX.ww902.siemens.net ([139.22.70.69]) with mapi id 14.03.0235.001; Wed, 15 Apr 2015 10:34:35 +0200 From: "Albrecht, Harald" To: "dnssd@ietf.org" Thread-Topic: Multicast DNS (mDNS) Threat Model and Security Consideration Thread-Index: AdB3Urb/OENoIy4+TgutqQVzjjyumg== Date: Wed, 15 Apr 2015 08:34:33 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.22] Content-Type: multipart/alternative; boundary="_000_E36F274013087B4EA05E08EB503750390BF63956DEFTHW99EK5MSXw_" MIME-Version: 1.0 Archived-At: Subject: [dnssd] Multicast DNS (mDNS) Threat Model and Security Consideration 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, 15 Apr 2015 08:36:30 -0000 --_000_E36F274013087B4EA05E08EB503750390BF63956DEFTHW99EK5MSXw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, just came across a few minor things in the DNSSD I-D "Multicast DNS (mDNS) = Threat Model and Security Consideration" -02. In section 3.2.2, second scenario the term "Time To Leave" for TTL should b= e "Time To Live" instead (http://en.wikipedia.org/wiki/Domain_Name_System#D= NS_resource_records). Albeit I have to admit that "time to leave" has a ver= y nice ring :) In section 3.3.1 you write "[...] these services may automatically announce= over mDNS both Universal Local Addresses (ULA) [RFC4193] and Global Unicas= t Addresses (GUA). Since a GUA address is global, the associated node may b= ecome accessible over the Internet." I think that the second GUA reference = should be to ULAs instead, that is, "Since a ULA address is global [...]". Another thing that strikes me is the use of "GUA address" and "ULA address"= . The "A" in "GUA" and "ULA" already means address, so "GUA address" basica= lly means a "global unicast address address". Either a sole "GUA"/"ULA" is = already sufficient or always spell "global unicast address" in full. With respect to section 3.7.1 "Storing mDNS names in unicast DNS" I wonder = if there are attacks possible based on leaking UTF-8 labels into unicast DN= S and thus upsetting either DNS servers, (stub) resolvers, and IDNA librari= es? In section 3.13.4.1 what is the security standpoint rationale to not publis= h GUAs? For instance, if a site decides to not use ULAs but only GUAs (beli= eve me, there are such huge sites in IPv4 that run their company intranet o= n global addresses, not on private ones) then this would not be less secure= than using ULAs. Some moments before the draft argues with respect to ULA = accessibility. The same also applies to GUAs. Not publishing something does= n't mean it's not reachable - this would be a perfect example of security b= y obscurity. And security by obscurity is known to not offer any security a= t all. So, please detail the rationale behind 3.13.4.1 and it focusing on U= LA only. Best regards, Harald Albrecht Siemens AG Digital Factory Division Gleiwitzer Str. 555 90475 Nuernberg, Germany Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Crom= me; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Off= icer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Siegfried Rus= swurm, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Comm= ercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE= -Reg.-No. DE 23691322 --_000_E36F274013087B4EA05E08EB503750390BF63956DEFTHW99EK5MSXw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
just came across a few minor things in the DNSSD I-D “Multicast = DNS (mDNS) Threat Model and Security Consideration” -02.
&nbs= p;
In section 3.2.2, second scenario the term “Time To Leave”= for TTL should be “Time To Live” instead (http://en.wikipedia.org/wiki/Domain_Name_System#DNS_resource_reco= rds). Albeit I have to admit that “time to leave” has a very nice rin= g :)
&nbs= p;
In section 3.3.1 you write “[…] these services may automat= ically announce over mDNS both Universal Local Addresses (ULA) [RFC4193] an= d Global Unicast Addresses (GUA). Since a GUA address is global, the associ= ated node may become accessible over the Internet.” I think that the second GUA reference should be to ULAs instead, that is, &= #8220;Since a ULA address is global […]”.
 
Another thing that strikes me is the use of “GUA address” = and “ULA address”. The “A” in “GUA” and= “ULA” already means address, so “GUA address” basi= cally means a “global unicast address address”. Either a sole &= #8220;GUA”/”ULA” is already sufficient or always spell “global unicast address” in full.
&nbs= p;
With respect to section 3.7.1 “Storing mDNS names in unicast DNS= ” I wonder if there are attacks possible based on leaking UTF-8 label= s into unicast DNS and thus upsetting either DNS servers, (stub) resolvers,= and IDNA libraries?
&nbs= p;
In section 3.13.4.1 what is the security standpoint rationale to not p= ublish GUAs? For instance, if a site decides to not use ULAs but only GUAs = (believe me, there are such huge sites in IPv4 that run their company intra= net on global addresses, not on private ones) then this would not be less secure than using ULAs. Some mome= nts before the draft argues with respect to ULA accessibility. The same als= o applies to GUAs. Not publishing something doesn’t mean it’s n= ot reachable – this would be a perfect example of security by obscurity. And security by obscurity is known to not offer a= ny security at all. So, please detail the rationale behind 3.13.4.1 and it = focusing on ULA only.
&nbs= p;
Best regards,
Harald Albrecht
 
Siemens AG
Digital Factory Division
Gleiwitzer Str. 555
90475 Nuernberg, Germany
 
Siemens Aktiengesellsc= haft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Jo= e Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Li= sa Davis, Klaus Helmrich, Janina Kugel, Siegfried Russwurm, Ralf P. Thomas; Registered offices: Berlin and Munich, = Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, H= RB 6684; WEEE-Reg.-No. DE 23691322
&nbs= p;
&nbs= p;
&nbs= p;
 --_000_E36F274013087B4EA05E08EB503750390BF63956DEFTHW99EK5MSXw_-- From nobody Wed Apr 15 13:38:32 2015 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 1014A1A8A7D for ; Wed, 15 Apr 2015 13:38:32 -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 l7SEKUnF_EBZ for ; Wed, 15 Apr 2015 13:38:30 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id B1B621A8A79 for ; Wed, 15 Apr 2015 13:38:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 6889C1063A for ; Wed, 15 Apr 2015 20:38:29 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMwHYpM_5bMf for ; Wed, 15 Apr 2015 20:38:28 +0000 (UTC) Received: from mx2.yitter.info (unknown [IPv6:2601:6:8c80:55dd:54f7:514:1570:d794]) by mx2.yitter.info (Postfix) with ESMTPSA id 7C6661062A for ; Wed, 15 Apr 2015 20:38:28 +0000 (UTC) Date: Wed, 15 Apr 2015 16:38:26 -0400 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20150415203825.GT1359@mx2.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnssd] Hybrid Proxy configuration & deployment draft 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, 15 Apr 2015 20:38:32 -0000 On Fri, Apr 10, 2015 at 09:53:55PM -0400, Tom Pusateri wrote: > > > I think 3.1 #2 was somewhat controversial? At least I vaguely remember that from Dallas. Perhaps mentioning something about that would be useful. > > Yes, Andrew Sullivan mentioned at the microphone that reverse records have fallen out of favor. From the context, I gathered he was referring to PTR records for hostnames (the inverse of A and AAAA records). This is certainly true for AAAA. But I’m not sure this applies to specialized PTR records for infrastructure such as the hybrid proxy. This is specified in section 11 of RFC 6763 and is simply a way to configure things for a campus all in one place and I don’t think the same negative connotation of PTR records applies in all cases. Maybe Andrew could chime in and expand? > I think you're right. My dim memory (and I'm sorry, by Dallas was a bit of a whirlwind) tells me that the discussion left me thinking you were going to be able to do forward-reverse matching in order to get some kind of assurance of something. The only point that I was trying to make is that the reverse tree is not that reliable. PTR records in general work just fine, and certainly if you're setting up SD you can use them and the'll work. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Apr 16 13:46:07 2015 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 B65551B36BD for ; Thu, 16 Apr 2015 13:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-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 ZRBNv4SXZYAz for ; Thu, 16 Apr 2015 13:46:02 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ADC31B36A0 for ; Thu, 16 Apr 2015 13:46:02 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id A3B5425CA274; Thu, 16 Apr 2015 20:45:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4SaBiLMrQZU; Thu, 16 Apr 2015 22:45:57 +0200 (CEST) Received: from kopoli (p5DCC6085.dip0.t-ipconnect.de [93.204.96.133]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 2AEA725CA22A; Thu, 16 Apr 2015 22:45:57 +0200 (CEST) From: "Hosnieh Rafiee" To: "'Albrecht, Harald'" References: In-Reply-To: Date: Thu, 16 Apr 2015 22:45:51 +0200 Message-ID: <002a01d07886$54cf31c0$fe6d9540$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH88HqhcGrpppT3rde6MaTcSsoJApz3G1bQ Content-Language: en-us Archived-At: Cc: dnssd@ietf.org Subject: Re: [dnssd] Multicast DNS (mDNS) Threat Model and Security Consideration 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, 16 Apr 2015 20:46:05 -0000 Hi Harald, Thanks a lot for your comments and deep review. I will apply them in next version. > > Hi, > > just came across a few minor things in the DNSSD I-D "Multicast DNS (mDNS) > Threat Model and Security Consideration" -02. > > In section 3.2.2, second scenario the term "Time To Leave" for TTL should be > "Time To Live" instead > (http://en.wikipedia.org/wiki/Domain_Name_System#DNS_resource_records > > ). Albeit I have to admit that "time to leave" has a very nice ring :) OMG... it made me smile too... what a funny mistake I did.. :-) . > > In section 3.3.1 you write "[.] these services may automatically announce > over mDNS both Universal Local Addresses (ULA) [RFC4193] and Global > Unicast Addresses (GUA). Since a GUA address is global, the associated node > may become accessible over the Internet." I think that the second GUA > reference should be to ULAs instead, that is, "Since a ULA address is global > [.]". True if the router is not configured to not route ULAs by default. I guess I have a lot of nits in this version... Unique Local addresses... (you're right universal and global are the same..) > Another thing that strikes me is the use of "GUA address" and "ULA address". > The "A" in "GUA" and "ULA" already means address, so "GUA address" > basically means a "global unicast address address". Either a sole "GUA"/"ULA" > is already sufficient or always spell "global unicast address" in full. True! > With respect to section 3.7.1 "Storing mDNS names in unicast DNS" I wonder if > there are attacks possible based on leaking UTF-8 labels into unicast DNS and > thus upsetting either DNS servers, (stub) resolvers, and IDNA libraries? I think it is possible to fool a human with different similar characters (possible phishing) in case a DNS server also accepts non-ASCII chars. But not sure this can make any problem for a DNS server itself when the DNS implementation checks the exact matching of a query name. So, this really depends on the implementation of a DNS server. > In section 3.13.4.1 what is the security standpoint rationale to not publish > GUAs? For instance, if a site decides to not use ULAs but only GUAs (believe > me, there are such huge sites in IPv4 that run their company intranet on > global addresses, not on private ones) then this would not be less secure than > using ULAs. Some moments before the draft argues with respect to ULA > accessibility. The same also applies to GUAs. Not publishing something doesn't > mean it's not reachable - this would be a perfect example of security by > obscurity. And security by obscurity is known to not offer any security at all. > So, please detail the rationale behind 3.13.4.1 and it focusing on ULA only. > Maybe for a website, it is less critical to separate the local and global. However, many companies make their high critical resources only available internally to make the risk lower. I think for services (like printer, fax, etc.) in the network it is critical to consider a clear scope. The scope can be also global but might be limited to only a certain range of external IP addresses. This is, of course, what might not be possible to define in the service itself, but in the security devices of a network that offers this service (like a firewall, or even a router to only route certain range of external IP to a service or not route the service responses to certain range of IP addresses), this is possible. This is because there might be high risk, if the range of IPv6 addresses is already known or there is available method to know which IPv6 address is in use in a target network. This gives an attacker a possibility to gain access to , e.g., a fax machine and sends his own faxes with the cost of others! . Although the fax machine is considered to have an access list but usually such devices have a low memory and very light OS that might support weak security. Unfortunately, such devices also might support a web user interface that even might not support SSL protocol... so attractive for an attacker! When the IP address is local and it is not routed outside of its local range, then the risk of attacks on a service is lower. Because an attacker needs to be in the exact local network of this service so that it can abuse this service. this is more difficult than when considering the case that an attacker is located in his own home or a coffeenet close to his home and tries to find a free fax machine on a internet. So what I would like to highlight here is that the definition of scope is really important. When the scope is smaller the chance of attack is lower. When ULA are not routable then the attack is limited to only local nodes, when the service uses GUAs then the chance of attack is higher because it might allow all over the internet to attack a service in a network. I hope I could answer your questions. Thanks again, Best, Hosnieh From nobody Thu Apr 16 16:23:23 2015 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 A34451B382B for ; Thu, 16 Apr 2015 16:23:21 -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 PpK2IdGBfLcm for ; Thu, 16 Apr 2015 16:23:20 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07BBD1B3825 for ; Thu, 16 Apr 2015 16:23:19 -0700 (PDT) Received: from [172.16.25.123] (69-77-155-151.static.skybest.com [69.77.155.151]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id A62C118DE6; Thu, 16 Apr 2015 19:22:34 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_EF731FC1-2602-4A68-BC4B-B0C115181E75"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Tom Pusateri In-Reply-To: Date: Thu, 16 Apr 2015 19:23:16 -0400 Message-Id: References: To: "Albrecht, Harald" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "dnssd@ietf.org" Subject: Re: [dnssd] Review of draft-ietf-dnssd-hybrid-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, 16 Apr 2015 23:23:21 -0000 --Apple-Mail=_EF731FC1-2602-4A68-BC4B-B0C115181E75 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the clarification Harald. For reference, "on-link" for IPv6 is defined in RFC 4861 Section 2.1 and = updated by RFC 5942 Section 3. For IPv4, Section 3.3.1.1 of RFC 1122 calls this a "connected = network=E2=80=9D. I think =E2=80=9Con-link=E2=80=9D may be the right term to use. But it = may have to be defined for IPv4. Tom > On Apr 13, 2015, at 4:06 AM, Albrecht, Harald = wrote: >=20 > Just a minor note, please see below: >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: dnssd [mailto:dnssd-bounces@ietf.org] Im Auftrag von Tom Pusateri >=20 > ++++ > Section 3 1st paragraph > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > After describing in the previous section what is meant by =E2=80=9C= on the same link=E2=80=9D, Section 3 says unicast DNS domain names are = assigned to "each physical link=E2=80=9D. The word physical should be = removed. Another way to say this may to use =E2=80=9Ceach IP subnet=E2=80=9D= which could be included in section 2 as well. > ++++ >=20 > =46rom the IPv6 perspective I would like to point out that on a given = IPv6 link there are typically many IP subnets simultaneously. In my home = network connected via broadband to a big TelCo I have four IPv6 subnet = simulatenously: first, the obvious fe80::/10 link-local subnet; next, my = own internally stable addresses coming from one of the many fd00::/8 ULA = subnets; then a global preferred IPv6 subnet; and finally a deprecated = IPv6 subnet that is due to the overlapping rolling subnet addresses we = get over here with those "All-IP" broadband access. >=20 > So in IPv6 territory we often can see multiple IPv6 subnets bound to = the same IPv6 link. Agreed, "physical" doesn't need to apply, as these = may be virtual links, such as IEEE 802 VLANs. >=20 > ++++ > Section 5 1st paragraph > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > "For this reason, each physical link may have *two* unrelated = ".local." zones, one for IPv4 and one for IPv6.=E2=80=9D > The word =E2=80=9Cphysical=E2=80=9D is used again here but I = would prefer to see IP subnet or just link without the =E2=80=9Cphysical=E2= =80=9D since you defined what link meant. > ++++ >=20 > I would like to ask for "link" (as in "IPv6 link" as we have a = definition for that term in the RFCs) for the reasons outlined above. >=20 >=20 > Wit best regards, > Harald >=20 > Siemens AG > Gleiwitzer Str. 555 > 90475 Nuernberg, Germany >=20 > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard = Cromme; Managing Board: Joe Kaeser, Chairman, President and Chief = Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina = Kugel, Siegfried Russwurm, Ralf P. Thomas; Registered offices: Berlin = and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB = 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 >=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_EF731FC1-2602-4A68-BC4B-B0C115181E75 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJVMERlAAoJEPk0GMVmUuYMwJQIAJNadCud3F3ELjg5YulD+7Sr Ev175p2co/gOrp/Wa1IrdQ/4P0GB0Yoj1nuJSwpbZkrujhBQNs+VcOFqJh+HCqN5 gsaMaYSqRgfR+s1drxxihvWGQnOoqfHOnY2m2ZoimX1tUg3e322u7B2Wa04DSqbb CDuvJxsUo6nj6lDEIjfK+jJAI6SExuhQREdTYmx1UfEKK7ZdVyBxU1zp7VFgoEpc Jt94yZ2TNvZimIQgKHvP+eOE1kCjZc4SfZ8B7FYsBaaaduSerVgTCTLqv4eXaAJU WEJmTKxStnPvCPBCt0cFUONd/zd8I0CRJttcZKuFaa7oDN5NntsoC1HvB+l0ck4= =06i6 -----END PGP SIGNATURE----- --Apple-Mail=_EF731FC1-2602-4A68-BC4B-B0C115181E75--