From nobody Mon Jun 9 21:32:42 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 A70661A03A2; Mon, 9 Jun 2014 21:32:37 -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 IE1gKMykSnS8; Mon, 9 Jun 2014 21:32:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D29E1A03B1; Mon, 9 Jun 2014 21:32:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140610043236.11492.28711.idtracker@ietfa.amsl.com> Date: Mon, 09 Jun 2014 21:32:36 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/Mo8lz7pRmzWw1RsSviG2J-s63xc Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-ietf-dnssd-requirements-02.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 10 Jun 2014 04:32:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery Working Group of the IETF. Title : Requirements for Scalable DNS-SD/mDNS Extensions Authors : Kerry Lynn Stuart Cheshire Marc Blanchet Daniel Migault Filename : draft-ietf-dnssd-requirements-02.txt Pages : 11 Date : 2014-06-09 Abstract: DNS-SD/mDNS is widely used today for discovery and resolution of services and names on a local link, but there are use cases to extend DNS-SD/mDNS to enable service discovery beyond the local link. This document provides a problem statement and a list of requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnssd-requirements-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-requirements-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 9 21:50:23 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 44E801A03C3; Mon, 9 Jun 2014 21:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 6xEcHEsPynhz; Mon, 9 Jun 2014 21:50:20 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B16D31A03C2; Mon, 9 Jun 2014 21:50:19 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id uy5so53991obc.8 for ; Mon, 09 Jun 2014 21:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=dNJbQOLOfARyXjDki6e3Jmr/qrokCJdor5PW/y8UoV8=; b=OwyV7lQDJqt43/JzTyj5hPlPy0A1vY2lNjs1MbI1kdfjNVi3ZynL9njaPf2OgQ/3zG Pe6w8w0zSlasKPoJcVrhohepeyjxY9NorJH7oStnGZyRxF8FAGvhdp4NqP7eYP+DX04q 4x+6qTP42/iZwaq8qoScpPB1fr3FeD0M8QBUdQou91b0K69JqgrJ5DTkBQBA8cefFOSO FGa3F2RdBiOQI05vBhCKTk9TXCXr5DbWeEWYG14aO50VunFLOzBczKb7v9IiGgaaQPgZ PK00Ah/d2+2MAdtV4qFHDgiAmWXuacPC5zKbHrZb9Qh41jUNupaRO8dDmlZjnPgfjlsj +iYg== MIME-Version: 1.0 X-Received: by 10.60.46.229 with SMTP id y5mr31088217oem.7.1402375819130; Mon, 09 Jun 2014 21:50:19 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.171.175 with HTTP; Mon, 9 Jun 2014 21:50:19 -0700 (PDT) In-Reply-To: <20140610043236.11492.28711.idtracker@ietfa.amsl.com> References: <20140610043236.11492.28711.idtracker@ietfa.amsl.com> Date: Tue, 10 Jun 2014 00:50:19 -0400 X-Google-Sender-Auth: bGSRCqrwg88osbs71rWK2005j0g Message-ID: From: Kerry Lynn To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=089e0153745a8a7fb504fb7410ca Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/aiIfkT3oC9wWVGhlNmO2LwF1jv0 Cc: dnssd@ietf.org, i-d-announce@ietf.org Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-requirements-02.txt 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: Tue, 10 Jun 2014 04:50:21 -0000 --089e0153745a8a7fb504fb7410ca Content-Type: text/plain; charset=UTF-8 Greetings, I have posted a new version of the Requirements Draft that addresses most of the issues raised by Dave Thaler and posted to this list on 3 March. In those cases where I did not address his comments (DT14, DT15, DT16) I did not feel I understood the point(s) well enough to generate alternate text. Any help would be appreciated. If there are any remaining issues that you feel are necessary to address before WGLC, I request that you send them along with proposed text by this Friday, 13 June. For example, how much specificity should we have regarding the definition of discovery scopes or zones in the Requirements Draft? There are two issues in particular that I would like discussion on: 1) we cite RFC 2119 but don't capitalize any of the keywords. Should we use keywords, or delete the reference to 2119? 2) Is everyone comfortable with a separate threat model document? Presumably that should be referenced in the security section of the Requirements Draft. Thanks in advance for your help, -K- On Tue, Jun 10, 2014 at 12:32 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Extensions for Scalable DNS Service > Discovery Working Group of the IETF. > > Title : Requirements for Scalable DNS-SD/mDNS Extensions > Authors : Kerry Lynn > Stuart Cheshire > Marc Blanchet > Daniel Migault > Filename : draft-ietf-dnssd-requirements-02.txt > Pages : 11 > Date : 2014-06-09 > > Abstract: > DNS-SD/mDNS is widely used today for discovery and resolution of > services and names on a local link, but there are use cases to extend > DNS-SD/mDNS to enable service discovery beyond the local link. This > document provides a problem statement and a list of requirements. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dnssd-requirements-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-requirements-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --089e0153745a8a7fb504fb7410ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Greetings,

I have posted a new version = of the Requirements Draft that addresses most of
the issues raise= d by Dave Thaler and posted to this list on 3 March. =C2=A0In those
cases where I did not address his comments (DT14, DT15, DT16) I did not<= /div>
feel I understood the point(s) well enough to generate alternate text.= =C2=A0Any help
would be appreciated.

If= there are any remaining issues that you feel are necessary to address befo= re
WGLC, I request that you send them along with proposed text by this Fr= iday,
13 June. =C2=A0For example, how much specificity should we = have regarding the
definition of discovery scopes or zones in the= Requirements Draft?

There are two issues in particular that I would like di= scussion on: 1) we cite
RFC 2119 but don't capitalize any of = the keywords. =C2=A0Should we use keywords,
or delete the referen= ce to 2119? =C2=A02) Is everyone comfortable with a separate
threat model document? =C2=A0Presumably that should be referenced in t= he security
section of the Requirements Draft.

Thanks in advance for your help, -K-



On Tue, Jun 10, 2014 at 12:32 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Extensions for Scalable DNS Service = Discovery =C2=A0Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Requ= irements for Scalable DNS-SD/mDNS Extensions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Kerry Lyn= n
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Stuart Cheshire
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Marc Blanchet
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Daniel Migault
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-dnssd-requirements-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 11 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2014-06-09

Abstract:
=C2=A0 =C2=A0DNS-SD/mDNS is widely used today for discovery and resolution = of
=C2=A0 =C2=A0services and names on a local link, but there are use cases to= extend
=C2=A0 =C2=A0DNS-SD/mDNS to enable service discovery beyond the local link.= =C2=A0This
=C2=A0 =C2=A0document provides a problem statement and a list of requiremen= ts.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnssd-requir= ements/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnssd-requirements-02<= /a>

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnssd-= requirements-02


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
dnssd mailing list
dnssd@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dnssd

