From nobody Fri Aug 1 06:16: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 971EB1A0B13 for ; Fri, 1 Aug 2014 06:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.653 X-Spam-Level: ** X-Spam-Status: No, score=2.653 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_06_12=1.543, HOST_MISMATCH_NET=0.311, 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 tvsf5q4SoseU for ; Fri, 1 Aug 2014 06:15:57 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) by ietfa.amsl.com (Postfix) with ESMTP id 6416B1A0B03 for ; Fri, 1 Aug 2014 06:15:57 -0700 (PDT) Received: from sandelman.ca (unknown [209.87.249.16]) by relay.sandelman.ca (Postfix) with ESMTPS id 7CA44220AF; Fri, 1 Aug 2014 09:15:56 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9D0AACA0F2; Fri, 1 Aug 2014 02:30:43 -0400 (EDT) From: Michael Richardson To: "Albrecht, Harald" In-reply-to: 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> Comments: In-reply-to "Albrecht, Harald" message dated "Fri, 25 Jul 2014 07:21:15 -0000." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.4.1 Date: Fri, 01 Aug 2014 02:30:43 -0400 Message-ID: <18120.1406874643@sandelman.ca> Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/zxHeTD38dOPBXDAXxSi-AiyACi4 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, 01 Aug 2014 13:16:02 -0000 I agree that the three printer example is contrived. 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 From nobody Fri Aug 1 06:16:21 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 044DF1A8BB0 for ; Fri, 1 Aug 2014 06:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.653 X-Spam-Level: ** X-Spam-Status: No, score=2.653 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_06_12=1.543, HOST_MISMATCH_NET=0.311, 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 sNAgORkGFwE8 for ; Fri, 1 Aug 2014 06:16:02 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) by ietfa.amsl.com (Postfix) with ESMTP id 70E1D1A0B06 for ; Fri, 1 Aug 2014 06:15:57 -0700 (PDT) Received: from sandelman.ca (unknown [209.87.249.16]) by relay.sandelman.ca (Postfix) with ESMTPS id 93CDF220B2; Fri, 1 Aug 2014 09:15:56 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 97591CA0F3; Fri, 1 Aug 2014 02:31:05 -0400 (EDT) From: Michael Richardson To: "Albrecht\, Harald" In-reply-to: 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> Comments: In-reply-to "Albrecht, Harald" message dated "Fri, 25 Jul 2014 07:21:15 -0000." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 01 Aug 2014 02:31:05 -0400 Message-ID: <18172.1406874665@sandelman.ca> Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/zGSXlk7bCydE-QT4zkz5r6EPniU 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, 01 Aug 2014 13:16:08 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I agree that the three printer example is contrived. 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 brok= en >> 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 concern= s, >> 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 mo= re > 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 proble= ms > 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 GU= As > aren't bad in any way ... unless there is general suspicion that GUAs > are bad in any case...? > With best regards, Harald =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJT2zQnAAoJEKD0KQ7Gj3P2rhAH/01xG6FWNoSe/rPpWwoEjw3D kX2R4NwdtG1/xkxBxl7Ci0MT1oVfRmDlNo+ExjdcXi0kgcMIMZWIrnJfwANqDMld xBFz3zaeiuoup42agIKfe/nreXe7/juj3s4vCBmGhmzUR3kKDu/qfTV7qLFzvPSL Thbb+FvYzVZF7UOYv02Fp5o4MwDfkVap1i0NB5Ndmo+vKM5SuxFmvzvplwApjnzU dzzPkrw2JqFzyER5akE+1InrvD8G8zP8prnVvGxFPXEBAaXtpmx8LdHvGClJVEn3 vluFFhDQjacfz8fWrqDsGAzUsRDVzBI+KjhKFi44M3gvJTsUj0/wsMcPrtq/DuU= =3BSg -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 6 07:35: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 43A111B279D for ; Wed, 6 Aug 2014 07:35:46 -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 KP8hgBV1g2du for ; Wed, 6 Aug 2014 07:35:44 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6BB1B2D57 for ; Wed, 6 Aug 2014 07:35:30 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id j15so2559175qaq.11 for ; Wed, 06 Aug 2014 07:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version; bh=xcId4zj+kZIzV3b2yoLFGnLwra5reAGk0u6/R32/W0E=; b=skQca90oZ0IY2nm7XIDWKkUUNxRRpCRVUq7p76QnSvDzI+e3XqE/cRu5GQuBixCRLB Hzshz59saS13TNYuUkmrcrqSGipDVv7YuVURHnd2WSLos9GwVKKibDp9YOXbPzAIm0db Un3WgeZIUZhUANBV7f+7NaRXCwmL0OSv+YPFNNPXYbqeMm2K89Jrjx7PrG7kU8X/LKga FM98PYio+Pr2QYzu1lwHM98tB9GAkFX9cqQHBX/+iUCqvtfMPjt9grIudwc/uZby+xCC 0KAU+qXgfiVQMVU/0njPhPVV4t/yHaXbrpBUGjdnmUIAtecu0QVUEDIHK41mqqNwL3bF WYkQ== X-Received: by 10.140.89.197 with SMTP id v63mr4002109qgd.71.1407335729712; Wed, 06 Aug 2014 07:35:29 -0700 (PDT) Received: from [10.30.20.8] (pool-173-79-6-58.washdc.fios.verizon.net. [173.79.6.58]) by mx.google.com with ESMTPSA id g35sm1165142qgf.49.2014.08.06.07.35.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 07:35:29 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 6 Aug 2014 10:35:29 -0400 To: dnssd@ietf.org Message-Id: <2DE538CD-E5F8-496A-B060-452C9FF435F7@gmail.com> Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/SuqcVrghLMfMRrDkIqsm0vpN9dU Subject: [dnssd] Feedback on 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, 06 Aug 2014 14:35:46 -0000 I apologise for the tardiness of this note. I have tried to organise this note following the sequence (e.g. pages, sections) of the I-D. Many of my comments are informed from Toronto WG time, numerous Toronto hallway discussions, and WG list discussions. I apologise that I often don't recall precisely who suggested which idea. Many of the ideas below arose from others and the note below is merely my formulation of an idea that originated in someone else's head. Yours, Ran Atkinson Section 1, paragraph 3: The 2nd sentence, which begins "Wireless networks...", is misleading at present. It could cause someone to erroneously believe that most types of wireless links and networks do not support multicasting efficiently. In fact, for most wireless link technologies, the link is natively broadcast (not only at the physical layer, but also at the link layer) making broadcast/multicast traffic much more efficient than unicast traffic. For MANET networking, the IETF has actually already defined mechanisms for handling IP multicasting well (e.g. RFC-6621). The paragraph could be edited a bit to make it clear that while there are wireless links with these issues, there are also many other wireless link technologies that work most efficiently with multicast/broadcast traffic. So, I propose to edit this paragraph to read instead: "mDNS in its present form is also not optimized for network technologies where multicast transmissions are relatively expensive. For most wireless link technologies, multicast and broadcast traffic is much more efficient than unicast traffic. However, some wireless networks, for example [IEEE.802.11], have a higher network overhead for multicast transmissions. For IEEE 802.11, this is a result of design choices made in the design of that MAC layer. Some wireless mesh networks, for example 6LoWPAN [RFC4944] are effectively multi-link subnets [RFC4903] where multicasts must be forwarded by intermediate nodes." Section 1.2: Consistent with Tim Chown's note from 29th July to the dnssd mailing list, please define these additional terms and also examine the whole I-D to use the newly defined terms to clarify intended meanings: - "discoverable service" - "reachable service" - "usable service" Section 2.1, paragraph 1: It would be helpful if the text more clearly indicated that the issues being summarised here are those from the Educause petition (as different from being generated within the IETF). We should give credit where due, and also differentiate them crisply from the Section 3 IETF requirements. Proposed Edit: s/The following is a summary of the technical issues/ The following is a summary of their technical issues/ Section 2.1, page 4: Another edit of the same type, for the same reason, as the above. Proposed Edit: s/The following is a summary of the technical requirements/ The following is a summary of their technical requirements/ Section 2.2, paragraph 1: As was true in Section 1, this section is unclear and seems to imply that non-efficient multicasting is typically true for a wireless technology, when actually the opposite is true for most wireless technologies. I propose to make slight edits to clarify this. Proposed Edit: s/In IEEE 802.11 networks however,/ However, unlike many other wireless link technologies, in IEEE 802.11 networks,/ Section 2.2, paragraph 2: All this talk of reliability might lead one to believe that wired Ethernet, wireless Ethernet, and IP are reliable. However, each is defined to provide an unreliable datagram service. Proposed new text to be appended to the end of this paragraph: "Of course, wired Ethernet, wireless Ethernet [IEEE 802.11], and the Internet Protocol (IP) are all defined to provide an unreliable datagram service." Section 3, Use case (C): For clarity and consistency, this should be edited: s/small business network/Small enterprise network/. Section 3, Use case (D): For clarity and consistency, this should be edited: s/Enterprise networks/Large enterprise networks/ Section 4, REQ3: Minor proposed edit to add clarifying examples: s/physical proximity/physical proximity (e.g. building)/ s/organisational structure/organisational structure (e.g. marketing, engineering)/ Section 4, REQ9: Optimising DNS-SD for any specific link-layer is objectionable, as I noted previously on the dnssd list. If optimisations are useful for particular link types (e.g. 802.11), then those optimisations ought to be confined to devices that implement 802.11 rather than impacting all deployed link types. Proposed Replacement Text: "SSD should operate efficiently in all networks." Section 4, REQ10: I don't know what this means and don't understand how it is trying to impact the WG's future engineering efforts. Section 4, Proposed New Requirement: I would like to make more explicit that any link-specific optimisations ought to be confined to devices that implement that type of link. Accordingly, I propose REQ15 below. Proposed New Text: "REQ15: Any link-specific optimisations for DNS-SD should be defined in separate specification documents and should be applicable only to devices that implement that specific link type." Section 6.3, paragraph 1: I find the first sentence of this paragraph awkward and its (very precise) meaning hard to understand. I think that many non-native readers of English will find this confusing. Please try to rephrase this, possibly making more clear the difference -- in a DNS context -- between "validity" and "veracity". It might be sufficient to add an example or two immediately after this first sentence. Section 6, page 9: Based on list discussion, I would suggest adding a new subsection immediately after sub-section 6.4 that discusses "Access Control". Some rapid candidate text follows; please edit to taste: "6.5 Access Control Access Control refers to the ability to restrict which users are able to use a particular service that might be advertised via DNS-SD. In this case, "use" of a service is different from the ability to "discover" or "reach" a service. [Ed: please recall to my suggested edit to Section 1.2] While access control to an advertised service is outside the scope of DNS-SD, we note that access control today often is provided by existing site infrastructure (e.g. router access control lists, firewalls) and/or by service-specific mechanisms (e.g. user authentication to the service). For example, many networked printers already support access controls via a user-id and password. At least one widely deployed DNS-SD + mDNS implementation supports such access controls for printers. So the reliance on existing service-specific security mechanisms (i.e. outside the scope of DNS-SD) does not create new security considerations." Section 6.5: The existing discussion is good, but the exact same issue arises with laptop computers, tablets, and so forth. Purely as an example, at the Toronto IETF a number of laptops were advertising on-link sharing of their music libraries via existing DNS-SD + mDNS. EOF