IETF Logo Mail Archive

Re: [dnssd] Security through Obscurity

"Kennedy, Smith (Wireless Architect)" <smith.kennedy@hp.com> Fri, 25 July 2014 15:06 UTC

Return-Path: <smith.kennedy@hp.com>
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 <dnssd@ietfa.amsl.com>; 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 <dnssd@ietfa.amsl.com>; 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 <dnssd@ietf.org>; 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)" <smith.kennedy@hp.com>
To: "Albrecht, Harald" <harald.albrecht@siemens.com>
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> <EMEW3|faec94f4ff05bea449f9614b93dae254q6NE8Q03tjc|ecs.soton.ac.uk|0E0BC226-E68E-4BC2-99EA-AFF1AF96A5EC@ecs.soton.ac.uk> <E6F68BE4-7094-45AA-ADD9-4B88BBC87921@gmail.com> <8465FD60-84CD-41B3-BBE3-1BDB52DF0DDB@hp.com> <364AAF85-5FB4-4828-A5A4-11160E747BC9@gmail.com> <24377.1406225491@sandelman.ca> <3949.1406228928@sandelman.ca> <E36F274013087B4EA05E08EB503750390BEDE8DF@DEFTHW99EK5MSX.ww902.siemens.net>
In-Reply-To: <E36F274013087B4EA05E08EB503750390BEDE8DF@DEFTHW99EK5MSX.ww902.siemens.net>
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" <dnssd@ietf.org>, Michael Richardson <mcr@sandelman.ca>
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." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jul 2014 15:06:38 -0000

I’m 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 <harald.albrecht@siemens.com> 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

v2.23.0 | Report a Bug | By Email