--089e0153745a8a7fb504fb7410ca-- From nobody Tue Jun 10 08:59:57 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 D13CA1A01E7 for ; Tue, 10 Jun 2014 08:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 P9gIshnUvvLE for ; Tue, 10 Jun 2014 08:59:52 -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 88B261A01DF for ; Tue, 10 Jun 2014 08:59:52 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 02FC656608D9 for ; Tue, 10 Jun 2014 15:59:50 +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 nYJrHb8Dm-Lc for ; Tue, 10 Jun 2014 17:59:18 +0200 (CEST) Received: from kopoli (g225041086.adsl.alicedsl.de [92.225.41.86]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 7DFA656608D8 for ; Tue, 10 Jun 2014 17:59:18 +0200 (CEST) From: "Hosnieh Rafiee" To: Date: Tue, 10 Jun 2014 17:59:15 +0200 Message-ID: <003401cf84c4$ee2c70a0$ca8551e0$@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: Ac+ExO2dOnAnRqOwTBOthbhbpxy8gg== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/49COwvnC8xk0Ckl71nvAyQN6TqQ Subject: [dnssd] threat model - do I need to 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: Tue, 10 Jun 2014 15:59:55 -0000 Hello, I will submit my final version for threat model tonight with some revisions that are the inputs from one of the reviewer (the following link doesn't reflect these revisions yet). Is there any big change in requirement document that might affect this threat model? I don't think I will have time to read it tonight to reflect those changes if any. But if there is a big change I should postpone submitting it. Thanks, Best, Hosnieh From nobody Tue Jun 10 15:31:45 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 5A0831A0328 for ; Tue, 10 Jun 2014 15:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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-ykOMKdvE9l for ; Tue, 10 Jun 2014 15:31:37 -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 070A01A0442 for ; Tue, 10 Jun 2014 15:31:31 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 0458256608D9 for ; Tue, 10 Jun 2014 22:31:28 +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 AJ_lFdUsDUit for ; Wed, 11 Jun 2014 00:30:58 +0200 (CEST) Received: from kopoli (g225041086.adsl.alicedsl.de [92.225.41.86]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 34DD256608D8 for ; Wed, 11 Jun 2014 00:30:58 +0200 (CEST) From: "Hosnieh Rafiee" To: References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> In-Reply-To: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> Date: Wed, 11 Jun 2014 00:30:55 +0200 Message-ID: <008101cf84fb$a5032c20$ef098460$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMHk5Dn0OApbj704Gp7rq+nCnqZrpj6zx3A Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/Bewd8sM8ZRDqOsnBGP5v4BmBAnA Subject: [dnssd] FW: New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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: Tue, 10 Jun 2014 22:31:43 -0000 Folks, As I've promised I sent the first version of this threat model. If you = would like to contribute (as I have already received one email), I = appreciate your help. Just contact me directly, I will give you access = to where you can also work on the source of this file. Best, Hosnieh -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Wednesday, June 11, 2014 12:26 AM To: Hosnieh Rafiee; Hosnieh Subject: New Version Notification for = draft-rafiee-dnssd-mdns-threatmodel-00.txt A new version of I-D, draft-rafiee-dnssd-mdns-threatmodel-00.txt has been successfully submitted by Hosnieh Rafiee and posted to the IETF = repository. Name: draft-rafiee-dnssd-mdns-threatmodel Revision: 00 Title: Multicast DNS (mDNS) Threat Model and Security Consideration Document date: 2014-06-10 Group: Individual Submission Pages: 11 URL: = http://www.ietf.org/internet-drafts/draft-rafiee-dnssd-mdns-threatmodel-0= 0.txt Status: = https://datatracker.ietf.org/doc/draft-rafiee-dnssd-mdns-threatmodel/ Htmlized: = http://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel-00 Abstract: This document describes threats associated with extending multicast DNS (mDNS) across layer 3. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From nobody Mon Jun 16 16:22:56 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 518711A02B8 for ; Mon, 16 Jun 2014 16:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 5rwLNZ_KQXko for ; Mon, 16 Jun 2014 16:22:53 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E714C1A02BC for ; Mon, 16 Jun 2014 16:22:52 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id w10so2274006pde.17 for ; Mon, 16 Jun 2014 16:22:52 -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:cc :message-id:references:to; bh=Mn5ujuawnipw48YUc8NJhBEyx5qhsFPnA9p79IscW0M=; b=nrt1nzdKhDcm8yJQZcEUAW7+0CC8KYHDm9ULuk48Kc6WkNbdz4Sc06SOOFoLIGFMh7 6l0iSBRS9kcbh0agwiI/Q28ueCfh3xHCYdOo+gzys9V5/cj5ba4Myazu5trUuqHseUiA YG9uhkMG7YfZMP1ZWCVzdUbw4PvWUFSwH31ccrno5V7dG9NBJKlH4lmmVj1Bynn+c07y 81vY/STCjhpRh1lwh/bkkugrYgn45aNmNqFTzw++LrsIlwuUGZdSH1xz7CLEKsTAvdrP M+0Dzi0U3wyGbo1NTWa3v8rZ+F76RegbkV6ztrlzWQLk8yQCvaiYnx2hWiowLrfATRU4 gKgw== X-Received: by 10.68.191.138 with SMTP id gy10mr8163935pbc.169.1402960972544; Mon, 16 Jun 2014 16:22:52 -0700 (PDT) Received: from ?IPv6:2601:9:7300:1510:61da:203:753c:7df1? ([2601:9:7300:1510:61da:203:753c:7df1]) by mx.google.com with ESMTPSA id ci4sm20711338pbb.50.2014.06.16.16.22.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Jun 2014 16:22:51 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_017F83BB-DC5A-48F6-B2CE-224C329928F6" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: <008101cf84fb$a5032c20$ef098460$@rozanak.com> Date: Mon, 16 Jun 2014 16:22:49 -0700 Message-Id: References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> To: Hosnieh Rafiee X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/OIIaFJigzo5oW-Qt95OMXZIB35s Cc: dnssd@ietf.org Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 16 Jun 2014 23:22:55 -0000 --Apple-Mail=_017F83BB-DC5A-48F6-B2CE-224C329928F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Hosnieh, As was stressed in the draft = http://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-03 use of mDSN = proxy into DNS requires that link-local be translated into routable IP = addresses to offer layer 3 bridging. =20 This difference removes a critical concept of local addressing needed to = support reasonable firewall protections. Many devices currently depend = on local network constraints. There are other solutions not found at = layer 3, one being Rbridge, as an example. Rbridge's support of PPP = also offers a reasonable solution for technologies lacking direct = Rbridge support. Environments not well suited for mDNS across the entire = local network can employ Rbridge to Rbridge filtering for larger = deployments. For such large scale deployments, bridge to bridge = filtering should offer a reasonable automatic mitigation strategy which = clarifies the services that will need to depend on other routing = techniques. Claims of Rbridge being unsuitable for home networks fail to overlook = reasonable deployment strategies. Claims that mDNS to DNS offers a = means to merge different network segments overlooks several serious = security limitations, some of which have been reviewed in Rafiee's = threat model. It also overlooks an inability to handle HDCP over layer = 3, a prime motivation for the Educause petition. http://support.apple.com/kb/HT4428 Although this mentions the HDMI portion of the path needing to support = HDCP, the network in essence does not permit layer 3 header changes = either. Recently, it has been a struggle to maintain OSX security due = to socially engineered privileges granted by users installing various = browser plugins having the effect of obfuscating java-script functions. = Any breach at this level can rapidly become a larger disaster when = coupled with insecure mDNS proxies.=20 Regards, Douglas Otis On Jun 10, 2014, at 3:30 PM, Hosnieh Rafiee wrote: > Folks, >=20 > As I've promised I sent the first version of this threat model. If you = would like to contribute (as I have already received one email), I = appreciate your help. Just contact me directly, I will give you access = to where you can also work on the source of this file. >=20 > Best, > Hosnieh >=20 >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Wednesday, June 11, 2014 12:26 AM > To: Hosnieh Rafiee; Hosnieh > Subject: New Version Notification for = draft-rafiee-dnssd-mdns-threatmodel-00.txt >=20 >=20 > A new version of I-D, draft-rafiee-dnssd-mdns-threatmodel-00.txt > has been successfully submitted by Hosnieh Rafiee and posted to the = IETF repository. >=20 > Name: draft-rafiee-dnssd-mdns-threatmodel > Revision: 00 > Title: Multicast DNS (mDNS) Threat Model and Security = Consideration > Document date: 2014-06-10 > Group: Individual Submission > Pages: 11 > URL: = http://www.ietf.org/internet-drafts/draft-rafiee-dnssd-mdns-threatmodel-00= .txt > Status: = https://datatracker.ietf.org/doc/draft-rafiee-dnssd-mdns-threatmodel/ > Htmlized: = http://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel-00 >=20 >=20 > Abstract: > This document describes threats associated with extending multicast > DNS (mDNS) across layer 3. >=20 >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_017F83BB-DC5A-48F6-B2CE-224C329928F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = Hosnieh,

As was stressed in the draft http://= tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-03 use of mDSN = proxy into DNS requires that link-local be translated into routable IP = addresses to offer layer 3 = bridging.
  
This difference removes a = critical concept of local addressing needed to support reasonable = firewall protections.  Many devices currently depend on local = network constraints.  There are other solutions not found at layer = 3, one being Rbridge, as an example.  Rbridge's support of PPP also = offers a reasonable solution for technologies lacking direct Rbridge = support. Environments not well suited for mDNS across the entire local = network can employ Rbridge to Rbridge filtering for larger deployments. =   For such large scale deployments, bridge to bridge filtering = should offer a reasonable automatic mitigation strategy which clarifies = the services that will need to depend on other routing = techniques.

Claims of Rbridge being unsuitable = for home networks fail to overlook reasonable deployment strategies. =  Claims that mDNS to DNS offers a means to merge different network = segments overlooks several serious security limitations, some of which = have been reviewed in Rafiee's threat model.  It also overlooks an = inability to handle HDCP over layer 3, a prime motivation for the = Educause petition.

Although this mentions the HDMI portion of the path = needing to support HDCP,  the network in essence does not permit = layer 3 header changes either.  Recently, it has been a struggle to = maintain OSX security due to socially engineered privileges granted by = users installing various browser plugins having the effect of = obfuscating java-script functions.  Any breach at this level can = rapidly become a larger disaster when coupled with insecure mDNS = proxies. 

Regards,
Douglas = Otis


On Jun 10, 2014, = at 3:30 PM, Hosnieh Rafiee <ietf@rozanak.com> = wrote:

Folks,

As I've promised I sent the first version of = this threat model. If you would like to contribute (as I have already = received one email), I appreciate your help. Just contact me directly, I = will give you access to where you can also work on the source of this = file.

Best,
Hosnieh



-----Original = Message-----
From: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]
Sent: Wednesday, June 11, 2014 12:26 AM
To: Hosnieh Rafiee; = Hosnieh
Subject: New Version Notification for = draft-rafiee-dnssd-mdns-threatmodel-00.txt


A new version of = I-D, draft-rafiee-dnssd-mdns-threatmodel-00.txt
has been successfully = submitted by Hosnieh Rafiee and posted to the IETF = repository.

Name: = draft-rafiee-dnssd-mdns-threatmodel
Revision: = 00
Title: Multicast DNS (mDNS) Threat Model = and Security Consideration
Document date: 2014-06-10
Group: = Individual Submission
Pages: 11
URL: =            http://www.ietf.org/internet-drafts/draft-rafiee-dnssd-mdns-= threatmodel-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-rafiee-dnssd-mdns-threatmodel/=
Htmlized:       http://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel-00
=

Abstract:
  This document describes threats = associated with extending multicast
  DNS (mDNS) across = layer 3.






Please note that it may take a = couple of minutes from the time of submission until the htmlized version = and diff are available at tools.ietf.org.

The IETF = Secretariat

_______________________________________________
dnss= d mailing list
dnssd@ietf.org
https://www.ietf.org/= mailman/listinfo/dnssd

= --Apple-Mail=_017F83BB-DC5A-48F6-B2CE-224C329928F6-- From nobody Tue Jun 17 08:14:26 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 8AD661A03AE for ; Tue, 17 Jun 2014 08:14:19 -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 CbHnZ8ocvsha for ; Tue, 17 Jun 2014 08:14:12 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11C121A006D for ; Tue, 17 Jun 2014 08:13:55 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id i50so97260qgf.0 for ; Tue, 17 Jun 2014 08:13:55 -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:cc :content-transfer-encoding:message-id:references:to; bh=jClbBakwMfmh1XvGpBZcNnT6SGpIyGHS9fEks6QwvLo=; b=LitQOTShKOEocYhmEvSm9dPP14bL9fqw0nfFZkf2TMuQ39kNkwAZ1xkgipNlDwRJ3P iZiFVBgh4eJLTCfuUllFYOPQGSyamlVGhMcZobcNG60JuCamLRBgbZnEpSuhK222ZOgC w85xcLhpoxf76LEYZCEtssdv+IkY0jU9LY2X4O2GpeDuqGUNsC+m0yRRjwlZsnT86jLV D8dMYgZCZHiwFkRgW+Wu5Dh+O89y70YkX5zd4AtSgSrLrxDlIjrCQfLWSlVqv3qEa9TO 7tiGOJ2wzDWLH/Ni/omSFPV2jJHOmovZDPATFYn8kiOJIaEHdy6QPJbRhySN98aSGfVA gUCQ== X-Received: by 10.224.88.66 with SMTP id z2mr21325614qal.86.1403018035272; Tue, 17 Jun 2014 08:13:55 -0700 (PDT) Received: from [10.82.101.26] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id f106sm9158309qge.8.2014.06.17.08.13.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Jun 2014 08:13:52 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ralph Droms In-Reply-To: Date: Tue, 17 Jun 2014 11:13:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> To: Douglas Otis X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/MUsC5afRSGtQLwGq1hY9XOvaTPM Cc: dnssd@ietf.org Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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: Tue, 17 Jun 2014 15:14:19 -0000 Douglas: Back on 4/4/2014, we posted e-mail to dnssd@ietf.org explaining the = position of the chairs regarding the charter of the dnssd WG and the = observation that TRILL and Rbridges are not appropriate for = consideration as a solution under the charter = (http://www.ietf.org/mail-archive/web/dnssd/current/msg00416.html). = Therefore, we specifically tell you not to bring TRILL and Rbridges up = for discussion as the solution, replacing discussion of solutions for = routed networks. Discussion along the lines of "given a TRILL deployment or other = campus/enterprise-wide L2 networks, how do we control propagation of = DNS-SD/mDNS traffic to meet security, privacy and scaling requirements" = is appropriate for the WG mailing list. For example, discussion of = security issues raised by merging mDNS and unicast DNS would be quite = appropriate and important for the the WG mailing list. - Tim and Ralph From nobody Wed Jun 18 04:47:09 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 D35501A0194 for ; Wed, 18 Jun 2014 04:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 Xucp2CMtj1i3 for ; Wed, 18 Jun 2014 04:47:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 984C71A018D for ; Wed, 18 Jun 2014 04:47:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIO30906; Wed, 18 Jun 2014 11:47:05 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Wed, 18 Jun 2014 12:47:01 +0100 From: Hosnieh Rafiee To: Ralph Droms Thread-Topic: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt Thread-Index: AQHPij6+0OApbj704Gp7rq+nCnqZrpt2wFeQ Date: Wed, 18 Jun 2014 11:47:00 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/0stxka4E91l7c1b5sbklhpCQpLo Cc: "dnssd@ietf.org" Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 18 Jun 2014 11:47:08 -0000 > For example, discussion of security issues raised by merging mDNS and uni= cast DNS would be quite appropriate and important for the the WG mailing li= st. Ralph, In the threat model document, I also covered this scenario where mDNS node = wants to update a record in unicast DNS. If folks think that it is better t= hat I expand it more, I would do it. Thank you, Best, Hosnieh From nobody Wed Jun 18 11:55:44 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 68BB61A00E1 for ; Wed, 18 Jun 2014 11:55:43 -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 lEzmJpVNRU5k for ; Wed, 18 Jun 2014 11:55:42 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AF2D1A0016 for ; Wed, 18 Jun 2014 11:55:42 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id r10so968427pdi.23 for ; Wed, 18 Jun 2014 11:55:41 -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:cc :content-transfer-encoding:message-id:references:to; bh=Am7++nZlI883w0ibxKF1LOEF1d2dPm0Ul7QAHJOjBgE=; b=PpJX5QgkTxEF6TWEJt/0HshYt6cDdSUnSYupJy0R4iuslb+osIkUMdo8s4JMx9LIHW ATjednyoW3akwyRTGfmmvN9tAzC366F3K5+tft/2NTB2YRl8gciT6K1z2dppkrJp/rlt nIIIYvdo6emcYNJTB+6a3XPioLdhcbEZ6WNyUr0bCYwkLfG982NjoHMgGGma9DH3PRw5 nD+hAjUb4m2sHoYmHkQeGsUmf1mjkJBGayllRo9wFt9wROdyGxZe4INkuKG5R+kc4uIO qpOZS4qYBq3MwOZEsMoRJj8gvjRnqNer/qmCtOo6XvBzkmZ4CEMiHEeFiRK1mBwBwMJF ILkA== X-Received: by 10.68.220.137 with SMTP id pw9mr100811pbc.24.1403117741700; Wed, 18 Jun 2014 11:55:41 -0700 (PDT) Received: from dhcp150.priv.bungi.com (c-76-21-122-217.hsd1.ca.comcast.net. [76.21.122.217]) by mx.google.com with ESMTPSA id ib5sm4679085pbb.55.2014.06.18.11.55.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Jun 2014 11:55:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> Date: Wed, 18 Jun 2014 11:55:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> To: Hosnieh Rafiee X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/MnQtEBCMTKuqMy6-JOsgGmwjmT4 Cc: "dnssd@ietf.org" , Ralph Droms Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 18 Jun 2014 18:55:43 -0000 On Jun 18, 2014, at 4:47 AM, Hosnieh Rafiee = wrote: >> For example, discussion of security issues raised by merging mDNS and = unicast DNS would be quite appropriate and important for the the WG = mailing list. >=20 > Ralph, >=20 > In the threat model document, I also covered this scenario where mDNS = node wants to update a record in unicast DNS. If folks think that it is = better that I expand it more, I would do it. Dear Hosnieh, Please greatly expand the related issues as there have been extremely = serious security concerns fully ignored in the consideration sections. 1) Converting link-local to routable addressing removes most firewall = protections. 2) Publishing addresses in DNS exposes devices that lack authentication. 3) Resolving name collisions between various network segments where = multi-interface devices connected to different segments could = potentially generate excessive traffic with mDNS's attempt to offer = rapid convergence. Perhaps something has been overlooked. There is seemingly no = consideration given that prevents this scheme from becoming a larger = problem. Can distributing recognized certificates in a zero-config fashion be = accomplished? Regards, Douglas Otis=20= From nobody Wed Jun 18 13:21:15 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 6921B1A0306 for ; Wed, 18 Jun 2014 13:21:12 -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 GUVzIWpM9YUB for ; Wed, 18 Jun 2014 13:21:11 -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 5B4E91A02F3 for ; Wed, 18 Jun 2014 13:21:10 -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 89BE910D86; Wed, 18 Jun 2014 16:21:08 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1962.2\)) From: Tom Pusateri In-Reply-To: <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> Date: Wed, 18 Jun 2014 16:21:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com> References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> To: Douglas Otis X-Mailer: Apple Mail (2.1962.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/m4eZrUbgciAtrlP2wVjSC_LMtls Cc: Hosnieh Rafiee , "dnssd@ietf.org" , Ralph Droms Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 18 Jun 2014 20:21:12 -0000 > On Jun 18, 2014, at 2:55 PM, Douglas Otis = wrote: >=20 >=20 > On Jun 18, 2014, at 4:47 AM, Hosnieh Rafiee = wrote: >=20 >>> For example, discussion of security issues raised by merging mDNS = and unicast DNS would be quite appropriate and important for the the WG = mailing list. >>=20 >> Ralph, >>=20 >> In the threat model document, I also covered this scenario where mDNS = node wants to update a record in unicast DNS. If folks think that it is = better that I expand it more, I would do it. >=20 > Dear Hosnieh, >=20 > Please greatly expand the related issues as there have been extremely = serious security concerns fully ignored in the consideration sections. >=20 > 1) Converting link-local to routable addressing removes most firewall = protections. Firewalls don't provide protections to packets that use link-local IP = addresses. Routers just don't forward them beyond the IP subnet. >=20 > 2) Publishing addresses in DNS exposes devices that lack = authentication. Devices that lack authentication have a problem with or without DNS = exposure. Service enumeration doesn't change that. Tom= From nobody Wed Jun 18 14:37:28 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 307661A016B for ; Wed, 18 Jun 2014 14:37:25 -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 AGL8fzUQQtua for ; Wed, 18 Jun 2014 14:37:23 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B911A0166 for ; Wed, 18 Jun 2014 14:37:23 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id up15so1155263pbc.20 for ; Wed, 18 Jun 2014 14:37:22 -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:cc :content-transfer-encoding:message-id:references:to; bh=KkcwmKs22HBr/dgs8zyyVnFKCYPWKYwhXSsbqWseess=; b=ImkYlxQniZiaIYFpMITfL3Nm9whlP5FMw71HmTw4RoPw5G1mfpJdZAeJPLBQodfAmn WP3Hmygu9lrPjn73Bj7XAcc0F9E1tBvNyRFSAu7WmvR+XdZ23WQma3HU7GNGP+d+njJQ bgqFhuN2hlmrF/xInGPhu3/b02WvQBs2bJKESV1rcDQQhN1t/DPCsBalfR661KgRZGLr a7MZhKOvu3KWXFmuy2+DpqoksrBIVMkbbB1wV569I6fQdzKniO65JOBGTI7BNhQQMYMT SvLME8agqTiBPik5UiUmu2R9ZS64tJl7AHWkcz7xmIry0TaKQgCMpS9oB7/t48d5wj07 XvIA== X-Received: by 10.68.164.4 with SMTP id ym4mr684169pbb.53.1403127441631; Wed, 18 Jun 2014 14:37:21 -0700 (PDT) Received: from ?IPv6:2601:9:7300:1510:1ddd:67c7:83c6:a47? ([2601:9:7300:1510:1ddd:67c7:83c6:a47]) by mx.google.com with ESMTPSA id fx5sm5033501pbb.62.2014.06.18.14.37.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Jun 2014 14:37:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com> Date: Wed, 18 Jun 2014 14:37:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com> To: Tom Pusateri X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/o--Nv9OJtKBKtgLDY3r-l9rVbcg Cc: Hosnieh Rafiee , "dnssd@ietf.org" , Ralph Droms Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 18 Jun 2014 21:37:25 -0000 Dear Tom, See comments inline: On Jun 18, 2014, at 1:21 PM, Tom Pusateri wrote: >=20 >> On Jun 18, 2014, at 2:55 PM, Douglas Otis = wrote: >>=20 >>=20 >> On Jun 18, 2014, at 4:47 AM, Hosnieh Rafiee = wrote: >>=20 >>>> For example, discussion of security issues raised by merging mDNS = and unicast DNS would be quite appropriate and important for the the WG = mailing list. >>>=20 >>> Ralph, >>>=20 >>> In the threat model document, I also covered this scenario where = mDNS node wants to update a record in unicast DNS. If folks think that = it is better that I expand it more, I would do it. >>=20 >> Dear Hosnieh, >>=20 >> Please greatly expand the related issues as there have been extremely = serious security concerns fully ignored in the consideration sections. >>=20 >> 1) Converting link-local to routable addressing removes most firewall = protections. >=20 > Firewalls don't provide protections to packets that use link-local IP = addresses. Routers just don't forward them beyond the IP subnet. When routable addresses are used to merge networks, as suggested by the = mDNS proxy scheme, this removes most local network firewall protections. = =20 >> 2) Publishing addresses in DNS exposes devices that lack = authentication. >=20 > Devices that lack authentication have a problem with or without DNS = exposure. Service enumeration doesn't change that. IPv6 link-local addressing offers two important protections: =20 1) prevents unintended data exfiltration 2) prevents external traffic infiltration 2a) Randomly assigned link-local addresses also thwarts many = encapsulation spoofing techniques An mDNS proxy scheme will have significant negative impacts on network = security. Many devices depend on link-local addressing, lack authentication, and = yet don't have a significant security problem. When enumeration = automatically translates link-local into routable addresses, this will = have profound and negative security impacts. Consider the all-in-one = printer/scanner/fax/media-reader. Would you like to have your device be = used by unknown parties to send faxes worldwide? Few if any current consumer printers log the originating IPs. Most = don't even offer a practical means to selectively restrict IPv6 access. = Do you consider this a problem? Regards, Douglas Otis From nobody Wed Jun 18 22:35:38 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 0829C1A030E for ; Wed, 18 Jun 2014 22:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 562TqJBDKDI8 for ; Wed, 18 Jun 2014 22:35:34 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975BA1A021C for ; Wed, 18 Jun 2014 22:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3134; q=dns/txt; s=iport; t=1403156135; x=1404365735; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VzfLa5jDy7IdDLV8vVZ8lRxcJL472r9jfX1lF+e6xGo=; b=Rr2a+TQiLw5WPedA01vUGAUJ4oQUkg/+1pRrGOdLcHjeIIfLZ6wNIS65 6wdHhXfqXkCitfhXObdNJMmFA+mEHtGLXu5JIgyaXDOiOM6uVOGOnxFeh bU01mzH3saFzMo09pu1dN5UUOvxJgO+feilmetIsgDU8zMizrKqEQYZ7Z E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEFANx1olOtJA2J/2dsb2JhbABagw1SqmoDAQIBAQUBkWiHPwGBDhZ1hAMBAQEDAQEBATc0CQIFCwIBCA4KHhAhBgslAgQOBYguAwkIDccoDYY3EwSFYoZxgXAzB4MtgRYEmEqBeY1YhgCCAIFC X-IronPort-AV: E=Sophos;i="5.01,505,1400025600"; d="scan'208";a="54287424" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-3.cisco.com with ESMTP; 19 Jun 2014 05:35:34 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5J5ZXS4017953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jun 2014 05:35:33 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.246]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Thu, 19 Jun 2014 00:35:33 -0500 From: "Ralph Schmieder (rschmied)" To: Douglas Otis Thread-Topic: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt Thread-Index: AQHPibnrQ8Bt/kaUHkmA9bXrkFCB/5t1vdoAgAFYiwCAAHfDgIAAF+GAgAAVSQCAADHNBA== Date: Thu, 19 Jun 2014 05:35:32 +0000 Message-ID: References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com>, <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> In-Reply-To: <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/pBNxDYRlfACIjhnHIH7VmDEF7Y0 Cc: Hosnieh Rafiee , "dnssd@ietf.org" , Tom Pusateri , Ralph Droms Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 19 Jun 2014 05:35:37 -0000 At no point the proposal talks about *converting* a link local address into= a routable address. Your printer would have to have a routable address alr= eady to be considered for service extension. In other words: if it only has= a link local address it won't be visible beyond the local subnet.=20 Thanks, -ralph > On Jun 18, 2014, at 11:37 PM, "Douglas Otis" wrot= e: >=20 >=20 > Dear Tom, > See comments inline: >=20 >> On Jun 18, 2014, at 1:21 PM, Tom Pusateri wrote: >>=20 >>=20 >>> On Jun 18, 2014, at 2:55 PM, Douglas Otis wrote= : >>>=20 >>>=20 >>> On Jun 18, 2014, at 4:47 AM, Hosnieh Rafiee = wrote: >>>=20 >>>>> For example, discussion of security issues raised by merging mDNS and= unicast DNS would be quite appropriate and important for the the WG mailin= g list. >>>>=20 >>>> Ralph, >>>>=20 >>>> In the threat model document, I also covered this scenario where mDNS = node wants to update a record in unicast DNS. If folks think that it is bet= ter that I expand it more, I would do it. >>>=20 >>> Dear Hosnieh, >>>=20 >>> Please greatly expand the related issues as there have been extremely s= erious security concerns fully ignored in the consideration sections. >>>=20 >>> 1) Converting link-local to routable addressing removes most firewall p= rotections. >>=20 >> Firewalls don't provide protections to packets that use link-local IP ad= dresses. Routers just don't forward them beyond the IP subnet. >=20 > When routable addresses are used to merge networks, as suggested by the m= DNS proxy scheme, this removes most local network firewall protections. = =20 >=20 >>> 2) Publishing addresses in DNS exposes devices that lack authentication= . >>=20 >> Devices that lack authentication have a problem with or without DNS expo= sure. Service enumeration doesn't change that. >=20 >=20 > IPv6 link-local addressing offers two important protections: =20 > 1) prevents unintended data exfiltration >=20 > 2) prevents external traffic infiltration >=20 > 2a) Randomly assigned link-local addresses also thwarts many encapsulatio= n spoofing techniques >=20 > An mDNS proxy scheme will have significant negative impacts on network se= curity. >=20 > Many devices depend on link-local addressing, lack authentication, and ye= t don't have a significant security problem. When enumeration automaticall= y translates link-local into routable addresses, this will have profound an= d negative security impacts. Consider the all-in-one printer/scanner/fax/m= edia-reader. Would you like to have your device be used by unknown parties= to send faxes worldwide? >=20 > Few if any current consumer printers log the originating IPs. Most don't= even offer a practical means to selectively restrict IPv6 access. Do you = consider this a problem? >=20 > Regards, > Douglas Otis >=20 >=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Thu Jun 19 01:04:33 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 121D51A0358 for ; Thu, 19 Jun 2014 01:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dgSXss_nqTNL for ; Thu, 19 Jun 2014 01:04:29 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.198]) by ietfa.amsl.com (Postfix) with ESMTP id 852661A030E for ; Thu, 19 Jun 2014 01:04:29 -0700 (PDT) Received: from poro.lan (84.248.74.106) by jenni2.inet.fi (8.5.140.03) (authenticated as stenma-47) id 53A17F6000116F1D; Thu, 19 Jun 2014 11:04:21 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Markus Stenberg In-Reply-To: <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> Date: Thu, 19 Jun 2014 11:04:20 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9FCED06B-006A-4194-9292-2DD26B53E694@iki.fi> References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com> <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> To: Douglas Otis X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/vN9M7IggDbcahN2zVTNi8-xe354 Cc: Hosnieh Rafiee , "dnssd@ietf.org" , Markus Stenberg , Tom Pusateri , Ralph Droms Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 19 Jun 2014 08:04:32 -0000 On 19.6.2014, at 0.37, Douglas Otis wrote: > On Jun 18, 2014, at 1:21 PM, Tom Pusateri wrote: >>> On Jun 18, 2014, at 2:55 PM, Douglas Otis = wrote: >>>=20 >>>=20 >>> On Jun 18, 2014, at 4:47 AM, Hosnieh Rafiee = wrote: >>>=20 >>>>> For example, discussion of security issues raised by merging mDNS = and unicast DNS would be quite appropriate and important for the the WG = mailing list. >>>>=20 >>>> Ralph, >>>>=20 >>>> In the threat model document, I also covered this scenario where = mDNS node wants to update a record in unicast DNS. If folks think that = it is better that I expand it more, I would do it. >>>=20 >>> Dear Hosnieh, >>>=20 >>> Please greatly expand the related issues as there have been = extremely serious security concerns fully ignored in the consideration = sections. >>>=20 >>> 1) Converting link-local to routable addressing removes most = firewall protections. >>=20 >> Firewalls don't provide protections to packets that use link-local IP = addresses. Routers just don't forward them beyond the IP subnet. > When routable addresses are used to merge networks, as suggested by = the mDNS proxy scheme, this removes most local network firewall = protections. =20 Ok, fine. Let=92s look at the current non-routable IP addresses.. RFC1918? I suppose, but that=92s network deployment detail and = non-routability is only within site that is behind the NAT. It can still = be attackable by anyone behind the same NAT. Similar grade of protection = on IPv6 globals can be achieved by simple =91drop inbound = non-established=92 rule in any firewall product you care to look at, = given they support IPv6. IPv6 link-locals? How many printers do you even have that support IPv6? = And how many of them by default are link-local only?=20 >>> 2) Publishing addresses in DNS exposes devices that lack = authentication. >> Devices that lack authentication have a problem with or without DNS = exposure. Service enumeration doesn't change that. > 2a) Randomly assigned link-local addresses also thwarts many = encapsulation spoofing techniques I have yet to see a device in the wild that doesn=92t do EUI64 linklocal = by default. Do you have an example of this? And if they do that, they = usually do SLAAC too and wind up with globals (at least in my home). > An mDNS proxy scheme will have significant negative impacts on network = security. >=20 > Many devices depend on link-local addressing, lack authentication, and = yet don't have a significant security problem. When enumeration = automatically translates link-local into routable addresses, this will = have profound and negative security impacts. Consider the all-in-one = printer/scanner/fax/media-reader. Would you like to have your device be = used by unknown parties to send faxes worldwide? >=20 > Few if any current consumer printers log the originating IPs. Most = don't even offer a practical means to selectively restrict IPv6 access. = Do you consider this a problem? I=92d love to find a consumer printer that operates on IPv6 linklocal = only first (preferably also without IPv4 to ensure it=92s really not = routable). Do you have an example? Cheers, -Markus= From nobody Thu Jun 19 01:40:46 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 4E8111A035A for ; Thu, 19 Jun 2014 01:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 yuirkX0tJLzP for ; Thu, 19 Jun 2014 01:40:42 -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 436A51A035D for ; Thu, 19 Jun 2014 01:40:42 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 8F87F566099F; Thu, 19 Jun 2014 08:40:39 +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 aZDjZoRD560D; Thu, 19 Jun 2014 10:40:09 +0200 (CEST) Received: from kopoli (tmo-103-135.customers.d1-online.com [80.187.103.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id DFC4F566098D; Thu, 19 Jun 2014 10:40:07 +0200 (CEST) From: "Hosnieh Rafiee" To: "'Markus Stenberg'" , "'Douglas Otis'" References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com> <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> <9FCED06B-006A-4194-9292-2DD26B53E694@iki.fi> In-Reply-To: <9FCED06B-006A-4194-9292-2DD26B53E694@iki.fi> Date: Thu, 19 Jun 2014 10:40:05 +0200 Message-ID: <001e01cf8b9a$13416130$39c42390$@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: AQMHk5Dn0OApbj704Gp7rq+nCnqZrgITYMNrAs0qQ48Bph39UgJzOqcpAagpOf4BlRV2ywKg2tqAAPyt4wmYiWL1EA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/FKfFWtc33u8YbELCEdQoCuiXTpQ Cc: 'Hosnieh Rafiee' , dnssd@ietf.org, 'Tom Pusateri' , 'Ralph Droms' Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 19 Jun 2014 08:40:44 -0000 Markus, Just a few comments on your questions. > Ok, fine. Let's look at the current non-routable IP addresses.. > > RFC1918? I suppose, but that's network deployment detail and non-routability > is only within site that is behind the NAT. It can still be attackable by anyone > behind the same NAT. Similar grade of protection on IPv6 globals can be > achieved by simple 'drop inbound non-established' rule in any firewall > product you care to look at, given they support IPv6. I presume that NAT in IPv6 doesn't applicable for local link addresses. At first the assumption for IPv6 was that there is no need for NAT since there are enough IP addresses. But later some folks thought that It would be also useful to have NAT, maybe for privacy reason?! Or other reasons but not because there is not enough valid IP addresses dissimilar to what we have for IPv4 to assign to the nodes. > > I'd love to find a consumer printer that operates on IPv6 linklocal only first > (preferably also without IPv4 to ensure it's really not routable). Do you have > an example? I was also curious to see whether any printer uses IPv6, I found this link http://www.internetsociety.org/deploy360/blog/2014/05/case-study-printing-an d-scanning-over-ipv6-only/ It appears that they do and they use SLAAC. In this case, if they need RA, I presume that they set both local link addresses which is not routable based on standards and routable IP addresses that needs to obtain prefixes from RA Best, Hosnieh From nobody Thu Jun 19 04:03:22 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 3D6631A036D for ; Thu, 19 Jun 2014 04:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 iSf8y8Jh4B_J for ; Thu, 19 Jun 2014 04:03:11 -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 3C78C1A036E for ; Thu, 19 Jun 2014 04:03:11 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 72BCD566099F; Thu, 19 Jun 2014 11:03:08 +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 8UB0C2HnQg7K; Thu, 19 Jun 2014 13:02:38 +0200 (CEST) Received: from kopoli (tmo-103-135.customers.d1-online.com [80.187.103.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 0DC48566098D; Thu, 19 Jun 2014 13:02:37 +0200 (CEST) From: "Hosnieh Rafiee" To: "'Markus Stenberg'" , "'Douglas Otis'" References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com> <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> <9FCED06B-006A-4194-9292-2DD26B53E694@iki.fi> <001e01cf8b9a$13416130$39c42390$@rozanak.com> In-Reply-To: <001e01cf8b9a$13416130$39c42390$@rozanak.com> Date: Thu, 19 Jun 2014 13:02:36 +0200 Message-ID: <001f01cf8bad$fb7fbf10$f27f3d30$@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: AQMHk5Dn0OApbj704Gp7rq+nCnqZrgITYMNrAs0qQ48Bph39UgJzOqcpAagpOf4BlRV2ywKg2tqAAPyt4wkB48IRzZh6cGOA Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/ilnk5t_Q4sczZ8cogTR8cTXcOLs Cc: 'Hosnieh Rafiee' , dnssd@ietf.org, 'Tom Pusateri' , 'Ralph Droms' Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 19 Jun 2014 11:03:16 -0000 Follow up I also found Xeron supports IPv6. Here is the configuration for Xeron printers. This document is for 2009. So it appears that some providers started supporting IPv6 some years ago. I was astonished to see this information. Best, Hosnieh From nobody Thu Jun 19 04:28:27 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 F13241A01C9 for ; Thu, 19 Jun 2014 04:28:25 -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 m11qesGMS8W3 for ; Thu, 19 Jun 2014 04:28:24 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 443861A0139 for ; Thu, 19 Jun 2014 04:28:20 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id z60so1957190qgd.2 for ; Thu, 19 Jun 2014 04:28:20 -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:cc :content-transfer-encoding:message-id:references:to; bh=CLwodIl2cmdxN/95dD9ETGIMu5T8afr3F+mpPmJ+33w=; b=AsdfeDTY4KzqheSek94hAJEr1CC+1ShOsk/whqsWAY+oay6OyP4+VkzDodcygEET4p mV9UsgLXjc2O0zTuh0S2rc/ot1kaCRb3gXa2E6PmTRA8AawJGqEJVdiX6EFqfaSPBKq3 Wxs+/mzz4mqN6DM+JZdqPec6jb68dG82fA3XjMtsTp2stLlNXW/2XBLECZkm5G1nCK3d gTL/VLhzIO1IeYUIA++8vnZ4kIm5lUtTSxKtHc/7LOP1XweR845YnvKnX8DZBoPFXqi9 G7orNY6C8LLjq+CPVewAMJW3mevyxk4HzA3gWQDWywCJGSG1ZnkYf1/1d/kJiYSFU1U5 wH3w== X-Received: by 10.140.21.239 with SMTP id 102mr5609934qgl.31.1403177300206; Thu, 19 Jun 2014 04:28:20 -0700 (PDT) Received: from ?IPv6:2601:6:6780:19e:11ba:b5bd:964a:643? ([2601:6:6780:19e:11ba:b5bd:964a:643]) by mx.google.com with ESMTPSA id m13sm8086760qab.19.2014.06.19.04.28.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Jun 2014 04:28:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ralph Droms In-Reply-To: <001f01cf8bad$fb7fbf10$f27f3d30$@rozanak.com> Date: Thu, 19 Jun 2014 07:28:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <37B315CB-2450-4D25-B1F9-171B7C7E9359@gmail.com> References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com> <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> <9FCED06B-006A-4194-9292-2DD26B53E694@iki.fi> <001e01cf8b9a$13416130$39c42390$@rozanak.com> <001f01cf8bad$fb7fbf10$f27f3d30$@rozanak.com> To: Hosnieh Rafiee X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/AD4YuSrYSfrDp0GL47t1jxxGYOQ Cc: Hosnieh Rafiee , dnssd@ietf.org, Markus Stenberg , Tom Pusateri , Douglas Otis Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 19 Jun 2014 11:28:26 -0000 I've had a HP laser printer and a web/surveillance camera w/ IPv6 for = several years. - Ralph On Jun 19, 2014, at 7:02 AM 6/19/14, Hosnieh Rafiee = wrote: > Follow up > = v6-Supplement.pdf > > I also found Xeron supports IPv6. Here is the configuration for Xeron > printers. This document is for 2009. So it appears that some providers > started supporting IPv6 some years ago. I was astonished to see this > information. >=20 >=20 > Best, > Hosnieh >=20 From nobody Thu Jun 19 05:06:56 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 D45D51A0380 for ; Thu, 19 Jun 2014 05:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 eiO4j4IHIc5F for ; Thu, 19 Jun 2014 05:06:51 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8F7E1A037D for ; Thu, 19 Jun 2014 05:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1403179610; x=2267093210; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mVtG1L+D0wAQoC/Yy62vlVE1DtW32Jwg3lrbBdQ8HWg=; b=RzaJh9u89DeDgNt5Sac4pi9hFxnXJWn5WYUjPJqPNBIS5BUeGKKr0f9B6tgAlXad tDrcG8XHmB0H8S4oSihD4FpC5umLc/M2gf0rjkd3mghrejPrjWVdBnG/pHDjxfnD +FOuWZT9+ZFlF1SH/l3JLrBd/Hm7bgLLqpo7lguauO0GvslUeqGFy2TDt2NcdwI1 rXURWoLXNIvRvN+67Eg01MXcqXN2J0Hu1bVNvOe31dUBIBS2skP728N5/eQdUtJV K0sxtzLK11VUNnOWdwrlrSrb/1alnmHnWq6LNYfrm/OvJNd/ou7T9YPNgkXB8X0u vV/7fdIZBbOAdwuMVGhHzg==; Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id DA.55.20114.A52D2A35; Thu, 19 Jun 2014 05:06:50 -0700 (PDT) MIME-version: 1.0 Received: from relay2.apple.com ([17.128.113.67]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N7F00A7L0B9SGP0@local.mail-out.apple.com> for dnssd@ietf.org; Thu, 19 Jun 2014 05:06:50 -0700 (PDT) X-AuditID: 11973e16-f79b86d000004e92-31-53a2d25aa433 Received: from cilantro.apple.com (cilantro.apple.com [17.128.115.18]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 03.CB.19003.B52D2A35; Thu, 19 Jun 2014 05:06:51 -0700 (PDT) Received: from [17.153.53.216] (unknown [17.153.53.216]) by cilantro.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0N7F00HO10BB0J10@cilantro.apple.com> for dnssd@ietf.org; Thu, 19 Jun 2014 05:06:50 -0700 (PDT) Content-type: multipart/signed; boundary="Apple-Mail=_B5FC26C2-A129-4B3D-BDB6-207569BA6B38"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: <9FCED06B-006A-4194-9292-2DD26B53E694@iki.fi> Date: Thu, 19 Jun 2014 08:06:52 -0400 Message-id: <158F7E24-CA05-427A-B6DC-DBE8718447D4@apple.com> References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com> <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> <9FCED06B-006A-4194-9292-2DD26B53E694@iki.fi> To: Markus Stenberg X-Mailer: Apple Mail (2.1878.2) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUiON3OWDfq0qJgg6vnjC3eL53F6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLU9V9gLXjpUTJl6kr2BcYNtFyMnh4SAicTPiZ9YIWwxiQv3 1rN1MXJxCAnMYpJ4cvw0E0iCV0BQ4sfkeywQialMEne6JrPDdO+89RSsSEhgIpPEnv0hEEWT mCROH3/BApIQFoiT2Pb7AStIgllgCqPEqhnNYB1sAmoSvyf1ge3mFLCSeDlvKVADBweLgKrE io0WEPWHGSVenoWI8wrYSNz6KQOx4BWzxO5rDWBzRAR0JC58Ogj1g7zEjPYT7CBFEgKb2CSm HvnDNoFReBaSN2YhOwQkwSygLbFs4WtmCNtA4mnnK1YI21TiydvtbBC2tcTPOY8YIWxFiSnd D9kXMLKvYhTKTczM0c3MM9dLLCjISdVLzs/dxAiJF7EdjA9XWR1iFOBgVOLhXXB5YbAQa2JZ cWXuIUZpDhYlcV5J7kXBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgP5D7Secay9kx5xYPk wJdLbsk5qZvfb+HnNNt7uz4naOqMh5enP3pz1JzjGg9f18EpDySrD806b7esJ+XHdccG1623 o1TlslZdCM/R+zH7Pafc1s8qutcrPec/2rLvQk7WhasBJ9nXFrlU9J9gKHl9bc2n1X731m/8 v3rPhzY5v4vHHh275rLmnhJLcUaioRZzUXEiAJ4AtmJ4AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUi2FAspBt9aVGwwYdT3Bbvl85idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtqeK+wFLx0qpkw9yd7AuMG2i5GTQ0LARGLnradMELaYxIV7 69m6GLk4hAQmMkncP9PKCuFMYpI4ffwFC0iVsECcxLbfD1hBbF4BA4k3B48zgRQxC0xhlFg1 oxlsFJuAmsTvSX1gRZwCVhIv5y0FaubgYBFQlVix0QKi/jCjxMuzEHFeARuJWz9lIJa9YpbY fa0BbI6IgI7EhU8HWSHOk5eY0X6CfQIj/ywku2ch2w2SYBbQlli28DUzhG0g8bTzFSuEbSrx 5O12NgjbWuLnnEeMELaixJTuh+wLGNlXMQoUpeYkVhrpJRYU5KTqJefnbmIEh3Gh8w7GY8us DjEKcDAq8fAuuLwwWIg1say4MvcQowrQiEcbVl9glGLJy89LVRLh7T6wKFiINyWxsiq1KD++ qDQntfgQozQHi5I47/XJ84OFBNITS1KzU1MLUotgskwcnFINjDs2C/n0XWxXmu4+R+q1Luvy rS+vl7m483Apaa9QPj3lU+3FugO+uzS1Yi0+nhRhCgvusXT8NWeWRMQ54XcRYksjdF+sXbdG XnorQ57qjK8qeyUVViveTyjq+Pm0WP3m05QZ1Yt/vDu9L3+N6Xu388xHz8Tkc11b/uHIvU/W Ifk7tBXE1q341a7EUpyRaKjFXFScCABoar9ZawIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/1Hvv8BTuLMxeTwQNPX_3cP1Tphc Cc: Hosnieh Rafiee , "dnssd@ietf.org" , Tom Pusateri , Douglas Otis , Ralph Droms Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 19 Jun 2014 12:06:54 -0000 --Apple-Mail=_B5FC26C2-A129-4B3D-BDB6-207569BA6B38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Markus, On Jun 19, 2014, at 4:04 AM, Markus Stenberg = wrote: > ... > IPv6 link-locals? How many printers do you even have that support = IPv6? And how many of them by default are link-local only?=20 Pretty much all current-year AirPrint printers support IPv6 (we've been = pushing hard for that since day one) and most only support link-local = out-of-the-box since few support DHCPv6... (all support manual = configuration) >> ... >> Few if any current consumer printers log the originating IPs. Most = don't even offer a practical means to selectively restrict IPv6 access. = Do you consider this a problem? >=20 > I=92d love to find a consumer printer that operates on IPv6 linklocal = only first (preferably also without IPv4 to ensure it=92s really not = routable). Do you have an example? AFAIK there are no printers that are IPv6-only (and there is strong = resistance to dropping IPv4). Most printers also do not allow IPv4 to be disabled, however IPv6 can = be... Such is the sad state of printer networking... _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_B5FC26C2-A129-4B3D-BDB6-207569BA6B38 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwNjE5MTIwNjUzWjAjBgkqhkiG9w0BCQQxFgQUYO1j2G+ilGpK+Xs43LYiPkv4 qVYwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQAcvhGgULOR1ND6qva0PPcvuXlwIPrlvkJyXjJw76TV8fn4A0W6JmShoZRByC2XaRBaAOeQg7q/ Pv0NwrmV1K5cHXo23ES6ekGFK63W+yIAhe4qZIYyuQ7Oz6YClhUdrKkmdjW2Rj0m2Bj2nLR6xILr Jis0+Jtad4AK8oP1e9gQn/17EkLQeOYo0Xfz/zq+ywvlitgDldSGueqjQSCuLFOHi2kHnjPYwlpM nZSfpJ4O8CkrCOIx3sp3bplyu+u7V8THX3MfIdRO2rwnRrT/yhbXAXiLH0SNS46XzDKBMiwfKkNA YkcLG5uJKVx71ZHNI4kKsqXwWzc/xXIk+/zJDiPFAAAAAAAA --Apple-Mail=_B5FC26C2-A129-4B3D-BDB6-207569BA6B38-- From nobody Thu Jun 19 07:02:40 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 B66BB1A0369 for ; Thu, 19 Jun 2014 07:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 HlDEthEHhU5y for ; Thu, 19 Jun 2014 07:02:37 -0700 (PDT) Received: from g4t3427.houston.hp.com (g4t3427.houston.hp.com [15.201.208.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037E81A01EE for ; Thu, 19 Jun 2014 07:02:36 -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 g4t3427.houston.hp.com (Postfix) with ESMTPS id 02079360; Thu, 19 Jun 2014 14:02:35 +0000 (UTC) Received: from G9W3617.americas.hpqcorp.net (16.216.186.52) by G9W0364.americas.hpqcorp.net (16.216.193.45) with Microsoft SMTP Server (TLS) id 14.3.169.1; Thu, 19 Jun 2014 14:01:28 +0000 Received: from G9W0339.americas.hpqcorp.net ([169.254.6.132]) by G9W3617.americas.hpqcorp.net ([16.216.186.52]) with mapi id 14.03.0169.001; Thu, 19 Jun 2014 14:01:28 +0000 From: "Tovey, Dwight (LaserJet R&D FW Eng.)" To: Michael Sweet , Markus Stenberg Thread-Topic: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt Thread-Index: AQHPij7Vq6jNE5ZaSE2LryTZ9jShYZt2wYkAgAB3xICAABfhgIAAFUkAgACvMQCAAEPDAIAAHtSg Date: Thu, 19 Jun 2014 14:01:27 +0000 Message-ID: References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com> <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> <9FCED06B-006A-4194-9292-2DD26B53E694@iki.fi> <158F7E24-CA05-427A-B6DC-DBE8718447D4@apple.com> In-Reply-To: <158F7E24-CA05-427A-B6DC-DBE8718447D4@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.210.48.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/pJDNDdNhpMDVqGf3BUCulYNacM4 Cc: Hosnieh Rafiee , "dnssd@ietf.org" , Tom Pusateri , Douglas Otis , Ralph Droms Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 19 Jun 2014 14:02:38 -0000 FWIW: HP LaserJet printers have had IPv6 support for several years, includi= ng at least some basic DHCPv6 support. They come out of the box with IPv4,= IPv6, and DHCPv6 enabled, but either IPv4 or IPv6 can be disabled either t= hrough the Embedded Web Server or via SNMP. Dwight Tovey Laserjet R&D FW Engineer (208)396-4645 -----Original Message----- From: dnssd [mailto:dnssd-bounces@ietf.org] On Behalf Of Michael Sweet Sent: Thursday, June 19, 2014 6:07 AM To: Markus Stenberg Cc: Hosnieh Rafiee; dnssd@ietf.org; Tom Pusateri; Douglas Otis; Ralph Droms Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-t= hreatmodel-00.txt Markus, On Jun 19, 2014, at 4:04 AM, Markus Stenberg wrote= : > ... > IPv6 link-locals? How many printers do you even have that support IPv6? A= nd how many of them by default are link-local only?=20 Pretty much all current-year AirPrint printers support IPv6 (we've been pus= hing hard for that since day one) and most only support link-local out-of-t= he-box since few support DHCPv6... (all support manual configuration) >> ... >> Few if any current consumer printers log the originating IPs. Most don'= t even offer a practical means to selectively restrict IPv6 access. Do you= consider this a problem? >=20 > I'd love to find a consumer printer that operates on IPv6 linklocal only = first (preferably also without IPv4 to ensure it's really not routable). Do= you have an example? AFAIK there are no printers that are IPv6-only (and there is strong resista= nce to dropping IPv4). Most printers also do not allow IPv4 to be disabled, however IPv6 can be... Such is the sad state of printer networking... _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair From nobody Thu Jun 19 07:35:34 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 4E17F1A0213 for ; Thu, 19 Jun 2014 07:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 68QT3BZqMl-3 for ; Thu, 19 Jun 2014 07:35:31 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.199]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1951A0278 for ; Thu, 19 Jun 2014 07:35:31 -0700 (PDT) Received: from poro.lan (84.248.74.106) by kirsi1.inet.fi (8.5.140.03) (authenticated as stenma-47) id 53A1810C0019746C; Thu, 19 Jun 2014 17:34:43 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Markus Stenberg In-Reply-To: Date: Thu, 19 Jun 2014 17:34:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com> <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> <9FCED06B-006A-4194-9292-2DD26B53E694@iki.fi> <158F7E24-CA05-427A-B6DC-DBE8718447D4@apple.com> To: "Tovey, Dwight (LaserJet R&D FW Eng.)" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/aEXlAXHdEubyG4IDJOoqEu5bifs Cc: "dnssd@ietf.org" , Markus Stenberg , Douglas Otis , Michael Sweet , Hosnieh Rafiee , Ralph Droms , Tom Pusateri Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 19 Jun 2014 14:35:33 -0000 On 19.6.2014, at 17.01, Tovey, Dwight (LaserJet R&D FW Eng.) = wrote: > FWIW: HP LaserJet printers have had IPv6 support for several years, = including at least some basic DHCPv6 support. They come out of the box = with IPv4, IPv6, and DHCPv6 enabled, but either IPv4 or IPv6 can be = disabled either through the Embedded Web Server or via SNMP. Ok, I=92m getting actually useful information out of this (last = networked printer I bought didn=92t have anything else than IPv4). = Clearly, the next one I buy _will_ ;) However, can someone point to a consumer-grade printer that _doesn=92t_ = do DHCPv6 or SLAAC but _does_ IPv6 link-locals out of the box? I believe = Douglas described that as the default IPv6 stance in his world, and that = sounds more like an exception than the rule. Cheers, -Markus= From nobody Thu Jun 19 07:43:12 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 A32AD1A03C4 for ; Thu, 19 Jun 2014 07:43:10 -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 xWln9Qp4ldnK for ; Thu, 19 Jun 2014 07:43:09 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d: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 607B31A03C2 for ; Thu, 19 Jun 2014 07:43:09 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id m5so2014132qaj.37 for ; Thu, 19 Jun 2014 07:43:08 -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:cc :content-transfer-encoding:message-id:references:to; bh=q1yQmRvHHbWLWGDe2A26W4a96OgaqjE3p/O4ZBdr+5s=; b=I1+Mqj0Q5AnUdsRIjd0ONI2gbW09O0ot1GwR1d8SmFSh8RAHqKiH5I1TqOg1FD/YuG nybhbiW/x0tNa/F1U9uru1BMU1IcwGYYZGM8AC6hXVjs9feC15EZVongRzCRJ/EM+LNL 1endBU8hr8VpkzUj8AG0qv+CSeIKOQkjwBtx2iWBF6KxF1wUjhIj8SF8FjiCNNRONKYa bqAmMUoWDDFII9wx25j5cfZ85+wsFYH9VOQSz2h2Xlg3umz5RKh3VNgXbmzsRVDGwr3c h1Klole211SeQUtJqnSV3OQKINKwnHMgLuAypqnyud5JWAn45rfWP5JyNob0Mk5LTv/C Fr3A== X-Received: by 10.140.95.105 with SMTP id h96mr7498804qge.2.1403188988597; Thu, 19 Jun 2014 07:43:08 -0700 (PDT) Received: from [10.86.246.151] (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id j1sm8806277qaa.11.2014.06.19.07.43.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Jun 2014 07:43:06 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ralph Droms In-Reply-To: Date: Thu, 19 Jun 2014 10:43:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <93D479C0-E10E-4CF3-811E-B8670654D208@gmail.com> References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com> <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> <9FCED06B-006A-4194-9292-2DD26B53E694@iki.fi> <158F7E24-CA05-427A-B6DC-DBE8718447D4@apple.com> To: Markus Stenberg X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/TbbuLRKq5G7_rz5Cny68zkakH_Q Cc: "dnssd@ietf.org" , Douglas Otis , Michael Sweet , Hosnieh Rafiee , "Tovey, Dwight \(LaserJet R&D FW Eng.\)" , Tom Pusateri Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 19 Jun 2014 14:43:10 -0000 I haven't experimented with my printer. I can imagine it might do IPv6 link-locals but not global address = assignment if it doesn't receive any RAs or hear from a DHCPv6 server. I do know that many devices will happily use IPv6 link-locals to = communicate with devices discovered through DNS-SD/mDNS even if there is = no global IPv6 service/addresses available. - Ralph On Jun 19, 2014, at 10:34 AM 6/19/14, Markus Stenberg = wrote: > On 19.6.2014, at 17.01, Tovey, Dwight (LaserJet R&D FW Eng.) = wrote: >> FWIW: HP LaserJet printers have had IPv6 support for several years, = including at least some basic DHCPv6 support. They come out of the box = with IPv4, IPv6, and DHCPv6 enabled, but either IPv4 or IPv6 can be = disabled either through the Embedded Web Server or via SNMP. >=20 > Ok, I=92m getting actually useful information out of this (last = networked printer I bought didn=92t have anything else than IPv4). = Clearly, the next one I buy _will_ ;) >=20 > However, can someone point to a consumer-grade printer that _doesn=92t_ = do DHCPv6 or SLAAC but _does_ IPv6 link-locals out of the box? I believe = Douglas described that as the default IPv6 stance in his world, and that = sounds more like an exception than the rule. >=20 > Cheers, >=20 > -Markus From nobody Thu Jun 19 07:55:59 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 8C5091A03D3 for ; Thu, 19 Jun 2014 07:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sj6-P4_9SV3p for ; Thu, 19 Jun 2014 07:55:56 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.198]) by ietfa.amsl.com (Postfix) with ESMTP id B23951A027E for ; Thu, 19 Jun 2014 07:55:55 -0700 (PDT) Received: from poro.lan (84.248.74.106) by kirsi1.inet.fi (8.5.140.03) (authenticated as stenma-47) id 53A1810C0019C8F7; Thu, 19 Jun 2014 17:55:53 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Markus Stenberg In-Reply-To: <93D479C0-E10E-4CF3-811E-B8670654D208@gmail.com> Date: Thu, 19 Jun 2014 17:55:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com> <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> <9FCED06B-006A-4194-9292-2DD26B53E694@iki.fi> <158F7E24-CA05-427A-B6DC-DBE8718447D4@apple.com> <93D479C0-E10E-4CF3-811E-B8670654D208@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/CLElVcbCzze3AfQWlyNmmzwtu4M Cc: "dnssd@ietf.org" , Markus Stenberg , Douglas Otis , Michael Sweet , Hosnieh Rafiee , "Tovey, Dwight \(LaserJet R&D FW Eng.\)" , Tom Pusateri Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 19 Jun 2014 14:55:56 -0000 On 19.6.2014, at 17.43, Ralph Droms wrote: > I haven't experimented with my printer. >=20 > I can imagine it might do IPv6 link-locals but not global address = assignment if it doesn't receive any RAs or hear from a DHCPv6 server. >=20 > I do know that many devices will happily use IPv6 link-locals to = communicate with devices discovered through DNS-SD/mDNS even if there is = no global IPv6 service/addresses available. Certainly. But if they accept RA (and do SLAAC based on it) or DHCPv6 = server-oriented address assignment, Douglas=92 claims of being safe = against evils of the world do not apply. So I=92m still looking for the link-local-only IPv6 printer ;) Given how predictable EUI-64 based addresses are, SLAAC-configured = printers may not even be very hard to find _without_ service discovery = if you=92re (say) running just one /64, and opponent knows = make/~approximate manufacturing date of your printer. Cheers, -Markus From nobody Thu Jun 19 08:03:36 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 4FC851A01EE for ; Thu, 19 Jun 2014 08:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 wXvNElGOo7fZ for ; Thu, 19 Jun 2014 08:03:28 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EBD71A0181 for ; Thu, 19 Jun 2014 08:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1403190207; x=2267103807; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WyQ3V2rlUjVbuL+Guf86F9XfixNDtmRu0gfoAUMEzBk=; b=u9Cz13OrI91mtcZnUnL+rRqFwikk5EkyiA0TPOL6/AwXz+gtz8xoRC8K2OyG9/Ju 3GwKUa0FS/xUGHHzY1R73/conHh2699JQ+3Kha+vFIcsu5ZSLYVm3WXmRjWcOl+z NxQCpthn0GCaOroXnvfP9ZuQJoDGBCVGNx9Ib2xGSZIdTZ8Cgb5wERk3YWaNqz0J 65WoaOG/Ch1QUbWf+8KZHz9OPHKKoEK4Q8VYRicnsQiK3XqTe+MHFZBYgvHCm8zP p8P1snJfxDeYUoF2wiMtU20dFoKSkmLW4NQthoWAWeNFSF19UIE284NmAGZmnlnF 0rMh6ZeCk126s9tLt4dXAw==; Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 71.35.20114.FBBF2A35; Thu, 19 Jun 2014 08:03:27 -0700 (PDT) MIME-version: 1.0 Received: from relay8.apple.com ([17.128.113.102]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N7F006068HOC030@local.mail-out.apple.com> for dnssd@ietf.org; Thu, 19 Jun 2014 08:03:27 -0700 (PDT) X-AuditID: 11973e16-f79b86d000004e92-03-53a2fbbf61a8 Received: from cilantro.apple.com (cilantro.apple.com [17.128.115.18]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id E3.AC.11638.0CBF2A35; Thu, 19 Jun 2014 08:03:28 -0700 (PDT) Received: from [17.153.53.216] (unknown [17.153.53.216]) by cilantro.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0N7F00A1A8HOCT10@cilantro.apple.com> for dnssd@ietf.org; Thu, 19 Jun 2014 08:03:27 -0700 (PDT) Content-type: multipart/signed; boundary="Apple-Mail=_007CF7D8-D6F7-4D72-B7E4-4689ADD4F730"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: Date: Thu, 19 Jun 2014 11:03:29 -0400 Message-id: <203279CC-CA06-4477-A7B0-1E79DF4D4D31@apple.com> References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com> <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> <9FCED06B-006A-4194-9292-2DD26B53E694@iki.fi> <158F7E24-CA05-427A-B6DC-DBE8718447D4@apple.com> To: Markus Stenberg X-Mailer: Apple Mail (2.1878.2) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUiON3OUHf/70XBBp/Palu8XzqL0YHRY8mS n0wBjFFcNimpOZllqUX6dglcGZdvbGQv+OtQMW3lfuYGxsO2XYycHBICJhITNkxhhrDFJC7c W88GYgsJzGSS2NgsBWLzCghK/Jh8j6WLkQsoPo1JYv3JuawwzW+fn2SGaJjIJPHjnx5E0SQm ieYXDWCThAXiJLb9fsAKkmAWmMIoMfnZVRaQBJuAmsTvSX1gkzgFrCTenjvLDmKzCKhK7Hn5 iA2ioZlJ4tidSawQd9hInHm/kAVi3XRWiYmrMkFsEQEdiQufDkKdJC8xo/0EO0izhMAmNolt y78wTWAUnoXkj1nILgFJMAtoSyxb+JoZwjaQeNr5ihXCNpV48nY7G4RtLfFzziNGCFtRYkr3 Q/YFjOyrGIVyEzNzdDPzzPUSCwpyUvWS83M3MULiRWwH48NVVocYBTgYlXh4F1xeGCzEmlhW XJl7iFGag0VJnFeSe1GwkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsYDVdvlvvwWcF585NuB teZ3tr1ZVPCrYH9RcO2bedb9BjvWlz8szCoyfvKi4eB5m7VMCfOPJb15HC3Fs+bxksjmuT2L tJdOn2MZc5P3ik/OSfF1968VFzc0n/8tJL5F4Vb+1t76zbWqQTbLTCeoPWoK/Ojx3avFye7e t+LqaebXTlzZemplpVivEktxRqKhFnNRcSIAvksYPXgCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUi2FAspHvg96Jggyv7hSzeL53F6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMs3NrIX/HWomLZyP3MD42HbLkZODgkBE4m3z08yQ9hiEhfu rWfrYuTiEBKYyCRxeslGZghnEpNE84sGNpAqYYE4iW2/H7CC2LwCBhJvDh5nAiliFpjCKDH5 2VUWkASbgJrE70l9YEWcAlYSb8+dZQexWQRUJfa8fMQG0dDMJHHsziSoSTYSZ94vBGsWEpjO KjFxVSaILSKgI3Hh00FWiPvkJWa0n2CfwMg/C8nyWciWgySYBbQlli18zQxhG0g87XzFCmGb Sjx5u50NwraW+DnnESOErSgxpfsh+wJG9lWMAkWpOYmVFnqJBQU5qXrJ+bmbGMGBXJi2g7Fp udUhRgEORiUe3gWXFwYLsSaWFVfmHmJUARrxaMPqC4xSLHn5ealKIry7vy4KFuJNSaysSi3K jy8qzUktPsQozcGiJM57Y/L8YCGB9MSS1OzU1ILUIpgsEwenVAOj8JXQfddPP/Uwyk6vTo5J uV1TvHHVjR1/rraK9K6M+xZ9rmizaWv4RPElCxIv2LIv2bVg+6/DUtX/RLsU7lSVTt5UUxac Z5vwzIpBx6Ghfq+Pxb0103+XMtkrLS/sEah6n+yxv75K8h3fVRb3vRzndvmeEZS6X/Fj6nRH Idt0z/l2u3L16zSVWIozEg21mIuKEwG2ET7XbAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/XVWIfasa82hBhbFH-6f-OFiqzWg Cc: "dnssd@ietf.org" , Douglas Otis , Hosnieh Rafiee , "Tovey, Dwight \(LaserJet R&D FW Eng.\)" , Ralph Droms , Tom Pusateri Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 19 Jun 2014 15:03:34 -0000 --Apple-Mail=_007CF7D8-D6F7-4D72-B7E4-4689ADD4F730 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Markus, On Jun 19, 2014, at 10:34 AM, Markus Stenberg = wrote: > On 19.6.2014, at 17.01, Tovey, Dwight (LaserJet R&D FW Eng.) = wrote: >> FWIW: HP LaserJet printers have had IPv6 support for several years, = including at least some basic DHCPv6 support. They come out of the box = with IPv4, IPv6, and DHCPv6 enabled, but either IPv4 or IPv6 can be = disabled either through the Embedded Web Server or via SNMP. >=20 > Ok, I=92m getting actually useful information out of this (last = networked printer I bought didn=92t have anything else than IPv4). = Clearly, the next one I buy _will_ ;) >=20 > However, can someone point to a consumer-grade printer that _doesn=92t_ = do DHCPv6 or SLAAC but _does_ IPv6 link-locals out of the box? I believe = Douglas described that as the default IPv6 stance in his world, and that = sounds more like an exception than the rule. Most of the current HP OfficeJet printers fall into this category. I also have an Epson XP-800 printer in my office that does IPv6 but just = basic link-local. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_007CF7D8-D6F7-4D72-B7E4-4689ADD4F730 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwNjE5MTUwMzI5WjAjBgkqhkiG9w0BCQQxFgQUw16Lco1p3jDASJsY+33tSNoG q5MwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQAQEbZVX/Wz9K7puUwRKw9B2fR48nLGhPrPa9jDYvqA0v+GE+C/duQkEO+kNuoHJiu6VecKqXgq 8z9qJ04HqCMdFkDnM7rTRgxCmgQhabtKnuVaOfLslFbC/hWhoaMxZR/T5zm/8SudGmupBQmbI0iJ ePDfLwIJcIEK89kT5LFJIlbnxT0xNgv9zQy0x1zlIBX3DixZswo6bHorffFl6EXx1G2jKVIK+YcO Wou+idOMjp8XvwtVN9+8vm87m+PZ5Z0SND7D++RfFM+rNv0xJQA4uXeE6rccnQps/AeB8vuy0b02 hfFfYITgR6zmYSNd7HliHiF56F1vn/AdolFEW0NpAAAAAAAA --Apple-Mail=_007CF7D8-D6F7-4D72-B7E4-4689ADD4F730-- From nobody Thu Jun 19 09:35:46 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 38DF91A03E3 for ; Thu, 19 Jun 2014 09:35:43 -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 i8ev2U4fIEd2 for ; Thu, 19 Jun 2014 09:35:42 -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 47DEC1A03DA for ; Thu, 19 Jun 2014 09:35:40 -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 13AF810E79; Thu, 19 Jun 2014 12:35:38 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1962.2\)) From: Tom Pusateri In-Reply-To: <203279CC-CA06-4477-A7B0-1E79DF4D4D31@apple.com> Date: Thu, 19 Jun 2014 12:35:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <80E4D71E-BDC0-4A64-AA2B-0DD898CC2135@bangj.com> References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com> <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> <9FCED06B-006A-4194-9292-2DD26B53E694@iki.fi> <158F7E24-CA05-427A-B6DC-DBE8718447D4@apple.com> <203279CC-CA06-4477-A7B0-1E79DF4D4D31@apple.com> To: Michael Sweet X-Mailer: Apple Mail (2.1962.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/vt5HdP-KllOOis1JcG30Jo4-vJU Cc: "dnssd@ietf.org" , Markus Stenberg , Douglas Otis , Hosnieh Rafiee , "Tovey, Dwight \(LaserJet R&D FW Eng.\)" , Ralph Droms Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 19 Jun 2014 16:35:43 -0000 > On Jun 19, 2014, at 11:03 AM, Michael Sweet wrote: >=20 > Markus, >=20 > On Jun 19, 2014, at 10:34 AM, Markus Stenberg = wrote: >> On 19.6.2014, at 17.01, Tovey, Dwight (LaserJet R&D FW Eng.) = wrote: >>> FWIW: HP LaserJet printers have had IPv6 support for several years, = including at least some basic DHCPv6 support. They come out of the box = with IPv4, IPv6, and DHCPv6 enabled, but either IPv4 or IPv6 can be = disabled either through the Embedded Web Server or via SNMP. >>=20 >> Ok, I=92m getting actually useful information out of this (last = networked printer I bought didn=92t have anything else than IPv4). = Clearly, the next one I buy _will_ ;) >>=20 >> However, can someone point to a consumer-grade printer that _doesn=92t_= do DHCPv6 or SLAAC but _does_ IPv6 link-locals out of the box? I = believe Douglas described that as the default IPv6 stance in his world, = and that sounds more like an exception than the rule. >=20 > Most of the current HP OfficeJet printers fall into this category. >=20 My 4 year old HP Officejet Pro 8500 defaulted to IPv6 SLAAC enabled. Tom From nobody Thu Jun 19 11:56:01 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 3ABBC1A02D3 for ; Thu, 19 Jun 2014 11:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 EX0nEo8s64Py for ; Thu, 19 Jun 2014 11:55:55 -0700 (PDT) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 971251A014C for ; Thu, 19 Jun 2014 11:55:55 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id uo5so2204494pbc.40 for ; Thu, 19 Jun 2014 11:55:55 -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:cc :message-id:references:to; bh=uBUErhVORqtzpDb8fGeF24D3UgTEJfCx8GCZPCSeoq4=; b=DeKbYOz4cKo3dTOevDUYRfpz7hU0OxHBjCUCs2ETC/Ao+wrLsD2C8M2EMb1CDvYOun gDjlDnWDtOsI02EE9WArygMJx+5QgppeC5IPe2hVI+IeJwGnLHvA4Eva6+HJG0D6lId2 UHuhcK9CYo4+E3kOxyzaWVeEaA46w4gBhLIm6QJR5cxuq5BN2mW9zo2xI7RaP4NXffku r9PlsBP1RD3J6VvUbSS2yLRE3dynwfcOtQ/WXcDOC/l+USa4eHlEX3OXBRF+37HkyHeS GiwJW5hzZOnID8H7Fn90ggAaiwoCC/EH0ghROlSobI2P5qoHDiRkWXRtJ7c5LqXUkgS6 g81Q== X-Received: by 10.66.100.200 with SMTP id fa8mr7844259pab.23.1403204155227; Thu, 19 Jun 2014 11:55:55 -0700 (PDT) Received: from ?IPv6:2601:9:7300:1510:fc05:ff10:ef3a:76b1? ([2601:9:7300:1510:fc05:ff10:ef3a:76b1]) by mx.google.com with ESMTPSA id se3sm9777949pbb.80.2014.06.19.11.55.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Jun 2014 11:55:54 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_517F5EA4-4032-45F4-865B-0B6B7FDD6AF4" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: Date: Thu, 19 Jun 2014 11:55:55 -0700 Message-Id: <67DC542A-4EA8-4B33-815C-5B61CCEF2C5C@gmail.com> References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com>, <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> To: "Ralph Schmieder (rschmied)" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/gGnwNCKE20uNm_XbOVJ0a_JLwMo Cc: Hosnieh Rafiee , "dnssd@ietf.org" , Tom Pusateri , Ralph Droms Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 19 Jun 2014 18:55:59 -0000 --Apple-Mail=_517F5EA4-4032-45F4-865B-0B6B7FDD6AF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Ralph, See comments inline: On Jun 18, 2014, at 10:35 PM, Ralph Schmieder (rschmied) = wrote: > At no point the proposal talks about *converting* a link local address = into a routable address. Your printer would have to have a routable = address already to be considered for service extension. In other words: = if it only has a link local address it won't be visible beyond the local = subnet.=20 = http://tools.ietf.org/id/draft-cheshire-mdnsext-hybrid-02.html#rfc.section= .3 About the sixth paragraph: ,-- In addition it would be desirable to suppress Unicast DNS replies for = records that are not useful outside the local link. For example, DNS A = and AAAA records for IPv4 link-local addresses [RFC3927] and IPv6 = link-local addresses [RFC4862] should be suppressed. Similarly, for = sites that have multiple private address [RFC1918] realms, private = addresses from one private address realm should not be communicated to = clients in a different private address realm. '--- Perhaps "converting" was a poor word choice. The mDNS hybrid proxy = draft recommends suppressing link-local addresses normally conveyed by = mDNS and to use only routable addresses to be published in DNS to = support routing between different network realms. DNS-SD SRV records = using only routable addresses greatly increases device exposures such as = printers and many others lacking authentication. Security considerations are dreadfully lacking by describing concerns as = being a "union" of DNS-SD and mDNS. Since DNS-SD claims to only define = a discovery structure, a fairly serious issue of assigning and = publishing routable addresses in DNS instead of link-local otherwise = only discoverable via layer 2 is being ignored. When SLACC is used and the attacker can guess the manufacturer, this = still leaves millions of possible assignments. If the printer is using = either DHCPv6 or static addressing (that all printers support), the = number of possible assignments becomes virtually unlimited from an = attacker's perspective. Regards, Douglas Otis >> On Jun 18, 2014, at 11:37 PM, "Douglas Otis" = wrote: >>=20 >>=20 >> Dear Tom, >> See comments inline: >>=20 >>> On Jun 18, 2014, at 1:21 PM, Tom Pusateri = wrote: >>>=20 >>>=20 >>>> On Jun 18, 2014, at 2:55 PM, Douglas Otis = wrote: >>>>=20 >>>>=20 >>>> On Jun 18, 2014, at 4:47 AM, Hosnieh Rafiee = wrote: >>>>=20 >>>>>> For example, discussion of security issues raised by merging mDNS = and unicast DNS would be quite appropriate and important for the the WG = mailing list. >>>>>=20 >>>>> Ralph, >>>>>=20 >>>>> In the threat model document, I also covered this scenario where = mDNS node wants to update a record in unicast DNS. If folks think that = it is better that I expand it more, I would do it. >>>>=20 >>>> Dear Hosnieh, >>>>=20 >>>> Please greatly expand the related issues as there have been = extremely serious security concerns fully ignored in the consideration = sections. >>>>=20 >>>> 1) Converting link-local to routable addressing removes most = firewall protections. >>>=20 >>> Firewalls don't provide protections to packets that use link-local = IP addresses. Routers just don't forward them beyond the IP subnet. >>=20 >> When routable addresses are used to merge networks, as suggested by = the mDNS proxy scheme, this removes most local network firewall = protections. =20 >>=20 >>>> 2) Publishing addresses in DNS exposes devices that lack = authentication. >>>=20 >>> Devices that lack authentication have a problem with or without DNS = exposure. Service enumeration doesn't change that. >>=20 >>=20 >> IPv6 link-local addressing offers two important protections: =20 >> 1) prevents unintended data exfiltration >>=20 >> 2) prevents external traffic infiltration >>=20 >> 2a) Randomly assigned link-local addresses also thwarts many = encapsulation spoofing techniques >>=20 >> An mDNS proxy scheme will have significant negative impacts on = network security. >>=20 >> Many devices depend on link-local addressing, lack authentication, = and yet don't have a significant security problem. When enumeration = automatically translates link-local into routable addresses, this will = have profound and negative security impacts. Consider the all-in-one = printer/scanner/fax/media-reader. Would you like to have your device be = used by unknown parties to send faxes worldwide? >>=20 >> Few if any current consumer printers log the originating IPs. Most = don't even offer a practical means to selectively restrict IPv6 access. = Do you consider this a problem? >>=20 >> Regards, >> Douglas Otis >>=20 >>=20 >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_517F5EA4-4032-45F4-865B-0B6B7FDD6AF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = Ralph,

See comments inline:
On Jun 18, 2014, = at 10:35 PM, Ralph Schmieder (rschmied) <rschmied@cisco.com> = wrote:

At no point the proposal talks about *converting* a link = local address into a routable address. Your printer would have to have a = routable address already to be considered for service extension. In = other words: if it only has a link local address it won't be visible = beyond the local subnet.

About the sixth = paragraph:
,--
In addition it would be desirable to = suppress Unicast DNS replies for records that are not useful outside the = local link. For example, DNS A and AAAA records for IPv4 link-local = addresses [RFC3927] and IPv6 link-local addresses [RFC4862] should be suppressed. Similarly, for sites that = have multiple private address [RFC1918] realms, private addresses from one private = address realm should not be communicated to clients in a different = private address realm.
'---

Perhaps = "converting" was a poor word choice.  The mDNS hybrid proxy draft = recommends suppressing link-local addresses normally conveyed by mDNS = and to use only routable addresses to be published in DNS to support = routing between different network realms.   DNS-SD SRV records = using only routable addresses greatly increases device exposures such as = printers and many others lacking = authentication.

Security considerations are = dreadfully lacking by describing concerns as being a "union" of DNS-SD = and mDNS.  Since DNS-SD claims to only define a discovery = structure, a fairly serious issue of assigning and publishing routable = addresses in DNS instead of link-local otherwise only discoverable via = layer 2 is being ignored.

When SLACC is used = and the attacker can guess the manufacturer, this still leaves millions = of possible assignments.  If the printer is using either DHCPv6 or = static addressing (that all printers support), the number of possible = assignments becomes virtually unlimited from an attacker's = perspective.

Regards,
Douglas = Otis

On Jun 18, 2014, at 11:37 PM, "Douglas Otis" <doug.mtview@gmail.com> = wrote:


Dear Tom,
See comments inline:

On Jun 18, 2014, at 1:21 PM, Tom Pusateri <pusateri@bangj.com> = wrote:


On Jun 18, 2014, at 2:55 PM, = Douglas Otis <doug.mtview@gmail.com> = wrote:


On Jun 18, 2014, at 4:47 AM, Hosnieh Rafiee <hosnieh.rafiee@huawei.com>= ; wrote:

For = example, discussion of security issues raised by merging mDNS and = unicast DNS would be quite appropriate and important for the the WG = mailing list.

Ralph,

In the threat model = document, I also covered this scenario where mDNS node wants to update a = record in unicast DNS. If folks think that it is better that I expand it = more, I would do it.

Dear Hosnieh,

Please = greatly expand the related issues as there have been extremely serious = security concerns fully ignored in the consideration sections.

1) = Converting link-local to routable addressing removes most firewall = protections.

Firewalls don't provide protections to = packets that use link-local IP addresses. Routers just don't forward = them beyond the IP subnet.

When routable addresses = are used to merge networks, as suggested by the mDNS proxy scheme, this = removes most local network firewall protections. =    

2) Publishing addresses in DNS exposes devices that lack = authentication.

Devices that lack authentication = have a problem with or without DNS exposure. Service enumeration doesn't = change that.


IPv6 link-local addressing offers = two important protections:  
1) prevents unintended data = exfiltration

