Re: [dnssd] Security through Obscurity
RJ Atkinson <rja.lists@gmail.com> Thu, 24 July 2014 13:50 UTC
Return-Path: <rja.lists@gmail.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 AFA9C1A035B for <dnssd@ietfa.amsl.com>; 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 <dnssd@ietfa.amsl.com>; 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 <dnssd@ietf.org>; Thu, 24 Jul 2014 06:49:37 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id n12so2824995wgh.9 for <dnssd@ietf.org>; 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 <dnssd@ietf.org> (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 <rja.lists@gmail.com>
In-Reply-To: <EMEW3|faec94f4ff05bea449f9614b93dae254q6NE8Q03tjc|ecs.soton.ac.uk|0E0BC226-E68E-4BC2-99EA-AFF1AF96A5EC@ecs.soton.ac.uk>
Date: Thu, 24 Jul 2014 09:49:31 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <E6F68BE4-7094-45AA-ADD9-4B88BBC87921@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> <EMEW3|faec94f4ff05bea449f9614b93dae254q6NE8Q03tjc|ecs.soton.ac.uk|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." <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: 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
- [dnssd] Security through Obscurity RJ Atkinson
- Re: [dnssd] Security through Obscurity Tim Chown
- Re: [dnssd] Security through Obscurity Douglas Otis
- Re: [dnssd] Security through Obscurity Tom Pusateri
- [dnssd] Site deployment options RJ Atkinson
- Re: [dnssd] Security through Obscurity Tim Chown
- Re: [dnssd] Security through Obscurity RJ Atkinson
- Re: [dnssd] Security through Obscurity Kennedy, Smith (Wireless Architect)
- Re: [dnssd] Security through Obscurity Douglas Otis
- Re: [dnssd] Security through Obscurity RJ Atkinson
- Re: [dnssd] Security through Obscurity Michael Richardson
- Re: [dnssd] Security through Obscurity Michael Richardson
- Re: [dnssd] Security through Obscurity Albrecht, Harald
- Re: [dnssd] Security through Obscurity Michael Sweet
- Re: [dnssd] Security through Obscurity Kennedy, Smith (Wireless Architect)
- Re: [dnssd] Security through Obscurity Douglas Otis
- Re: [dnssd] Security through Obscurity Albrecht, Harald
- Re: [dnssd] Security through Obscurity Tim Chown
- Re: [dnssd] Security through Obscurity Albrecht, Harald
- Re: [dnssd] Security through Obscurity Michael Richardson
- Re: [dnssd] Security through Obscurity Michael Richardson