Re: [dnssd] Threat model - answer to questions

Douglas Otis <doug.mtview@gmail.com> Wed, 19 November 2014 23:48 UTC

Return-Path: <doug.mtview@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 5C14C1A1B16 for <dnssd@ietfa.amsl.com>; Wed, 19 Nov 2014 15:48:52 -0800 (PST)
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 dAeh9B3BXn0Z for <dnssd@ietfa.amsl.com>; Wed, 19 Nov 2014 15:48:50 -0800 (PST)
Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 210D61A1AF3 for <dnssd@ietf.org>; Wed, 19 Nov 2014 15:48:50 -0800 (PST)
Received: by mail-qg0-f44.google.com with SMTP id z60so1358735qgd.3 for <dnssd@ietf.org>; Wed, 19 Nov 2014 15:48:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pp6syO2tU+t9NQY5rP/PGLDgClbcO0V1uTl5iR/UZXA=; b=iUj12tcxpTc9XZ9EucYeIDjjQHuyeRZxLE38i2BiVZJ2Ol7sHVF3spSz6pUQGcnnp6 Ud/lvV2Z0P5fa44JOWoHlHVXKlc9enDurhzaYnT7S7FyFkzlzFuSDdBQgnDKIbNeuXEl 4M0uX8HD3Sn44jqHtveaVqdVVNSukzFYzaQn+nOrtyCe5Mphvk61AcBqhUt3Lln5/kj4 K2JgjfsrctFOI7rMcALyfKUgMj9kibrG7Si04cV6cApiDy1ZHEGuGCp2bk6aKUQSH6ev hj4iuI7CUqW6DAoOGDZhP0NCLHKTobr2neOTUVj6GY9cGf8roxC+7ZaIPejgqbOdtOFg YCGw==
X-Received: by 10.140.30.201 with SMTP id d67mr32031224qgd.55.1416440929335; Wed, 19 Nov 2014 15:48:49 -0800 (PST)
Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id 11sm668227qab.23.2014.11.19.15.48.48 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Nov 2014 15:48:48 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: text/plain; charset="windows-1252"
From: Douglas Otis <doug.mtview@gmail.com>
In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A5E576@lhreml513-mbb.china.huawei.com>
Date: Wed, 19 Nov 2014 15:48:47 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <AD1ACD05-A7BF-44E8-AC52-9BDA756C1722@gmail.com>
References: <814D0BFB77D95844A01CA29B44CBF8A7A5E576@lhreml513-mbb.china.huawei.com>
To: Hosnieh Rafiee <hosnieh.rafiee@huawei.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/rWM3lDDXjBOKzNNk-5oJKbNTMZk
Cc: "dnssd@ietf.org" <dnssd@ietf.org>
Subject: Re: [dnssd] Threat model - answer to questions
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: Wed, 19 Nov 2014 23:48:52 -0000

On Nov 14, 2014, at 7:08 AM, Hosnieh Rafiee <hosnieh.rafiee@huawei.com> wrote:

> 5- overlay networks and SSD (Douglas)
> 
> Answer: I still do not understand what is the relationship of overlay networks to SSD. This was the case I did not know what to answer to your question. Why should we consider this? What will happen if we do not consider this?

Dear Hosnieh,

For resource constrained devices, security is best enforced by use of ULA address space defined by RFC4193.  Few CPE devices conforming with RFC7084 permit address specific exceptions for externally initiated sessions.  This limitation makes external exposure either a default accept or deny setting.  ULAs offer a means for resource constrained devices to make exceptions for traffic within its domain.  Otherwise, exclusion of all external initiated sessions might inhibit domain connectivity.

ULA is not an IPv6 version of RFC1918 address space normally combined with NAT/NAPT for Internet connectivity.  ULAs do not require translations since first hop communications can leverage IPv6’s default support of multiple-addresses-per-interface.  This permits network overlays rather than address translation techniques.  An overlay can be achieved by using centrally or locally assigned ULA prefixes (FC00::/8 or FD00::/8).  Apple currently represents the largest deployment of locally assigned ULA prefixes in their Back-to-My-Mac feature by making use of L2TP tunneling.

A ULA prefix is not to be advertised outside a given domain used by agreement of those networked within the domain. Administrators need to clearly set the scope of the ULAs and configure ACLs on relevant border routers to enforce their scope. If internal DNS is used, administrators should use internal-only DNS names for ULAs and might need to use split horizon DNS to ensure internal names do not resolve on the Internet as described in RFC6950.

To maintain security, address preference rules employed by a proxy device should properly consider use of ULAs as described by RFC7368.  Per section 2.4, a device should only use its ULA address within its domain. Even where multiple /48 ULA prefixes are in use within a single domain, as may occur when there are multiple Internet uplinks, utilizing a ULA source address and a ULA destination address from two disjoint internal ULA prefixes should still be preferred over use of GUAs.  When a device has not been specifically enabled to be externally accessible, mDNS proxy into DNS should not publish associated GUAs.

Omitting proper address selection rules is unlikely to obtain the desired security.  This consideration was omitted in both the Hybrid Proxy and Security Threat documents.  

Note: Last hop security depends on header compliance with RA Guard RFC7113. 

Regards,
Douglas Otis