2) prevents external traffic infiltration

2a) = Randomly assigned link-local addresses also thwarts many encapsulation = spoofing techniques

An mDNS proxy scheme will have significant = negative impacts on network security.

Many devices depend on = link-local addressing, lack authentication, and yet don't have a = significant security problem.  When enumeration automatically = translates link-local into routable addresses, this will have profound = and negative security impacts.  Consider the all-in-one = printer/scanner/fax/media-reader.  Would you like to have your = device be used by unknown parties to send faxes worldwide?

Few if = any current consumer printers log the originating IPs.  Most don't = even offer a practical means to selectively restrict IPv6 access. =  Do you consider this a problem?

Regards,
Douglas = Otis



_______________________________________________
dns= sd mailing list
dnssd@ietf.org
https://www.ietf.org/= mailman/listinfo/dnssd

=
= --Apple-Mail=_517F5EA4-4032-45F4-865B-0B6B7FDD6AF4-- From nobody Mon Jun 23 19:07:48 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 7FD461B27C0 for ; Mon, 23 Jun 2014 19:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 ZsL0EA4IM-kN for ; Mon, 23 Jun 2014 19:07:42 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C93B1A03AF for ; Mon, 23 Jun 2014 19:07:42 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id c9so6799067qcz.37 for ; Mon, 23 Jun 2014 19:07:41 -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:cc :message-id:references:to; bh=xdGZ9xCvwJ06pfcXmJH13iA559XUyzzKDMZDf47vK4Q=; b=tydLWc9Fqm2X+2uoFJ1NcjTOVJhhe5E0Pz4OZYOqer4kLMogGV568nvxKTeVnJLw/g AHrm7xe30Y8UG9KahNyrpUj/8SL6ikx4zlV+7WGwKJ2ilz4KRNN12OGnqikg6o2s/pKW gSgUwsA0kHocIO1sLJ5uHe0ObMKVkIMndjdAXa8SwkLkS4AlSQGYedriGeeJrp+8Eo1C Ju1uTT30xlfj4K2v7xY9buVK9qeOnZ/M2rD6J2sDp1iPS75KTEFwAqqbcv5EZ0cuOZZY KTnLplHARcL303OdD/1qE6RPdyuNG4asKCdBNuQC4iOAC9nnJ+TnRss4UgNROMQ+aYcO 15oA== X-Received: by 10.140.85.102 with SMTP id m93mr37155492qgd.26.1403575661374; Mon, 23 Jun 2014 19:07:41 -0700 (PDT) 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 c52sm2032874qgc.32.2014.06.23.19.07.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Jun 2014 19:07:40 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6BBC1EA0-C888-4D04-9464-19D85F467D0C" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: Date: Mon, 23 Jun 2014 19:07:38 -0700 Message-Id: References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com> <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> <9FCED06B-006A-4194-9292-2DD26B53E694@iki.fi> <158F7E24-CA05-427A-B6DC-DBE8718447D4@apple.com> <93D479C0-E10E-4CF3-811E-B8670654D208@gmail.com> To: Markus Stenberg X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/a8RZOQYozcmnaf0i3oAQJfiBeFQ Cc: "dnssd@ietf.org" , Michael Sweet , Hosnieh Rafiee , "Tovey, Dwight \(LaserJet R&D FW Eng.\)" , Ralph Droms , Tom Pusateri Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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: Tue, 24 Jun 2014 02:07:46 -0000 --Apple-Mail=_6BBC1EA0-C888-4D04-9464-19D85F467D0C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 19, 2014, at 7:55 AM, Markus Stenberg = wrote: > On 19.6.2014, at 17.43, Ralph Droms wrote: >> I haven't experimented with my printer. >>=20 >> I can imagine it might do IPv6 link-locals but not global address = assignment if it doesn't receive any RAs or hear from a DHCPv6 server. >>=20 >> I do know that many devices will happily use IPv6 link-locals to = communicate with devices discovered through DNS-SD/mDNS even if there is = no global IPv6 service/addresses available. >=20 > Certainly. >=20 > But if they accept RA (and do SLAAC based on it) or DHCPv6 = server-oriented address assignment, Douglas=92 claims of being safe = against evils of the world do not apply. >=20 > So I=92m still looking for the link-local-only IPv6 printer ;) >=20 > Given how predictable EUI-64 based addresses are, SLAAC-configured = printers may not even be very hard to find _without_ service discovery = if you=92re (say) running just one /64, and opponent knows = make/~approximate manufacturing date of your printer. Dear Markus, There are several issues related to link-local addressing such as ULA = addresses commonly used in things like BTMM = http://tools.ietf.org/html/rfc4193. In that service, the ULA addresses = exposed are not routable and are accessed via a tunnel restricted by a = centralized authenticating service. In the case of mDNS Hybrid Proxies = http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid, this layer of = security does not exist and yet deceptively purports current use of the = related discovery strategy? This draft even goes on to describe = eventual mergers of .local domains which also necessitates recognizing = name collisions caused by multiple interface devices from those needing = reassignment.=20 In the case of the All-In-One Printer/Fax/Scanner/Media-Reader: 1) How can a device be accessed when only a link-local address is = reported? 2) How are routable addresses discovered when link-local is returned by = mDNS? 3) How can devices be secured when SLACC or DHCPv6 addresses are being = indirectly exposed? 4) How will disparate .local domains be merged? While one might attempt to guess likely SLACC assignments out of a = possible range likely in the millions, users are also free to manually = assign addresses. If a problem is discovered, this strategy would give = malefactors a guessing range of about 9 quintillion. Of course, unusual = levels of address probing can be detected and blocked. Automated = DNS-Based Service Discovery http://tools.ietf.org/html/rfc6763 as = suggested, precludes malefactors even needing to make a series of = guesses. Of course, IPsec tunneling represents viable strategy that = might be used, but this no longer offers zero configuration. It seems = unauthenticated exposure of even ULAs has a fair amount of security = related risk doesn't it? I need a clue as this seems to be a serious problem. Regards, Douglas Otis --Apple-Mail=_6BBC1EA0-C888-4D04-9464-19D85F467D0C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jun 19, 2014, at 7:55 AM, Markus = Stenberg <markus.stenberg@iki.fi> = wrote:

On 19.6.2014, at 17.43, Ralph Droms <rdroms.ietf@gmail.com> = wrote:
I haven't experimented with my = printer.

I can imagine it might do IPv6 link-locals but not = global address assignment if it doesn't receive any RAs or hear from a = DHCPv6 server.

I do know that many devices will happily use IPv6 = link-locals to communicate with devices discovered through DNS-SD/mDNS = even if there is no global IPv6 service/addresses = available.

Certainly.

But if they accept RA = (and do SLAAC based on it) or DHCPv6 server-oriented address assignment, = Douglas=92 claims of being safe against evils of the world do not = apply.

So I=92m still looking for the link-local-only IPv6 = printer ;)

Given how predictable EUI-64 based addresses are, = SLAAC-configured printers may not even be very hard to find _without_ = service discovery if you=92re (say) running just one /64, and opponent = knows make/~approximate manufacturing date of your = printer.

Dear = Markus,

There are several issues related to = link-local addressing such as ULA addresses commonly used in things like = BTMM http://tools.ietf.org/html/rfc= 4193. In that service, the ULA addresses exposed are not routable = and are accessed via a tunnel restricted by a centralized authenticating = service.  In the case of mDNS Hybrid Proxies http://t= ools.ietf.org/html/draft-cheshire-mdnsext-hybrid, this layer of = security does not exist and yet deceptively purports current use of the = related discovery strategy?  This draft even goes on to describe = eventual mergers of .local domains which also necessitates recognizing = name collisions caused by multiple interface devices from those needing = reassignment. 

In the case of the = All-In-One Printer/Fax/Scanner/Media-Reader:

1) = How can a device be accessed when only a link-local address is = reported?

2) How are routable addresses = discovered when link-local is returned by = mDNS?

3) How can devices be secured when = SLACC or DHCPv6 addresses are being indirectly = exposed?

4) How will disparate .local domains = be merged?

While one might attempt to guess = likely SLACC assignments out of a possible range likely in the millions, = users are also free to manually assign addresses.  If a problem is = discovered, this strategy would give malefactors a guessing range of = about 9 quintillion.  Of course, unusual levels of address probing = can be detected and blocked.  Automated DNS-Based Service = Discovery http://tools.ietf.org/html/rfc= 6763 as suggested, precludes malefactors even needing to = make a series of guesses.  Of course, IPsec tunneling represents = viable strategy that might be used, but this no longer offers zero = configuration. It seems unauthenticated exposure of even ULAs has a fair = amount of security related risk doesn't it?

I = need a clue as this seems to be a serious = problem.

Regards,
Douglas = Otis


= --Apple-Mail=_6BBC1EA0-C888-4D04-9464-19D85F467D0C-- From nobody Tue Jun 24 00:17:22 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 615841B286A for ; Tue, 24 Jun 2014 00:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qNlBo_ncO2-E for ; Tue, 24 Jun 2014 00:17:12 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.198]) by ietfa.amsl.com (Postfix) with ESMTP id C69FC1B286F for ; Tue, 24 Jun 2014 00:17:08 -0700 (PDT) Received: from poro.lan (84.248.74.106) by jenni2.inet.fi (8.5.140.03) (authenticated as stenma-47) id 53A17F6000660510; Tue, 24 Jun 2014 10:17:04 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Markus Stenberg In-Reply-To: Date: Tue, 24 Jun 2014 10:17:03 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <399DC567-F288-49A1-8801-3C0AA7674A3B@iki.fi> References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com> <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> <9FCED06B-006A-4194-9292-2DD26B53E694@iki.fi> <158F7E24-CA05-427A-B6DC-DBE8718447D4@apple.com> <93D479C0-E10E-4CF3-811E-B8670654D208@gmail.com> To: Douglas Otis X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/J7SBWYjIMryJkNFOjaExVSP52OE Cc: "dnssd@ietf.org" , Markus Stenberg , Michael Sweet , Hosnieh Rafiee , "Tovey, Dwight \(LaserJet R&D FW Eng.\)" , Ralph Droms , Tom Pusateri Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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: Tue, 24 Jun 2014 07:17:14 -0000 On 24.6.2014, at 5.07, Douglas Otis wrote: > On Jun 19, 2014, at 7:55 AM, Markus Stenberg = wrote: >> On 19.6.2014, at 17.43, Ralph Droms wrote: >>> I haven't experimented with my printer. >>>=20 >>> I can imagine it might do IPv6 link-locals but not global address = assignment if it doesn't receive any RAs or hear from a DHCPv6 server. >>>=20 >>> I do know that many devices will happily use IPv6 link-locals to = communicate with devices discovered through DNS-SD/mDNS even if there is = no global IPv6 service/addresses available. >>=20 >> Certainly. >>=20 >> But if they accept RA (and do SLAAC based on it) or DHCPv6 = server-oriented address assignment, Douglas=92 claims of being safe = against evils of the world do not apply. >>=20 >> So I=92m still looking for the link-local-only IPv6 printer ;) >>=20 >> Given how predictable EUI-64 based addresses are, SLAAC-configured = printers may not even be very hard to find _without_ service discovery = if you=92re (say) running just one /64, and opponent knows = make/~approximate manufacturing date of your printer. > There are several issues related to link-local addressing such as ULA = addresses commonly used in things like BTMM = http://tools.ietf.org/html/rfc4193. In that service, the ULA addresses = exposed are not routable and are accessed via a tunnel restricted by a = centralized authenticating service. In the case of mDNS Hybrid Proxies = http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid, this layer of = security does not exist and yet deceptively purports current use of the = related discovery strategy? This draft even goes on to describe = eventual mergers of .local domains which also necessitates recognizing = name collisions caused by multiple interface devices from those needing = reassignment.=20 That draft forces you to route ULAs outside your organization?=20 > In the case of the All-In-One Printer/Fax/Scanner/Media-Reader: >=20 > 1) How can a device be accessed when only a link-local address is = reported? It cannot be. But I=92m still looking for that IPv6 link-local only = All-In-One Printer/Fax/Scanner/Media-Reader, please report one to me and = I=92ll consider this a problem ;) > 2) How are routable addresses discovered when link-local is returned = by mDNS? They are not. > 3) How can devices be secured when SLACC or DHCPv6 addresses are being = indirectly exposed? Firewalls are traditional way of protecting _any_ addresses. IPv6 = linklocals _and_ ULAs provide added property of not being globally = routable, just like RFC1918 IPv4 addresses. > 4) How will disparate .local domains be merged? They need not be. Read hybrid draft + RFC6763, especially on the =91browse= domain _list_=92 part. Merging is just (ugly) glue that could deal with broken clients which = handle only either pure mdns, or single list of entries-style dns-sd = (=91legacy browse domain=92 is the term in RFC6763). > While one might attempt to guess likely SLACC assignments out of a = possible range likely in the millions, users are also free to manually = assign addresses. If a problem is discovered, this strategy would give = malefactors a guessing range of about 9 quintillion. Of course, unusual = levels of address probing can be detected and blocked. Automated = DNS-Based Service Discovery http://tools.ietf.org/html/rfc6763 as = suggested, precludes malefactors even needing to make a series of = guesses. Of course, IPsec tunneling represents viable strategy that = might be used, but this no longer offers zero configuration. It seems = unauthenticated exposure of even ULAs has a fair amount of security = related risk doesn=92t it? Nothing forces you to export those hybrid proxy / DNS-SD zones outside = your organization. Split horizon DNS was state of the art in late 90s = when (IPsec) VPNs started to first show up, but I don=92t really = consider it bleeding edge anymore.=20 Cheers, -Markus From nobody Tue Jun 24 01:33:41 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 E9C031A01B8 for ; Tue, 24 Jun 2014 01:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.752 X-Spam-Level: X-Spam-Status: No, score=-7.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_61=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 udtxszeCcGJC for ; Tue, 24 Jun 2014 01:33:38 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FC021A0165 for ; Tue, 24 Jun 2014 01:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9232; q=dns/txt; s=iport; t=1403598817; x=1404808417; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=UanRsIplM+M5IiDGHk3p3vn4HGX+EqW6UDXcTn9CdxQ=; b=jxqTs2XC2Ao9MJ8AONwi2z40OpdNVpo2+zo/LRcydWbhPnPGbxXy48Lv Z9p+GdbQlsWcGq15JAF8i30XHezH106LBs0fl5Jb/7HKX+7Yprs8edFgy 3EOqbG35UUBaMefdSC7cHuqbcKK5/hXLuPe4Pu4Pq0KaCu8oySw3IpUE6 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsGANk2qVOtJssW/2dsb2JhbABUBoNfqxkFAZF1h0ABgR11hAMBAQEDAQEBAWsBCAIFCwsYLiEGMAYTiC4DCQgNvh4NhikXhWOGdIFiEDMHgy2BFgSYUoF6gUWMGIYGggCBRDsvAQ X-IronPort-AV: E=Sophos;i="5.01,536,1400025600"; d="scan'208";a="96773676" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 24 Jun 2014 08:33:35 +0000 Received: from rtp-vpn4-88.cisco.com (rtp-vpn4-88.cisco.com [10.82.208.88]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5O8XRLM021598 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jun 2014 08:33:30 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ralph Schmieder In-Reply-To: <399DC567-F288-49A1-8801-3C0AA7674A3B@iki.fi> Date: Tue, 24 Jun 2014 10:33:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com> <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> <9FCED06B-006A-4194-9292-2DD26B53E694@iki.fi> <158F7E24-CA05-427A-B6DC-DBE8718447D4@apple.com> <93D479C0-E10E-4CF3-811E-B8670654D208@gmail.com> <399DC567-F288-49A1-8801-3C0AA7674A3B@iki.fi> To: Markus Stenberg X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/V1kUAaQt3O1YKrxRYENn3CfnHVk Cc: "dnssd@ietf.org" , Douglas Otis , Michael Sweet , Hosnieh Rafiee , "Tovey, Dwight \(LaserJet R&D FW Eng.\)" , Ralph Droms , Tom Pusateri Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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: Tue, 24 Jun 2014 08:33:40 -0000 On Jun 24, 2014, at 9:17 AM GMT+2, Markus Stenberg = wrote: > On 24.6.2014, at 5.07, Douglas Otis wrote: >> On Jun 19, 2014, at 7:55 AM, Markus Stenberg = wrote: >>> On 19.6.2014, at 17.43, Ralph Droms wrote: >>>> I haven't experimented with my printer. >>>>=20 >>>> I can imagine it might do IPv6 link-locals but not global address = assignment if it doesn't receive any RAs or hear from a DHCPv6 server. >>>>=20 >>>> I do know that many devices will happily use IPv6 link-locals to = communicate with devices discovered through DNS-SD/mDNS even if there is = no global IPv6 service/addresses available. >>>=20 >>> Certainly. >>>=20 >>> But if they accept RA (and do SLAAC based on it) or DHCPv6 = server-oriented address assignment, Douglas=92 claims of being safe = against evils of the world do not apply. >>>=20 >>> So I=92m still looking for the link-local-only IPv6 printer ;) >>>=20 >>> Given how predictable EUI-64 based addresses are, SLAAC-configured = printers may not even be very hard to find _without_ service discovery = if you=92re (say) running just one /64, and opponent knows = make/~approximate manufacturing date of your printer. >> There are several issues related to link-local addressing such as ULA = addresses commonly used in things like BTMM = http://tools.ietf.org/html/rfc4193. In that service, the ULA addresses = exposed are not routable and are accessed via a tunnel restricted by a = centralized authenticating service. In the case of mDNS Hybrid Proxies = http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid, this layer of = security does not exist and yet deceptively purports current use of the = related discovery strategy? This draft even goes on to describe = eventual mergers of .local domains which also necessitates recognizing = name collisions caused by multiple interface devices from those needing = reassignment.=20 >=20 > That draft forces you to route ULAs outside your organization?=20 >=20 >> In the case of the All-In-One Printer/Fax/Scanner/Media-Reader: >>=20 >> 1) How can a device be accessed when only a link-local address is = reported? >=20 > It cannot be. But I=92m still looking for that IPv6 link-local only = All-In-One Printer/Fax/Scanner/Media-Reader, please report one to me and = I=92ll consider this a problem ;) In fact, I do have a Canon printer which advertises a link-local address = only. It has, however, both: a link local AND a global IPv6 address = (which it does not tell about via mDNS). It's certainly an = implementation detail of the printer to include global IPv6 addresses in = the service advertisement but if it would be IPv6 only it could not be = used beyond the local subnet with that link-local address only. rtp-vpn4-88:Desktop rschmied$ dns-sd -B _ipp._tcp Browsing for _ipp._tcp DATE: ---Tue 24 Jun 2014--- 10:18:28.792 ...STARTING... Timestamp A/R Flags if Domain Service Type = Instance Name 10:18:28.792 Add 2 9 local. _ipp._tcp. = Canon MX920 series ^C rtp-vpn4-88:Desktop rschmied$ dns-sd -L 'Canon MX920 series' _ipp._tcp Lookup Canon MX920 series._ipp._tcp.local DATE: ---Tue 24 Jun 2014--- 10:18:38.967 ...STARTING... 10:18:39.169 Canon\032MX920\032series._ipp._tcp.local. can be reached = at Canon.local.:631 (interface 9) txtvers=3D1 rp=3Dipp/print note=3Dmylocation qtotal=3D1 priority=3D15 = ty=3DCanon\ MX920\ series product=3D\(Canon\ MX920\ series\) = pdl=3Dapplication/octet-stream,image/urf,image/jpeg = adminurl=3Dhttp://Canon.local./mainmenu.html usb_MFG=3DCanon = usb_MDL=3DMX920\ series usb_CMD=3DURF = UUID=3D00000000-0000-1000-8000-F481391493A7 = URF=3DV1.2,CP1,PQ4-5,RS600,SRGB24,W8,OB9,OFU0,DM3,IS11-13 Color=3DT = Duplex=3DT Scan=3DT Fax=3DF ^C rtp-vpn4-88:Desktop rschmied$ dns-sd -G v4v6 Canon.local. DATE: ---Tue 24 Jun 2014--- 10:18:57.335 ...STARTING... Timestamp A/R Flags if Hostname = Address TTL 10:18:57.335 Add 3 9 Canon.local. = FE80:0000:0000:0000:1A0C:ACFF:FEEB:938E%en4 60 10:18:57.335 Add 2 9 Canon.local. = 172.16.33.9 60 ^C rtp-vpn4-88:Desktop rschmied$=20 otherwise, I wholeheartedly agree with your below assessment. Extending = services beyond the local subnet for devices that do have a global IPv6 = address does not automatically expose those devices to the world. The visibility and accessibility of the device is still subject to = administration (apply BCPs) and like with split DNS one could certainly = make e.g. printers visible globally but one does not have to. Like with = Stuart's dns-sd.org domain: rtp-vpn4-88:Desktop rschmied$ dns-sd -B _ipp._tcp dns-sd.org. Browsing for _ipp._tcp.dns-sd.org. DATE: ---Tue 24 Jun 2014--- 10:24:44.550 ...STARTING... Timestamp A/R Flags if Domain Service Type = Instance Name 10:24:48.930 Add 3 0 dns-sd.org. _ipp._tcp. = 3rd. Floor Copy Room 10:24:48.930 Add 3 0 dns-sd.org. _ipp._tcp. = Sales 10:24:48.930 Add 3 0 dns-sd.org. _ipp._tcp. = Marketing 10:24:48.930 Add 3 0 dns-sd.org. _ipp._tcp. = Engineering 10:24:48.930 Add 2 0 dns-sd.org. _ipp._tcp. = Stuart's Home AirPrint Printer ^C rtp-vpn4-88:Desktop rschmied$ dns-sd -L "Stuart's Home AirPrint Printer" = _ipp._tcp dns-sd.org. Lookup Stuart's Home AirPrint Printer._ipp._tcp.dns-sd.org. DATE: ---Tue 24 Jun 2014--- 10:25:47.340 ...STARTING... 10:25:48.357 = Stuart's\032Home\032AirPrint\032Printer._ipp._tcp.dns-sd.org. can be = reached at airprint.dns-sd.org.:631 (interface 0) txtvers=3D1 qtotal=3D1 = pdl=3Dapplication/postscript,application/vnd.hp-PCL,application/vnd.hp-PCL= XL,application/pdf,image/urf rp=3Dipp/printer = URF=3DCP99,W8,OB10,PQ3-4-5,ADOBERGB24,DEVRGB24,DEVW8,SRGB24,IS1-2-4,MT1-2-= 3-5-12,MT1-2-3-5-12,RS600 ty=3DHP\ LaserJet\ 400\ color\ M451nw = product=3D\(HP\ LaserJet\ 400\ color\ M451nw\) priority=3D10 = adminurl=3Dhttp://www.dns-sd.org/ServerStaticSetup.html note=3DAt\ = Stuart\'s\ house Color=3DT Duplex=3DF Scan=3DF ^C rtp-vpn4-88:Desktop rschmied$ dns-sd -Gv4v6 airprint.dns-sd.org. DATE: ---Tue 24 Jun 2014--- 10:26:01.411 ...STARTING... Timestamp A/R Flags if Hostname = Address TTL 10:26:01.412 Add 2 0 airprint.dns-sd.org. = 173.164.252.149 77 10:26:02.266 Add 2 0 airprint.dns-sd.org. = 0000:0000:0000:0000:0000:0000:0000:0000%<0> 77 No Such Record ^C rtp-vpn4-88:Desktop rschmied$=20 Does the visibility imply that the printers I see are reachable or even = existing? No. Does internal visibility imply external visibility? No. Is he forced to publish that information and make it visible to me? No. Thanks, -ralph >=20 >> 2) How are routable addresses discovered when link-local is returned = by mDNS? >=20 > They are not. >=20 >> 3) How can devices be secured when SLACC or DHCPv6 addresses are = being indirectly exposed? >=20 > Firewalls are traditional way of protecting _any_ addresses. IPv6 = linklocals _and_ ULAs provide added property of not being globally = routable, just like RFC1918 IPv4 addresses. >=20 >> 4) How will disparate .local domains be merged? >=20 > They need not be. Read hybrid draft + RFC6763, especially on the = =91browse domain _list_=92 part. >=20 > Merging is just (ugly) glue that could deal with broken clients which = handle only either pure mdns, or single list of entries-style dns-sd = (=91legacy browse domain=92 is the term in RFC6763). >=20 >> While one might attempt to guess likely SLACC assignments out of a = possible range likely in the millions, users are also free to manually = assign addresses. If a problem is discovered, this strategy would give = malefactors a guessing range of about 9 quintillion. Of course, unusual = levels of address probing can be detected and blocked. Automated = DNS-Based Service Discovery http://tools.ietf.org/html/rfc6763 as = suggested, precludes malefactors even needing to make a series of = guesses. Of course, IPsec tunneling represents viable strategy that = might be used, but this no longer offers zero configuration. It seems = unauthenticated exposure of even ULAs has a fair amount of security = related risk doesn=92t it? >=20 > Nothing forces you to export those hybrid proxy / DNS-SD zones outside = your organization. Split horizon DNS was state of the art in late 90s = when (IPsec) VPNs started to first show up, but I don=92t really = consider it bleeding edge anymore.=20 >=20 > Cheers, >=20 > -Markus >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Tue Jun 24 18:26:14 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 7371E1B2A11 for ; Tue, 24 Jun 2014 18:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 judJsWtq_I4p for ; Tue, 24 Jun 2014 18:26:08 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8011B2A0C for ; Tue, 24 Jun 2014 18:26:08 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id y10so942174pdj.5 for ; Tue, 24 Jun 2014 18:26:08 -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:cc :message-id:references:to; bh=+/1QsN6OvmHTyib8+HJ2TTRfKYkCELfNcj1D9ntRvBI=; b=FF53dsng7TpBZB0eP/iUvdAILmU2u/M2OiYP4BBWSemvTQONsaFbdQKEh/8ZXx8lyj MXClFPAuwkE59ZI4/nLtv6RN6MvqYLXWuhiwfzz7ddlN39LcZYib1VLOSPQ2poXlhJK2 PlQxcjSv5JJ3/w5YFvbcnvWeoNchmB3dERAxuVecrCIeblB2FFv9d+/c0+T19lo0nuPv EkagrwC+KhEuG5SeroTxgdNlQPsGFrHCdQRoEjV8x8Rfgjvnwf2X69hYgnc4PPwBKsHC VWeOe+zSpVNH5M2jXHEieFOmjUZy4w3hL7jkKK7aRbCSOnGss1ichOoy5Fepfx8dabCp gyKw== X-Received: by 10.66.66.133 with SMTP id f5mr6443744pat.81.1403659567958; Tue, 24 Jun 2014 18:26:07 -0700 (PDT) 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 wk4sm9389491pab.5.2014.06.24.18.26.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Jun 2014 18:26:07 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_32981A45-3D20-44BA-B820-025DB651DFAB" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: <399DC567-F288-49A1-8801-3C0AA7674A3B@iki.fi> Date: Tue, 24 Jun 2014 18:25:39 -0700 Message-Id: <6C5E88EB-BCDB-4BDE-9B6B-9895E06689D1@gmail.com> References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com> <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> <9FCED06B-006A-4194-9292-2DD26B53E694@iki.fi> <158F7E24-CA05-427A-B6DC-DBE8718447D4@apple.com> <93D479C0-E10E-4CF3-811E-B8670654D208@gmail.com> <399DC567-F288-49A1-8801-3C0AA7674A3B@iki.fi> To: Markus Stenberg X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/2s0shg3Bxfzny1aJu4neobfbG4A Cc: "dnssd@ietf.org" , Michael Sweet , Hosnieh Rafiee , "Tovey, Dwight \(LaserJet R&D FW Eng.\)" , Ralph Droms , Tom Pusateri Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 25 Jun 2014 01:26:12 -0000 --Apple-Mail=_32981A45-3D20-44BA-B820-025DB651DFAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 24, 2014, at 12:17 AM, Markus Stenberg = wrote: > On 24.6.2014, at 5.07, Douglas Otis wrote: >> On Jun 19, 2014, at 7:55 AM, Markus Stenberg = wrote: >>> On 19.6.2014, at 17.43, Ralph Droms wrote: >>>> I haven't experimented with my printer. >>>>=20 >>>> I can imagine it might do IPv6 link-locals but not global address = assignment if it doesn't receive any RAs or hear from a DHCPv6 server. >>>>=20 >>>> I do know that many devices will happily use IPv6 link-locals to = communicate with devices discovered through DNS-SD/mDNS even if there is = no global IPv6 service/addresses available. >>>=20 >>> Certainly. >>>=20 >>> But if they accept RA (and do SLAAC based on it) or DHCPv6 = server-oriented address assignment, Douglas=92 claims of being safe = against evils of the world do not apply. >>>=20 >>> So I=92m still looking for the link-local-only IPv6 printer ;) >>>=20 >>> Given how predictable EUI-64 based addresses are, SLAAC-configured = printers may not even be very hard to find _without_ service discovery = if you=92re (say) running just one /64, and opponent knows = make/~approximate manufacturing date of your printer. >>=20 >> There are several issues related to link-local addressing such as ULA = addresses commonly used in things like BTMM = http://tools.ietf.org/html/rfc4193. In that service, the ULA addresses = exposed are not routable and are accessed via a tunnel restricted by a = centralized authenticating service. In the case of mDNS Hybrid Proxies = http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid, this layer of = security does not exist and yet deceptively purports current use of the = related discovery strategy? This draft even goes on to describe = eventual mergers of .local domains which also necessitates recognizing = name collisions caused by multiple interface devices from those needing = reassignment.=20 >=20 > That draft forces you to route ULAs outside your organization?=20 The draft only suggests link-local addresses should not be published via = DNS. It also adds confusing statements regarding token-ring routing = which relies on the MAC. ,--- In particular, if any device forwarding a packet modifies any part of the IP header or IP payload then the packet is no longer considered to be on the same link. This means that the packet may pass through devices such as repeaters, bridges, hubs or switches and still be considered to be on the same link for the purpose of this document, but not through a device such as an IP router that decrements the TTL or otherwise modifies the IP header. '--- Can't tell where the document is headed, but it is not hard to imagine a = scheme for converting ULA into routable. The statement "on the same = link for the purpose of this document" remains unclear while it also = describes packets carried through bridges, repeaters, and hubs with a = provisional requirement TTLs are not to be decremented. It seems this = too represents yet another potential security concern as this defeats = loop detection and greatly simplifies data exfiltration.=20 >> In the case of the All-In-One Printer/Fax/Scanner/Media-Reader: >>=20 >> 1) How can a device be accessed when only a link-local address is = reported? >=20 > It cannot be. But I=92m still looking for that IPv6 link-local only = All-In-One Printer/Fax/Scanner/Media-Reader, please report one to me and = I=92ll consider this a problem ;) >=20 >> 2) How are routable addresses discovered when link-local is returned = by mDNS? >=20 > They are not. Perhaps this limitation should be CLEARLY stated, such as the = recommended suppression of link-local excludes suppression of ULAs = http://tools.ietf.org/html/rfc4193 which seems likely derived outside of = mDNS resolutions. Hard to judge an undefined mechanism.=20 >> 3) How can devices be secured when SLACC or DHCPv6 addresses are = being indirectly exposed? >=20 > Firewalls are traditional way of protecting _any_ addresses. IPv6 = linklocals _and_ ULAs provide added property of not being globally = routable, just like RFC1918 IPv4 addresses. While link-local addressing is often critical in establishing firewall = protection, such addressing may also inhibit adjacent link access. The = language in mDNS Hybrid-Proxy document is fairly opaque with references = to Token-Ring for example. It also lacks meaningful security = considerations clarifying how secure adjacent link communications is = established and possible details that might relate to a split DNS = configuration. By failing to include suppression of ULAs (used in = BTTM), should one assume a site-specific policy will cause preferences = for locally directed ULAs? If so, how is that preference secured? >> 4) How will disparate .local domains be merged? >=20 > They need not be. Read hybrid draft + RFC6763, especially on the = =91browse domain _list_=92 part. Once again this overlooks mDNS returns link-local addressing which is = not to be placed into DNS per draft-cheshire-mdnsext-hybrid. While = logical, this lacks details that are necessary to properly establish = possible security concerns. > Merging is just (ugly) glue that could deal with broken clients which = handle only either pure mdns, or single list of entries-style dns-sd = (=91legacy browse domain=92 is the term in RFC6763). This is not about dealing with pure mDNS or legacy DNS-SD browsing.=20 3. Hybrid Proxy Operation ,--- [..] a Hybrid Proxy gets its data by performing a Multicast DNS query (e.g., "_printer._tcp.local. PTR ?") on its local link, and then, from the Multicast DNS replies it receives, it generates a corresponding Unicast DNS reply. '--- Details should be offered regarding the reply construction with = specifics and even examples. =20 >> While one might attempt to guess likely SLACC assignments out of a = possible range likely in the millions, users are also free to manually = assign addresses. If a problem is discovered, this strategy would give = malefactors a guessing range of about 9 quintillion. Of course, unusual = levels of address probing can be detected and blocked. Automated = DNS-Based Service Discovery http://tools.ietf.org/html/rfc6763 as = suggested, precludes malefactors even needing to make a series of = guesses. Of course, IPsec tunneling represents viable strategy that = might be used, but this no longer offers zero configuration. It seems = unauthenticated exposure of even ULAs has a fair amount of security = related risk doesn=92t it? >=20 > Nothing forces you to export those hybrid proxy / DNS-SD zones outside = your organization. Split horizon DNS was state of the art in late 90s = when (IPsec) VPNs started to first show up, but I don=92t really = consider it bleeding edge anymore. We have been struggling at providing even a modicum of security when = browser plugins are used in conjunction with various websites. With the = abundance of obfuscated javascript, it seems unlikely sensitive portions = of DNS can remain hidden. In such cases, there should be an effort to = enumerate security implications of DNS related exfiltration that defeats = efforts at securing devices that depend on remaining isolated from = direct Internet access. These might represent embedded devices having = vulnerable firmware that the user is unable to update or even the = All-in-One printer. Similar issues concern defenses based on which end = originates a session. Again, details are lacking regarding specifics of the creation of a DNS = reply for a protected device and how related information is secured.=20 Regards, Douglas Otis= --Apple-Mail=_32981A45-3D20-44BA-B820-025DB651DFAB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jun 24, 2014, at 12:17 AM, Markus = Stenberg <markus.stenberg@iki.fi> = wrote:

On 24.6.2014, at 5.07, Douglas Otis <doug.mtview@gmail.com> = wrote:
On Jun 19, 2014, at 7:55 AM, Markus = Stenberg <markus.stenberg@iki.fi> = wrote:
On 19.6.2014, at 17.43, Ralph Droms = <rdroms.ietf@gmail.com>= wrote:
I haven't experimented with my = printer.

I can imagine it might do IPv6 link-locals but not = global address assignment if it doesn't receive any RAs or hear from a = DHCPv6 server.

I do know that many devices will happily use IPv6 = link-locals to communicate with devices discovered through DNS-SD/mDNS = even if there is no global IPv6 service/addresses = available.

Certainly.

But if they accept RA = (and do SLAAC based on it) or DHCPv6 server-oriented address assignment, = Douglas=92 claims of being safe against evils of the world do not = apply.

So I=92m still looking for the link-local-only IPv6 = printer ;)

Given how predictable EUI-64 based addresses are, = SLAAC-configured printers may not even be very hard to find _without_ = service discovery if you=92re (say) running just one /64, and opponent = knows make/~approximate manufacturing date of your = printer.

There are several issues related = to link-local addressing such as ULA addresses commonly used in things = like BTMM http://tools.ietf.org/html/rfc= 4193. In that service, the ULA addresses exposed are not routable = and are accessed via a tunnel restricted by a centralized authenticating = service.  In the case of mDNS Hybrid Proxies http://t= ools.ietf.org/html/draft-cheshire-mdnsext-hybrid, this layer of = security does not exist and yet deceptively purports current use of the = related discovery strategy?  This draft even goes on to describe = eventual mergers of .local domains which also necessitates recognizing = name collisions caused by multiple interface devices from those needing = reassignment. 

That draft forces you to route ULAs outside your = organization?

The draft only = suggests link-local addresses should not be published via DNS.  It = also adds confusing statements regarding token-ring routing which relies = on the MAC.
,---
In particular, if
any device = forwarding a packet modifies any part of the IP header or
IP = payload then the packet is no longer considered to be on the = same
link.  This means that the packet may pass through = devices such as
repeaters, bridges, hubs or switches and still = be considered to be on
the same link for the purpose of this = document, but not through a
device such as an IP router that = decrements the TTL or otherwise
modifies the IP = header.
'---

Can't tell where the document is headed, = but it is not hard to imagine a scheme for converting ULA into routable. =  The statement "on the same link for the purpose of this document" = remains unclear while it also describes packets carried through bridges, = repeaters, and hubs with a provisional requirement TTLs are not to be = decremented.  It seems this too represents yet another potential = security concern as this defeats loop detection and greatly simplifies = data exfiltration. 

In the case of the All-In-One = Printer/Fax/Scanner/Media-Reader:

1) How can a device be accessed = when only a link-local address is reported?

It = cannot be. But I=92m still looking for that IPv6 link-local only = All-In-One Printer/Fax/Scanner/Media-Reader, please report one to me and = I=92ll consider this a problem ;)

2) = How are routable addresses discovered when link-local is returned by = mDNS?

They are = not.

Perhaps this limitation should = be CLEARLY stated, such as the recommended suppression of link-local = excludes suppression of ULAs http://tools.ietf.org/html/rfc= 4193 which seems likely derived outside of mDNS resolutions. =  Hard to judge an undefined = mechanism. 

3) How can devices be secured when SLACC or DHCPv6 = addresses are being indirectly exposed?

Firewalls = are traditional way of protecting _any_ addresses. IPv6 linklocals _and_ = ULAs provide added property of not being globally routable, just like = RFC1918 IPv4 addresses.

While = link-local addressing is often critical in establishing firewall = protection, such addressing may also inhibit adjacent link access. =  The language in mDNS Hybrid-Proxy document is fairly opaque with = references to Token-Ring for example.  It also lacks meaningful = security considerations clarifying how secure adjacent link = communications is established and possible details that might relate to = a split DNS configuration.  By failing to include suppression of = ULAs (used in BTTM), should one assume a site-specific policy will cause = preferences for locally directed ULAs?  If so, how is that = preference secured?

4) How will disparate .local domains be = merged?

They need not be. Read hybrid draft + = RFC6763, especially on the =91browse domain _list_=92 = part.

Once again this overlooks mDNS = returns link-local addressing which is not to be placed into DNS = per draft-ch= eshire-mdnsext-hybrid.  While logical, this lacks details that = are necessary to properly establish possible security = concerns.

Merging is just (ugly) glue = that could deal with broken clients which handle only either pure mdns, = or single list of entries-style dns-sd (=91legacy browse domain=92 is = the term in RFC6763).

This is not about dealing with pure mDNS or legacy = DNS-SD browsing. 

3.  Hybrid Proxy = Operation
,---
[..] a Hybrid Proxy gets its = data by performing a Multicast DNS
query (e.g., = "_printer._tcp.local.  PTR ?") on its local link, = and
then, from the Multicast DNS replies it receives, it = generates a
corresponding Unicast DNS = reply.
'---

Details should be = offered regarding the reply construction with specifics and even = examples.  

While one might attempt to guess likely SLACC assignments = out of a possible range likely in the millions, users are also free to = manually assign addresses.  If a problem is discovered, this = strategy would give malefactors a guessing range of about 9 quintillion. =  Of course, unusual levels of address probing can be detected and = blocked.  Automated DNS-Based Service Discovery http://tools.ietf.org/html/rfc= 6763 as suggested, precludes malefactors even needing to make a = series of guesses.  Of course, IPsec tunneling represents viable = strategy that might be used, but this no longer offers zero = configuration. It seems unauthenticated exposure of even ULAs has a fair = amount of security related risk doesn=92t = it?

Nothing forces you to export those hybrid proxy = / DNS-SD zones outside your organization. Split horizon DNS was state of = the art in late 90s when (IPsec) VPNs started to first show up, but =  I don=92t really consider it bleeding edge = anymore.

We have been struggling at = providing even a modicum of security when browser plugins are used in = conjunction with various websites.  With the abundance of = obfuscated javascript, it seems unlikely sensitive portions of DNS can = remain hidden.  In such cases, there should be an effort to = enumerate security implications of DNS related exfiltration that defeats = efforts at securing devices that depend on remaining isolated from = direct Internet access.  These might represent embedded devices = having vulnerable firmware that the user is unable to update or even the = All-in-One printer.  Similar issues concern defenses based on which = end originates a session.

Again, details are = lacking regarding specifics of the creation of a DNS reply for a = protected device and how related information is = secured. 

Regards,
Douglas = Otis
= --Apple-Mail=_32981A45-3D20-44BA-B820-025DB651DFAB-- From nobody Wed Jun 25 00:24:45 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 288C81B2AE0 for ; Wed, 25 Jun 2014 00:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2j7gFl7tdrBU for ; Wed, 25 Jun 2014 00:24:40 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.199]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6721B2AE9 for ; Wed, 25 Jun 2014 00:24:40 -0700 (PDT) Received: from poro.lan (84.248.74.106) by kirsi1.inet.fi (8.5.140.03) (authenticated as stenma-47) id 53A1810C007A5C8E; Wed, 25 Jun 2014 10:24:37 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Markus Stenberg In-Reply-To: <6C5E88EB-BCDB-4BDE-9B6B-9895E06689D1@gmail.com> Date: Wed, 25 Jun 2014 10:24:34 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <70F7F734-8FBD-4BDC-B1BB-D2D242D7E963@iki.fi> References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com> <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> <9FCED06B-006A-4194-9292-2DD26B53E694@iki.fi> <158F7E24-CA05-427A-B6DC-DBE8718447D4@apple.com> <93D479C0-E10E-4CF3-811E-B8670654D208@gmail.com> <399DC567-F288-49A1-8801-3C0AA7674A3B@iki.fi> <6C5E88EB-BCDB-4BDE-9B6B-9895E06689D1@gmail.com> To: Douglas Otis X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/XHxVmESQQ-thxhyyq5b8Duk2KJU Cc: "dnssd@ietf.org" , Markus Stenberg , Michael Sweet , Hosnieh Rafiee , "Tovey, Dwight \(LaserJet R&D FW Eng.\)" , Ralph Droms , Tom Pusateri Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 25 Jun 2014 07:24:43 -0000 This is my last email in this thread, I promise.=20 On 25.6.2014, at 4.25, Douglas Otis wrote: >> That draft forces you to route ULAs outside your organization?=20 > The draft only suggests link-local addresses should not be published = via DNS. It also adds confusing statements regarding token-ring routing = which relies on the MAC. > ,--- > In particular, if > any device forwarding a packet modifies any part of the IP header or > IP payload then the packet is no longer considered to be on the same > link. This means that the packet may pass through devices such as > repeaters, bridges, hubs or switches and still be considered to be on > the same link for the purpose of this document, but not through a > device such as an IP router that decrements the TTL or otherwise > modifies the IP header. > =91--- > Can't tell where the document is headed, but it is not hard to imagine = a scheme for converting ULA into routable. The statement "on the same = link for the purpose of this document" remains unclear while it also = describes packets carried through bridges, repeaters, and hubs with a = provisional requirement TTLs are not to be decremented. It seems this = too represents yet another potential security concern as this defeats = loop detection and greatly simplifies data exfiltration.=20 I can=92t usually tell where any document is headed, especially not = being an author. However, it defines link boundary as not changing IP = header _or_ payload, and that it operates only on one link. So if you = want =91better guarantees=92, ask the author to write some sort of = solemn promise not to change the contents of IP header or something. >>> 2) How are routable addresses discovered when link-local is returned = by mDNS? >> They are not. > Perhaps this limitation should be CLEARLY stated, such as the = recommended suppression of link-local excludes suppression of ULAs = http://tools.ietf.org/html/rfc4193 which seems likely derived outside of = mDNS resolutions. Hard to judge an undefined mechanism.=20 Quoting section 3.1: Generating the corresponding Unicast DNS reply involves, at the very least, rewriting the "local" suffix to the appropriate Unicast DNS domain (e.g., "Building 1.example.com"). In addition it would be desirable to suppress Unicast DNS replies for records that are not useful outside the local link. For example, DNS A and AAAA records for IPv4 link-local addresses [RFC3927] and IPv6 link-local addresses [RFC4862] should be suppressed. .. Second paragraph states that fairly clearly to me (somewhat elided). >>> 4) How will disparate .local domains be merged? >> They need not be. Read hybrid draft + RFC6763, especially on the = =91browse domain _list_=92 part. > Once again this overlooks mDNS returns link-local addressing which is = not to be placed into DNS per draft-cheshire-mdnsext-hybrid. While = logical, this lacks details that are necessary to properly establish = possible security concerns. See above, the naming (lack of) merging is handled in first paragraph = and the link-local logic in the second one. =91Get reply. If it=92s link-local only, drop. If not, pass along to = client.=92 If you have better text, contact mr. Cheshire ;) Cheers, -Markus From nobody Wed Jun 25 12:44:25 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 44D571B2E58 for ; Wed, 25 Jun 2014 12:44:24 -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 b1M7umu6JeTZ for ; Wed, 25 Jun 2014 12:44:21 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD90E1B2E56 for ; Wed, 25 Jun 2014 12:44:21 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id rd3so2124648pab.17 for ; Wed, 25 Jun 2014 12:44:21 -0700 (PDT) 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=reRSctmWopBkq8B+Col5SThX4EE4NvslK2zd6983qXQ=; b=ShLcTNpGUqiFYmpbKROkUyDKEv+mu7EM+2B6eaayI90abf4yhSUZdqqL0wMoTaW9Pr /mQlkD7U0yXKHFC7ViunkYdlcvfoo7AfkB4oAE5Q8JZARuhYCczJLt5OuoDzut8aCMxh O84OjUWv6vCD1wbrDqCPRlz+WmJzeHUvMazCoJWZlhDfimeZnzFyE2pdBv1hESZwiYdM qVjMa8Ep4VmepqP9B8N7TDsZQswL2H6IT1y9q/t5+GeMvFOVj+MfGDjFcPclQqYpdC0I yHHAR06BO5UiDC0xWwQo10nBLIN6Lt/Cg6eoR4JUgvQb7f4RbHXPhbGJjWxQ1xrUVwUh 3Lhw== X-Received: by 10.68.197.134 with SMTP id iu6mr14901049pbc.164.1403725461480; Wed, 25 Jun 2014 12:44:21 -0700 (PDT) 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 vx10sm22644205pac.17.2014.06.25.12.44.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Jun 2014 12:44:20 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=windows-1252 From: Douglas Otis In-Reply-To: <70F7F734-8FBD-4BDC-B1BB-D2D242D7E963@iki.fi> Date: Wed, 25 Jun 2014 12:44:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com> <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> <9FCED06B-006A-4194-9292-2DD26B53E694@iki.fi> <158F7E24-CA05-427A-B6DC-DBE8718447D4@apple.com> <93D479C0-E10E-4CF3-811E-B8670654D208@gmail.com> <399DC567-F288-49A1-8801-3C0AA7674A3B@iki.fi> <6C5E88EB-BCDB-4BDE-9B6B-9895E06689D1@gmail.com> <70F7F734-8FBD-4BDC-B1BB-D2D242D7E963@iki.fi> To: Markus Stenberg X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/fvLtaCJ0BZJoY2iHyUfnuzr7gU4 Cc: Stuart Cheshire , "dnssd@ietf.org" , Michael Sweet , Hosnieh Rafiee , "Tovey, Dwight \(LaserJet R&D FW Eng.\)" , Ralph Droms , Tom Pusateri Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 25 Jun 2014 19:44:24 -0000 Dear Markus, Thank you for your response. See comments inline: On Jun 25, 2014, at 12:24 AM, Markus Stenberg = wrote: > This is my last email in this thread, I promise.=20 >=20 > On 25.6.2014, at 4.25, Douglas Otis wrote: >>> That draft forces you to route ULAs outside your organization?=20 >> The draft only suggests link-local addresses should not be published = via DNS. It also adds confusing statements regarding token-ring routing = which relies on the MAC. >> ,--- >> In particular, if >> any device forwarding a packet modifies any part of the IP header or >> IP payload then the packet is no longer considered to be on the same >> link. This means that the packet may pass through devices such as >> repeaters, bridges, hubs or switches and still be considered to be on >> the same link for the purpose of this document, but not through a >> device such as an IP router that decrements the TTL or otherwise >> modifies the IP header. >> =91--- >> Can't tell where the document is headed, but it is not hard to = imagine a scheme for converting ULA into routable. The statement "on = the same link for the purpose of this document" remains unclear while it = also describes packets carried through bridges, repeaters, and hubs with = a provisional requirement TTLs are not to be decremented. It seems this = too represents yet another potential security concern as this defeats = loop detection and greatly simplifies data exfiltration.=20 >=20 > I can=92t usually tell where any document is headed, especially not = being an author. However, it defines link boundary as not changing IP = header _or_ payload, and that it operates only on one link. So if you = want =91better guarantees=92, ask the author to write some sort of = solemn promise not to change the contents of IP header or something. >=20 >>>> 2) How are routable addresses discovered when link-local is = returned by mDNS? >>> They are not. >> Perhaps this limitation should be CLEARLY stated, such as the = recommended suppression of link-local excludes suppression of ULAs = http://tools.ietf.org/html/rfc4193 which seems likely derived outside of = mDNS resolutions. Hard to judge an undefined mechanism.=20 >=20 > Quoting section 3.1: >=20 > Generating the corresponding Unicast DNS reply involves, at the very > least, rewriting the "local" suffix to the appropriate Unicast DNS > domain (e.g., "Building 1.example.com"). >=20 > In addition it would be desirable to suppress Unicast DNS replies = for > records that are not useful outside the local link. For example, = DNS > A and AAAA records for IPv4 link-local addresses [RFC3927] and IPv6 > link-local addresses [RFC4862] should be suppressed. .. >=20 > Second paragraph states that fairly clearly to me (somewhat elided). This document would be clearer by not remaining silent on use of ULAs. = But ignoring that, even assuming link-local AND ULAs addresses are not = conveyed, the overly simplified description of mDNS Hybrid Proxy = operation will result in a significant security exposure. This is = illustrated in a comparison of how a similar scheme works with BTTM. = Only devices able to authenticate with a ULA endpoint tunnel is exposed = within DNS where any non-authenticating device's resources are = suppressed whether or not mDNS offers a routable IP address. The = published authenticating devices are then able to forward traffic to = non-authenticating devices such as printers. Do you see the problem? = It is a major security concern assuming split horizon DNS offers a = reasonable level of security to protect much simpler devices.=20 >>>> 4) How will disparate .local domains be merged? >>> They need not be. Read hybrid draft + RFC6763, especially on the = =91browse domain _list_=92 part. >> Once again this overlooks mDNS returns link-local addressing which is = not to be placed into DNS per draft-cheshire-mdnsext-hybrid. While = logical, this lacks details that are necessary to properly establish = possible security concerns. >=20 > See above, the naming (lack of) merging is handled in first paragraph = and the link-local logic in the second one. >=20 > =91Get reply. If it=92s link-local only, drop. If not, pass along to = client.=92 As said before, this scheme has a significant security flaw relying on = split-horizon DNS services. No direct path should be published for = devices unable to authenticate external sessions. This may not be of = great concern for Stuart since his company is already doing the "right = thing". The "right thing" should also be expressed in this mDNS Hybrid = specification. This should include an explanation of possible ULA use = and an added requirement to suppress DNS publication of devices unable = to authenticate external sessions. I have included Mr. Cheshire in this thread. Regards, Douglas Otis From nobody Wed Jun 25 18:44:06 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 F2B4C1B2A21 for ; Wed, 25 Jun 2014 18:44:03 -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 7Uy0sTmvNH7J for ; Wed, 25 Jun 2014 18:44:02 -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 F30841B2ED6 for ; Wed, 25 Jun 2014 18:44:00 -0700 (PDT) Received: from [172.16.21.114] (cpe-098-122-037-156.sc.res.rr.com [98.122.37.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id A1B2B13680; Wed, 25 Jun 2014 21:43:58 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1962.2\)) From: Tom Pusateri In-Reply-To: Date: Wed, 25 Jun 2014 21:43:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com> <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> <9FCED06B-006A-4194-9292-2DD26B53E694@iki.fi> <158F7E24-CA05-427A-B6DC-DBE8718447D4@apple.com> <93D479C0-E10E-4CF3-811E-B8670654D208@gmail.com> <399DC567-F288-49A1-8801-3C0AA7674A3B@iki.fi> <6C5E88EB-BCDB-4BDE-9B6B-9895E06689D1@gmail.com> <70F7F734-8FBD-4BDC-B1BB-D2D242D7E963@iki.fi> To: Douglas Otis X-Mailer: Apple Mail (2.1962.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/Ab3luxXp4eaZv-13c2tJwBpUWz4 Cc: Stuart Cheshire , "dnssd@ietf.org" , Markus Stenberg , Michael Sweet , Hosnieh Rafiee , "Tovey, Dwight \(LaserJet R&D FW Eng.\)" , Ralph Droms Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 26 Jun 2014 01:44:04 -0000 Douglas, The basis of your unsupported accusations is that publishing the = existence of services in DNS is somehow a "significant security flaw" = but you continue to ignore my initial point that the security of = services is independent from the announcement and relies solely on the = security of the network node providing the service. You ignore the fact that most services are attacked as a result of port = scans and not because of published DNS entries. Machines are taken over all the time and bots attack link local = neighbors. The whole addressing argument is a straw man. You have not shown in any way that Hybrid Proxies create security flaws. Tom > On Jun 25, 2014, at 3:44 PM, Douglas Otis = wrote: >=20 > Dear Markus, >=20 > Thank you for your response. See comments inline: > On Jun 25, 2014, at 12:24 AM, Markus Stenberg = wrote: >=20 >> This is my last email in this thread, I promise.=20 >>=20 >> On 25.6.2014, at 4.25, Douglas Otis wrote: >>>> That draft forces you to route ULAs outside your organization?=20 >>> The draft only suggests link-local addresses should not be published = via DNS. It also adds confusing statements regarding token-ring routing = which relies on the MAC. >>> ,--- >>> In particular, if >>> any device forwarding a packet modifies any part of the IP header or >>> IP payload then the packet is no longer considered to be on the same >>> link. This means that the packet may pass through devices such as >>> repeaters, bridges, hubs or switches and still be considered to be = on >>> the same link for the purpose of this document, but not through a >>> device such as an IP router that decrements the TTL or otherwise >>> modifies the IP header. >>> =91--- >>> Can't tell where the document is headed, but it is not hard to = imagine a scheme for converting ULA into routable. The statement "on = the same link for the purpose of this document" remains unclear while it = also describes packets carried through bridges, repeaters, and hubs with = a provisional requirement TTLs are not to be decremented. It seems this = too represents yet another potential security concern as this defeats = loop detection and greatly simplifies data exfiltration.=20 >>=20 >> I can=92t usually tell where any document is headed, especially not = being an author. However, it defines link boundary as not changing IP = header _or_ payload, and that it operates only on one link. So if you = want =91better guarantees=92, ask the author to write some sort of = solemn promise not to change the contents of IP header or something. >>=20 >>>>> 2) How are routable addresses discovered when link-local is = returned by mDNS? >>>> They are not. >>> Perhaps this limitation should be CLEARLY stated, such as the = recommended suppression of link-local excludes suppression of ULAs = http://tools.ietf.org/html/rfc4193 which seems likely derived outside of = mDNS resolutions. Hard to judge an undefined mechanism.=20 >>=20 >> Quoting section 3.1: >>=20 >> Generating the corresponding Unicast DNS reply involves, at the very >> least, rewriting the "local" suffix to the appropriate Unicast DNS >> domain (e.g., "Building 1.example.com"). >>=20 >> In addition it would be desirable to suppress Unicast DNS replies = for >> records that are not useful outside the local link. For example, = DNS >> A and AAAA records for IPv4 link-local addresses [RFC3927] and IPv6 >> link-local addresses [RFC4862] should be suppressed. .. >>=20 >> Second paragraph states that fairly clearly to me (somewhat elided). >=20 > This document would be clearer by not remaining silent on use of ULAs. = But ignoring that, even assuming link-local AND ULAs addresses are not = conveyed, the overly simplified description of mDNS Hybrid Proxy = operation will result in a significant security exposure. This is = illustrated in a comparison of how a similar scheme works with BTTM. = Only devices able to authenticate with a ULA endpoint tunnel is exposed = within DNS where any non-authenticating device's resources are = suppressed whether or not mDNS offers a routable IP address. The = published authenticating devices are then able to forward traffic to = non-authenticating devices such as printers. Do you see the problem? = It is a major security concern assuming split horizon DNS offers a = reasonable level of security to protect much simpler devices.=20 >=20 >>>>> 4) How will disparate .local domains be merged? >>>> They need not be. Read hybrid draft + RFC6763, especially on the = =91browse domain _list_=92 part. >>> Once again this overlooks mDNS returns link-local addressing which = is not to be placed into DNS per draft-cheshire-mdnsext-hybrid. While = logical, this lacks details that are necessary to properly establish = possible security concerns. >>=20 >> See above, the naming (lack of) merging is handled in first paragraph = and the link-local logic in the second one. >>=20 >> =91Get reply. If it=92s link-local only, drop. If not, pass along to = client.=92 >=20 > As said before, this scheme has a significant security flaw relying on = split-horizon DNS services. No direct path should be published for = devices unable to authenticate external sessions. This may not be of = great concern for Stuart since his company is already doing the "right = thing". The "right thing" should also be expressed in this mDNS Hybrid = specification. This should include an explanation of possible ULA use = and an added requirement to suppress DNS publication of devices unable = to authenticate external sessions. >=20 > I have included Mr. Cheshire in this thread. >=20 > Regards, > Douglas Otis >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Wed Jun 25 21:27:15 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 3118D1B2A8F for ; Wed, 25 Jun 2014 21:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 Q19iXt4Ef_KQ for ; Wed, 25 Jun 2014 21:27:07 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4AF11B2A7B for ; Wed, 25 Jun 2014 21:27:07 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id rd3so2628662pab.31 for ; Wed, 25 Jun 2014 21:27:07 -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:cc :message-id:references:to; bh=ogj7QDqburvpPpDsk2AUQEnhEg7/iq72HoS0F14tREw=; b=pJq61/OvPGHIaxz+ZvBSAPUCrQZJ1dv1XhL+9toYdN0rpGiauIaAHvHF0ze4FiYjCt 6Vhdif9ziKb5O4SOXMIYDtRFCgPAtIwvf9sBsNHE1mSi5//uGphpLEo7J31Krjd1lbwp kn8KpZ8HguwTTIjHBPbywg5lhmK3AMTsBEqK2lhUVUWqAjQLAT+C9JrXi8cu5JeSSA4o N7ekMtnGmn5DjccHmph4LwJYrZvBf86BE87oLX0IiUjjfLkMqgnvfzLlatl162iVX0T0 52J82MKNyuMOcCGs3/YNZ+aEbOUJpyM9basTPyfUC9s4WMilv+HSAvJFVcRBTu23b5JZ oxog== X-Received: by 10.68.231.229 with SMTP id tj5mr17574201pbc.101.1403756827358; Wed, 25 Jun 2014 21:27:07 -0700 (PDT) Received: from ?IPv6:2601:9:7680:203:ddba:86d2:c806:c633? ([2601:9:7680:203:ddba:86d2:c806:c633]) by mx.google.com with ESMTPSA id io6sm28059837pac.44.2014.06.25.21.27.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Jun 2014 21:27:06 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B422BF31-9881-4C67-A734-69C66EB6A787" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: Date: Wed, 25 Jun 2014 21:27:04 -0700 Message-Id: <611492C3-106F-4202-BE9A-A9F529CE0D3E@gmail.com> References: <20140610222623.26744.65633.idtracker@ietfa.amsl.com> <008101cf84fb$a5032c20$ef098460$@rozanak.com> <814D0BFB77D95844A01CA29B44CBF8A7A0288F@lhreml513-mbb.china.huawei.com> <1D49D64B-79C0-47AA-A6A7-09CD1E085DBB@gmail.com> <0D64CACB-A972-4CA3-954F-5928A40CE6DF@bangj.com> <893B6E1B-F930-44A9-94A7-CBAD0DDD1C4F@gmail.com> <9FCED06B-006A-4194-9292-2DD26B53E694@iki.fi> <158F7E24-CA05-427A-B6DC-DBE8718447D4@apple.com> <93D479C0-E10E-4CF3-811E-B8670654D208@gmail.com> <399DC567-F288-49A1-8801-3C0AA7674A3B@iki.fi> <6C5E88EB-BCDB-4BDE-9B6B-9895E06689D1@gmail.com> <70F7F734-8FBD-4BDC-B1BB-D2D242D7E963@iki.fi> To: Tom Pusateri X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/wlHacF7Z56lxUrOcntEpk6QQhao Cc: Stuart Cheshire , "dnssd@ietf.org" , Markus Stenberg , Michael Sweet , Hosnieh Rafiee , "Tovey, Dwight \(LaserJet R&D FW Eng.\)" , Ralph Droms Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt 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, 26 Jun 2014 04:27:13 -0000 --Apple-Mail=_B422BF31-9881-4C67-A734-69C66EB6A787 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 25, 2014, at 6:43 PM, Tom Pusateri wrote: > Douglas, >=20 > The basis of your unsupported accusations is that publishing the = existence of services in DNS is somehow a "significant security flaw" = but you continue to ignore my initial point that the security of = services is independent from the announcement and relies solely on the = security of the network node providing the service. >=20 > You ignore the fact that most services are attacked as a result of = port scans and not because of published DNS entries. >=20 > Machines are taken over all the time and bots attack link local = neighbors. The whole addressing argument is a straw man. >=20 > You have not shown in any way that Hybrid Proxies create security = flaws. >=20 > Tom Dear Tom, It's true that IPv4 is port-scannable. With IPv6, a major hurdle is = discovering network interfaces without being detected. It's also true = many devices have IPv4 relevant security options (like filters, etc). = Unfortunately, most of these approaches are simply impractical with = IPv6. =20 It's also true that we (as a whole) ignored security with IPv4 until = abuse was rampant. Today, we have a chance to get ahead of potential = abuse in particular with this protocol. What I am suggesting, again, is that we _clarify_ in the security = section that this *is* a security risk. Printers, many cameras, and other consumer devices designed to be = attached to a local network are unable to withstand Internet-sourced = attacks. At a minimum, we need to include a section letting = administrators know that publishing a globally reachable IPv6 address in = DNS can be a problem. This needs to be clearly explained in hope of = being understood along with offering a practical coping strategy. Or, we can (again) simply choose to ignore it, and suffer from abuse = later. Apple's approach, with use of ULA and gateway devices, and the secure = exchange of credentials offers a great example as how to deal with these = potential problems. We should be able to follow their example in this = regard. I'll remind you, as well, that I _did_ specifically show that remote = access via IPv6 to a DNS-populated-from-mDNS printer enabled me to = remotely initiate a fax from the Internet with nothing logged as to = where the fax exchange originated. The only indication might be a = potentially massive phone bill when sent long distances late at night. = Similarly, it would be possible to access media on the printer, and do = simple DDoS (exhaust ink and paper, for example). Scanning for these = devices would not be possible in my lifetime, even knowing the target = network. =20 Is this the fault of the printer (which has no access controls on IPv6)? = Not really. In general, common printers and the like were never = designed to offer direct access from the Internet. This means we must = be ultra careful not to help malefactors by publishing specific = locations of these devices thereby permitting direct Internet access. = Doing so would represent a significant security flaw as it would be = wrong to blame a problem on devices having known limitations that were = simply ignored. We should strive to do better. =20 Can it be _fixed_ in the printer? Maybe, but this will impose a massive = change. Should it be fixed in the router? Very few routers today, and = fewer printers have an ability or resources to do extensive IPv6 = filtering. Should the administrator be aware of this? Absolutely. = Should this weakness be an aspect of design considerations. Absolutely. = IMHO, there are already well considered system level solutions = available. Regards, Douglas Otis= --Apple-Mail=_B422BF31-9881-4C67-A734-69C66EB6A787 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jun 25, 2014, at 6:43 PM, Tom = Pusateri <pusateri@bangj.com> = wrote:

Douglas,

The basis of your unsupported = accusations is that publishing the existence of services in DNS is = somehow a "significant security flaw" but you continue to ignore my = initial point that the security of services is independent from the = announcement and relies solely on the security of the network node = providing the service.

You ignore the fact that most services are attacked as a = result of port scans and not because of published DNS entries.

Machines are taken over all = the time and bots attack link local neighbors. The whole addressing = argument is a straw man.

You have not shown in any way that Hybrid Proxies create = security flaws.

Tom

Dear = Tom,

It's true that IPv4 is port-scannable. =  With IPv6, a major hurdle is discovering network interfaces = without being detected.  It's also true many devices have IPv4 = relevant security options (like filters, etc).  Unfortunately, most = of these approaches are simply impractical with IPv6.  

It's = also true that we (as a whole) ignored security with IPv4 until abuse = was rampant.  Today, we have a chance to get ahead of potential = abuse in particular with this protocol.

What I am suggesting, = again, is that we _clarify_ in the security section that this *is* a = security risk.

Printers, many cameras, and = other consumer devices designed to be attached to a local network are = unable to withstand Internet-sourced attacks.  At a minimum, we = need to include a section letting administrators know that publishing a = globally reachable IPv6 address in DNS can be a problem. This needs to = be clearly explained in hope of being understood along with offering a = practical coping strategy.

Or, we can (again) simply choose to = ignore it, and suffer from abuse later.

Apple's approach, with = use of ULA and gateway devices, and the secure exchange of credentials = offers a great example as how to deal with these potential problems. =  We should be able to follow their example in this = regard.

I'll remind you, as well, that I _did_ specifically show = that remote access via IPv6 to a DNS-populated-from-mDNS printer enabled = me to remotely initiate a fax from the Internet with nothing logged as = to where the fax exchange originated.  The only indication might be = a potentially massive phone bill when sent long distances late at night. = Similarly, it would be possible to access media on the printer, and do = simple DDoS (exhaust ink and paper, for example).  Scanning for = these devices would not be possible in my lifetime, even knowing the = target network.  

Is this the fault of the printer (which = has no access controls on IPv6)?  Not really.  In general, = common printers and the like were never designed to offer direct access = from the Internet.  This means we must be ultra careful not to help = malefactors by publishing specific locations of these devices thereby = permitting direct Internet access.  Doing so would represent a = significant security flaw as it would be wrong to blame a problem on = devices having known limitations that were simply ignored.  We = should strive to do better.  

Can it be _fixed_ in the = printer?  Maybe, but this will impose a massive change. =  Should it be fixed in the router?  Very few routers today, = and fewer printers have an ability or resources to do extensive IPv6 = filtering.  Should the administrator be aware of this? =  Absolutely.  Should this weakness be an aspect of design = considerations.  Absolutely.  IMHO, there are already well = considered system level solutions = available.

Regards,
Douglas = Otis
= --Apple-Mail=_B422BF31-9881-4C67-A734-69C66EB6A787-- From nobody Mon Jun 30 08:53:16 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 A42291A0389 for ; Mon, 30 Jun 2014 08:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 D7ZqNfI8wTNl for ; Mon, 30 Jun 2014 08:53:12 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88A351A035C for ; Mon, 30 Jun 2014 08:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=561; q=dns/txt; s=iport; t=1404143592; x=1405353192; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=ix8UT4c153bLsq0+Blttw3bWLJL67vlTIXdzwKRYekg=; b=AGyT6VrCCcLhSTI6P0vIlUa8i7iANc42efwmzE932jaf2JGp3RqVqG1c Y37kShIfbuFbSMAOaSbYd+YOU3bWFW0moQoXBe3kgJHwtKkCMhmkStMBR bgxtd5RcGJn9QLq6M9NvBCZ0WU++VH6ADm25nouV7WEuOIsKt8W/LWRsh M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMHAIuGsVOtJA2B/2dsb2JhbABagw2BLKsZAQEBAQEBBQFuAZlGgQ8WdYQKOj8SAT5CJwQOiEfHVxeFZIkjgzSBFgWaXpN9g0KCMA X-IronPort-AV: E=Sophos;i="5.01,575,1400025600"; d="scan'208";a="57157634" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP; 30 Jun 2014 15:53:11 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s5UFrBRp011719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jun 2014 15:53:11 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.189]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Mon, 30 Jun 2014 10:53:11 -0500 From: "Ralph Droms (rdroms)" To: "dnssd@ietf.org" Thread-Topic: dnssd WG meeting in Toronto Thread-Index: AQHPlHtkj2zc0X+TP0mOcqO9HAWKRQ== Date: Mon, 30 Jun 2014 15:53:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.101.36] Content-Type: text/plain; charset="us-ascii" Content-ID: <10068ED2B0102544BEC9D69C6EF54DE1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/SH0oIQYnoLPTtC0KHG2EmcmEXi0 Cc: "dnssd-chairs@tools.ietf.org" , Sullivan Andrew Subject: [dnssd] dnssd WG meeting in Toronto 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, 30 Jun 2014 15:53:14 -0000 The dnssd WG meeting is currently scheduled for 1520-1720 EDT, Thursday, Ju= ly 24. Note that the date and time are subject to change. I will not be attending IETF-90. Andrew Sullivan has graciously agreed to = act as co-chair with Tim for the meeting. We are collecting requests for agenda slots. Please contact the chairs and= Andrew with your requests by noon Saturday, July 5. We will put together = the agenda for WG review on Monday and submission by the deadline for Draft= Working Group agendas, which is UTC 23:59, July 7. - Ralph From nobody Mon Jun 30 08:55:47 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 BC9D01A035C for ; Mon, 30 Jun 2014 08:55:44 -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 tAEhp-VYxOWy for ; Mon, 30 Jun 2014 08:55:42 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 434CB1A0389 for ; Mon, 30 Jun 2014 08:55:42 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id dc16so6644941qab.1 for ; Mon, 30 Jun 2014 08:55:41 -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:cc :content-transfer-encoding:message-id:references:to; bh=SKSQTFs078dWAQMny/o8CVxr3/ST0qXtnIGbRRH7ZWk=; b=toX1CTNCmgWORPRuFdUBY/UIO6h+wGmXdNOxNorndTMxYv346VAbHWeGbQMl2yTV1X NoH7n+sjD2WPGwkbXprbWmeogqQSUwVd5fAQLVUXwh3EzL8fmorFnk0sOSizm8+RmEuF IyupbM5f7ktB3kcICeKQ8dDd+9Trd58BDAQmdCpfTHGOVEqnEewR0nCgJsX8ASZ0KZIL FiWAgT7Ti25Vwa54afdqXl4RmIBH7GGxorTg+3AW6DjhKBWinFn7pkrpBiAmhMcXMdQ5 ajCmzRdMSpGBEMNbY8aZpxDRp4OQ8KAz0N5oig/NuPe34okNJNF6acxFdCuh+Ug94xx4 vlWg== X-Received: by 10.224.79.11 with SMTP id n11mr62063836qak.40.1404143741424; Mon, 30 Jun 2014 08:55:41 -0700 (PDT) Received: from [10.82.101.36] (rtp-isp-nat-pool1-1.cisco.com. [64.102.254.34]) by mx.google.com with ESMTPSA id q18sm32586181qac.48.2014.06.30.08.55.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Jun 2014 08:55:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ralph Droms In-Reply-To: Date: Mon, 30 Jun 2014 11:55:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <07621E70-7F1C-4A6D-A563-177B265B0E41@gmail.com> References: To: "dnssd@ietf.org" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/lBsWWR_kPO7pARhYY3Erorcsq1M Cc: "dnssd-chairs@tools.ietf.org" , Sullivan Andrew Subject: Re: [dnssd] dnssd WG meeting in Toronto 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, 30 Jun 2014 15:55:44 -0000 The deadline for agenda slot requests is noon *EDT* on July 5. On Jun 30, 2014, at 11:53 AM 6/30/14, Ralph Droms (rdroms) = wrote: > The dnssd WG meeting is currently scheduled for 1520-1720 EDT, = Thursday, July 24. Note that the date and time are subject to change. >=20 > I will not be attending IETF-90. Andrew Sullivan has graciously = agreed to act as co-chair with Tim for the meeting. >=20 > We are collecting requests for agenda slots. Please contact the = chairs and Andrew with your requests by noon Saturday, July 5. We will = put together the agenda for WG review on Monday and submission by the = deadline for Draft Working Group agendas, which is UTC 23:59, July 7. >=20 > - Ralph >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd