From tom.deseyn@gmail.com Tue Dec 24 11:56:39 2013 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 731821AE073 for ; Tue, 24 Dec 2013 11:56:39 -0800 (PST) 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 bvwdBm9ddxn1 for ; Tue, 24 Dec 2013 11:56:38 -0800 (PST) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 01E941AE06E for ; Tue, 24 Dec 2013 11:56:37 -0800 (PST) Received: by mail-ve0-f180.google.com with SMTP id jz11so3606914veb.39 for ; Tue, 24 Dec 2013 11:56:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XISLbyQcAnNp7nLaqN7n+4AH/0GrBdSaigi7D8tXuQU=; b=Vwbi4B/7+IHBnpT2w0CdIKaPEfBkW9xSfzQc9+TjimEbGdJEpMv4wZOemZkkYchkQn DkGoDNaf8VmNTfRlikbXSmQKq/DLI44HsrNCXWizI+01+J6YlW03S99dyrbbeEpmEL0H QIpXbjAIUOPZiSTir4VtGgni5qQLQ82R+8VsC+Wai92+lw++4xKWS5hjgR1jgWQJG+6b +NVL5tUcTl84pJ5nVdwskqHg6tGpORawukQyL+SaPlv7oFJCMI+aHd6vN2rmjglDwfEL ZRuGiDBplOCLSxANjkFMqzDxyXQ+sJPiEQ6QRF+LltJuy0ckczRd8rh05gbIzkS1KZo/ l06Q== MIME-Version: 1.0 X-Received: by 10.58.67.9 with SMTP id j9mr17140271vet.3.1387914994141; Tue, 24 Dec 2013 11:56:34 -0800 (PST) Received: by 10.52.230.72 with HTTP; Tue, 24 Dec 2013 11:56:34 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Dec 2013 20:56:34 +0100 Message-ID: From: Tom Deseyn To: Stuart Cheshire Content-Type: multipart/alternative; boundary=047d7b339e07344fc604ee4d2439 X-Mailman-Approved-At: Thu, 02 Jan 2014 11:47:35 -0800 Cc: dnssd@ietf.org Subject: Re: [dnssd] rfc6762 Multicast DNS A/AAAA additional records 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 Dec 2013 19:56:39 -0000 --047d7b339e07344fc604ee4d2439 Content-Type: text/plain; charset=ISO-8859-1 The section you quote is called "Responding to Address Queries" and it doesn't says whether it applies to the unsolicited messages which are sent when an address is added/removed. So perhaps this can be made more explicit. I checked on my system and avahi v0.6.31 does not include the additional records. Your comment on the NSEC assertion makes sense to me. It means that querying for an A record includes the AAAA responses and vice versa. Such responses can be a NSEC asserting the non-existence of the AAAA record. Wkr, Tom On Fri, Dec 20, 2013 at 8:25 PM, Stuart Cheshire wrote: > On 14 Dec, 2013, at 05:03, Tom Deseyn wrote: > > > Hi all, > > > > RFC6762 states that a response on a query for an A record should include > AAAA answers and vice versa. > > > > Would it makes sense to generalize this to requiring that additional > A/AAAA records should be added to any message which contains an A/AAAA > record? > > > > For example if a machine drops an IPv6 address this results in a message > with an AAAA record with ttl 0. The previous paragraph would mean that > other addresses still valid for this machine (IPv4 and IPv6) are included > in the message. > > Yes, this makes perfect sense. > > RFC 6762 says: > > When a Multicast DNS responder places an IPv4 or IPv6 address record > (rrtype "A" or "AAAA") into a response message, it SHOULD also place > any records of the other address type with the same name into the > additional section, if there is space in the message. This is to > provide fate sharing, so that all a device's addresses are delivered > atomically in a single message, to reduce the risk that packet loss > could cause a querier to receive only the IPv4 addresses and not the > IPv6 addresses, or vice versa. > > So, I think this correctly covers the case of a AAAA record with zero TTL. > > An interesting question would be if we should apply this more generally: > If a device sends a response message containing an NSEC asserting the > non-existence of a AAAA record, should it also volunteer any A records that > do exist for that name? > > Stuart Cheshire > > --047d7b339e07344fc604ee4d2439 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The section you quote is called "Responding to A= ddress Queries" and it doesn't says whether it applies to the unso= licited messages which are sent when an address is added/removed. So perhap= s this can be made more explicit.
I checked on my system and avahi v0.6.31 does not include the addition= al records.

Your comment on the NSEC assertion mak= es sense to me. It means that querying for an A record includes the AAAA re= sponses and vice versa. Such responses can be a NSEC asserting the non-exis= tence of the AAAA record.

Wkr,

Tom


On Fri, Dec 20, 2013 at= 8:25 PM, Stuart Cheshire <cheshire@apple.com> wrote:
On 1= 4 Dec, 2013, at 05:03, Tom Deseyn <tom.deseyn@gmail.com> wrote:

> Hi all,
>
> RFC6762 states that a response on a query for an A record should inclu= de AAAA answers and vice versa.
>
> Would it makes sense to generalize this to requiring that additional A= /AAAA records should be added to any message which contains an A/AAAA recor= d?
>
> For example if a machine drops an IPv6 address this results in a messa= ge with an AAAA record with ttl 0. The previous paragraph would mean that o= ther addresses still valid for this machine (IPv4 and IPv6) are included in= the message.

Yes, this makes perfect sense.

RFC 6762 says:

=A0 =A0When a Multicast DNS responder places an IPv4 or IPv6 address record=
=A0 =A0(rrtype "A" or "AAAA") into a response message, = it SHOULD also place
=A0 =A0any records of the other address type with the same name into the =A0 =A0additional section, if there is space in the message. =A0This is to<= br> =A0 =A0provide fate sharing, so that all a device's addresses are deliv= ered
=A0 =A0atomically in a single message, to reduce the risk that packet loss<= br> =A0 =A0could cause a querier to receive only the IPv4 addresses and not the=
=A0 =A0IPv6 addresses, or vice versa.

So, I think this correctly covers the case of a AAAA record with zero TTL.<= br>
An interesting question would be if we should apply this more generally: If= a device sends a response message containing an NSEC asserting the non-exi= stence of a AAAA record, should it also volunteer any A records that do exi= st for that name?

Stuart Cheshire


--047d7b339e07344fc604ee4d2439-- From kerlyn2001@gmail.com Mon Jan 6 11:28: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 C91181AE15F for ; Mon, 6 Jan 2014 11:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.961 X-Spam-Level: X-Spam-Status: No, score=0.961 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 7MtFqK1pemn0 for ; Mon, 6 Jan 2014 11:28:40 -0800 (PST) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id B7DB61AE167 for ; Mon, 6 Jan 2014 11:28:38 -0800 (PST) Received: by mail-oa0-f53.google.com with SMTP id h16so2328273oag.12 for ; Mon, 06 Jan 2014 11:28:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=nOybdtHR4nTU0l/WV/B8nBICHMVE77MgxKILe/F3/5Y=; b=USEWEKqkFjymzyvx91ldDHIbvmcUGyXQ6hzVLD0152xP2QRjQNfLS1cjqV1NePISEx V6fMV0V3Q/40tQSd6iL62zAnmxo/+VCAmrsjImmoACcX1PzK8kjdMJGaYzSXShvewxTP 8mpK2z8XzfRr4fJ7CTOY+PMOjkBHEfnxLUH6S38QGRJ2z6c4l8k7zezbLfagQ1VI//b4 buHAl8GYphgnPVgA7CBfL6JregIIazvBPi2zQvOR0OhQ7P0Bw+hwab6mQxbfbtu392sX 9Bj3t1WiElPi4T66u2xRJ1m9Ql1gU7ApF/TX1rPxumaQKRyvKIMxU7NUmadKhbDvnl8A ZzQA== MIME-Version: 1.0 X-Received: by 10.182.213.166 with SMTP id nt6mr2323239obc.53.1389036510136; Mon, 06 Jan 2014 11:28:30 -0800 (PST) Received: by 10.60.141.69 with HTTP; Mon, 6 Jan 2014 11:28:30 -0800 (PST) Date: Mon, 6 Jan 2014 14:28:30 -0500 Message-ID: From: Kerry Lynn To: dnssd@ietf.org Content-Type: multipart/alternative; boundary=001a11c2e60ac44f9504ef52432c Subject: [dnssd] Work resumes on the draft requirements WG document 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, 06 Jan 2014 19:28:41 -0000 --001a11c2e60ac44f9504ef52432c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Greetings and Happy New Year, I have uploaded the -00 WG draft requirements (pending group chair approval). You may diff this against draft-lynn-dnssd-requirements-00.txt to see the (minimal) changes from the previous version. The draft co-authors and anyone wishing to contribute will resume work on this document starting with a WebEx call tomorrow and followed by two more at tw= o week intervals (details below). The purpose of the call will be to set priorities and goals for the co-authors to accomplish by the next call. If you cannot make the WebEx you can still help set the agenda by flagging issues to this list. Topics I have for tomorrow: - "Timeliness" and "reliability" of responses [submitted by Dave Thaler] - Improve security requirements - Is it useful to explore (and define) the differences between dnssd and fully managed DNS? (E.g. to articulate non-goals) Regards, -K- ----- DIAL-IN DETAILS ----- Hello , Ralph Droms invites you to attend this online meeting. Topic: DNS-SD requirements document Date: Every 2 weeks on Tuesday, from Tuesday, January 7, 2014 to Tuesday, February 4, 2014 Time: 12:00 pm, Eastern Standard Time (New York, GMT-05:00) Meeting Number: 207 534 698 Meeting Password: dnssd ------------------------------ ------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D249615187&UID=3D0&PW=3DNNzE2N= zdlMzVh&RT=3DMiMxMQ%3D%3D 2. Enter your name and email address. 3. Enter the meeting password: dnssd 4. Click "Join Now". To view in other time zones or languages, please click the link: https://cisco.webex.com/ciscosales/j.php?ED=3D249615187&UID=3D0&PW=3DNNzE2N= zdlMzVh&ORT=3DMiMxMQ%3D%3D ---------------------------------------------------------------- ALERT =96 PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (408) OR (919) AREA CODES ---------------------------------------------------------------- Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 Dialing the WebEx toll free numbers from within 408 or 919 area codes is not enabled (non-Cisco phones). =93 If you dial the toll-free numbers withi= n the 408 or 919 area codes you will be instructed to hang up and dial the local access number.=94 Please use the call-back option whenever possible a= nd otherwise dial local numbers only. The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/mc 2. On the left navigation bar, click "Support". You can contact me at: rdroms@cisco.com 1-978-936 1674 To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://cisco.webex.com/ciscosales/j.php?ED=3D249615187&UID=3D0&ICS=3DMI&LD= =3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAgA-pXsQWEbdeg/4shs9GvCx/T04/avc2AYNrIFhivfq&= RT=3DMiMxMQ%3D%3D http://www.webex.com CCP:+14085256800x207534698# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. --001a11c2e60ac44f9504ef52432c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Greetings and Happy New Year= ,

I have uploaded the -00 WG draft requirements (pending group= chair approval).
You may diff this against draft-lynn-dnssd-requirement= s-00.txt to see the (minimal)
changes from the previous version.

The draft co-authors = and anyone wishing to contribute will resume work on this
document= starting with a WebEx call tomorrow and followed by two more at two
week intervals (details below).

The purpose of the call will b= e to set priorities and goals for the co-authors to
accomplis= h by the next call.=A0 If you cannot make the WebEx you can still help
set the agenda by flagging issues to this list.

Topics I = have for tomorrow:

- "Timeliness" and "rel= iability" of responses [submitted by Dave Thaler]
- Impr= ove security requirements
- Is it useful to explore (and define) the differences between d= nssd and
=A0=A0 fully managed DNS?=A0 (E.g. to articulate non= -goals)

Regards, -K-


----- DIAL-IN = DETAILS -----

Hello ,

Ralph Droms invites you to attend this online meeting.

Topic: DNS-SD requirements document
Date: Every 2 weeks on Tue= sday, from T= uesday, January 7, 2014 to Tuesday, February 4, 2014
Time: 12:00 pm, Eastern Standard Time (New York, GMT-05:00)
Meeting Number: 207 534 698
Meeting Password: dnssd


------------------------------
------------------------- To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D249615187&UID=3D0&P= W=3DNNzE2NzdlMzVh&RT=3DMiMxMQ%3D%3D
2. Enter your name and email address.
3. Enter the meeting password: dnssd
4. Click "Join Now".

To view in other time zones or languages, please click the link:
https= ://cisco.webex.com/ciscosales/j.php?ED=3D249615187&UID=3D0&PW=3DNNz= E2NzdlMzVh&ORT=3DMiMxMQ%3D%3D

----------------------------------------------------------------
ALERT =96 PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (4= 08) OR (919) AREA CODES
----------------------------------------------------------------
Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

Dialing the WebEx toll free numbers from within 408 or 919 area codes is not enabled (non-Cisco phones). =93 If you dial the toll-free numbers=20 within the 408 or 919 area codes you will be instructed to hang up and=20 dial the local access number.=94 Please use the call-back option whenever= =20 possible and otherwise dial local numbers only. The affected toll free=20 numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866)=20 349-3520 for the RTP area.

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferen= cing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign.

San Jose, CA: +1.4= 08.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.= 432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.43= 50.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.= 9394 China: = +86.10.8515.5666

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/mc
2. On the left navigation bar, click "Support".

You can contact me at:
rdroms@cisco.com
1-978-936 1674<= br>
To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link:
https://cisco.webex.com/ciscosales/j.php?ED=3D249615187&UID=3D0&I= CS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAgA-pXsQWEbdeg/4shs= 9GvCx/T04/avc2AYNrIFhivfq&RT=3DMiMxMQ%3D%3D






http://www.webex.com=

CCP:+14085256800x207534698#

IMPORTANT NOTICE: This WebEx service includes a feature that allows=20 audio and any documents and other materials exchanged or viewed during=20 the session to be recorded. By joining this session, you automatically=20 consent to such recordings. If you do not consent to the recording,=20 discuss your concerns with the meeting host prior to the start of the=20 recording or do not join the session. Please note that any such=20 recordings may be subject to discovery in the event of litigation.
--001a11c2e60ac44f9504ef52432c-- From internet-drafts@ietf.org Mon Jan 6 12:38: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 3D5301AE1D2; Mon, 6 Jan 2014 12:38:09 -0800 (PST) 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 c2OIq6oloQw7; Mon, 6 Jan 2014 12:38:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BFA1AE1B3; Mon, 6 Jan 2014 12:38:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140106203803.30709.97198.idtracker@ietfa.amsl.com> Date: Mon, 06 Jan 2014 12:38:03 -0800 Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-ietf-dnssd-requirements-00.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: Mon, 06 Jan 2014 20:38:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Extensions for Scalable DNS Service Disco= very Working Group of the IETF. Title : Requirements for Scalable DNS-SD/mDNS Extensions Authors : Kerry Lynn Stuart Cheshire Marc Blanchet Filename : draft-ietf-dnssd-requirements-00.txt Pages : 10 Date : 2014-01-06 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-00 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 dengguangqing@cnnic.cn Tue Jan 7 03:30: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 CE7111ADF4B for ; Tue, 7 Jan 2014 03:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.026 X-Spam-Level: X-Spam-Status: No, score=-1.026 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FSL_NEW_HELO_USER=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, T_FILL_THIS_FORM_SHORT=0.01] 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 HIpXDPeIGxxI for ; Tue, 7 Jan 2014 03:30:19 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 5CA791AD9B8 for ; Tue, 7 Jan 2014 03:30:16 -0800 (PST) X-EYOUMAIL-SMTPAUTH: dengguangqing@cnnic.cn Received: from unknown127.0.0.1 (HELO user-think) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 07 Jan 2014 19:30:04 +0800 Date: Tue, 7 Jan 2014 19:30:05 +0800 From: "Guangqing Deng" To: "Kerry Lynn" References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 1, 3, 52[cn] Mime-Version: 1.0 Message-ID: <201401071930035591519@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart114118410627_=----" Cc: dnssd Subject: Re: [dnssd] Work resumes on the draft requirements WG document 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, 07 Jan 2014 11:30:23 -0000 This is a multi-part message in MIME format. ------=_001_NextPart114118410627_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VycnksIGdsYWQgdG8gc2VlIHRoaXMgZHJhZnQgYW5kIEkgaGF2ZSBhIG1pbm9yIHF1ZXN0 aW9uLiBJbiBzZWN0aW9uIDYgKHJlcXVpcmVtZW50cyksIGl0IGlzIHNhaWQgdGhhdCB0aGUgbmV3 IHNvbHV0aW9uIE1VU1QgYmUgY2FwYWJsZSBvZiBzcGFubmluZyBtdWx0aXBsZSBsaW5rcyAoaG9w cykgYW5kIE1VU1QgYmUgc2NhbGFibGUgdG8gdGhvdXNhbmRzIG9mIHNlcnZlcnMuIE9idmlvdXNs eSB0aGlzIHNvbHV0aW9uIGNhbiBwcm92aWRlIGEgU0QgKFNlcnZpY2UgRGVzY292ZXJ5KSBzZXJ2 aWNlIGFjcm9zcyBhIHZlcnkgbGFyZ2UgYXJlYSwgYW5kIHdoYXQgSSBhbSBpbnRlcmVzdGVkIGlu IGlzIHRoYXQgY2FuIHRoaXMgc29sdXRpb24gcHJvdmlkZSBTRCBzZXJ2aWNlIG92ZXIgdGhlIHdo b2xlIEludGVybmV0IHRob3VnaCBpdCBtYXkgbm90IGhhdmUgdG8/IEluIGZhY3QsIHRoZSBlbnRl cnByaXNlIG5ldHdvcmsgb2Ygc29tZSBpbnRlcm5hdGlvbmFsIGNvbXBhbmllcyBtYXkgc3BhbiBt dWx0aXBsZSBjb250aW5lbnRzLg0KDQoNCg0KDQpHdWFuZ3FpbmcgRGVuZw0KQ05OSUMgDQoNCkZy b206IEtlcnJ5IEx5bm4NCkRhdGU6IDIwMTQtMDEtMDcgMDM6MjgNClRvOiBkbnNzZA0KU3ViamVj dDogW2Ruc3NkXSBXb3JrIHJlc3VtZXMgb24gdGhlIGRyYWZ0IHJlcXVpcmVtZW50cyBXRyBkb2N1 bWVudA0KR3JlZXRpbmdzIGFuZCBIYXBweSBOZXcgWWVhciwNCg0KDQpJIGhhdmUgdXBsb2FkZWQg dGhlIC0wMCBXRyBkcmFmdCByZXF1aXJlbWVudHMgKHBlbmRpbmcgZ3JvdXAgY2hhaXIgYXBwcm92 YWwpLg0KWW91IG1heSBkaWZmIHRoaXMgYWdhaW5zdCBkcmFmdC1seW5uLWRuc3NkLXJlcXVpcmVt ZW50cy0wMC50eHQgdG8gc2VlIHRoZSAobWluaW1hbCkNCmNoYW5nZXMgZnJvbSB0aGUgcHJldmlv dXMgdmVyc2lvbi4NCg0KDQoNClRoZSBkcmFmdCBjby1hdXRob3JzIGFuZCBhbnlvbmUgd2lzaGlu ZyB0byBjb250cmlidXRlIHdpbGwgcmVzdW1lIHdvcmsgb24gdGhpcw0KDQpkb2N1bWVudCBzdGFy dGluZyB3aXRoIGEgV2ViRXggY2FsbCB0b21vcnJvdyBhbmQgZm9sbG93ZWQgYnkgdHdvIG1vcmUg YXQgdHdvDQp3ZWVrIGludGVydmFscyAoZGV0YWlscyBiZWxvdykuDQoNCg0KVGhlIHB1cnBvc2Ug b2YgdGhlIGNhbGwgd2lsbCBiZSB0byBzZXQgcHJpb3JpdGllcyBhbmQgZ29hbHMgZm9yIHRoZSBj by1hdXRob3JzIHRvDQoNCmFjY29tcGxpc2ggYnkgdGhlIG5leHQgY2FsbC4gIElmIHlvdSBjYW5u b3QgbWFrZSB0aGUgV2ViRXggeW91IGNhbiBzdGlsbCBoZWxwDQpzZXQgdGhlIGFnZW5kYSBieSBm bGFnZ2luZyBpc3N1ZXMgdG8gdGhpcyBsaXN0Lg0KDQoNClRvcGljcyBJIGhhdmUgZm9yIHRvbW9y cm93Og0KDQoNCi0gIlRpbWVsaW5lc3MiIGFuZCAicmVsaWFiaWxpdHkiIG9mIHJlc3BvbnNlcyBb c3VibWl0dGVkIGJ5IERhdmUgVGhhbGVyXQ0KDQotIEltcHJvdmUgc2VjdXJpdHkgcmVxdWlyZW1l bnRzDQoNCi0gSXMgaXQgdXNlZnVsIHRvIGV4cGxvcmUgKGFuZCBkZWZpbmUpIHRoZSBkaWZmZXJl bmNlcyBiZXR3ZWVuIGRuc3NkIGFuZA0KDQogICBmdWxseSBtYW5hZ2VkIEROUz8gIChFLmcuIHRv IGFydGljdWxhdGUgbm9uLWdvYWxzKQ0KDQoNClJlZ2FyZHMsIC1LLQ0KDQoNCg0KLS0tLS0gRElB TC1JTiBERVRBSUxTIC0tLS0tDQoNCg0KSGVsbG8gLA0KDQpSYWxwaCBEcm9tcyBpbnZpdGVzIHlv dSB0byBhdHRlbmQgdGhpcyBvbmxpbmUgbWVldGluZy4NCg0KVG9waWM6IEROUy1TRCByZXF1aXJl bWVudHMgZG9jdW1lbnQNCkRhdGU6IEV2ZXJ5IDIgd2Vla3Mgb24gVHVlc2RheSwgZnJvbSBUdWVz ZGF5LCBKYW51YXJ5IDcsIDIwMTQgdG8gVHVlc2RheSwgRmVicnVhcnkgNCwgMjAxNA0KVGltZTog MTI6MDAgcG0sIEVhc3Rlcm4gU3RhbmRhcmQgVGltZSAoTmV3IFlvcmssIEdNVC0wNTowMCkNCk1l ZXRpbmcgTnVtYmVyOiAyMDcgNTM0IDY5OA0KTWVldGluZyBQYXNzd29yZDogZG5zc2QNCg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClRvIGpvaW4gdGhlIG9ubGluZSBtZWV0aW5nIChOb3cgZnJvbSBtb2JpbGUgZGV2aWNlcyEpDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQox LiBHbyB0byBodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2oucGhwP0VEPTI0OTYx NTE4NyZVSUQ9MCZQVz1OTnpFMk56ZGxNelZoJlJUPU1pTXhNUSUzRCUzRA0KMi4gRW50ZXIgeW91 ciBuYW1lIGFuZCBlbWFpbCBhZGRyZXNzLg0KMy4gRW50ZXIgdGhlIG1lZXRpbmcgcGFzc3dvcmQ6 IGRuc3NkDQo0LiBDbGljayAiSm9pbiBOb3ciLg0KDQpUbyB2aWV3IGluIG90aGVyIHRpbWUgem9u ZXMgb3IgbGFuZ3VhZ2VzLCBwbGVhc2UgY2xpY2sgdGhlIGxpbms6DQpodHRwczovL2Npc2NvLndl YmV4LmNvbS9jaXNjb3NhbGVzL2oucGhwP0VEPTI0OTYxNTE4NyZVSUQ9MCZQVz1OTnpFMk56ZGxN elZoJk9SVD1NaU14TVElM0QlM0QNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQUxFUlQg4oCTIFBMRUFTRSBSRUFEOiBE TyBOT1QgRElBTCBUSEUgVE9MTCBGUkVFIE5VTUJFUlMgRlJPTSBXSVRISU4gVEhFICg0MDgpIE9S ICg5MTkpIEFSRUEgQ09ERVMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClBsZWFzZSBkaWFsIHRoZSBsb2NhbCBhY2Nlc3Mg bnVtYmVyIGZvciB5b3VyIGFyZWEgZnJvbSB0aGUgbGlzdCBiZWxvdzoNCi0gU2FuIEpvc2UvTWls cGl0YXMgKDQwOCkgYXJlYTogNTI1LTY4MDANCi0gUlRQICg5MTkpIGFyZWE6IDM5Mi0zMzMwDQoN CkRpYWxpbmcgdGhlIFdlYkV4IHRvbGwgZnJlZSBudW1iZXJzIGZyb20gd2l0aGluIDQwOCBvciA5 MTkgYXJlYSBjb2RlcyBpcyBub3QgZW5hYmxlZCAobm9uLUNpc2NvIHBob25lcykuIOKAnCBJZiB5 b3UgZGlhbCB0aGUgdG9sbC1mcmVlIG51bWJlcnMgd2l0aGluIHRoZSA0MDggb3IgOTE5IGFyZWEg Y29kZXMgeW91IHdpbGwgYmUgaW5zdHJ1Y3RlZCB0byBoYW5nIHVwIGFuZCBkaWFsIHRoZSBsb2Nh bCBhY2Nlc3MgbnVtYmVyLuKAnSBQbGVhc2UgdXNlIHRoZSBjYWxsLWJhY2sgb3B0aW9uIHdoZW5l dmVyIHBvc3NpYmxlIGFuZCBvdGhlcndpc2UgZGlhbCBsb2NhbCBudW1iZXJzIG9ubHkuIFRoZSBh ZmZlY3RlZCB0b2xsIGZyZWUgbnVtYmVycyBhcmU6ICg4NjYpIDQzMi05OTAzIGZvciB0aGUgU2Fu IEpvc2UvTWlscGl0YXMgYXJlYSBhbmQgKDg2NikgMzQ5LTM1MjAgZm9yIHRoZSBSVFAgYXJlYS4N Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KVG8gam9pbiB0aGUgdGVsZWNvbmZlcmVuY2Ugb25seQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KMS4gRGlhbCBpbnRvIENpc2NvIFdl YkV4ICh2aWV3IGFsbCBHbG9iYWwgQWNjZXNzIE51bWJlcnMgYXQNCmh0dHA6Ly9jaXNjby5jb20v ZW4vVVMvYWJvdXQvZG9pbmdfYnVzaW5lc3MvY29uZmVyZW5jaW5nL2luZGV4Lmh0bWwNCjIuIEZv bGxvdyB0aGUgcHJvbXB0cyB0byBlbnRlciB0aGUgTWVldGluZyBOdW1iZXIgKGxpc3RlZCBhYm92 ZSkgb3IgQWNjZXNzIENvZGUgZm9sbG93ZWQgYnkgdGhlICMgc2lnbi4NCg0KU2FuIEpvc2UsIENB OiArMS40MDguNTI1LjY4MDAgUlRQOiArMS45MTkuMzkyLjMzMzANCg0KVVMvQ2FuYWRhOiArMS44 NjYuNDMyLjk5MDMgVW5pdGVkIEtpbmdkb206ICs0NC4yMC44ODI0LjAxMTcNCg0KSW5kaWE6ICs5 MS44MC40MzUwLjExMTEgR2VybWFueTogKzQ5LjYxOS42NzczLjkwMDINCg0KSmFwYW46ICs4MS4z LjU3NjMuOTM5NCBDaGluYTogKzg2LjEwLjg1MTUuNTY2Ng0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGb3IgYXNzaXN0YW5jZQ0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KMS4g R28gdG8gaHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxlcy9tYw0KMi4gT24gdGhlIGxl ZnQgbmF2aWdhdGlvbiBiYXIsIGNsaWNrICJTdXBwb3J0Ii4NCg0KWW91IGNhbiBjb250YWN0IG1l IGF0Og0KcmRyb21zQGNpc2NvLmNvbQ0KMS05NzgtOTM2IDE2NzQNCg0KVG8gYWRkIHRoaXMgbWVl dGluZyB0byB5b3VyIGNhbGVuZGFyIHByb2dyYW0gKGZvciBleGFtcGxlIE1pY3Jvc29mdCBPdXRs b29rKSwgY2xpY2sgdGhpcyBsaW5rOg0KaHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxl cy9qLnBocD9FRD0yNDk2MTUxODcmVUlEPTAmSUNTPU1JJkxEPTEmUkQ9MiZTVD0xJlNIQTI9QUFB QUFnQS1wWHNRV0ViZGVnLzRzaHM5R3ZDeC9UMDQvYXZjMkFZTnJJRmhpdmZxJlJUPU1pTXhNUSUz RCUzRA0KDQoNCg0KDQoNCg0KaHR0cDovL3d3dy53ZWJleC5jb20NCg0KQ0NQOisxNDA4NTI1Njgw MHgyMDc1MzQ2OTgjDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoaXMgV2ViRXggc2VydmljZSBpbmNs dWRlcyBhIGZlYXR1cmUgdGhhdCBhbGxvd3MgYXVkaW8gYW5kIGFueSBkb2N1bWVudHMgYW5kIG90 aGVyIG1hdGVyaWFscyBleGNoYW5nZWQgb3Igdmlld2VkIGR1cmluZyB0aGUgc2Vzc2lvbiB0byBi ZSByZWNvcmRlZC4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNv bnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gdGhlIHJl Y29yZGluZywgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIG1lZXRpbmcgaG9zdCBwcmlv ciB0byB0aGUgc3RhcnQgb2YgdGhlIHJlY29yZGluZyBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lv bi4gUGxlYXNlIG5vdGUgdGhhdCBhbnkgc3VjaCByZWNvcmRpbmdzIG1heSBiZSBzdWJqZWN0IHRv IGRpc2NvdmVyeSBpbiB0aGUgZXZlbnQgb2YgbGl0aWdhdGlvbi4g ------=_001_NextPart114118410627_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi Kerry, gla= d to see=20 this draft and I have a minor question. In section 6 (requirements), it is= said=20 that the new solution MUST be capable of spanning multiple links (hops) an= d MUST=20 be scalable to thousands of servers. Obviously this solution can provide a= SD=20 (Service Descovery) service across a very large area, and what I am=20 interested in is that can this solution provide SD service over the whole=20 Internet though it may not have to? In fact, the enterprise network of som= e=20 international companies may span multiple continents.
 
Guangqing=20 Deng
CNNIC 
 
Date: 2014-01-07 03:28
To: dnssd
Subject: [dnssd] Work resumes on the draft requirements W= G=20 document
Greetings and Happy New Year,

I have uploaded the -00 WG= draft=20 requirements (pending group chair approval).
You may diff this against=20 draft-lynn-dnssd-requirements-00.txt to see the (minimal)
changes from = the=20 previous version.

The draft co-authors and anyone wishi= ng to=20 contribute will resume work on this
document starting with a WebE= x call=20 tomorrow and followed by two more at two
week intervals (details=20 below).

The purpose of the call will be to set priorities and= goals=20 for the co-authors to
accomplish by the next call.  If you cannot make the WebEx you c= an=20 still help
set the agenda by flagging issues to this list.

Topics I have for tomorrow:

- "Timeliness" and "reliability" of responses [submitted by Dave=20 Thaler]
- Improve security requirements
- Is it useful to explore (and define) the differences between dnssd=20 and
   fully managed DNS?  (E.g. to articulate=20 non-goals)

Regards, -K-


----- DIAL-IN DETAILS -----

Hello ,

Ralph Droms invites you to attend this online=20 meeting.

Topic: DNS-SD requirements document
Date: Every 2 weeks= on Tuesday, from Tuesday,=20 January 7, 2014 to Tuesday, February 4, 2014
Time: 12:00 pm, Eastern Standard Time (New York= ,=20 GMT-05:00)
Meeting Number: 207 534 698
Meeting Password:=20 dnssd


------------------------------
-------------------------
To join the online meeting (No= w from=20 mobile=20 devices!)
-------------------------------------------------------
1.= Go to=20 https://cisco.webex.com/ciscosales/j.php?ED=3D249615187&am= p;UID=3D0&PW=3DNNzE2NzdlMzVh&RT=3DMiMxMQ%3D%3D
2.=20 Enter your name and email address.
3. Enter the meeting password: dnssd=
4.=20 Click "Join Now".

To view in other time zones or languages, please = click=20 the link:
https://cisco.webex.com/ciscosales/j.php?ED=3D249615187&am= p;UID=3D0&PW=3DNNzE2NzdlMzVh&ORT=3DMiMxMQ%3D%3D

-------= ---------------------------------------------------------
ALERT=20 =E2=80=93 PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (= 408) OR (919)=20 AREA=20 CODES
----------------------------------------------------------------<= BR>Please=20 dial the local access number for your area from the list below:
- San=20 Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

Di= aling=20 the WebEx toll free numbers from within 408 or 919 area codes is not enabl= ed=20 (non-Cisco phones). =E2=80=9C If you dial the toll-free numbers within the= 408 or 919=20 area codes you will be instructed to hang up and dial the local access num= ber.=E2=80=9D=20 Please use the call-back option whenever possible and otherwise dial local= =20 numbers only. The affected toll free numbers are: (866) 432-9903 for the S= an=20 Jose/Milpitas area and (866) 349-3520 for the RTP=20 area.

-------------------------------------------------------
To= join=20 the teleconference=20 only
-------------------------------------------------------
1. Dial= into=20 Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing/i= ndex.html
2.=20 Follow the prompts to enter the Meeting Number (listed above) or Access Co= de=20 followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 = United=20 Kingdom: +44.20.8824.0117

India: +91.80.4350.1111=20 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 = China: +86.10.8515.5666

----------------------= ---------------------------------
For=20 assistance
-------------------------------------------------------
1= . Go=20 to https://cisco.webex.com/ciscosales/mc
2. On the lef= t=20 navigation bar, click "Support".

You can contact me at:
rdroms@cisco.com
1-978-936 1674
To=20 add this meeting to your calendar program (for example Microsoft Outlook),= click=20 this link:
https://cisco.webex.com/ciscosales/j.php?ED=3D249615187&am= p;UID=3D0&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAgA= -pXsQWEbdeg/4shs9GvCx/T04/avc2AYNrIFhivfq&RT=3DMiMxMQ%3D%3D





http://www.webex.com

CCP:+14085256800x207534698= #

IMPORTANT=20 NOTICE: This WebEx service includes a feature that allows audio and any=20 documents and other materials exchanged or viewed during the session to be= =20 recorded. By joining this session, you automatically consent to such recor= dings.=20 If you do not consent to the recording, discuss your concerns with the mee= ting=20 host prior to the start of the recording or do not join the session. Pleas= e note=20 that any such recordings may be subject to discovery in the event of litig= ation.=20

------=_001_NextPart114118410627_=------ From tom.deseyn@gmail.com Tue Jan 7 14:18:19 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 7E9F01AE212 for ; Tue, 7 Jan 2014 14:18:19 -0800 (PST) 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 leg-x7TNKq_0 for ; Tue, 7 Jan 2014 14:18:17 -0800 (PST) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB831AE1CF for ; Tue, 7 Jan 2014 14:18:17 -0800 (PST) Received: by mail-vb0-f46.google.com with SMTP id w20so578143vbb.19 for ; Tue, 07 Jan 2014 14:18:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OByglWTG6M3ocqjG4vfPoQXzxAKpFaF/Py0DX3gHM7g=; b=tqBkeu9BAMTAI7Ny2Gi9e28WZjsqGhpI6l8eUosc534MEEbuHNBdxaQ+zRvxXka1O3 Y7n4NRZQtTgwr8Nn0bHpSlwMDjbDtab+loYzZ4J6Fp2rp6yE9dTWWP4xDfR8rSLoa0G2 vBsdbW+M8T1baUupVL87FLo5P72bw0guokpo6P6sd8saLGE33L1LZENvAGfw1RzJLgkc uPZ3WkA6Bn93OOV+5wIDJWctFvOVYHYqgu6y/168cKDNuFiA8l5Uy63XP2+HLygDBov2 4PVltvgru53xzgp0bC9/f/7NSKHJ96665hDOwNQDsfg7bZe+jbCU7Qg0+K0WiigH5FSk FYXg== MIME-Version: 1.0 X-Received: by 10.52.163.65 with SMTP id yg1mr63724147vdb.14.1389133088188; Tue, 07 Jan 2014 14:18:08 -0800 (PST) Received: by 10.52.179.231 with HTTP; Tue, 7 Jan 2014 14:18:08 -0800 (PST) In-Reply-To: References: Date: Tue, 7 Jan 2014 23:18:08 +0100 Message-ID: From: Tom Deseyn To: Stuart Cheshire Content-Type: multipart/alternative; boundary=001a11c2cc5844719404ef68c09c Cc: dnssd@ietf.org Subject: Re: [dnssd] rfc6762 Multicast DNS A/AAAA additional records 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, 07 Jan 2014 22:18:19 -0000 --001a11c2cc5844719404ef68c09c Content-Type: text/plain; charset=ISO-8859-1 Hi Stuart, Do you have any further thoughts on this topic? Thanks, Tom On Tue, Dec 24, 2013 at 8:56 PM, Tom Deseyn wrote: > The section you quote is called "Responding to Address Queries" and it > doesn't says whether it applies to the unsolicited messages which are sent > when an address is added/removed. So perhaps this can be made more explicit. > I checked on my system and avahi v0.6.31 does not include the additional > records. > > Your comment on the NSEC assertion makes sense to me. It means that > querying for an A record includes the AAAA responses and vice versa. Such > responses can be a NSEC asserting the non-existence of the AAAA record. > > Wkr, > > Tom > > > On Fri, Dec 20, 2013 at 8:25 PM, Stuart Cheshire wrote: > >> On 14 Dec, 2013, at 05:03, Tom Deseyn wrote: >> >> > Hi all, >> > >> > RFC6762 states that a response on a query for an A record should >> include AAAA answers and vice versa. >> > >> > Would it makes sense to generalize this to requiring that additional >> A/AAAA records should be added to any message which contains an A/AAAA >> record? >> > >> > For example if a machine drops an IPv6 address this results in a >> message with an AAAA record with ttl 0. The previous paragraph would mean >> that other addresses still valid for this machine (IPv4 and IPv6) are >> included in the message. >> >> Yes, this makes perfect sense. >> >> RFC 6762 says: >> >> When a Multicast DNS responder places an IPv4 or IPv6 address record >> (rrtype "A" or "AAAA") into a response message, it SHOULD also place >> any records of the other address type with the same name into the >> additional section, if there is space in the message. This is to >> provide fate sharing, so that all a device's addresses are delivered >> atomically in a single message, to reduce the risk that packet loss >> could cause a querier to receive only the IPv4 addresses and not the >> IPv6 addresses, or vice versa. >> >> So, I think this correctly covers the case of a AAAA record with zero TTL. >> >> An interesting question would be if we should apply this more generally: >> If a device sends a response message containing an NSEC asserting the >> non-existence of a AAAA record, should it also volunteer any A records that >> do exist for that name? >> >> Stuart Cheshire >> >> > --001a11c2cc5844719404ef68c09c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Stuart,

Do you have any further thou= ghts on this topic?

Thanks,

Tom


On Tue, Dec 24, 2013 at 8:56 PM, Tom Deseyn <tom.deseyn@gmail.com= > wrote:
The section you quote is called "Responding to A= ddress Queries" and it doesn't says whether it applies to the unso= licited messages which are sent when an address is added/removed. So perhap= s this can be made more explicit.
I checked on my system and avahi v0.6.31 does not include the addition= al records.

Your comment on the NSEC assertion mak= es sense to me. It means that querying for an A record includes the AAAA re= sponses and vice versa. Such responses can be a NSEC asserting the non-exis= tence of the AAAA record.

Wkr,

Tom


On Fri, Dec 20, 2013 at 8:25 PM, Stuart Cheshire <cheshi= re@apple.com> wrote:
On 14 Dec, 2013, at 05:03, Tom Des= eyn <tom.desey= n@gmail.com> wrote:

> Hi all,
>
> RFC6762 states that a response on a query for an A record should inclu= de AAAA answers and vice versa.
>
> Would it makes sense to generalize this to requiring that additional A= /AAAA records should be added to any message which contains an A/AAAA recor= d?
>
> For example if a machine drops an IPv6 address this results in a messa= ge with an AAAA record with ttl 0. The previous paragraph would mean that o= ther addresses still valid for this machine (IPv4 and IPv6) are included in= the message.

Yes, this makes perfect sense.

RFC 6762 says:

=A0 =A0When a Multicast DNS responder places an IPv4 or IPv6 address record=
=A0 =A0(rrtype "A" or "AAAA") into a response message, = it SHOULD also place
=A0 =A0any records of the other address type with the same name into the =A0 =A0additional section, if there is space in the message. =A0This is to<= br> =A0 =A0provide fate sharing, so that all a device's addresses are deliv= ered
=A0 =A0atomically in a single message, to reduce the risk that packet loss<= br> =A0 =A0could cause a querier to receive only the IPv4 addresses and not the=
=A0 =A0IPv6 addresses, or vice versa.

So, I think this correctly covers the case of a AAAA record with zero TTL.<= br>
An interesting question would be if we should apply this more generally: If= a device sends a response message containing an NSEC asserting the non-exi= stence of a AAAA record, should it also volunteer any A records that do exi= st for that name?

Stuart Cheshire



--001a11c2cc5844719404ef68c09c-- From rdroms@cisco.com Wed Jan 8 12:20:08 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 8505B1AE1ED for ; Wed, 8 Jan 2014 12:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 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.538, 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 HwAtxnH8Qs7N for ; Wed, 8 Jan 2014 12:20:06 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 08B4F1AE1B3 for ; Wed, 8 Jan 2014 12:20:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=250; q=dns/txt; s=iport; t=1389212397; x=1390421997; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=m9OZtdYiSVfLbHeAvrzx2JcObOXljAWKd5+rn2vp4ak=; b=faLezRQxRAMMqslN3vLVOXEPAWwnM/BfWePzEbsNW1qTzIiZiadsWyL3 5RhZfbE0cgYiEhLqvT8FSX+Fnx55Fz8qdKOsSzs37U94/GNqDPcBOvDav heX1BmTWQRJuyHYViti9ri1Bqzj69o0Gat2jSTWZjYwFeUnAKJGgl6Xns w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAGiyzVKtJXG9/2dsb2JhbABZgwuBDrpQFnSCLDpRAT5CJwSIF5pmqV8XjjGDf4ETBJgXkhWDLYIq X-IronPort-AV: E=Sophos;i="4.95,626,1384300800"; d="scan'208";a="295911962" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 08 Jan 2014 20:19:56 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s08KJubn030756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 8 Jan 2014 20:19:56 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.10]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Wed, 8 Jan 2014 14:19:56 -0600 From: "Ralph Droms (rdroms)" To: "dnssd@ietf.org" Thread-Topic: Meeting in London Thread-Index: AQHPDK7+TfTG7+31Ok+TA8lYSys7Kg== Date: Wed, 8 Jan 2014 20:19:55 +0000 Message-ID: <94A3F78C-DC20-4C30-9F55-0180EF143B5B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.68.184] Content-Type: text/plain; charset="us-ascii" Content-ID: <30D01C596B2F3B49B160F81AA3888377@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dnssd] Meeting in London 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, 08 Jan 2014 20:20:09 -0000 We just submitted a request for a 2 hour meeting slot for dnssd in London. = Here are the WG conflicts we asked to avoid: First Priority: appsawg v6ops dnsop homenet 6man dhc 6lo mboned core sdnrg Are there others we should list? - Ralph From marc.blanchet@viagenie.ca Wed Jan 8 13:08:24 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 2E4F21AE5DE for ; Wed, 8 Jan 2014 13:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 xCgRYng-qKbl for ; Wed, 8 Jan 2014 13:08:22 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 493331AE5C8 for ; Wed, 8 Jan 2014 13:08:22 -0800 (PST) Received: from [192.168.1.111] (modemcable060.86-160-184.mc.videotron.ca [184.160.86.60]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 87952403FD; Wed, 8 Jan 2014 16:08:12 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Marc Blanchet In-Reply-To: <94A3F78C-DC20-4C30-9F55-0180EF143B5B@cisco.com> Date: Wed, 8 Jan 2014 16:08:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94A3F78C-DC20-4C30-9F55-0180EF143B5B@cisco.com> To: Ralph Droms X-Mailer: Apple Mail (2.1827) Cc: "dnssd@ietf.org" Subject: Re: [dnssd] Meeting in London 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, 08 Jan 2014 21:08:24 -0000 Le 2014-01-08 =E0 15:19, Ralph Droms (rdroms) a =E9crit= : > We just submitted a request for a 2 hour meeting slot for dnssd in = London. Here are the WG conflicts we asked to avoid: >=20 > First Priority: appsawg v6ops dnsop homenet 6man dhc 6lo mboned core = sdnrg I fail to see the "first priority conflict" with sdnrg. maybe I'm = missing something. >=20 > Are there others we should list? - the more we list, we more it makes the scheduling complicated for the = secretariat. We shall consume this very carefully. - I would argue that some in the list above could be in second priority, = such as core, 6lo. but I might be missing something. Marc. >=20 > - Ralph >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From tjc@ecs.soton.ac.uk Wed Jan 8 16:16:30 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 0B2861ADEA1 for ; Wed, 8 Jan 2014 16:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_NEUTRAL=0.779] 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 MDeMD2xxm1uO for ; Wed, 8 Jan 2014 16:16:28 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEE31ADE86 for ; Wed, 8 Jan 2014 16:16:27 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s090GAUf015894; Thu, 9 Jan 2014 00:16:10 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s090GAUf015894 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1389226571; bh=hRaST6IAXuAYapemEjih4iyZCVg=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=kHQqsxofJlRIQEane5ahEQW8mePsSX5+9jU5Il/8iwcutWKiqAwtXSW55vkvMosJL ifrv1NjFzUYJYyPCI3Y/LyUMo0v4t2lFC0ADJQ6NquTmH6DQACMJ6TMY22ZDnD+Ygu QhSqhkHK9aJxHrvL4ePxRdBFfOSB/3IeYLH8gxmw= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q080GA0959646983PS ret-id none; Thu, 09 Jan 2014 00:16:11 +0000 Received: from [192.168.1.101] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s090Eqpv011450 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jan 2014 00:14:52 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Chown In-Reply-To: Date: Thu, 9 Jan 2014 00:14:51 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <94A3F78C-DC20-4C30-9F55-0180EF143B5B@cisco.com> To: Marc Blanchet X-Mailer: Apple Mail (2.1827) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q080GA095964698300; tid=q080GA0959646983PS; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s090GAUf015894 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "dnssd@ietf.org" , Ralph Droms Subject: Re: [dnssd] Meeting in London 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, 09 Jan 2014 00:16:30 -0000 Hi Marc, On 8 Jan 2014, at 21:08, Marc Blanchet = wrote: > Le 2014-01-08 =E0 15:19, Ralph Droms (rdroms) a = =E9crit : >=20 >> We just submitted a request for a 2 hour meeting slot for dnssd in = London. Here are the WG conflicts we asked to avoid: >>=20 >> First Priority: appsawg v6ops dnsop homenet 6man dhc 6lo mboned core = sdnrg >=20 > I fail to see the "first priority conflict" with sdnrg. maybe I'm = missing something. It=92s the same as requested for IETF88. It=92s a clash I personally = want to avoid, but others had mentioned it to me before we added it to = the clash list last time. I might agree that if there were a deadlock in = the timetabling algorithm, it would be one conflict to consider = relaxing. But I think the above list is pretty reasonable. >> Are there others we should list? >=20 > - the more we list, we more it makes the scheduling complicated for = the secretariat. We shall consume this very carefully. > - I would argue that some in the list above could be in second = priority, such as core, 6lo. but I might be missing something. I recall core and 6lo were added due to interest in dnssd from low = power/mesh network people. I=92d assumed there was some software-based timetabling magic from our = wonderful tools team=85 is the scheduling done by hand? Tim= From marc.blanchet@viagenie.ca Wed Jan 8 17:09:37 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 914F11ADF5B for ; Wed, 8 Jan 2014 17:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.839 X-Spam-Level: X-Spam-Status: No, score=-1.839 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_54=0.6, RP_MATCHES_RCVD=-0.538, 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 m8dzgXsZvbeL for ; Wed, 8 Jan 2014 17:09:33 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4311ADF0E for ; Wed, 8 Jan 2014 17:09:33 -0800 (PST) Received: from h195.viagenie.ca (h195.viagenie.ca [206.123.31.195]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0443F403FD; Wed, 8 Jan 2014 20:09:22 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Marc Blanchet In-Reply-To: Date: Wed, 8 Jan 2014 20:09:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1886DD70-EF94-4347-B1FD-7F90E8DD397D@viagenie.ca> References: <94A3F78C-DC20-4C30-9F55-0180EF143B5B@cisco.com> To: Tim Chown X-Mailer: Apple Mail (2.1827) Cc: "dnssd@ietf.org" , Ralph Droms Subject: Re: [dnssd] Meeting in London 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, 09 Jan 2014 01:09:38 -0000 Le 2014-01-08 =E0 19:14, Tim Chown a =E9crit : > Hi Marc, >=20 > On 8 Jan 2014, at 21:08, Marc Blanchet = wrote: >=20 >> Le 2014-01-08 =E0 15:19, Ralph Droms (rdroms) a = =E9crit : >>=20 >>> We just submitted a request for a 2 hour meeting slot for dnssd in = London. Here are the WG conflicts we asked to avoid: >>>=20 >>> First Priority: appsawg v6ops dnsop homenet 6man dhc 6lo mboned core = sdnrg >>=20 >> I fail to see the "first priority conflict" with sdnrg. maybe I'm = missing something. >=20 > It=92s the same as requested for IETF88. It=92s a clash I personally = want to avoid, but others had mentioned it to me before we added it to = the clash list last time. I might agree that if there were a deadlock in = the timetabling algorithm, it would be one conflict to consider = relaxing. But I think the above list is pretty reasonable. >=20 >>> Are there others we should list? >>=20 >> - the more we list, we more it makes the scheduling complicated for = the secretariat. We shall consume this very carefully. >> - I would argue that some in the list above could be in second = priority, such as core, 6lo. but I might be missing something. >=20 > I recall core and 6lo were added due to interest in dnssd from low = power/mesh network people. >=20 > I=92d assumed there was some software-based timetabling magic from our = wonderful tools team=85 is the scheduling done by hand? >=20 I don't know the details, but I've heard many times how difficult it is = the scheduling. ADs, such as Ralph!!, know more than me! I remember = also a call to wgchairs to be more careful with the conflict list, again = to ease the scheduling. I would suggest using first and second priorities more appropriately: = i.e. maybe put sdnrg,core,6lo as second priorities and keep the first = priorities as minimal as possible. Marc. > Tim From tjc@ecs.soton.ac.uk Thu Jan 9 07:31:32 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 0F43F1AE405 for ; Thu, 9 Jan 2014 07:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.758 X-Spam-Level: X-Spam-Status: No, score=-1.758 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_NEUTRAL=0.779] 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 64FAJLR399S5 for ; Thu, 9 Jan 2014 07:31:28 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 424E41AE32D for ; Thu, 9 Jan 2014 07:31:28 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s09FVDox006393 for ; Thu, 9 Jan 2014 15:31:13 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s09FVDox006393 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1389281473; bh=4Eqp7QGHkHBYDhzB2/OWEwcB1Mg=; h=From:Subject:Date:References:To:Mime-Version; b=QdBADP7eke2BX3REjWfrsAQ6kLCRfvweZd4N44/r2LYvIG4WYFOVbVpjKYzP1/PyU ebIubb8LATmkoUIGqgjVE+R/3Lwh+bKSgnjPCDkJ67+Bx3SZ7Hh9Ny+fCKYDe7XJ4r dF01Xp9/hVA6BLtM1HwbCD+SWpfQOQLnlaCHGAvQ= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q08FVD0959655256R6 ret-id none; Thu, 09 Jan 2014 15:31:13 +0000 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s09FVB2w010893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 9 Jan 2014 15:31:11 GMT From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_EF5B9D83-D1FD-4CD9-857B-41431C97C39D" Date: Thu, 9 Jan 2014 15:31:16 +0000 References: <1D7B028C-3B31-4C81-A4BB-25BCACF5C890@ecs.soton.ac.uk> To: dnssd@ietf.org Message-ID: Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q08FVD095965525600; tid=q08FVD0959655256R6; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s09FVDox006393 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: [dnssd] Fwd: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-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, 09 Jan 2014 15:31:32 -0000 --Apple-Mail=_EF5B9D83-D1FD-4CD9-857B-41431C97C39D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Copied here given our discussion inIETF88 on special use names... Brian = I think also forwarded it to homenet. I suggest any specific feedback is sent via dnsop. Tim Begin forwarded message: > From: Suzanne Woolf > Subject: [DNSOP] additional special names Fwd: I-D Action: = draft-chapin-additional-reserved-tlds-00.txt > Date: 8 January 2014 18:18:09 GMT > To: "dnsop@ietf.org WG" >=20 > Colleagues, >=20 > This new internet-draft is another request for additions to the RFC = 6761 special names registry, this time motivated by an interest in = reserving the names most commonly found in recent analysis of TLDs in = private name spaces. The special names registration would serve to = minimize the chances of collision between private and public DNS = namespaces by keeping these names unassigned in the public namespace. >=20 > In addition to discussion on the merits of this specific request, I = would expect the IESG to be interested in any new aspects this request = brings up to the discussion we were already having on the p2p special = names draft, and the usability and scalability of the process in RFC = 6761. >=20 > thanks, > Suzanne >=20 >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: I-D Action: draft-chapin-additional-reserved-tlds-00.txt >> Date: January 8, 2014 10:11:28 AM EST >> To: i-d-announce@ietf.org >> Reply-To: internet-drafts@ietf.org >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >>=20 >> Title : Additional Reserved Top Level Domains >> Authors : Lyman Chapin >> Mark McFadden >> Filename : draft-chapin-additional-reserved-tlds-00.txt >> Pages : 26 >> Date : 2014-01-08 >>=20 >> Abstract: >> The Internet Domain Name System (DNS) defines a tree of names >> starting with root, ".", immediately below which are top level >> domain (TLD) names such as ".com" and ".us". In June 1999 RFC2606 >> reserved a small number of TLD names for use in documentation >> examples, private testing, experiments, and other circumstances in >> which it is desirable to avoid conflict with current or future >> actual TLD names in the DNS. >>=20 >> There has been significant evolution of Internet engineering and >> operation practices since RFC2606 was published. In February 2013 >> RFC6761 defined criteria and procedures for reserving a domain name >> for special use, and established an IANA registry for such names. >> This document reserves eight domain name labels for special use in >> accordance with the criteria and procedures of RFC6761: = localdomain, >> domain, lan, home, host, corp, mail, and exchange. >>=20 >> It is important to note that TLD names may be reserved, in other >> contexts, for policy, political, or other reasons that are distinct >> from the IETF's concern with Internet engineering and operations. >> This document reserves TLD names only for operational and >> engineering reasons. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-chapin-additional-reserved-tlds/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-chapin-additional-reserved-tlds-00 >>=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 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --Apple-Mail=_EF5B9D83-D1FD-4CD9-857B-41431C97C39D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: Suzanne Woolf <suzworldwide@gmail.com>
<= /span>
Subject: [DNSOP] additional special names Fwd: I-D Action: = draft-chapin-additional-reserved-tlds-00.txt
Date: 8 January 2014 = 18:18:09 GMT

=
Subject: I-D Action: = draft-chapin-additional-reserved-tlds-00.txt
Date: January 8, 2014 10:11:28 AM EST
Reply-To: internet-drafts@ietf.org
<= /span>


A New Internet-Draft is available from the = on-line Internet-Drafts directories.


=        Title =           : Additional = Reserved Top Level Domains
=        Authors =         : Lyman Chapin
=             &n= bsp;           &nbs= p;Mark McFadden
Filename =        : = draft-chapin-additional-reserved-tlds-00.txt
Pages =           : = 26
= Date =            : = 2014-01-08

Abstract:
  The Internet Domain Name = System (DNS) defines a tree of names
  starting with root, = ".", immediately below which are top level
  domain (TLD) = names such as ".com" and ".us". In June 1999 RFC2606
=   reserved a small number of TLD names for use in = documentation
  examples, private testing, experiments, = and other circumstances in
  which it is desirable to = avoid conflict with current or future
  actual TLD names = in the DNS.

  There has been significant evolution of = Internet engineering and
  operation practices since = RFC2606 was published. In February 2013
  RFC6761 defined = criteria and procedures for reserving a domain name
  for = special use, and established an IANA registry for such names.
=   This document reserves eight domain name labels for special = use in
  accordance with the criteria and procedures of = RFC6761: localdomain,
  domain, lan, home, host, corp, = mail, and exchange.

  It is important to note that TLD = names may be reserved, in other
  contexts, for policy, = political, or other reasons that are distinct
  from the = IETF's concern with Internet engineering and operations.
=   This document reserves TLD names only for operational = and
  engineering reasons.


The IETF datatracker = status page for this draft is:
https://datatracker.ietf.org/doc/draft-chapin-additional-reserved-t= lds/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-chapin-additional-reserved-tlds-00=


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/

________________________= _______________________
I-D-Announce mailing = list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

= _______________________________________________
DNSOP = mailing list
DNSOP@ietf.org
https://www.ietf.org/= mailman/listinfo/dnsop

= --Apple-Mail=_EF5B9D83-D1FD-4CD9-857B-41431C97C39D-- From mglt.ietf@gmail.com Sun Jan 19 00:02:24 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 471941A1F7B for ; Sun, 19 Jan 2014 00:02:24 -0800 (PST) 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 GPyM53RDNRpU for ; Sun, 19 Jan 2014 00:02:17 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id DAA411A1F7A for ; Sun, 19 Jan 2014 00:02:16 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id x55so5768694wes.8 for ; Sun, 19 Jan 2014 00:02:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=tOTv/9ZT0IrZhagM3ZtmzZ64kCYIHeQFt/dLM/wDLbk=; b=0e+MyGcVizUV7IssilKptwb1ZTv9j9KDVHVz6SYH6gkfzCcCWXkBWqr1CemDvF+xTx 5AP/qvgu9XMe7XEsDBt0MKIsy2brhBI9JW3lMOD6EssXmW7SMF+jZFN63bIlqVZNloRf sBvwX2fnuDz9eyvAh1+pn0sjf0lJut/ruRTE3s2imHCFTTgx6eesKSxf8gA1R+Z6ogC/ lvkk0Nmh53x97jcbnK0RWzPVRvbd8hzUvWAM1SSsxmPu/ne0Xs7dhuiMu2EpKpJqMHBd f6vNY3yGnVreuBhHTKBLBkZyuJcf9a5zyKta1e6/hS5jHRUDE6jJgPVKjPL+EgVow3hg zGVg== MIME-Version: 1.0 X-Received: by 10.194.20.33 with SMTP id k1mr6015099wje.40.1390118523209; Sun, 19 Jan 2014 00:02:03 -0800 (PST) Received: by 10.194.171.129 with HTTP; Sun, 19 Jan 2014 00:02:03 -0800 (PST) Date: Sun, 19 Jan 2014 09:02:03 +0100 Message-ID: From: Daniel Migault To: dnssd@ietf.org Content-Type: multipart/alternative; boundary=047d7b5d377ac58ee604f04e3030 Cc: Tim Chown , Kerry Lynn Subject: [dnssd] draft-ietf-dnssd-requirements-00.txt: Requirements/Security Considerations 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: Sun, 19 Jan 2014 08:02:24 -0000 --047d7b5d377ac58ee604f04e3030 Content-Type: text/plain; charset=ISO-8859-1 Hi Folks, Here are some additional requirements for draft-ietf-dnssd-requirements-00.txt as well as a starting point for the security consideration section. This section has been updated with Tim's comments. Your are more than welcome to comment/clarify/change the proposed text. We would appreciate you provide them by Friday January 23 so they can be considered for the next version. Best Regards, Daniel *Terminology section:* I think we should add the following terms. I am using used them in the remaining of the mail. They may be changed for the draft. mDNS: multicast DNS as defined in [RFC6762] SSD: Scalable Service Discovery SD DNS-Based Service Discovery [RFC6763] *Requirements section:* I suggest adding or complete existing requirements with the following ones: SSD SHOULD be designed for both DNS and mDNS working in a cooperative way. More specifically, it SHOULD consider interaction between DNS and mDNS. SSD SHOULD be able to be performed by client only using DNS and unicast to avoid multiple multicast messages. SSD SHOULD work with existing DNS-Based Service Discovery over mDNS and SHOULD NOT break any other discovery protocols. As specified in the charter [http://datatracker.ietf.org/wg/dnssd/charter/] "The WG will consider the tradeoffs between reusing/extending existing protocols and developing entirely new ones. It is highly desirable that any new solution is backwardly compatible with existing DNS-SD/mDNS deployments. Any solution developed by the dnssd WG must not conflict or interfere with the operation of other zero-configuration service and naming protocols such as uPnP or LLMNR. Integration with such protocols is out of scope for this WG." and "To document challenges and problems encountered in the coexistence of zero configuration and global DNS name services in such multi-link networks, including consideration of both the name resolution mechanism and the namespace." SSD SHOULD consider the use of globally unique FQDN that is specific of a given network instead of a default domain name as ".local". SSD SHOULD provide means to discover/announce the FQDN associated to the network. A default and common FQDN - like ".local." could be used only when the specific FQDN of the network has not been determined. Furthermore, in order to ease interoperation with DNS the domain name SHOULD follow DNS-compatible encoding (i.e ascii or punycode). SSD SHOULD be able to take advantage of network configurations (DHCP/RA) protocol. If it is clear that SSD and DNS SHOULD be able to work together, DHCP may also be used to announce necessary information for the network such as its associated FQDN (using DHCP Domain Search / DHCP Domain option / IPv6 RA [RFC6106]), the interface to register FQDNs... This MAY for example complement or avoid the use of the specific b/db/r/dr/lb.dns-sd._udp. or equivalent queries. SSD SHOULD be able to announce the scope Service Discovery informations are expected to be accessed or multicasted. This requires something like a "scope" discovery protocol. *Security Consideration section* Here is some text I propose. Comments are more then welcome! I hope that we will be able to fix this section during the next meeting. 1. Scalable DNS Service is not an extension of SD in term of security Scalable DNS-Based Service Discovery can hardly rely on the security considerations defined for DNS-Based Service Discovery [RFC6763]. Considering "Scalability" requires new security practices that are defines in this document. DNS-Based Service Discovery [RFC6763] has been designed so that a device can announce a service to the other devices of the network. Although DNS or mDNS can be used for SD, SD has been mostly thought to work over mDNS to avoid DNS zone management and to handle UTF8 names for the end users even in the domain part of the Instance Service Name. As a result SD' security considerations rely on mDNS security considerations, DNSSEC [RFC4033] for authentication and secure DNS update [RFC3007] to secure DNS update [RFC2136]. These considerations are not sufficient for SSD as explained below. - a) DNSSEC is probably the DNS extension that MAY be used to provide authentication and integrity check protection. However, authentication other than proof-of-ownership or leap-of-faith security model requires trust anchors. Trust anchor MAY be provided by the global DNS, but this has not been specified in SD. Section 10 of RFC6763 illustrates how to populate the DNS with information but clearly states that such interactions are out of scope of RFC6763. Interactions between SSD and DNS cannot be specified in an illustrative section. - b) Similarly, DNS updates are used by SD to cooperate with DNS. These interactions are left as illustrative in RFC6763, which is not sufficient for SSD. -c) mDNS security considerations are not sufficient for SSD. At first, mDNS requires cooperative devices. If cooperative devices is a reasonable assumption in a one hop network such as most home networks, this assumption cannot be made for larger networks, such as corporate networks for example. In case all devices cannot trust each other, SD considers the use of IPsec or DNSSEC. How these protocols are used is not fully described in RFC6762 and SHOULD be at least documented for SSD. More specifically, DNSSEC can be used with different security models. Authentication of the devices may require a chain of trust and interaction with DNS. Alternatively authentication may rely on devices configured with certificates. In the absence of such certificates or chain of trust, a proof-of-ownership with device's reputation may be considered. mDNS considers the use of DNSSEC to differentiate responses from the global DNS and mDNS that addresses a local scope. DNSSEC may not be the appropriated solution for SSD as DNSSEC may not be deployed for the global DNS or for mDNS which would make distinction impossible. As suggested by RFC6761, the use of ".local" to specify mDNS may be more appropriated. mDNS also raises the issue of relative domain names (example.com) that may be solved as example.com.local. or as example.com.search-domain. This issue becomes more complex with SSD. For SD there is little ambiguity with the meaning of ".local". It is a single link, usually a single network. SSD considers multiple links and as such multiple ".local" and multiple different search domain. Thus the question may be which link's search domain is to be considered. mDNS considers very few interactions with DNS. The only mentioned case is when a global DNS resolution is performed using mDNS. mDNS indicates how to treat relative domains. Interaction between mDNS and DNS was not so necessary as with one hop network there is a clear separation between the local and non local (Internet) network. With multiple networks, the frontier between local and non local becomes much undefined. As result whether naming resolution is local (mDNS) or global (DNS) is not obvious. This is why SSD needs to specify interactions between DNS and mDNS whereas DNS-Based Service Discovery [RFC6763] does not. As a result security considerations for SSD considers 1) security considerations of SSD over mDNS, 2) security considerations of SSD over DNS and 3) security considerations on interactions between DNS and mDNS. As a result, security assumption of DNS-Based Service Discovery [RFC6763] are not any more valid for Scalable DNS-Based Service Discovery. 1) Privacy protection Information provided by SSD may contain private information that is not expected to go outside the specified scope. Service Discovery carry information about the type of devices available in your network, the software version, their location both physical like floor as well as networking - like the IP address. All these pieces of information may be useful for an intruder. Device and software information are useful to identify vulnerabilities, and location information are useful to locate the target, names may also include information that may be useful to define a specific target - like "Personal CEO Printer". For these reasons, one is willing to limit the scope these pieces of information. a) Informations spreading may be limited based on network information. When DNS is used, the DNS zone SHOULD NOT be accessed by anyone from outside the specific network. This can be performed at the DNS server level or at the network boundaries by setting firewall policies specifying which kind of IP address can access the DNS server. When mDNS is used, multicasted information SHOULD NOT be forwarded outside the expected network. This can be performed by firewalls that drops outbound/inbound mDNS packets at the network boundaries. Note that in both cases, these policies are outside the scope of mDNS or DNS. On the other hand, for mobile devices, for example, which information may be provided depends on the network. These policies have to be implemented by the mobile device. b) SSD SHOULD also consider scopes that are not correlated to network definitions like 'building' or 'room'. As defined in the charter: "It is also desirable that multiple discovery scopes are supported, from the point of view of either performing discovery within a specified scope or advertisement within a specified scope, and being able to discover (enumerate) the set of scopes such that an application could then choose to do either. It should be noted that scope in this sense might refer to 'building' or 'room' and thus might have no correlation to network topology." This requires 1) definition of the different available scopes. Some default value MAY be provided by the device without knowledge of the specific available scopes of the network. Such default values MAY be used by devices if they do not discover the different scopes specific to the network or if the device does not have sufficient information to trust the announced scopes. In that case the device MAY start with a default limited scope. 2) Specific network values SHOULD be announced in an authenticated way to avoid that, for example, non existing scope used results in service unavailable. The policy for non existing scopes SHOULD be defined with a reduced scope, and the device SHOULD be informed that the scope does not exist so it may update its scope. 3) Once devices have been informed of the various scope, it MAY chose the one that seems the most appropriated and provide this information. Depending on the scope, routers or middle boxes MAY chose to forward the information or not. The information MAY be forwarded on multiple links. With scopes that are not network correlated, the information MAY be forwarded to a subset of devices within a link. The use of distinct multicast IP address may be used to distinguish the different scopes. However, the use of different IP addresses does not prevent devices to listen to the information. If the device needs the information to be read only by the members of the scope, cryptography MAY be used to encrypt the data. IPsec multicast extension [RFC5374] may be a good candidate. This mechanism may also be used to prevent an unauthorised device to provide a service for a given scope. In other words, my printer should not be able to announce its service for the "CEO" scope and I should not be able to see the announcement of the printer of my CEO. 2) Exposing Services A Service announced over a network does not mean the service is available to anyone. Such services SHOULD enforce access control policies for the service. If a connected printer is not using SD, it MAY appear as a simple IP connected device attached to the network. Only specific tests/scans/traffic monitor can determine the device is a printer. When SD or SSD is used, as soon as the device is plugged on the network everyone knows "Photo Color Printer, Building A floor 2" has been plugged. If this printer is reserved for the Graphic an Design department, than the printer SHOULD implement access control mechanisms. Although these policies are out of scope of SSD, they MAY be required as a consequence of SSD. 2) Resource exhaustion With new emerging types of networks like sensor networks and more generally the IoT, SSD cannot anymore rely on mDNS and multicast to advertise its services and SHOULD provide a dedicated entity that can perform SSD via unicast messages. Typically, this can be deployed with a mDNS-to-DNS agent that receives announcement from mDNS devices and stores this information to the DNS zone. Since the information is stored, other devices in the network do not have to receive and treat mDNS announcements. SSD MUST be able to scale to thousands of devices. The use of multicast for service announcement requires that each device informs all other devices some information like the hosted service for example. In order to make sure devices always have the information up-to-date or that any new device has the information, the device regularly retransmits the information to all other devices. This is not a scalable architecture as it does not scale in term of bandwidth nor it consider energy consumption constrains of small devices. Any messages are bytes received by the devices connected on the network, which may require additional processing such as cryptographic check if used in conjunction with DNSSEC for example. These devices may rely on battery, and each of these messages directly impact the lifetime of the device. As a result aggressive multicast may unnecessarily affect IoT devices. More rational approach MAY consists in making possible SSD using unicast communications only or to prevent that IoT device wakes up at every multicast message or using multicast to announce information updates as opposed to cache populating. More specifically, a new device can use multicast to announce a newly published information. Eventually this information may be cached by always-on devices and stored in the DNS. A new device may get access to these pieces of information with an unicast AXFR for example. The main advantage is that multicast interface can be switched off. So here we're in similar territory to the discussions about RAs, and multicast on certain types of links, which has led to the efficient-ND proposal, and related work on energy efficiency for low power devices etc. [ http://www.ietf.org/internet-drafts/draft-halpern-6man-nd-pre-resolve-addr-00.txt ] 3) Trusted Scalable Service Discovery This section is only focused on how information provided by the SSD can be trusted. As every device announce their service, SSD SHOULD prevent an attacker to announce it is the "CEO Printer" in order to collect all documents printed by the CEO. In this section, we consider that "CEO Printer" does not exists and that the attack does not aim at hijacking a specific name. Using the SD terminology "CEO Printer" would be the Instance part of the Service Instance Name. a) User perspective When DNS is used, DNSSEC can be used, and one can trust the information as it provides from a trusted party. Although DNSSEC has not been designed as a protocol that certifies the validity of the DNS RDATA, in our case, DNSSEC could be used as such. Contrary to registrars that are hosting FQDNs they have very few knowledge on, network administrators are expected to administrated the DNS zone according to the resources available for the network. As a result DNSSEC validation could be interpreted as "validated by the administrator". mDNS does not have trust anchors provided by DNSSEC. However, DNSSEC used in conjunction of mDNS can be used to provide a proof-of-ownership of the information. How reliable is that information can be learned over time by processing the reputation of a device (represented by its public key) or by monitoring whether the information remains coherent over time. For example, if a printer announces its IP address as part of the company network, and suddenly starts announcing an IP address located somewhere else, further checks may be performed before trusting the information. Even though the mDNS message signed with DNS cannot be trusted the same way as it would have been trusted in a DNSSEC zone, using DNSSEC in conjunction of mDNS makes possible to assign some pieces of information to a specific key. This helps in establishing a reputation as well as avoids spoofed messages. On a user perspective, mDNS requires the end user to establish a reputation mechanism whereas DNS provides certified information. The main advantage of DNS is that a new end user has certified information which is not possible with mDNS. [TBD check/compare hybrid model] b) Devices perspective When DNS is used, the device MUST be able to provide the information to the DNS server via DNS update [RFC2136] or secure DNS update [RFC3007]. This scenario may not meet a Zero configuration requirement as the DNS server needs to know the public key of the devices, and the device needs to know at least the IP address of the DNS server. If DHCPv6 the IP address of the MAY be derived from the Domain Search List and the DNS Recursive Name Server option [RFC3646]. The device MAY send a DNS query for one domain search with type NS to the recursive name server. However, registering the public keys of the devices in the DNS does not scale thousands of devices. Most likely, their public keys may be considered as trusted based on reputation, leap of faith principles which does not necessarily prevent an attacker to set false data into the DNS zone. When mDNS is used, the device does not need any configuration. This information is announced to the network. The information will be trusted by the devices that trust the announcer. As for the DNS, provisioning all devices of the network with all public keys is not scalable. As mentioned above, public keys will be trusted most likely based on reputation or leap of faith principles. The main difference between DNS and mDNS seems that DNS requires less provisioning or configuration than mDNS (n versus n * (n - 1) for a n device network). Then in a zero configuration scenario, DNS centralises in a single point the way a key can be trusted. The only disadvantage of using DNS is the devices should discover the DNS server. It seems that approach combining mDNS and DNS can take advantage of both. Devices announce information using mDNS and the DNS according to the level of trust stores the information in its zone. 4) Information impersonation The previous section provided considerations on how a device can be associated to a public key and eventually identified as a trusted device. With zero configuration, the level of trust associated to a device results of a trade off between configuration and a learning process. This section indicates how information provided by the devices can be monitored to determine the reputation of a device, to raise an alarm to the administrator, and eventually show a device cannot be trusted or indicate a device has been corrupted. The kind of informations provided by SD or SSD that are visible to the end user are 1) a name that describes a service and 2) the location of the service. The name of the service corresponds to Service Instance Name. With SD the name is mentioned in the RDATA part of the PTR and as the key of the SRV RRSet. The location of the service is the RDATA part of the SRV as well as its corresponding locator. The Service Instance Name is composed of three parts: Instance, Service Name and Domain. SD recommends that Instance and Domain are encoded using UTF8. UTF8 enables specific characters that are not yet being considered in the current DNS. Traditional DNS uses ascii or Punycode. If UTF8 is more flexible in term of string representation, it may provide multiple ways to express the same thing which may confuse the end user. In fact using UTF8 "My Printer", "my printer" "My printer" are different strings. This may be used by an attacker that will provide a service different in term of UTF8 format, but that the end user will assimilate to the same service. In addition, "my printer" will be displayed differently if encoded in UTF8 or in ascii. As a result two service "my printer" could be stored in a DNS zone without any collisions. One way to avoid multiple format would be to consider the necessary or missing characters provided by UTF8 and add them in the Puny code. If there may be some advantages in using UTF8 for the service name, the domain name part SHOULD use only the Punycode. As a result, checking information for SSD requires to establish metrics/similarities between strings. Worth noting in the DNS the device might be hpprint01.bldg32.somesite.com, while its internally stored label may be "Building 32 foyer printer". The location of the service is identified by a FQDN and a corresponding IP address. In SD, the FQDN respect the Punnycode encoding. The FQDN of the service may be checked against the known domain names associated to the network. Similarly, the IP address is generally used to locate the service. if the IP address is not inside the network, this may raise a warning to the administrator, that may validate the IP address. When DNSSEC is used closed names addressed by different keys are suspicious. Without the use of DNSSEC is becomes hard to detect the device/SD device has not changed their IP address. 5) Unique network identifier SD uses ".local" prefix to indicate the scope of the FQDN. ".local" is a special use domain name - RFC 6761, and in the registry at http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml ".local" is instantiated in any networks. This results in a given string with multiple meanings. "My Printer" at home is not the same service as "My Printer" at work and if the information is cached in some devices, this may result in cross site name hijacking. An attacker could for example advertise "My Printer" in a public network like in an airport with a global IP address. The Service Instance Name used could be something as "My Printer_ipp_tcp.local SRV global-printer.example.com". People in the airport may then send their documents to "My Printer" advertised in the airport - that is to say global-printer.example.com -, instead of the one of their office. In order to mitigate this confusion, ".local" SHOULD be used only when the device does not know the domain name associated to the network. If DHCPv6 is used this may be derived by the DHCPv6 Client FQDN option [RFC4704]. Note also that "My printer" may be a different printer when I am at home or at work. On the other hand, while at hoe I SHOULD be able to use "My Office Printer" and vice versa. This ambiguity may be leverage by the use of unique prefix. 6) Compromised device This section estimates how a compromised device impacts the SSD service. We assume DNSSEC is used. Once detected, the public key associated to the device is revoked. With DNS the revocation occurs once in the DNS, and the information is only stored in the remaining caches of devices that have requested the information before it expires. After TTL seconds, the information is revoked from all devices. If mDNS is used, revocation should occur in every device. The mechanism to detect a device is compromised is complex and will probably not be implemented properly in most devices. With the current SD, a compromised device MAY provide wrong information about itself but does not affect others device information. -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7b5d377ac58ee604f04e3030 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Folks,

Here are some addit= ional requirements for=A0 draft-ietf-dnssd-requirements-00.txt as well as a= starting point for the security consideration section. This section has be= en updated with Tim's comments.

Your are more than welcome to comment/clarify/change the proposed= text. We would appreciate you provide them by Friday January 23 so they ca= n be considered for the next version.

Best Regards,

Daniel
=A0
Terminology section:

I think we should = add the following terms. I am using used them in the remaining of the mail.= They may be changed for the draft.

mDNS: multicast DNS as defined i= n [RFC6762]
SSD: Scalable Service Discovery
SD DNS-Based Service Discovery [RFC6763]=

Requirements section:

I suggest adding or complete ex= isting requirements with the following ones:

SSD SHOULD be designed = for both DNS and mDNS working in a cooperative way. More specifically, it S= HOULD consider interaction between DNS and mDNS.

SSD SHOULD be able to be performed by client only using DNS and unicast= to avoid multiple multicast messages.

SSD SHOULD work with existing= DNS-Based Service Discovery over mDNS and SHOULD NOT break any other disco= very protocols.
As specified in the charter [http://datatracker.ietf.org/wg/dnssd/charter/]
"The= WG will consider the tradeoffs between reusing/extending existing
proto= cols and developing entirely new ones. It is highly desirable
that any new solution is backwardly compatible with existing DNS-SD/mDNSdeployments. Any solution developed by the dnssd WG must not conflict
o= r interfere with the operation of other zero-configuration service and
naming protocols such as uPnP or LLMNR. Integration with such protocols
= is out of scope for this WG."

and

"To document chal= lenges and problems encountered in the coexistence
of zero configuratio= n and global DNS name services in such
multi-link networks, including consideration of both the name
resolutio= n mechanism and the namespace."


SSD SHOULD consider the use= of globally unique FQDN that is specific of a given network instead of a d= efault domain name as ".local". SSD SHOULD provide means to disco= ver/announce the FQDN associated to the network. A default and common FQDN = - like ".local." could be used only when the specific FQDN of the= network has not been determined. Furthermore, in order to ease interoperat= ion with DNS the domain name SHOULD follow DNS-compatible encoding (i.e asc= ii or punycode).


SSD SHOULD be able to take advantage of network configurations (DHC= P/RA) protocol. If it is clear that SSD and DNS SHOULD be able to work toge= ther, DHCP may also be used to announce necessary information for the netwo= rk such as its associated FQDN (using DHCP Domain Search / DHCP Domain opti= on / IPv6 RA [RFC6106]), the interface to register FQDNs... This MAY for ex= ample complement or avoid the use of the specific b/db/r/dr/lb.dns-sd._udp.= <domain> or equivalent queries.=A0


SSD SHOULD be able to announce the scope Service Discovery informat= ions are expected to be accessed or multicasted. This requires something li= ke a "scope" discovery protocol.


Security Considera= tion section

Here is some text I propose. Comments are more then welcome! I hope tha= t we will be able to fix this section during the next meeting.


1= . Scalable DNS Service is not an extension of SD in term of security

Scalable DNS-Based Service Discovery can hardly rely on the security co= nsiderations defined for DNS-Based Service Discovery [RFC6763]. Considering= "Scalability" requires new security practices that are defines i= n this document.

DNS-Based Service Discovery [RFC6763] has been designed so that a devic= e can announce a service to the other devices of the network. Although DNS = or mDNS can be used for SD, SD has been mostly thought to work over mDNS to= avoid DNS zone management and to handle UTF8 names for the end users even = in the domain part of the Instance Service Name. As a result SD' securi= ty considerations rely on mDNS security considerations, DNSSEC [RFC4033] fo= r authentication and secure DNS update [RFC3007] to secure DNS update [RFC2= 136]. These considerations are not sufficient for SSD as explained below.
=A0=A0=A0 - a) DNSSEC is probably the DNS extension that MAY be used to= provide authentication and integrity check protection. However, authentica= tion other than proof-of-ownership or leap-of-faith security model requires= trust anchors. Trust anchor MAY be provided by the global DNS, but this ha= s not been specified in SD. Section 10 of RFC6763 illustrates how to popula= te the DNS with information but clearly states that such interactions are o= ut of scope of RFC6763. Interactions between SSD and DNS cannot be specifie= d in an illustrative section.

=A0=A0=A0 - b) Similarly, DNS updates are used by SD to cooperate with = DNS. These interactions are left as illustrative in RFC6763, which is not s= ufficient for SSD.

=A0=A0=A0 -c) mDNS security considerations are no= t sufficient for SSD. At first, mDNS requires cooperative devices. If coope= rative devices is a reasonable assumption in a one hop network such as most= home networks, this assumption cannot be made for larger networks, such as= corporate networks for example.

=A0=A0=A0=A0=A0=A0 In case all devices cannot trust each other, SD cons= iders the use of IPsec or DNSSEC. How these protocols are used is not fully= described in RFC6762 and SHOULD be at least documented for SSD. More speci= fically, DNSSEC can be used with different security models. Authentication = of the devices may require a chain of trust and interaction with DNS. Alter= natively authentication may rely on devices configured with certificates. I= n the absence of such certificates or chain of trust, a proof-of-ownership = with device's reputation may be considered.=A0

=A0=A0=A0=A0=A0 mDNS considers the use of DNSSEC to differentiate respo= nses from the global DNS and mDNS that addresses a local scope. DNSSEC may = not be the appropriated solution for SSD as DNSSEC may not be deployed for = the global DNS or for mDNS which would make distinction impossible. As sugg= ested by RFC6761, the use of ".local" to specify mDNS may be more= appropriated.

=A0=A0=A0=A0=A0 mDNS also raises the issue of relative domain names (example.com) that may be solved as example= .com.local. or as example.com.search-domain. This issue becomes more comple= x with SSD. For SD there is little ambiguity with the meaning of ".loc= al". It is a single link, usually a single network. SSD considers mult= iple links and as such multiple ".local" and multiple different s= earch domain. Thus the question may be which link's search domain is to= be considered.
=A0=A0=A0
=A0=A0=A0=A0=A0 mDNS considers very few interactions with DNS= . The only mentioned case is when a global DNS resolution is performed usin= g mDNS. mDNS indicates how to treat relative domains. Interaction between m= DNS and DNS was not so necessary as with one hop network there is a clear s= eparation between the local and non local (Internet) network. With multiple= networks, the frontier between local and non local becomes much undefined.= As result whether naming resolution is local (mDNS) or global (DNS) is not= obvious. This is why SSD needs to specify interactions between DNS and mDN= S whereas DNS-Based Service Discovery [RFC6763] does not. As a result secur= ity considerations for SSD considers 1) security considerations of SSD over= mDNS, 2) security considerations of SSD over DNS and 3) security considera= tions on interactions between DNS and mDNS.


As a result, security assumption of DNS-Based Service Discovery [RF= C6763] are not any more valid for Scalable DNS-Based Service Discovery.
1) Privacy protection

Information provided by SSD may contain p= rivate information that is not expected to go outside=A0 the specified scop= e.

Service Discovery carry information about the type of devices available= in your network, the software version, their location both physical like f= loor as well as networking - like the IP address. All these pieces of infor= mation may be useful for an intruder. Device and software information are u= seful to identify vulnerabilities, and location information are useful to l= ocate the target, names may also include information that may be useful to = define a specific target - like "Personal CEO Printer". For these= reasons, one is willing to limit the scope these pieces of information.
=A0=A0=A0 a) Informations spreading may be limited based on network inf= ormation. When DNS is used, the DNS zone SHOULD NOT be accessed by anyone f= rom outside the specific network. This can be performed at the DNS server l= evel or at the network boundaries by setting firewall policies specifying w= hich kind of IP address can access the DNS server. When mDNS is used, multi= casted information SHOULD NOT be forwarded outside the expected network. Th= is can be performed by firewalls that drops outbound/inbound mDNS packets a= t the network boundaries. Note that in both cases, these policies are outsi= de the scope of mDNS or DNS. On the other hand, for mobile devices, for exa= mple, which information may be provided depends on the network. These polic= ies have to be implemented by the mobile device.

=A0=A0=A0 b) SSD SHOULD also consider scopes that are not correlated to= network definitions like 'building' or 'room'. As defined = in the charter:
"It is also desirable that multiple discovery scop= es are supported,
from the point of view of either performing discovery within a
specifie= d scope or advertisement within a specified scope, and
being able to di= scover (enumerate) the set of scopes such that
an application could the= n choose to do either. It should be noted
that scope in this sense might refer to 'building' or 'room'= ; and thus
might have no correlation to network topology."

= This requires 1) definition of the different available scopes. Some default= value MAY be provided by the device without knowledge of the specific avai= lable scopes of the network. Such default values MAY be used by devices if = they do not discover the different scopes specific to the network or if the= device does not have sufficient information to trust the announced scopes.= In that case the device MAY start with a default limited scope. 2) Specifi= c network values SHOULD be announced in an authenticated way to avoid that,= for example,=A0 non existing scope used results in service unavailable. Th= e policy for non existing scopes SHOULD be defined with a reduced scope, an= d the device SHOULD be informed that the scope does not exist so it may upd= ate its scope. 3) Once devices have been informed of the various scope, it = MAY chose the one that seems the most appropriated and provide this informa= tion. Depending on the scope, routers or middle boxes MAY chose to forward = the information or not. The information MAY be forwarded on multiple links.= With scopes that are not network correlated, the information MAY be forwar= ded to a subset of devices within a link. The use of distinct multicast IP = address may be used to distinguish the different scopes. However, the use o= f different IP addresses does not prevent devices to listen to the informat= ion. If the device needs the information to be read only by the members of = the scope, cryptography MAY be used to encrypt the data. IPsec multicast ex= tension [RFC5374] may be a good candidate. This mechanism may also be used = to prevent an unauthorised device to provide a service for a given scope. I= n other words, my printer should not be able to announce its service for th= e "CEO" scope and I should not be able to see the announcement of= the printer of my CEO.

2) Exposing Services

A Service announced over a network does not= mean the service is available to anyone. Such services SHOULD enforce acce= ss control policies for the service.

If a connected printer is not u= sing SD, it MAY appear as a simple IP connected device attached to the netw= ork. Only specific tests/scans/traffic monitor can determine the device is = a printer. When SD or SSD is used, as soon as the device is plugged on the = network everyone knows "Photo Color Printer, Building A floor 2" = has been plugged. If this printer is reserved for the Graphic an Design dep= artment, than the printer SHOULD implement access control mechanisms. Altho= ugh these policies are out of scope of SSD, they MAY be required as a conse= quence of SSD.
=A0
2) Resource exhaustion

With new emerging types of networks l= ike sensor networks and more generally the IoT, SSD cannot anymore rely on = mDNS and multicast to advertise its services and SHOULD provide a dedicated= entity that can perform SSD via unicast messages. Typically, this can be d= eployed with a mDNS-to-DNS agent that receives announcement from mDNS devic= es and stores this information to the DNS zone. Since the information is st= ored, other devices in the network do not have to receive and treat mDNS an= nouncements.

SSD MUST be able to scale to thousands of devices. The use of multicast= for service announcement requires that each device informs all other devic= es some information like the hosted service for example. In order to make s= ure devices always have the information up-to-date or that any new device h= as the information, the device regularly retransmits the information to all= other devices. This is not a scalable architecture as it does not scale in= term of bandwidth nor it consider energy consumption constrains of small d= evices.

Any messages are bytes received by the devices connected on the network= , which may require additional processing such as cryptographic check if us= ed in conjunction with DNSSEC for example. These devices may rely on batter= y, and each of these messages directly impact the lifetime of the device. A= s a result aggressive multicast may unnecessarily affect IoT devices. More = rational approach MAY consists in making possible SSD using unicast communi= cations only or to prevent that IoT device wakes up at every multicast mess= age or using multicast to announce information updates as opposed to cache = populating. More specifically, a new device can use multicast to announce a= newly published information. Eventually this information may be cached by = always-on devices and stored in the DNS. A new device may get access to the= se pieces of information with an unicast AXFR for example. The main advanta= ge is that multicast interface can be switched off.
=A0
So here we're in similar territory to the discussions about RAs,= and multicast on certain types of links, which has led to the efficient-ND= proposal, and related work on energy efficiency for low power devices etc.= [http://www.ietf.org/internet-drafts/draft-halpern-6man= -nd-pre-resolve-addr-00.txt]

3) Trusted Scalable Service Discovery

This section is only focus= ed on how information provided by the SSD can be trusted. As every device a= nnounce their service, SSD SHOULD prevent an attacker to announce it is the= "CEO Printer" in order to collect all documents printed by the C= EO.
In this section, we consider that "CEO Printer" does not exists a= nd that the attack does not aim at hijacking a specific name. Using the SD = terminology "CEO Printer" would be the Instance part of the Servi= ce Instance Name.

a) User perspective
When DNS is used, DNSSEC can be used, and one ca= n trust the information as it provides from a trusted party. Although DNSSE= C has not been designed as a protocol that certifies the validity of the DN= S RDATA, in our case, DNSSEC could be used as such. Contrary to registrars = that are hosting FQDNs they have very few knowledge on, network administrat= ors are expected to administrated the DNS zone according to the resources a= vailable for the network. As a result DNSSEC validation could be interprete= d as "validated by the administrator".

mDNS does not have trust anchors provided by DNSSEC. However, DNSSEC us= ed in conjunction of mDNS can be used to provide a proof-of-ownership of th= e information. How reliable is that information can be learned over time by= processing the reputation of a device (represented by its public key) or b= y monitoring whether the information remains coherent over time. For exampl= e, if a printer announces its IP address as part of the company network, an= d suddenly starts announcing an IP address located somewhere else, further = checks may be performed before trusting the information. Even though the mD= NS message signed with DNS cannot be trusted the same way as it would have = been trusted in a DNSSEC zone, using DNSSEC in conjunction of mDNS makes po= ssible to assign some pieces of information to a specific key. This helps i= n establishing a reputation as well as avoids spoofed messages.

On a user perspective, mDNS requires the end user to establish a reputa= tion mechanism whereas DNS provides certified information. The main advanta= ge of DNS is that a new end user has certified information which is not pos= sible with mDNS.

[TBD check/compare hybrid model]

b) Devices perspective

W= hen DNS is used, the device MUST be able to provide the information to the = DNS server via DNS update [RFC2136] or secure DNS update [RFC3007]. This sc= enario may not meet a Zero configuration requirement as the DNS server need= s to know the public key of the devices, and the device needs to know at le= ast the IP address of the DNS server. If DHCPv6 the IP address of the MAY b= e derived from the Domain Search List and the DNS Recursive Name Server opt= ion [RFC3646]. The device MAY send a DNS query for one domain search with t= ype NS to the recursive name server. However, registering the public keys o= f the devices in the DNS does not scale thousands of devices. Most likely, = their public keys may be considered as trusted based on reputation, leap of= faith principles which does not necessarily prevent an attacker to set fal= se data into the DNS zone.
=A0=A0
When mDNS is used, the device does not need any configuration. T= his information is announced to the network. The information will be truste= d by the devices that trust the announcer. As for the DNS, provisioning all= devices of the network with all public keys is not scalable. As mentioned = above, public keys will be trusted most likely based on reputation or leap = of faith principles.

The main difference between DNS and mDNS seems that DNS requires less p= rovisioning or configuration than mDNS (n versus n * (n - 1) for a n device= network). Then in a zero configuration scenario, DNS centralises in a sing= le point the way a key can be trusted. The only disadvantage of using DNS i= s the devices should discover the DNS server.

It seems that approach combining mDNS and DNS can take advantage of bot= h. Devices announce information using mDNS and the DNS according to the lev= el of trust stores the information in its zone.


4) Information i= mpersonation

The previous section provided considerations on how a device can be ass= ociated to a public key and eventually identified as a trusted device. With= zero configuration, the level of trust associated to a device results of a= trade off between configuration and a learning process. This section indic= ates how information provided by the devices can be monitored to determine = the reputation of a device, to raise an alarm to the administrator, and eve= ntually show a device cannot be trusted or indicate a device has been=A0 co= rrupted.

The kind of informations provided by SD or SSD that are visible to the = end user are 1) a name that describes a service and 2) the location of the = service. The name of the service corresponds to Service Instance Name. With= SD the name is mentioned in the RDATA part of the PTR and as the key of th= e SRV RRSet. The location of the service is the RDATA part of the SRV as we= ll as its corresponding locator.

The Service Instance Name is composed of three parts: Instance, Service= Name and Domain. SD recommends that Instance and Domain are encoded using = UTF8. UTF8 enables specific characters that are not yet being considered in= the current DNS. Traditional DNS uses ascii or Punycode. If UTF8 is more f= lexible in term of string representation, it may provide multiple ways to e= xpress the same thing which may confuse the end user. In fact using UTF8 &q= uot;My Printer", "my printer" "My printer" are dif= ferent strings. This may be used by an attacker that will provide a service= different in term of UTF8 format, but that the end user will assimilate to= the same service. In addition, "my printer" will be displayed di= fferently if encoded in UTF8 or in ascii. As a result two service "my = printer" could be stored in a DNS zone without any collisions.
One way to avoid multiple format would be to consider the necessary or miss= ing characters provided by UTF8 and add them in the Puny code.
If there = may be some advantages in using UTF8 for the service name, the domain name = part SHOULD use only the Punycode.
As a result, checking information for SSD requires to establish metrics/sim= ilarities between strings.

Worth noting in the DNS the device might = be hpprint01.bldg32.somesi= te.com, while its internally stored label may be "Building 32 foye= r printer".


The location of the service is identified by a FQDN and a correspon= ding IP address. In SD, the FQDN respect the Punnycode encoding. The FQDN o= f the service may be checked against the known domain names associated to t= he network. Similarly, the IP address is generally used to locate the servi= ce. if the IP address is not inside the network, this may raise a warning t= o the administrator, that may validate the IP address.


When DNSSEC is used closed names addressed by different keys are su= spicious. Without the use of DNSSEC is becomes hard to detect the device/SD= device has not changed their IP address.


5) Unique network iden= tifier
=A0
SD uses ".local" prefix to indicate the scope of the FQDN= .=A0 ".local" is a special use domain name - RFC 6761, and in the= registry at
http://www.iana.org/assignments/sp= ecial-use-domain-names/special-use-domain-names.xhtml

".local" is instantiated in any networks. This results in a g= iven string with multiple meanings. "My Printer" at home is not t= he same service as "My Printer" at work and if the information is= cached in some devices, this may result in cross site name hijacking. An a= ttacker could for example advertise "My Printer" in a public netw= ork like in an airport with a global IP address. The Service Instance Name = used could be something as "My Printer_ipp_tcp.local SRV global-printer.example.com". Peop= le in the airport may then send their documents to "My Printer" a= dvertised in the airport - that is to say global-printer.example.com -, instead of the one of their = office.

In order to mitigate this confusion, ".local" SHOULD be used = only when the device does not know the domain name associated to the networ= k. If DHCPv6 is used this may be derived by the DHCPv6 Client FQDN option [= RFC4704].

Note also that "My printer" may be a different printer when I= am at home or at work. On the other hand, while at hoe I SHOULD be able to= use "My Office Printer" and vice versa. This ambiguity may be le= verage by the use of unique prefix.

6) Compromised device=A0=A0=A0=A0

This section estimates how a = compromised device impacts the SSD service. We assume DNSSEC is used.
Once detected, the public key associated to the device is revoked. With D= NS the revocation occurs once in the DNS, and the information is only store= d in the remaining caches of devices that have requested the information be= fore it expires. After TTL seconds, the information is revoked from all dev= ices. If mDNS is used, revocation should occur in every device. The mechani= sm to detect a device is compromised is complex and will probably not be im= plemented properly in most devices.

With the current SD, a compromised device MAY provide wrong information= about itself but does not affect others device information.



--
Daniel Migault
Orange Labs -- S= ecurity
+33 6 70 72 69 58
--047d7b5d377ac58ee604f04e3030-- From mglt.ietf@gmail.com Sun Jan 19 00:16:52 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 5A85D1A1F7B for ; Sun, 19 Jan 2014 00:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9W-PhJgTjj9 for ; Sun, 19 Jan 2014 00:16:48 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 814CC1ADBD5 for ; Sun, 19 Jan 2014 00:16:47 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id w62so5840699wes.24 for ; Sun, 19 Jan 2014 00:16:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=J3gNJBh5RqXYMT05KlOjfCXjMp63xn/DXMGH+s5NK3s=; b=RXOMMX3lnxI06shanbCNWY4+tMAtljeUWAED8J4nKv9KmkVUxf/5cu5yPXWs5GahGJ 0w19tp4FMzSOwydQX+0dUJIwxFZIDXmUhqcZJalIKPRFIV2yrtevDFOTb1SrRWmzxuk+ bQBIpnXk3kq4dAsOfmi8L2oOSb9ALzYZxHaFO4izzxbE/iS7DMft5TIizWOd48kn04HE Z4LYx3UT4m1ppQzDDT3KZHpkF/eIfDJanFBEpGLpOZjxExdSDYwcwvcZ9H8BOWJ3R3Eu WJcq2neJ5Fs+PtwPjRrUJunKBVd7ORlh/Utrc6PBSDweJfEQdG2on0Ho8SiEDoO4f/Yn i9mQ== MIME-Version: 1.0 X-Received: by 10.194.82.105 with SMTP id h9mr643440wjy.52.1390119393758; Sun, 19 Jan 2014 00:16:33 -0800 (PST) Received: by 10.194.171.129 with HTTP; Sun, 19 Jan 2014 00:16:33 -0800 (PST) Date: Sun, 19 Jan 2014 09:16:33 +0100 Message-ID: From: Daniel Migault To: dnssd@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Tim Chown , Kerry Lynn Subject: [dnssd] draft-ietf-dnssd-requirements-00.txt: Requirements/Security Considerations 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: Sun, 19 Jan 2014 08:16:52 -0000 Hi Folks, Here are some additional requirements for draft-ietf-dnssd-requirements-00.txt as well as a starting point for the security consideration section. This section has been updated with Tim's comments. Your are more than welcome to comment/clarify/change the proposed text. We would appreciate you provide them by Friday January 23 so they can be considered for the next version. Best Regards, Daniel ** Terminology section: I think we should add the following terms. I am using used them in the remaining of the mail. They may be changed for the draft. mDNS: multicast DNS as defined in [RFC6762] SSD: Scalable Service Discovery SD DNS-Based Service Discovery [RFC6763] ** Requirements section: I suggest adding or complete existing requirements with the following ones: SSD SHOULD be designed for both DNS and mDNS working in a cooperative way. More specifically, it SHOULD consider interaction between DNS and mDNS. SSD SHOULD be able to be performed by client only using DNS and unicast to avoid multiple multicast messages. SSD SHOULD work with existing DNS-Based Service Discovery over mDNS and SHOULD NOT break any other discovery protocols. As specified in the charter [http://datatracker.ietf.org/wg/dnssd/charter/] "The WG will consider the tradeoffs between reusing/extending existing protocols and developing entirely new ones. It is highly desirable that any new solution is backwardly compatible with existing DNS-SD/mDNS deployments. Any solution developed by the dnssd WG must not conflict or interfere with the operation of other zero-configuration service and naming protocols such as uPnP or LLMNR. Integration with such protocols is out of scope for this WG." and "To document challenges and problems encountered in the coexistence of zero configuration and global DNS name services in such multi-link networks, including consideration of both the name resolution mechanism and the namespace." SSD SHOULD consider the use of globally unique FQDN that is specific of a given network instead of a default domain name as ".local". SSD SHOULD provide means to discover/announce the FQDN associated to the network. A default and common FQDN - like ".local." could be used only when the specific FQDN of the network has not been determined. Furthermore, in order to ease interoperation with DNS the domain name SHOULD follow DNS-compatible encoding (i.e ascii or punycode). SSD SHOULD be able to take advantage of network configurations (DHCP/RA) protocol. If it is clear that SSD and DNS SHOULD be able to work together, DHCP may also be used to announce necessary information for the network such as its associated FQDN (using DHCP Domain Search / DHCP Domain option / IPv6 RA [RFC6106]), the interface to register FQDNs... This MAY for example complement or avoid the use of the specific b/db/r/dr/lb.dns-sd._udp. or equivalent queries. SSD SHOULD be able to announce the scope Service Discovery informations are expected to be accessed or multicasted. This requires something like a "scope" discovery protocol. ** Security Consideration section Here is some text I propose. Comments are more then welcome! I hope that we will be able to fix this section during the next meeting. 1. Scalable DNS Service is not an extension of SD in term of security Scalable DNS-Based Service Discovery can hardly rely on the security considerations defined for DNS-Based Service Discovery [RFC6763]. Considering "Scalability" requires new security practices that are defines in this document. DNS-Based Service Discovery [RFC6763] has been designed so that a device can announce a service to the other devices of the network. Although DNS or mDNS can be used for SD, SD has been mostly thought to work over mDNS to avoid DNS zone management and to handle UTF8 names for the end users even in the domain part of the Instance Service Name. As a result SD' security considerations rely on mDNS security considerations, DNSSEC [RFC4033] for authentication and secure DNS update [RFC3007] to secure DNS update [RFC2136]. These considerations are not sufficient for SSD as explained below. - a) DNSSEC is probably the DNS extension that MAY be used to provide authentication and integrity check protection. However, authentication other than proof-of-ownership or leap-of-faith security model requires trust anchors. Trust anchor MAY be provided by the global DNS, but this has not been specified in SD. Section 10 of RFC6763 illustrates how to populate the DNS with information but clearly states that such interactions are out of scope of RFC6763. Interactions between SSD and DNS cannot be specified in an illustrative section. - b) Similarly, DNS updates are used by SD to cooperate with DNS. These interactions are left as illustrative in RFC6763, which is not sufficient for SSD. -c) mDNS security considerations are not sufficient for SSD. At first, mDNS requires cooperative devices. If cooperative devices is a reasonable assumption in a one hop network such as most home networks, this assumption cannot be made for larger networks, such as corporate networks for example. In case all devices cannot trust each other, SD considers the use of IPsec or DNSSEC. How these protocols are used is not fully described in RFC6762 and SHOULD be at least documented for SSD. More specifically, DNSSEC can be used with different security models. Authentication of the devices may require a chain of trust and interaction with DNS. Alternatively authentication may rely on devices configured with certificates. In the absence of such certificates or chain of trust, a proof-of-ownership with device's reputation may be considered. mDNS considers the use of DNSSEC to differentiate responses from the global DNS and mDNS that addresses a local scope. DNSSEC may not be the appropriated solution for SSD as DNSSEC may not be deployed for the global DNS or for mDNS which would make distinction impossible. As suggested by RFC6761, the use of ".local" to specify mDNS may be more appropriated. mDNS also raises the issue of relative domain names (example.com) that may be solved as example.com.local. or as example.com.search-domain. This issue becomes more complex with SSD. For SD there is little ambiguity with the meaning of ".local". It is a single link, usually a single network. SSD considers multiple links and as such multiple ".local" and multiple different search domain. Thus the question may be which link's search domain is to be considered. mDNS considers very few interactions with DNS. The only mentioned case is when a global DNS resolution is performed using mDNS. mDNS indicates how to treat relative domains. Interaction between mDNS and DNS was not so necessary as with one hop network there is a clear separation between the local and non local (Internet) network. With multiple networks, the frontier between local and non local becomes much undefined. As result whether naming resolution is local (mDNS) or global (DNS) is not obvious. This is why SSD needs to specify interactions between DNS and mDNS whereas DNS-Based Service Discovery [RFC6763] does not. As a result security considerations for SSD considers 1) security considerations of SSD over mDNS, 2) security considerations of SSD over DNS and 3) security considerations on interactions between DNS and mDNS. As a result, security assumption of DNS-Based Service Discovery [RFC6763] are not any more valid for Scalable DNS-Based Service Discovery. 1) Privacy protection Information provided by SSD may contain private information that is not expected to go outside the specified scope. Service Discovery carry information about the type of devices available in your network, the software version, their location both physical like floor as well as networking - like the IP address. All these pieces of information may be useful for an intruder. Device and software information are useful to identify vulnerabilities, and location information are useful to locate the target, names may also include information that may be useful to define a specific target - like "Personal CEO Printer". For these reasons, one is willing to limit the scope these pieces of information. a) Informations spreading may be limited based on network information. When DNS is used, the DNS zone SHOULD NOT be accessed by anyone from outside the specific network. This can be performed at the DNS server level or at the network boundaries by setting firewall policies specifying which kind of IP address can access the DNS server. When mDNS is used, multicasted information SHOULD NOT be forwarded outside the expected network. This can be performed by firewalls that drops outbound/inbound mDNS packets at the network boundaries. Note that in both cases, these policies are outside the scope of mDNS or DNS. On the other hand, for mobile devices, for example, which information may be provided depends on the network. These policies have to be implemented by the mobile device. b) SSD SHOULD also consider scopes that are not correlated to network definitions like 'building' or 'room'. As defined in the charter: "It is also desirable that multiple discovery scopes are supported, from the point of view of either performing discovery within a specified scope or advertisement within a specified scope, and being able to discover (enumerate) the set of scopes such that an application could then choose to do either. It should be noted that scope in this sense might refer to 'building' or 'room' and thus might have no correlation to network topology." This requires 1) definition of the different available scopes. Some default value MAY be provided by the device without knowledge of the specific available scopes of the network. Such default values MAY be used by devices if they do not discover the different scopes specific to the network or if the device does not have sufficient information to trust the announced scopes. In that case the device MAY start with a default limited scope. 2) Specific network values SHOULD be announced in an authenticated way to avoid that, for example, non existing scope used results in service unavailable. The policy for non existing scopes SHOULD be defined with a reduced scope, and the device SHOULD be informed that the scope does not exist so it may update its scope. 3) Once devices have been informed of the various scope, it MAY chose the one that seems the most appropriated and provide this information. Depending on the scope, routers or middle boxes MAY chose to forward the information or not. The information MAY be forwarded on multiple links. With scopes that are not network correlated, the information MAY be forwarded to a subset of devices within a link. The use of distinct multicast IP address may be used to distinguish the different scopes. However, the use of different IP addresses does not prevent devices to listen to the information. If the device needs the information to be read only by the members of the scope, cryptography MAY be used to encrypt the data. IPsec multicast extension [RFC5374] may be a good candidate. This mechanism may also be used to prevent an unauthorised device to provide a service for a given scope. In other words, my printer should not be able to announce its service for the "CEO" scope and I should not be able to see the announcement of the printer of my CEO. 2) Exposing Services A Service announced over a network does not mean the service is available to anyone. Such services SHOULD enforce access control policies for the service. If a connected printer is not using SD, it MAY appear as a simple IP connected device attached to the network. Only specific tests/scans/traffic monitor can determine the device is a printer. When SD or SSD is used, as soon as the device is plugged on the network everyone knows "Photo Color Printer, Building A floor 2" has been plugged. If this printer is reserved for the Graphic an Design department, than the printer SHOULD implement access control mechanisms. Although these policies are out of scope of SSD, they MAY be required as a consequence of SSD. 2) Resource exhaustion With new emerging types of networks like sensor networks and more generally the IoT, SSD cannot anymore rely on mDNS and multicast to advertise its services and SHOULD provide a dedicated entity that can perform SSD via unicast messages. Typically, this can be deployed with a mDNS-to-DNS agent that receives announcement from mDNS devices and stores this information to the DNS zone. Since the information is stored, other devices in the network do not have to receive and treat mDNS announcements. SSD MUST be able to scale to thousands of devices. The use of multicast for service announcement requires that each device informs all other devices some information like the hosted service for example. In order to make sure devices always have the information up-to-date or that any new device has the information, the device regularly retransmits the information to all other devices. This is not a scalable architecture as it does not scale in term of bandwidth nor it consider energy consumption constrains of small devices. Any messages are bytes received by the devices connected on the network, which may require additional processing such as cryptographic check if used in conjunction with DNSSEC for example. These devices may rely on battery, and each of these messages directly impact the lifetime of the device. As a result aggressive multicast may unnecessarily affect IoT devices. More rational approach MAY consists in making possible SSD using unicast communications only or to prevent that IoT device wakes up at every multicast message or using multicast to announce information updates as opposed to cache populating. More specifically, a new device can use multicast to announce a newly published information. Eventually this information may be cached by always-on devices and stored in the DNS. A new device may get access to these pieces of information with an unicast AXFR for example. The main advantage is that multicast interface can be switched off. So here we're in similar territory to the discussions about RAs, and multicast on certain types of links, which has led to the efficient-ND proposal, and related work on energy efficiency for low power devices etc. [http://www.ietf.org/internet-drafts/draft-halpern-6man-nd-pre-resolve-addr-00.txt] 3) Trusted Scalable Service Discovery This section is only focused on how information provided by the SSD can be trusted. As every device announce their service, SSD SHOULD prevent an attacker to announce it is the "CEO Printer" in order to collect all documents printed by the CEO. In this section, we consider that "CEO Printer" does not exists and that the attack does not aim at hijacking a specific name. Using the SD terminology "CEO Printer" would be the Instance part of the Service Instance Name. a) User perspective When DNS is used, DNSSEC can be used, and one can trust the information as it provides from a trusted party. Although DNSSEC has not been designed as a protocol that certifies the validity of the DNS RDATA, in our case, DNSSEC could be used as such. Contrary to registrars that are hosting FQDNs they have very few knowledge on, network administrators are expected to administrated the DNS zone according to the resources available for the network. As a result DNSSEC validation could be interpreted as "validated by the administrator". mDNS does not have trust anchors provided by DNSSEC. However, DNSSEC used in conjunction of mDNS can be used to provide a proof-of-ownership of the information. How reliable is that information can be learned over time by processing the reputation of a device (represented by its public key) or by monitoring whether the information remains coherent over time. For example, if a printer announces its IP address as part of the company network, and suddenly starts announcing an IP address located somewhere else, further checks may be performed before trusting the information. Even though the mDNS message signed with DNS cannot be trusted the same way as it would have been trusted in a DNSSEC zone, using DNSSEC in conjunction of mDNS makes possible to assign some pieces of information to a specific key. This helps in establishing a reputation as well as avoids spoofed messages. On a user perspective, mDNS requires the end user to establish a reputation mechanism whereas DNS provides certified information. The main advantage of DNS is that a new end user has certified information which is not possible with mDNS. [TBD check/compare hybrid model] b) Devices perspective When DNS is used, the device MUST be able to provide the information to the DNS server via DNS update [RFC2136] or secure DNS update [RFC3007]. This scenario may not meet a Zero configuration requirement as the DNS server needs to know the public key of the devices, and the device needs to know at least the IP address of the DNS server. If DHCPv6 the IP address of the MAY be derived from the Domain Search List and the DNS Recursive Name Server option [RFC3646]. The device MAY send a DNS query for one domain search with type NS to the recursive name server. However, registering the public keys of the devices in the DNS does not scale thousands of devices. Most likely, their public keys may be considered as trusted based on reputation, leap of faith principles which does not necessarily prevent an attacker to set false data into the DNS zone. When mDNS is used, the device does not need any configuration. This information is announced to the network. The information will be trusted by the devices that trust the announcer. As for the DNS, provisioning all devices of the network with all public keys is not scalable. As mentioned above, public keys will be trusted most likely based on reputation or leap of faith principles. The main difference between DNS and mDNS seems that DNS requires less provisioning or configuration than mDNS (n versus n * (n - 1) for a n device network). Then in a zero configuration scenario, DNS centralises in a single point the way a key can be trusted. The only disadvantage of using DNS is the devices should discover the DNS server. It seems that approach combining mDNS and DNS can take advantage of both. Devices announce information using mDNS and the DNS according to the level of trust stores the information in its zone. 4) Information impersonation The previous section provided considerations on how a device can be associated to a public key and eventually identified as a trusted device. With zero configuration, the level of trust associated to a device results of a trade off between configuration and a learning process. This section indicates how information provided by the devices can be monitored to determine the reputation of a device, to raise an alarm to the administrator, and eventually show a device cannot be trusted or indicate a device has been corrupted. The kind of informations provided by SD or SSD that are visible to the end user are 1) a name that describes a service and 2) the location of the service. The name of the service corresponds to Service Instance Name. With SD the name is mentioned in the RDATA part of the PTR and as the key of the SRV RRSet. The location of the service is the RDATA part of the SRV as well as its corresponding locator. The Service Instance Name is composed of three parts: Instance, Service Name and Domain. SD recommends that Instance and Domain are encoded using UTF8. UTF8 enables specific characters that are not yet being considered in the current DNS. Traditional DNS uses ascii or Punycode. If UTF8 is more flexible in term of string representation, it may provide multiple ways to express the same thing which may confuse the end user. In fact using UTF8 "My Printer", "my printer" "My printer" are different strings. This may be used by an attacker that will provide a service different in term of UTF8 format, but that the end user will assimilate to the same service. In addition, "my printer" will be displayed differently if encoded in UTF8 or in ascii. As a result two service "my printer" could be stored in a DNS zone without any collisions. One way to avoid multiple format would be to consider the necessary or missing characters provided by UTF8 and add them in the Puny code. If there may be some advantages in using UTF8 for the service name, the domain name part SHOULD use only the Punycode. As a result, checking information for SSD requires to establish metrics/similarities between strings. Worth noting in the DNS the device might be hpprint01.bldg32.somesite.com, while its internally stored label may be "Building 32 foyer printer". The location of the service is identified by a FQDN and a corresponding IP address. In SD, the FQDN respect the Punnycode encoding. The FQDN of the service may be checked against the known domain names associated to the network. Similarly, the IP address is generally used to locate the service. if the IP address is not inside the network, this may raise a warning to the administrator, that may validate the IP address. When DNSSEC is used closed names addressed by different keys are suspicious. Without the use of DNSSEC is becomes hard to detect the device/SD device has not changed their IP address. 5) Unique network identifier SD uses ".local" prefix to indicate the scope of the FQDN. ".local" is a special use domain name - RFC 6761, and in the registry at http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml ".local" is instantiated in any networks. This results in a given string with multiple meanings. "My Printer" at home is not the same service as "My Printer" at work and if the information is cached in some devices, this may result in cross site name hijacking. An attacker could for example advertise "My Printer" in a public network like in an airport with a global IP address. The Service Instance Name used could be something as "My Printer_ipp_tcp.local SRV global-printer.example.com". People in the airport may then send their documents to "My Printer" advertised in the airport - that is to say global-printer.example.com -, instead of the one of their office. In order to mitigate this confusion, ".local" SHOULD be used only when the device does not know the domain name associated to the network. If DHCPv6 is used this may be derived by the DHCPv6 Client FQDN option [RFC4704]. Note also that "My printer" may be a different printer when I am at home or at work. On the other hand, while at hoe I SHOULD be able to use "My Office Printer" and vice versa. This ambiguity may be leverage by the use of unique prefix. 6) Compromised device This section estimates how a compromised device impacts the SSD service. We assume DNSSEC is used. Once detected, the public key associated to the device is revoked. With DNS the revocation occurs once in the DNS, and the information is only stored in the remaining caches of devices that have requested the information before it expires. After TTL seconds, the information is revoked from all devices. If mDNS is used, revocation should occur in every device. The mechanism to detect a device is compromised is complex and will probably not be implemented properly in most devices. With the current SD, a compromised device MAY provide wrong information about itself but does not affect others device information. -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 From dengguangqing@cnnic.cn Mon Jan 20 23:54:20 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 782531A0054 for ; Mon, 20 Jan 2014 23:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.365 X-Spam-Level: ** X-Spam-Status: No, score=2.365 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FSL_NEW_HELO_USER=2.099, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] 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 AKUOCtpsyQCq for ; Mon, 20 Jan 2014 23:54:14 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id B29B91A0020 for ; Mon, 20 Jan 2014 23:54:11 -0800 (PST) X-EYOUMAIL-SMTPAUTH: dengguangqing@cnnic.cn Received: from unknown127.0.0.1 (HELO user-think) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 21 Jan 2014 15:54:08 +0800 Date: Tue, 21 Jan 2014 15:54:09 +0800 From: "Guangqing Deng" To: "Daniel Migault" References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 1, 3, 52[cn] Mime-Version: 1.0 Message-ID: <2014012115540802807511@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart027738470163_=----" Cc: dnssd Subject: Re: [dnssd] draft-ietf-dnssd-requirements-00.txt: Requirements/Security Considerations 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, 21 Jan 2014 07:54:20 -0000 This is a multi-part message in MIME format. ------=_001_NextPart027738470163_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIERhbmllbCwgc28gbWFueSBkZXRhaWxzIG9uIFNTRCByZXF1aXJlbWVudHMgYXJlIHByZXNl bnRlZCBoZXJlLCB3aGljaCBoZWxwcyBtZSBoYXZlIGEgbW9yZSBkZWVwIHVuZGVyc3RhbmRpbmcg b24gdGhpcyBpc3N1ZS4gSXQgaXMgc2FpZCB0aGF0IElQc2VjIGFuZCBETlNTRUMgY2FuIGJlIHVz ZWQgdG8gYXV0aGVudGljYXRlIHRoZSBkZXZpY2VzIHRlbmRpbmcgdG8gcHJvdmlkZSBzZXJ2aWNl LiBXaGlsZSBvbmUgcXVlc3Rpb24gaXMgdGhhdCB0aGUgZGVwbG95bWVudCBvZiBJUHNlYyBhbmQg RE5TU0VDIG1heSBsZWFkIHRvIGhpZ2hseSBpbmNyZWFzZWQgdHJhZmZpYyB3aXRoaW4gdGhlIGxv Y2FsIG5ldHdvcmsuIEFuZCBmb3IgdGhvc2UgdGVtcG9yYXJ5IHNlcnZpY2UgcHJvdmlkZXJzICh3 aGljaCBqdXN0IHByb3ZpZGUgc2VydmljZXMgaW4gYSBzaG9ydCB0aW1lIGluIGEgbWVzaCB3aXJl bGVzcyBuZXR3b3JrLCBmb3IgaW5zdGFuY2UpLCB0aGUgcHJvY2VzcyBvZiB0ZW1wb3Jhcnkgc2Vy dmljZSBwcm92aWRlciByZWdpc3RlcmluZyBvbiBETlNTRUMgc3lzdGVtIG1heSBiZSB0b28gbG9u ZyBjb21wYXJlZCB3aXRoIHRoZSByZWxhdGl2ZWx5IHNob3J0IHNlcnZpbmcgcGVyaW9kLiBBbHNv LCB0aGUgRE5TU0VDIHN5c3RlbSBoYXMgdG8gcmV2b2tlIHRoZSBwdWJsaWMga2V5IG9mIHRoZSB0 ZW1wb3Jhcnkgc2VydmljZSBwcm92aWRlciBpZiBpdCBoYXMgZ29uZSBvZmYtbGluZS4gU28gaXQg c2VlbXMgdGhhdCB3ZSBzaG91bGQgY2xhcmlmeSB0aGUgc2VydmljZSBtZW50aW9uZWQgaW4gdGhp cyBXRy4gSXMgdGhlIHNlcnZpY2UgbWVudGlvbmVkIGluIHRoaXMgV0cgbWVhbnMgYSBsb25nLXRl cm0gb25lIG9yIHNob3J0LXRlcm0gb25lIG9yIGJvdGg/DQoNCg0KDQoNCkd1YW5ncWluZyBEZW5n DQpDTk5JQyANCg0KRnJvbTogRGFuaWVsIE1pZ2F1bHQNCkRhdGU6IDIwMTQtMDEtMTkgMTY6MDIN ClRvOiBkbnNzZA0KQ0M6IFRpbSBDaG93bjsgS2VycnkgTHlubg0KU3ViamVjdDogW2Ruc3NkXSBk cmFmdC1pZXRmLWRuc3NkLXJlcXVpcmVtZW50cy0wMC50eHQ6IFJlcXVpcmVtZW50cy9TZWN1cml0 eSBDb25zaWRlcmF0aW9ucw0KSGkgRm9sa3MsIA0KDQoNCkhlcmUgYXJlIHNvbWUgYWRkaXRpb25h bCByZXF1aXJlbWVudHMgZm9yICBkcmFmdC1pZXRmLWRuc3NkLXJlcXVpcmVtZW50cy0wMC50eHQg YXMgd2VsbCBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlv biBzZWN0aW9uLiBUaGlzIHNlY3Rpb24gaGFzIGJlZW4gdXBkYXRlZCB3aXRoIFRpbSdzIGNvbW1l bnRzLg0KDQoNCllvdXIgYXJlIG1vcmUgdGhhbiB3ZWxjb21lIHRvIGNvbW1lbnQvY2xhcmlmeS9j aGFuZ2UgdGhlIHByb3Bvc2VkIHRleHQuIFdlIHdvdWxkIGFwcHJlY2lhdGUgeW91IHByb3ZpZGUg dGhlbSBieSBGcmlkYXkgSmFudWFyeSAyMyBzbyB0aGV5IGNhbiBiZSBjb25zaWRlcmVkIGZvciB0 aGUgbmV4dCB2ZXJzaW9uLg0KDQpCZXN0IFJlZ2FyZHMsDQoNCg0KRGFuaWVsDQogDQoNClRlcm1p bm9sb2d5IHNlY3Rpb246DQoNCkkgdGhpbmsgd2Ugc2hvdWxkIGFkZCB0aGUgZm9sbG93aW5nIHRl cm1zLiBJIGFtIHVzaW5nIHVzZWQgdGhlbSBpbiB0aGUgcmVtYWluaW5nIG9mIHRoZSBtYWlsLiBU aGV5IG1heSBiZSBjaGFuZ2VkIGZvciB0aGUgZHJhZnQuDQoNCm1ETlM6IG11bHRpY2FzdCBETlMg YXMgZGVmaW5lZCBpbiBbUkZDNjc2Ml0NClNTRDogU2NhbGFibGUgU2VydmljZSBEaXNjb3ZlcnkN ClNEIEROUy1CYXNlZCBTZXJ2aWNlIERpc2NvdmVyeSBbUkZDNjc2M10NCg0KUmVxdWlyZW1lbnRz IHNlY3Rpb246DQoNCkkgc3VnZ2VzdCBhZGRpbmcgb3IgY29tcGxldGUgZXhpc3RpbmcgcmVxdWly ZW1lbnRzIHdpdGggdGhlIGZvbGxvd2luZyBvbmVzOg0KDQpTU0QgU0hPVUxEIGJlIGRlc2lnbmVk IGZvciBib3RoIEROUyBhbmQgbUROUyB3b3JraW5nIGluIGEgY29vcGVyYXRpdmUgd2F5LiBNb3Jl IHNwZWNpZmljYWxseSwgaXQgU0hPVUxEIGNvbnNpZGVyIGludGVyYWN0aW9uIGJldHdlZW4gRE5T IGFuZCBtRE5TLg0KDQpTU0QgU0hPVUxEIGJlIGFibGUgdG8gYmUgcGVyZm9ybWVkIGJ5IGNsaWVu dCBvbmx5IHVzaW5nIEROUyBhbmQgdW5pY2FzdCB0byBhdm9pZCBtdWx0aXBsZSBtdWx0aWNhc3Qg bWVzc2FnZXMuDQoNClNTRCBTSE9VTEQgd29yayB3aXRoIGV4aXN0aW5nIEROUy1CYXNlZCBTZXJ2 aWNlIERpc2NvdmVyeSBvdmVyIG1ETlMgYW5kIFNIT1VMRCBOT1QgYnJlYWsgYW55IG90aGVyIGRp c2NvdmVyeSBwcm90b2NvbHMuIA0KQXMgc3BlY2lmaWVkIGluIHRoZSBjaGFydGVyIFtodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvZG5zc2QvY2hhcnRlci9dDQoiVGhlIFdHIHdpbGwgY29u c2lkZXIgdGhlIHRyYWRlb2ZmcyBiZXR3ZWVuIHJldXNpbmcvZXh0ZW5kaW5nIGV4aXN0aW5nDQpw cm90b2NvbHMgYW5kIGRldmVsb3BpbmcgZW50aXJlbHkgbmV3IG9uZXMuIEl0IGlzIGhpZ2hseSBk ZXNpcmFibGUNCnRoYXQgYW55IG5ldyBzb2x1dGlvbiBpcyBiYWNrd2FyZGx5IGNvbXBhdGlibGUg d2l0aCBleGlzdGluZyBETlMtU0QvbUROUw0KZGVwbG95bWVudHMuIEFueSBzb2x1dGlvbiBkZXZl bG9wZWQgYnkgdGhlIGRuc3NkIFdHIG11c3Qgbm90IGNvbmZsaWN0DQpvciBpbnRlcmZlcmUgd2l0 aCB0aGUgb3BlcmF0aW9uIG9mIG90aGVyIHplcm8tY29uZmlndXJhdGlvbiBzZXJ2aWNlIGFuZA0K bmFtaW5nIHByb3RvY29scyBzdWNoIGFzIHVQblAgb3IgTExNTlIuIEludGVncmF0aW9uIHdpdGgg c3VjaCBwcm90b2NvbHMNCmlzIG91dCBvZiBzY29wZSBmb3IgdGhpcyBXRy4iDQoNCmFuZA0KDQoi VG8gZG9jdW1lbnQgY2hhbGxlbmdlcyBhbmQgcHJvYmxlbXMgZW5jb3VudGVyZWQgaW4gdGhlIGNv ZXhpc3RlbmNlIA0Kb2YgemVybyBjb25maWd1cmF0aW9uIGFuZCBnbG9iYWwgRE5TIG5hbWUgc2Vy dmljZXMgaW4gc3VjaCANCm11bHRpLWxpbmsgbmV0d29ya3MsIGluY2x1ZGluZyBjb25zaWRlcmF0 aW9uIG9mIGJvdGggdGhlIG5hbWUgDQpyZXNvbHV0aW9uIG1lY2hhbmlzbSBhbmQgdGhlIG5hbWVz cGFjZS4iDQoNCg0KU1NEIFNIT1VMRCBjb25zaWRlciB0aGUgdXNlIG9mIGdsb2JhbGx5IHVuaXF1 ZSBGUUROIHRoYXQgaXMgc3BlY2lmaWMgb2YgYSBnaXZlbiBuZXR3b3JrIGluc3RlYWQgb2YgYSBk ZWZhdWx0IGRvbWFpbiBuYW1lIGFzICIubG9jYWwiLiBTU0QgU0hPVUxEIHByb3ZpZGUgbWVhbnMg dG8gZGlzY292ZXIvYW5ub3VuY2UgdGhlIEZRRE4gYXNzb2NpYXRlZCB0byB0aGUgbmV0d29yay4g QSBkZWZhdWx0IGFuZCBjb21tb24gRlFETiAtIGxpa2UgIi5sb2NhbC4iIGNvdWxkIGJlIHVzZWQg b25seSB3aGVuIHRoZSBzcGVjaWZpYyBGUUROIG9mIHRoZSBuZXR3b3JrIGhhcyBub3QgYmVlbiBk ZXRlcm1pbmVkLiBGdXJ0aGVybW9yZSwgaW4gb3JkZXIgdG8gZWFzZSBpbnRlcm9wZXJhdGlvbiB3 aXRoIEROUyB0aGUgZG9tYWluIG5hbWUgU0hPVUxEIGZvbGxvdyBETlMtY29tcGF0aWJsZSBlbmNv ZGluZyAoaS5lIGFzY2lpIG9yIHB1bnljb2RlKS4NCg0KDQpTU0QgU0hPVUxEIGJlIGFibGUgdG8g dGFrZSBhZHZhbnRhZ2Ugb2YgbmV0d29yayBjb25maWd1cmF0aW9ucyAoREhDUC9SQSkgcHJvdG9j b2wuIElmIGl0IGlzIGNsZWFyIHRoYXQgU1NEIGFuZCBETlMgU0hPVUxEIGJlIGFibGUgdG8gd29y ayB0b2dldGhlciwgREhDUCBtYXkgYWxzbyBiZSB1c2VkIHRvIGFubm91bmNlIG5lY2Vzc2FyeSBp bmZvcm1hdGlvbiBmb3IgdGhlIG5ldHdvcmsgc3VjaCBhcyBpdHMgYXNzb2NpYXRlZCBGUUROICh1 c2luZyBESENQIERvbWFpbiBTZWFyY2ggLyBESENQIERvbWFpbiBvcHRpb24gLyBJUHY2IFJBIFtS RkM2MTA2XSksIHRoZSBpbnRlcmZhY2UgdG8gcmVnaXN0ZXIgRlFETnMuLi4gVGhpcyBNQVkgZm9y IGV4YW1wbGUgY29tcGxlbWVudCBvciBhdm9pZCB0aGUgdXNlIG9mIHRoZSBzcGVjaWZpYyBiL2Ri L3IvZHIvbGIuZG5zLXNkLl91ZHAuPGRvbWFpbj4gb3IgZXF1aXZhbGVudCBxdWVyaWVzLiAgDQoN Cg0KU1NEIFNIT1VMRCBiZSBhYmxlIHRvIGFubm91bmNlIHRoZSBzY29wZSBTZXJ2aWNlIERpc2Nv dmVyeSBpbmZvcm1hdGlvbnMgYXJlIGV4cGVjdGVkIHRvIGJlIGFjY2Vzc2VkIG9yIG11bHRpY2Fz dGVkLiBUaGlzIHJlcXVpcmVzIHNvbWV0aGluZyBsaWtlIGEgInNjb3BlIiBkaXNjb3ZlcnkgcHJv dG9jb2wuDQoNCg0KU2VjdXJpdHkgQ29uc2lkZXJhdGlvbiBzZWN0aW9uDQoNCkhlcmUgaXMgc29t ZSB0ZXh0IEkgcHJvcG9zZS4gQ29tbWVudHMgYXJlIG1vcmUgdGhlbiB3ZWxjb21lISBJIGhvcGUg dGhhdCB3ZSB3aWxsIGJlIGFibGUgdG8gZml4IHRoaXMgc2VjdGlvbiBkdXJpbmcgdGhlIG5leHQg bWVldGluZy4NCg0KDQoxLiBTY2FsYWJsZSBETlMgU2VydmljZSBpcyBub3QgYW4gZXh0ZW5zaW9u IG9mIFNEIGluIHRlcm0gb2Ygc2VjdXJpdHkNCg0KU2NhbGFibGUgRE5TLUJhc2VkIFNlcnZpY2Ug RGlzY292ZXJ5IGNhbiBoYXJkbHkgcmVseSBvbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg ZGVmaW5lZCBmb3IgRE5TLUJhc2VkIFNlcnZpY2UgRGlzY292ZXJ5IFtSRkM2NzYzXS4gQ29uc2lk ZXJpbmcgIlNjYWxhYmlsaXR5IiByZXF1aXJlcyBuZXcgc2VjdXJpdHkgcHJhY3RpY2VzIHRoYXQg YXJlIGRlZmluZXMgaW4gdGhpcyBkb2N1bWVudC4NCg0KRE5TLUJhc2VkIFNlcnZpY2UgRGlzY292 ZXJ5IFtSRkM2NzYzXSBoYXMgYmVlbiBkZXNpZ25lZCBzbyB0aGF0IGEgZGV2aWNlIGNhbiBhbm5v dW5jZSBhIHNlcnZpY2UgdG8gdGhlIG90aGVyIGRldmljZXMgb2YgdGhlIG5ldHdvcmsuIEFsdGhv dWdoIEROUyBvciBtRE5TIGNhbiBiZSB1c2VkIGZvciBTRCwgU0QgaGFzIGJlZW4gbW9zdGx5IHRo b3VnaHQgdG8gd29yayBvdmVyIG1ETlMgdG8gYXZvaWQgRE5TIHpvbmUgbWFuYWdlbWVudCBhbmQg dG8gaGFuZGxlIFVURjggbmFtZXMgZm9yIHRoZSBlbmQgdXNlcnMgZXZlbiBpbiB0aGUgZG9tYWlu IHBhcnQgb2YgdGhlIEluc3RhbmNlIFNlcnZpY2UgTmFtZS4gQXMgYSByZXN1bHQgU0QnIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIHJlbHkgb24gbUROUyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucywg RE5TU0VDIFtSRkM0MDMzXSBmb3IgYXV0aGVudGljYXRpb24gYW5kIHNlY3VyZSBETlMgdXBkYXRl IFtSRkMzMDA3XSB0byBzZWN1cmUgRE5TIHVwZGF0ZSBbUkZDMjEzNl0uIFRoZXNlIGNvbnNpZGVy YXRpb25zIGFyZSBub3Qgc3VmZmljaWVudCBmb3IgU1NEIGFzIGV4cGxhaW5lZCBiZWxvdy4NCg0K ICAgIC0gYSkgRE5TU0VDIGlzIHByb2JhYmx5IHRoZSBETlMgZXh0ZW5zaW9uIHRoYXQgTUFZIGJl IHVzZWQgdG8gcHJvdmlkZSBhdXRoZW50aWNhdGlvbiBhbmQgaW50ZWdyaXR5IGNoZWNrIHByb3Rl Y3Rpb24uIEhvd2V2ZXIsIGF1dGhlbnRpY2F0aW9uIG90aGVyIHRoYW4gcHJvb2Ytb2Ytb3duZXJz aGlwIG9yIGxlYXAtb2YtZmFpdGggc2VjdXJpdHkgbW9kZWwgcmVxdWlyZXMgdHJ1c3QgYW5jaG9y cy4gVHJ1c3QgYW5jaG9yIE1BWSBiZSBwcm92aWRlZCBieSB0aGUgZ2xvYmFsIEROUywgYnV0IHRo aXMgaGFzIG5vdCBiZWVuIHNwZWNpZmllZCBpbiBTRC4gU2VjdGlvbiAxMCBvZiBSRkM2NzYzIGls bHVzdHJhdGVzIGhvdyB0byBwb3B1bGF0ZSB0aGUgRE5TIHdpdGggaW5mb3JtYXRpb24gYnV0IGNs ZWFybHkgc3RhdGVzIHRoYXQgc3VjaCBpbnRlcmFjdGlvbnMgYXJlIG91dCBvZiBzY29wZSBvZiBS RkM2NzYzLiBJbnRlcmFjdGlvbnMgYmV0d2VlbiBTU0QgYW5kIEROUyBjYW5ub3QgYmUgc3BlY2lm aWVkIGluIGFuIGlsbHVzdHJhdGl2ZSBzZWN0aW9uLg0KDQogICAgLSBiKSBTaW1pbGFybHksIERO UyB1cGRhdGVzIGFyZSB1c2VkIGJ5IFNEIHRvIGNvb3BlcmF0ZSB3aXRoIEROUy4gVGhlc2UgaW50 ZXJhY3Rpb25zIGFyZSBsZWZ0IGFzIGlsbHVzdHJhdGl2ZSBpbiBSRkM2NzYzLCB3aGljaCBpcyBu b3Qgc3VmZmljaWVudCBmb3IgU1NELg0KDQogICAgLWMpIG1ETlMgc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMgYXJlIG5vdCBzdWZmaWNpZW50IGZvciBTU0QuIEF0IGZpcnN0LCBtRE5TIHJlcXVpcmVz IGNvb3BlcmF0aXZlIGRldmljZXMuIElmIGNvb3BlcmF0aXZlIGRldmljZXMgaXMgYSByZWFzb25h YmxlIGFzc3VtcHRpb24gaW4gYSBvbmUgaG9wIG5ldHdvcmsgc3VjaCBhcyBtb3N0IGhvbWUgbmV0 d29ya3MsIHRoaXMgYXNzdW1wdGlvbiBjYW5ub3QgYmUgbWFkZSBmb3IgbGFyZ2VyIG5ldHdvcmtz LCBzdWNoIGFzIGNvcnBvcmF0ZSBuZXR3b3JrcyBmb3IgZXhhbXBsZS4gDQoNCiAgICAgICBJbiBj YXNlIGFsbCBkZXZpY2VzIGNhbm5vdCB0cnVzdCBlYWNoIG90aGVyLCBTRCBjb25zaWRlcnMgdGhl IHVzZSBvZiBJUHNlYyBvciBETlNTRUMuIEhvdyB0aGVzZSBwcm90b2NvbHMgYXJlIHVzZWQgaXMg bm90IGZ1bGx5IGRlc2NyaWJlZCBpbiBSRkM2NzYyIGFuZCBTSE9VTEQgYmUgYXQgbGVhc3QgZG9j dW1lbnRlZCBmb3IgU1NELiBNb3JlIHNwZWNpZmljYWxseSwgRE5TU0VDIGNhbiBiZSB1c2VkIHdp dGggZGlmZmVyZW50IHNlY3VyaXR5IG1vZGVscy4gQXV0aGVudGljYXRpb24gb2YgdGhlIGRldmlj ZXMgbWF5IHJlcXVpcmUgYSBjaGFpbiBvZiB0cnVzdCBhbmQgaW50ZXJhY3Rpb24gd2l0aCBETlMu IEFsdGVybmF0aXZlbHkgYXV0aGVudGljYXRpb24gbWF5IHJlbHkgb24gZGV2aWNlcyBjb25maWd1 cmVkIHdpdGggY2VydGlmaWNhdGVzLiBJbiB0aGUgYWJzZW5jZSBvZiBzdWNoIGNlcnRpZmljYXRl cyBvciBjaGFpbiBvZiB0cnVzdCwgYSBwcm9vZi1vZi1vd25lcnNoaXAgd2l0aCBkZXZpY2UncyBy ZXB1dGF0aW9uIG1heSBiZSBjb25zaWRlcmVkLiAgDQoNCiAgICAgIG1ETlMgY29uc2lkZXJzIHRo ZSB1c2Ugb2YgRE5TU0VDIHRvIGRpZmZlcmVudGlhdGUgcmVzcG9uc2VzIGZyb20gdGhlIGdsb2Jh bCBETlMgYW5kIG1ETlMgdGhhdCBhZGRyZXNzZXMgYSBsb2NhbCBzY29wZS4gRE5TU0VDIG1heSBu b3QgYmUgdGhlIGFwcHJvcHJpYXRlZCBzb2x1dGlvbiBmb3IgU1NEIGFzIEROU1NFQyBtYXkgbm90 IGJlIGRlcGxveWVkIGZvciB0aGUgZ2xvYmFsIEROUyBvciBmb3IgbUROUyB3aGljaCB3b3VsZCBt YWtlIGRpc3RpbmN0aW9uIGltcG9zc2libGUuIEFzIHN1Z2dlc3RlZCBieSBSRkM2NzYxLCB0aGUg dXNlIG9mICIubG9jYWwiIHRvIHNwZWNpZnkgbUROUyBtYXkgYmUgbW9yZSBhcHByb3ByaWF0ZWQu IA0KDQogICAgICBtRE5TIGFsc28gcmFpc2VzIHRoZSBpc3N1ZSBvZiByZWxhdGl2ZSBkb21haW4g bmFtZXMgKGV4YW1wbGUuY29tKSB0aGF0IG1heSBiZSBzb2x2ZWQgYXMgZXhhbXBsZS5jb20ubG9j YWwuIG9yIGFzIGV4YW1wbGUuY29tLnNlYXJjaC1kb21haW4uIFRoaXMgaXNzdWUgYmVjb21lcyBt b3JlIGNvbXBsZXggd2l0aCBTU0QuIEZvciBTRCB0aGVyZSBpcyBsaXR0bGUgYW1iaWd1aXR5IHdp dGggdGhlIG1lYW5pbmcgb2YgIi5sb2NhbCIuIEl0IGlzIGEgc2luZ2xlIGxpbmssIHVzdWFsbHkg YSBzaW5nbGUgbmV0d29yay4gU1NEIGNvbnNpZGVycyBtdWx0aXBsZSBsaW5rcyBhbmQgYXMgc3Vj aCBtdWx0aXBsZSAiLmxvY2FsIiBhbmQgbXVsdGlwbGUgZGlmZmVyZW50IHNlYXJjaCBkb21haW4u IFRodXMgdGhlIHF1ZXN0aW9uIG1heSBiZSB3aGljaCBsaW5rJ3Mgc2VhcmNoIGRvbWFpbiBpcyB0 byBiZSBjb25zaWRlcmVkLiANCiAgICANCiAgICAgIG1ETlMgY29uc2lkZXJzIHZlcnkgZmV3IGlu dGVyYWN0aW9ucyB3aXRoIEROUy4gVGhlIG9ubHkgbWVudGlvbmVkIGNhc2UgaXMgd2hlbiBhIGds b2JhbCBETlMgcmVzb2x1dGlvbiBpcyBwZXJmb3JtZWQgdXNpbmcgbUROUy4gbUROUyBpbmRpY2F0 ZXMgaG93IHRvIHRyZWF0IHJlbGF0aXZlIGRvbWFpbnMuIEludGVyYWN0aW9uIGJldHdlZW4gbURO UyBhbmQgRE5TIHdhcyBub3Qgc28gbmVjZXNzYXJ5IGFzIHdpdGggb25lIGhvcCBuZXR3b3JrIHRo ZXJlIGlzIGEgY2xlYXIgc2VwYXJhdGlvbiBiZXR3ZWVuIHRoZSBsb2NhbCBhbmQgbm9uIGxvY2Fs IChJbnRlcm5ldCkgbmV0d29yay4gV2l0aCBtdWx0aXBsZSBuZXR3b3JrcywgdGhlIGZyb250aWVy IGJldHdlZW4gbG9jYWwgYW5kIG5vbiBsb2NhbCBiZWNvbWVzIG11Y2ggdW5kZWZpbmVkLiBBcyBy ZXN1bHQgd2hldGhlciBuYW1pbmcgcmVzb2x1dGlvbiBpcyBsb2NhbCAobUROUykgb3IgZ2xvYmFs IChETlMpIGlzIG5vdCBvYnZpb3VzLiBUaGlzIGlzIHdoeSBTU0QgbmVlZHMgdG8gc3BlY2lmeSBp bnRlcmFjdGlvbnMgYmV0d2VlbiBETlMgYW5kIG1ETlMgd2hlcmVhcyBETlMtQmFzZWQgU2Vydmlj ZSBEaXNjb3ZlcnkgW1JGQzY3NjNdIGRvZXMgbm90LiBBcyBhIHJlc3VsdCBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyBmb3IgU1NEIGNvbnNpZGVycyAxKSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBv ZiBTU0Qgb3ZlciBtRE5TLCAyKSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBvZiBTU0Qgb3ZlciBE TlMgYW5kIDMpIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIG9uIGludGVyYWN0aW9ucyBiZXR3ZWVu IEROUyBhbmQgbUROUy4NCg0KDQpBcyBhIHJlc3VsdCwgc2VjdXJpdHkgYXNzdW1wdGlvbiBvZiBE TlMtQmFzZWQgU2VydmljZSBEaXNjb3ZlcnkgW1JGQzY3NjNdIGFyZSBub3QgYW55IG1vcmUgdmFs aWQgZm9yIFNjYWxhYmxlIEROUy1CYXNlZCBTZXJ2aWNlIERpc2NvdmVyeS4gDQoNCjEpIFByaXZh Y3kgcHJvdGVjdGlvbg0KDQpJbmZvcm1hdGlvbiBwcm92aWRlZCBieSBTU0QgbWF5IGNvbnRhaW4g cHJpdmF0ZSBpbmZvcm1hdGlvbiB0aGF0IGlzIG5vdCBleHBlY3RlZCB0byBnbyBvdXRzaWRlICB0 aGUgc3BlY2lmaWVkIHNjb3BlLiANCg0KU2VydmljZSBEaXNjb3ZlcnkgY2FycnkgaW5mb3JtYXRp b24gYWJvdXQgdGhlIHR5cGUgb2YgZGV2aWNlcyBhdmFpbGFibGUgaW4geW91ciBuZXR3b3JrLCB0 aGUgc29mdHdhcmUgdmVyc2lvbiwgdGhlaXIgbG9jYXRpb24gYm90aCBwaHlzaWNhbCBsaWtlIGZs b29yIGFzIHdlbGwgYXMgbmV0d29ya2luZyAtIGxpa2UgdGhlIElQIGFkZHJlc3MuIEFsbCB0aGVz ZSBwaWVjZXMgb2YgaW5mb3JtYXRpb24gbWF5IGJlIHVzZWZ1bCBmb3IgYW4gaW50cnVkZXIuIERl dmljZSBhbmQgc29mdHdhcmUgaW5mb3JtYXRpb24gYXJlIHVzZWZ1bCB0byBpZGVudGlmeSB2dWxu ZXJhYmlsaXRpZXMsIGFuZCBsb2NhdGlvbiBpbmZvcm1hdGlvbiBhcmUgdXNlZnVsIHRvIGxvY2F0 ZSB0aGUgdGFyZ2V0LCBuYW1lcyBtYXkgYWxzbyBpbmNsdWRlIGluZm9ybWF0aW9uIHRoYXQgbWF5 IGJlIHVzZWZ1bCB0byBkZWZpbmUgYSBzcGVjaWZpYyB0YXJnZXQgLSBsaWtlICJQZXJzb25hbCBD RU8gUHJpbnRlciIuIEZvciB0aGVzZSByZWFzb25zLCBvbmUgaXMgd2lsbGluZyB0byBsaW1pdCB0 aGUgc2NvcGUgdGhlc2UgcGllY2VzIG9mIGluZm9ybWF0aW9uLg0KDQogICAgYSkgSW5mb3JtYXRp b25zIHNwcmVhZGluZyBtYXkgYmUgbGltaXRlZCBiYXNlZCBvbiBuZXR3b3JrIGluZm9ybWF0aW9u LiBXaGVuIEROUyBpcyB1c2VkLCB0aGUgRE5TIHpvbmUgU0hPVUxEIE5PVCBiZSBhY2Nlc3NlZCBi eSBhbnlvbmUgZnJvbSBvdXRzaWRlIHRoZSBzcGVjaWZpYyBuZXR3b3JrLiBUaGlzIGNhbiBiZSBw ZXJmb3JtZWQgYXQgdGhlIEROUyBzZXJ2ZXIgbGV2ZWwgb3IgYXQgdGhlIG5ldHdvcmsgYm91bmRh cmllcyBieSBzZXR0aW5nIGZpcmV3YWxsIHBvbGljaWVzIHNwZWNpZnlpbmcgd2hpY2gga2luZCBv ZiBJUCBhZGRyZXNzIGNhbiBhY2Nlc3MgdGhlIEROUyBzZXJ2ZXIuIFdoZW4gbUROUyBpcyB1c2Vk LCBtdWx0aWNhc3RlZCBpbmZvcm1hdGlvbiBTSE9VTEQgTk9UIGJlIGZvcndhcmRlZCBvdXRzaWRl IHRoZSBleHBlY3RlZCBuZXR3b3JrLiBUaGlzIGNhbiBiZSBwZXJmb3JtZWQgYnkgZmlyZXdhbGxz IHRoYXQgZHJvcHMgb3V0Ym91bmQvaW5ib3VuZCBtRE5TIHBhY2tldHMgYXQgdGhlIG5ldHdvcmsg Ym91bmRhcmllcy4gTm90ZSB0aGF0IGluIGJvdGggY2FzZXMsIHRoZXNlIHBvbGljaWVzIGFyZSBv dXRzaWRlIHRoZSBzY29wZSBvZiBtRE5TIG9yIEROUy4gT24gdGhlIG90aGVyIGhhbmQsIGZvciBt b2JpbGUgZGV2aWNlcywgZm9yIGV4YW1wbGUsIHdoaWNoIGluZm9ybWF0aW9uIG1heSBiZSBwcm92 aWRlZCBkZXBlbmRzIG9uIHRoZSBuZXR3b3JrLiBUaGVzZSBwb2xpY2llcyBoYXZlIHRvIGJlIGlt cGxlbWVudGVkIGJ5IHRoZSBtb2JpbGUgZGV2aWNlLg0KDQogICAgYikgU1NEIFNIT1VMRCBhbHNv IGNvbnNpZGVyIHNjb3BlcyB0aGF0IGFyZSBub3QgY29ycmVsYXRlZCB0byBuZXR3b3JrIGRlZmlu aXRpb25zIGxpa2UgJ2J1aWxkaW5nJyBvciAncm9vbScuIEFzIGRlZmluZWQgaW4gdGhlIGNoYXJ0 ZXI6IA0KIkl0IGlzIGFsc28gZGVzaXJhYmxlIHRoYXQgbXVsdGlwbGUgZGlzY292ZXJ5IHNjb3Bl cyBhcmUgc3VwcG9ydGVkLA0KZnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBlaXRoZXIgcGVyZm9y bWluZyBkaXNjb3Zlcnkgd2l0aGluIGEgDQpzcGVjaWZpZWQgc2NvcGUgb3IgYWR2ZXJ0aXNlbWVu dCB3aXRoaW4gYSBzcGVjaWZpZWQgc2NvcGUsIGFuZCANCmJlaW5nIGFibGUgdG8gZGlzY292ZXIg KGVudW1lcmF0ZSkgdGhlIHNldCBvZiBzY29wZXMgc3VjaCB0aGF0IA0KYW4gYXBwbGljYXRpb24g Y291bGQgdGhlbiBjaG9vc2UgdG8gZG8gZWl0aGVyLiBJdCBzaG91bGQgYmUgbm90ZWQNCnRoYXQg c2NvcGUgaW4gdGhpcyBzZW5zZSBtaWdodCByZWZlciB0byAnYnVpbGRpbmcnIG9yICdyb29tJyBh bmQgdGh1cyANCm1pZ2h0IGhhdmUgbm8gY29ycmVsYXRpb24gdG8gbmV0d29yayB0b3BvbG9neS4i DQoNClRoaXMgcmVxdWlyZXMgMSkgZGVmaW5pdGlvbiBvZiB0aGUgZGlmZmVyZW50IGF2YWlsYWJs ZSBzY29wZXMuIFNvbWUgZGVmYXVsdCB2YWx1ZSBNQVkgYmUgcHJvdmlkZWQgYnkgdGhlIGRldmlj ZSB3aXRob3V0IGtub3dsZWRnZSBvZiB0aGUgc3BlY2lmaWMgYXZhaWxhYmxlIHNjb3BlcyBvZiB0 aGUgbmV0d29yay4gU3VjaCBkZWZhdWx0IHZhbHVlcyBNQVkgYmUgdXNlZCBieSBkZXZpY2VzIGlm IHRoZXkgZG8gbm90IGRpc2NvdmVyIHRoZSBkaWZmZXJlbnQgc2NvcGVzIHNwZWNpZmljIHRvIHRo ZSBuZXR3b3JrIG9yIGlmIHRoZSBkZXZpY2UgZG9lcyBub3QgaGF2ZSBzdWZmaWNpZW50IGluZm9y bWF0aW9uIHRvIHRydXN0IHRoZSBhbm5vdW5jZWQgc2NvcGVzLiBJbiB0aGF0IGNhc2UgdGhlIGRl dmljZSBNQVkgc3RhcnQgd2l0aCBhIGRlZmF1bHQgbGltaXRlZCBzY29wZS4gMikgU3BlY2lmaWMg bmV0d29yayB2YWx1ZXMgU0hPVUxEIGJlIGFubm91bmNlZCBpbiBhbiBhdXRoZW50aWNhdGVkIHdh eSB0byBhdm9pZCB0aGF0LCBmb3IgZXhhbXBsZSwgIG5vbiBleGlzdGluZyBzY29wZSB1c2VkIHJl c3VsdHMgaW4gc2VydmljZSB1bmF2YWlsYWJsZS4gVGhlIHBvbGljeSBmb3Igbm9uIGV4aXN0aW5n IHNjb3BlcyBTSE9VTEQgYmUgZGVmaW5lZCB3aXRoIGEgcmVkdWNlZCBzY29wZSwgYW5kIHRoZSBk ZXZpY2UgU0hPVUxEIGJlIGluZm9ybWVkIHRoYXQgdGhlIHNjb3BlIGRvZXMgbm90IGV4aXN0IHNv IGl0IG1heSB1cGRhdGUgaXRzIHNjb3BlLiAzKSBPbmNlIGRldmljZXMgaGF2ZSBiZWVuIGluZm9y bWVkIG9mIHRoZSB2YXJpb3VzIHNjb3BlLCBpdCBNQVkgY2hvc2UgdGhlIG9uZSB0aGF0IHNlZW1z IHRoZSBtb3N0IGFwcHJvcHJpYXRlZCBhbmQgcHJvdmlkZSB0aGlzIGluZm9ybWF0aW9uLiBEZXBl bmRpbmcgb24gdGhlIHNjb3BlLCByb3V0ZXJzIG9yIG1pZGRsZSBib3hlcyBNQVkgY2hvc2UgdG8g Zm9yd2FyZCB0aGUgaW5mb3JtYXRpb24gb3Igbm90LiBUaGUgaW5mb3JtYXRpb24gTUFZIGJlIGZv cndhcmRlZCBvbiBtdWx0aXBsZSBsaW5rcy4gV2l0aCBzY29wZXMgdGhhdCBhcmUgbm90IG5ldHdv cmsgY29ycmVsYXRlZCwgdGhlIGluZm9ybWF0aW9uIE1BWSBiZSBmb3J3YXJkZWQgdG8gYSBzdWJz ZXQgb2YgZGV2aWNlcyB3aXRoaW4gYSBsaW5rLiBUaGUgdXNlIG9mIGRpc3RpbmN0IG11bHRpY2Fz dCBJUCBhZGRyZXNzIG1heSBiZSB1c2VkIHRvIGRpc3Rpbmd1aXNoIHRoZSBkaWZmZXJlbnQgc2Nv cGVzLiBIb3dldmVyLCB0aGUgdXNlIG9mIGRpZmZlcmVudCBJUCBhZGRyZXNzZXMgZG9lcyBub3Qg cHJldmVudCBkZXZpY2VzIHRvIGxpc3RlbiB0byB0aGUgaW5mb3JtYXRpb24uIElmIHRoZSBkZXZp Y2UgbmVlZHMgdGhlIGluZm9ybWF0aW9uIHRvIGJlIHJlYWQgb25seSBieSB0aGUgbWVtYmVycyBv ZiB0aGUgc2NvcGUsIGNyeXB0b2dyYXBoeSBNQVkgYmUgdXNlZCB0byBlbmNyeXB0IHRoZSBkYXRh LiBJUHNlYyBtdWx0aWNhc3QgZXh0ZW5zaW9uIFtSRkM1Mzc0XSBtYXkgYmUgYSBnb29kIGNhbmRp ZGF0ZS4gVGhpcyBtZWNoYW5pc20gbWF5IGFsc28gYmUgdXNlZCB0byBwcmV2ZW50IGFuIHVuYXV0 aG9yaXNlZCBkZXZpY2UgdG8gcHJvdmlkZSBhIHNlcnZpY2UgZm9yIGEgZ2l2ZW4gc2NvcGUuIElu IG90aGVyIHdvcmRzLCBteSBwcmludGVyIHNob3VsZCBub3QgYmUgYWJsZSB0byBhbm5vdW5jZSBp dHMgc2VydmljZSBmb3IgdGhlICJDRU8iIHNjb3BlIGFuZCBJIHNob3VsZCBub3QgYmUgYWJsZSB0 byBzZWUgdGhlIGFubm91bmNlbWVudCBvZiB0aGUgcHJpbnRlciBvZiBteSBDRU8uIA0KDQoyKSBF eHBvc2luZyBTZXJ2aWNlcw0KDQpBIFNlcnZpY2UgYW5ub3VuY2VkIG92ZXIgYSBuZXR3b3JrIGRv ZXMgbm90IG1lYW4gdGhlIHNlcnZpY2UgaXMgYXZhaWxhYmxlIHRvIGFueW9uZS4gU3VjaCBzZXJ2 aWNlcyBTSE9VTEQgZW5mb3JjZSBhY2Nlc3MgY29udHJvbCBwb2xpY2llcyBmb3IgdGhlIHNlcnZp Y2UuDQoNCklmIGEgY29ubmVjdGVkIHByaW50ZXIgaXMgbm90IHVzaW5nIFNELCBpdCBNQVkgYXBw ZWFyIGFzIGEgc2ltcGxlIElQIGNvbm5lY3RlZCBkZXZpY2UgYXR0YWNoZWQgdG8gdGhlIG5ldHdv cmsuIE9ubHkgc3BlY2lmaWMgdGVzdHMvc2NhbnMvdHJhZmZpYyBtb25pdG9yIGNhbiBkZXRlcm1p bmUgdGhlIGRldmljZSBpcyBhIHByaW50ZXIuIFdoZW4gU0Qgb3IgU1NEIGlzIHVzZWQsIGFzIHNv b24gYXMgdGhlIGRldmljZSBpcyBwbHVnZ2VkIG9uIHRoZSBuZXR3b3JrIGV2ZXJ5b25lIGtub3dz ICJQaG90byBDb2xvciBQcmludGVyLCBCdWlsZGluZyBBIGZsb29yIDIiIGhhcyBiZWVuIHBsdWdn ZWQuIElmIHRoaXMgcHJpbnRlciBpcyByZXNlcnZlZCBmb3IgdGhlIEdyYXBoaWMgYW4gRGVzaWdu IGRlcGFydG1lbnQsIHRoYW4gdGhlIHByaW50ZXIgU0hPVUxEIGltcGxlbWVudCBhY2Nlc3MgY29u dHJvbCBtZWNoYW5pc21zLiBBbHRob3VnaCB0aGVzZSBwb2xpY2llcyBhcmUgb3V0IG9mIHNjb3Bl IG9mIFNTRCwgdGhleSBNQVkgYmUgcmVxdWlyZWQgYXMgYSBjb25zZXF1ZW5jZSBvZiBTU0QuDQog IA0KMikgUmVzb3VyY2UgZXhoYXVzdGlvbg0KDQpXaXRoIG5ldyBlbWVyZ2luZyB0eXBlcyBvZiBu ZXR3b3JrcyBsaWtlIHNlbnNvciBuZXR3b3JrcyBhbmQgbW9yZSBnZW5lcmFsbHkgdGhlIElvVCwg U1NEIGNhbm5vdCBhbnltb3JlIHJlbHkgb24gbUROUyBhbmQgbXVsdGljYXN0IHRvIGFkdmVydGlz ZSBpdHMgc2VydmljZXMgYW5kIFNIT1VMRCBwcm92aWRlIGEgZGVkaWNhdGVkIGVudGl0eSB0aGF0 IGNhbiBwZXJmb3JtIFNTRCB2aWEgdW5pY2FzdCBtZXNzYWdlcy4gVHlwaWNhbGx5LCB0aGlzIGNh biBiZSBkZXBsb3llZCB3aXRoIGEgbUROUy10by1ETlMgYWdlbnQgdGhhdCByZWNlaXZlcyBhbm5v dW5jZW1lbnQgZnJvbSBtRE5TIGRldmljZXMgYW5kIHN0b3JlcyB0aGlzIGluZm9ybWF0aW9uIHRv IHRoZSBETlMgem9uZS4gU2luY2UgdGhlIGluZm9ybWF0aW9uIGlzIHN0b3JlZCwgb3RoZXIgZGV2 aWNlcyBpbiB0aGUgbmV0d29yayBkbyBub3QgaGF2ZSB0byByZWNlaXZlIGFuZCB0cmVhdCBtRE5T IGFubm91bmNlbWVudHMuDQoNClNTRCBNVVNUIGJlIGFibGUgdG8gc2NhbGUgdG8gdGhvdXNhbmRz IG9mIGRldmljZXMuIFRoZSB1c2Ugb2YgbXVsdGljYXN0IGZvciBzZXJ2aWNlIGFubm91bmNlbWVu dCByZXF1aXJlcyB0aGF0IGVhY2ggZGV2aWNlIGluZm9ybXMgYWxsIG90aGVyIGRldmljZXMgc29t ZSBpbmZvcm1hdGlvbiBsaWtlIHRoZSBob3N0ZWQgc2VydmljZSBmb3IgZXhhbXBsZS4gSW4gb3Jk ZXIgdG8gbWFrZSBzdXJlIGRldmljZXMgYWx3YXlzIGhhdmUgdGhlIGluZm9ybWF0aW9uIHVwLXRv LWRhdGUgb3IgdGhhdCBhbnkgbmV3IGRldmljZSBoYXMgdGhlIGluZm9ybWF0aW9uLCB0aGUgZGV2 aWNlIHJlZ3VsYXJseSByZXRyYW5zbWl0cyB0aGUgaW5mb3JtYXRpb24gdG8gYWxsIG90aGVyIGRl dmljZXMuIFRoaXMgaXMgbm90IGEgc2NhbGFibGUgYXJjaGl0ZWN0dXJlIGFzIGl0IGRvZXMgbm90 IHNjYWxlIGluIHRlcm0gb2YgYmFuZHdpZHRoIG5vciBpdCBjb25zaWRlciBlbmVyZ3kgY29uc3Vt cHRpb24gY29uc3RyYWlucyBvZiBzbWFsbCBkZXZpY2VzLg0KDQpBbnkgbWVzc2FnZXMgYXJlIGJ5 dGVzIHJlY2VpdmVkIGJ5IHRoZSBkZXZpY2VzIGNvbm5lY3RlZCBvbiB0aGUgbmV0d29yaywgd2hp Y2ggbWF5IHJlcXVpcmUgYWRkaXRpb25hbCBwcm9jZXNzaW5nIHN1Y2ggYXMgY3J5cHRvZ3JhcGhp YyBjaGVjayBpZiB1c2VkIGluIGNvbmp1bmN0aW9uIHdpdGggRE5TU0VDIGZvciBleGFtcGxlLiBU aGVzZSBkZXZpY2VzIG1heSByZWx5IG9uIGJhdHRlcnksIGFuZCBlYWNoIG9mIHRoZXNlIG1lc3Nh Z2VzIGRpcmVjdGx5IGltcGFjdCB0aGUgbGlmZXRpbWUgb2YgdGhlIGRldmljZS4gQXMgYSByZXN1 bHQgYWdncmVzc2l2ZSBtdWx0aWNhc3QgbWF5IHVubmVjZXNzYXJpbHkgYWZmZWN0IElvVCBkZXZp Y2VzLiBNb3JlIHJhdGlvbmFsIGFwcHJvYWNoIE1BWSBjb25zaXN0cyBpbiBtYWtpbmcgcG9zc2li bGUgU1NEIHVzaW5nIHVuaWNhc3QgY29tbXVuaWNhdGlvbnMgb25seSBvciB0byBwcmV2ZW50IHRo YXQgSW9UIGRldmljZSB3YWtlcyB1cCBhdCBldmVyeSBtdWx0aWNhc3QgbWVzc2FnZSBvciB1c2lu ZyBtdWx0aWNhc3QgdG8gYW5ub3VuY2UgaW5mb3JtYXRpb24gdXBkYXRlcyBhcyBvcHBvc2VkIHRv IGNhY2hlIHBvcHVsYXRpbmcuIE1vcmUgc3BlY2lmaWNhbGx5LCBhIG5ldyBkZXZpY2UgY2FuIHVz ZSBtdWx0aWNhc3QgdG8gYW5ub3VuY2UgYSBuZXdseSBwdWJsaXNoZWQgaW5mb3JtYXRpb24uIEV2 ZW50dWFsbHkgdGhpcyBpbmZvcm1hdGlvbiBtYXkgYmUgY2FjaGVkIGJ5IGFsd2F5cy1vbiBkZXZp Y2VzIGFuZCBzdG9yZWQgaW4gdGhlIEROUy4gQSBuZXcgZGV2aWNlIG1heSBnZXQgYWNjZXNzIHRv IHRoZXNlIHBpZWNlcyBvZiBpbmZvcm1hdGlvbiB3aXRoIGFuIHVuaWNhc3QgQVhGUiBmb3IgZXhh bXBsZS4gVGhlIG1haW4gYWR2YW50YWdlIGlzIHRoYXQgbXVsdGljYXN0IGludGVyZmFjZSBjYW4g YmUgc3dpdGNoZWQgb2ZmLg0KIA0KU28gaGVyZSB3ZSdyZSBpbiBzaW1pbGFyIHRlcnJpdG9yeSB0 byB0aGUgZGlzY3Vzc2lvbnMgYWJvdXQgUkFzLCBhbmQgbXVsdGljYXN0IG9uIGNlcnRhaW4gdHlw ZXMgb2YgbGlua3MsIHdoaWNoIGhhcyBsZWQgdG8gdGhlIGVmZmljaWVudC1ORCBwcm9wb3NhbCwg YW5kIHJlbGF0ZWQgd29yayBvbiBlbmVyZ3kgZWZmaWNpZW5jeSBmb3IgbG93IHBvd2VyIGRldmlj ZXMgZXRjLiBbaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaGFscGVy bi02bWFuLW5kLXByZS1yZXNvbHZlLWFkZHItMDAudHh0XQ0KDQozKSBUcnVzdGVkIFNjYWxhYmxl IFNlcnZpY2UgRGlzY292ZXJ5DQoNClRoaXMgc2VjdGlvbiBpcyBvbmx5IGZvY3VzZWQgb24gaG93 IGluZm9ybWF0aW9uIHByb3ZpZGVkIGJ5IHRoZSBTU0QgY2FuIGJlIHRydXN0ZWQuIEFzIGV2ZXJ5 IGRldmljZSBhbm5vdW5jZSB0aGVpciBzZXJ2aWNlLCBTU0QgU0hPVUxEIHByZXZlbnQgYW4gYXR0 YWNrZXIgdG8gYW5ub3VuY2UgaXQgaXMgdGhlICJDRU8gUHJpbnRlciIgaW4gb3JkZXIgdG8gY29s bGVjdCBhbGwgZG9jdW1lbnRzIHByaW50ZWQgYnkgdGhlIENFTy4gDQpJbiB0aGlzIHNlY3Rpb24s IHdlIGNvbnNpZGVyIHRoYXQgIkNFTyBQcmludGVyIiBkb2VzIG5vdCBleGlzdHMgYW5kIHRoYXQg dGhlIGF0dGFjayBkb2VzIG5vdCBhaW0gYXQgaGlqYWNraW5nIGEgc3BlY2lmaWMgbmFtZS4gVXNp bmcgdGhlIFNEIHRlcm1pbm9sb2d5ICJDRU8gUHJpbnRlciIgd291bGQgYmUgdGhlIEluc3RhbmNl IHBhcnQgb2YgdGhlIFNlcnZpY2UgSW5zdGFuY2UgTmFtZS4NCg0KYSkgVXNlciBwZXJzcGVjdGl2 ZQ0KV2hlbiBETlMgaXMgdXNlZCwgRE5TU0VDIGNhbiBiZSB1c2VkLCBhbmQgb25lIGNhbiB0cnVz dCB0aGUgaW5mb3JtYXRpb24gYXMgaXQgcHJvdmlkZXMgZnJvbSBhIHRydXN0ZWQgcGFydHkuIEFs dGhvdWdoIEROU1NFQyBoYXMgbm90IGJlZW4gZGVzaWduZWQgYXMgYSBwcm90b2NvbCB0aGF0IGNl cnRpZmllcyB0aGUgdmFsaWRpdHkgb2YgdGhlIEROUyBSREFUQSwgaW4gb3VyIGNhc2UsIEROU1NF QyBjb3VsZCBiZSB1c2VkIGFzIHN1Y2guIENvbnRyYXJ5IHRvIHJlZ2lzdHJhcnMgdGhhdCBhcmUg aG9zdGluZyBGUUROcyB0aGV5IGhhdmUgdmVyeSBmZXcga25vd2xlZGdlIG9uLCBuZXR3b3JrIGFk bWluaXN0cmF0b3JzIGFyZSBleHBlY3RlZCB0byBhZG1pbmlzdHJhdGVkIHRoZSBETlMgem9uZSBh Y2NvcmRpbmcgdG8gdGhlIHJlc291cmNlcyBhdmFpbGFibGUgZm9yIHRoZSBuZXR3b3JrLiBBcyBh IHJlc3VsdCBETlNTRUMgdmFsaWRhdGlvbiBjb3VsZCBiZSBpbnRlcnByZXRlZCBhcyAidmFsaWRh dGVkIGJ5IHRoZSBhZG1pbmlzdHJhdG9yIi4NCg0KbUROUyBkb2VzIG5vdCBoYXZlIHRydXN0IGFu Y2hvcnMgcHJvdmlkZWQgYnkgRE5TU0VDLiBIb3dldmVyLCBETlNTRUMgdXNlZCBpbiBjb25qdW5j dGlvbiBvZiBtRE5TIGNhbiBiZSB1c2VkIHRvIHByb3ZpZGUgYSBwcm9vZi1vZi1vd25lcnNoaXAg b2YgdGhlIGluZm9ybWF0aW9uLiBIb3cgcmVsaWFibGUgaXMgdGhhdCBpbmZvcm1hdGlvbiBjYW4g YmUgbGVhcm5lZCBvdmVyIHRpbWUgYnkgcHJvY2Vzc2luZyB0aGUgcmVwdXRhdGlvbiBvZiBhIGRl dmljZSAocmVwcmVzZW50ZWQgYnkgaXRzIHB1YmxpYyBrZXkpIG9yIGJ5IG1vbml0b3Jpbmcgd2hl dGhlciB0aGUgaW5mb3JtYXRpb24gcmVtYWlucyBjb2hlcmVudCBvdmVyIHRpbWUuIEZvciBleGFt cGxlLCBpZiBhIHByaW50ZXIgYW5ub3VuY2VzIGl0cyBJUCBhZGRyZXNzIGFzIHBhcnQgb2YgdGhl IGNvbXBhbnkgbmV0d29yaywgYW5kIHN1ZGRlbmx5IHN0YXJ0cyBhbm5vdW5jaW5nIGFuIElQIGFk ZHJlc3MgbG9jYXRlZCBzb21ld2hlcmUgZWxzZSwgZnVydGhlciBjaGVja3MgbWF5IGJlIHBlcmZv cm1lZCBiZWZvcmUgdHJ1c3RpbmcgdGhlIGluZm9ybWF0aW9uLiBFdmVuIHRob3VnaCB0aGUgbURO UyBtZXNzYWdlIHNpZ25lZCB3aXRoIEROUyBjYW5ub3QgYmUgdHJ1c3RlZCB0aGUgc2FtZSB3YXkg YXMgaXQgd291bGQgaGF2ZSBiZWVuIHRydXN0ZWQgaW4gYSBETlNTRUMgem9uZSwgdXNpbmcgRE5T U0VDIGluIGNvbmp1bmN0aW9uIG9mIG1ETlMgbWFrZXMgcG9zc2libGUgdG8gYXNzaWduIHNvbWUg cGllY2VzIG9mIGluZm9ybWF0aW9uIHRvIGEgc3BlY2lmaWMga2V5LiBUaGlzIGhlbHBzIGluIGVz dGFibGlzaGluZyBhIHJlcHV0YXRpb24gYXMgd2VsbCBhcyBhdm9pZHMgc3Bvb2ZlZCBtZXNzYWdl cy4NCg0KT24gYSB1c2VyIHBlcnNwZWN0aXZlLCBtRE5TIHJlcXVpcmVzIHRoZSBlbmQgdXNlciB0 byBlc3RhYmxpc2ggYSByZXB1dGF0aW9uIG1lY2hhbmlzbSB3aGVyZWFzIEROUyBwcm92aWRlcyBj ZXJ0aWZpZWQgaW5mb3JtYXRpb24uIFRoZSBtYWluIGFkdmFudGFnZSBvZiBETlMgaXMgdGhhdCBh IG5ldyBlbmQgdXNlciBoYXMgY2VydGlmaWVkIGluZm9ybWF0aW9uIHdoaWNoIGlzIG5vdCBwb3Nz aWJsZSB3aXRoIG1ETlMuDQoNCltUQkQgY2hlY2svY29tcGFyZSBoeWJyaWQgbW9kZWxdDQoNCmIp IERldmljZXMgcGVyc3BlY3RpdmUNCg0KV2hlbiBETlMgaXMgdXNlZCwgdGhlIGRldmljZSBNVVNU IGJlIGFibGUgdG8gcHJvdmlkZSB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIEROUyBzZXJ2ZXIgdmlh IEROUyB1cGRhdGUgW1JGQzIxMzZdIG9yIHNlY3VyZSBETlMgdXBkYXRlIFtSRkMzMDA3XS4gVGhp cyBzY2VuYXJpbyBtYXkgbm90IG1lZXQgYSBaZXJvIGNvbmZpZ3VyYXRpb24gcmVxdWlyZW1lbnQg YXMgdGhlIEROUyBzZXJ2ZXIgbmVlZHMgdG8ga25vdyB0aGUgcHVibGljIGtleSBvZiB0aGUgZGV2 aWNlcywgYW5kIHRoZSBkZXZpY2UgbmVlZHMgdG8ga25vdyBhdCBsZWFzdCB0aGUgSVAgYWRkcmVz cyBvZiB0aGUgRE5TIHNlcnZlci4gSWYgREhDUHY2IHRoZSBJUCBhZGRyZXNzIG9mIHRoZSBNQVkg YmUgZGVyaXZlZCBmcm9tIHRoZSBEb21haW4gU2VhcmNoIExpc3QgYW5kIHRoZSBETlMgUmVjdXJz aXZlIE5hbWUgU2VydmVyIG9wdGlvbiBbUkZDMzY0Nl0uIFRoZSBkZXZpY2UgTUFZIHNlbmQgYSBE TlMgcXVlcnkgZm9yIG9uZSBkb21haW4gc2VhcmNoIHdpdGggdHlwZSBOUyB0byB0aGUgcmVjdXJz aXZlIG5hbWUgc2VydmVyLiBIb3dldmVyLCByZWdpc3RlcmluZyB0aGUgcHVibGljIGtleXMgb2Yg dGhlIGRldmljZXMgaW4gdGhlIEROUyBkb2VzIG5vdCBzY2FsZSB0aG91c2FuZHMgb2YgZGV2aWNl cy4gTW9zdCBsaWtlbHksIHRoZWlyIHB1YmxpYyBrZXlzIG1heSBiZSBjb25zaWRlcmVkIGFzIHRy dXN0ZWQgYmFzZWQgb24gcmVwdXRhdGlvbiwgbGVhcCBvZiBmYWl0aCBwcmluY2lwbGVzIHdoaWNo IGRvZXMgbm90IG5lY2Vzc2FyaWx5IHByZXZlbnQgYW4gYXR0YWNrZXIgdG8gc2V0IGZhbHNlIGRh dGEgaW50byB0aGUgRE5TIHpvbmUuIA0KICAgDQpXaGVuIG1ETlMgaXMgdXNlZCwgdGhlIGRldmlj ZSBkb2VzIG5vdCBuZWVkIGFueSBjb25maWd1cmF0aW9uLiBUaGlzIGluZm9ybWF0aW9uIGlzIGFu bm91bmNlZCB0byB0aGUgbmV0d29yay4gVGhlIGluZm9ybWF0aW9uIHdpbGwgYmUgdHJ1c3RlZCBi eSB0aGUgZGV2aWNlcyB0aGF0IHRydXN0IHRoZSBhbm5vdW5jZXIuIEFzIGZvciB0aGUgRE5TLCBw cm92aXNpb25pbmcgYWxsIGRldmljZXMgb2YgdGhlIG5ldHdvcmsgd2l0aCBhbGwgcHVibGljIGtl eXMgaXMgbm90IHNjYWxhYmxlLiBBcyBtZW50aW9uZWQgYWJvdmUsIHB1YmxpYyBrZXlzIHdpbGwg YmUgdHJ1c3RlZCBtb3N0IGxpa2VseSBiYXNlZCBvbiByZXB1dGF0aW9uIG9yIGxlYXAgb2YgZmFp dGggcHJpbmNpcGxlcy4NCg0KVGhlIG1haW4gZGlmZmVyZW5jZSBiZXR3ZWVuIEROUyBhbmQgbURO UyBzZWVtcyB0aGF0IEROUyByZXF1aXJlcyBsZXNzIHByb3Zpc2lvbmluZyBvciBjb25maWd1cmF0 aW9uIHRoYW4gbUROUyAobiB2ZXJzdXMgbiAqIChuIC0gMSkgZm9yIGEgbiBkZXZpY2UgbmV0d29y aykuIFRoZW4gaW4gYSB6ZXJvIGNvbmZpZ3VyYXRpb24gc2NlbmFyaW8sIEROUyBjZW50cmFsaXNl cyBpbiBhIHNpbmdsZSBwb2ludCB0aGUgd2F5IGEga2V5IGNhbiBiZSB0cnVzdGVkLiBUaGUgb25s eSBkaXNhZHZhbnRhZ2Ugb2YgdXNpbmcgRE5TIGlzIHRoZSBkZXZpY2VzIHNob3VsZCBkaXNjb3Zl ciB0aGUgRE5TIHNlcnZlci4NCg0KSXQgc2VlbXMgdGhhdCBhcHByb2FjaCBjb21iaW5pbmcgbURO UyBhbmQgRE5TIGNhbiB0YWtlIGFkdmFudGFnZSBvZiBib3RoLiBEZXZpY2VzIGFubm91bmNlIGlu Zm9ybWF0aW9uIHVzaW5nIG1ETlMgYW5kIHRoZSBETlMgYWNjb3JkaW5nIHRvIHRoZSBsZXZlbCBv ZiB0cnVzdCBzdG9yZXMgdGhlIGluZm9ybWF0aW9uIGluIGl0cyB6b25lLg0KDQoNCjQpIEluZm9y bWF0aW9uIGltcGVyc29uYXRpb24NCg0KVGhlIHByZXZpb3VzIHNlY3Rpb24gcHJvdmlkZWQgY29u c2lkZXJhdGlvbnMgb24gaG93IGEgZGV2aWNlIGNhbiBiZSBhc3NvY2lhdGVkIHRvIGEgcHVibGlj IGtleSBhbmQgZXZlbnR1YWxseSBpZGVudGlmaWVkIGFzIGEgdHJ1c3RlZCBkZXZpY2UuIFdpdGgg emVybyBjb25maWd1cmF0aW9uLCB0aGUgbGV2ZWwgb2YgdHJ1c3QgYXNzb2NpYXRlZCB0byBhIGRl dmljZSByZXN1bHRzIG9mIGEgdHJhZGUgb2ZmIGJldHdlZW4gY29uZmlndXJhdGlvbiBhbmQgYSBs ZWFybmluZyBwcm9jZXNzLiBUaGlzIHNlY3Rpb24gaW5kaWNhdGVzIGhvdyBpbmZvcm1hdGlvbiBw cm92aWRlZCBieSB0aGUgZGV2aWNlcyBjYW4gYmUgbW9uaXRvcmVkIHRvIGRldGVybWluZSB0aGUg cmVwdXRhdGlvbiBvZiBhIGRldmljZSwgdG8gcmFpc2UgYW4gYWxhcm0gdG8gdGhlIGFkbWluaXN0 cmF0b3IsIGFuZCBldmVudHVhbGx5IHNob3cgYSBkZXZpY2UgY2Fubm90IGJlIHRydXN0ZWQgb3Ig aW5kaWNhdGUgYSBkZXZpY2UgaGFzIGJlZW4gIGNvcnJ1cHRlZC4NCg0KVGhlIGtpbmQgb2YgaW5m b3JtYXRpb25zIHByb3ZpZGVkIGJ5IFNEIG9yIFNTRCB0aGF0IGFyZSB2aXNpYmxlIHRvIHRoZSBl bmQgdXNlciBhcmUgMSkgYSBuYW1lIHRoYXQgZGVzY3JpYmVzIGEgc2VydmljZSBhbmQgMikgdGhl IGxvY2F0aW9uIG9mIHRoZSBzZXJ2aWNlLiBUaGUgbmFtZSBvZiB0aGUgc2VydmljZSBjb3JyZXNw b25kcyB0byBTZXJ2aWNlIEluc3RhbmNlIE5hbWUuIFdpdGggU0QgdGhlIG5hbWUgaXMgbWVudGlv bmVkIGluIHRoZSBSREFUQSBwYXJ0IG9mIHRoZSBQVFIgYW5kIGFzIHRoZSBrZXkgb2YgdGhlIFNS ViBSUlNldC4gVGhlIGxvY2F0aW9uIG9mIHRoZSBzZXJ2aWNlIGlzIHRoZSBSREFUQSBwYXJ0IG9m IHRoZSBTUlYgYXMgd2VsbCBhcyBpdHMgY29ycmVzcG9uZGluZyBsb2NhdG9yLiANCg0KVGhlIFNl cnZpY2UgSW5zdGFuY2UgTmFtZSBpcyBjb21wb3NlZCBvZiB0aHJlZSBwYXJ0czogSW5zdGFuY2Us IFNlcnZpY2UgTmFtZSBhbmQgRG9tYWluLiBTRCByZWNvbW1lbmRzIHRoYXQgSW5zdGFuY2UgYW5k IERvbWFpbiBhcmUgZW5jb2RlZCB1c2luZyBVVEY4LiBVVEY4IGVuYWJsZXMgc3BlY2lmaWMgY2hh cmFjdGVycyB0aGF0IGFyZSBub3QgeWV0IGJlaW5nIGNvbnNpZGVyZWQgaW4gdGhlIGN1cnJlbnQg RE5TLiBUcmFkaXRpb25hbCBETlMgdXNlcyBhc2NpaSBvciBQdW55Y29kZS4gSWYgVVRGOCBpcyBt b3JlIGZsZXhpYmxlIGluIHRlcm0gb2Ygc3RyaW5nIHJlcHJlc2VudGF0aW9uLCBpdCBtYXkgcHJv dmlkZSBtdWx0aXBsZSB3YXlzIHRvIGV4cHJlc3MgdGhlIHNhbWUgdGhpbmcgd2hpY2ggbWF5IGNv bmZ1c2UgdGhlIGVuZCB1c2VyLiBJbiBmYWN0IHVzaW5nIFVURjggIk15IFByaW50ZXIiLCAibXkg cHJpbnRlciIgIk15IHByaW50ZXIiIGFyZSBkaWZmZXJlbnQgc3RyaW5ncy4gVGhpcyBtYXkgYmUg dXNlZCBieSBhbiBhdHRhY2tlciB0aGF0IHdpbGwgcHJvdmlkZSBhIHNlcnZpY2UgZGlmZmVyZW50 IGluIHRlcm0gb2YgVVRGOCBmb3JtYXQsIGJ1dCB0aGF0IHRoZSBlbmQgdXNlciB3aWxsIGFzc2lt aWxhdGUgdG8gdGhlIHNhbWUgc2VydmljZS4gSW4gYWRkaXRpb24sICJteSBwcmludGVyIiB3aWxs IGJlIGRpc3BsYXllZCBkaWZmZXJlbnRseSBpZiBlbmNvZGVkIGluIFVURjggb3IgaW4gYXNjaWku IEFzIGEgcmVzdWx0IHR3byBzZXJ2aWNlICJteSBwcmludGVyIiBjb3VsZCBiZSBzdG9yZWQgaW4g YSBETlMgem9uZSB3aXRob3V0IGFueSBjb2xsaXNpb25zLg0KT25lIHdheSB0byBhdm9pZCBtdWx0 aXBsZSBmb3JtYXQgd291bGQgYmUgdG8gY29uc2lkZXIgdGhlIG5lY2Vzc2FyeSBvciBtaXNzaW5n IGNoYXJhY3RlcnMgcHJvdmlkZWQgYnkgVVRGOCBhbmQgYWRkIHRoZW0gaW4gdGhlIFB1bnkgY29k ZS4NCklmIHRoZXJlIG1heSBiZSBzb21lIGFkdmFudGFnZXMgaW4gdXNpbmcgVVRGOCBmb3IgdGhl IHNlcnZpY2UgbmFtZSwgdGhlIGRvbWFpbiBuYW1lIHBhcnQgU0hPVUxEIHVzZSBvbmx5IHRoZSBQ dW55Y29kZS4gDQpBcyBhIHJlc3VsdCwgY2hlY2tpbmcgaW5mb3JtYXRpb24gZm9yIFNTRCByZXF1 aXJlcyB0byBlc3RhYmxpc2ggbWV0cmljcy9zaW1pbGFyaXRpZXMgYmV0d2VlbiBzdHJpbmdzLg0K DQpXb3J0aCBub3RpbmcgaW4gdGhlIEROUyB0aGUgZGV2aWNlIG1pZ2h0IGJlIGhwcHJpbnQwMS5i bGRnMzIuc29tZXNpdGUuY29tLCB3aGlsZSBpdHMgaW50ZXJuYWxseSBzdG9yZWQgbGFiZWwgbWF5 IGJlICJCdWlsZGluZyAzMiBmb3llciBwcmludGVyIi4NCg0KDQpUaGUgbG9jYXRpb24gb2YgdGhl IHNlcnZpY2UgaXMgaWRlbnRpZmllZCBieSBhIEZRRE4gYW5kIGEgY29ycmVzcG9uZGluZyBJUCBh ZGRyZXNzLiBJbiBTRCwgdGhlIEZRRE4gcmVzcGVjdCB0aGUgUHVubnljb2RlIGVuY29kaW5nLiBU aGUgRlFETiBvZiB0aGUgc2VydmljZSBtYXkgYmUgY2hlY2tlZCBhZ2FpbnN0IHRoZSBrbm93biBk b21haW4gbmFtZXMgYXNzb2NpYXRlZCB0byB0aGUgbmV0d29yay4gU2ltaWxhcmx5LCB0aGUgSVAg YWRkcmVzcyBpcyBnZW5lcmFsbHkgdXNlZCB0byBsb2NhdGUgdGhlIHNlcnZpY2UuIGlmIHRoZSBJ UCBhZGRyZXNzIGlzIG5vdCBpbnNpZGUgdGhlIG5ldHdvcmssIHRoaXMgbWF5IHJhaXNlIGEgd2Fy bmluZyB0byB0aGUgYWRtaW5pc3RyYXRvciwgdGhhdCBtYXkgdmFsaWRhdGUgdGhlIElQIGFkZHJl c3MuDQoNCg0KV2hlbiBETlNTRUMgaXMgdXNlZCBjbG9zZWQgbmFtZXMgYWRkcmVzc2VkIGJ5IGRp ZmZlcmVudCBrZXlzIGFyZSBzdXNwaWNpb3VzLiBXaXRob3V0IHRoZSB1c2Ugb2YgRE5TU0VDIGlz IGJlY29tZXMgaGFyZCB0byBkZXRlY3QgdGhlIGRldmljZS9TRCBkZXZpY2UgaGFzIG5vdCBjaGFu Z2VkIHRoZWlyIElQIGFkZHJlc3MuDQoNCg0KNSkgVW5pcXVlIG5ldHdvcmsgaWRlbnRpZmllcg0K ICANClNEIHVzZXMgIi5sb2NhbCIgcHJlZml4IHRvIGluZGljYXRlIHRoZSBzY29wZSBvZiB0aGUg RlFETi4gICIubG9jYWwiIGlzIGEgc3BlY2lhbCB1c2UgZG9tYWluIG5hbWUgLSBSRkMgNjc2MSwg YW5kIGluIHRoZSByZWdpc3RyeSBhdA0KaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9z cGVjaWFsLXVzZS1kb21haW4tbmFtZXMvc3BlY2lhbC11c2UtZG9tYWluLW5hbWVzLnhodG1sDQoN CiIubG9jYWwiIGlzIGluc3RhbnRpYXRlZCBpbiBhbnkgbmV0d29ya3MuIFRoaXMgcmVzdWx0cyBp biBhIGdpdmVuIHN0cmluZyB3aXRoIG11bHRpcGxlIG1lYW5pbmdzLiAiTXkgUHJpbnRlciIgYXQg aG9tZSBpcyBub3QgdGhlIHNhbWUgc2VydmljZSBhcyAiTXkgUHJpbnRlciIgYXQgd29yayBhbmQg aWYgdGhlIGluZm9ybWF0aW9uIGlzIGNhY2hlZCBpbiBzb21lIGRldmljZXMsIHRoaXMgbWF5IHJl c3VsdCBpbiBjcm9zcyBzaXRlIG5hbWUgaGlqYWNraW5nLiBBbiBhdHRhY2tlciBjb3VsZCBmb3Ig ZXhhbXBsZSBhZHZlcnRpc2UgIk15IFByaW50ZXIiIGluIGEgcHVibGljIG5ldHdvcmsgbGlrZSBp biBhbiBhaXJwb3J0IHdpdGggYSBnbG9iYWwgSVAgYWRkcmVzcy4gVGhlIFNlcnZpY2UgSW5zdGFu Y2UgTmFtZSB1c2VkIGNvdWxkIGJlIHNvbWV0aGluZyBhcyAiTXkgUHJpbnRlcl9pcHBfdGNwLmxv Y2FsIFNSViBnbG9iYWwtcHJpbnRlci5leGFtcGxlLmNvbSIuIFBlb3BsZSBpbiB0aGUgYWlycG9y dCBtYXkgdGhlbiBzZW5kIHRoZWlyIGRvY3VtZW50cyB0byAiTXkgUHJpbnRlciIgYWR2ZXJ0aXNl ZCBpbiB0aGUgYWlycG9ydCAtIHRoYXQgaXMgdG8gc2F5IGdsb2JhbC1wcmludGVyLmV4YW1wbGUu Y29tIC0sIGluc3RlYWQgb2YgdGhlIG9uZSBvZiB0aGVpciBvZmZpY2UuIA0KDQpJbiBvcmRlciB0 byBtaXRpZ2F0ZSB0aGlzIGNvbmZ1c2lvbiwgIi5sb2NhbCIgU0hPVUxEIGJlIHVzZWQgb25seSB3 aGVuIHRoZSBkZXZpY2UgZG9lcyBub3Qga25vdyB0aGUgZG9tYWluIG5hbWUgYXNzb2NpYXRlZCB0 byB0aGUgbmV0d29yay4gSWYgREhDUHY2IGlzIHVzZWQgdGhpcyBtYXkgYmUgZGVyaXZlZCBieSB0 aGUgREhDUHY2IENsaWVudCBGUUROIG9wdGlvbiBbUkZDNDcwNF0uDQoNCk5vdGUgYWxzbyB0aGF0 ICJNeSBwcmludGVyIiBtYXkgYmUgYSBkaWZmZXJlbnQgcHJpbnRlciB3aGVuIEkgYW0gYXQgaG9t ZSBvciBhdCB3b3JrLiBPbiB0aGUgb3RoZXIgaGFuZCwgd2hpbGUgYXQgaG9lIEkgU0hPVUxEIGJl IGFibGUgdG8gdXNlICJNeSBPZmZpY2UgUHJpbnRlciIgYW5kIHZpY2UgdmVyc2EuIFRoaXMgYW1i aWd1aXR5IG1heSBiZSBsZXZlcmFnZSBieSB0aGUgdXNlIG9mIHVuaXF1ZSBwcmVmaXguDQoNCjYp IENvbXByb21pc2VkIGRldmljZSAgICAgDQoNClRoaXMgc2VjdGlvbiBlc3RpbWF0ZXMgaG93IGEg Y29tcHJvbWlzZWQgZGV2aWNlIGltcGFjdHMgdGhlIFNTRCBzZXJ2aWNlLiBXZSBhc3N1bWUgRE5T U0VDIGlzIHVzZWQuDQoNCk9uY2UgZGV0ZWN0ZWQsIHRoZSBwdWJsaWMga2V5IGFzc29jaWF0ZWQg dG8gdGhlIGRldmljZSBpcyByZXZva2VkLiBXaXRoIEROUyB0aGUgcmV2b2NhdGlvbiBvY2N1cnMg b25jZSBpbiB0aGUgRE5TLCBhbmQgdGhlIGluZm9ybWF0aW9uIGlzIG9ubHkgc3RvcmVkIGluIHRo ZSByZW1haW5pbmcgY2FjaGVzIG9mIGRldmljZXMgdGhhdCBoYXZlIHJlcXVlc3RlZCB0aGUgaW5m b3JtYXRpb24gYmVmb3JlIGl0IGV4cGlyZXMuIEFmdGVyIFRUTCBzZWNvbmRzLCB0aGUgaW5mb3Jt YXRpb24gaXMgcmV2b2tlZCBmcm9tIGFsbCBkZXZpY2VzLiBJZiBtRE5TIGlzIHVzZWQsIHJldm9j YXRpb24gc2hvdWxkIG9jY3VyIGluIGV2ZXJ5IGRldmljZS4gVGhlIG1lY2hhbmlzbSB0byBkZXRl Y3QgYSBkZXZpY2UgaXMgY29tcHJvbWlzZWQgaXMgY29tcGxleCBhbmQgd2lsbCBwcm9iYWJseSBu b3QgYmUgaW1wbGVtZW50ZWQgcHJvcGVybHkgaW4gbW9zdCBkZXZpY2VzLg0KDQpXaXRoIHRoZSBj dXJyZW50IFNELCBhIGNvbXByb21pc2VkIGRldmljZSBNQVkgcHJvdmlkZSB3cm9uZyBpbmZvcm1h dGlvbiBhYm91dCBpdHNlbGYgYnV0IGRvZXMgbm90IGFmZmVjdCBvdGhlcnMgZGV2aWNlIGluZm9y bWF0aW9uLg0KDQoNCg0KDQoNCi0tIA0KRGFuaWVsIE1pZ2F1bHQNCk9yYW5nZSBMYWJzIC0tIFNl Y3VyaXR5DQorMzMgNiA3MCA3MiA2OSA1OCA= ------=_001_NextPart027738470163_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi, Daniel, s= o many=20 details on SSD requirements are presented here, which helps me have a more= deep=20 understanding on this issue. It is said that IPsec and DNSSEC can be used = to=20 authenticate the devices tending to provide service. While one question is= that=20 the deployment of IPsec and DNSSEC may lead to highly increased traffic wi= thin=20 the local network. And for those temporary service providers (which just p= rovide=20 services in a short time in a mesh wireless network, for instance), the pr= ocess=20 of temporary service provider registering on DNSSEC system may be too long= =20 compared with the relatively short serving period. Also, the DNSSEC system= has=20 to revoke the public key of the temporary service provider if it has gone=20 off-line. So it seems that we should clarify the service mentioned in this= WG.=20 Is the service mentioned in this WG means a long-term one or short-term on= e or=20 both?
 
Guangqing=20 Deng
CNNIC 
 
Date: 2014-01-19 16:02
To: dnssd
CC: Tim Chown;= Kerry Lynn
Subject: [dnssd] draft-ietf-dnssd-requirements-00.txt:=20 Requirements/Security Considerations
Hi Folks,

Here are some additional requirements for&nbs= p;=20 draft-ietf-dnssd-requirements-00.txt as well as a starting point for the=20 security consideration section. This section has been updated with Tim's=20 comments.

Your are more than welcome to comment/clarify/chang= e the=20 proposed text. We would appreciate you provide them by Friday January 23 s= o they=20 can be considered for the next version.

Best=20 Regards,

Daniel
 
Terminology section:

I think we should add the followin= g=20 terms. I am using used them in the remaining of the mail. They may be chan= ged=20 for the draft.

mDNS: multicast DNS as defined in [RFC6762]
SSD:=20 Scalable Service Discovery
SD DNS-Based Service Discovery=20 [RFC6763]

Requirements section:

I suggest adding or=20 complete existing requirements with the following ones:

SSD SHOULD = be=20 designed for both DNS and mDNS working in a cooperative way. More specific= ally,=20 it SHOULD consider interaction between DNS and mDNS.

SSD SHOULD be = able=20 to be performed by client only using DNS and unicast to avoid multiple mul= ticast=20 messages.

SSD SHOULD work with existing DNS-Based Service Discovery= over=20 mDNS and SHOULD NOT break any other discovery protocols.
As specified = in the=20 charter [http://datatracker.= ietf.org/wg/dnssd/charter/]
"The=20 WG will consider the tradeoffs between reusing/extending existing
proto= cols=20 and developing entirely new ones. It is highly desirable
that any new=20 solution is backwardly compatible with existing DNS-SD/mDNS
deployments= . Any=20 solution developed by the dnssd WG must not conflict
or interfere with = the=20 operation of other zero-configuration service and
naming protocols such= as=20 uPnP or LLMNR. Integration with such protocols
is out of scope for this= =20 WG."

and

"To document challenges and problems encountered in= the=20 coexistence
of zero configuration and global DNS name services in such= =20
multi-link networks, including consideration of both the name
reso= lution=20 mechanism and the namespace."


SSD SHOULD consider the use of gl= obally=20 unique FQDN that is specific of a given network instead of a default domai= n name=20 as ".local". SSD SHOULD provide means to discover/announce the FQDN associ= ated=20 to the network. A default and common FQDN - like ".local." could be used o= nly=20 when the specific FQDN of the network has not been determined. Furthermore= , in=20 order to ease interoperation with DNS the domain name SHOULD follow=20 DNS-compatible encoding (i.e ascii or punycode).


SSD SHOULD be = able=20 to take advantage of network configurations (DHCP/RA) protocol. If it is c= lear=20 that SSD and DNS SHOULD be able to work together, DHCP may also be used to= =20 announce necessary information for the network such as its associated FQDN= =20 (using DHCP Domain Search / DHCP Domain option / IPv6 RA [RFC6106]), the=20 interface to register FQDNs... This MAY for example complement or avoid th= e use=20 of the specific b/db/r/dr/lb.dns-sd._udp.<domain> or equivalent=20 queries. 


SSD SHOULD be able to announce the scope Servic= e=20 Discovery informations are expected to be accessed or multicasted. This re= quires=20 something like a "scope" discovery protocol.


Security=20 Consideration section

Here is some text I propose. Comments are= more=20 then welcome! I hope that we will be able to fix this section during the n= ext=20 meeting.


1. Scalable DNS Service is not an extension of SD in t= erm of=20 security

Scalable DNS-Based Service Discovery can hardly rely on th= e=20 security considerations defined for DNS-Based Service Discovery [RFC6763].= =20 Considering "Scalability" requires new security practices that are defines= in=20 this document.

DNS-Based Service Discovery [RFC6763] has been desig= ned so=20 that a device can announce a service to the other devices of the network.=20 Although DNS or mDNS can be used for SD, SD has been mostly thought to wor= k over=20 mDNS to avoid DNS zone management and to handle UTF8 names for the end use= rs=20 even in the domain part of the Instance Service Name. As a result SD' secu= rity=20 considerations rely on mDNS security considerations, DNSSEC [RFC4033] for=20 authentication and secure DNS update [RFC3007] to secure DNS update [RFC21= 36].=20 These considerations are not sufficient for SSD as explained=20 below.

    - a) DNSSEC is probably the DNS extension= that=20 MAY be used to provide authentication and integrity check protection. Howe= ver,=20 authentication other than proof-of-ownership or leap-of-faith security mod= el=20 requires trust anchors. Trust anchor MAY be provided by the global DNS, bu= t this=20 has not been specified in SD. Section 10 of RFC6763 illustrates how to pop= ulate=20 the DNS with information but clearly states that such interactions are out= of=20 scope of RFC6763. Interactions between SSD and DNS cannot be specified in = an=20 illustrative section.

    - b) Similarly, DNS update= s are=20 used by SD to cooperate with DNS. These interactions are left as illustrat= ive in=20 RFC6763, which is not sufficient for SSD.

    -c) mD= NS=20 security considerations are not sufficient for SSD. At first, mDNS require= s=20 cooperative devices. If cooperative devices is a reasonable assumption in = a one=20 hop network such as most home networks, this assumption cannot be made for= =20 larger networks, such as corporate networks for example.=20

       In case all devices cannot tr= ust=20 each other, SD considers the use of IPsec or DNSSEC. How these protocols a= re=20 used is not fully described in RFC6762 and SHOULD be at least documented f= or=20 SSD. More specifically, DNSSEC can be used with different security models.= =20 Authentication of the devices may require a chain of trust and interaction= with DNS. Alternatively authentication may rely on devices configured with=20 certificates. In the absence of such certificates or chain of trust, a=20 proof-of-ownership with device's reputation may be considered. =20

      mDNS considers the use of DNSSEC to= =20 differentiate responses from the global DNS and mDNS that addresses a loca= l=20 scope. DNSSEC may not be the appropriated solution for SSD as DNSSEC may n= ot be=20 deployed for the global DNS or for mDNS which would make distinction impos= sible.=20 As suggested by RFC6761, the use of ".local" to specify mDNS may be more=20 appropriated.

      mDNS also raises the = issue=20 of relative domain names (example.com) = that may=20 be solved as example.com.local. or as example.com.search-domain. This issu= e=20 becomes more complex with SSD. For SD there is little ambiguity with the m= eaning=20 of ".local". It is a single link, usually a single network. SSD considers=20 multiple links and as such multiple ".local" and multiple different search= =20 domain. Thus the question may be which link's search domain is to be consi= dered.=20
   
      mDNS considers v= ery=20 few interactions with DNS. The only mentioned case is when a global DNS=20 resolution is performed using mDNS. mDNS indicates how to treat relative=20 domains. Interaction between mDNS and DNS was not so necessary as with one= hop=20 network there is a clear separation between the local and non local (Inter= net)=20 network. With multiple networks, the frontier between local and non local=20 becomes much undefined. As result whether naming resolution is local (mDNS= ) or=20 global (DNS) is not obvious. This is why SSD needs to specify interactions= =20 between DNS and mDNS whereas DNS-Based Service Discovery [RFC6763] does no= t. As=20 a result security considerations for SSD considers 1) security considerati= ons of=20 SSD over mDNS, 2) security considerations of SSD over DNS and 3) security=20 considerations on interactions between DNS and mDNS.


As a resul= t,=20 security assumption of DNS-Based Service Discovery [RFC6763] are not any m= ore=20 valid for Scalable DNS-Based Service Discovery.

1) Privacy=20 protection

Information provided by SSD may contain private informat= ion=20 that is not expected to go outside  the specified scope.

Serv= ice=20 Discovery carry information about the type of devices available in your ne= twork,=20 the software version, their location both physical like floor as well as=20 networking - like the IP address. All these pieces of information may be u= seful=20 for an intruder. Device and software information are useful to identify=20 vulnerabilities, and location information are useful to locate the target,= names=20 may also include information that may be useful to define a specific targe= t -=20 like "Personal CEO Printer". For these reasons, one is willing to limit th= e=20 scope these pieces of information.

    a) Informatio= ns=20 spreading may be limited based on network information. When DNS is used, t= he DNS=20 zone SHOULD NOT be accessed by anyone from outside the specific network. T= his=20 can be performed at the DNS server level or at the network boundaries by s= etting=20 firewall policies specifying which kind of IP address can access the DNS s= erver.=20 When mDNS is used, multicasted information SHOULD NOT be forwarded outside= the=20 expected network. This can be performed by firewalls that drops outbound/i= nbound=20 mDNS packets at the network boundaries. Note that in both cases, these pol= icies=20 are outside the scope of mDNS or DNS. On the other hand, for mobile device= s, for=20 example, which information may be provided depends on the network. These=20 policies have to be implemented by the mobile device.

  &= nbsp;=20 b) SSD SHOULD also consider scopes that are not correlated to network=20 definitions like 'building' or 'room'. As defined in the charter:
"It = is=20 also desirable that multiple discovery scopes are supported,
from the p= oint=20 of view of either performing discovery within a
specified scope or=20 advertisement within a specified scope, and
being able to discover=20 (enumerate) the set of scopes such that
an application could then choo= se to=20 do either. It should be noted
that scope in this sense might refer to=20 'building' or 'room' and thus
might have no correlation to network=20 topology."

This requires 1) definition of the different available s= copes.=20 Some default value MAY be provided by the device without knowledge of the=20 specific available scopes of the network. Such default values MAY be used = by=20 devices if they do not discover the different scopes specific to the netwo= rk or=20 if the device does not have sufficient information to trust the announced=20 scopes. In that case the device MAY start with a default limited scope. 2)= =20 Specific network values SHOULD be announced in an authenticated way to avo= id=20 that, for example,  non existing scope used results in service unavai= lable. The policy for non existing scopes SHOULD be defined with a reduced scope,= and=20 the device SHOULD be informed that the scope does not exist so it may upda= te its=20 scope. 3) Once devices have been informed of the various scope, it MAY cho= se the=20 one that seems the most appropriated and provide this information. Dependi= ng on=20 the scope, routers or middle boxes MAY chose to forward the information or= not.=20 The information MAY be forwarded on multiple links. With scopes that are n= ot=20 network correlated, the information MAY be forwarded to a subset of device= s=20 within a link. The use of distinct multicast IP address may be used to=20 distinguish the different scopes. However, the use of different IP address= es=20 does not prevent devices to listen to the information. If the device needs= the=20 information to be read only by the members of the scope, cryptography MAY = be=20 used to encrypt the data. IPsec multicast extension [RFC5374] may be a goo= d=20 candidate. This mechanism may also be used to prevent an unauthorised devi= ce to=20 provide a service for a given scope. In other words, my printer should not= be=20 able to announce its service for the "CEO" scope and I should not be able = to see=20 the announcement of the printer of my CEO.

2) Exposing Services
A=20 Service announced over a network does not mean the service is available to= =20 anyone. Such services SHOULD enforce access control policies for the=20 service.

If a connected printer is not using SD, it MAY appear as a= =20 simple IP connected device attached to the network. Only specific=20 tests/scans/traffic monitor can determine the device is a printer. When SD= or=20 SSD is used, as soon as the device is plugged on the network everyone know= s=20 "Photo Color Printer, Building A floor 2" has been plugged. If this printe= r is=20 reserved for the Graphic an Design department, than the printer SHOULD imp= lement=20 access control mechanisms. Although these policies are out of scope of SSD= , they=20 MAY be required as a consequence of SSD.
 
2) Resource=20 exhaustion

With new emerging types of networks like sensor networks= and=20 more generally the IoT, SSD cannot anymore rely on mDNS and multicast to=20 advertise its services and SHOULD provide a dedicated entity that can perf= orm=20 SSD via unicast messages. Typically, this can be deployed with a mDNS-to-D= NS=20 agent that receives announcement from mDNS devices and stores this informa= tion=20 to the DNS zone. Since the information is stored, other devices in the net= work=20 do not have to receive and treat mDNS announcements.

SSD MUST be ab= le to=20 scale to thousands of devices. The use of multicast for service announceme= nt=20 requires that each device informs all other devices some information like = the=20 hosted service for example. In order to make sure devices always have the=20 information up-to-date or that any new device has the information, the dev= ice=20 regularly retransmits the information to all other devices. This is not a=20 scalable architecture as it does not scale in term of bandwidth nor it con= sider=20 energy consumption constrains of small devices.

Any messages are by= tes=20 received by the devices connected on the network, which may require additi= onal=20 processing such as cryptographic check if used in conjunction with DNSSEC = for=20 example. These devices may rely on battery, and each of these messages dir= ectly=20 impact the lifetime of the device. As a result aggressive multicast may=20 unnecessarily affect IoT devices. More rational approach MAY consists in m= aking=20 possible SSD using unicast communications only or to prevent that IoT devi= ce=20 wakes up at every multicast message or using multicast to announce informa= tion=20 updates as opposed to cache populating. More specifically, a new device ca= n use=20 multicast to announce a newly published information. Eventually this infor= mation=20 may be cached by always-on devices and stored in the DNS. A new device may= get=20 access to these pieces of information with an unicast AXFR for example. Th= e main=20 advantage is that multicast interface can be switched off.
 
So= here=20 we're in similar territory to the discussions about RAs, and multicast on=20 certain types of links, which has led to the efficient-ND proposal, and re= lated=20 work on energy efficiency for low power devices etc. [http://www.ietf.org/internet-drafts/draft-halpern-6man-nd= -pre-resolve-addr-00.txt]

3)=20 Trusted Scalable Service Discovery

This section is only focused on = how=20 information provided by the SSD can be trusted. As every device announce t= heir=20 service, SSD SHOULD prevent an attacker to announce it is the "CEO Printer= " in=20 order to collect all documents printed by the CEO.
In this section, we= =20 consider that "CEO Printer" does not exists and that the attack does not a= im at=20 hijacking a specific name. Using the SD terminology "CEO Printer" would be= the=20 Instance part of the Service Instance Name.

a) User perspective
= When=20 DNS is used, DNSSEC can be used, and one can trust the information as it=20 provides from a trusted party. Although DNSSEC has not been designed as a=20 protocol that certifies the validity of the DNS RDATA, in our case, DNSSEC= could=20 be used as such. Contrary to registrars that are hosting FQDNs they have v= ery=20 few knowledge on, network administrators are expected to administrated the= DNS=20 zone according to the resources available for the network. As a result DNS= SEC=20 validation could be interpreted as "validated by the administrator".
mDNS=20 does not have trust anchors provided by DNSSEC. However, DNSSEC used in=20 conjunction of mDNS can be used to provide a proof-of-ownership of the=20 information. How reliable is that information can be learned over time by=20 processing the reputation of a device (represented by its public key) or b= y=20 monitoring whether the information remains coherent over time. For example= , if a=20 printer announces its IP address as part of the company network, and sudde= nly=20 starts announcing an IP address located somewhere else, further checks may= be=20 performed before trusting the information. Even though the mDNS message si= gned=20 with DNS cannot be trusted the same way as it would have been trusted in a= =20 DNSSEC zone, using DNSSEC in conjunction of mDNS makes possible to assign = some=20 pieces of information to a specific key. This helps in establishing a repu= tation=20 as well as avoids spoofed messages.

On a user perspective, mDNS req= uires=20 the end user to establish a reputation mechanism whereas DNS provides cert= ified=20 information. The main advantage of DNS is that a new end user has certifie= d=20 information which is not possible with mDNS.

[TBD check/compare hyb= rid=20 model]

b) Devices perspective

When DNS is used, the device M= UST be=20 able to provide the information to the DNS server via DNS update [RFC2136]= or=20 secure DNS update [RFC3007]. This scenario may not meet a Zero configurati= on=20 requirement as the DNS server needs to know the public key of the devices,= and=20 the device needs to know at least the IP address of the DNS server. If DHC= Pv6=20 the IP address of the MAY be derived from the Domain Search List and the D= NS=20 Recursive Name Server option [RFC3646]. The device MAY send a DNS query fo= r one=20 domain search with type NS to the recursive name server. However, register= ing=20 the public keys of the devices in the DNS does not scale thousands of devi= ces.=20 Most likely, their public keys may be considered as trusted based on reput= ation,=20 leap of faith principles which does not necessarily prevent an attacker to= set=20 false data into the DNS zone.
  
When mDNS is used, the = device=20 does not need any configuration. This information is announced to the netw= ork.=20 The information will be trusted by the devices that trust the announcer. A= s for=20 the DNS, provisioning all devices of the network with all public keys is n= ot=20 scalable. As mentioned above, public keys will be trusted most likely base= d on=20 reputation or leap of faith principles.

The main difference between= DNS=20 and mDNS seems that DNS requires less provisioning or configuration than m= DNS (n=20 versus n * (n - 1) for a n device network). Then in a zero configuration=20 scenario, DNS centralises in a single point the way a key can be trusted. = The=20 only disadvantage of using DNS is the devices should discover the DNS=20 server.

It seems that approach combining mDNS and DNS can take adva= ntage=20 of both. Devices announce information using mDNS and the DNS according to = the=20 level of trust stores the information in its zone.


4) Informati= on=20 impersonation

The previous section provided considerations on how a= =20 device can be associated to a public key and eventually identified as a tr= usted=20 device. With zero configuration, the level of trust associated to a device= =20 results of a trade off between configuration and a learning process. This=20 section indicates how information provided by the devices can be monitored= to=20 determine the reputation of a device, to raise an alarm to the administrat= or,=20 and eventually show a device cannot be trusted or indicate a device has=20 been  corrupted.

The kind of informations provided by SD or SS= D that=20 are visible to the end user are 1) a name that describes a service and 2) = the=20 location of the service. The name of the service corresponds to Service In= stance=20 Name. With SD the name is mentioned in the RDATA part of the PTR and as th= e key=20 of the SRV RRSet. The location of the service is the RDATA part of the SRV= as=20 well as its corresponding locator.

The Service Instance Name is co= mposed=20 of three parts: Instance, Service Name and Domain. SD recommends that Inst= ance=20 and Domain are encoded using UTF8. UTF8 enables specific characters that a= re not=20 yet being considered in the current DNS. Traditional DNS uses ascii or Pun= ycode.=20 If UTF8 is more flexible in term of string representation, it may provide=20 multiple ways to express the same thing which may confuse the end user. In= fact=20 using UTF8 "My Printer", "my printer" "My printer" are different strings. = This=20 may be used by an attacker that will provide a service different in term o= f UTF8=20 format, but that the end user will assimilate to the same service. In addi= tion,=20 "my printer" will be displayed differently if encoded in UTF8 or in ascii.= As a=20 result two service "my printer" could be stored in a DNS zone without any=20 collisions.
One way to avoid multiple format would be to consider the=20 necessary or missing characters provided by UTF8 and add them in the Puny=20 code.
If there may be some advantages in using UTF8 for the service nam= e, the=20 domain name part SHOULD use only the Punycode.
As a result, checking=20 information for SSD requires to establish metrics/similarities between=20 strings.

Worth noting in the DNS the device might be hpprint01.bldg32.somesite.co= m,=20 while its internally stored label may be "Building 32 foyer=20 printer".


The location of the service is identified by a FQDN a= nd a=20 corresponding IP address. In SD, the FQDN respect the Punnycode encoding. = The=20 FQDN of the service may be checked against the known domain names associat= ed to=20 the network. Similarly, the IP address is generally used to locate the ser= vice.=20 if the IP address is not inside the network, this may raise a warning to t= he=20 administrator, that may validate the IP address.


When DNSSEC is= used=20 closed names addressed by different keys are suspicious. Without the use o= f=20 DNSSEC is becomes hard to detect the device/SD device has not changed thei= r IP=20 address.


5) Unique network identifier
 
SD uses ".l= ocal"=20 prefix to indicate the scope of the FQDN.  ".local" is a special use = domain=20 name - RFC 6761, and in the registry at
http://www.iana.org/assignments/special-use-domain-= names/special-use-domain-names.xhtml

".local"=20 is instantiated in any networks. This results in a given string with multi= ple=20 meanings. "My Printer" at home is not the same service as "My Printer" at = work=20 and if the information is cached in some devices, this may result in cross= site=20 name hijacking. An attacker could for example advertise "My Printer" in a = public=20 network like in an airport with a global IP address. The Service Instance = Name=20 used could be something as "My Printer_ipp_tcp.local SRV global-printer.example.com"= . People=20 in the airport may then send their documents to "My Printer" advertised in= the=20 airport - that is to say global-printer.example.com = -,=20 instead of the one of their office.

In order to mitigate this conf= usion,=20 ".local" SHOULD be used only when the device does not know the domain name= =20 associated to the network. If DHCPv6 is used this may be derived by the DH= CPv6=20 Client FQDN option [RFC4704].

Note also that "My printer" may be a=20 different printer when I am at home or at work. On the other hand, while a= t hoe=20 I SHOULD be able to use "My Office Printer" and vice versa. This ambiguity= may=20 be leverage by the use of unique prefix.

6) Compromised=20 device    

This section estimates how a compro= mised=20 device impacts the SSD service. We assume DNSSEC is used.

Once dete= cted,=20 the public key associated to the device is revoked. With DNS the revocatio= n=20 occurs once in the DNS, and the information is only stored in the remainin= g=20 caches of devices that have requested the information before it expires. A= fter=20 TTL seconds, the information is revoked from all devices. If mDNS is used,= =20 revocation should occur in every device. The mechanism to detect a device = is=20 compromised is complex and will probably not be implemented properly in mo= st=20 devices.

With the current SD, a compromised device MAY provide wron= g=20 information about itself but does not affect others device information.




--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 6= 9 58=20
------=_001_NextPart027738470163_=------ From mglt.ietf@gmail.com Tue Jan 21 22:56:02 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 8325A1A02B3 for ; Tue, 21 Jan 2014 22:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 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, 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 DIEZ97H11zRQ for ; Tue, 21 Jan 2014 22:55:57 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7FC1A02DD for ; Tue, 21 Jan 2014 22:55:57 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id p61so8802686wes.20 for ; Tue, 21 Jan 2014 22:55:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tV6TQTw8EnHrVPJRT7vc1zVG6OQ01hjydStVwQ2plbU=; b=XW4hBlO4qsslz0lWtuHaplzneNlDw781qkF7XwA7aps4qlyWO1Rrk+ATM0s8T+HRmF F8WT8C1aAmYisAmccRTqAsb7NaRxu08AqvjS9jeXOS1pEiwR865txuzWKMQ2ZBgVGzJw j3hp6sffe76V8rT5H1EWbo+tJEZDq7csOKKPeU+JdnAkTomtEiZ6lG7jm9zzjMnWz3Ro eXD1aVB83WWco2U3+ci5z4BToXFs5y2DpkBlRMSb4QesX/TpUwJ1EFYmvQ0QDzY0sRdr bcUBi+32HLd30hNXI6SQiviWlSmee0is+A2fcLq/aHhay+edWJ1DU35UwD/YCf5XZdRo DORQ== MIME-Version: 1.0 X-Received: by 10.195.13.164 with SMTP id ez4mr22813981wjd.11.1390373756207; Tue, 21 Jan 2014 22:55:56 -0800 (PST) Received: by 10.194.171.129 with HTTP; Tue, 21 Jan 2014 22:55:56 -0800 (PST) In-Reply-To: <2014012115540802807511@cnnic.cn> References: <2014012115540802807511@cnnic.cn> Date: Wed, 22 Jan 2014 07:55:56 +0100 Message-ID: From: Daniel Migault To: Guangqing Deng Content-Type: text/plain; charset=ISO-8859-1 Cc: dnssd Subject: Re: [dnssd] draft-ietf-dnssd-requirements-00.txt: Requirements/Security Considerations 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, 22 Jan 2014 06:56:02 -0000 Hi Deng, Thank you very much for the comments and question. If I understand correctly your point, you are saying that DNSSEC and IPsec performed in an authenticated way may add to much overhead on the network for a temporary service. This may be true on two aspects: 1) IPsec/DNSSEC adds configurations, or equivalent mechanisms to have a trust anchor 2) DNSSEC /IPsec adds overheads (that is more bytes). In the draft we are not really concerned about the service BUT service discovery protocol. More specifically this means how you learn your printer is at IP XXX using this configuration, not how you connect to the printer. To be honest I am not sure we have considered the specific service you are referring to. Maybe you could specify briefly the service and point out what would bother the service. I guess the additional overhead depends on how long "temporary" is, and to which frequency the service is up. I would be interested to have more details on the service you are referring to. What is not so clear to me is that security is the cause of the problem. Maybe the problem of updating information is due to the DNS format used to carry the service information. The DNS format imposes a modification is efficient after TTL seconds which is the necessary time all caches expires. During these TTL seconds, if not properly considered, they may be some incoherent information about the service. Again, a description of the service may clarify this. The next paragraphs attempt to describe the overhead due to the use of DNSSEC or IPsec. With IPsec, devices could share a Certificate Authority or a specific certificate. The service may be configured with this certificate which would enable to authenticate to protect the mDNS/DNS transactions . Of course it needs an initial configuration. IKEv2 adds a 4 packet exchange over at least the first connection every connection. As a result IKEv2 is the additional traffic. With the use of DNSSEC as a certified database, each device / service may need to register. Again, this may require the DNS to authenticate the devices. keys associated to devices may be provisioned to the DNS server. Then SIG(0) can be used to authenticate the update of the service. With DNSSEC you may have to remove security informations (keys) in the DNS, but even without security you may had to remove the connectivity inforlation (like IP addreses). As a result it does not add additional exchanges, but makes message larger. If dnssd uses mDNS, that is not a centralized database, then the use of DNSSEC does not adds exchanges, but makes messages largers. BR, Daniel BR Daniel On Tue, Jan 21, 2014 at 8:54 AM, Guangqing Deng wrote: > Hi, Daniel, so many details on SSD requirements are presented here, which > helps me have a more deep understanding on this issue. It is said that IPsec > and DNSSEC can be used to authenticate the devices tending to provide > service. While one question is that the deployment of IPsec and DNSSEC may > lead to highly increased traffic within the local network. And for those > temporary service providers (which just provide services in a short time in > a mesh wireless network, for instance), the process of temporary service > provider registering on DNSSEC system may be too long compared with the > relatively short serving period. Also, the DNSSEC system has to revoke the > public key of the temporary service provider if it has gone off-line. So it > seems that we should clarify the service mentioned in this WG. Is the > service mentioned in this WG means a long-term one or short-term one or > both? > > ________________________________ > Guangqing Deng > CNNIC > > From: Daniel Migault > Date: 2014-01-19 16:02 > To: dnssd > CC: Tim Chown; Kerry Lynn > Subject: [dnssd] draft-ietf-dnssd-requirements-00.txt: Requirements/Security > Considerations > Hi Folks, > > Here are some additional requirements for > draft-ietf-dnssd-requirements-00.txt as well as a starting point for the > security consideration section. This section has been updated with Tim's > comments. > > Your are more than welcome to comment/clarify/change the proposed text. We > would appreciate you provide them by Friday January 23 so they can be > considered for the next version. > > Best Regards, > > Daniel > > Terminology section: > > I think we should add the following terms. I am using used them in the > remaining of the mail. They may be changed for the draft. > > mDNS: multicast DNS as defined in [RFC6762] > SSD: Scalable Service Discovery > SD DNS-Based Service Discovery [RFC6763] > > Requirements section: > > I suggest adding or complete existing requirements with the following ones: > > SSD SHOULD be designed for both DNS and mDNS working in a cooperative way. > More specifically, it SHOULD consider interaction between DNS and mDNS. > > SSD SHOULD be able to be performed by client only using DNS and unicast to > avoid multiple multicast messages. > > SSD SHOULD work with existing DNS-Based Service Discovery over mDNS and > SHOULD NOT break any other discovery protocols. > As specified in the charter [http://datatracker.ietf.org/wg/dnssd/charter/] > "The WG will consider the tradeoffs between reusing/extending existing > protocols and developing entirely new ones. It is highly desirable > that any new solution is backwardly compatible with existing DNS-SD/mDNS > deployments. Any solution developed by the dnssd WG must not conflict > or interfere with the operation of other zero-configuration service and > naming protocols such as uPnP or LLMNR. Integration with such protocols > is out of scope for this WG." > > and > > "To document challenges and problems encountered in the coexistence > of zero configuration and global DNS name services in such > multi-link networks, including consideration of both the name > resolution mechanism and the namespace." > > > SSD SHOULD consider the use of globally unique FQDN that is specific of a > given network instead of a default domain name as ".local". SSD SHOULD > provide means to discover/announce the FQDN associated to the network. A > default and common FQDN - like ".local." could be used only when the > specific FQDN of the network has not been determined. Furthermore, in order > to ease interoperation with DNS the domain name SHOULD follow DNS-compatible > encoding (i.e ascii or punycode). > > > SSD SHOULD be able to take advantage of network configurations (DHCP/RA) > protocol. If it is clear that SSD and DNS SHOULD be able to work together, > DHCP may also be used to announce necessary information for the network such > as its associated FQDN (using DHCP Domain Search / DHCP Domain option / IPv6 > RA [RFC6106]), the interface to register FQDNs... This MAY for example > complement or avoid the use of the specific > b/db/r/dr/lb.dns-sd._udp. or equivalent queries. > > > SSD SHOULD be able to announce the scope Service Discovery informations are > expected to be accessed or multicasted. This requires something like a > "scope" discovery protocol. > > > Security Consideration section > > Here is some text I propose. Comments are more then welcome! I hope that we > will be able to fix this section during the next meeting. > > > 1. Scalable DNS Service is not an extension of SD in term of security > > Scalable DNS-Based Service Discovery can hardly rely on the security > considerations defined for DNS-Based Service Discovery [RFC6763]. > Considering "Scalability" requires new security practices that are defines > in this document. > > DNS-Based Service Discovery [RFC6763] has been designed so that a device can > announce a service to the other devices of the network. Although DNS or mDNS > can be used for SD, SD has been mostly thought to work over mDNS to avoid > DNS zone management and to handle UTF8 names for the end users even in the > domain part of the Instance Service Name. As a result SD' security > considerations rely on mDNS security considerations, DNSSEC [RFC4033] for > authentication and secure DNS update [RFC3007] to secure DNS update > [RFC2136]. These considerations are not sufficient for SSD as explained > below. > > - a) DNSSEC is probably the DNS extension that MAY be used to provide > authentication and integrity check protection. However, authentication other > than proof-of-ownership or leap-of-faith security model requires trust > anchors. Trust anchor MAY be provided by the global DNS, but this has not > been specified in SD. Section 10 of RFC6763 illustrates how to populate the > DNS with information but clearly states that such interactions are out of > scope of RFC6763. Interactions between SSD and DNS cannot be specified in an > illustrative section. > > - b) Similarly, DNS updates are used by SD to cooperate with DNS. These > interactions are left as illustrative in RFC6763, which is not sufficient > for SSD. > > -c) mDNS security considerations are not sufficient for SSD. At first, > mDNS requires cooperative devices. If cooperative devices is a reasonable > assumption in a one hop network such as most home networks, this assumption > cannot be made for larger networks, such as corporate networks for example. > > In case all devices cannot trust each other, SD considers the use of > IPsec or DNSSEC. How these protocols are used is not fully described in > RFC6762 and SHOULD be at least documented for SSD. More specifically, DNSSEC > can be used with different security models. Authentication of the devices > may require a chain of trust and interaction with DNS. Alternatively > authentication may rely on devices configured with certificates. In the > absence of such certificates or chain of trust, a proof-of-ownership with > device's reputation may be considered. > > mDNS considers the use of DNSSEC to differentiate responses from the > global DNS and mDNS that addresses a local scope. DNSSEC may not be the > appropriated solution for SSD as DNSSEC may not be deployed for the global > DNS or for mDNS which would make distinction impossible. As suggested by > RFC6761, the use of ".local" to specify mDNS may be more appropriated. > > mDNS also raises the issue of relative domain names (example.com) that > may be solved as example.com.local. or as example.com.search-domain. This > issue becomes more complex with SSD. For SD there is little ambiguity with > the meaning of ".local". It is a single link, usually a single network. SSD > considers multiple links and as such multiple ".local" and multiple > different search domain. Thus the question may be which link's search domain > is to be considered. > > mDNS considers very few interactions with DNS. The only mentioned case > is when a global DNS resolution is performed using mDNS. mDNS indicates how > to treat relative domains. Interaction between mDNS and DNS was not so > necessary as with one hop network there is a clear separation between the > local and non local (Internet) network. With multiple networks, the frontier > between local and non local becomes much undefined. As result whether naming > resolution is local (mDNS) or global (DNS) is not obvious. This is why SSD > needs to specify interactions between DNS and mDNS whereas DNS-Based Service > Discovery [RFC6763] does not. As a result security considerations for SSD > considers 1) security considerations of SSD over mDNS, 2) security > considerations of SSD over DNS and 3) security considerations on > interactions between DNS and mDNS. > > > As a result, security assumption of DNS-Based Service Discovery [RFC6763] > are not any more valid for Scalable DNS-Based Service Discovery. > > 1) Privacy protection > > Information provided by SSD may contain private information that is not > expected to go outside the specified scope. > > Service Discovery carry information about the type of devices available in > your network, the software version, their location both physical like floor > as well as networking - like the IP address. All these pieces of information > may be useful for an intruder. Device and software information are useful to > identify vulnerabilities, and location information are useful to locate the > target, names may also include information that may be useful to define a > specific target - like "Personal CEO Printer". For these reasons, one is > willing to limit the scope these pieces of information. > > a) Informations spreading may be limited based on network information. > When DNS is used, the DNS zone SHOULD NOT be accessed by anyone from outside > the specific network. This can be performed at the DNS server level or at > the network boundaries by setting firewall policies specifying which kind of > IP address can access the DNS server. When mDNS is used, multicasted > information SHOULD NOT be forwarded outside the expected network. This can > be performed by firewalls that drops outbound/inbound mDNS packets at the > network boundaries. Note that in both cases, these policies are outside the > scope of mDNS or DNS. On the other hand, for mobile devices, for example, > which information may be provided depends on the network. These policies > have to be implemented by the mobile device. > > b) SSD SHOULD also consider scopes that are not correlated to network > definitions like 'building' or 'room'. As defined in the charter: > "It is also desirable that multiple discovery scopes are supported, > from the point of view of either performing discovery within a > specified scope or advertisement within a specified scope, and > being able to discover (enumerate) the set of scopes such that > an application could then choose to do either. It should be noted > that scope in this sense might refer to 'building' or 'room' and thus > might have no correlation to network topology." > > This requires 1) definition of the different available scopes. Some default > value MAY be provided by the device without knowledge of the specific > available scopes of the network. Such default values MAY be used by devices > if they do not discover the different scopes specific to the network or if > the device does not have sufficient information to trust the announced > scopes. In that case the device MAY start with a default limited scope. 2) > Specific network values SHOULD be announced in an authenticated way to avoid > that, for example, non existing scope used results in service unavailable. > The policy for non existing scopes SHOULD be defined with a reduced scope, > and the device SHOULD be informed that the scope does not exist so it may > update its scope. 3) Once devices have been informed of the various scope, > it MAY chose the one that seems the most appropriated and provide this > information. Depending on the scope, routers or middle boxes MAY chose to > forward the information or not. The information MAY be forwarded on multiple > links. With scopes that are not network correlated, the information MAY be > forwarded to a subset of devices within a link. The use of distinct > multicast IP address may be used to distinguish the different scopes. > However, the use of different IP addresses does not prevent devices to > listen to the information. If the device needs the information to be read > only by the members of the scope, cryptography MAY be used to encrypt the > data. IPsec multicast extension [RFC5374] may be a good candidate. This > mechanism may also be used to prevent an unauthorised device to provide a > service for a given scope. In other words, my printer should not be able to > announce its service for the "CEO" scope and I should not be able to see the > announcement of the printer of my CEO. > > 2) Exposing Services > > A Service announced over a network does not mean the service is available to > anyone. Such services SHOULD enforce access control policies for the > service. > > If a connected printer is not using SD, it MAY appear as a simple IP > connected device attached to the network. Only specific tests/scans/traffic > monitor can determine the device is a printer. When SD or SSD is used, as > soon as the device is plugged on the network everyone knows "Photo Color > Printer, Building A floor 2" has been plugged. If this printer is reserved > for the Graphic an Design department, than the printer SHOULD implement > access control mechanisms. Although these policies are out of scope of SSD, > they MAY be required as a consequence of SSD. > > 2) Resource exhaustion > > With new emerging types of networks like sensor networks and more generally > the IoT, SSD cannot anymore rely on mDNS and multicast to advertise its > services and SHOULD provide a dedicated entity that can perform SSD via > unicast messages. Typically, this can be deployed with a mDNS-to-DNS agent > that receives announcement from mDNS devices and stores this information to > the DNS zone. Since the information is stored, other devices in the network > do not have to receive and treat mDNS announcements. > > SSD MUST be able to scale to thousands of devices. The use of multicast for > service announcement requires that each device informs all other devices > some information like the hosted service for example. In order to make sure > devices always have the information up-to-date or that any new device has > the information, the device regularly retransmits the information to all > other devices. This is not a scalable architecture as it does not scale in > term of bandwidth nor it consider energy consumption constrains of small > devices. > > Any messages are bytes received by the devices connected on the network, > which may require additional processing such as cryptographic check if used > in conjunction with DNSSEC for example. These devices may rely on battery, > and each of these messages directly impact the lifetime of the device. As a > result aggressive multicast may unnecessarily affect IoT devices. More > rational approach MAY consists in making possible SSD using unicast > communications only or to prevent that IoT device wakes up at every > multicast message or using multicast to announce information updates as > opposed to cache populating. More specifically, a new device can use > multicast to announce a newly published information. Eventually this > information may be cached by always-on devices and stored in the DNS. A new > device may get access to these pieces of information with an unicast AXFR > for example. The main advantage is that multicast interface can be switched > off. > > So here we're in similar territory to the discussions about RAs, and > multicast on certain types of links, which has led to the efficient-ND > proposal, and related work on energy efficiency for low power devices etc. > [http://www.ietf.org/internet-drafts/draft-halpern-6man-nd-pre-resolve-addr-00.txt] > > 3) Trusted Scalable Service Discovery > > This section is only focused on how information provided by the SSD can be > trusted. As every device announce their service, SSD SHOULD prevent an > attacker to announce it is the "CEO Printer" in order to collect all > documents printed by the CEO. > In this section, we consider that "CEO Printer" does not exists and that the > attack does not aim at hijacking a specific name. Using the SD terminology > "CEO Printer" would be the Instance part of the Service Instance Name. > > a) User perspective > When DNS is used, DNSSEC can be used, and one can trust the information as > it provides from a trusted party. Although DNSSEC has not been designed as a > protocol that certifies the validity of the DNS RDATA, in our case, DNSSEC > could be used as such. Contrary to registrars that are hosting FQDNs they > have very few knowledge on, network administrators are expected to > administrated the DNS zone according to the resources available for the > network. As a result DNSSEC validation could be interpreted as "validated by > the administrator". > > mDNS does not have trust anchors provided by DNSSEC. However, DNSSEC used in > conjunction of mDNS can be used to provide a proof-of-ownership of the > information. How reliable is that information can be learned over time by > processing the reputation of a device (represented by its public key) or by > monitoring whether the information remains coherent over time. For example, > if a printer announces its IP address as part of the company network, and > suddenly starts announcing an IP address located somewhere else, further > checks may be performed before trusting the information. Even though the > mDNS message signed with DNS cannot be trusted the same way as it would have > been trusted in a DNSSEC zone, using DNSSEC in conjunction of mDNS makes > possible to assign some pieces of information to a specific key. This helps > in establishing a reputation as well as avoids spoofed messages. > > On a user perspective, mDNS requires the end user to establish a reputation > mechanism whereas DNS provides certified information. The main advantage of > DNS is that a new end user has certified information which is not possible > with mDNS. > > [TBD check/compare hybrid model] > > b) Devices perspective > > When DNS is used, the device MUST be able to provide the information to the > DNS server via DNS update [RFC2136] or secure DNS update [RFC3007]. This > scenario may not meet a Zero configuration requirement as the DNS server > needs to know the public key of the devices, and the device needs to know at > least the IP address of the DNS server. If DHCPv6 the IP address of the MAY > be derived from the Domain Search List and the DNS Recursive Name Server > option [RFC3646]. The device MAY send a DNS query for one domain search with > type NS to the recursive name server. However, registering the public keys > of the devices in the DNS does not scale thousands of devices. Most likely, > their public keys may be considered as trusted based on reputation, leap of > faith principles which does not necessarily prevent an attacker to set false > data into the DNS zone. > > When mDNS is used, the device does not need any configuration. This > information is announced to the network. The information will be trusted by > the devices that trust the announcer. As for the DNS, provisioning all > devices of the network with all public keys is not scalable. As mentioned > above, public keys will be trusted most likely based on reputation or leap > of faith principles. > > The main difference between DNS and mDNS seems that DNS requires less > provisioning or configuration than mDNS (n versus n * (n - 1) for a n device > network). Then in a zero configuration scenario, DNS centralises in a single > point the way a key can be trusted. The only disadvantage of using DNS is > the devices should discover the DNS server. > > It seems that approach combining mDNS and DNS can take advantage of both. > Devices announce information using mDNS and the DNS according to the level > of trust stores the information in its zone. > > > 4) Information impersonation > > The previous section provided considerations on how a device can be > associated to a public key and eventually identified as a trusted device. > With zero configuration, the level of trust associated to a device results > of a trade off between configuration and a learning process. This section > indicates how information provided by the devices can be monitored to > determine the reputation of a device, to raise an alarm to the > administrator, and eventually show a device cannot be trusted or indicate a > device has been corrupted. > > The kind of informations provided by SD or SSD that are visible to the end > user are 1) a name that describes a service and 2) the location of the > service. The name of the service corresponds to Service Instance Name. With > SD the name is mentioned in the RDATA part of the PTR and as the key of the > SRV RRSet. The location of the service is the RDATA part of the SRV as well > as its corresponding locator. > > The Service Instance Name is composed of three parts: Instance, Service Name > and Domain. SD recommends that Instance and Domain are encoded using UTF8. > UTF8 enables specific characters that are not yet being considered in the > current DNS. Traditional DNS uses ascii or Punycode. If UTF8 is more > flexible in term of string representation, it may provide multiple ways to > express the same thing which may confuse the end user. In fact using UTF8 > "My Printer", "my printer" "My printer" are different strings. This may be > used by an attacker that will provide a service different in term of UTF8 > format, but that the end user will assimilate to the same service. In > addition, "my printer" will be displayed differently if encoded in UTF8 or > in ascii. As a result two service "my printer" could be stored in a DNS zone > without any collisions. > One way to avoid multiple format would be to consider the necessary or > missing characters provided by UTF8 and add them in the Puny code. > If there may be some advantages in using UTF8 for the service name, the > domain name part SHOULD use only the Punycode. > As a result, checking information for SSD requires to establish > metrics/similarities between strings. > > Worth noting in the DNS the device might be hpprint01.bldg32.somesite.com, > while its internally stored label may be "Building 32 foyer printer". > > > The location of the service is identified by a FQDN and a corresponding IP > address. In SD, the FQDN respect the Punnycode encoding. The FQDN of the > service may be checked against the known domain names associated to the > network. Similarly, the IP address is generally used to locate the service. > if the IP address is not inside the network, this may raise a warning to the > administrator, that may validate the IP address. > > > When DNSSEC is used closed names addressed by different keys are suspicious. > Without the use of DNSSEC is becomes hard to detect the device/SD device has > not changed their IP address. > > > 5) Unique network identifier > > SD uses ".local" prefix to indicate the scope of the FQDN. ".local" is a > special use domain name - RFC 6761, and in the registry at > http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml > > ".local" is instantiated in any networks. This results in a given string > with multiple meanings. "My Printer" at home is not the same service as "My > Printer" at work and if the information is cached in some devices, this may > result in cross site name hijacking. An attacker could for example advertise > "My Printer" in a public network like in an airport with a global IP > address. The Service Instance Name used could be something as "My > Printer_ipp_tcp.local SRV global-printer.example.com". People in the airport > may then send their documents to "My Printer" advertised in the airport - > that is to say global-printer.example.com -, instead of the one of their > office. > > In order to mitigate this confusion, ".local" SHOULD be used only when the > device does not know the domain name associated to the network. If DHCPv6 is > used this may be derived by the DHCPv6 Client FQDN option [RFC4704]. > > Note also that "My printer" may be a different printer when I am at home or > at work. On the other hand, while at hoe I SHOULD be able to use "My Office > Printer" and vice versa. This ambiguity may be leverage by the use of unique > prefix. > > 6) Compromised device > > This section estimates how a compromised device impacts the SSD service. We > assume DNSSEC is used. > > Once detected, the public key associated to the device is revoked. With DNS > the revocation occurs once in the DNS, and the information is only stored in > the remaining caches of devices that have requested the information before > it expires. After TTL seconds, the information is revoked from all devices. > If mDNS is used, revocation should occur in every device. The mechanism to > detect a device is compromised is complex and will probably not be > implemented properly in most devices. > > With the current SD, a compromised device MAY provide wrong information > about itself but does not affect others device information. > > > > > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 From ajs@anvilwalrusden.com Wed Jan 22 14:26:19 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 6005D1A04CB for ; Wed, 22 Jan 2014 14:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 d_GZlRvd8pRN for ; Wed, 22 Jan 2014 14:26:18 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE051A01DA for ; Wed, 22 Jan 2014 14:26:18 -0800 (PST) Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 7B6568A031 for ; Wed, 22 Jan 2014 22:26:17 +0000 (UTC) Date: Wed, 22 Jan 2014 17:26:17 -0500 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20140122222616.GN1271@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 22 Jan 2014 22:26:19 -0000 Dear colleagues, At the last meeting, there was a request that I adapt the draft I presented in order to get rid of the solution proposal (work we're not chartered to undertake), and extract just the motivation or requirements bit. I think I've done that with draft-sullivan-dnssd-mdns-dns-interop-00. I hereby solicit review. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From doug.mtview@gmail.com Wed Jan 22 17:48: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 E31E31A0266 for ; Wed, 22 Jan 2014 17:48:26 -0800 (PST) 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 1OQMxXt5NZBR for ; Wed, 22 Jan 2014 17:48:24 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 14A3F1A02F1 for ; Wed, 22 Jan 2014 17:48:24 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id lf10so1187005pab.18 for ; Wed, 22 Jan 2014 17:48:23 -0800 (PST) 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=hhiTkWz14bZ3IAVMyiPESVP9rbcwR9bruQSR4ucbEMk=; b=scACSFn0pck2QAtqT3SDLNkOiXJ9awnUP3t/6rWK3BL56O+7yMbjx48r+Nwb2uBZWF VJanyKqleH+hTYgB2ENMp4ml1irCGnx7itNzj2EqwxZSH7XcMWsi/cwBzLU1iJ6Dpce6 hXcyMEmYv9ipSuDRc7eWslZDCqNk899GApwTlmutYGKixRWpasHaLc1DC1dMMljaBjm9 sabe498H+HxY2Fd6yY8zfvHDcDIL7515bNdV+JKNpfo8XGhxzN/UJAcsiznwdY7GOUu2 Dqfbi0pk55mI9kR1DSRTWmwm/7TuHSEohB+Vb+nUtVBw2k6YW6La60oflr6zudv0NHZZ fgkQ== X-Received: by 10.68.224.195 with SMTP id re3mr5030294pbc.93.1390441703530; Wed, 22 Jan 2014 17:48:23 -0800 (PST) Received: from [192.168.2.250] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id yi8sm54988524pab.16.2014.01.22.17.48.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jan 2014 17:48:22 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F6E59A9B-A063-4428-8333-C5C53C95534D" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Douglas Otis In-Reply-To: <20140122222616.GN1271@mx1.yitter.info> Date: Wed, 22 Jan 2014 17:48:20 -0800 Message-Id: References: <20140122222616.GN1271@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1827) Cc: DNSSD Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 23 Jan 2014 01:48:27 -0000 --Apple-Mail=_F6E59A9B-A063-4428-8333-C5C53C95534D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Andrew, Thank you for your effort but this seems headed in the wrong direction = although there are a few areas that should be improved in mDNS. Before = going into that, the basis of your MI profile seems like a good place to = start about why this approach seems wrong. The MI profile has three rules: 1. If the label is made entirely of LDH code points, then the label MUST be an LDH label. [ Simply refer to a hostname in compliance with RFC1123 section 2.1. ]=20= 2. All LDH code points MUST be folded to lower case. [ This requirement is well beyond = https://tools.ietf.org/html/rfc1123#section-2.1. A method used to = enhance transactional security is to modify query case which DNS handles = well without issue??? ] 3. If the label contains any other code point, then the label MUST be a well-formed U-label. [ IDNA2008 clarifies the need to avoid code points that are neither = PROTOCOL-VALID or CONTEXTUAL RULE REQUIRED. This requirement is not = reflected in an ambiguous U-Label reference. See: = http://tools.ietf.org/html/rfc5894#section-7.2.3 which goes beyond what = http://tools.ietf.org/html/rfc5198 required. It even seems mDNS servers might treat IDNA2008 code-point violations as = name collisions to force renaming. The underlying goal is to ensure an idempotent result. Use of Rbridges = http://tools.ietf.org/search/rfc6325 would be a superior means to = transparently extend mDNS requiring far less intervention. As network = video content increases, spanning-tree constraints cause unfortunate = bottlenecks that operates at the IP layer not well suited for IPv6. As mDNS RFC6762 points out, this is not the only link-local protocol = making use of UTF-8. LLMNR http://tools.ietf.org/html/rfc4795 has not = been updated to reflect current implementations however. See: = http://download.microsoft.com/download/9/5/E/95EF66AF-9026-4BB0-A41D-A4F81= 802D92C/%5BMS-LLMNRP%5D.pdf This document makes an inaccurate statement = that ignores RFC1123 Section 3.1.5 in their modification as follows: =20 ,--- [RFC4795] does not specify whether names in queries are to be sent in = UTF-8 [RFC3629] or Punycode [RFC3492]. In this LLMNR profile, a sender = MUST send queries in UTF-8, not Punycode. '--- At least http://tools.ietf.org/html/draft-sekar-dns-llq-01 takes an = extra step to call out an extension to permit use of UTF-8 instance = names defined for mDNS within DNS. BTW, why is this document excluded = from those developed by the dnssd group? It is called out in = draft-cheshire-mdnsext-hybrid. =20 Perhaps mDNS RFC6762 should reference IDNA2008 described in RFC5891 = instead of the older RFC5198. This might better fix some of these = issues the MI profile misses, especially with reference to uppercase = code points.=20 It seems attempts to make instance names compliant with host names = defeats the intent to make environments normally lacking DNS services = user friendly. mDNS is not DNS nor should protocols attempt to use mDNS = and DNS interchangeably without a directed discovery process. It is not = healthy to use URLs found lying about. :^) Regards, Douglas Otis On Jan 22, 2014, at 2:26 PM, Andrew Sullivan = wrote: > Dear colleagues, >=20 > At the last meeting, there was a request that I adapt the draft I > presented in order to get rid of the solution proposal (work we're not > chartered to undertake), and extract just the motivation or > requirements bit. I think I've done that with > draft-sullivan-dnssd-mdns-dns-interop-00. I hereby solicit review. >=20 > Best regards, >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_F6E59A9B-A063-4428-8333-C5C53C95534D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = Andrew,

Thank you for your effort but this seems = headed in the wrong direction although there are a few areas that should = be improved in mDNS.  Before going into that, the basis of your MI = profile seems like a good place to start about why this approach seems = wrong.

The MI profile has three = rules:

   1.  If the label is = made entirely of LDH code points, then the label
    =    MUST be an LDH label.

[ Simply = refer to a hostname in compliance with RFC1123 section 2.1. = ] 

   2.  All LDH code = points MUST be folded to lower case.

[ This = requirement is well beyond https://tools.iet= f.org/html/rfc1123#section-2.1.  A method used to enhance = transactional security is to modify query case which DNS handles well = without issue??? ]

   3.  If the = label contains any other code point, then the label = MUST
       be a well-formed = U-label.

[ IDNA2008 clarifies the need to = avoid code points that are neither PROTOCOL-VALID or CONTEXTUAL RULE = REQUIRED.  This requirement is not reflected in an ambiguous = U-Label reference.  See: http://tools.iet= f.org/html/rfc5894#section-7.2.3 which goes beyond what http://tools.ietf.org/html/rfc= 5198 required.

It even seems mDNS = servers might treat IDNA2008 code-point violations as name collisions to = force renaming.

The underlying goal is to = ensure an idempotent result. Use of Rbridges http://tools.ietf.org/search= /rfc6325 would be a superior means to transparently extend mDNS = requiring far less intervention.  As network video content = increases, spanning-tree constraints cause unfortunate bottlenecks that = operates at the IP layer not well suited for = IPv6.

As mDNS RFC6762 points out, = this is not the only link-local protocol making use of UTF-8. =  LLMNR http://tools.ietf.org/html/rfc= 4795 has not been updated to reflect current implementations = however. See: http://download.microsoft.com/download/9/= 5/E/95EF66AF-9026-4BB0-A41D-A4F81802D92C/%5BMS-LLMNRP%5D.pdf  = This document makes an inaccurate statement that ignores RFC1123 Section = 3.1.5 in their modification as follows: =  
,---
[RFC4795] does not specify whether names in queries are to = be sent in UTF-8 [RFC3629] = or Punycode [RFC3492]. In = this LLMNR profile, a sender MUST send queries in UTF-8, not = Punycode.
'---

At least http://tools.ie= tf.org/html/draft-sekar-dns-llq-01 takes an extra step to call = out an extension to permit use of UTF-8 instance names defined for mDNS = within DNS.  BTW, why is this document excluded from those = developed by the dnssd group?  It is called out in draft= -cheshire-mdnsext-hybrid.  

Perhaps = mDNS RFC6762 should = reference IDNA2008 described in RFC5891 instead of = the older RFC5198. =  This might better fix some of these issues the MI profile misses, = especially with reference to uppercase code = points. 

It seems attempts to make = instance names compliant with host names defeats the intent to make = environments normally lacking DNS services user friendly.  mDNS is = not DNS nor should protocols attempt to use mDNS and DNS interchangeably = without a directed discovery process.  It is not healthy to use = URLs found lying about. = :^)

Regards,
Douglas = Otis

On Jan 22, 2014, at 2:26 PM, Andrew = Sullivan <ajs@anvilwalrusden.com> = wrote:

Dear colleagues,

At the = last meeting, there was a request that I adapt the draft I
presented = in order to get rid of the solution proposal (work we're = not
chartered to undertake), and extract just the motivation = or
requirements bit.  I think I've done that = with
draft-sullivan-dnssd-mdns-dns-interop-00.  I hereby solicit = review.

Best regards,

A

-- 
Andrew = Sullivan
ajs@anvilwalrusden.com
_____= __________________________________________
dnssd mailing = list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
<= /blockquote>
= --Apple-Mail=_F6E59A9B-A063-4428-8333-C5C53C95534D-- From ajs@anvilwalrusden.com Wed Jan 22 19:25: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 2B9321A01A6 for ; Wed, 22 Jan 2014 19:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 2OS6J7ZblRs5 for ; Wed, 22 Jan 2014 19:25:56 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id EBBA01A0144 for ; Wed, 22 Jan 2014 19:25:55 -0800 (PST) Received: from mx1.yitter.info (unknown [12.53.193.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id DC9028A031 for ; Thu, 23 Jan 2014 03:25:54 +0000 (UTC) Date: Wed, 22 Jan 2014 22:25:53 -0500 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20140123032553.GC1580@mx1.yitter.info> References: <20140122222616.GN1271@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 23 Jan 2014 03:25:57 -0000 Hi Doug, On Wed, Jan 22, 2014 at 05:48:20PM -0800, Douglas Otis wrote: > > mDNS. Before going into that, the basis of your MI profile seems Why are we discussing the miprofile draft? The _whole point_ of this new draft is to avoid discussing a solution, because the WG isn't chartered to come up with one. > services user friendly. mDNS is not DNS nor should protocols > attempt to use mDNS and DNS interchangeably without a directed > discovery process. I _thought_ the draft as written made clear that this is exactly the problem: Users of applications are, of course, frequently unconcerned with (not to say oblivious to) the name-resolution system(s) in service at any given moment, and are inclined simply to use the same names in different contexts. As a result, the same string might be tried as a name using different name resolution technologies. In my opinion at least, that is the problem we actually have that caused the formation of the WG, because people want DNS-SD over mDNS to work outside the link-local context and it doesn't today. If you think this is a problem not to be solved, then we may have a charter problem. A -- Andrew Sullivan ajs@anvilwalrusden.com From dengguangqing@cnnic.cn Wed Jan 22 19:42:58 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 3C54B1A00DD for ; Wed, 22 Jan 2014 19:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.335 X-Spam-Level: X-Spam-Status: No, score=-0.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_NEW_HELO_USER=2.099, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] 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 58FEQuv5GXbB for ; Wed, 22 Jan 2014 19:42:51 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id B99611A00E7 for ; Wed, 22 Jan 2014 19:42:48 -0800 (PST) X-EYOUMAIL-SMTPAUTH: dengguangqing@cnnic.cn Received: from unknown127.0.0.1 (HELO user-think) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 23 Jan 2014 11:42:45 +0800 Date: Thu, 23 Jan 2014 11:42:49 +0800 From: "Guangqing Deng" To: Migault References: , <2014012115540802807511@cnnic.cn>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 1, 3, 52[cn] Mime-Version: 1.0 Message-ID: <20140123114249054035102@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart061220635831_=----" Cc: dnssd Subject: Re: [dnssd] draft-ietf-dnssd-requirements-00.txt: Requirements/Security Considerations 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, 23 Jan 2014 03:42:58 -0000 This is a multi-part message in MIME format. ------=_001_NextPart061220635831_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIERhbmllbCwgdGhyZWUgcGllY2VzIG9mIGluLWxpbmUgY29tbWVudHMgYmVnaW5uaW5nIHdp dGggW0d1YW5ncWluZyBEZW5nXSBhcmUgbGlzdGVkIGJlbG93LCBwbGVhc2UgcmVmZXIgdG8uDQoN Cg0KDQoNCkd1YW5ncWluZyBEZW5nDQpDTk5JQyANCg0KRnJvbTogRGFuaWVsIE1pZ2F1bHQNCkRh dGU6IDIwMTQtMDEtMjIgMTQ6NTUNClRvOiBHdWFuZ3FpbmcgRGVuZw0KQ0M6IGRuc3NkDQpTdWJq ZWN0OiBSZTogW2Ruc3NkXSBkcmFmdC1pZXRmLWRuc3NkLXJlcXVpcmVtZW50cy0wMC50eHQ6IFJl cXVpcmVtZW50cy9TZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KSGkgRGVuZywNCg0KVGhhbmsgeW91 IHZlcnkgbXVjaCBmb3IgdGhlIGNvbW1lbnRzIGFuZCBxdWVzdGlvbi4gSWYgSSB1bmRlcnN0YW5k DQpjb3JyZWN0bHkgeW91ciBwb2ludCwgeW91IGFyZSBzYXlpbmcgdGhhdCBETlNTRUMgYW5kIElQ c2VjIHBlcmZvcm1lZA0KaW4gYW4gYXV0aGVudGljYXRlZCB3YXkgbWF5IGFkZCB0byBtdWNoIG92 ZXJoZWFkIG9uIHRoZSBuZXR3b3JrIGZvciBhDQp0ZW1wb3Jhcnkgc2VydmljZS4gVGhpcyBtYXkg YmUgdHJ1ZSBvbiB0d28gYXNwZWN0czogMSkgSVBzZWMvRE5TU0VDDQphZGRzIGNvbmZpZ3VyYXRp b25zLCBvciBlcXVpdmFsZW50IG1lY2hhbmlzbXMgdG8gaGF2ZSBhIHRydXN0IGFuY2hvcg0KMikg RE5TU0VDIC9JUHNlYyBhZGRzIG92ZXJoZWFkcyAodGhhdCBpcyBtb3JlIGJ5dGVzKS4NCg0KW0d1 YW5ncWluZyBEZW5nXSBleGFjdGx5Lg0KDQpJbiB0aGUgZHJhZnQgd2UgYXJlIG5vdCByZWFsbHkg Y29uY2VybmVkIGFib3V0IHRoZSBzZXJ2aWNlIEJVVCBzZXJ2aWNlDQpkaXNjb3ZlcnkgcHJvdG9j b2wuIE1vcmUgc3BlY2lmaWNhbGx5IHRoaXMgbWVhbnMgaG93IHlvdSBsZWFybiB5b3VyDQpwcmlu dGVyIGlzIGF0IElQIFhYWCB1c2luZyB0aGlzIGNvbmZpZ3VyYXRpb24sIG5vdCBob3cgeW91IGNv bm5lY3QgdG8NCnRoZSBwcmludGVyLg0KDQpbR3VhbmdxaW5nIERlbmddIHlvdSBhcmUgcmlnaHQs IGJ1dCBkaWZmZXJlbnQga2luZHMgb2Ygc2VydmljZXMgbWF5IGNhbGwgZm9yIGRpZmZlcmVudCAN CnNwZWNpZmljIHNlcnZpY2UgZGlzY292ZXJ5IHByb3RvY29scyBhbmQgdGh1cyBtYXliZSBkaWZm ZXJlbnQgc2VjdXJpdHkgcmVxdWlyZW1lbnRzLiBGb3IgdGhvc2Ugc28tY2FsbGVkDQp0ZW1wb3Jh cnkgc2VydmljZSwgbUROUyBtYXkgYmUgcHJlZmVycmVkOyB3aGlsZSBmb3IgcmVsYXRpdmVseSBz dGFibGUgc2VydmljZSAoc3VjaCBhcyBwcmludGluZyBzZXJ2aWNlKSwNCmVpdGhlciBtRE5TIG9y IHVuaWNhc3QgRE5TIGlzIE9LLiBBbmQgRE5TU0VDIGlzIGp1c3QgYXZhaWxhYmxlIGluICB1bmlj YXN0IEROUw0KYnV0IG5vdCBtRE5TIGF0IHRoZSBtb21lbnQsIHNvIHRoZSBzZWN1cml0eSByZXF1 aXJlbWVudCBtYXkgYmUgYWxzbyBkaWZmZXJlbnQuDQoNClRvIGJlIGhvbmVzdCBJIGFtIG5vdCBz dXJlIHdlIGhhdmUgY29uc2lkZXJlZCB0aGUgc3BlY2lmaWMgc2VydmljZSB5b3UNCmFyZSByZWZl cnJpbmcgdG8uIE1heWJlIHlvdSBjb3VsZCBzcGVjaWZ5IGJyaWVmbHkgdGhlIHNlcnZpY2UgYW5k DQpwb2ludCBvdXQgd2hhdCB3b3VsZCBib3RoZXIgdGhlIHNlcnZpY2UuDQoNCltHdWFuZ3Fpbmcg RGVuZ10gRnVuZGFtZW50YWxseSwgb25seSB0aG9zZSByZWxhdGl2ZWx5IHN0YWJsZSBzZXJ2aWNl IGlzIHN1aXRhYmxlIHRvIGJlIGRpc2NvdmVyZWQgdGhyb3VnaCBETlMtYmFzZWQgDQpkaXNjb3Zl cnkgcHJvdG9jb2w7IHdoaWxlIHdpdGggdGhlIGRldmVsb3BtZW50IG9mIG1vYmlsZSBJbnRlcm5l dCwgc29tZSB0ZW1wb3Jhcnkgc2VydmljZSBsaWtlIGZpbGUgKGluY2x1ZGluZyB2aWRlb3MsIG11 c2ljLCBpbWFnZXMgZXQgYWwuKSANCnNoYXJpbmcgYmVjb21lcyBtb3JlIGFuZCBtb3JlIHBvcHVs YXIgZXNwZWNpYWxseSBpbiB3aXJlbGVzcyBtZXNoIG5ldHdvcmsgbGlrZSA4MDIuMTEgbmV0d29y ay4gRm9yIGluc3RhbmNlLCBvbmUgbWF5IGhvcGUNCnRvIHNoYXJlIHNvbWUgaW1hZ2VzIG9yIGRv Y3VtZW50cyB0byBoZXIvaGlzIGNvbGxlYWd1ZXMgdGhyb3VnaCA4MDIuMTEgbmV0d29yayBpbiBh IHBhcnRpY3VsYXIgdGltZSBwZXJpb2QgKGZyb20gOSBhbSB0byAxMCBhbSwgZm9yIGluc3RhbmNl KQ0KZHVyaW5nIHdoaWNoIGFsbCBjb2xsZWFndWVzIGluIHRoZSBzYW1lIGNvbXBhbnkgY2FuIGRv d25sb2FkIHRoZSBmaWxlcy4gIFNvLCBiYXNpY2x5LCB0aGVyZSBtYXkgYmUgdHdvIGtpbmRzIG9m IHNlcnZpY2VzIGluIEROU1NEIFdHLCBvbmUgbWF5IA0KYmUgY2FsbGVkIGxvbmcgdGVybSAgc2Vy dmljZSAob3Igc3RhYmxlIHNlcnZpY2U/KSBhbmQgdGhlIG90aGVyIHNob3J0IHRlcm0gc2Vydmlj ZSAob3IgdGVtcG9yYXJ5IHNlcnZpY2U/KS4gVGhlIGZvcm1lciBtZWFucyB0aGUgc2VydmljZSB3 aWxsIGJlIA0KcHJvdmlkZWQgaW4gYSBsb25nIHRpbWUgcGVyaW9kIGFuZCB0aHVzIHRoZSBmcmVx dWVuY3kgb2YgcmVnaXN0ZXJyaW5nLCB1cGRhdGluZyBhbmQgcmV2b2tpbmcgdGhlIHNlY3VyaXR5 IGNyZWRlbnRpYWwgaXMgcmVsYXRpdmVseSBsb3cuIEFuZCBmdXJ0aGVyIHNvbWUgaGVhdnkgd2Vp Z2h0IA0Kc2VjdXJpdHkgdGVjaG5vbG9naWVzIHN1Y2ggYXMgSVBzZWMgYW5kIEROU1NFQyBjYW4g YmUgaW50cm9kdWNlZCB3aXRob3V0IHRvbyBtdWNoIGFkZGl0aW9uYWwgdHJhZmZpYy4gVGhlIGxh dHRlciBtZWFucyB0aGUgc2VydmljZSBpcyBqdXN0DQpwcm92aWRlZCBpbiBhIHNob3J0IHRpbWUg cGVyaW9kIGFuZCB0aHVzIHRoaXMga2luZCBvZiBzZXJ2aWNlIHNob3VsZCBiZSBkaXNjb3ZlcmVk IGFuZCByZXZva2VkIGluIGEgdGltZWx5IGZhc2hpb24gYnkgdGhlIHNlcnZpY2UgZGlzY292ZXJ5 IHByb3RvY29sIHByb3Bvc2VkIA0KYnkgdGhpcyBXRy4gSW4gdGhpcyBjaXJjdW1zdGFuY2UsIG1E TlMgYnV0IG5vdCB1bmljYXN0IEROUyBtYXkgYmUgbW9yZSBwcmVmZXJyZWQsIHdoaWNoIG1lYW5z IHRoYXQgdGhlIGNvcnJlc3BvbmRpbmcgc2VjdXJpdHkgdGVjaG5vbG9naWVzIGNhbiBiZSB1c2Vk IA0KZm9yIGRpc2NvdmVyaW5nIHRoZSBzaG9ydCB0ZXJtIHNlcnZpY2UgaXMgZGlmZmVyZW50IGZy b20gdGhhdCBmb3IgbG9uZyB0ZXJtIHNlcnZpY2UuIFNvIGl0IHNlZW1zIHRoYXQgZGlmZmVyZW50 IGtpbmRzIG9mIHNlcnZpY2VzIGxlYWQgdG8gZGlmZmVyZW50IHNlY3VyaXR5IHRlY2hub2xvZ2ll cywNCmRpZmZlcmVudCBhZGRpdGlvbmFsIHRyYWZmaWMgYW5kIHRodXMgbWF5YmUgZGlmZmVyZW50 IHNlY3VyaXR5IHJlcXVpcmVtZW50LCB0aG91Z2ggYm90aCBzZXJ2aWNlcyBjYW4gYmUgcmVwcmVz ZW50ZWQgYnkgdGhlIHNlcnZpY2UgaW5zdGFuY2UgbmFtZXMgd2l0aCBzYW1lIGZvcm1hdC4NClNv IG1heWJlIGl0IGlzIHRpbWUgdG8gZ2l2ZSBhIGV4cGxpY2l0IGRlZmluYXRpb24gdG8gdGhlIHNv LWNhbGxlZCBfc2VydmljZV8gaW4gdGhpcyBXRywgYnV0IGZpcnN0IHdlIHNob3VsZCBkZXRlcm1p bmUgd2hpY2gga2luZHMgb2Ygc2VydmljZXMgaXMgdGhpcyBXRyBpbnRlcmVzdGVkIGluLg0KQW5k IEkgc3RpbGwgZG8gbm90IGhhdmUgdHdvIG1vcmUgZm9ybWFsIGFuZCBjbGVhciBkZWZpbml0aW9u cyBmb3IgdGhlc2UgdHdvIGtpbmRzIG9mIHNlcnZpY2VzIHlldCBhdCB0aGUgbW9tZW50LCB0aG91 Z2ggSSBhbSB0cnlpbmcgdG8uDQoNCkkgZ3Vlc3MgdGhlIGFkZGl0aW9uYWwgb3ZlcmhlYWQgZGVw ZW5kcyBvbiBob3cgbG9uZyAidGVtcG9yYXJ5IiBpcywNCmFuZCB0byB3aGljaCBmcmVxdWVuY3kg dGhlIHNlcnZpY2UgaXMgdXAuIEkgd291bGQgYmUgaW50ZXJlc3RlZCB0bw0KaGF2ZSBtb3JlIGRl dGFpbHMgb24gdGhlIHNlcnZpY2UgeW91IGFyZSByZWZlcnJpbmcgdG8uDQoNCldoYXQgaXMgbm90 IHNvIGNsZWFyIHRvIG1lIGlzIHRoYXQgc2VjdXJpdHkgaXMgdGhlIGNhdXNlIG9mIHRoZQ0KcHJv YmxlbS4gTWF5YmUgdGhlIHByb2JsZW0gb2YgdXBkYXRpbmcgaW5mb3JtYXRpb24gaXMgZHVlIHRv IHRoZSBETlMNCmZvcm1hdCB1c2VkIHRvIGNhcnJ5IHRoZSBzZXJ2aWNlIGluZm9ybWF0aW9uLiBU aGUgRE5TIGZvcm1hdCBpbXBvc2VzIGENCm1vZGlmaWNhdGlvbiBpcyBlZmZpY2llbnQgYWZ0ZXIg VFRMIHNlY29uZHMgd2hpY2ggaXMgdGhlIG5lY2Vzc2FyeQ0KdGltZSBhbGwgY2FjaGVzIGV4cGly ZXMuIER1cmluZyB0aGVzZSBUVEwgc2Vjb25kcywgaWYgbm90IHByb3Blcmx5DQpjb25zaWRlcmVk LCB0aGV5IG1heSBiZSBzb21lIGluY29oZXJlbnQgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHNlcnZp Y2UuDQpBZ2FpbiwgYSBkZXNjcmlwdGlvbiBvZiB0aGUgc2VydmljZSBtYXkgY2xhcmlmeSB0aGlz Lg0KDQpUaGUgbmV4dCBwYXJhZ3JhcGhzIGF0dGVtcHQgdG8gZGVzY3JpYmUgdGhlIG92ZXJoZWFk IGR1ZSB0byB0aGUgdXNlIG9mDQpETlNTRUMgb3IgSVBzZWMuDQoNCldpdGggSVBzZWMsIGRldmlj ZXMgY291bGQgc2hhcmUgYSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkgb3IgYSBzcGVjaWZpYw0KY2Vy dGlmaWNhdGUuIFRoZSBzZXJ2aWNlIG1heSBiZSBjb25maWd1cmVkIHdpdGggdGhpcyBjZXJ0aWZp Y2F0ZSB3aGljaA0Kd291bGQgZW5hYmxlIHRvIGF1dGhlbnRpY2F0ZSB0byBwcm90ZWN0IHRoZSBt RE5TL0ROUyB0cmFuc2FjdGlvbnMgLiBPZg0KY291cnNlIGl0IG5lZWRzIGFuIGluaXRpYWwgY29u ZmlndXJhdGlvbi4gSUtFdjIgYWRkcyBhIDQgcGFja2V0DQpleGNoYW5nZSBvdmVyIGF0IGxlYXN0 IHRoZSBmaXJzdCBjb25uZWN0aW9uIGV2ZXJ5IGNvbm5lY3Rpb24uIEFzIGENCnJlc3VsdCBJS0V2 MiBpcyB0aGUgYWRkaXRpb25hbCB0cmFmZmljLg0KDQpXaXRoIHRoZSB1c2Ugb2YgRE5TU0VDIGFz IGEgY2VydGlmaWVkIGRhdGFiYXNlLCBlYWNoIGRldmljZSAvIHNlcnZpY2UNCm1heSBuZWVkIHRv IHJlZ2lzdGVyLiBBZ2FpbiwgdGhpcyBtYXkgcmVxdWlyZSB0aGUgRE5TIHRvIGF1dGhlbnRpY2F0 ZQ0KdGhlIGRldmljZXMuIGtleXMgYXNzb2NpYXRlZCB0byBkZXZpY2VzIG1heSBiZSBwcm92aXNp b25lZCB0byB0aGUgRE5TDQpzZXJ2ZXIuICBUaGVuIFNJRygwKSBjYW4gYmUgdXNlZCB0byBhdXRo ZW50aWNhdGUgdGhlIHVwZGF0ZSBvZiB0aGUNCnNlcnZpY2UuIFdpdGggRE5TU0VDIHlvdSBtYXkg aGF2ZSB0byByZW1vdmUgc2VjdXJpdHkgaW5mb3JtYXRpb25zDQooa2V5cykgaW4gdGhlIEROUywg YnV0IGV2ZW4gd2l0aG91dCBzZWN1cml0eSB5b3UgbWF5IGhhZCB0byByZW1vdmUgdGhlDQpjb25u ZWN0aXZpdHkgaW5mb3JsYXRpb24gKGxpa2UgSVAgYWRkcmVzZXMpLiBBcyBhIHJlc3VsdCBpdCBk b2VzIG5vdA0KYWRkIGFkZGl0aW9uYWwgZXhjaGFuZ2VzLCBidXQgbWFrZXMgbWVzc2FnZSBsYXJn ZXIuIElmIGRuc3NkIHVzZXMNCm1ETlMsIHRoYXQgaXMgbm90IGEgY2VudHJhbGl6ZWQgZGF0YWJh c2UsIHRoZW4gdGhlIHVzZSBvZiBETlNTRUMgZG9lcw0Kbm90IGFkZHMgZXhjaGFuZ2VzLCBidXQg bWFrZXMgbWVzc2FnZXMgbGFyZ2Vycy4NCg0KDQpCUiwNCkRhbmllbA0KDQoNCg0KDQpCUg0KRGFu aWVsDQoNCg0KDQpPbiBUdWUsIEphbiAyMSwgMjAxNCBhdCA4OjU0IEFNLCBHdWFuZ3FpbmcgRGVu ZyA8ZGVuZ2d1YW5ncWluZ0Bjbm5pYy5jbj4gd3JvdGU6DQo+IEhpLCBEYW5pZWwsIHNvIG1hbnkg ZGV0YWlscyBvbiBTU0QgcmVxdWlyZW1lbnRzIGFyZSBwcmVzZW50ZWQgaGVyZSwgd2hpY2gNCj4g aGVscHMgbWUgaGF2ZSBhIG1vcmUgZGVlcCB1bmRlcnN0YW5kaW5nIG9uIHRoaXMgaXNzdWUuIEl0 IGlzIHNhaWQgdGhhdCBJUHNlYw0KPiBhbmQgRE5TU0VDIGNhbiBiZSB1c2VkIHRvIGF1dGhlbnRp Y2F0ZSB0aGUgZGV2aWNlcyB0ZW5kaW5nIHRvIHByb3ZpZGUNCj4gc2VydmljZS4gV2hpbGUgb25l IHF1ZXN0aW9uIGlzIHRoYXQgdGhlIGRlcGxveW1lbnQgb2YgSVBzZWMgYW5kIEROU1NFQyBtYXkN Cj4gbGVhZCB0byBoaWdobHkgaW5jcmVhc2VkIHRyYWZmaWMgd2l0aGluIHRoZSBsb2NhbCBuZXR3 b3JrLiBBbmQgZm9yIHRob3NlDQo+IHRlbXBvcmFyeSBzZXJ2aWNlIHByb3ZpZGVycyAod2hpY2gg anVzdCBwcm92aWRlIHNlcnZpY2VzIGluIGEgc2hvcnQgdGltZSBpbg0KPiBhIG1lc2ggd2lyZWxl c3MgbmV0d29yaywgZm9yIGluc3RhbmNlKSwgdGhlIHByb2Nlc3Mgb2YgdGVtcG9yYXJ5IHNlcnZp Y2UNCj4gcHJvdmlkZXIgcmVnaXN0ZXJpbmcgb24gRE5TU0VDIHN5c3RlbSBtYXkgYmUgdG9vIGxv bmcgY29tcGFyZWQgd2l0aCB0aGUNCj4gcmVsYXRpdmVseSBzaG9ydCBzZXJ2aW5nIHBlcmlvZC4g QWxzbywgdGhlIEROU1NFQyBzeXN0ZW0gaGFzIHRvIHJldm9rZSB0aGUNCj4gcHVibGljIGtleSBv ZiB0aGUgdGVtcG9yYXJ5IHNlcnZpY2UgcHJvdmlkZXIgaWYgaXQgaGFzIGdvbmUgb2ZmLWxpbmUu IFNvIGl0DQo+IHNlZW1zIHRoYXQgd2Ugc2hvdWxkIGNsYXJpZnkgdGhlIHNlcnZpY2UgbWVudGlv bmVkIGluIHRoaXMgV0cuIElzIHRoZQ0KPiBzZXJ2aWNlIG1lbnRpb25lZCBpbiB0aGlzIFdHIG1l YW5zIGEgbG9uZy10ZXJtIG9uZSBvciBzaG9ydC10ZXJtIG9uZSBvcg0KPiBib3RoPw0KPg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBHdWFuZ3FpbmcgRGVuZw0KPiBDTk5J Qw0KPg0KPiBGcm9tOiBEYW5pZWwgTWlnYXVsdA0KPiBEYXRlOiAyMDE0LTAxLTE5IDE2OjAyDQo+ IFRvOiBkbnNzZA0KPiBDQzogVGltIENob3duOyBLZXJyeSBMeW5uDQo+IFN1YmplY3Q6IFtkbnNz ZF0gZHJhZnQtaWV0Zi1kbnNzZC1yZXF1aXJlbWVudHMtMDAudHh0OiBSZXF1aXJlbWVudHMvU2Vj dXJpdHkNCj4gQ29uc2lkZXJhdGlvbnMNCj4gSGkgRm9sa3MsDQo+DQo+IEhlcmUgYXJlIHNvbWUg YWRkaXRpb25hbCByZXF1aXJlbWVudHMgZm9yDQo+IGRyYWZ0LWlldGYtZG5zc2QtcmVxdWlyZW1l bnRzLTAwLnR4dCBhcyB3ZWxsIGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIHRoZQ0KPiBzZWN1cml0 eSBjb25zaWRlcmF0aW9uIHNlY3Rpb24uIFRoaXMgc2VjdGlvbiBoYXMgYmVlbiB1cGRhdGVkIHdp dGggVGltJ3MNCj4gY29tbWVudHMuDQo+DQo+IFlvdXIgYXJlIG1vcmUgdGhhbiB3ZWxjb21lIHRv IGNvbW1lbnQvY2xhcmlmeS9jaGFuZ2UgdGhlIHByb3Bvc2VkIHRleHQuIFdlDQo+IHdvdWxkIGFw cHJlY2lhdGUgeW91IHByb3ZpZGUgdGhlbSBieSBGcmlkYXkgSmFudWFyeSAyMyBzbyB0aGV5IGNh biBiZQ0KPiBjb25zaWRlcmVkIGZvciB0aGUgbmV4dCB2ZXJzaW9uLg0KPg0KPiBCZXN0IFJlZ2Fy ZHMsDQo+DQo+IERhbmllbA0KPg0KPiBUZXJtaW5vbG9neSBzZWN0aW9uOg0KPg0KPiBJIHRoaW5r IHdlIHNob3VsZCBhZGQgdGhlIGZvbGxvd2luZyB0ZXJtcy4gSSBhbSB1c2luZyB1c2VkIHRoZW0g aW4gdGhlDQo+IHJlbWFpbmluZyBvZiB0aGUgbWFpbC4gVGhleSBtYXkgYmUgY2hhbmdlZCBmb3Ig dGhlIGRyYWZ0Lg0KPg0KPiBtRE5TOiBtdWx0aWNhc3QgRE5TIGFzIGRlZmluZWQgaW4gW1JGQzY3 NjJdDQo+IFNTRDogU2NhbGFibGUgU2VydmljZSBEaXNjb3ZlcnkNCj4gU0QgRE5TLUJhc2VkIFNl cnZpY2UgRGlzY292ZXJ5IFtSRkM2NzYzXQ0KPg0KPiBSZXF1aXJlbWVudHMgc2VjdGlvbjoNCj4N Cj4gSSBzdWdnZXN0IGFkZGluZyBvciBjb21wbGV0ZSBleGlzdGluZyByZXF1aXJlbWVudHMgd2l0 aCB0aGUgZm9sbG93aW5nIG9uZXM6DQo+DQo+IFNTRCBTSE9VTEQgYmUgZGVzaWduZWQgZm9yIGJv dGggRE5TIGFuZCBtRE5TIHdvcmtpbmcgaW4gYSBjb29wZXJhdGl2ZSB3YXkuDQo+IE1vcmUgc3Bl Y2lmaWNhbGx5LCBpdCBTSE9VTEQgY29uc2lkZXIgaW50ZXJhY3Rpb24gYmV0d2VlbiBETlMgYW5k IG1ETlMuDQo+DQo+IFNTRCBTSE9VTEQgYmUgYWJsZSB0byBiZSBwZXJmb3JtZWQgYnkgY2xpZW50 IG9ubHkgdXNpbmcgRE5TIGFuZCB1bmljYXN0IHRvDQo+IGF2b2lkIG11bHRpcGxlIG11bHRpY2Fz dCBtZXNzYWdlcy4NCj4NCj4gU1NEIFNIT1VMRCB3b3JrIHdpdGggZXhpc3RpbmcgRE5TLUJhc2Vk IFNlcnZpY2UgRGlzY292ZXJ5IG92ZXIgbUROUyBhbmQNCj4gU0hPVUxEIE5PVCBicmVhayBhbnkg b3RoZXIgZGlzY292ZXJ5IHByb3RvY29scy4NCj4gQXMgc3BlY2lmaWVkIGluIHRoZSBjaGFydGVy IFtodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvZG5zc2QvY2hhcnRlci9dDQo+ICJUaGUg V0cgd2lsbCBjb25zaWRlciB0aGUgdHJhZGVvZmZzIGJldHdlZW4gcmV1c2luZy9leHRlbmRpbmcg ZXhpc3RpbmcNCj4gcHJvdG9jb2xzIGFuZCBkZXZlbG9waW5nIGVudGlyZWx5IG5ldyBvbmVzLiBJ dCBpcyBoaWdobHkgZGVzaXJhYmxlDQo+IHRoYXQgYW55IG5ldyBzb2x1dGlvbiBpcyBiYWNrd2Fy ZGx5IGNvbXBhdGlibGUgd2l0aCBleGlzdGluZyBETlMtU0QvbUROUw0KPiBkZXBsb3ltZW50cy4g QW55IHNvbHV0aW9uIGRldmVsb3BlZCBieSB0aGUgZG5zc2QgV0cgbXVzdCBub3QgY29uZmxpY3QN Cj4gb3IgaW50ZXJmZXJlIHdpdGggdGhlIG9wZXJhdGlvbiBvZiBvdGhlciB6ZXJvLWNvbmZpZ3Vy YXRpb24gc2VydmljZSBhbmQNCj4gbmFtaW5nIHByb3RvY29scyBzdWNoIGFzIHVQblAgb3IgTExN TlIuIEludGVncmF0aW9uIHdpdGggc3VjaCBwcm90b2NvbHMNCj4gaXMgb3V0IG9mIHNjb3BlIGZv ciB0aGlzIFdHLiINCj4NCj4gYW5kDQo+DQo+ICJUbyBkb2N1bWVudCBjaGFsbGVuZ2VzIGFuZCBw cm9ibGVtcyBlbmNvdW50ZXJlZCBpbiB0aGUgY29leGlzdGVuY2UNCj4gb2YgemVybyBjb25maWd1 cmF0aW9uIGFuZCBnbG9iYWwgRE5TIG5hbWUgc2VydmljZXMgaW4gc3VjaA0KPiBtdWx0aS1saW5r IG5ldHdvcmtzLCBpbmNsdWRpbmcgY29uc2lkZXJhdGlvbiBvZiBib3RoIHRoZSBuYW1lDQo+IHJl c29sdXRpb24gbWVjaGFuaXNtIGFuZCB0aGUgbmFtZXNwYWNlLiINCj4NCj4NCj4gU1NEIFNIT1VM RCBjb25zaWRlciB0aGUgdXNlIG9mIGdsb2JhbGx5IHVuaXF1ZSBGUUROIHRoYXQgaXMgc3BlY2lm aWMgb2YgYQ0KPiBnaXZlbiBuZXR3b3JrIGluc3RlYWQgb2YgYSBkZWZhdWx0IGRvbWFpbiBuYW1l IGFzICIubG9jYWwiLiBTU0QgU0hPVUxEDQo+IHByb3ZpZGUgbWVhbnMgdG8gZGlzY292ZXIvYW5u b3VuY2UgdGhlIEZRRE4gYXNzb2NpYXRlZCB0byB0aGUgbmV0d29yay4gQQ0KPiBkZWZhdWx0IGFu ZCBjb21tb24gRlFETiAtIGxpa2UgIi5sb2NhbC4iIGNvdWxkIGJlIHVzZWQgb25seSB3aGVuIHRo ZQ0KPiBzcGVjaWZpYyBGUUROIG9mIHRoZSBuZXR3b3JrIGhhcyBub3QgYmVlbiBkZXRlcm1pbmVk LiBGdXJ0aGVybW9yZSwgaW4gb3JkZXINCj4gdG8gZWFzZSBpbnRlcm9wZXJhdGlvbiB3aXRoIERO UyB0aGUgZG9tYWluIG5hbWUgU0hPVUxEIGZvbGxvdyBETlMtY29tcGF0aWJsZQ0KPiBlbmNvZGlu ZyAoaS5lIGFzY2lpIG9yIHB1bnljb2RlKS4NCj4NCj4NCj4gU1NEIFNIT1VMRCBiZSBhYmxlIHRv IHRha2UgYWR2YW50YWdlIG9mIG5ldHdvcmsgY29uZmlndXJhdGlvbnMgKERIQ1AvUkEpDQo+IHBy b3RvY29sLiBJZiBpdCBpcyBjbGVhciB0aGF0IFNTRCBhbmQgRE5TIFNIT1VMRCBiZSBhYmxlIHRv IHdvcmsgdG9nZXRoZXIsDQo+IERIQ1AgbWF5IGFsc28gYmUgdXNlZCB0byBhbm5vdW5jZSBuZWNl c3NhcnkgaW5mb3JtYXRpb24gZm9yIHRoZSBuZXR3b3JrIHN1Y2gNCj4gYXMgaXRzIGFzc29jaWF0 ZWQgRlFETiAodXNpbmcgREhDUCBEb21haW4gU2VhcmNoIC8gREhDUCBEb21haW4gb3B0aW9uIC8g SVB2Ng0KPiBSQSBbUkZDNjEwNl0pLCB0aGUgaW50ZXJmYWNlIHRvIHJlZ2lzdGVyIEZRRE5zLi4u IFRoaXMgTUFZIGZvciBleGFtcGxlDQo+IGNvbXBsZW1lbnQgb3IgYXZvaWQgdGhlIHVzZSBvZiB0 aGUgc3BlY2lmaWMNCj4gYi9kYi9yL2RyL2xiLmRucy1zZC5fdWRwLjxkb21haW4+IG9yIGVxdWl2 YWxlbnQgcXVlcmllcy4NCj4NCj4NCj4gU1NEIFNIT1VMRCBiZSBhYmxlIHRvIGFubm91bmNlIHRo ZSBzY29wZSBTZXJ2aWNlIERpc2NvdmVyeSBpbmZvcm1hdGlvbnMgYXJlDQo+IGV4cGVjdGVkIHRv IGJlIGFjY2Vzc2VkIG9yIG11bHRpY2FzdGVkLiBUaGlzIHJlcXVpcmVzIHNvbWV0aGluZyBsaWtl IGENCj4gInNjb3BlIiBkaXNjb3ZlcnkgcHJvdG9jb2wuDQo+DQo+DQo+IFNlY3VyaXR5IENvbnNp ZGVyYXRpb24gc2VjdGlvbg0KPg0KPiBIZXJlIGlzIHNvbWUgdGV4dCBJIHByb3Bvc2UuIENvbW1l bnRzIGFyZSBtb3JlIHRoZW4gd2VsY29tZSEgSSBob3BlIHRoYXQgd2UNCj4gd2lsbCBiZSBhYmxl IHRvIGZpeCB0aGlzIHNlY3Rpb24gZHVyaW5nIHRoZSBuZXh0IG1lZXRpbmcuDQo+DQo+DQo+IDEu IFNjYWxhYmxlIEROUyBTZXJ2aWNlIGlzIG5vdCBhbiBleHRlbnNpb24gb2YgU0QgaW4gdGVybSBv ZiBzZWN1cml0eQ0KPg0KPiBTY2FsYWJsZSBETlMtQmFzZWQgU2VydmljZSBEaXNjb3ZlcnkgY2Fu IGhhcmRseSByZWx5IG9uIHRoZSBzZWN1cml0eQ0KPiBjb25zaWRlcmF0aW9ucyBkZWZpbmVkIGZv ciBETlMtQmFzZWQgU2VydmljZSBEaXNjb3ZlcnkgW1JGQzY3NjNdLg0KPiBDb25zaWRlcmluZyAi U2NhbGFiaWxpdHkiIHJlcXVpcmVzIG5ldyBzZWN1cml0eSBwcmFjdGljZXMgdGhhdCBhcmUgZGVm aW5lcw0KPiBpbiB0aGlzIGRvY3VtZW50Lg0KPg0KPiBETlMtQmFzZWQgU2VydmljZSBEaXNjb3Zl cnkgW1JGQzY3NjNdIGhhcyBiZWVuIGRlc2lnbmVkIHNvIHRoYXQgYSBkZXZpY2UgY2FuDQo+IGFu bm91bmNlIGEgc2VydmljZSB0byB0aGUgb3RoZXIgZGV2aWNlcyBvZiB0aGUgbmV0d29yay4gQWx0 aG91Z2ggRE5TIG9yIG1ETlMNCj4gY2FuIGJlIHVzZWQgZm9yIFNELCBTRCBoYXMgYmVlbiBtb3N0 bHkgdGhvdWdodCB0byB3b3JrIG92ZXIgbUROUyB0byBhdm9pZA0KPiBETlMgem9uZSBtYW5hZ2Vt ZW50IGFuZCB0byBoYW5kbGUgVVRGOCBuYW1lcyBmb3IgdGhlIGVuZCB1c2VycyBldmVuIGluIHRo ZQ0KPiBkb21haW4gcGFydCBvZiB0aGUgSW5zdGFuY2UgU2VydmljZSBOYW1lLiBBcyBhIHJlc3Vs dCBTRCcgc2VjdXJpdHkNCj4gY29uc2lkZXJhdGlvbnMgcmVseSBvbiBtRE5TIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zLCBETlNTRUMgW1JGQzQwMzNdIGZvcg0KPiBhdXRoZW50aWNhdGlvbiBhbmQg c2VjdXJlIEROUyB1cGRhdGUgW1JGQzMwMDddIHRvIHNlY3VyZSBETlMgdXBkYXRlDQo+IFtSRkMy MTM2XS4gVGhlc2UgY29uc2lkZXJhdGlvbnMgYXJlIG5vdCBzdWZmaWNpZW50IGZvciBTU0QgYXMg ZXhwbGFpbmVkDQo+IGJlbG93Lg0KPg0KPiAgICAgLSBhKSBETlNTRUMgaXMgcHJvYmFibHkgdGhl IEROUyBleHRlbnNpb24gdGhhdCBNQVkgYmUgdXNlZCB0byBwcm92aWRlDQo+IGF1dGhlbnRpY2F0 aW9uIGFuZCBpbnRlZ3JpdHkgY2hlY2sgcHJvdGVjdGlvbi4gSG93ZXZlciwgYXV0aGVudGljYXRp b24gb3RoZXINCj4gdGhhbiBwcm9vZi1vZi1vd25lcnNoaXAgb3IgbGVhcC1vZi1mYWl0aCBzZWN1 cml0eSBtb2RlbCByZXF1aXJlcyB0cnVzdA0KPiBhbmNob3JzLiBUcnVzdCBhbmNob3IgTUFZIGJl IHByb3ZpZGVkIGJ5IHRoZSBnbG9iYWwgRE5TLCBidXQgdGhpcyBoYXMgbm90DQo+IGJlZW4gc3Bl Y2lmaWVkIGluIFNELiBTZWN0aW9uIDEwIG9mIFJGQzY3NjMgaWxsdXN0cmF0ZXMgaG93IHRvIHBv cHVsYXRlIHRoZQ0KPiBETlMgd2l0aCBpbmZvcm1hdGlvbiBidXQgY2xlYXJseSBzdGF0ZXMgdGhh dCBzdWNoIGludGVyYWN0aW9ucyBhcmUgb3V0IG9mDQo+IHNjb3BlIG9mIFJGQzY3NjMuIEludGVy YWN0aW9ucyBiZXR3ZWVuIFNTRCBhbmQgRE5TIGNhbm5vdCBiZSBzcGVjaWZpZWQgaW4gYW4NCj4g aWxsdXN0cmF0aXZlIHNlY3Rpb24uDQo+DQo+ICAgICAtIGIpIFNpbWlsYXJseSwgRE5TIHVwZGF0 ZXMgYXJlIHVzZWQgYnkgU0QgdG8gY29vcGVyYXRlIHdpdGggRE5TLiBUaGVzZQ0KPiBpbnRlcmFj dGlvbnMgYXJlIGxlZnQgYXMgaWxsdXN0cmF0aXZlIGluIFJGQzY3NjMsIHdoaWNoIGlzIG5vdCBz dWZmaWNpZW50DQo+IGZvciBTU0QuDQo+DQo+ICAgICAtYykgbUROUyBzZWN1cml0eSBjb25zaWRl cmF0aW9ucyBhcmUgbm90IHN1ZmZpY2llbnQgZm9yIFNTRC4gQXQgZmlyc3QsDQo+IG1ETlMgcmVx dWlyZXMgY29vcGVyYXRpdmUgZGV2aWNlcy4gSWYgY29vcGVyYXRpdmUgZGV2aWNlcyBpcyBhIHJl YXNvbmFibGUNCj4gYXNzdW1wdGlvbiBpbiBhIG9uZSBob3AgbmV0d29yayBzdWNoIGFzIG1vc3Qg aG9tZSBuZXR3b3JrcywgdGhpcyBhc3N1bXB0aW9uDQo+IGNhbm5vdCBiZSBtYWRlIGZvciBsYXJn ZXIgbmV0d29ya3MsIHN1Y2ggYXMgY29ycG9yYXRlIG5ldHdvcmtzIGZvciBleGFtcGxlLg0KPg0K PiAgICAgICAgSW4gY2FzZSBhbGwgZGV2aWNlcyBjYW5ub3QgdHJ1c3QgZWFjaCBvdGhlciwgU0Qg Y29uc2lkZXJzIHRoZSB1c2Ugb2YNCj4gSVBzZWMgb3IgRE5TU0VDLiBIb3cgdGhlc2UgcHJvdG9j b2xzIGFyZSB1c2VkIGlzIG5vdCBmdWxseSBkZXNjcmliZWQgaW4NCj4gUkZDNjc2MiBhbmQgU0hP VUxEIGJlIGF0IGxlYXN0IGRvY3VtZW50ZWQgZm9yIFNTRC4gTW9yZSBzcGVjaWZpY2FsbHksIERO U1NFQw0KPiBjYW4gYmUgdXNlZCB3aXRoIGRpZmZlcmVudCBzZWN1cml0eSBtb2RlbHMuIEF1dGhl bnRpY2F0aW9uIG9mIHRoZSBkZXZpY2VzDQo+IG1heSByZXF1aXJlIGEgY2hhaW4gb2YgdHJ1c3Qg YW5kIGludGVyYWN0aW9uIHdpdGggRE5TLiBBbHRlcm5hdGl2ZWx5DQo+IGF1dGhlbnRpY2F0aW9u IG1heSByZWx5IG9uIGRldmljZXMgY29uZmlndXJlZCB3aXRoIGNlcnRpZmljYXRlcy4gSW4gdGhl DQo+IGFic2VuY2Ugb2Ygc3VjaCBjZXJ0aWZpY2F0ZXMgb3IgY2hhaW4gb2YgdHJ1c3QsIGEgcHJv b2Ytb2Ytb3duZXJzaGlwIHdpdGgNCj4gZGV2aWNlJ3MgcmVwdXRhdGlvbiBtYXkgYmUgY29uc2lk ZXJlZC4NCj4NCj4gICAgICAgbUROUyBjb25zaWRlcnMgdGhlIHVzZSBvZiBETlNTRUMgdG8gZGlm ZmVyZW50aWF0ZSByZXNwb25zZXMgZnJvbSB0aGUNCj4gZ2xvYmFsIEROUyBhbmQgbUROUyB0aGF0 IGFkZHJlc3NlcyBhIGxvY2FsIHNjb3BlLiBETlNTRUMgbWF5IG5vdCBiZSB0aGUNCj4gYXBwcm9w cmlhdGVkIHNvbHV0aW9uIGZvciBTU0QgYXMgRE5TU0VDIG1heSBub3QgYmUgZGVwbG95ZWQgZm9y IHRoZSBnbG9iYWwNCj4gRE5TIG9yIGZvciBtRE5TIHdoaWNoIHdvdWxkIG1ha2UgZGlzdGluY3Rp b24gaW1wb3NzaWJsZS4gQXMgc3VnZ2VzdGVkIGJ5DQo+IFJGQzY3NjEsIHRoZSB1c2Ugb2YgIi5s b2NhbCIgdG8gc3BlY2lmeSBtRE5TIG1heSBiZSBtb3JlIGFwcHJvcHJpYXRlZC4NCj4NCj4gICAg ICAgbUROUyBhbHNvIHJhaXNlcyB0aGUgaXNzdWUgb2YgcmVsYXRpdmUgZG9tYWluIG5hbWVzIChl eGFtcGxlLmNvbSkgdGhhdA0KPiBtYXkgYmUgc29sdmVkIGFzIGV4YW1wbGUuY29tLmxvY2FsLiBv ciBhcyBleGFtcGxlLmNvbS5zZWFyY2gtZG9tYWluLiBUaGlzDQo+IGlzc3VlIGJlY29tZXMgbW9y ZSBjb21wbGV4IHdpdGggU1NELiBGb3IgU0QgdGhlcmUgaXMgbGl0dGxlIGFtYmlndWl0eSB3aXRo DQo+IHRoZSBtZWFuaW5nIG9mICIubG9jYWwiLiBJdCBpcyBhIHNpbmdsZSBsaW5rLCB1c3VhbGx5 IGEgc2luZ2xlIG5ldHdvcmsuIFNTRA0KPiBjb25zaWRlcnMgbXVsdGlwbGUgbGlua3MgYW5kIGFz IHN1Y2ggbXVsdGlwbGUgIi5sb2NhbCIgYW5kIG11bHRpcGxlDQo+IGRpZmZlcmVudCBzZWFyY2gg ZG9tYWluLiBUaHVzIHRoZSBxdWVzdGlvbiBtYXkgYmUgd2hpY2ggbGluaydzIHNlYXJjaCBkb21h aW4NCj4gaXMgdG8gYmUgY29uc2lkZXJlZC4NCj4NCj4gICAgICAgbUROUyBjb25zaWRlcnMgdmVy eSBmZXcgaW50ZXJhY3Rpb25zIHdpdGggRE5TLiBUaGUgb25seSBtZW50aW9uZWQgY2FzZQ0KPiBp cyB3aGVuIGEgZ2xvYmFsIEROUyByZXNvbHV0aW9uIGlzIHBlcmZvcm1lZCB1c2luZyBtRE5TLiBt RE5TIGluZGljYXRlcyBob3cNCj4gdG8gdHJlYXQgcmVsYXRpdmUgZG9tYWlucy4gSW50ZXJhY3Rp b24gYmV0d2VlbiBtRE5TIGFuZCBETlMgd2FzIG5vdCBzbw0KPiBuZWNlc3NhcnkgYXMgd2l0aCBv bmUgaG9wIG5ldHdvcmsgdGhlcmUgaXMgYSBjbGVhciBzZXBhcmF0aW9uIGJldHdlZW4gdGhlDQo+ IGxvY2FsIGFuZCBub24gbG9jYWwgKEludGVybmV0KSBuZXR3b3JrLiBXaXRoIG11bHRpcGxlIG5l dHdvcmtzLCB0aGUgZnJvbnRpZXINCj4gYmV0d2VlbiBsb2NhbCBhbmQgbm9uIGxvY2FsIGJlY29t ZXMgbXVjaCB1bmRlZmluZWQuIEFzIHJlc3VsdCB3aGV0aGVyIG5hbWluZw0KPiByZXNvbHV0aW9u IGlzIGxvY2FsIChtRE5TKSBvciBnbG9iYWwgKEROUykgaXMgbm90IG9idmlvdXMuIFRoaXMgaXMg d2h5IFNTRA0KPiBuZWVkcyB0byBzcGVjaWZ5IGludGVyYWN0aW9ucyBiZXR3ZWVuIEROUyBhbmQg bUROUyB3aGVyZWFzIEROUy1CYXNlZCBTZXJ2aWNlDQo+IERpc2NvdmVyeSBbUkZDNjc2M10gZG9l cyBub3QuIEFzIGEgcmVzdWx0IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciBTU0QNCj4gY29u c2lkZXJzIDEpIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIG9mIFNTRCBvdmVyIG1ETlMsIDIpIHNl Y3VyaXR5DQo+IGNvbnNpZGVyYXRpb25zIG9mIFNTRCBvdmVyIEROUyBhbmQgMykgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMgb24NCj4gaW50ZXJhY3Rpb25zIGJldHdlZW4gRE5TIGFuZCBtRE5TLg0K Pg0KPg0KPiBBcyBhIHJlc3VsdCwgc2VjdXJpdHkgYXNzdW1wdGlvbiBvZiBETlMtQmFzZWQgU2Vy dmljZSBEaXNjb3ZlcnkgW1JGQzY3NjNdDQo+IGFyZSBub3QgYW55IG1vcmUgdmFsaWQgZm9yIFNj YWxhYmxlIEROUy1CYXNlZCBTZXJ2aWNlIERpc2NvdmVyeS4NCj4NCj4gMSkgUHJpdmFjeSBwcm90 ZWN0aW9uDQo+DQo+IEluZm9ybWF0aW9uIHByb3ZpZGVkIGJ5IFNTRCBtYXkgY29udGFpbiBwcml2 YXRlIGluZm9ybWF0aW9uIHRoYXQgaXMgbm90DQo+IGV4cGVjdGVkIHRvIGdvIG91dHNpZGUgIHRo ZSBzcGVjaWZpZWQgc2NvcGUuDQo+DQo+IFNlcnZpY2UgRGlzY292ZXJ5IGNhcnJ5IGluZm9ybWF0 aW9uIGFib3V0IHRoZSB0eXBlIG9mIGRldmljZXMgYXZhaWxhYmxlIGluDQo+IHlvdXIgbmV0d29y aywgdGhlIHNvZnR3YXJlIHZlcnNpb24sIHRoZWlyIGxvY2F0aW9uIGJvdGggcGh5c2ljYWwgbGlr ZSBmbG9vcg0KPiBhcyB3ZWxsIGFzIG5ldHdvcmtpbmcgLSBsaWtlIHRoZSBJUCBhZGRyZXNzLiBB bGwgdGhlc2UgcGllY2VzIG9mIGluZm9ybWF0aW9uDQo+IG1heSBiZSB1c2VmdWwgZm9yIGFuIGlu dHJ1ZGVyLiBEZXZpY2UgYW5kIHNvZnR3YXJlIGluZm9ybWF0aW9uIGFyZSB1c2VmdWwgdG8NCj4g aWRlbnRpZnkgdnVsbmVyYWJpbGl0aWVzLCBhbmQgbG9jYXRpb24gaW5mb3JtYXRpb24gYXJlIHVz ZWZ1bCB0byBsb2NhdGUgdGhlDQo+IHRhcmdldCwgbmFtZXMgbWF5IGFsc28gaW5jbHVkZSBpbmZv cm1hdGlvbiB0aGF0IG1heSBiZSB1c2VmdWwgdG8gZGVmaW5lIGENCj4gc3BlY2lmaWMgdGFyZ2V0 IC0gbGlrZSAiUGVyc29uYWwgQ0VPIFByaW50ZXIiLiBGb3IgdGhlc2UgcmVhc29ucywgb25lIGlz DQo+IHdpbGxpbmcgdG8gbGltaXQgdGhlIHNjb3BlIHRoZXNlIHBpZWNlcyBvZiBpbmZvcm1hdGlv bi4NCj4NCj4gICAgIGEpIEluZm9ybWF0aW9ucyBzcHJlYWRpbmcgbWF5IGJlIGxpbWl0ZWQgYmFz ZWQgb24gbmV0d29yayBpbmZvcm1hdGlvbi4NCj4gV2hlbiBETlMgaXMgdXNlZCwgdGhlIEROUyB6 b25lIFNIT1VMRCBOT1QgYmUgYWNjZXNzZWQgYnkgYW55b25lIGZyb20gb3V0c2lkZQ0KPiB0aGUg c3BlY2lmaWMgbmV0d29yay4gVGhpcyBjYW4gYmUgcGVyZm9ybWVkIGF0IHRoZSBETlMgc2VydmVy IGxldmVsIG9yIGF0DQo+IHRoZSBuZXR3b3JrIGJvdW5kYXJpZXMgYnkgc2V0dGluZyBmaXJld2Fs bCBwb2xpY2llcyBzcGVjaWZ5aW5nIHdoaWNoIGtpbmQgb2YNCj4gSVAgYWRkcmVzcyBjYW4gYWNj ZXNzIHRoZSBETlMgc2VydmVyLiBXaGVuIG1ETlMgaXMgdXNlZCwgbXVsdGljYXN0ZWQNCj4gaW5m b3JtYXRpb24gU0hPVUxEIE5PVCBiZSBmb3J3YXJkZWQgb3V0c2lkZSB0aGUgZXhwZWN0ZWQgbmV0 d29yay4gVGhpcyBjYW4NCj4gYmUgcGVyZm9ybWVkIGJ5IGZpcmV3YWxscyB0aGF0IGRyb3BzIG91 dGJvdW5kL2luYm91bmQgbUROUyBwYWNrZXRzIGF0IHRoZQ0KPiBuZXR3b3JrIGJvdW5kYXJpZXMu IE5vdGUgdGhhdCBpbiBib3RoIGNhc2VzLCB0aGVzZSBwb2xpY2llcyBhcmUgb3V0c2lkZSB0aGUN Cj4gc2NvcGUgb2YgbUROUyBvciBETlMuIE9uIHRoZSBvdGhlciBoYW5kLCBmb3IgbW9iaWxlIGRl dmljZXMsIGZvciBleGFtcGxlLA0KPiB3aGljaCBpbmZvcm1hdGlvbiBtYXkgYmUgcHJvdmlkZWQg ZGVwZW5kcyBvbiB0aGUgbmV0d29yay4gVGhlc2UgcG9saWNpZXMNCj4gaGF2ZSB0byBiZSBpbXBs ZW1lbnRlZCBieSB0aGUgbW9iaWxlIGRldmljZS4NCj4NCj4gICAgIGIpIFNTRCBTSE9VTEQgYWxz byBjb25zaWRlciBzY29wZXMgdGhhdCBhcmUgbm90IGNvcnJlbGF0ZWQgdG8gbmV0d29yaw0KPiBk ZWZpbml0aW9ucyBsaWtlICdidWlsZGluZycgb3IgJ3Jvb20nLiBBcyBkZWZpbmVkIGluIHRoZSBj aGFydGVyOg0KPiAiSXQgaXMgYWxzbyBkZXNpcmFibGUgdGhhdCBtdWx0aXBsZSBkaXNjb3Zlcnkg c2NvcGVzIGFyZSBzdXBwb3J0ZWQsDQo+IGZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgZWl0aGVy IHBlcmZvcm1pbmcgZGlzY292ZXJ5IHdpdGhpbiBhDQo+IHNwZWNpZmllZCBzY29wZSBvciBhZHZl cnRpc2VtZW50IHdpdGhpbiBhIHNwZWNpZmllZCBzY29wZSwgYW5kDQo+IGJlaW5nIGFibGUgdG8g ZGlzY292ZXIgKGVudW1lcmF0ZSkgdGhlIHNldCBvZiBzY29wZXMgc3VjaCB0aGF0DQo+IGFuIGFw cGxpY2F0aW9uIGNvdWxkIHRoZW4gY2hvb3NlIHRvIGRvIGVpdGhlci4gSXQgc2hvdWxkIGJlIG5v dGVkDQo+IHRoYXQgc2NvcGUgaW4gdGhpcyBzZW5zZSBtaWdodCByZWZlciB0byAnYnVpbGRpbmcn IG9yICdyb29tJyBhbmQgdGh1cw0KPiBtaWdodCBoYXZlIG5vIGNvcnJlbGF0aW9uIHRvIG5ldHdv cmsgdG9wb2xvZ3kuIg0KPg0KPiBUaGlzIHJlcXVpcmVzIDEpIGRlZmluaXRpb24gb2YgdGhlIGRp ZmZlcmVudCBhdmFpbGFibGUgc2NvcGVzLiBTb21lIGRlZmF1bHQNCj4gdmFsdWUgTUFZIGJlIHBy b3ZpZGVkIGJ5IHRoZSBkZXZpY2Ugd2l0aG91dCBrbm93bGVkZ2Ugb2YgdGhlIHNwZWNpZmljDQo+ IGF2YWlsYWJsZSBzY29wZXMgb2YgdGhlIG5ldHdvcmsuIFN1Y2ggZGVmYXVsdCB2YWx1ZXMgTUFZ IGJlIHVzZWQgYnkgZGV2aWNlcw0KPiBpZiB0aGV5IGRvIG5vdCBkaXNjb3ZlciB0aGUgZGlmZmVy ZW50IHNjb3BlcyBzcGVjaWZpYyB0byB0aGUgbmV0d29yayBvciBpZg0KPiB0aGUgZGV2aWNlIGRv ZXMgbm90IGhhdmUgc3VmZmljaWVudCBpbmZvcm1hdGlvbiB0byB0cnVzdCB0aGUgYW5ub3VuY2Vk DQo+IHNjb3Blcy4gSW4gdGhhdCBjYXNlIHRoZSBkZXZpY2UgTUFZIHN0YXJ0IHdpdGggYSBkZWZh dWx0IGxpbWl0ZWQgc2NvcGUuIDIpDQo+IFNwZWNpZmljIG5ldHdvcmsgdmFsdWVzIFNIT1VMRCBi ZSBhbm5vdW5jZWQgaW4gYW4gYXV0aGVudGljYXRlZCB3YXkgdG8gYXZvaWQNCj4gdGhhdCwgZm9y IGV4YW1wbGUsICBub24gZXhpc3Rpbmcgc2NvcGUgdXNlZCByZXN1bHRzIGluIHNlcnZpY2UgdW5h dmFpbGFibGUuDQo+IFRoZSBwb2xpY3kgZm9yIG5vbiBleGlzdGluZyBzY29wZXMgU0hPVUxEIGJl IGRlZmluZWQgd2l0aCBhIHJlZHVjZWQgc2NvcGUsDQo+IGFuZCB0aGUgZGV2aWNlIFNIT1VMRCBi ZSBpbmZvcm1lZCB0aGF0IHRoZSBzY29wZSBkb2VzIG5vdCBleGlzdCBzbyBpdCBtYXkNCj4gdXBk YXRlIGl0cyBzY29wZS4gMykgT25jZSBkZXZpY2VzIGhhdmUgYmVlbiBpbmZvcm1lZCBvZiB0aGUg dmFyaW91cyBzY29wZSwNCj4gaXQgTUFZIGNob3NlIHRoZSBvbmUgdGhhdCBzZWVtcyB0aGUgbW9z dCBhcHByb3ByaWF0ZWQgYW5kIHByb3ZpZGUgdGhpcw0KPiBpbmZvcm1hdGlvbi4gRGVwZW5kaW5n IG9uIHRoZSBzY29wZSwgcm91dGVycyBvciBtaWRkbGUgYm94ZXMgTUFZIGNob3NlIHRvDQo+IGZv cndhcmQgdGhlIGluZm9ybWF0aW9uIG9yIG5vdC4gVGhlIGluZm9ybWF0aW9uIE1BWSBiZSBmb3J3 YXJkZWQgb24gbXVsdGlwbGUNCj4gbGlua3MuIFdpdGggc2NvcGVzIHRoYXQgYXJlIG5vdCBuZXR3 b3JrIGNvcnJlbGF0ZWQsIHRoZSBpbmZvcm1hdGlvbiBNQVkgYmUNCj4gZm9yd2FyZGVkIHRvIGEg c3Vic2V0IG9mIGRldmljZXMgd2l0aGluIGEgbGluay4gVGhlIHVzZSBvZiBkaXN0aW5jdA0KPiBt dWx0aWNhc3QgSVAgYWRkcmVzcyBtYXkgYmUgdXNlZCB0byBkaXN0aW5ndWlzaCB0aGUgZGlmZmVy ZW50IHNjb3Blcy4NCj4gSG93ZXZlciwgdGhlIHVzZSBvZiBkaWZmZXJlbnQgSVAgYWRkcmVzc2Vz IGRvZXMgbm90IHByZXZlbnQgZGV2aWNlcyB0bw0KPiBsaXN0ZW4gdG8gdGhlIGluZm9ybWF0aW9u LiBJZiB0aGUgZGV2aWNlIG5lZWRzIHRoZSBpbmZvcm1hdGlvbiB0byBiZSByZWFkDQo+IG9ubHkg YnkgdGhlIG1lbWJlcnMgb2YgdGhlIHNjb3BlLCBjcnlwdG9ncmFwaHkgTUFZIGJlIHVzZWQgdG8g ZW5jcnlwdCB0aGUNCj4gZGF0YS4gSVBzZWMgbXVsdGljYXN0IGV4dGVuc2lvbiBbUkZDNTM3NF0g bWF5IGJlIGEgZ29vZCBjYW5kaWRhdGUuIFRoaXMNCj4gbWVjaGFuaXNtIG1heSBhbHNvIGJlIHVz ZWQgdG8gcHJldmVudCBhbiB1bmF1dGhvcmlzZWQgZGV2aWNlIHRvIHByb3ZpZGUgYQ0KPiBzZXJ2 aWNlIGZvciBhIGdpdmVuIHNjb3BlLiBJbiBvdGhlciB3b3JkcywgbXkgcHJpbnRlciBzaG91bGQg bm90IGJlIGFibGUgdG8NCj4gYW5ub3VuY2UgaXRzIHNlcnZpY2UgZm9yIHRoZSAiQ0VPIiBzY29w ZSBhbmQgSSBzaG91bGQgbm90IGJlIGFibGUgdG8gc2VlIHRoZQ0KPiBhbm5vdW5jZW1lbnQgb2Yg dGhlIHByaW50ZXIgb2YgbXkgQ0VPLg0KPg0KPiAyKSBFeHBvc2luZyBTZXJ2aWNlcw0KPg0KPiBB IFNlcnZpY2UgYW5ub3VuY2VkIG92ZXIgYSBuZXR3b3JrIGRvZXMgbm90IG1lYW4gdGhlIHNlcnZp Y2UgaXMgYXZhaWxhYmxlIHRvDQo+IGFueW9uZS4gU3VjaCBzZXJ2aWNlcyBTSE9VTEQgZW5mb3Jj ZSBhY2Nlc3MgY29udHJvbCBwb2xpY2llcyBmb3IgdGhlDQo+IHNlcnZpY2UuDQo+DQo+IElmIGEg Y29ubmVjdGVkIHByaW50ZXIgaXMgbm90IHVzaW5nIFNELCBpdCBNQVkgYXBwZWFyIGFzIGEgc2lt cGxlIElQDQo+IGNvbm5lY3RlZCBkZXZpY2UgYXR0YWNoZWQgdG8gdGhlIG5ldHdvcmsuIE9ubHkg c3BlY2lmaWMgdGVzdHMvc2NhbnMvdHJhZmZpYw0KPiBtb25pdG9yIGNhbiBkZXRlcm1pbmUgdGhl IGRldmljZSBpcyBhIHByaW50ZXIuIFdoZW4gU0Qgb3IgU1NEIGlzIHVzZWQsIGFzDQo+IHNvb24g YXMgdGhlIGRldmljZSBpcyBwbHVnZ2VkIG9uIHRoZSBuZXR3b3JrIGV2ZXJ5b25lIGtub3dzICJQ aG90byBDb2xvcg0KPiBQcmludGVyLCBCdWlsZGluZyBBIGZsb29yIDIiIGhhcyBiZWVuIHBsdWdn ZWQuIElmIHRoaXMgcHJpbnRlciBpcyByZXNlcnZlZA0KPiBmb3IgdGhlIEdyYXBoaWMgYW4gRGVz aWduIGRlcGFydG1lbnQsIHRoYW4gdGhlIHByaW50ZXIgU0hPVUxEIGltcGxlbWVudA0KPiBhY2Nl c3MgY29udHJvbCBtZWNoYW5pc21zLiBBbHRob3VnaCB0aGVzZSBwb2xpY2llcyBhcmUgb3V0IG9m IHNjb3BlIG9mIFNTRCwNCj4gdGhleSBNQVkgYmUgcmVxdWlyZWQgYXMgYSBjb25zZXF1ZW5jZSBv ZiBTU0QuDQo+DQo+IDIpIFJlc291cmNlIGV4aGF1c3Rpb24NCj4NCj4gV2l0aCBuZXcgZW1lcmdp bmcgdHlwZXMgb2YgbmV0d29ya3MgbGlrZSBzZW5zb3IgbmV0d29ya3MgYW5kIG1vcmUgZ2VuZXJh bGx5DQo+IHRoZSBJb1QsIFNTRCBjYW5ub3QgYW55bW9yZSByZWx5IG9uIG1ETlMgYW5kIG11bHRp Y2FzdCB0byBhZHZlcnRpc2UgaXRzDQo+IHNlcnZpY2VzIGFuZCBTSE9VTEQgcHJvdmlkZSBhIGRl ZGljYXRlZCBlbnRpdHkgdGhhdCBjYW4gcGVyZm9ybSBTU0QgdmlhDQo+IHVuaWNhc3QgbWVzc2Fn ZXMuIFR5cGljYWxseSwgdGhpcyBjYW4gYmUgZGVwbG95ZWQgd2l0aCBhIG1ETlMtdG8tRE5TIGFn ZW50DQo+IHRoYXQgcmVjZWl2ZXMgYW5ub3VuY2VtZW50IGZyb20gbUROUyBkZXZpY2VzIGFuZCBz dG9yZXMgdGhpcyBpbmZvcm1hdGlvbiB0bw0KPiB0aGUgRE5TIHpvbmUuIFNpbmNlIHRoZSBpbmZv cm1hdGlvbiBpcyBzdG9yZWQsIG90aGVyIGRldmljZXMgaW4gdGhlIG5ldHdvcmsNCj4gZG8gbm90 IGhhdmUgdG8gcmVjZWl2ZSBhbmQgdHJlYXQgbUROUyBhbm5vdW5jZW1lbnRzLg0KPg0KPiBTU0Qg TVVTVCBiZSBhYmxlIHRvIHNjYWxlIHRvIHRob3VzYW5kcyBvZiBkZXZpY2VzLiBUaGUgdXNlIG9m IG11bHRpY2FzdCBmb3INCj4gc2VydmljZSBhbm5vdW5jZW1lbnQgcmVxdWlyZXMgdGhhdCBlYWNo IGRldmljZSBpbmZvcm1zIGFsbCBvdGhlciBkZXZpY2VzDQo+IHNvbWUgaW5mb3JtYXRpb24gbGlr ZSB0aGUgaG9zdGVkIHNlcnZpY2UgZm9yIGV4YW1wbGUuIEluIG9yZGVyIHRvIG1ha2Ugc3VyZQ0K PiBkZXZpY2VzIGFsd2F5cyBoYXZlIHRoZSBpbmZvcm1hdGlvbiB1cC10by1kYXRlIG9yIHRoYXQg YW55IG5ldyBkZXZpY2UgaGFzDQo+IHRoZSBpbmZvcm1hdGlvbiwgdGhlIGRldmljZSByZWd1bGFy bHkgcmV0cmFuc21pdHMgdGhlIGluZm9ybWF0aW9uIHRvIGFsbA0KPiBvdGhlciBkZXZpY2VzLiBU aGlzIGlzIG5vdCBhIHNjYWxhYmxlIGFyY2hpdGVjdHVyZSBhcyBpdCBkb2VzIG5vdCBzY2FsZSBp bg0KPiB0ZXJtIG9mIGJhbmR3aWR0aCBub3IgaXQgY29uc2lkZXIgZW5lcmd5IGNvbnN1bXB0aW9u IGNvbnN0cmFpbnMgb2Ygc21hbGwNCj4gZGV2aWNlcy4NCj4NCj4gQW55IG1lc3NhZ2VzIGFyZSBi eXRlcyByZWNlaXZlZCBieSB0aGUgZGV2aWNlcyBjb25uZWN0ZWQgb24gdGhlIG5ldHdvcmssDQo+ IHdoaWNoIG1heSByZXF1aXJlIGFkZGl0aW9uYWwgcHJvY2Vzc2luZyBzdWNoIGFzIGNyeXB0b2dy YXBoaWMgY2hlY2sgaWYgdXNlZA0KPiBpbiBjb25qdW5jdGlvbiB3aXRoIEROU1NFQyBmb3IgZXhh bXBsZS4gVGhlc2UgZGV2aWNlcyBtYXkgcmVseSBvbiBiYXR0ZXJ5LA0KPiBhbmQgZWFjaCBvZiB0 aGVzZSBtZXNzYWdlcyBkaXJlY3RseSBpbXBhY3QgdGhlIGxpZmV0aW1lIG9mIHRoZSBkZXZpY2Uu IEFzIGENCj4gcmVzdWx0IGFnZ3Jlc3NpdmUgbXVsdGljYXN0IG1heSB1bm5lY2Vzc2FyaWx5IGFm ZmVjdCBJb1QgZGV2aWNlcy4gTW9yZQ0KPiByYXRpb25hbCBhcHByb2FjaCBNQVkgY29uc2lzdHMg aW4gbWFraW5nIHBvc3NpYmxlIFNTRCB1c2luZyB1bmljYXN0DQo+IGNvbW11bmljYXRpb25zIG9u bHkgb3IgdG8gcHJldmVudCB0aGF0IElvVCBkZXZpY2Ugd2FrZXMgdXAgYXQgZXZlcnkNCj4gbXVs dGljYXN0IG1lc3NhZ2Ugb3IgdXNpbmcgbXVsdGljYXN0IHRvIGFubm91bmNlIGluZm9ybWF0aW9u IHVwZGF0ZXMgYXMNCj4gb3Bwb3NlZCB0byBjYWNoZSBwb3B1bGF0aW5nLiBNb3JlIHNwZWNpZmlj YWxseSwgYSBuZXcgZGV2aWNlIGNhbiB1c2UNCj4gbXVsdGljYXN0IHRvIGFubm91bmNlIGEgbmV3 bHkgcHVibGlzaGVkIGluZm9ybWF0aW9uLiBFdmVudHVhbGx5IHRoaXMNCj4gaW5mb3JtYXRpb24g bWF5IGJlIGNhY2hlZCBieSBhbHdheXMtb24gZGV2aWNlcyBhbmQgc3RvcmVkIGluIHRoZSBETlMu IEEgbmV3DQo+IGRldmljZSBtYXkgZ2V0IGFjY2VzcyB0byB0aGVzZSBwaWVjZXMgb2YgaW5mb3Jt YXRpb24gd2l0aCBhbiB1bmljYXN0IEFYRlINCj4gZm9yIGV4YW1wbGUuIFRoZSBtYWluIGFkdmFu dGFnZSBpcyB0aGF0IG11bHRpY2FzdCBpbnRlcmZhY2UgY2FuIGJlIHN3aXRjaGVkDQo+IG9mZi4N Cj4NCj4gU28gaGVyZSB3ZSdyZSBpbiBzaW1pbGFyIHRlcnJpdG9yeSB0byB0aGUgZGlzY3Vzc2lv bnMgYWJvdXQgUkFzLCBhbmQNCj4gbXVsdGljYXN0IG9uIGNlcnRhaW4gdHlwZXMgb2YgbGlua3Ms IHdoaWNoIGhhcyBsZWQgdG8gdGhlIGVmZmljaWVudC1ORA0KPiBwcm9wb3NhbCwgYW5kIHJlbGF0 ZWQgd29yayBvbiBlbmVyZ3kgZWZmaWNpZW5jeSBmb3IgbG93IHBvd2VyIGRldmljZXMgZXRjLg0K PiBbaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaGFscGVybi02bWFu LW5kLXByZS1yZXNvbHZlLWFkZHItMDAudHh0XQ0KPg0KPiAzKSBUcnVzdGVkIFNjYWxhYmxlIFNl cnZpY2UgRGlzY292ZXJ5DQo+DQo+IFRoaXMgc2VjdGlvbiBpcyBvbmx5IGZvY3VzZWQgb24gaG93 IGluZm9ybWF0aW9uIHByb3ZpZGVkIGJ5IHRoZSBTU0QgY2FuIGJlDQo+IHRydXN0ZWQuIEFzIGV2 ZXJ5IGRldmljZSBhbm5vdW5jZSB0aGVpciBzZXJ2aWNlLCBTU0QgU0hPVUxEIHByZXZlbnQgYW4N Cj4gYXR0YWNrZXIgdG8gYW5ub3VuY2UgaXQgaXMgdGhlICJDRU8gUHJpbnRlciIgaW4gb3JkZXIg dG8gY29sbGVjdCBhbGwNCj4gZG9jdW1lbnRzIHByaW50ZWQgYnkgdGhlIENFTy4NCj4gSW4gdGhp cyBzZWN0aW9uLCB3ZSBjb25zaWRlciB0aGF0ICJDRU8gUHJpbnRlciIgZG9lcyBub3QgZXhpc3Rz IGFuZCB0aGF0IHRoZQ0KPiBhdHRhY2sgZG9lcyBub3QgYWltIGF0IGhpamFja2luZyBhIHNwZWNp ZmljIG5hbWUuIFVzaW5nIHRoZSBTRCB0ZXJtaW5vbG9neQ0KPiAiQ0VPIFByaW50ZXIiIHdvdWxk IGJlIHRoZSBJbnN0YW5jZSBwYXJ0IG9mIHRoZSBTZXJ2aWNlIEluc3RhbmNlIE5hbWUuDQo+DQo+ IGEpIFVzZXIgcGVyc3BlY3RpdmUNCj4gV2hlbiBETlMgaXMgdXNlZCwgRE5TU0VDIGNhbiBiZSB1 c2VkLCBhbmQgb25lIGNhbiB0cnVzdCB0aGUgaW5mb3JtYXRpb24gYXMNCj4gaXQgcHJvdmlkZXMg ZnJvbSBhIHRydXN0ZWQgcGFydHkuIEFsdGhvdWdoIEROU1NFQyBoYXMgbm90IGJlZW4gZGVzaWdu ZWQgYXMgYQ0KPiBwcm90b2NvbCB0aGF0IGNlcnRpZmllcyB0aGUgdmFsaWRpdHkgb2YgdGhlIERO UyBSREFUQSwgaW4gb3VyIGNhc2UsIEROU1NFQw0KPiBjb3VsZCBiZSB1c2VkIGFzIHN1Y2guIENv bnRyYXJ5IHRvIHJlZ2lzdHJhcnMgdGhhdCBhcmUgaG9zdGluZyBGUUROcyB0aGV5DQo+IGhhdmUg dmVyeSBmZXcga25vd2xlZGdlIG9uLCBuZXR3b3JrIGFkbWluaXN0cmF0b3JzIGFyZSBleHBlY3Rl ZCB0bw0KPiBhZG1pbmlzdHJhdGVkIHRoZSBETlMgem9uZSBhY2NvcmRpbmcgdG8gdGhlIHJlc291 cmNlcyBhdmFpbGFibGUgZm9yIHRoZQ0KPiBuZXR3b3JrLiBBcyBhIHJlc3VsdCBETlNTRUMgdmFs aWRhdGlvbiBjb3VsZCBiZSBpbnRlcnByZXRlZCBhcyAidmFsaWRhdGVkIGJ5DQo+IHRoZSBhZG1p bmlzdHJhdG9yIi4NCj4NCj4gbUROUyBkb2VzIG5vdCBoYXZlIHRydXN0IGFuY2hvcnMgcHJvdmlk ZWQgYnkgRE5TU0VDLiBIb3dldmVyLCBETlNTRUMgdXNlZCBpbg0KPiBjb25qdW5jdGlvbiBvZiBt RE5TIGNhbiBiZSB1c2VkIHRvIHByb3ZpZGUgYSBwcm9vZi1vZi1vd25lcnNoaXAgb2YgdGhlDQo+ IGluZm9ybWF0aW9uLiBIb3cgcmVsaWFibGUgaXMgdGhhdCBpbmZvcm1hdGlvbiBjYW4gYmUgbGVh cm5lZCBvdmVyIHRpbWUgYnkNCj4gcHJvY2Vzc2luZyB0aGUgcmVwdXRhdGlvbiBvZiBhIGRldmlj ZSAocmVwcmVzZW50ZWQgYnkgaXRzIHB1YmxpYyBrZXkpIG9yIGJ5DQo+IG1vbml0b3Jpbmcgd2hl dGhlciB0aGUgaW5mb3JtYXRpb24gcmVtYWlucyBjb2hlcmVudCBvdmVyIHRpbWUuIEZvciBleGFt cGxlLA0KPiBpZiBhIHByaW50ZXIgYW5ub3VuY2VzIGl0cyBJUCBhZGRyZXNzIGFzIHBhcnQgb2Yg dGhlIGNvbXBhbnkgbmV0d29yaywgYW5kDQo+IHN1ZGRlbmx5IHN0YXJ0cyBhbm5vdW5jaW5nIGFu IElQIGFkZHJlc3MgbG9jYXRlZCBzb21ld2hlcmUgZWxzZSwgZnVydGhlcg0KPiBjaGVja3MgbWF5 IGJlIHBlcmZvcm1lZCBiZWZvcmUgdHJ1c3RpbmcgdGhlIGluZm9ybWF0aW9uLiBFdmVuIHRob3Vn aCB0aGUNCj4gbUROUyBtZXNzYWdlIHNpZ25lZCB3aXRoIEROUyBjYW5ub3QgYmUgdHJ1c3RlZCB0 aGUgc2FtZSB3YXkgYXMgaXQgd291bGQgaGF2ZQ0KPiBiZWVuIHRydXN0ZWQgaW4gYSBETlNTRUMg em9uZSwgdXNpbmcgRE5TU0VDIGluIGNvbmp1bmN0aW9uIG9mIG1ETlMgbWFrZXMNCj4gcG9zc2li bGUgdG8gYXNzaWduIHNvbWUgcGllY2VzIG9mIGluZm9ybWF0aW9uIHRvIGEgc3BlY2lmaWMga2V5 LiBUaGlzIGhlbHBzDQo+IGluIGVzdGFibGlzaGluZyBhIHJlcHV0YXRpb24gYXMgd2VsbCBhcyBh dm9pZHMgc3Bvb2ZlZCBtZXNzYWdlcy4NCj4NCj4gT24gYSB1c2VyIHBlcnNwZWN0aXZlLCBtRE5T IHJlcXVpcmVzIHRoZSBlbmQgdXNlciB0byBlc3RhYmxpc2ggYSByZXB1dGF0aW9uDQo+IG1lY2hh bmlzbSB3aGVyZWFzIEROUyBwcm92aWRlcyBjZXJ0aWZpZWQgaW5mb3JtYXRpb24uIFRoZSBtYWlu IGFkdmFudGFnZSBvZg0KPiBETlMgaXMgdGhhdCBhIG5ldyBlbmQgdXNlciBoYXMgY2VydGlmaWVk IGluZm9ybWF0aW9uIHdoaWNoIGlzIG5vdCBwb3NzaWJsZQ0KPiB3aXRoIG1ETlMuDQo+DQo+IFtU QkQgY2hlY2svY29tcGFyZSBoeWJyaWQgbW9kZWxdDQo+DQo+IGIpIERldmljZXMgcGVyc3BlY3Rp dmUNCj4NCj4gV2hlbiBETlMgaXMgdXNlZCwgdGhlIGRldmljZSBNVVNUIGJlIGFibGUgdG8gcHJv dmlkZSB0aGUgaW5mb3JtYXRpb24gdG8gdGhlDQo+IEROUyBzZXJ2ZXIgdmlhIEROUyB1cGRhdGUg W1JGQzIxMzZdIG9yIHNlY3VyZSBETlMgdXBkYXRlIFtSRkMzMDA3XS4gVGhpcw0KPiBzY2VuYXJp byBtYXkgbm90IG1lZXQgYSBaZXJvIGNvbmZpZ3VyYXRpb24gcmVxdWlyZW1lbnQgYXMgdGhlIERO UyBzZXJ2ZXINCj4gbmVlZHMgdG8ga25vdyB0aGUgcHVibGljIGtleSBvZiB0aGUgZGV2aWNlcywg YW5kIHRoZSBkZXZpY2UgbmVlZHMgdG8ga25vdyBhdA0KPiBsZWFzdCB0aGUgSVAgYWRkcmVzcyBv ZiB0aGUgRE5TIHNlcnZlci4gSWYgREhDUHY2IHRoZSBJUCBhZGRyZXNzIG9mIHRoZSBNQVkNCj4g YmUgZGVyaXZlZCBmcm9tIHRoZSBEb21haW4gU2VhcmNoIExpc3QgYW5kIHRoZSBETlMgUmVjdXJz aXZlIE5hbWUgU2VydmVyDQo+IG9wdGlvbiBbUkZDMzY0Nl0uIFRoZSBkZXZpY2UgTUFZIHNlbmQg YSBETlMgcXVlcnkgZm9yIG9uZSBkb21haW4gc2VhcmNoIHdpdGgNCj4gdHlwZSBOUyB0byB0aGUg cmVjdXJzaXZlIG5hbWUgc2VydmVyLiBIb3dldmVyLCByZWdpc3RlcmluZyB0aGUgcHVibGljIGtl eXMNCj4gb2YgdGhlIGRldmljZXMgaW4gdGhlIEROUyBkb2VzIG5vdCBzY2FsZSB0aG91c2FuZHMg b2YgZGV2aWNlcy4gTW9zdCBsaWtlbHksDQo+IHRoZWlyIHB1YmxpYyBrZXlzIG1heSBiZSBjb25z aWRlcmVkIGFzIHRydXN0ZWQgYmFzZWQgb24gcmVwdXRhdGlvbiwgbGVhcCBvZg0KPiBmYWl0aCBw cmluY2lwbGVzIHdoaWNoIGRvZXMgbm90IG5lY2Vzc2FyaWx5IHByZXZlbnQgYW4gYXR0YWNrZXIg dG8gc2V0IGZhbHNlDQo+IGRhdGEgaW50byB0aGUgRE5TIHpvbmUuDQo+DQo+IFdoZW4gbUROUyBp cyB1c2VkLCB0aGUgZGV2aWNlIGRvZXMgbm90IG5lZWQgYW55IGNvbmZpZ3VyYXRpb24uIFRoaXMN Cj4gaW5mb3JtYXRpb24gaXMgYW5ub3VuY2VkIHRvIHRoZSBuZXR3b3JrLiBUaGUgaW5mb3JtYXRp b24gd2lsbCBiZSB0cnVzdGVkIGJ5DQo+IHRoZSBkZXZpY2VzIHRoYXQgdHJ1c3QgdGhlIGFubm91 bmNlci4gQXMgZm9yIHRoZSBETlMsIHByb3Zpc2lvbmluZyBhbGwNCj4gZGV2aWNlcyBvZiB0aGUg bmV0d29yayB3aXRoIGFsbCBwdWJsaWMga2V5cyBpcyBub3Qgc2NhbGFibGUuIEFzIG1lbnRpb25l ZA0KPiBhYm92ZSwgcHVibGljIGtleXMgd2lsbCBiZSB0cnVzdGVkIG1vc3QgbGlrZWx5IGJhc2Vk IG9uIHJlcHV0YXRpb24gb3IgbGVhcA0KPiBvZiBmYWl0aCBwcmluY2lwbGVzLg0KPg0KPiBUaGUg bWFpbiBkaWZmZXJlbmNlIGJldHdlZW4gRE5TIGFuZCBtRE5TIHNlZW1zIHRoYXQgRE5TIHJlcXVp cmVzIGxlc3MNCj4gcHJvdmlzaW9uaW5nIG9yIGNvbmZpZ3VyYXRpb24gdGhhbiBtRE5TIChuIHZl cnN1cyBuICogKG4gLSAxKSBmb3IgYSBuIGRldmljZQ0KPiBuZXR3b3JrKS4gVGhlbiBpbiBhIHpl cm8gY29uZmlndXJhdGlvbiBzY2VuYXJpbywgRE5TIGNlbnRyYWxpc2VzIGluIGEgc2luZ2xlDQo+ IHBvaW50IHRoZSB3YXkgYSBrZXkgY2FuIGJlIHRydXN0ZWQuIFRoZSBvbmx5IGRpc2FkdmFudGFn ZSBvZiB1c2luZyBETlMgaXMNCj4gdGhlIGRldmljZXMgc2hvdWxkIGRpc2NvdmVyIHRoZSBETlMg c2VydmVyLg0KPg0KPiBJdCBzZWVtcyB0aGF0IGFwcHJvYWNoIGNvbWJpbmluZyBtRE5TIGFuZCBE TlMgY2FuIHRha2UgYWR2YW50YWdlIG9mIGJvdGguDQo+IERldmljZXMgYW5ub3VuY2UgaW5mb3Jt YXRpb24gdXNpbmcgbUROUyBhbmQgdGhlIEROUyBhY2NvcmRpbmcgdG8gdGhlIGxldmVsDQo+IG9m IHRydXN0IHN0b3JlcyB0aGUgaW5mb3JtYXRpb24gaW4gaXRzIHpvbmUuDQo+DQo+DQo+IDQpIElu Zm9ybWF0aW9uIGltcGVyc29uYXRpb24NCj4NCj4gVGhlIHByZXZpb3VzIHNlY3Rpb24gcHJvdmlk ZWQgY29uc2lkZXJhdGlvbnMgb24gaG93IGEgZGV2aWNlIGNhbiBiZQ0KPiBhc3NvY2lhdGVkIHRv IGEgcHVibGljIGtleSBhbmQgZXZlbnR1YWxseSBpZGVudGlmaWVkIGFzIGEgdHJ1c3RlZCBkZXZp Y2UuDQo+IFdpdGggemVybyBjb25maWd1cmF0aW9uLCB0aGUgbGV2ZWwgb2YgdHJ1c3QgYXNzb2Np YXRlZCB0byBhIGRldmljZSByZXN1bHRzDQo+IG9mIGEgdHJhZGUgb2ZmIGJldHdlZW4gY29uZmln dXJhdGlvbiBhbmQgYSBsZWFybmluZyBwcm9jZXNzLiBUaGlzIHNlY3Rpb24NCj4gaW5kaWNhdGVz IGhvdyBpbmZvcm1hdGlvbiBwcm92aWRlZCBieSB0aGUgZGV2aWNlcyBjYW4gYmUgbW9uaXRvcmVk IHRvDQo+IGRldGVybWluZSB0aGUgcmVwdXRhdGlvbiBvZiBhIGRldmljZSwgdG8gcmFpc2UgYW4g YWxhcm0gdG8gdGhlDQo+IGFkbWluaXN0cmF0b3IsIGFuZCBldmVudHVhbGx5IHNob3cgYSBkZXZp Y2UgY2Fubm90IGJlIHRydXN0ZWQgb3IgaW5kaWNhdGUgYQ0KPiBkZXZpY2UgaGFzIGJlZW4gIGNv cnJ1cHRlZC4NCj4NCj4gVGhlIGtpbmQgb2YgaW5mb3JtYXRpb25zIHByb3ZpZGVkIGJ5IFNEIG9y IFNTRCB0aGF0IGFyZSB2aXNpYmxlIHRvIHRoZSBlbmQNCj4gdXNlciBhcmUgMSkgYSBuYW1lIHRo YXQgZGVzY3JpYmVzIGEgc2VydmljZSBhbmQgMikgdGhlIGxvY2F0aW9uIG9mIHRoZQ0KPiBzZXJ2 aWNlLiBUaGUgbmFtZSBvZiB0aGUgc2VydmljZSBjb3JyZXNwb25kcyB0byBTZXJ2aWNlIEluc3Rh bmNlIE5hbWUuIFdpdGgNCj4gU0QgdGhlIG5hbWUgaXMgbWVudGlvbmVkIGluIHRoZSBSREFUQSBw YXJ0IG9mIHRoZSBQVFIgYW5kIGFzIHRoZSBrZXkgb2YgdGhlDQo+IFNSViBSUlNldC4gVGhlIGxv Y2F0aW9uIG9mIHRoZSBzZXJ2aWNlIGlzIHRoZSBSREFUQSBwYXJ0IG9mIHRoZSBTUlYgYXMgd2Vs bA0KPiBhcyBpdHMgY29ycmVzcG9uZGluZyBsb2NhdG9yLg0KPg0KPiBUaGUgU2VydmljZSBJbnN0 YW5jZSBOYW1lIGlzIGNvbXBvc2VkIG9mIHRocmVlIHBhcnRzOiBJbnN0YW5jZSwgU2VydmljZSBO YW1lDQo+IGFuZCBEb21haW4uIFNEIHJlY29tbWVuZHMgdGhhdCBJbnN0YW5jZSBhbmQgRG9tYWlu IGFyZSBlbmNvZGVkIHVzaW5nIFVURjguDQo+IFVURjggZW5hYmxlcyBzcGVjaWZpYyBjaGFyYWN0 ZXJzIHRoYXQgYXJlIG5vdCB5ZXQgYmVpbmcgY29uc2lkZXJlZCBpbiB0aGUNCj4gY3VycmVudCBE TlMuIFRyYWRpdGlvbmFsIEROUyB1c2VzIGFzY2lpIG9yIFB1bnljb2RlLiBJZiBVVEY4IGlzIG1v cmUNCj4gZmxleGlibGUgaW4gdGVybSBvZiBzdHJpbmcgcmVwcmVzZW50YXRpb24sIGl0IG1heSBw cm92aWRlIG11bHRpcGxlIHdheXMgdG8NCj4gZXhwcmVzcyB0aGUgc2FtZSB0aGluZyB3aGljaCBt YXkgY29uZnVzZSB0aGUgZW5kIHVzZXIuIEluIGZhY3QgdXNpbmcgVVRGOA0KPiAiTXkgUHJpbnRl ciIsICJteSBwcmludGVyIiAiTXkgcHJpbnRlciIgYXJlIGRpZmZlcmVudCBzdHJpbmdzLiBUaGlz IG1heSBiZQ0KPiB1c2VkIGJ5IGFuIGF0dGFja2VyIHRoYXQgd2lsbCBwcm92aWRlIGEgc2Vydmlj ZSBkaWZmZXJlbnQgaW4gdGVybSBvZiBVVEY4DQo+IGZvcm1hdCwgYnV0IHRoYXQgdGhlIGVuZCB1 c2VyIHdpbGwgYXNzaW1pbGF0ZSB0byB0aGUgc2FtZSBzZXJ2aWNlLiBJbg0KPiBhZGRpdGlvbiwg Im15IHByaW50ZXIiIHdpbGwgYmUgZGlzcGxheWVkIGRpZmZlcmVudGx5IGlmIGVuY29kZWQgaW4g VVRGOCBvcg0KPiBpbiBhc2NpaS4gQXMgYSByZXN1bHQgdHdvIHNlcnZpY2UgIm15IHByaW50ZXIi IGNvdWxkIGJlIHN0b3JlZCBpbiBhIEROUyB6b25lDQo+IHdpdGhvdXQgYW55IGNvbGxpc2lvbnMu DQo+IE9uZSB3YXkgdG8gYXZvaWQgbXVsdGlwbGUgZm9ybWF0IHdvdWxkIGJlIHRvIGNvbnNpZGVy IHRoZSBuZWNlc3Nhcnkgb3INCj4gbWlzc2luZyBjaGFyYWN0ZXJzIHByb3ZpZGVkIGJ5IFVURjgg YW5kIGFkZCB0aGVtIGluIHRoZSBQdW55IGNvZGUuDQo+IElmIHRoZXJlIG1heSBiZSBzb21lIGFk dmFudGFnZXMgaW4gdXNpbmcgVVRGOCBmb3IgdGhlIHNlcnZpY2UgbmFtZSwgdGhlDQo+IGRvbWFp biBuYW1lIHBhcnQgU0hPVUxEIHVzZSBvbmx5IHRoZSBQdW55Y29kZS4NCj4gQXMgYSByZXN1bHQs IGNoZWNraW5nIGluZm9ybWF0aW9uIGZvciBTU0QgcmVxdWlyZXMgdG8gZXN0YWJsaXNoDQo+IG1l dHJpY3Mvc2ltaWxhcml0aWVzIGJldHdlZW4gc3RyaW5ncy4NCj4NCj4gV29ydGggbm90aW5nIGlu IHRoZSBETlMgdGhlIGRldmljZSBtaWdodCBiZSBocHByaW50MDEuYmxkZzMyLnNvbWVzaXRlLmNv bSwNCj4gd2hpbGUgaXRzIGludGVybmFsbHkgc3RvcmVkIGxhYmVsIG1heSBiZSAiQnVpbGRpbmcg MzIgZm95ZXIgcHJpbnRlciIuDQo+DQo+DQo+IFRoZSBsb2NhdGlvbiBvZiB0aGUgc2VydmljZSBp cyBpZGVudGlmaWVkIGJ5IGEgRlFETiBhbmQgYSBjb3JyZXNwb25kaW5nIElQDQo+IGFkZHJlc3Mu IEluIFNELCB0aGUgRlFETiByZXNwZWN0IHRoZSBQdW5ueWNvZGUgZW5jb2RpbmcuIFRoZSBGUURO IG9mIHRoZQ0KPiBzZXJ2aWNlIG1heSBiZSBjaGVja2VkIGFnYWluc3QgdGhlIGtub3duIGRvbWFp biBuYW1lcyBhc3NvY2lhdGVkIHRvIHRoZQ0KPiBuZXR3b3JrLiBTaW1pbGFybHksIHRoZSBJUCBh ZGRyZXNzIGlzIGdlbmVyYWxseSB1c2VkIHRvIGxvY2F0ZSB0aGUgc2VydmljZS4NCj4gaWYgdGhl IElQIGFkZHJlc3MgaXMgbm90IGluc2lkZSB0aGUgbmV0d29yaywgdGhpcyBtYXkgcmFpc2UgYSB3 YXJuaW5nIHRvIHRoZQ0KPiBhZG1pbmlzdHJhdG9yLCB0aGF0IG1heSB2YWxpZGF0ZSB0aGUgSVAg YWRkcmVzcy4NCj4NCj4NCj4gV2hlbiBETlNTRUMgaXMgdXNlZCBjbG9zZWQgbmFtZXMgYWRkcmVz c2VkIGJ5IGRpZmZlcmVudCBrZXlzIGFyZSBzdXNwaWNpb3VzLg0KPiBXaXRob3V0IHRoZSB1c2Ug b2YgRE5TU0VDIGlzIGJlY29tZXMgaGFyZCB0byBkZXRlY3QgdGhlIGRldmljZS9TRCBkZXZpY2Ug aGFzDQo+IG5vdCBjaGFuZ2VkIHRoZWlyIElQIGFkZHJlc3MuDQo+DQo+DQo+IDUpIFVuaXF1ZSBu ZXR3b3JrIGlkZW50aWZpZXINCj4NCj4gU0QgdXNlcyAiLmxvY2FsIiBwcmVmaXggdG8gaW5kaWNh dGUgdGhlIHNjb3BlIG9mIHRoZSBGUUROLiAgIi5sb2NhbCIgaXMgYQ0KPiBzcGVjaWFsIHVzZSBk b21haW4gbmFtZSAtIFJGQyA2NzYxLCBhbmQgaW4gdGhlIHJlZ2lzdHJ5IGF0DQo+IGh0dHA6Ly93 d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvc3BlY2lhbC11c2UtZG9tYWluLW5hbWVzL3NwZWNpYWwt dXNlLWRvbWFpbi1uYW1lcy54aHRtbA0KPg0KPiAiLmxvY2FsIiBpcyBpbnN0YW50aWF0ZWQgaW4g YW55IG5ldHdvcmtzLiBUaGlzIHJlc3VsdHMgaW4gYSBnaXZlbiBzdHJpbmcNCj4gd2l0aCBtdWx0 aXBsZSBtZWFuaW5ncy4gIk15IFByaW50ZXIiIGF0IGhvbWUgaXMgbm90IHRoZSBzYW1lIHNlcnZp Y2UgYXMgIk15DQo+IFByaW50ZXIiIGF0IHdvcmsgYW5kIGlmIHRoZSBpbmZvcm1hdGlvbiBpcyBj YWNoZWQgaW4gc29tZSBkZXZpY2VzLCB0aGlzIG1heQ0KPiByZXN1bHQgaW4gY3Jvc3Mgc2l0ZSBu YW1lIGhpamFja2luZy4gQW4gYXR0YWNrZXIgY291bGQgZm9yIGV4YW1wbGUgYWR2ZXJ0aXNlDQo+ ICJNeSBQcmludGVyIiBpbiBhIHB1YmxpYyBuZXR3b3JrIGxpa2UgaW4gYW4gYWlycG9ydCB3aXRo IGEgZ2xvYmFsIElQDQo+IGFkZHJlc3MuIFRoZSBTZXJ2aWNlIEluc3RhbmNlIE5hbWUgdXNlZCBj b3VsZCBiZSBzb21ldGhpbmcgYXMgIk15DQo+IFByaW50ZXJfaXBwX3RjcC5sb2NhbCBTUlYgZ2xv YmFsLXByaW50ZXIuZXhhbXBsZS5jb20iLiBQZW9wbGUgaW4gdGhlIGFpcnBvcnQNCj4gbWF5IHRo ZW4gc2VuZCB0aGVpciBkb2N1bWVudHMgdG8gIk15IFByaW50ZXIiIGFkdmVydGlzZWQgaW4gdGhl IGFpcnBvcnQgLQ0KPiB0aGF0IGlzIHRvIHNheSBnbG9iYWwtcHJpbnRlci5leGFtcGxlLmNvbSAt LCBpbnN0ZWFkIG9mIHRoZSBvbmUgb2YgdGhlaXINCj4gb2ZmaWNlLg0KPg0KPiBJbiBvcmRlciB0 byBtaXRpZ2F0ZSB0aGlzIGNvbmZ1c2lvbiwgIi5sb2NhbCIgU0hPVUxEIGJlIHVzZWQgb25seSB3 aGVuIHRoZQ0KPiBkZXZpY2UgZG9lcyBub3Qga25vdyB0aGUgZG9tYWluIG5hbWUgYXNzb2NpYXRl ZCB0byB0aGUgbmV0d29yay4gSWYgREhDUHY2IGlzDQo+IHVzZWQgdGhpcyBtYXkgYmUgZGVyaXZl ZCBieSB0aGUgREhDUHY2IENsaWVudCBGUUROIG9wdGlvbiBbUkZDNDcwNF0uDQo+DQo+IE5vdGUg YWxzbyB0aGF0ICJNeSBwcmludGVyIiBtYXkgYmUgYSBkaWZmZXJlbnQgcHJpbnRlciB3aGVuIEkg YW0gYXQgaG9tZSBvcg0KPiBhdCB3b3JrLiBPbiB0aGUgb3RoZXIgaGFuZCwgd2hpbGUgYXQgaG9l IEkgU0hPVUxEIGJlIGFibGUgdG8gdXNlICJNeSBPZmZpY2UNCj4gUHJpbnRlciIgYW5kIHZpY2Ug dmVyc2EuIFRoaXMgYW1iaWd1aXR5IG1heSBiZSBsZXZlcmFnZSBieSB0aGUgdXNlIG9mIHVuaXF1 ZQ0KPiBwcmVmaXguDQo+DQo+IDYpIENvbXByb21pc2VkIGRldmljZQ0KPg0KPiBUaGlzIHNlY3Rp b24gZXN0aW1hdGVzIGhvdyBhIGNvbXByb21pc2VkIGRldmljZSBpbXBhY3RzIHRoZSBTU0Qgc2Vy dmljZS4gV2UNCj4gYXNzdW1lIEROU1NFQyBpcyB1c2VkLg0KPg0KPiBPbmNlIGRldGVjdGVkLCB0 aGUgcHVibGljIGtleSBhc3NvY2lhdGVkIHRvIHRoZSBkZXZpY2UgaXMgcmV2b2tlZC4gV2l0aCBE TlMNCj4gdGhlIHJldm9jYXRpb24gb2NjdXJzIG9uY2UgaW4gdGhlIEROUywgYW5kIHRoZSBpbmZv cm1hdGlvbiBpcyBvbmx5IHN0b3JlZCBpbg0KPiB0aGUgcmVtYWluaW5nIGNhY2hlcyBvZiBkZXZp Y2VzIHRoYXQgaGF2ZSByZXF1ZXN0ZWQgdGhlIGluZm9ybWF0aW9uIGJlZm9yZQ0KPiBpdCBleHBp cmVzLiBBZnRlciBUVEwgc2Vjb25kcywgdGhlIGluZm9ybWF0aW9uIGlzIHJldm9rZWQgZnJvbSBh bGwgZGV2aWNlcy4NCj4gSWYgbUROUyBpcyB1c2VkLCByZXZvY2F0aW9uIHNob3VsZCBvY2N1ciBp biBldmVyeSBkZXZpY2UuIFRoZSBtZWNoYW5pc20gdG8NCj4gZGV0ZWN0IGEgZGV2aWNlIGlzIGNv bXByb21pc2VkIGlzIGNvbXBsZXggYW5kIHdpbGwgcHJvYmFibHkgbm90IGJlDQo+IGltcGxlbWVu dGVkIHByb3Blcmx5IGluIG1vc3QgZGV2aWNlcy4NCj4NCj4gV2l0aCB0aGUgY3VycmVudCBTRCwg YSBjb21wcm9taXNlZCBkZXZpY2UgTUFZIHByb3ZpZGUgd3JvbmcgaW5mb3JtYXRpb24NCj4gYWJv dXQgaXRzZWxmIGJ1dCBkb2VzIG5vdCBhZmZlY3Qgb3RoZXJzIGRldmljZSBpbmZvcm1hdGlvbi4N Cj4NCj4NCj4NCj4NCj4gLS0NCj4gRGFuaWVsIE1pZ2F1bHQNCj4gT3JhbmdlIExhYnMgLS0gU2Vj dXJpdHkNCj4gKzMzIDYgNzAgNzIgNjkgNTgNCg0KDQoNCi0tIA0KRGFuaWVsIE1pZ2F1bHQNCk9y YW5nZSBMYWJzIC0tIFNlY3VyaXR5DQorMzMgNiA3MCA3MiA2OSA1OA0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRuc3NkIG1haWxpbmcgbGlzdA0KZG5z c2RAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zc2Q= ------=_001_NextPart061220635831_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi, Daniel, t= hree=20 pieces of in-line comments beginning with [Guangqing Deng] are listed= =20 below, please refer to.
 
Guangqing=20 Deng
CNNIC 
 
Date: 2014-01-22 14:55
CC: dnssd
Subject: Re: [dnssd] draft-ietf-dnssd-requirements-00.t= xt:=20 Requirements/Security Considerations
Hi Deng,
 
Thank you very much for the comments and question. If I understand<= /DIV>
correctly your point, you are saying that DNSSEC and IPsec=20 performed
in an authenticated way may add to much overhead on the network for= =20 a
temporary service. This may be true on two aspects: 1) IPsec/DNSSEC=
adds configurations, or equivalent mechanisms to have a trust=20 anchor
2) DNSSEC /IPsec adds overheads (that is more bytes).
 
[Gu= angqing=20 Deng] exactly.
 
In the draft we are not really concerned about the service BUT=20 service
discovery protocol. More specifically this means how you learn your=
printer is at IP XXX using this configuration, not how you connect=20 to
the printer.
 
[Gu= angqing=20 Deng] you are right, but different kinds of services may call for differen= t=20
spe= cific=20 service discovery protocols and thus maybe different security requirements= . For=20 those so-called
tem= porary=20 service, mDNS may be preferred; while for relatively stable service (such = as=20 printing service),
eit= her mDNS=20 or unicast DNS is OK. And DNSSEC is just available in  unicast=20 DNS
but= not mDNS=20 at the moment, so the security requirement may be also=20 different.
 
To be honest I am not sure we have considered the specific service=20 you
are referring to. Maybe you could specify briefly the service and
point out what would bother the service.
 
[Gu= angqing=20 Deng] Fundamentally, only those relatively stable service is suitable to b= e=20 discovered through DNS-based
dis= covery=20 protocol; while with the development of mobile Internet, some temporary=20 service like file (including videos, music, images et al.)
sha= ring=20 becomes more and more popular especially in wireless mesh network lik= e=20 802.11 network. For instance, one may hope
to = share some=20 images or documents to her/his colleagues through 802.11 network in a= =20 particular time period (from 9 am to 10 am, for instance)
dur= ing which=20 all colleagues in the same company can download the files.  = ;So,=20 basicly, there may be two kinds of services in DNSSD WG, one may
be = called=20 long term  service (or stable service?) and the other short term serv= ice=20 (or temporary service?). The former means the service will be
pro= vided in a=20 long time period and thus the frequency of registerring, updating and revo= king=20 the security credential is relatively low. And further some heavy weight <= /DIV>
sec= urity=20 technologies such as IPsec and DNSSEC can be introduced without too m= uch=20 additional traffic. The latter means the service is just
pro= vided in a=20 short time period and thus this kind of service should be discovered and r= evoked=20 in a timely fashion by the service discovery protocol proposed
by = this WG.=20 In this circumstance, mDNS but not unicast DNS may be more preferred, whic= h=20 means that the corresponding security technologies can be used
for= =20 discovering the short term service is different from that for long term se= rvice.=20 So it seems that different kinds of services lead to different security=20 technologies,
dif= ferent=20 additional traffic and thus maybe different security requirement, though b= oth=20 services can be represented by the service instance names with same=20 format.
So = maybe it=20 is time to give a explicit defination to the so-called _service_ in this W= G, but=20 first we should determine which kinds of services is this WG interest= ed=20 in.
And= I still=20 do not have two more formal and clear definitions for these two kinds of=20 services yet at the moment, though I am trying to.
 
I guess the additional overhead depends on how long "temporary" is,=
and to which frequency the service is up. I would be interested to<= /DIV>
have more details on the service you are referring to.
 
What is not so clear to me is that security is the cause of the
problem. Maybe the problem of updating information is due to the=20 DNS
format used to carry the service information. The DNS format impose= s=20 a
modification is efficient after TTL seconds which is the necessary<= /DIV>
time all caches expires. During these TTL seconds, if not properly<= /DIV>
considered, they may be some incoherent information about the=20 service.
Again, a description of the service may clarify this.
 
The next paragraphs attempt to describe the overhead due to the use= =20 of
DNSSEC or IPsec.
 
With IPsec, devices could share a Certificate Authority or a=20 specific
certificate. The service may be configured with this certificate=20 which
would enable to authenticate to protect the mDNS/DNS transactions .= =20 Of
course it needs an initial configuration. IKEv2 adds a 4 packet
exchange over at least the first connection every connection. As a<= /DIV>
result IKEv2 is the additional traffic.
 
With the use of DNSSEC as a certified database, each device /=20 service
may need to register. Again, this may require the DNS to=20 authenticate
the devices. keys associated to devices may be provisioned to the=20 DNS
server.  Then SIG(0) can be used to authenticate the update of= =20 the
service. With DNSSEC you may have to remove security informations
(keys) in the DNS, but even without security you may had to remove=20 the
connectivity inforlation (like IP addreses). As a result it does=20 not
add additional exchanges, but makes message larger. If dnssd uses
mDNS, that is not a centralized database, then the use of DNSSEC=20 does
not adds exchanges, but makes messages largers.
 
 
BR,
Daniel
 
 
 
 
BR
Daniel
 
 
 
On Tue, Jan 21, 2014 at 8:54 AM, Guangqing Deng=20 <dengguangqing@cnnic.cn> wrote:
> Hi, Daniel, so many details on SSD requirements are presented = here,=20 which
> helps me have a more deep understanding on this issue. It is s= aid=20 that IPsec
> and DNSSEC can be used to authenticate the devices tending to=20 provide
> service. While one question is that the deployment of IPsec an= d=20 DNSSEC may
> lead to highly increased traffic within the local network. And= for=20 those
> temporary service providers (which just provide services in a = short=20 time in
> a mesh wireless network, for instance), the process of tempora= ry=20 service
> provider registering on DNSSEC system may be too long compared= with=20 the
> relatively short serving period. Also, the DNSSEC system has t= o=20 revoke the
> public key of the temporary service provider if it has gone=20 off-line. So it
> seems that we should clarify the service mentioned in this WG.= Is=20 the
> service mentioned in this WG means a long-term one or short-te= rm one=20 or
> both?
>
> ________________________________
> Guangqing Deng
> CNNIC
>
> From: Daniel Migault
> Date: 2014-01-19 16:02
> To: dnssd
> CC: Tim Chown; Kerry Lynn
> Subject: [dnssd] draft-ietf-dnssd-requirements-00.txt:=20 Requirements/Security
> Considerations
> Hi Folks,
>
> Here are some additional requirements for
> draft-ietf-dnssd-requirements-00.txt as well as a starting poi= nt for=20 the
> security consideration section. This section has been updated = with=20 Tim's
> comments.
>
> Your are more than welcome to comment/clarify/change the propo= sed=20 text. We
> would appreciate you provide them by Friday January 23 so they= can=20 be
> considered for the next version.
>
> Best Regards,
>
> Daniel
>
> Terminology section:
>
> I think we should add the following terms. I am using used the= m in=20 the
> remaining of the mail. They may be changed for the draft.
>
> mDNS: multicast DNS as defined in [RFC6762]
> SSD: Scalable Service Discovery
> SD DNS-Based Service Discovery [RFC6763]
>
> Requirements section:
>
> I suggest adding or complete existing requirements with the=20 following ones:
>
> SSD SHOULD be designed for both DNS and mDNS working in a=20 cooperative way.
> More specifically, it SHOULD consider interaction between DNS = and=20 mDNS.
>
> SSD SHOULD be able to be performed by client only using DNS an= d=20 unicast to
> avoid multiple multicast messages.
>
> SSD SHOULD work with existing DNS-Based Service Discovery over= mDNS=20 and
> SHOULD NOT break any other discovery protocols.
> As specified in the charter=20 [http://datatracker.ietf.org/wg/dnssd/charter/]
> "The WG will consider the tradeoffs between reusing/extending=20 existing
> protocols and developing entirely new ones. It is highly=20 desirable
> that any new solution is backwardly compatible with existing=20 DNS-SD/mDNS
> deployments. Any solution developed by the dnssd WG must not=20 conflict
> or interfere with the operation of other zero-configuration se= rvice=20 and
> naming protocols such as uPnP or LLMNR. Integration with such=20 protocols
> is out of scope for this WG."
>
> and
>
> "To document challenges and problems encountered in the=20 coexistence
> of zero configuration and global DNS name services in such
> multi-link networks, including consideration of both the name<= /DIV>
> resolution mechanism and the namespace."
>
>
> SSD SHOULD consider the use of globally unique FQDN that is sp= ecific=20 of a
> given network instead of a default domain name as ".local". SS= D=20 SHOULD
> provide means to discover/announce the FQDN associated to the=20 network. A
> default and common FQDN - like ".local." could be used only wh= en=20 the
> specific FQDN of the network has not been determined. Furtherm= ore,=20 in order
> to ease interoperation with DNS the domain name SHOULD follow=20 DNS-compatible
> encoding (i.e ascii or punycode).
>
>
> SSD SHOULD be able to take advantage of network configurations= =20 (DHCP/RA)
> protocol. If it is clear that SSD and DNS SHOULD be able to wo= rk=20 together,
> DHCP may also be used to announce necessary information for th= e=20 network such
> as its associated FQDN (using DHCP Domain Search / DHCP Domain= =20 option / IPv6
> RA [RFC6106]), the interface to register FQDNs... This MAY for= =20 example
> complement or avoid the use of the specific
> b/db/r/dr/lb.dns-sd._udp.<domain> or equivalent queries.=
>
>
> SSD SHOULD be able to announce the scope Service Discovery=20 informations are
> expected to be accessed or multicasted. This requires somethin= g like=20 a
> "scope" discovery protocol.
>
>
> Security Consideration section
>
> Here is some text I propose. Comments are more then welcome! I= hope=20 that we
> will be able to fix this section during the next meeting.
>
>
> 1. Scalable DNS Service is not an extension of SD in term of=20 security
>
> Scalable DNS-Based Service Discovery can hardly rely on the=20 security
> considerations defined for DNS-Based Service Discovery=20 [RFC6763].
> Considering "Scalability" requires new security practices that= are=20 defines
> in this document.
>
> DNS-Based Service Discovery [RFC6763] has been designed so tha= t a=20 device can
> announce a service to the other devices of the network. Althou= gh DNS=20 or mDNS
> can be used for SD, SD has been mostly thought to work over mD= NS to=20 avoid
> DNS zone management and to handle UTF8 names for the end users= even=20 in the
> domain part of the Instance Service Name. As a result SD'=20 security
> considerations rely on mDNS security considerations, DNSSEC=20 [RFC4033] for
> authentication and secure DNS update [RFC3007] to secure DNS=20 update
> [RFC2136]. These considerations are not sufficient for SSD as=20 explained
> below.
>
>     - a) DNSSEC is probably the DNS extens= ion=20 that MAY be used to provide
> authentication and integrity check protection. However,=20 authentication other
> than proof-of-ownership or leap-of-faith security model requir= es=20 trust
> anchors. Trust anchor MAY be provided by the global DNS, but t= his=20 has not
> been specified in SD. Section 10 of RFC6763 illustrates how to= =20 populate the
> DNS with information but clearly states that such interactions= are=20 out of
> scope of RFC6763. Interactions between SSD and DNS cannot be=20 specified in an
> illustrative section.
>
>     - b) Similarly, DNS updates are used b= y SD=20 to cooperate with DNS. These
> interactions are left as illustrative in RFC6763, which is not= =20 sufficient
> for SSD.
>
>     -c) mDNS security considerations are n= ot=20 sufficient for SSD. At first,
> mDNS requires cooperative devices. If cooperative devices is a= =20 reasonable
> assumption in a one hop network such as most home networks, th= is=20 assumption
> cannot be made for larger networks, such as corporate networks= for=20 example.
>
>        In case all devices = cannot=20 trust each other, SD considers the use of
> IPsec or DNSSEC. How these protocols are used is not fully des= cribed=20 in
> RFC6762 and SHOULD be at least documented for SSD. More=20 specifically, DNSSEC
> can be used with different security models. Authentication of = the=20 devices
> may require a chain of trust and interaction with DNS.=20 Alternatively
> authentication may rely on devices configured with certificate= s. In=20 the
> absence of such certificates or chain of trust, a proof-of-own= ership=20 with
> device's reputation may be considered.
>
>       mDNS considers the use of = DNSSEC=20 to differentiate responses from the
> global DNS and mDNS that addresses a local scope. DNSSEC may n= ot be=20 the
> appropriated solution for SSD as DNSSEC may not be deployed fo= r the=20 global
> DNS or for mDNS which would make distinction impossible. As=20 suggested by
> RFC6761, the use of ".local" to specify mDNS may be more=20 appropriated.
>
>       mDNS also raises the issue= of=20 relative domain names (example.com) that
> may be solved as example.com.local. or as example.com.search-d= omain.=20 This
> issue becomes more complex with SSD. For SD there is little=20 ambiguity with
> the meaning of ".local". It is a single link, usually a single= =20 network. SSD
> considers multiple links and as such multiple ".local" and=20 multiple
> different search domain. Thus the question may be which link's= =20 search domain
> is to be considered.
>
>       mDNS considers very few=20 interactions with DNS. The only mentioned case
> is when a global DNS resolution is performed using mDNS. mDNS=20 indicates how
> to treat relative domains. Interaction between mDNS and DNS wa= s not=20 so
> necessary as with one hop network there is a clear separation=20 between the
> local and non local (Internet) network. With multiple networks= , the=20 frontier
> between local and non local becomes much undefined. As result=20 whether naming
> resolution is local (mDNS) or global (DNS) is not obvious. Thi= s is=20 why SSD
> needs to specify interactions between DNS and mDNS whereas DNS= -Based=20 Service
> Discovery [RFC6763] does not. As a result security considerati= ons=20 for SSD
> considers 1) security considerations of SSD over mDNS, 2)=20 security
> considerations of SSD over DNS and 3) security considerations=20 on
> interactions between DNS and mDNS.
>
>
> As a result, security assumption of DNS-Based Service Discover= y=20 [RFC6763]
> are not any more valid for Scalable DNS-Based Service=20 Discovery.
>
> 1) Privacy protection
>
> Information provided by SSD may contain private information th= at is=20 not
> expected to go outside  the specified scope.
>
> Service Discovery carry information about the type of devices=20 available in
> your network, the software version, their location both physic= al=20 like floor
> as well as networking - like the IP address. All these pieces = of=20 information
> may be useful for an intruder. Device and software information= are=20 useful to
> identify vulnerabilities, and location information are useful = to=20 locate the
> target, names may also include information that may be useful = to=20 define a
> specific target - like "Personal CEO Printer". For these reaso= ns,=20 one is
> willing to limit the scope these pieces of information.
>
>     a) Informations spreading may be limit= ed=20 based on network information.
> When DNS is used, the DNS zone SHOULD NOT be accessed by anyon= e from=20 outside
> the specific network. This can be performed at the DNS server = level=20 or at
> the network boundaries by setting firewall policies specifying= which=20 kind of
> IP address can access the DNS server. When mDNS is used,=20 multicasted
> information SHOULD NOT be forwarded outside the expected netwo= rk.=20 This can
> be performed by firewalls that drops outbound/inbound mDNS pac= kets=20 at the
> network boundaries. Note that in both cases, these policies ar= e=20 outside the
> scope of mDNS or DNS. On the other hand, for mobile devices, f= or=20 example,
> which information may be provided depends on the network. Thes= e=20 policies
> have to be implemented by the mobile device.
>
>     b) SSD SHOULD also consider scopes tha= t are=20 not correlated to network
> definitions like 'building' or 'room'. As defined in the=20 charter:
> "It is also desirable that multiple discovery scopes are=20 supported,
> from the point of view of either performing discovery within a=
> specified scope or advertisement within a specified scope, and=
> being able to discover (enumerate) the set of scopes such that=
> an application could then choose to do either. It should be=20 noted
> that scope in this sense might refer to 'building' or 'room' a= nd=20 thus
> might have no correlation to network topology."
>
> This requires 1) definition of the different available scopes.= Some=20 default
> value MAY be provided by the device without knowledge of the=20 specific
> available scopes of the network. Such default values MAY be us= ed by=20 devices
> if they do not discover the different scopes specific to the n= etwork=20 or if
> the device does not have sufficient information to trust the=20 announced
> scopes. In that case the device MAY start with a default limit= ed=20 scope. 2)
> Specific network values SHOULD be announced in an authenticate= d way=20 to avoid
> that, for example,  non existing scope used results in se= rvice=20 unavailable.
> The policy for non existing scopes SHOULD be defined with a re= duced=20 scope,
> and the device SHOULD be informed that the scope does not exis= t so=20 it may
> update its scope. 3) Once devices have been informed of the va= rious=20 scope,
> it MAY chose the one that seems the most appropriated and prov= ide=20 this
> information. Depending on the scope, routers or middle boxes M= AY=20 chose to
> forward the information or not. The information MAY be forward= ed on=20 multiple
> links. With scopes that are not network correlated, the inform= ation=20 MAY be
> forwarded to a subset of devices within a link. The use of=20 distinct
> multicast IP address may be used to distinguish the different=20 scopes.
> However, the use of different IP addresses does not prevent de= vices=20 to
> listen to the information. If the device needs the information= to be=20 read
> only by the members of the scope, cryptography MAY be used to=20 encrypt the
> data. IPsec multicast extension [RFC5374] may be a good candid= ate.=20 This
> mechanism may also be used to prevent an unauthorised device t= o=20 provide a
> service for a given scope. In other words, my printer should n= ot be=20 able to
> announce its service for the "CEO" scope and I should not be a= ble to=20 see the
> announcement of the printer of my CEO.
>
> 2) Exposing Services
>
> A Service announced over a network does not mean the service i= s=20 available to
> anyone. Such services SHOULD enforce access control policies f= or=20 the
> service.
>
> If a connected printer is not using SD, it MAY appear as a sim= ple=20 IP
> connected device attached to the network. Only specific=20 tests/scans/traffic
> monitor can determine the device is a printer. When SD or SSD = is=20 used, as
> soon as the device is plugged on the network everyone knows "P= hoto=20 Color
> Printer, Building A floor 2" has been plugged. If this printer= is=20 reserved
> for the Graphic an Design department, than the printer SHOULD=20 implement
> access control mechanisms. Although these policies are out of = scope=20 of SSD,
> they MAY be required as a consequence of SSD.
>
> 2) Resource exhaustion
>
> With new emerging types of networks like sensor networks and m= ore=20 generally
> the IoT, SSD cannot anymore rely on mDNS and multicast to adve= rtise=20 its
> services and SHOULD provide a dedicated entity that can perfor= m SSD=20 via
> unicast messages. Typically, this can be deployed with a mDNS-= to-DNS=20 agent
> that receives announcement from mDNS devices and stores this=20 information to
> the DNS zone. Since the information is stored, other devices i= n the=20 network
> do not have to receive and treat mDNS announcements.
>
> SSD MUST be able to scale to thousands of devices. The use of=20 multicast for
> service announcement requires that each device informs all oth= er=20 devices
> some information like the hosted service for example. In order= to=20 make sure
> devices always have the information up-to-date or that any new= =20 device has
> the information, the device regularly retransmits the informat= ion to=20 all
> other devices. This is not a scalable architecture as it does = not=20 scale in
> term of bandwidth nor it consider energy consumption constrain= s of=20 small
> devices.
>
> Any messages are bytes received by the devices connected on th= e=20 network,
> which may require additional processing such as cryptographic = check=20 if used
> in conjunction with DNSSEC for example. These devices may rely= on=20 battery,
> and each of these messages directly impact the lifetime of the= =20 device. As a
> result aggressive multicast may unnecessarily affect IoT devic= es.=20 More
> rational approach MAY consists in making possible SSD using=20 unicast
> communications only or to prevent that IoT device wakes up at=20 every
> multicast message or using multicast to announce information u= pdates=20 as
> opposed to cache populating. More specifically, a new device c= an=20 use
> multicast to announce a newly published information. Eventuall= y=20 this
> information may be cached by always-on devices and stored in t= he=20 DNS. A new
> device may get access to these pieces of information with an u= nicast=20 AXFR
> for example. The main advantage is that multicast interface ca= n be=20 switched
> off.
>
> So here we're in similar territory to the discussions about RA= s,=20 and
> multicast on certain types of links, which has led to the=20 efficient-ND
> proposal, and related work on energy efficiency for low power=20 devices etc.
>=20 [http://www.ietf.org/internet-drafts/draft-halpern-6man-nd-pre-resolve-a= ddr-00.txt]
>
> 3) Trusted Scalable Service Discovery
>
> This section is only focused on how information provided by th= e SSD=20 can be
> trusted. As every device announce their service, SSD SHOULD pr= event=20 an
> attacker to announce it is the "CEO Printer" in order to colle= ct=20 all
> documents printed by the CEO.
> In this section, we consider that "CEO Printer" does not exist= s and=20 that the
> attack does not aim at hijacking a specific name. Using the SD= =20 terminology
> "CEO Printer" would be the Instance part of the Service Instan= ce=20 Name.
>
> a) User perspective
> When DNS is used, DNSSEC can be used, and one can trust the=20 information as
> it provides from a trusted party. Although DNSSEC has not been= =20 designed as a
> protocol that certifies the validity of the DNS RDATA, in our = case,=20 DNSSEC
> could be used as such. Contrary to registrars that are hosting= FQDNs=20 they
> have very few knowledge on, network administrators are expecte= d=20 to
> administrated the DNS zone according to the resources availabl= e for=20 the
> network. As a result DNSSEC validation could be interpreted as= =20 "validated by
> the administrator".
>
> mDNS does not have trust anchors provided by DNSSEC. However, = DNSSEC=20 used in
> conjunction of mDNS can be used to provide a proof-of-ownershi= p of=20 the
> information. How reliable is that information can be learned o= ver=20 time by
> processing the reputation of a device (represented by its publ= ic=20 key) or by
> monitoring whether the information remains coherent over time.= For=20 example,
> if a printer announces its IP address as part of the company=20 network, and
> suddenly starts announcing an IP address located somewhere els= e,=20 further
> checks may be performed before trusting the information. Even = though=20 the
> mDNS message signed with DNS cannot be trusted the same way as= it=20 would have
> been trusted in a DNSSEC zone, using DNSSEC in conjunction of = mDNS=20 makes
> possible to assign some pieces of information to a specific ke= y.=20 This helps
> in establishing a reputation as well as avoids spoofed=20 messages.
>
> On a user perspective, mDNS requires the end user to establish= a=20 reputation
> mechanism whereas DNS provides certified information. The main= =20 advantage of
> DNS is that a new end user has certified information which is = not=20 possible
> with mDNS.
>
> [TBD check/compare hybrid model]
>
> b) Devices perspective
>
> When DNS is used, the device MUST be able to provide the infor= mation=20 to the
> DNS server via DNS update [RFC2136] or secure DNS update [RFC3= 007].=20 This
> scenario may not meet a Zero configuration requirement as the = DNS=20 server
> needs to know the public key of the devices, and the device ne= eds to=20 know at
> least the IP address of the DNS server. If DHCPv6 the IP addre= ss of=20 the MAY
> be derived from the Domain Search List and the DNS Recursive N= ame=20 Server
> option [RFC3646]. The device MAY send a DNS query for one doma= in=20 search with
> type NS to the recursive name server. However, registering the= =20 public keys
> of the devices in the DNS does not scale thousands of devices.= Most=20 likely,
> their public keys may be considered as trusted based on reputa= tion,=20 leap of
> faith principles which does not necessarily prevent an attacke= r to=20 set false
> data into the DNS zone.
>
> When mDNS is used, the device does not need any configuration.= =20 This
> information is announced to the network. The information will = be=20 trusted by
> the devices that trust the announcer. As for the DNS, provisio= ning=20 all
> devices of the network with all public keys is not scalable. A= s=20 mentioned
> above, public keys will be trusted most likely based on reputa= tion=20 or leap
> of faith principles.
>
> The main difference between DNS and mDNS seems that DNS requir= es=20 less
> provisioning or configuration than mDNS (n versus n * (n - 1) = for a=20 n device
> network). Then in a zero configuration scenario, DNS centralis= es in=20 a single
> point the way a key can be trusted. The only disadvantage of u= sing=20 DNS is
> the devices should discover the DNS server.
>
> It seems that approach combining mDNS and DNS can take advanta= ge of=20 both.
> Devices announce information using mDNS and the DNS according = to the=20 level
> of trust stores the information in its zone.
>
>
> 4) Information impersonation
>
> The previous section provided considerations on how a device c= an=20 be
> associated to a public key and eventually identified as a trus= ted=20 device.
> With zero configuration, the level of trust associated to a de= vice=20 results
> of a trade off between configuration and a learning process. T= his=20 section
> indicates how information provided by the devices can be monit= ored=20 to
> determine the reputation of a device, to raise an alarm to the=
> administrator, and eventually show a device cannot be trusted = or=20 indicate a
> device has been  corrupted.
>
> The kind of informations provided by SD or SSD that are visibl= e to=20 the end
> user are 1) a name that describes a service and 2) the locatio= n of=20 the
> service. The name of the service corresponds to Service Instan= ce=20 Name. With
> SD the name is mentioned in the RDATA part of the PTR and as t= he key=20 of the
> SRV RRSet. The location of the service is the RDATA part of th= e SRV=20 as well
> as its corresponding locator.
>
> The Service Instance Name is composed of three parts: Instance= ,=20 Service Name
> and Domain. SD recommends that Instance and Domain are encoded= using=20 UTF8.
> UTF8 enables specific characters that are not yet being consid= ered=20 in the
> current DNS. Traditional DNS uses ascii or Punycode. If UTF8 i= s=20 more
> flexible in term of string representation, it may provide mult= iple=20 ways to
> express the same thing which may confuse the end user. In fact= using=20 UTF8
> "My Printer", "my printer" "My printer" are different strings.= This=20 may be
> used by an attacker that will provide a service different in t= erm of=20 UTF8
> format, but that the end user will assimilate to the same serv= ice.=20 In
> addition, "my printer" will be displayed differently if encode= d in=20 UTF8 or
> in ascii. As a result two service "my printer" could be stored= in a=20 DNS zone
> without any collisions.
> One way to avoid multiple format would be to consider the nece= ssary=20 or
> missing characters provided by UTF8 and add them in the Puny=20 code.
> If there may be some advantages in using UTF8 for the service = name,=20 the
> domain name part SHOULD use only the Punycode.
> As a result, checking information for SSD requires to=20 establish
> metrics/similarities between strings.
>
> Worth noting in the DNS the device might be=20 hpprint01.bldg32.somesite.com,
> while its internally stored label may be "Building 32 foyer=20 printer".
>
>
> The location of the service is identified by a FQDN and a=20 corresponding IP
> address. In SD, the FQDN respect the Punnycode encoding. The F= QDN of=20 the
> service may be checked against the known domain names associat= ed to=20 the
> network. Similarly, the IP address is generally used to locate= the=20 service.
> if the IP address is not inside the network, this may raise a=20 warning to the
> administrator, that may validate the IP address.
>
>
> When DNSSEC is used closed names addressed by different keys a= re=20 suspicious.
> Without the use of DNSSEC is becomes hard to detect the device= /SD=20 device has
> not changed their IP address.
>
>
> 5) Unique network identifier
>
> SD uses ".local" prefix to indicate the scope of the FQDN.&nbs= p;=20 ".local" is a
> special use domain name - RFC 6761, and in the registry at
>=20 http://www.iana.org/assignments/special-use-domain-names/special-use-dom= ain-names.xhtml
>
> ".local" is instantiated in any networks. This results in a gi= ven=20 string
> with multiple meanings. "My Printer" at home is not the same s= ervice=20 as "My
> Printer" at work and if the information is cached in some devi= ces,=20 this may
> result in cross site name hijacking. An attacker could for exa= mple=20 advertise
> "My Printer" in a public network like in an airport with a glo= bal=20 IP
> address. The Service Instance Name used could be something as=20 "My
> Printer_ipp_tcp.local SRV global-printer.example.com". People = in the=20 airport
> may then send their documents to "My Printer" advertised in th= e=20 airport -
> that is to say global-printer.example.com -, instead of the on= e of=20 their
> office.
>
> In order to mitigate this confusion, ".local" SHOULD be used o= nly=20 when the
> device does not know the domain name associated to the network= . If=20 DHCPv6 is
> used this may be derived by the DHCPv6 Client FQDN option=20 [RFC4704].
>
> Note also that "My printer" may be a different printer when I = am at=20 home or
> at work. On the other hand, while at hoe I SHOULD be able to u= se "My=20 Office
> Printer" and vice versa. This ambiguity may be leverage by the= use=20 of unique
> prefix.
>
> 6) Compromised device
>
> This section estimates how a compromised device impacts the SS= D=20 service. We
> assume DNSSEC is used.
>
> Once detected, the public key associated to the device is revo= ked.=20 With DNS
> the revocation occurs once in the DNS, and the information is = only=20 stored in
> the remaining caches of devices that have requested the inform= ation=20 before
> it expires. After TTL seconds, the information is revoked from= all=20 devices.
> If mDNS is used, revocation should occur in every device. The=20 mechanism to
> detect a device is compromised is complex and will probably no= t=20 be
> implemented properly in most devices.
>
> With the current SD, a compromised device MAY provide wrong=20 information
> about itself but does not affect others device information.
>
>
>
>
> --
> Daniel Migault
> Orange Labs -- Security
> +33 6 70 72 69 58
 
 
 
--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
------=_001_NextPart061220635831_=------ From cheshire@apple.com Wed Jan 22 21:10:11 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 23C491A0176 for ; Wed, 22 Jan 2014 21:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.437 X-Spam-Level: X-Spam-Status: No, score=-107.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 jCVS65BHaFng for ; Wed, 22 Jan 2014 21:10:09 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 21A411A0136 for ; Wed, 22 Jan 2014 21:10:09 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MZU0076590N46Q0@mail-out.apple.com> for dnssd@ietf.org; Wed, 22 Jan 2014 21:10:08 -0800 (PST) X-AuditID: 11807158-b7efa6d000002d28-60-52e0a430e0d0 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id A3.3C.11560.034A0E25; Wed, 22 Jan 2014 21:10:08 -0800 (PST) Received: from chesh1.apple.com (chesh1.apple.com [17.193.13.41]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MZU005I390W6U40@spicerack.apple.com> for dnssd@ietf.org; Wed, 22 Jan 2014 21:10:08 -0800 (PST) From: Stuart Cheshire In-reply-to: <0C617632-5E53-45CE-859F-33F708B110A4@gmail.com> Date: Wed, 22 Jan 2014 21:10:10 -0800 Content-transfer-encoding: quoted-printable Message-id: <50CBC838-E1C4-4C60-A35B-B4E0A1130131@apple.com> References: <0C617632-5E53-45CE-859F-33F708B110A4@gmail.com> To: Ilya Kulakov X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUi2FCsoWuw5EGQwfcXshbvl85idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqbviQWH+SuuPD7J3sB4jaeLkZNDQsBE4snfHawQtpjEhXvr 2UBsIYHJTBJd7RpdjFxA9iomiQc/7zF1MXJwMAvoSdy/qAVSwwtk7ty7DaxXWCBBYmv/AhYQ m01AS+LF5ytsIOWcArYSLZt5QcIsAqoSl3/uYQaxmQWEJBZc28IOYWtLPHl3gRWknFfARmLv X1GIC2wkHm39BFYuIqApMfnGYagrZSVOn3vOMoFRYBbCPbOQ3DMLydAFjMyrGAWKUnMSK031 EgsKclL1kvNzNzGCw60wYgfj/2VWhxgFOBiVeHgTv9wPEmJNLCuuzD3EKMHBrCTC2zLtQZAQ b0piZVVqUX58UWlOavEhRmkOFiVx3tsPbgUJCaQnlqRmp6YWpBbBZJk4OKUaGLOyulV3H/7T vcDrjJrznR2HjnZ/OzM98ILtsYcGfGcqH+SwbZmrN/V2s0rj+xQndpkrReyzXuUuSp7uVpKs G3ZQbdb5GYJTosuKHhTP+6bvyH5AP79FZn/DVb7M/acFGJ1/OETHNeYfj5hUcs/i61bXuEr5 oxZs/0Qu8K2fLB4Q1/b2190pDEosxRmJhlrMRcWJAL2rYf4zAgAA Cc: dnssd@ietf.org Subject: Re: [dnssd] Encoding limitations of the portion of the Service Instance Name 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, 23 Jan 2014 05:10:11 -0000 On 14 Dec, 2013, at 13:38, Ilya Kulakov wrote: > RFC 6763 states the following regarding the portion: > In addition, because Service Instance Names are not constrained by > the limitations of host names, this document recommends that they be > stored in the DNS, and communicated over the wire, encoded as > straightforward canonical precomposed UTF-8 [RFC3629] "Net-Unicode" > (Unicode Normalization Form C) [RFC5198] text. >=20 > Which looks almost exactly as the portion: > The portion of the Service Instance Name is a user- > friendly name consisting of arbitrary Net-Unicode text [RFC5198]. It > MUST NOT contain ASCII control characters (byte values 0x00-0x1F and > 0x7F) [RFC20]=85 >=20 > Except that the portion does not allow ASCII control = characters. My question is whether such limitation is not set on the = and it indeed allows ASCII control characters? >=20 > Best regards,=20 > Ilya Kulakov You are right. The restrictions for the portion should match = the portion: both disallow ASCII control characters (byte = values 0x00-0x1F and 0x7F). We should publish an update or erratum to clarify this. The intention was to strike the right balance between expressiveness and = restrictiveness. The decision, right or wrong, was to disallow ASCII = control characters as having no conceivable legitimate use in names = (e.g. adding linefeed 0x0A to move the cursor down and overwrite the = next service name in the list, or adding BEL 0x07 to make the computer = go =91beep=92, etc.) but to allow all other Unicode code points. Many of = those other Unicode code points may also have no legitimate use, but we = didn=92t try to make that determination for every Unicode code point. = The ASCII control characters were an obvious thing to disallow, because = we couldn=92t imagine any use for them except mischief. Stuart Cheshire From cheshire@apple.com Wed Jan 22 21:30: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 CC8411A0193 for ; Wed, 22 Jan 2014 21:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.437 X-Spam-Level: X-Spam-Status: No, score=-109.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 ia0Sm1WwfW17 for ; Wed, 22 Jan 2014 21:30:38 -0800 (PST) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id DB3781A01C0 for ; Wed, 22 Jan 2014 21:30:38 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from relay2.apple.com ([17.128.113.67]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MZU007UU9Y6CY90@mail-out.apple.com> for dnssd@ietf.org; Wed, 22 Jan 2014 21:30:20 -0800 (PST) X-AuditID: 11807143-b7fbb6d00000049d-0a-52e0a8ecbabf Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (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 39.01.01181.CE8A0E25; Wed, 22 Jan 2014 21:30:20 -0800 (PST) Received: from chesh1.apple.com (chesh1.apple.com [17.193.13.41]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MZU005OC9YKVN10@spicerack.apple.com> for dnssd@ietf.org; Wed, 22 Jan 2014 21:30:20 -0800 (PST) From: Stuart Cheshire In-reply-to: <20131215155347.GA65994@mx1.yitter.info> Date: Wed, 22 Jan 2014 21:30:24 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <2966D8D9-16B5-4A95-97DC-606BB4338043@gmail.com> <20131215155347.GA65994@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUi2FCsoftmxYMggz2nlSzeL53F6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIlfXzAV/BSv+HdzLmsD42PhLkZODgkBE4ldJ66xQthiEhfu rWfrYuTiEBKYzCTx6+YvVghnFZPEnEPPmbsYOTiYBdQlpkzJBWngFdCT2Ll3GytIWFggRWLL bneQMJuAlsSLz1fYQGxOAVOJh3NXg3WyCKhK3FkeDhJmFhCSWHBtCzuErS3x5N0FVoiJNhIn j/8HaxUSSJf48bqVBcQWEdCRWLHuISPEmbISp889Z5nAKDAL4Z5ZSO6ZhWTqAkbmVYwCRak5 iZVGeokFBTmpesn5uZsYwSFX6LyD8dgyq0OMAhyMSjy8iV/uBwmxJpYVV+YeYpTgYFYS4W2Z 9iBIiDclsbIqtSg/vqg0J7X4EKM0B4uSOO+tB7eCgG5MLEnNTk0tSC2CyTJxcEo1MM53ynMv W3nRKl/+6G0/Nas7/U5RWSrzOGb89rV2tFre/NIuPKzjztbqxA01rFoFsbILPh8TZuLfKdIU sqLv8cRnm46ukL7ztuXVQ/nKnzzb/2p9NW3a9z63+P6Me4kH3v+cG7m8+a/r5yuZBwWUc2t3 8ahVv3JMvj1NRHI5n9S6p+4uNup8rEosxRmJhlrMRcWJAOZtJcQ1AgAA Cc: dnssd@ietf.org Subject: Re: [dnssd] A concrete example of the Punycode fallback variants for the portion 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, 23 Jan 2014 05:30:41 -0000 On 15 Dec, 2013, at 07:53, Andrew Sullivan = wrote: > On Sun, Dec 15, 2013 at 02:15:15PM +0200, Ilya Kulakov wrote: >=20 >> If I have domain is =E2=80=98my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.=D1=80=D1= =84.=E2=80=99 what are the fallback variants? Should I try every = combination: >> =E2=80=98my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.=D1=80=D1=84.=E2=80=99 >> =E2=80=98my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.xn--p1ai.=E2=80=99 >> =E2=80=98my.xn--d1acufc.=D1=80=D1=84.=E2=80=99 >> ''my.xn--d1acufc.xn--p1ai.=E2=80=99 >=20 > This is the only correct answer. You have to cover all possible > combinations. However, the text doesn't read that way. It reads as > though you start label by label: >=20 >> Or I should avoid =E2=80=9Cgaps=E2=80=9D: >> =E2=80=98my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.=D1=80=D1=84.=E2=80=99 >> =E2=80=98my.=D0=B4=D0=BE=D0=BC=D0=B5=D0=BD.xn--p1ai.=E2=80=99 >> ''my.xn--d1acufc.xn--p1ai.=E2=80=99 I realise you may not agree with the design, but the text reads the way = it does intentionally, and, yes, the intent is that you do go label by = label, starting at the right. We wanted a simple linear algorithm, not an n^2 algorithm. And, like = many engineering decisions, that design decision comes with trade offs. = The benefit is that it=E2=80=99s a simple linear search. The consequence = is that it constrains the choice of names. We felt that constraint was = reasonable. 1. Users want rich text for instance names, so they want UTF-8 instance = names, not Punycode, because Punycode doesn=E2=80=99t even allow simple = things like spaces (remember the days when DOS filenames couldn=E2=80=99t = even have spaces in them?). 2. Top-level and second-level domains are likely to be Punycode. So, in any given FQDN, it=E2=80=99s likely that Punycode labels will be = closer to the root, and UTF-8 labels will be closer to the leaves. The algorithm works like this: 1. Upon receiving NXDOMAIN, examine the name in question. Starting at = the root, examine each label in turn, looking for the first label = that=E2=80=99s not composed of letters, digits, and hyphens. Possible = outcomes: 2. No such non-LDH label found. Return NXDOMAIN to caller. 3. A non-LDH label is found. Convert it to Punycode, if possible. If not = possible, return NXDOMAIN to caller, else 4. Repeat query with this UTF-8 label converted to Punycode. If you get = another NXDOMAIN, goto 1. This simple algorithm stores minimal state (just the name currently = being queried for). Any organisation is free to use either Punycode or = UTF-8 labels, as long as the name delegated to them is either LDH or = Punycode =E2=80=94 which is always the case today, and I expect to = remain the case. The constraint is that if your parent organisation has = decided to delegate a UTF-8 name to you, then you also have to use UTF-8 = downstream of that delegation. I don=E2=80=99t foresee this becoming a = realistic problem, which is why the simple linear algorithm was chosen. Stuart Cheshire From cheshire@apple.com Wed Jan 22 21:34: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 43C571A01C0 for ; Wed, 22 Jan 2014 21:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.437 X-Spam-Level: X-Spam-Status: No, score=-107.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 Lh0GeAHKK5LR for ; Wed, 22 Jan 2014 21:34:39 -0800 (PST) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1743B1A003E for ; Wed, 22 Jan 2014 21:34:39 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from relay7.apple.com ([17.128.113.101]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MZU00751A4KCYA0@mail-out.apple.com> for dnssd@ietf.org; Wed, 22 Jan 2014 21:34:38 -0800 (PST) X-AuditID: 11807165-b7f8e6d000004de8-af-52e0a9eea013 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 9A.31.19944.EE9A0E25; Wed, 22 Jan 2014 21:34:38 -0800 (PST) Received: from chesh1.apple.com (chesh1.apple.com [17.193.13.41]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MZU005QHA5QVN10@spicerack.apple.com> for dnssd@ietf.org; Wed, 22 Jan 2014 21:34:38 -0800 (PST) From: Stuart Cheshire In-reply-to: Date: Wed, 22 Jan 2014 21:34:42 -0800 Content-transfer-encoding: quoted-printable Message-id: References: To: Tom Pusateri X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FCsoftu5YMggyVHlC3eL53F6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujHOTVjIWvGav6Fq8ibWBcTlbFyMnh4SAicTzxqVMELaYxIV7 64HiXBxCApOZJJaeWsMI4axiktg/fS57FyMHB7OAnsT9i1ogDbxA5s6921hBwsIC2hKd791A wmwCWhIvPl8Bm88pYCux89oTsPksAqoSx3/cB7OZBYQkFlzbwg5ha0s8eXeBFWKkjcTuby/A aoSA7BVLt4LZIkC9D9ZtY4e4U1bi9LnnLBMYBWYhHDQLyUGzkExdwMi8ilGgKDUnsdJcL7Gg ICdVLzk/dxMjOOgKU3cwNi63OsQowMGoxMOb8OV+kBBrYllxZe4hRgkOZiUR3pZpD4KEeFMS K6tSi/Lji0pzUosPMUpzsCiJ8959cCtISCA9sSQ1OzW1ILUIJsvEwSnVwMjVdU7cNXVpYO/8 o5kM+x4Y8hrU/Wuwll7BE7/0tpvS3iaL0y+OseVOljpW8MqI7f6W3VYZp9a/TJ65+8eful9d IRmO73QFlpbP7+HdJbLrww/n992bO94v1c7co/it08Hc37bqy5nXmr33r7ybH7h5j1R7oY5Z W8G6hWH7GMN2PFia39rBYaDEUpyRaKjFXFScCABMU+qSNgIAAA== Cc: dnssd@ietf.org Subject: Re: [dnssd] service instance names 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, 23 Jan 2014 05:34:40 -0000 On 16 Dec, 2013, at 13:24, Tom Pusateri wrote: > Quick question about service names: >=20 > RFC 6763 describes the general format of service instance names in = Section 4.1: >=20 > Service Instance Name =3D . . >=20 > In looking at an example from an iPhone, I see: >=20 > 934406fa._sub._apple-mobdev2._tcp.local. >=20 > Is the service _apple-mobdev2 and the instance 934406fa._sub? >=20 > Or is the service _sub._apple-mobdev2 and the instance 934406fa? To confirm what others have said, this is a service with subtypes. The service type is =93_apple-mobdev2._tcp=94 To perform simple instance filtering, this service type is defined to = have subtypes -- in this case =93934406fa=94 is the subtype. That name is the owner name of a PTR record. If you look at the rdata of = the PTR record you will see the name of the service being advertised, in = =93 . . =94 format. Stuart Cheshire From cheshire@apple.com Wed Jan 22 21:44:21 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0D51A003E for ; Wed, 22 Jan 2014 21:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.437 X-Spam-Level: X-Spam-Status: No, score=-107.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 WmI-ucFOkfnp for ; Wed, 22 Jan 2014 21:44:19 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 939BF1A0200 for ; Wed, 22 Jan 2014 21:44:18 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MZU007RMALSCYA0@mail-out.apple.com> for dnssd@ietf.org; Wed, 22 Jan 2014 21:44:18 -0800 (PST) X-AuditID: 11807157-b7ff46d000001540-f2-52e0ac32f62e Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id AA.FB.05440.23CA0E25; Wed, 22 Jan 2014 21:44:18 -0800 (PST) Received: from chesh1.apple.com (chesh1.apple.com [17.193.13.41]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MZU005UPALTVN10@spicerack.apple.com> for dnssd@ietf.org; Wed, 22 Jan 2014 21:44:17 -0800 (PST) From: Stuart Cheshire In-reply-to: <20131218221612.GW6418@mx1.yitter.info> Date: Wed, 22 Jan 2014 21:44:21 -0800 Content-transfer-encoding: quoted-printable Message-id: <4363A1E2-C215-4591-80BB-86EBEF0CD1DD@apple.com> References: <558DE89C-4EBA-44E9-A691-A7FCE23E5C25@gmail.com> <20131218221612.GW6418@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUi2FCsoWu05kGQwbR37Bbvl85idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrlDc9gLrnBVTL3Yz9zAeIWji5GTQ0LARGJiyysmCFtM4sK9 9WwgtpDAZCaJVd+Cuhi5gOxVTBIH5l0HSnBwMAvoSdy/qAVSwwtk7ty7jRXEFhawlPjYcpIF xGYT0JJ48fkK2BxOoPkXvx8Ga2URUJVYvskXJMwsICSx4NoWdghbW+LJuwusECNtJDrffWGH OCFNYuq9rYwgtoiAjsSKdQ8ZIc6UlTh97jnLBEaBWQgHzUJy0CwkUxcwMq9iFChKzUmsNNFL LCjISdVLzs/dxAgOucLwHYz/llkdYhTgYFTi4U34cj9IiDWxrLgy9xCjBAezkghvy7QHQUK8 KYmVValF+fFFpTmpxYcYpTlYlMR5bz24FSQkkJ5YkpqdmlqQWgSTZeLglGpg9NW0Zl6dctd4 U8+vXaqCAT3L0+trcr1ubtrDtc146coI+zV/eKduuWVS3L5yNouXi5n1xNjOA5/rT8w6lmQe tP3rn/AqS7aFDKWnmguy1uxc/Zkh2SPxhjDXTiHTNsPNmsYspcFSaTVKs18rM/LofpCL1dPQ POX9YFtX38U/c1zco9PWr6hQYinOSDTUYi4qTgQAQiFXJjUCAAA= Cc: dnssd@ietf.org Subject: Re: [dnssd] Comparison of DNS names with subtype 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, 23 Jan 2014 05:44:22 -0000 On 18 Dec, 2013, at 14:16, Andrew Sullivan = wrote: > On Wed, Dec 18, 2013 at 10:58:27PM +0100, Ilya Kulakov wrote: >=20 >> According to RFC 6763, subtypes have absolutely no constraints and = can be expressed using arbitrary 8-bit data. >=20 > Yes. >=20 >> However, there is the note about comparison: >> Note, however, that even when using arbitrary 8-bit data for >> subtype strings, DNS name comparisons are still case-insensitive, so >> (for example) the byte values 0x41 and 0x61 will be considered >> equivalent for subtype comparison purposes. >=20 > Ugh. This clearly should have been "still case-insensitive for > comparison of ASCII-range characters" or something like that. The DNS > RFCs are quite clear that the case insensitivity is for comparison of > ASCII characters only, because when they were written there was no way > to know what the eventual internationalization story would be. Yes, our intent was merely to remind the reader of case insensitivity as = defined in RFC 1034 -- i.e., US ASCII characters 0x41-0x5A are = equivalent to 0x61-0x7A. There are no other automatic equivalences. This text went in because some developers were using Base64 to generate = subtype strings, and were then caught off-guard when they got matches = they weren=92t expecting. Stuart Cheshire From cheshire@apple.com Wed Jan 22 21:49:05 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 319D21A01F1 for ; Wed, 22 Jan 2014 21:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.437 X-Spam-Level: X-Spam-Status: No, score=-107.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 1UegDOtd0oDf for ; Wed, 22 Jan 2014 21:49:03 -0800 (PST) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id D4DF91A01B5 for ; Wed, 22 Jan 2014 21:49:03 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MZU007ZIATLCYA0@mail-out.apple.com> for dnssd@ietf.org; Wed, 22 Jan 2014 21:49:03 -0800 (PST) X-AuditID: 11807158-b7efa6d000002d28-be-52e0ad4fba77 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id E8.08.11560.F4DA0E25; Wed, 22 Jan 2014 21:49:03 -0800 (PST) Received: from chesh1.apple.com (chesh1.apple.com [17.193.13.41]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MZU005XPATQVN10@spicerack.apple.com> for dnssd@ietf.org; Wed, 22 Jan 2014 21:49:03 -0800 (PST) From: Stuart Cheshire In-reply-to: <20131220201127.GB1369@mx1.yitter.info> Date: Wed, 22 Jan 2014 21:49:07 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <20131220201127.GB1369@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FCsoeu/9kGQwbElohbvl85idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxozmVqaC41wVxy79Ym1g3MjRxcjJISFgIjHjwmFGCFtM4sK9 9WxdjFwcQgKTmSReHLvJDuGsYpLYP+cPcxcjBwezgJ7E/YtaIA28QObOvdtYQWxhAReJ0/N/ sYHYbAJaEi8+XwGzOYEW/F8xH6yGRUBVouP5AmYQm1lASGLBtS3sELa2xJN3F1ghZtpIXHw2 gxFi73pGiQML/zCBJEQEdCRWrHsIdamsxOlzz1kmMArMQjhpFpKTZiEZu4CReRWjQFFqTmKl qV5iQUFOql5yfu4mRnDgFUbsYPy/zOoQowAHoxIPb+KX+0FCrIllxZW5hxglOJiVRHhbpj0I EuJNSaysSi3Kjy8qzUktPsQozcGiJM57+8GtICGB9MSS1OzU1ILUIpgsEwenVAMj68uy3Jd1 UuYTJA0i1Nub7k88nBi7jsk114N/m7+Pq6bO11XLRXK2793m6m19yHbKniKOI+3ZmybvPmhY fWFHw+l/Ig7d4Uf3WXxNUz/8NbdG54OPamXGTHGhBQaCN/bcm/X9GN/L6xLVPzUVOLJ9pV1S T7ye8Mqz/2yJxbmWvuQn8zek8okrsRRnJBpqMRcVJwIA5Ec/RTgCAAA= Cc: dnssd@ietf.org Subject: Re: [dnssd] rfc6762 Multicast DNS A/AAAA additional records 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, 23 Jan 2014 05:49:05 -0000 On 20 Dec, 2013, at 12:11, Andrew Sullivan = wrote: > On Fri, Dec 20, 2013 at 11:25:24AM -0800, Stuart Cheshire wrote: >=20 >> An interesting question would be if we should apply this more = generally: If a device sends a response message containing an NSEC = asserting the non-existence of a AAAA record, should it also volunteer = any A records that do exist for that name? >=20 > In the old-fashioned DNS, of course, such a record would be ignored as > probable poison. If you expect to re-use resolution libraries, then > the answer to the above is therefore "probably not", but if you expect > the libraries to be completely different them I can't see any harm. My view is that the sender should put in any records that it can = reasonably predict are likely to be of use to the receiver. It=92s up to = the receiver=92s algorithm to decide what to accept. I think it=92s unlikely that a receiver will decide that it=92s willing = to accept an NSEC record asserting that, =93this owner name has some A = records but no AAAA records=94, and then at the same time refuse to = believe the actual A records provided in the same packet by the same = sender. If it trusts the NSEC record to assert that the A records exist, = why would it not trust the A records themselves? Stuart Cheshire From cheshire@apple.com Wed Jan 22 23:03:08 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 5C6F41A026F for ; Wed, 22 Jan 2014 23:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.437 X-Spam-Level: X-Spam-Status: No, score=-107.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 wZMjBqNc4EFg for ; Wed, 22 Jan 2014 23:03:06 -0800 (PST) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFED1A025E for ; Wed, 22 Jan 2014 23:03:06 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MZU00CDNE8RM720@mail-out.apple.com> for dnssd@ietf.org; Wed, 22 Jan 2014 23:03:05 -0800 (PST) X-AuditID: 11807157-b7ff46d000001540-2a-52e0bea90757 Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 54.93.05440.9AEB0E25; Wed, 22 Jan 2014 23:03:05 -0800 (PST) Received: from [10.0.1.3] (173-164-252-149-SFBA.hfc.comcastbusiness.net [173.164.252.149]) by jimbu.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MZU00C2HE95Z960@jimbu.apple.com> for dnssd@ietf.org; Wed, 22 Jan 2014 23:03:05 -0800 (PST) From: Stuart Cheshire Date: Wed, 22 Jan 2014 23:03:04 -0800 References: <20140123065829.15432.41228.idtracker@ietfa.amsl.com> To: dnssd@ietf.org Message-id: <0870591F-F018-4A60-B21E-70813C16FDAB@apple.com> X-Mailer: Apple Mail (2.1827) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupiluLIzCtJLcpLzFFi42IRnG6nqrty34Mgg/u92hbvl85idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRsOL9YwFXSIVP3+fY2pgXCHQxcjBISFgInGhy6WLkRPIFJO4 cG89WxcjF4eQQAOTxKO+96wgCSGBvUwSV/6IgdhsAloSLz5fYQOxmYHs9TuPM0HY2hJP3l0A qxcW8JWYOuEXE8h8FgFViRUfSyDGOEr0rt8F1ioiICSxdO4hdhCbV8BG4uu/HkYIW09i47zZ zBCnyUrMP106gZFvFpJls5Asm4WkYwEj8ypGgaLUnMRKE73EgoKcVL3k/NxNjKAQaigM38H4 b5nVIUYBDkYlHt6EL/eDhFgTy4orcw8xSnAwK4nwMqx7ECTEm5JYWZValB9fVJqTWnyIUZqD RUmc99aDW0FCAumJJanZqakFqUUwWSYOTqkGRvOFAkL3rBvuBaadKzmpKa75qV17R/mce+5N h9dPyj3qffQC/4LO28e4y2K2rpmZ/WNNxZvorbsP/KoOsEto+vp7zYomiy9KZ1wVHn+pEXvh k/braHaQ79X7B+833jQPOWBb8pdr3t7d4ct7rzk6TXjy1WjXBd51h5d07D7IusDB4UFZNuNZ nTdKLMUZiYZazEXFiQDo3rftHQIAAA== Subject: [dnssd] Fwd: New Version Notification for draft-cheshire-dnssd-hybrid-01.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, 23 Jan 2014 07:03:08 -0000 I have submitted draft-cheshire-dnssd-hybrid-01. The main change is the addition of section 3.1.1 which discusses application-specific data translation. This section was added in response to operational experience where large numbers of AirPrint printers could result in large DNS replies over TCP, and describes an optimization to trim unnecessary data from such replies. Right now AirPrint is the only case that warrants such optimization, but possibly we might find others. Stuart Cheshire Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-cheshire-dnssd-hybrid-01.txt > Date: 22 January, 2014 at 22:58:29 PST > To: Stuart Cheshire , Stuart Cheshire > > > A new version of I-D, draft-cheshire-dnssd-hybrid-01.txt > has been successfully submitted by Stuart Cheshire and posted to the > IETF repository. > > Name: draft-cheshire-dnssd-hybrid > Revision: 01 > Title: Hybrid Unicast/Multicast DNS-Based Service Discovery > Document date: 2014-01-22 > Group: Individual Submission > Pages: 13 > URL: http://www.ietf.org/internet-drafts/draft-cheshire-dnssd-hybrid-01.txt > Status: https://datatracker.ietf.org/doc/draft-cheshire-dnssd-hybrid/ > Htmlized: http://tools.ietf.org/html/draft-cheshire-dnssd-hybrid-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-cheshire-dnssd-hybrid-01 > > Abstract: > Performing DNS-Based Service Discovery using purely link-local > Multicast DNS enables discovery of services that are on the local > link, but not (without some kind of proxy or similar special support) > of services that are outside the local link. Using a very large > local link with thousands of hosts improves service discovery, but at > the cost of large amounts of multicast traffic. > > Performing DNS-Based Service Discovery using purely Unicast DNS is > more efficient, but requires configuration of DNS Update keys on the > devices offering the services, which can be onerous for simple > devices like printers and network cameras. > > Hence a compromise is needed, that provides easy service discovery > without requiring either large amounts of multicast traffic or > onerous configuration. > > 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 doug.mtview@gmail.com Thu Jan 23 13:54: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 05AF91A0415 for ; Thu, 23 Jan 2014 13:54:06 -0800 (PST) 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 JEjkkXJchNpx for ; Thu, 23 Jan 2014 13:54:03 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id AB1761A03EE for ; Thu, 23 Jan 2014 13:54:03 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id kx10so2404035pab.7 for ; Thu, 23 Jan 2014 13:54:02 -0800 (PST) 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=3hCy7pBe7RiEmjxGNF5FBCObo5nppw9oI/Ku1kGuESw=; b=L5UsqPdxqNHLlkWZiF6yf3Xv+GLNRc0iKA0qnIrac+dGOKAMb9FnbR+pjiuN+1S9iv Jq0NoEPyyCDBqP74CkEFGqj8mg29WEIw7vWU/O+xpIOF15qCJavkDcdgiQCxad3Z5xBf qVy69PuGaziKZHUKPUB8/OLa3JIPapkHtJIgjaWdY4/CbCd2QCYZhGZ7XKuWfnJac3iS eQVzfFqXphah8aYel4C+g1Jp2w5jMyeLc3yHbyNS4QGOP72Qgx1m2Ar1cFHyXBj4K+x6 0sumIAOJlWZyPAtqTbbuaJmF7Oezu9EeX2vSrbl2DGGisiQ1wImmmTCd8KwUMYeHGTeE BgyQ== X-Received: by 10.68.138.165 with SMTP id qr5mr10541539pbb.123.1390514042786; Thu, 23 Jan 2014 13:54:02 -0800 (PST) Received: from [192.168.2.252] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id nu10sm10899205pbb.16.2014.01.23.13.54.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jan 2014 13:54:01 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_51AA60EF-4E70-4339-8283-53665D767C07" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Douglas Otis In-Reply-To: <20140123032553.GC1580@mx1.yitter.info> Date: Thu, 23 Jan 2014 13:53:59 -0800 Message-Id: <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com> References: <20140122222616.GN1271@mx1.yitter.info> <20140123032553.GC1580@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1827) Cc: dnssd@ietf.org Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 23 Jan 2014 21:54:06 -0000 --Apple-Mail=_51AA60EF-4E70-4339-8283-53665D767C07 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 22, 2014, at 7:25 PM, Andrew Sullivan = wrote: > Hi Doug, >=20 > On Wed, Jan 22, 2014 at 05:48:20PM -0800, Douglas Otis wrote: >>=20 >> mDNS. Before going into that, the basis of your MI profile seems >=20 > Why are we discussing the miprofile draft? The _whole point_ of this > new draft is to avoid discussing a solution, because the WG isn't > chartered to come up with one. Dear Andrew, It was the use of "profile" that lead to the consideration of = http://tools.ietf.org/html/draft-sullivan-dnssd-label-miprofile-00. My = apologies, but it was unclear what your use of "profile" meant. There = are serious problems with your draft that discusses profiles. >> services user friendly. mDNS is not DNS nor should protocols >> attempt to use mDNS and DNS interchangeably without a directed >> discovery process. >=20 > I _thought_ the draft as written made clear that this is exactly the > problem: >=20 > Users of applications are, of course, frequently unconcerned with > (not to say oblivious to) the name-resolution system(s) in service = at > any given moment, and are inclined simply to use the same names in > different contexts. As a result, the same string might be tried as = a > name using different name resolution technologies. As I pointed out, mDNS does not represent the only use of UTF-8 for = accessing local services. Various schemes have been around many years = without users being confused by their own local namespace often making = use of local access tools.=20 IMHO, Rbridges http://tools.ietf.org/search/rfc6325 offers a superior = means for transparently extending mDNS within multi-router = (campus/office/home) settings. Switches would not be exposed to = everyone's MAC address while permitting more robust configurations = making better use of limited network deployments. > In my opinion at least, that is the problem we actually have that > caused the formation of the WG, because people want DNS-SD over mDNS > to work outside the link-local context and it doesn't today. If you > think this is a problem not to be solved, then we may have a charter > problem. Rbridges http://tools.ietf.org/search/rfc6325 offers such a solution = without any change to mDNS or DNS. Either way, bridging routers = represents a larger environment where visual presentation represents = normal one-off service selection methods. As such, it seems prudent to = impose constraints defined by IDNA2008 while still permitting = punctuation and spaces since people find this freedom helpful. To = enable effective management of this local namespace, after normalization = there should be only one result for each instance.=20 RFC5198 is too broad to be used to locate services in these larger = settings, IMHO. It seems applying IDNA2008 normalizations and = restrictions while permitting additional punctuation can be implemented = without disrupting use of mDNS by describing any resulting conflicts as = name collisions.=20 While Rbridges seems ideal, using DNS with EDNS0 extensions over = different ports isolates local namespace from that of the Internet. The = namespace in my office offers both local and Internet namespace. Often = access requires some form of authentication for local services, which is = currently being done using a non-standard TLD. I have seen = configurations that employ ".mdns." as a TLD to clarify how the = namespace is resolved. Alas, I don't see that being proffered as a = designated TLD. ".local." works but does not offer a clue for how the = namespace is resolved. Trying to make local and Internet namespaces = appear similar invites greater confusion, IMHO. Regards, Douglas Otis= --Apple-Mail=_51AA60EF-4E70-4339-8283-53665D767C07 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jan 22, 2014, at 7:25 PM, = Andrew Sullivan <ajs@anvilwalrusden.com> = wrote:

Hi Doug,

On Wed, Jan 22, = 2014 at 05:48:20PM -0800, Douglas Otis wrote:

mDNS.  Before going into that, the basis of your = MI profile seems

Why are we discussing the miprofile = draft?  The _whole point_ of this
new draft is to avoid = discussing a solution, because the WG isn't
chartered to come up with = one.

Dear = Andrew,

It was the use of "profile" that lead = to the consideration of http://tools.ietf.org/html/draft-sullivan-dnssd-label-miprofile-00. =  My apologies, but it was unclear what your use of "profile" meant. =  There are serious problems with your draft that discusses = profiles.

services user friendly.  mDNS is not DNS nor should = protocols
attempt to use mDNS and DNS interchangeably without a = directed
discovery process.

I _thought_ the draft = as written made clear that this is exactly the
problem:

  = Users of applications are, of course, frequently unconcerned = with
  (not to say oblivious to) the name-resolution system(s) = in service at
  any given moment, and are inclined simply to use = the same names in
  different contexts.  As a result, the = same string might be tried as a
  name using different name = resolution technologies.

As I = pointed out, mDNS does not represent the only use of UTF-8 for accessing = local services.  Various schemes have been around many years = without users being confused by their own local namespace often making = use of local access tools. 

IMHO, = Rbridges http://tools.ietf.org/search= /rfc6325 offers a superior means for transparently extending = mDNS within multi-router (campus/office/home) settings.  Switches = would not be exposed to everyone's MAC address while permitting more = robust configurations making better use of limited network = deployments.

In my opinion = at least, that is the problem we actually have that
caused the = formation of the WG, because people want DNS-SD over mDNS
to work = outside the link-local context and it doesn't today.  If = you
think this is a problem not to be solved, then we may have a = charter
problem.

Rbridges http://tools.ietf.org/search= /rfc6325 offers such a solution without any change to mDNS or = DNS.  Either way, bridging routers represents a larger environment = where visual presentation represents normal one-off service selection = methods.  As such, it seems prudent to impose constraints defined = by IDNA2008 while still permitting punctuation and spaces since people = find this freedom helpful.  To enable effective management of this = local namespace, after normalization there should be only one result for = each instance. 

RFC5198 is too broad = to be used to locate services in these larger settings, IMHO.  It = seems applying IDNA2008 normalizations and restrictions while permitting = additional punctuation can be implemented without disrupting use of mDNS = by describing any resulting conflicts as name = collisions. 

While Rbridges seems ideal, = using DNS with EDNS0 extensions over different ports isolates local = namespace from that of the Internet.  The namespace in my office = offers both local and Internet namespace.  Often access requires = some form of authentication for local services, which is currently being = done using a non-standard TLD.   I have seen configurations that = employ ".mdns." as a TLD to clarify how the namespace is resolved. =  Alas, I don't see that being proffered as a designated TLD. =  ".local." works but does not offer a clue for how the namespace is = resolved. Trying to make local and Internet namespaces appear similar = invites greater confusion, = IMHO.

Regards,
Douglas = Otis
= --Apple-Mail=_51AA60EF-4E70-4339-8283-53665D767C07-- From ajs@anvilwalrusden.com Fri Jan 24 11:32: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 ED3A91A00F4 for ; Fri, 24 Jan 2014 11:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 s-GT37X4vNuf for ; Fri, 24 Jan 2014 11:32:08 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 7140B1A0047 for ; Fri, 24 Jan 2014 11:32:08 -0800 (PST) Received: from mx1.yitter.info (unknown [64.150.193.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D71638A037 for ; Fri, 24 Jan 2014 19:32:06 +0000 (UTC) Date: Fri, 24 Jan 2014 14:32:05 -0500 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20140124193205.GB2065@mx1.yitter.info> References: <20140122222616.GN1271@mx1.yitter.info> <20140123032553.GC1580@mx1.yitter.info> <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 19:32:10 -0000 Hi Doug, On Thu, Jan 23, 2014 at 01:53:59PM -0800, Douglas Otis wrote: > > It was the use of "profile" that lead to the consideration of http://tools.ietf.org/html/draft-sullivan-dnssd-label-miprofile-00. My apologies, but it was unclear what your use of "profile" meant. There are serious problems with your draft that discusses profiles. > Which "draft that discusses profiles"? We're talking about draft-sullivan-dnssd-mdns-dns-interop-00. The text says, One approach to interoperability under these circumstances is to use a single operational convention for names under the different naming systems. This memo posits such a use profile, and outlines what is necessary to make it work. If your concern is the use of this word "profile", perhaps you can suggest another one? > As I pointed out, mDNS does not represent the only use of UTF-8 for > accessing local services. Correct. But it's the case I happen to be worried about right now. I'm aware how the DNS works. > Various schemes have been around many years without users being > confused by their own local namespace often making use of local > access tools. But our problem -- the actual problem that I'm talking about -- is when users move from one resolution technology to another without taking that into account. I think I state this baldly in the draft. If that's not clear from the text, I'd like to understand how to help make it clearer. > IMHO, Rbridges http://tools.ietf.org/search/rfc6325 offers a > superior means for transparently extending mDNS within multi-router > (campus/office/home) settings. Switches would not be exposed to > everyone's MAC address while permitting more robust configurations > making better use of limited network deployments. Yes, you said that already. But I am not convinced that actually addresses the problem we're talking about, so I don't understand why you think it's relevant. > As such, it seems prudent > to impose constraints defined by IDNA2008 while still permitting > punctuation and spaces since people find this freedom helpful. That sentence says, "It seems wise to impose constraints defined by IDNA2008 and also not to impose those constraints." I'm not sure how to implement (A & ~A) using binary logic. I am a pretty bad programmer, it's true, but I think I got this part right. Could you explain what you mean? (I didn't understand anything more after reading the other two paragraphs I deleted.) Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From mglt.ietf@gmail.com Sun Jan 26 11:58:11 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 7EA761A0096 for ; Sun, 26 Jan 2014 11:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 mg2ujafblEDQ for ; Sun, 26 Jan 2014 11:58:06 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 66B751A0093 for ; Sun, 26 Jan 2014 11:58:05 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id t60so4462250wes.18 for ; Sun, 26 Jan 2014 11:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IkoVSOLvEu9gey8lmt8wYExih96IgckjPjhnQocQNk4=; b=uLrQ8RTbwwPqHB7JS73f+6PXDn0Z6YF9pRn59Ccp+MfMf0W3mdusPMSJCk0CWv5YVM zYGtKR/vx726vhs9q17jRTQ3ENsZVGC2Lg/xEb+ZsXcAaT9Cte3QCd3GyiBQpdSSTqx0 Z5C4gOCCoLGxYc5yAMxW3JkDZ/F1jc8K9Nmem7DtIBC022oiNflUFTOccih6jZ9PXWzl CNWU9wVMESp0QAatbaJQah1XJIX8s3sJeET68VKgozI8yyhWLwqh9OdxphSb0o38fQ6a pKXVl6CJ7J3y9jpMFMYAgf8GdvK3YtHI2KdqprLufDu4l/vC7DxxdvVmrC9ldE/VcsNO /G+A== MIME-Version: 1.0 X-Received: by 10.181.13.165 with SMTP id ez5mr9607146wid.56.1390766282877; Sun, 26 Jan 2014 11:58:02 -0800 (PST) Received: by 10.194.171.129 with HTTP; Sun, 26 Jan 2014 11:58:02 -0800 (PST) In-Reply-To: <20140123114249054035102@cnnic.cn> References: <2014012115540802807511@cnnic.cn> <20140123114249054035102@cnnic.cn> Date: Sun, 26 Jan 2014 20:58:02 +0100 Message-ID: From: Daniel Migault To: Guangqing Deng Content-Type: text/plain; charset=ISO-8859-1 Cc: dnssd Subject: Re: [dnssd] draft-ietf-dnssd-requirements-00.txt: Requirements/Security Considerations 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: Sun, 26 Jan 2014 19:58:11 -0000 Hi, Thanks for the feed backs. We should definitely consider these specific "volatile" services. I have added my comments in the text body. I would be happy to know your thoughts and if it answers your questions. Then we will check how to update the current text ;-) BR, Daniel On Thu, Jan 23, 2014 at 4:42 AM, Guangqing Deng wrote: > Hi, Daniel, three pieces of in-line comments beginning with [Guangqing Deng] > are listed below, please refer to. > > ________________________________ > Guangqing Deng > CNNIC > > > From: Daniel Migault > Date: 2014-01-22 14:55 > To: Guangqing Deng > CC: dnssd > Subject: Re: [dnssd] draft-ietf-dnssd-requirements-00.txt: > Requirements/Security Considerations > Hi Deng, > > Thank you very much for the comments and question. If I understand > correctly your point, you are saying that DNSSEC and IPsec performed > in an authenticated way may add to much overhead on the network for a > temporary service. This may be true on two aspects: 1) IPsec/DNSSEC > adds configurations, or equivalent mechanisms to have a trust anchor > 2) DNSSEC /IPsec adds overheads (that is more bytes). > > > [Guangqing Deng] exactly. > > > In the draft we are not really concerned about the service BUT service > discovery protocol. More specifically this means how you learn your > printer is at IP XXX using this configuration, not how you connect to > the printer. > > > [Guangqing Deng] you are right, but different kinds of services may call for > different > specific service discovery protocols and thus maybe different security > requirements. For those so-called > temporary service, mDNS may be preferred; while for relatively stable > service (such as printing service), > either mDNS or unicast DNS is OK. And DNSSEC is just available in unicast > DNS > but not mDNS at the moment, so the security requirement may be also > different. > You are right. What I mean is that mDNS and DNS can use DNSSEC more or less in the same way. However, use cases addressed by mDNS may miss the chain of trust. As a result DNSSEC may be used only for proof-of-owership. In some case this may be sufficient (especially for long term services). But it is true that for "volatile" services, that is service announced for a very short time once, the interests provided by proof-of-ownership may be limited. Let me know what you think of this text. a) mDNS and DNS unicast as different DNS application transport protocols: mDNS and DNS can be seen as two ways to provide DNS data, and in that sense DNSSEC can be used by both DNS unicast and mDNS. DNSSEC RRsets are DNSKEYS, SIG or NSEC/NSEC3 (although I would not consider NSEC/NSEC3 at first). SIG binds the RRs signed to the key stored in the DNSKEY RRset, thus providing integrity check, and proof-of-ownership. To be able to say the DNSKEY is authoritative and legitimate to announce the service the DNSKEY should be either a trust anchor or signed by a trusted anchor. Being signed by a trust anchor may require some interactions with a central entity which requires additional process. Becoming a trust anchor may be done over time, which of course suppose there is a long term establishment for the service. b) Proof-of-ownership may be sufficient: Proof-of-ownership here means the entity claiming authority to the RR also holds the private key associated to DNSSEY. This binding without kind of certification is useful if a single device is expected to have multiple interactions with the service discovery. (at least broadcasting multiple messages with mDNS). For example service S is announced at IP1, and latter due to renumbering the same service is hosted at IP2. Using proof-of-ownership indicates that the service is announced by the same entity. If the mDNS message is sent by the service itself (like the printer) it means the same printer has changed its IP address. Without the DNSSEC RRsets, one would not have been able to determine whether the service has changed its IP address or whether a new service is being announced or the previous service is being hijacked. If IP1 is re-announced using mDNS, then the bindings asserts that the announcement comes from the same device. Similarly if we combine mDNS and DNS with a mDNS agent that receives mDNS messages and store them in a ".local" DNS unicast zone. Updating the RRset via DNS updates requires a proof-of-ownership. c) Proof-of ownership may not be sufficient There are of course some cases where proof of ownership is not sufficient. In fact proof-of-ownership does not assert the announcer is legitimate. As a result certification may be required for both devices that do not have a learning process of the trusted devices. On the client side, this can be on small devices that do not implement these process or new comer devices that do not have time to perform the learning procedure. On the service side, one-time announcement for "volatile" services do not provides the opportunity to be trusted. First a new comer nodes will not be able to know a service is being announced by the legitimate service. In that case, the new comer device does not have the sufficient time to learn whose device is legitimate. > > To be honest I am not sure we have considered the specific service you > are referring to. Maybe you could specify briefly the service and > point out what would bother the service. > > > [Guangqing Deng] Fundamentally, only those relatively stable service is > suitable to be discovered through DNS-based > discovery protocol; while with the development of mobile Internet, some > temporary service like file (including videos, music, images et al.) > sharing becomes more and more popular especially in wireless mesh network > like 802.11 network. For instance, one may hope > to share some images or documents to her/his colleagues through 802.11 > network in a particular time period (from 9 am to 10 am, for instance) > during which all colleagues in the same company can download the files. So, > basicly, there may be two kinds of services in DNSSD WG, one may > be called long term service (or stable service?) and the other short term > service (or temporary service?). The former means the service will be > provided in a long time period and thus the frequency of registerring, > updating and revoking the security credential is relatively low. And further > some heavy weight > security technologies such as IPsec and DNSSEC can be introduced without too > much additional traffic. The latter means the service is just > provided in a short time period and thus this kind of service should be > discovered and revoked in a timely fashion by the service discovery protocol > proposed > by this WG. In this circumstance, mDNS but not unicast DNS may be more > preferred, which means that the corresponding security technologies can be > used > for discovering the short term service is different from that for long term > service. So it seems that different kinds of services lead to different > security technologies, > different additional traffic and thus maybe different security requirement, > though both services can be represented by the service instance names with > same format. > So maybe it is time to give a explicit defination to the so-called _service_ > in this WG, but first we should determine which kinds of services is this WG > interested in. > And I still do not have two more formal and clear definitions for these two > kinds of services yet at the moment, though I am trying to. > > To me there is no difference with DNS and mDNS. Suppose a DNS listen to the mDNS message and builds a ".local" zone the same a mDNS device would do. As an end user, I will be to send a ".local" query to the DNS, which avoids me to handle mDNS. The main advantage is that such DNS is most likely always on and will be appropriated to define how a device can be trusted over time. In a sense this DNS provides some security features and can reduce the mDNS traffic. A service only needs to announce the service every TTL as the DNS is always on, and does not have to consider new incoming devices. For a service available 1 hour, I would consider: - the service knows a DNS ".local" is associated to a mDNS agent: the service broadcast a mDNS message with a short TTL and then rely on the DNS for being discovered. Once finished, it sends a mDNS update with TTL set to 0. This lead to a service that may be cached TTL while not available anymore. The other way around is to update directly the DNS. In both cases it supposed client prefer the DNS as mDNS. - There is no DNS. In this case, I imagine more the case of mobile phone in a undergrounds announcing service. An these service are available for a few minutes to a few seconds. Suppose I am sharing pictures, or videos. In such cases, it is not obvious you need to authenticate the device, nor to trust it. As a result you may not need to use DNSSEC or any kind of security. Proof-of-ownership may be required to bind the service AND the Service discovery to a single DNSKEY. (cf TLSA in dane). Th euse of key may also help differentiate the different announced services. Note that in both case, the device uses mDNS for announcing the service. In the first case, the DNS keep this information which can be accessed via DNS unicast. This avoids multiple mDNS announcements. In the second case, because we are in a very opportunistic scenario, a single mDNS announcement may be sufficient. This makes announcement easier for the devices. In the first case, end user may only be DNS enable, whereas in second the end user must be mDNS enable. So I agree scenarios may prefer DNS or mDNS, but for very opportunistic scenarios, I still see some interests in using DNSSEC. I agree that it mostly depends on the service and the environment (mDNS agent, DNS present or not for the shared network). > I guess the additional overhead depends on how long "temporary" is, > and to which frequency the service is up. I would be interested to > have more details on the service you are referring to. > > What is not so clear to me is that security is the cause of the > problem. Maybe the problem of updating information is due to the DNS > format used to carry the service information. The DNS format imposes a > modification is efficient after TTL seconds which is the necessary > time all caches expires. During these TTL seconds, if not properly > considered, they may be some incoherent information about the service. > Again, a description of the service may clarify this. > > The next paragraphs attempt to describe the overhead due to the use of > DNSSEC or IPsec. > > With IPsec, devices could share a Certificate Authority or a specific > certificate. The service may be configured with this certificate which > would enable to authenticate to protect the mDNS/DNS transactions . Of > course it needs an initial configuration. IKEv2 adds a 4 packet > exchange over at least the first connection every connection. As a > result IKEv2 is the additional traffic. > > With the use of DNSSEC as a certified database, each device / service > may need to register. Again, this may require the DNS to authenticate > the devices. keys associated to devices may be provisioned to the DNS > server. Then SIG(0) can be used to authenticate the update of the > service. With DNSSEC you may have to remove security informations > (keys) in the DNS, but even without security you may had to remove the > connectivity inforlation (like IP addreses). As a result it does not > add additional exchanges, but makes message larger. If dnssd uses > mDNS, that is not a centralized database, then the use of DNSSEC does > not adds exchanges, but makes messages largers. > > > BR, > Daniel > > > > > BR > Daniel > > > > On Tue, Jan 21, 2014 at 8:54 AM, Guangqing Deng > wrote: >> Hi, Daniel, so many details on SSD requirements are presented here, which >> helps me have a more deep understanding on this issue. It is said that >> IPsec >> and DNSSEC can be used to authenticate the devices tending to provide >> service. While one question is that the deployment of IPsec and DNSSEC may >> lead to highly increased traffic within the local network. And for those >> temporary service providers (which just provide services in a short time >> in >> a mesh wireless network, for instance), the process of temporary service >> provider registering on DNSSEC system may be too long compared with the >> relatively short serving period. Also, the DNSSEC system has to revoke the >> public key of the temporary service provider if it has gone off-line. So >> it >> seems that we should clarify the service mentioned in this WG. Is the >> service mentioned in this WG means a long-term one or short-term one or >> both? >> >> ________________________________ >> Guangqing Deng >> CNNIC >> >> From: Daniel Migault >> Date: 2014-01-19 16:02 >> To: dnssd >> CC: Tim Chown; Kerry Lynn >> Subject: [dnssd] draft-ietf-dnssd-requirements-00.txt: >> Requirements/Security >> Considerations >> Hi Folks, >> >> Here are some additional requirements for >> draft-ietf-dnssd-requirements-00.txt as well as a starting point for the >> security consideration section. This section has been updated with Tim's >> comments. >> >> Your are more than welcome to comment/clarify/change the proposed text. We >> would appreciate you provide them by Friday January 23 so they can be >> considered for the next version. >> >> Best Regards, >> >> Daniel >> >> Terminology section: >> >> I think we should add the following terms. I am using used them in the >> remaining of the mail. They may be changed for the draft. >> >> mDNS: multicast DNS as defined in [RFC6762] >> SSD: Scalable Service Discovery >> SD DNS-Based Service Discovery [RFC6763] >> >> Requirements section: >> >> I suggest adding or complete existing requirements with the following >> ones: >> >> SSD SHOULD be designed for both DNS and mDNS working in a cooperative way. >> More specifically, it SHOULD consider interaction between DNS and mDNS. >> >> SSD SHOULD be able to be performed by client only using DNS and unicast to >> avoid multiple multicast messages. >> >> SSD SHOULD work with existing DNS-Based Service Discovery over mDNS and >> SHOULD NOT break any other discovery protocols. >> As specified in the charter >> [http://datatracker.ietf.org/wg/dnssd/charter/] >> "The WG will consider the tradeoffs between reusing/extending existing >> protocols and developing entirely new ones. It is highly desirable >> that any new solution is backwardly compatible with existing DNS-SD/mDNS >> deployments. Any solution developed by the dnssd WG must not conflict >> or interfere with the operation of other zero-configuration service and >> naming protocols such as uPnP or LLMNR. Integration with such protocols >> is out of scope for this WG." >> >> and >> >> "To document challenges and problems encountered in the coexistence >> of zero configuration and global DNS name services in such >> multi-link networks, including consideration of both the name >> resolution mechanism and the namespace." >> >> >> SSD SHOULD consider the use of globally unique FQDN that is specific of a >> given network instead of a default domain name as ".local". SSD SHOULD >> provide means to discover/announce the FQDN associated to the network. A >> default and common FQDN - like ".local." could be used only when the >> specific FQDN of the network has not been determined. Furthermore, in >> order >> to ease interoperation with DNS the domain name SHOULD follow >> DNS-compatible >> encoding (i.e ascii or punycode). >> >> >> SSD SHOULD be able to take advantage of network configurations (DHCP/RA) >> protocol. If it is clear that SSD and DNS SHOULD be able to work together, >> DHCP may also be used to announce necessary information for the network >> such >> as its associated FQDN (using DHCP Domain Search / DHCP Domain option / >> IPv6 >> RA [RFC6106]), the interface to register FQDNs... This MAY for example >> complement or avoid the use of the specific >> b/db/r/dr/lb.dns-sd._udp. or equivalent queries. >> >> >> SSD SHOULD be able to announce the scope Service Discovery informations >> are >> expected to be accessed or multicasted. This requires something like a >> "scope" discovery protocol. >> >> >> Security Consideration section >> >> Here is some text I propose. Comments are more then welcome! I hope that >> we >> will be able to fix this section during the next meeting. >> >> >> 1. Scalable DNS Service is not an extension of SD in term of security >> >> Scalable DNS-Based Service Discovery can hardly rely on the security >> considerations defined for DNS-Based Service Discovery [RFC6763]. >> Considering "Scalability" requires new security practices that are defines >> in this document. >> >> DNS-Based Service Discovery [RFC6763] has been designed so that a device >> can >> announce a service to the other devices of the network. Although DNS or >> mDNS >> can be used for SD, SD has been mostly thought to work over mDNS to avoid >> DNS zone management and to handle UTF8 names for the end users even in the >> domain part of the Instance Service Name. As a result SD' security >> considerations rely on mDNS security considerations, DNSSEC [RFC4033] for >> authentication and secure DNS update [RFC3007] to secure DNS update >> [RFC2136]. These considerations are not sufficient for SSD as explained >> below. >> >> - a) DNSSEC is probably the DNS extension that MAY be used to provide >> authentication and integrity check protection. However, authentication >> other >> than proof-of-ownership or leap-of-faith security model requires trust >> anchors. Trust anchor MAY be provided by the global DNS, but this has not >> been specified in SD. Section 10 of RFC6763 illustrates how to populate >> the >> DNS with information but clearly states that such interactions are out of >> scope of RFC6763. Interactions between SSD and DNS cannot be specified in >> an >> illustrative section. >> >> - b) Similarly, DNS updates are used by SD to cooperate with DNS. >> These >> interactions are left as illustrative in RFC6763, which is not sufficient >> for SSD. >> >> -c) mDNS security considerations are not sufficient for SSD. At first, >> mDNS requires cooperative devices. If cooperative devices is a reasonable >> assumption in a one hop network such as most home networks, this >> assumption >> cannot be made for larger networks, such as corporate networks for >> example. >> >> In case all devices cannot trust each other, SD considers the use >> of >> IPsec or DNSSEC. How these protocols are used is not fully described in >> RFC6762 and SHOULD be at least documented for SSD. More specifically, >> DNSSEC >> can be used with different security models. Authentication of the devices >> may require a chain of trust and interaction with DNS. Alternatively >> authentication may rely on devices configured with certificates. In the >> absence of such certificates or chain of trust, a proof-of-ownership with >> device's reputation may be considered. >> >> mDNS considers the use of DNSSEC to differentiate responses from the >> global DNS and mDNS that addresses a local scope. DNSSEC may not be the >> appropriated solution for SSD as DNSSEC may not be deployed for the global >> DNS or for mDNS which would make distinction impossible. As suggested by >> RFC6761, the use of ".local" to specify mDNS may be more appropriated. >> >> mDNS also raises the issue of relative domain names (example.com) >> that >> may be solved as example.com.local. or as example.com.search-domain. This >> issue becomes more complex with SSD. For SD there is little ambiguity with >> the meaning of ".local". It is a single link, usually a single network. >> SSD >> considers multiple links and as such multiple ".local" and multiple >> different search domain. Thus the question may be which link's search >> domain >> is to be considered. >> >> mDNS considers very few interactions with DNS. The only mentioned >> case >> is when a global DNS resolution is performed using mDNS. mDNS indicates >> how >> to treat relative domains. Interaction between mDNS and DNS was not so >> necessary as with one hop network there is a clear separation between the >> local and non local (Internet) network. With multiple networks, the >> frontier >> between local and non local becomes much undefined. As result whether >> naming >> resolution is local (mDNS) or global (DNS) is not obvious. This is why SSD >> needs to specify interactions between DNS and mDNS whereas DNS-Based >> Service >> Discovery [RFC6763] does not. As a result security considerations for SSD >> considers 1) security considerations of SSD over mDNS, 2) security >> considerations of SSD over DNS and 3) security considerations on >> interactions between DNS and mDNS. >> >> >> As a result, security assumption of DNS-Based Service Discovery [RFC6763] >> are not any more valid for Scalable DNS-Based Service Discovery. >> >> 1) Privacy protection >> >> Information provided by SSD may contain private information that is not >> expected to go outside the specified scope. >> >> Service Discovery carry information about the type of devices available in >> your network, the software version, their location both physical like >> floor >> as well as networking - like the IP address. All these pieces of >> information >> may be useful for an intruder. Device and software information are useful >> to >> identify vulnerabilities, and location information are useful to locate >> the >> target, names may also include information that may be useful to define a >> specific target - like "Personal CEO Printer". For these reasons, one is >> willing to limit the scope these pieces of information. >> >> a) Informations spreading may be limited based on network information. >> When DNS is used, the DNS zone SHOULD NOT be accessed by anyone from >> outside >> the specific network. This can be performed at the DNS server level or at >> the network boundaries by setting firewall policies specifying which kind >> of >> IP address can access the DNS server. When mDNS is used, multicasted >> information SHOULD NOT be forwarded outside the expected network. This can >> be performed by firewalls that drops outbound/inbound mDNS packets at the >> network boundaries. Note that in both cases, these policies are outside >> the >> scope of mDNS or DNS. On the other hand, for mobile devices, for example, >> which information may be provided depends on the network. These policies >> have to be implemented by the mobile device. >> >> b) SSD SHOULD also consider scopes that are not correlated to network >> definitions like 'building' or 'room'. As defined in the charter: >> "It is also desirable that multiple discovery scopes are supported, >> from the point of view of either performing discovery within a >> specified scope or advertisement within a specified scope, and >> being able to discover (enumerate) the set of scopes such that >> an application could then choose to do either. It should be noted >> that scope in this sense might refer to 'building' or 'room' and thus >> might have no correlation to network topology." >> >> This requires 1) definition of the different available scopes. Some >> default >> value MAY be provided by the device without knowledge of the specific >> available scopes of the network. Such default values MAY be used by >> devices >> if they do not discover the different scopes specific to the network or if >> the device does not have sufficient information to trust the announced >> scopes. In that case the device MAY start with a default limited scope. 2) >> Specific network values SHOULD be announced in an authenticated way to >> avoid >> that, for example, non existing scope used results in service >> unavailable. >> The policy for non existing scopes SHOULD be defined with a reduced scope, >> and the device SHOULD be informed that the scope does not exist so it may >> update its scope. 3) Once devices have been informed of the various scope, >> it MAY chose the one that seems the most appropriated and provide this >> information. Depending on the scope, routers or middle boxes MAY chose to >> forward the information or not. The information MAY be forwarded on >> multiple >> links. With scopes that are not network correlated, the information MAY be >> forwarded to a subset of devices within a link. The use of distinct >> multicast IP address may be used to distinguish the different scopes. >> However, the use of different IP addresses does not prevent devices to >> listen to the information. If the device needs the information to be read >> only by the members of the scope, cryptography MAY be used to encrypt the >> data. IPsec multicast extension [RFC5374] may be a good candidate. This >> mechanism may also be used to prevent an unauthorised device to provide a >> service for a given scope. In other words, my printer should not be able >> to >> announce its service for the "CEO" scope and I should not be able to see >> the >> announcement of the printer of my CEO. >> >> 2) Exposing Services >> >> A Service announced over a network does not mean the service is available >> to >> anyone. Such services SHOULD enforce access control policies for the >> service. >> >> If a connected printer is not using SD, it MAY appear as a simple IP >> connected device attached to the network. Only specific >> tests/scans/traffic >> monitor can determine the device is a printer. When SD or SSD is used, as >> soon as the device is plugged on the network everyone knows "Photo Color >> Printer, Building A floor 2" has been plugged. If this printer is reserved >> for the Graphic an Design department, than the printer SHOULD implement >> access control mechanisms. Although these policies are out of scope of >> SSD, >> they MAY be required as a consequence of SSD. >> >> 2) Resource exhaustion >> >> With new emerging types of networks like sensor networks and more >> generally >> the IoT, SSD cannot anymore rely on mDNS and multicast to advertise its >> services and SHOULD provide a dedicated entity that can perform SSD via >> unicast messages. Typically, this can be deployed with a mDNS-to-DNS agent >> that receives announcement from mDNS devices and stores this information >> to >> the DNS zone. Since the information is stored, other devices in the >> network >> do not have to receive and treat mDNS announcements. >> >> SSD MUST be able to scale to thousands of devices. The use of multicast >> for >> service announcement requires that each device informs all other devices >> some information like the hosted service for example. In order to make >> sure >> devices always have the information up-to-date or that any new device has >> the information, the device regularly retransmits the information to all >> other devices. This is not a scalable architecture as it does not scale in >> term of bandwidth nor it consider energy consumption constrains of small >> devices. >> >> Any messages are bytes received by the devices connected on the network, >> which may require additional processing such as cryptographic check if >> used >> in conjunction with DNSSEC for example. These devices may rely on battery, >> and each of these messages directly impact the lifetime of the device. As >> a >> result aggressive multicast may unnecessarily affect IoT devices. More >> rational approach MAY consists in making possible SSD using unicast >> communications only or to prevent that IoT device wakes up at every >> multicast message or using multicast to announce information updates as >> opposed to cache populating. More specifically, a new device can use >> multicast to announce a newly published information. Eventually this >> information may be cached by always-on devices and stored in the DNS. A >> new >> device may get access to these pieces of information with an unicast AXFR >> for example. The main advantage is that multicast interface can be >> switched >> off. >> >> So here we're in similar territory to the discussions about RAs, and >> multicast on certain types of links, which has led to the efficient-ND >> proposal, and related work on energy efficiency for low power devices etc. >> >> [http://www.ietf.org/internet-drafts/draft-halpern-6man-nd-pre-resolve-addr-00.txt] >> >> 3) Trusted Scalable Service Discovery >> >> This section is only focused on how information provided by the SSD can be >> trusted. As every device announce their service, SSD SHOULD prevent an >> attacker to announce it is the "CEO Printer" in order to collect all >> documents printed by the CEO. >> In this section, we consider that "CEO Printer" does not exists and that >> the >> attack does not aim at hijacking a specific name. Using the SD terminology >> "CEO Printer" would be the Instance part of the Service Instance Name. >> >> a) User perspective >> When DNS is used, DNSSEC can be used, and one can trust the information as >> it provides from a trusted party. Although DNSSEC has not been designed as >> a >> protocol that certifies the validity of the DNS RDATA, in our case, DNSSEC >> could be used as such. Contrary to registrars that are hosting FQDNs they >> have very few knowledge on, network administrators are expected to >> administrated the DNS zone according to the resources available for the >> network. As a result DNSSEC validation could be interpreted as "validated >> by >> the administrator". >> >> mDNS does not have trust anchors provided by DNSSEC. However, DNSSEC used >> in >> conjunction of mDNS can be used to provide a proof-of-ownership of the >> information. How reliable is that information can be learned over time by >> processing the reputation of a device (represented by its public key) or >> by >> monitoring whether the information remains coherent over time. For >> example, >> if a printer announces its IP address as part of the company network, and >> suddenly starts announcing an IP address located somewhere else, further >> checks may be performed before trusting the information. Even though the >> mDNS message signed with DNS cannot be trusted the same way as it would >> have >> been trusted in a DNSSEC zone, using DNSSEC in conjunction of mDNS makes >> possible to assign some pieces of information to a specific key. This >> helps >> in establishing a reputation as well as avoids spoofed messages. >> >> On a user perspective, mDNS requires the end user to establish a >> reputation >> mechanism whereas DNS provides certified information. The main advantage >> of >> DNS is that a new end user has certified information which is not possible >> with mDNS. >> >> [TBD check/compare hybrid model] >> >> b) Devices perspective >> >> When DNS is used, the device MUST be able to provide the information to >> the >> DNS server via DNS update [RFC2136] or secure DNS update [RFC3007]. This >> scenario may not meet a Zero configuration requirement as the DNS server >> needs to know the public key of the devices, and the device needs to know >> at >> least the IP address of the DNS server. If DHCPv6 the IP address of the >> MAY >> be derived from the Domain Search List and the DNS Recursive Name Server >> option [RFC3646]. The device MAY send a DNS query for one domain search >> with >> type NS to the recursive name server. However, registering the public keys >> of the devices in the DNS does not scale thousands of devices. Most >> likely, >> their public keys may be considered as trusted based on reputation, leap >> of >> faith principles which does not necessarily prevent an attacker to set >> false >> data into the DNS zone. >> >> When mDNS is used, the device does not need any configuration. This >> information is announced to the network. The information will be trusted >> by >> the devices that trust the announcer. As for the DNS, provisioning all >> devices of the network with all public keys is not scalable. As mentioned >> above, public keys will be trusted most likely based on reputation or leap >> of faith principles. >> >> The main difference between DNS and mDNS seems that DNS requires less >> provisioning or configuration than mDNS (n versus n * (n - 1) for a n >> device >> network). Then in a zero configuration scenario, DNS centralises in a >> single >> point the way a key can be trusted. The only disadvantage of using DNS is >> the devices should discover the DNS server. >> >> It seems that approach combining mDNS and DNS can take advantage of both. >> Devices announce information using mDNS and the DNS according to the level >> of trust stores the information in its zone. >> >> >> 4) Information impersonation >> >> The previous section provided considerations on how a device can be >> associated to a public key and eventually identified as a trusted device. >> With zero configuration, the level of trust associated to a device results >> of a trade off between configuration and a learning process. This section >> indicates how information provided by the devices can be monitored to >> determine the reputation of a device, to raise an alarm to the >> administrator, and eventually show a device cannot be trusted or indicate >> a >> device has been corrupted. >> >> The kind of informations provided by SD or SSD that are visible to the end >> user are 1) a name that describes a service and 2) the location of the >> service. The name of the service corresponds to Service Instance Name. >> With >> SD the name is mentioned in the RDATA part of the PTR and as the key of >> the >> SRV RRSet. The location of the service is the RDATA part of the SRV as >> well >> as its corresponding locator. >> >> The Service Instance Name is composed of three parts: Instance, Service >> Name >> and Domain. SD recommends that Instance and Domain are encoded using UTF8. >> UTF8 enables specific characters that are not yet being considered in the >> current DNS. Traditional DNS uses ascii or Punycode. If UTF8 is more >> flexible in term of string representation, it may provide multiple ways to >> express the same thing which may confuse the end user. In fact using UTF8 >> "My Printer", "my printer" "My printer" are different strings. This may be >> used by an attacker that will provide a service different in term of UTF8 >> format, but that the end user will assimilate to the same service. In >> addition, "my printer" will be displayed differently if encoded in UTF8 or >> in ascii. As a result two service "my printer" could be stored in a DNS >> zone >> without any collisions. >> One way to avoid multiple format would be to consider the necessary or >> missing characters provided by UTF8 and add them in the Puny code. >> If there may be some advantages in using UTF8 for the service name, the >> domain name part SHOULD use only the Punycode. >> As a result, checking information for SSD requires to establish >> metrics/similarities between strings. >> >> Worth noting in the DNS the device might be hpprint01.bldg32.somesite.com, >> while its internally stored label may be "Building 32 foyer printer". >> >> >> The location of the service is identified by a FQDN and a corresponding IP >> address. In SD, the FQDN respect the Punnycode encoding. The FQDN of the >> service may be checked against the known domain names associated to the >> network. Similarly, the IP address is generally used to locate the >> service. >> if the IP address is not inside the network, this may raise a warning to >> the >> administrator, that may validate the IP address. >> >> >> When DNSSEC is used closed names addressed by different keys are >> suspicious. >> Without the use of DNSSEC is becomes hard to detect the device/SD device >> has >> not changed their IP address. >> >> >> 5) Unique network identifier >> >> SD uses ".local" prefix to indicate the scope of the FQDN. ".local" is a >> special use domain name - RFC 6761, and in the registry at >> >> http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml >> >> ".local" is instantiated in any networks. This results in a given string >> with multiple meanings. "My Printer" at home is not the same service as >> "My >> Printer" at work and if the information is cached in some devices, this >> may >> result in cross site name hijacking. An attacker could for example >> advertise >> "My Printer" in a public network like in an airport with a global IP >> address. The Service Instance Name used could be something as "My >> Printer_ipp_tcp.local SRV global-printer.example.com". People in the >> airport >> may then send their documents to "My Printer" advertised in the airport - >> that is to say global-printer.example.com -, instead of the one of their >> office. >> >> In order to mitigate this confusion, ".local" SHOULD be used only when the >> device does not know the domain name associated to the network. If DHCPv6 >> is >> used this may be derived by the DHCPv6 Client FQDN option [RFC4704]. >> >> Note also that "My printer" may be a different printer when I am at home >> or >> at work. On the other hand, while at hoe I SHOULD be able to use "My >> Office >> Printer" and vice versa. This ambiguity may be leverage by the use of >> unique >> prefix. >> >> 6) Compromised device >> >> This section estimates how a compromised device impacts the SSD service. >> We >> assume DNSSEC is used. >> >> Once detected, the public key associated to the device is revoked. With >> DNS >> the revocation occurs once in the DNS, and the information is only stored >> in >> the remaining caches of devices that have requested the information before >> it expires. After TTL seconds, the information is revoked from all >> devices. >> If mDNS is used, revocation should occur in every device. The mechanism to >> detect a device is compromised is complex and will probably not be >> implemented properly in most devices. >> >> With the current SD, a compromised device MAY provide wrong information >> about itself but does not affect others device information. >> >> >> >> >> -- >> Daniel Migault >> Orange Labs -- Security >> +33 6 70 72 69 58 > > > > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 From doug.mtview@gmail.com Mon Jan 27 17:03: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 0DDD11A0377 for ; Mon, 27 Jan 2014 17:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_45=0.6, 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 e_zPrqqHxp6N for ; Mon, 27 Jan 2014 17:03:39 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E87081A036D for ; Mon, 27 Jan 2014 17:03:38 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id lf10so6625930pab.18 for ; Mon, 27 Jan 2014 17:03:36 -0800 (PST) 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=UMYdQvfewJ8qfu8re92Yirod+qLL5wJ8P14V6vvjR1w=; b=WLPf2OidV0x7/CVrFencQmGuFIOKw1LRtJCWzAqq6E5Rue03ocaqOaQbiCXtJVkFIY EMf2AQqp5BpYWlRit7wb+ZyyuhR4FLj0Smb6TkWLc8hdCyUK+4A02dvwtpzHGoCyjxHF FNxHqfRghu5+CKA/xZXgs+00GEvth2R1sgph/ovgXqdEmUlnhSgyQSpRWhQ7eU+xKsr4 hLu8xnnZUPoE2JGMpVFv8+atmSU+HjN3uIbNTZnMO5A6xcdvByvgKvf9haKW4xArvFlo kYSwzkCH436HgqsIqsWCPlIugTOx59vXtKEYWVkclF1nF5OKchIAAXeYLDzQfrbihQ+J +q2Q== X-Received: by 10.66.175.4 with SMTP id bw4mr33551498pac.56.1390871016729; Mon, 27 Jan 2014 17:03:36 -0800 (PST) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id lh13sm97139673pab.4.2014.01.27.17.03.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Jan 2014 17:03:35 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Douglas Otis In-Reply-To: <20140124193205.GB2065@mx1.yitter.info> Date: Mon, 27 Jan 2014 17:03:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140122222616.GN1271@mx1.yitter.info> <20140123032553.GC1580@mx1.yitter.info> <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com> <20140124193205.GB2065@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1827) Cc: dnssd@ietf.org Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 28 Jan 2014 01:03:41 -0000 Dear Andrew, On Jan 24, 2014, at 11:32 AM, Andrew Sullivan = wrote: > One approach to interoperability under these circumstances is to use > a single operational convention for names under the different naming > systems. This memo posits such a use profile, and outlines what is > necessary to make it work. >=20 > If your concern is the use of this word "profile", perhaps you can > suggest another one? What is meant by "single operational convention" while discussing mDNS = and DNS is difficult to comprehend. These two services are not = operationally similar. One conventional change that could have value are some of the = constraints defined in IDNA2008 that ensure a single valid UTF-8 string = for any apparent visually duplicated instance (except ASCII case = folding). Any such visual duplication created by different UTF-8 = strings might prove problematic when spoofed instance names are = presented prior to legitimate names. These constraints would ensure any = visual presentation offers a single valid UTF-8 result. This would mean = replacing RFC5198 with a document following IDNA2008 sans Puny-code and = A-Labels while permitting various punctuations and spaces. I would be = happy to compose a draft making the appropriate references as a means to = leverage IDNA benefits.=20 This is not to merge mDNS and DNS namespaces. The present operational = strategy depends on the correct mDNS resolution process where ".local." = TLD signifies the necessary convention. Resolving .local. services contained in other non-local networks may = make use of DNS to establish a type of gateway. IMHO,Trill represents a = simpler and more robust alternative. Trill extends multicast via = Rbridges located by their MAC address. Regardless of the access method, = mDNS discovery conventions can be extended with various search domains, = ideally after a user selection process from available local services.=20 >> Various schemes have been around many years without users being >> confused by their own local namespace often making use of local >> access tools. >=20 > But our problem -- the actual problem that I'm talking about -- is > when users move from one resolution technology to another without > taking that into account. I think I state this baldly in the draft. > If that's not clear from the text, I'd like to understand how to help > make it clearer. Perhaps a protocol prefix could remind users a local namespace is = involved. Those developing a proxy or gateway could resolve these = issues. This could be done using curly brackets around instance labels = for example. i.e. {instance}.service.domain. Allow those developing = these services to impose the necessary syntax.=20 The gist of your document seems aimed at unifying the DNS and mDNS = namespace without this providing greater clarity or security. >> IMHO, Rbridges http://tools.ietf.org/search/rfc6325 offers a >> superior means for transparently extending mDNS within multi-router >> (campus/office/home) settings. Switches would not be exposed to >> everyone's MAC address while permitting more robust configurations >> making better use of limited network deployments. >=20 > Yes, you said that already. But I am not convinced that actually > addresses the problem we're talking about, so I don't understand why > you think it's relevant. I hope I have explained this more clearly. The only agreeable aspect = that seems related to your statements would be in regard to ensuring = idempotent results. Am I to assume you don't find that to be a concern? = It seems there are few excuses for taking shortcuts on security. The = results of such shortcuts are likely to prove expensive and difficult to = justify.=20 >> As such, it seems prudent >> to impose constraints defined by IDNA2008 while still permitting >> punctuation and spaces since people find this freedom helpful. >=20 > That sentence says, "It seems wise to impose constraints defined by > IDNA2008 and also not to impose those constraints." > I'm not sure how > to implement (A & ~A) using binary logic. I am a pretty bad > programmer, it's true, but I think I got this part right. Could you > explain what you mean? (I didn't understand anything more after > reading the other two paragraphs I deleted.) There are extensions that ensure mDNS instance labels are supported by = DNS. A gateway, proxy, or Trill bridge could claim a name collision with = any invalid UTF-8 instance as determined by new IDNA2008 constraints. = For Campus/Office/Home networks, Trill offers a more robust, secure, and = scalable solution than possible with a proxy scheme. In addition, Trill = would not greatly expand network limitations imposed on mDNS services, = while likely covering most current needs. I see the mDNS proxy effort = largely aimed at supporting soon to be legacy devices. Regards, Douglas Otis From ajs@anvilwalrusden.com Mon Jan 27 19:50:51 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 D47C41A028A for ; Mon, 27 Jan 2014 19:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.559 X-Spam-Level: ** X-Spam-Status: No, score=2.559 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 atROMEpEHSeA for ; Mon, 27 Jan 2014 19:50:50 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0591A0180 for ; Mon, 27 Jan 2014 19:50:49 -0800 (PST) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 102818A031 for ; Tue, 28 Jan 2014 03:50:46 +0000 (UTC) Date: Mon, 27 Jan 2014 22:50:44 -0500 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20140128035044.GB7975@mx1.yitter.info> References: <20140122222616.GN1271@mx1.yitter.info> <20140123032553.GC1580@mx1.yitter.info> <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com> <20140124193205.GB2065@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 28 Jan 2014 03:50:52 -0000 Hi Doug, On Mon, Jan 27, 2014 at 05:03:34PM -0800, Douglas Otis wrote: > > What is meant by "single operational convention" while discussing > mDNS and DNS is difficult to comprehend. These two services are not > operationally similar. Of course not. _That's the problem_. Let me see if an example will make this more plain. If not, I think I'll have to give up until I hear from someone else about whether this point is clear in the draft (or fail to hear from anyone, in which case I'll infer that the WG just doesn't care about this problem). Suppose we have a device, call it téléviseur1. The device is in use in the Dept of Languages at example university. So its FQDN in the DNS (were it to have one) would be téléviseur1.lang.example.edu. Now, it so happens that Languages is kinda big, and classes have to be all over campus. But profs in the department want to use their devices from all over the campus to get back to télévision, which is the department's content server administered by Languages's IT monkey. Inside the department network, télévision works seamlessly. So IT configures everyone in the department to have a search path of lang.example.edu, and so when just télévision is entered, if there's no mDNS responder for télévision.local (in UTF-8) then the label gets the search path appended after being turned into xn--tlvision-b1ab, and the lookup is xn--tlvision-b1ab.lang.example.edu, and everything is good. Now, suppose instead that the department's content server is called instead "Source de Télévision, Département de Langues". This is great in an mDNS context: DNS-SD will find it just fine. But if you enter "Source de Télévision, Département de Langues.lang.example.edu", the effects are unpredictable. On some systems, that will be passed through to the resolution layer unchanged, and the lookup will match the octets modulo the 0x20 processing of ASCII characters. On other systems, it will be intercepted by the application or the system resolver or both as a potential IDNA label, and processed according to local IDNA rules. Both IDNA2003 and IDNA2008 have trouble with spaces, so we'll have some problems no matter what; IDNA2008 will certainly reject it. If your application is one of those "IDNA2003 except some new stuff we haven't specified", it's hard to know exactly what will happen, but probably whatever would happen with IDNA2003 (because that label's handling ought not to change). The _point_ of the proposal is to say that the first scenario in this example (télévision) works fine, but the second one does not, and so we need a way of making these work together. It's just supposed to say that, and not presuppose any particular solution. > string for any apparent visually duplicated instance This has nothing to do with any of the visual confusion stuff or any of that. > Perhaps a protocol prefix could remind users a local namespace is > involved. This requires users to have a theory of namespaces, which is already very far away from users' needs. > There are extensions that ensure mDNS instance labels are supported > by DNS. There are some labels that DNS-SD recommends that, I claim, cannot be supported in DNS using IDNA. That's all this is about. I do not see how Trill helps this, but I'm sure my ignorance is showing. > I see the mDNS proxy effort largely aimed at supporting soon to be > legacy devices. Again, to the extent I understand you, this sounds like you're arguing that the WG is chartered to cover a non-problem. Is that right? Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From kerlyn2001@gmail.com Tue Jan 28 10:48:49 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0771A0436 for ; Tue, 28 Jan 2014 10:48:49 -0800 (PST) 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 coDF1m7nlwdZ for ; Tue, 28 Jan 2014 10:48:46 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3A89E1A0434 for ; Tue, 28 Jan 2014 10:48:46 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id wp4so847886obc.2 for ; Tue, 28 Jan 2014 10:48:43 -0800 (PST) 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=pG+jE5sJcDVW/e8GkStMv8pw6VdUewQI6dRNKBy8o90=; b=Ui4zpp7RTpd8xijSV9AkjvMP5c8xcr+kOOkKtUDdpXQAlGsSHlMBicsszHQ/ttlb3o NIC6N2TbwjpdrFgI8zRJyGkM/9fG+WQcfKkUsaZ9MBklmu1rTiNZF09LBePHU1oBuQ0+ T+0GosJMVdkKFH2t0pNlCxzHsin/GgTt58JQtg945oevt8ZbU8+Jlub/0FtslpEcAjol v1fiLoPFavDSWMgNEaZoo48WjjFZ2fwJ35iZJNcuV2BlvzVU61ptx39SUdKXUaT6FXsO PHuDXGw5Ufa7zjXbaxEc5pCP0FYM8ztM2HMvCufzb8c5oIaRA/mjRLd0TxdAds3FRRHD dZkQ== MIME-Version: 1.0 X-Received: by 10.182.28.134 with SMTP id b6mr2261714obh.27.1390934923541; Tue, 28 Jan 2014 10:48:43 -0800 (PST) Sender: kerlyn2001@gmail.com Received: by 10.60.83.10 with HTTP; Tue, 28 Jan 2014 10:48:43 -0800 (PST) In-Reply-To: <20140128035044.GB7975@mx1.yitter.info> References: <20140122222616.GN1271@mx1.yitter.info> <20140123032553.GC1580@mx1.yitter.info> <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com> <20140124193205.GB2065@mx1.yitter.info> <20140128035044.GB7975@mx1.yitter.info> Date: Tue, 28 Jan 2014 13:48:43 -0500 X-Google-Sender-Auth: WbzDP_QZbE7mo7U6MAl-_rKUqCw Message-ID: From: Kerry Lynn To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a11c2903c06055c04f10c4661 Cc: dnssd@ietf.org Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 28 Jan 2014 18:48:49 -0000 --001a11c2903c06055c04f10c4661 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jan 27, 2014 at 10:50 PM, Andrew Sullivan w= rote: > Hi Doug, > > On Mon, Jan 27, 2014 at 05:03:34PM -0800, Douglas Otis wrote: > > > > What is meant by "single operational convention" while discussing > > mDNS and DNS is difficult to comprehend. These two services are not > > operationally similar. > > Of course not. _That's the problem_. Let me see if an example will > make this more plain. If not, I think I'll have to give up until I > hear from someone else about whether this point is clear in the draft > (or fail to hear from anyone, in which case I'll infer that the WG > just doesn't care about this problem). > > Suppose we have a device, call it t=E9l=E9viseur1. > > Am I correct that in this example you are referring to what is conventionally called a "host name", that is, the name of the A or AAAA record for a given host? Can we agree that DNS-SD [RFC 6763, section 4.1.3] does not dispute the LDH convention for host names (even though particular implementations may currently allow local UTF-8 host names). We should be more concerned about Service Instance Name labels [ibid] and the issues around importing these into the global DNS. > The device is in use in the Dept of Languages at example university. > So its FQDN in the DNS (were it to have one) would be > t=E9l=E9viseur1.lang.example.edu . > > A better example that would put this more squarely in our WG's wheelhouse might be a service named t=E9l=E9viseur1._http._tcp.lang.example.edu The rdata of the SRV record with this name might contain "0 0 80 some-host.lang.example.edu". Now, it so happens that Languages is kinda big, and classes have to be > all over campus. But profs in the department want to use their > devices from all over the campus to get back to t=E9l=E9vision, which is > the department's content server administered by Languages's IT monkey. > > Inside the department network, t=E9l=E9vision works seamlessly. So IT > configures everyone in the department to have a search path of > lang.example.edu, and so when just t=E9l=E9vision is entered, if there's > no mDNS responder for t=E9l=E9vision.local (in UTF-8) then the label > gets the search path appended after being turned into > xn--tlvision-b1ab, and the lookup is > xn--tlvision-b1ab.lang.example.edu, and everything is good. > > The current UI model for DNS-based service discovery is to select an entr= y from a list, as from a service name browser. Granted, the main example of this today is Apple's Safari browser and it displays all instances of a given service in one big flat list. But let's assume a future where multi-zone browsing is enabled and the user has made the choices "human readable web sites" (_http._tcp) and "lang.example.edu" as the and parts of the Service Instance Name, respectively. What then appears in the list is the set of names that match those constraints. Perhaps complicating this example is the fact that the name of the service already exists in the zone file for "lang.example.edu", inserted there by the IT monkey who used his favorite editor to emit UTF-8. Now, suppose instead that the department's content server is called > instead "Source de T=E9l=E9vision, D=E9partement de Langues". This is gr= eat > in an mDNS context: DNS-SD will find it just fine. But if you enter > "Source de T=E9l=E9vision, D=E9partement de Langues.lang.example.edu", th= e > effects are unpredictable. The format of the user's (service browser) query was for PTR records named "_http._tcp.lang.example.edu". The application receiving the responses is a service name browser. Is there some library in the path that will munge the responses before they get to the application? > On some systems, that will be passed > through to the resolution layer unchanged, and the lookup will match > the octets modulo the 0x20 processing of ASCII characters. On other > systems, it will be intercepted by the application or the system > resolver or both as a potential IDNA label, and processed according to > local IDNA rules. Both IDNA2003 and IDNA2008 have trouble with > spaces, so we'll have some problems no matter what; IDNA2008 will > certainly reject it. If your application is one of those "IDNA2003 > except some new stuff we haven't specified", it's hard to know exactly > what will happen, but probably whatever would happen with IDNA2003 > (because that label's handling ought not to change). > > So have we convinced ourselves that the problem lies not with DNS and the server, but with host-resident resolver libraries? This is an importan= t question, because it potentially divides the problem space in half. The _point_ of the proposal is to say that the first scenario in this > example (t=E9l=E9vision) works fine, but the second one does not, and so > we need a way of making these work together. It's just supposed to > say that, and not presuppose any particular solution. > > I, for one, would find it extremely helpful if the draft went into more depth about WHY the second one does not work and whether this is true in all cases for all time. Just that additional information would seem to constrain the solution space, which I do think is a useful side-effect of the draft. > string for any apparent visually duplicated instance > > This has nothing to do with any of the visual confusion stuff or any > of that. > > > Perhaps a protocol prefix could remind users a local namespace is > > involved. > > This requires users to have a theory of namespaces, which is already > very far away from users' needs. > > That is implied by your use of "lang.example.edu" above. I think as this scales up to K's of instances for a given service, users will either need t= o get comfortable scanning through K's of instance names in a big flat list or deal with hierarchical paths. Many users do have a feeling for folders (directory structures) and files (instances) so maybe we can leverage that experience. > > There are extensions that ensure mDNS instance labels are supported > > by DNS. > > There are some labels that DNS-SD recommends that, I claim, cannot be > supported in DNS using IDNA. That's all this is about. I do not see > how Trill helps this, but I'm sure my ignorance is showing. > > > I see the mDNS proxy effort largely aimed at supporting soon to be > > legacy devices. > > I strongly disagree with this statement. mDNS is becoming more prevalent as time goes on (and one would expect that to continue now that it is a standards track RFC) and there are literally millions of servers deployed that alread= y support it. Again, to the extent I understand you, this sounds like you're arguing > that the WG is chartered to cover a non-problem. Is that right? > > To the extent that some of these services must be made visible in the DNS (the famous homenet "I want to see my home printer from Timbuktu" problem) I think problem is all about Service Instance Names that will work both locally and globally. We are not chartered to solve this problem but to describe it, and I think Andrew's draft is on point (but perhaps not quite there yet). Regards, -K- > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --001a11c2903c06055c04f10c4661 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 27, 2014 at 10:50 PM, Andrew Sullivan <a= js@anvilwalrusden.com> wrote:
<= div class=3D"gmail_quote">
Hi Doug,

On Mon, Jan 27, 2014 at 05:03:34PM -0800, Douglas Otis wrote:
>
> What is meant by "single operational convention" while discu= ssing
> mDNS and DNS is difficult to comprehend. =A0These two services are not=
> operationally similar.

Of course not. =A0_That's the problem_. =A0Let me see if an examp= le will
make this more plain. =A0If not, I think I'll have to give up until I hear from someone else about whether this point is clear in the draft
(or fail to hear from anyone, in which case I'll infer that the WG
just doesn't care about this problem).

Suppose we have a device, call it t=E9l=E9viseur1.

Am I correct that in this example you are referring t= o what is conventionally
called a "host name", that is, the na= me of the A or AAAA record for a given host?
Can we agree tha= t DNS-SD [RFC 6763, section 4.1.3] does not dispute the LDH
convention for host names (even though particular implementation= s may currently
allow local UTF-8 host names).=A0 We should b= e more concerned about Service
Instance Name labels [ibid] and the issue= s around importing these into the global
DNS.
=A0
The device is in use in the Dept of Languages at example university.
So its FQDN in the DNS (were it to have one) would be
t= =E9l=E9viseur1.lang.example.edu.

A better example that would put this more squarely in= our WG's wheelhouse might
be a service named t=E9l=E9viseur1._http._t= cp.lang.example.edu=A0 The rdata of the SRV
record with this name might contain "0 0 80 some-host.lang.example.edu".

Now, it so happens that Languages is kinda big, and classes have to be
all over campus. =A0But profs in the department want to use their
devices from all over the campus to get back to t=E9l=E9vision, which is the department's content server administered by Languages's IT monk= ey.

Inside the department network, t=E9l=E9vision works seamlessly. =A0So IT configures everyone in the department to have a search path of
lang.example.edu,= and so when just t=E9l=E9vision is entered, if there's
no mDNS responder for t=E9l=E9vision.local (in UTF-8) then the label
gets the search path appended after being turned into
xn--tlvision-b1ab, and the lookup is
xn-= -tlvision-b1ab.lang.example.edu, and everything is good.

The current UI model for DNS-based service discovery = is to select an entry
from a list, as from a service name browser.=A0 Gr= anted, the main example of
this today is Apple's Safari browser and = it displays all instances of a given
service in one big flat list.=A0 But let's assume a future where multi-= zone
browsing is enabled and the user has made the choices "human r= eadable
web sites" (_http._tcp) and "lang.example.edu" as the <service name>= ;
and <domain> parts of the Service Instance Name, respectively.=A0 Wha= t then
appears in the list is the set of=A0 <instance> names that = match those constraints.

Perhaps complicating this exampl= e is the fact that the name of the service
already exists in the zone file for "lang.example.edu", inserted there by the
IT monkey who used his favorite editor to emit UTF-8.

Now, suppose instead that the department's content server is called
instead "Source de T=E9l=E9vision, D=E9partement de Langues". =A0= This is great
in an mDNS context: DNS-SD will find it just fine. =A0But if you enter
"Source de T=E9l=E9vision, D=E9partement de Langues.lang.example.edu", the=
effects are unpredictable.

The format of th= e user's (service browser) query was for PTR records named
"_http._tcp.lang.example.edu= ".=A0 The application receiving the responses
is a service name browser.=A0 Is there some library in the path = that will munge
the responses before they get to the applicat= ion?
=A0
=A0On some systems, that will be passed
through to the resolution layer unchanged, and the lookup will match
the octets modulo the 0x20 processing of ASCII characters. =A0On other
systems, it will be intercepted by the application or the system
resolver or both as a potential IDNA label, and processed according to
local IDNA rules. =A0Both IDNA2003 and IDNA2008 have trouble with
spaces, so we'll have some problems no matter what; IDNA2008 will
certainly reject it. =A0If your application is one of those "IDNA2003<= br> except some new stuff we haven't specified", it's hard to know= exactly
what will happen, but probably whatever would happen with IDNA2003
(because that label's handling ought not to change).

So have we convinced ourselves that the problem lies = not with DNS and
the server, but with host-resident resolver = libraries?=A0 This is an important
question, because it poten= tially divides the problem space in half.

The _point_ of the proposal is to say that the first scenario in this
example (t=E9l=E9vision) works fine, but the second one does not, and so we need a way of making these work together. =A0It's just supposed to say that, and not presuppose any particular solution.

I, for one, would find it ext= remely helpful if the draft went into more depth
about WHY th= e second one does not work and whether this is true in all
cases for all time.=A0 Just that additional information would seem to
co= nstrain the solution space, which I do think is a useful side-effect of
= the draft.

> string for any apparent visually duplicated instance

This has nothing to do with any of the visual confusion stuff or any<= br> of that.

> Perhaps a protocol prefix could remind users a local namespace is
> involved.

This requires users to have a theory of namespaces, which is already<= br> very far away from users' needs.

That is implied by your use o= f "lang.example.edu" abov= e.=A0 I think as this
scales up to K's of instances for a given serv= ice, users will either need to
get comfortable scanning through K's of instance names in a = big flat list
or deal with hierarchical paths.=A0 Many users = do have a feeling for folders
(directory structures) and file= s (instances) so maybe we can leverage that
experience.
=A0
> There are extensions that ensure mDNS instance labels are supported > by DNS.

There are some labels that DNS-SD recommends that, I claim, cannot be=
supported in DNS using IDNA. =A0That's all this is about. =A0I do not s= ee
how Trill helps this, but I'm sure my ignorance is showing.

> I see the mDNS proxy effort largely aimed at supporting soon to be
> legacy devices.

I strongly disagree with this statement.=A0 mDN= S is becoming more prevalent as
time goes on (and one would expect that = to continue now that it is a standards
track RFC) and there a= re literally millions of servers deployed that already
support it.=A0

Again, to the extent I understand you, this sounds like you're ar= guing
that the WG is chartered to cover a non-problem. =A0Is that right?

To the extent that some of th= ese services must be made visible in the
DNS (the famous homenet "I= want to see my home printer from Timbuktu"
problem) I think proble= m is all about Service Instance Names that will
work both locally and globally.=A0 We are not chartered to solve this = problem
but to describe it, and I think Andrew's draft is on point (= but perhaps not
quite there yet).

Reg= ards, -K-
=A0
Best regards,

A

--
Andrew Sullivan
ajs@anvilwalrusden.com
___________________________________= ____________
dnssd mailing list
dnssd@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dnssd
--001a11c2903c06055c04f10c4661-- From ajs@anvilwalrusden.com Tue Jan 28 11:08:02 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 193001A0263 for ; Tue, 28 Jan 2014 11:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.559 X-Spam-Level: ** X-Spam-Status: No, score=2.559 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 GL4ekS4lYTyQ for ; Tue, 28 Jan 2014 11:08:00 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 576211A0242 for ; Tue, 28 Jan 2014 11:08:00 -0800 (PST) Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 8B1088A031 for ; Tue, 28 Jan 2014 19:07:57 +0000 (UTC) Date: Tue, 28 Jan 2014 14:07:46 -0500 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20140128190745.GF8796@mx1.yitter.info> References: <20140122222616.GN1271@mx1.yitter.info> <20140123032553.GC1580@mx1.yitter.info> <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com> <20140124193205.GB2065@mx1.yitter.info> <20140128035044.GB7975@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 28 Jan 2014 19:08:02 -0000 On Tue, Jan 28, 2014 at 01:48:43PM -0500, Kerry Lynn wrote: > Am I correct that in this example you are referring to what is > conventionally > called a "host name", that is, the name of the A or AAAA record for a given > host? If I thought there were really one convention for what is meant by "host name", I might be able to answer that question. :-/ But in any case, > Can we agree that DNS-SD [RFC 6763, section 4.1.3] does not dispute the LDH > convention for host names (even though particular implementations may > currently > allow local UTF-8 host names). we most certainly cannot agree about that. 4.1.3 is perfectly clear that it recommends that the owner name in the DNS of a Service Instance Name 'be stored in the DNS, and communicated over the wire, encoded as straightforward canonical precomposed UTF-8 [RFC3629] "Net-Unicode" (Unicode Normalization Form C) [RFC5198] text.' That is quite the opposite of LDH. > We should be more concerned about Service > Instance Name The Service Instance Name in the case of the DNS is the whole name in question -- in DNS terms what is called the "owner name". > > A better example that would put this more squarely in our WG's wheelhouse > might > be a service named > téléviseur1._http._tcp.lang.example.edu No, it's the portion of the Service Instance Name that is the problem. That's why I structured the example as I did. A -- Andrew Sullivan ajs@anvilwalrusden.com From doug.mtview@gmail.com Tue Jan 28 12:01:31 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 49D681A0266 for ; Tue, 28 Jan 2014 12:01:31 -0800 (PST) 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 b0t5tXcgPPus for ; Tue, 28 Jan 2014 12:01:27 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 001611A026C for ; Tue, 28 Jan 2014 12:01:26 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id bj1so810726pad.11 for ; Tue, 28 Jan 2014 12:01:24 -0800 (PST) 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=UVC1RLUitcYShjyfryZeogAhrKcohZES6We4/YRi3Ms=; b=xbyzk9q7bUygpxWhR+xDvJeFrBhM74ze47ZggTB/6lOIKv9hIle/duh4w9zovm6Qg8 QLThVZXjL+pWEwNWsCwQf+ZdlZzZ/AlxNCY6uWpMSnirhsRkVrRM8PbZRm4Pxrha1DVF NncgqaRDdnFcd7TU29ZmOBr9az7Na8a2XG259eB8FW2ILZBAns1djF3+xvojq37wPe+9 rGWGUrRmmWbEzTWutaeMgGRuq2YWsVKEdMoYm/GK6NBYe40KUndOK9POlNVk71uJxg7z 3lMOO+yNMqS5WCYcXUXRix7mtbCxC4H17ORB7vkTBJRTjFLF6IQ8ULUthQsiGvJ0Ao29 41sw== X-Received: by 10.68.108.130 with SMTP id hk2mr3649731pbb.16.1390939283463; Tue, 28 Jan 2014 12:01:23 -0800 (PST) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id sx8sm117309920pab.5.2014.01.28.12.01.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Jan 2014 12:01:21 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_3AF8F3D0-2182-4FED-B4BE-B552C476E6FD" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Douglas Otis In-Reply-To: Date: Tue, 28 Jan 2014 12:01:15 -0800 Message-Id: <775DF8F4-D145-4769-8001-D44BD5ACE82B@gmail.com> References: <20140122222616.GN1271@mx1.yitter.info> <20140123032553.GC1580@mx1.yitter.info> <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com> <20140124193205.GB2065@mx1.yitter.info> <20140128035044.GB7975@mx1.yitter.info> To: Kerry Lynn X-Mailer: Apple Mail (2.1827) Cc: dnssd@ietf.org, Andrew Sullivan Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 28 Jan 2014 20:01:31 -0000 --Apple-Mail=_3AF8F3D0-2182-4FED-B4BE-B552C476E6FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jan 28, 2014, at 10:48 AM, Kerry Lynn wrote: > On Mon, Jan 27, 2014 at 10:50 PM, Andrew Sullivan = wrote: > Hi Doug, >=20 > On Mon, Jan 27, 2014 at 05:03:34PM -0800, Douglas Otis wrote: > > > > What is meant by "single operational convention" while discussing > > mDNS and DNS is difficult to comprehend. These two services are not > > operationally similar. >=20 > Of course not. _That's the problem_. Let me see if an example will > make this more plain. If not, I think I'll have to give up until I > hear from someone else about whether this point is clear in the draft > (or fail to hear from anyone, in which case I'll infer that the WG > just doesn't care about this problem). >=20 > Suppose we have a device, call it t=E9l=E9viseur1. >=20 > Am I correct that in this example you are referring to what is = conventionally > called a "host name", that is, the name of the A or AAAA record for a = given host? > Can we agree that DNS-SD [RFC 6763, section 4.1.3] does not dispute = the LDH > convention for host names (even though particular implementations may = currently > allow local UTF-8 host names). We should be more concerned about = Service > Instance Name labels [ibid] and the issues around importing these into = the global > DNS. > =20 > The device is in use in the Dept of Languages at example university. > So its FQDN in the DNS (were it to have one) would be > t=E9l=E9viseur1.lang.example.edu. >=20 > A better example that would put this more squarely in our WG's = wheelhouse might > be a service named t=E9l=E9viseur1._http._tcp.lang.example.edu The = rdata of the SRV > record with this name might contain "0 0 80 = some-host.lang.example.edu". >=20 > Now, it so happens that Languages is kinda big, and classes have to be > all over campus. But profs in the department want to use their > devices from all over the campus to get back to t=E9l=E9vision, which = is > the department's content server administered by Languages's IT monkey. >=20 > Inside the department network, t=E9l=E9vision works seamlessly. So IT > configures everyone in the department to have a search path of > lang.example.edu, and so when just t=E9l=E9vision is entered, if = there's > no mDNS responder for t=E9l=E9vision.local (in UTF-8) then the label > gets the search path appended after being turned into > xn--tlvision-b1ab, and the lookup is > xn--tlvision-b1ab.lang.example.edu, and everything is good. >=20 > The current UI model for DNS-based service discovery is to select an = entry > from a list, as from a service name browser. Granted, the main = example of > this today is Apple's Safari browser and it displays all instances of = a given > service in one big flat list. But let's assume a future where = multi-zone > browsing is enabled and the user has made the choices "human readable > web sites" (_http._tcp) and "lang.example.edu" as the > and parts of the Service Instance Name, respectively. What = then > appears in the list is the set of names that match those = constraints. >=20 > Perhaps complicating this example is the fact that the name of the = service > already exists in the zone file for "lang.example.edu", inserted there = by the > IT monkey who used his favorite editor to emit UTF-8. >=20 > Now, suppose instead that the department's content server is called > instead "Source de T=E9l=E9vision, D=E9partement de Langues". This is = great > in an mDNS context: DNS-SD will find it just fine. But if you enter > "Source de T=E9l=E9vision, D=E9partement de Langues.lang.example.edu", = the > effects are unpredictable. >=20 > The format of the user's (service browser) query was for PTR records = named > "_http._tcp.lang.example.edu". The application receiving the = responses > is a service name browser. Is there some library in the path that = will munge > the responses before they get to the application? > =20 > On some systems, that will be passed > through to the resolution layer unchanged, and the lookup will match > the octets modulo the 0x20 processing of ASCII characters. On other > systems, it will be intercepted by the application or the system > resolver or both as a potential IDNA label, and processed according to > local IDNA rules. Both IDNA2003 and IDNA2008 have trouble with > spaces, so we'll have some problems no matter what; IDNA2008 will > certainly reject it. If your application is one of those "IDNA2003 > except some new stuff we haven't specified", it's hard to know exactly > what will happen, but probably whatever would happen with IDNA2003 > (because that label's handling ought not to change). >=20 > So have we convinced ourselves that the problem lies not with DNS and > the server, but with host-resident resolver libraries? This is an = important > question, because it potentially divides the problem space in half. >=20 > The _point_ of the proposal is to say that the first scenario in this > example (t=E9l=E9vision) works fine, but the second one does not, and = so > we need a way of making these work together. It's just supposed to > say that, and not presuppose any particular solution. >=20 > I, for one, would find it extremely helpful if the draft went into = more depth > about WHY the second one does not work and whether this is true in all > cases for all time. Just that additional information would seem to > constrain the solution space, which I do think is a useful side-effect = of > the draft. >=20 > > string for any apparent visually duplicated instance >=20 > This has nothing to do with any of the visual confusion stuff or any > of that. >=20 > > Perhaps a protocol prefix could remind users a local namespace is > > involved. >=20 > This requires users to have a theory of namespaces, which is already > very far away from users' needs. >=20 > That is implied by your use of "lang.example.edu" above. I think as = this > scales up to K's of instances for a given service, users will either = need to > get comfortable scanning through K's of instance names in a big flat = list > or deal with hierarchical paths. Many users do have a feeling for = folders > (directory structures) and files (instances) so maybe we can leverage = that > experience. > =20 > > There are extensions that ensure mDNS instance labels are supported > > by DNS. >=20 > There are some labels that DNS-SD recommends that, I claim, cannot be > supported in DNS using IDNA. That's all this is about. I do not see > how Trill helps this, but I'm sure my ignorance is showing. >=20 > > I see the mDNS proxy effort largely aimed at supporting soon to be > > legacy devices. >=20 > I strongly disagree with this statement. mDNS is becoming more = prevalent as > time goes on (and one would expect that to continue now that it is a = standards > track RFC) and there are literally millions of servers deployed that = already > support it. =20 >=20 > Again, to the extent I understand you, this sounds like you're arguing > that the WG is chartered to cover a non-problem. Is that right? >=20 > To the extent that some of these services must be made visible in the > DNS (the famous homenet "I want to see my home printer from Timbuktu" > problem) I think problem is all about Service Instance Names that will > work both locally and globally. We are not chartered to solve this = problem > but to describe it, and I think Andrew's draft is on point (but = perhaps not > quite there yet). Dear Kerry and Andrew, Andrew's concept of a 'single operational convention' for services = outside the ".local." domain is to have discovery use DNS where = applications obtain domain lists provided by DHCP (v4 RFC2131, v6 = RFC3315) or RA DNSSL (v6 RFC6106) where service instances are published = as A-Labels (RFC5891) where users enter matching U-Labels. Any such = instance or domain MUST publish A-Labels, not U-Labels.=20 Facilitating such an approach, network administrators will need to = publish services in DNS as A-Labels with fixed IP address translations = whenever their address on the local network is not global. In essence = this means spaces, punctuation, and UTF-8 sequences declared illegal in = IDNA2008 can not be used. While SRV and PTR placed in DNS can = facilitate discovery, DNS itself has no way to know when a service is = active. As such, all possible services and addresses will require fixed = global translations that are problematic within constrained resources. Andrew's approach is likely to expose cryptic puny-coded labels in a = less friendly format nor does it solve the need for ad-hoc local = resolutions.=20 The current concept is to provide mDNS gateways to transparently extend = the local network. IMHO, an Rbridge (RFC6325) represents a generic = solution that does not impact either DNS or mDNS. IMHO, the WG hopes to = offer similar solutions when an Rbridge is not available. The IS-IS = approach used in Rbridge is more scalable and does not impose path = constraints causing undesirable bottle-necks. With the ever increasing = use of video over WiFi, such bottle-necks represent a growing concern. Regards, Douglas Otis= --Apple-Mail=_3AF8F3D0-2182-4FED-B4BE-B552C476E6FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Jan 28, 2014, at 10:48 AM, Kerry = Lynn <kerlyn@ieee.org> = wrote:

On Mon, Jan 27, 2014 at 10:50 PM, Andrew = Sullivan <ajs@anvilwalrusden.com> wrote:
Hi Doug,

On Mon, Jan 27, 2014 at 05:03:34PM -0800, Douglas Otis wrote:
>
> What is meant by "single operational convention" while = discussing
> mDNS and DNS is difficult to comprehend.  These two services = are not
> operationally similar.

Of course not.  _That's the problem_.  Let me see if an = example will
make this more plain.  If not, I think I'll have to give up until = I
hear from someone else about whether this point is clear in the = draft
(or fail to hear from anyone, in which case I'll infer that the WG
just doesn't care about this problem).

Suppose we have a device, call it t=E9l=E9viseur1.

Am I correct that in this example you are = referring to what is conventionally
called a "host name", that is, = the name of the A or AAAA record for a given host?
Can we = agree that DNS-SD [RFC 6763, section 4.1.3] does not dispute the LDH
convention for host names (even though particular = implementations may currently
allow local UTF-8 host = names).  We should be more concerned about Service
Instance Name = labels [ibid] and the issues around importing these into the global
DNS.
 
The device is in use in the Dept of Languages at example university.
So its FQDN in the DNS (were it to have one) would be
t=E9l=E9viseur1.lang.example.edu.

A better example that would put this more squarely = in our WG's wheelhouse might
be a service named t=E9l=E9viseur1._http._tcp.lang.example.edu  = The rdata of the SRV
record with this name might contain "0 0 80 some-host.lang.example.edu= ".

Now, it so happens that Languages is kinda big, and classes have to = be
all over campus.  But profs in the department want to use their
devices from all over the campus to get back to t=E9l=E9vision, which = is
the department's content server administered by Languages's IT = monkey.

Inside the department network, t=E9l=E9vision works seamlessly.  So = IT
configures everyone in the department to have a search path of
lang.example.edu, and so when just t=E9l=E9vision = is entered, if there's
no mDNS responder for t=E9l=E9vision.local (in UTF-8) then the label
gets the search path appended after being turned into
xn--tlvision-b1ab, and the lookup is
xn--tlvision-b1ab.lang.example.edu, and everything = is good.

The current UI model for DNS-based service = discovery is to select an entry
from a list, as from a service name = browser.  Granted, the main example of
this today is Apple's = Safari browser and it displays all instances of a given
service in one big flat list.  But let's assume a future where = multi-zone
browsing is enabled and the user has made the choices = "human readable
web sites" (_http._tcp) and "lang.example.edu" as the = <service name>
and <domain> parts of the Service Instance Name, = respectively.  What then
appears in the list is the set of  = <instance> names that match those = constraints.

Perhaps complicating this example is the = fact that the name of the service
already exists in the zone file for "lang.example.edu", inserted there = by the
IT monkey who used his favorite editor to emit = UTF-8.

Now, suppose instead that the department's content server is called
instead "Source de T=E9l=E9vision, D=E9partement de Langues".  This = is great
in an mDNS context: DNS-SD will find it just fine.  But if you = enter
"Source de T=E9l=E9vision, D=E9partement de Langues.lang.example.edu", the
effects are unpredictable.

The format of = the user's (service browser) query was for PTR records = named
"_http._tcp.lang.example.edu".  = The application receiving the responses
is a service name browser.  Is there some library in the = path that will munge
the responses before they get to the = application?
 
 On some systems, that will be passed
through to the resolution layer unchanged, and the lookup will match
the octets modulo the 0x20 processing of ASCII characters.  On = other
systems, it will be intercepted by the application or the system
resolver or both as a potential IDNA label, and processed according = to
local IDNA rules.  Both IDNA2003 and IDNA2008 have trouble with
spaces, so we'll have some problems no matter what; IDNA2008 will
certainly reject it.  If your application is one of those = "IDNA2003
except some new stuff we haven't specified", it's hard to know = exactly
what will happen, but probably whatever would happen with IDNA2003
(because that label's handling ought not to change).

So have we convinced ourselves that the problem = lies not with DNS and
the server, but with host-resident = resolver libraries?  This is an important
question, = because it potentially divides the problem space in half.

The _point_ of the proposal is to say that the first scenario in = this
example (t=E9l=E9vision) works fine, but the second one does not, and = so
we need a way of making these work together.  It's just supposed = to
say that, and not presuppose any particular solution.

I, for one, would find it = extremely helpful if the draft went into more depth
about = WHY the second one does not work and whether this is true in = all
cases for all time.  Just that additional information would seem = to
constrain the solution space, which I do think is a useful = side-effect of
the draft.

> string for any apparent visually duplicated instance

This has nothing to do with any of the visual confusion stuff or = any
of that.

> Perhaps a protocol prefix could remind users a local namespace = is
> involved.

This requires users to have a theory of namespaces, which is = already
very far away from users' needs.

That is implied by your = use of "lang.example.edu" = above.  I think as this
scales up to K's of instances for a = given service, users will either need to
get comfortable scanning through K's of instance names in a = big flat list
or deal with hierarchical paths.  Many = users do have a feeling for folders
(directory structures) = and files (instances) so maybe we can leverage that
experience.
 
> There are extensions that ensure mDNS instance labels are = supported
> by DNS.

There are some labels that DNS-SD recommends that, I claim, cannot = be
supported in DNS using IDNA.  That's all this is about.  I do = not see
how Trill helps this, but I'm sure my ignorance is showing.

> I see the mDNS proxy effort largely aimed at supporting soon to = be
> legacy devices.

I strongly disagree with this = statement.  mDNS is becoming more prevalent as
time goes on (and = one would expect that to continue now that it is a = standards
track RFC) and there are literally millions of = servers deployed that already
support it. 

Again, to the extent I understand you, this sounds like you're = arguing
that the WG is chartered to cover a non-problem.  Is that = right?

To the extent that some of = these services must be made visible in the
DNS (the famous homenet "I = want to see my home printer from Timbuktu"
problem) I think problem = is all about Service Instance Names that will
work both locally and globally.  We are not chartered to solve = this problem
but to describe it, and I think Andrew's draft is on = point (but perhaps not
quite there = yet).

De= ar Kerry and Andrew,

Andrew's concept of a = 'single operational convention' for services outside the ".local." = domain is to have discovery use DNS where applications obtain domain = lists provided by DHCP (v4  RFC2131, v6 RFC3315) or RA DNSSL (v6 = RFC6106) where service instances are published as A-Labels (RFC5891) = where users enter matching U-Labels.  Any such instance or domain = MUST publish A-Labels, not = U-Labels. 

Facilitating such an approach, = network administrators will need to publish services in DNS as A-Labels = with fixed IP address translations whenever their address on the local = network is not global.  In essence this means spaces, punctuation, = and UTF-8 sequences declared illegal in IDNA2008 can not be used. =  While SRV and PTR placed in DNS can facilitate discovery, DNS = itself has no way to know when a service is active.  As such, all = possible services and addresses will require fixed global translations = that are problematic within constrained = resources.

Andrew's approach is likely to = expose cryptic puny-coded labels in a less friendly format nor does it = solve the need for ad-hoc local = resolutions. 

The current concept is to = provide mDNS gateways to transparently extend the local network. =  IMHO, an Rbridge (RFC6325) represents a generic solution that does = not impact either DNS or mDNS.  IMHO, the WG hopes to offer similar = solutions when an Rbridge is not available.  The IS-IS approach = used in Rbridge is more scalable and does not impose path constraints = causing undesirable bottle-necks.  With the ever increasing use of = video over WiFi, such bottle-necks represent a growing = concern.

Regards,
Douglas = Otis
= --Apple-Mail=_3AF8F3D0-2182-4FED-B4BE-B552C476E6FD-- From brian.peter.dickson@gmail.com Tue Jan 28 12:36: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 AD3ED1A026C for ; Tue, 28 Jan 2014 12:36:47 -0800 (PST) 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 Ow6V6z8OsxoE for ; Tue, 28 Jan 2014 12:36:45 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 30B7C1A024C for ; Tue, 28 Jan 2014 12:36:45 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id at1so1110131iec.11 for ; Tue, 28 Jan 2014 12:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4yd285c9PZ9c5IF/GdDKhtnVZoBVdEP3gGHxpmVLL3g=; b=PeVSArRuwng41O0XeLw8Nk6fsHmF4sP2mwiRCQ+9aTpx/tKOJsoPp/JAWvLhw62TDI iQwfqPinmLoLHTkg7PwSIjNVHII9BQ9F2wyBv39HG54jBvJToJHeuU7tWz1MraYSLSXU J/wJlw8Y25XfrcUkCfqI4wGB1tFloqUCLGBgdnkRoyJYUXQBylp+PRvpN0Y5jFA988Jk O2X/ukiqq72cMlliuxrIa4EdTElNUG+iZIzrP47uZBrwcLK1Outwta4nag1vVxYQBDiN HcmPs2HyWZEMsXlqpV7e4A5mjrQnxG5R16xlx3grzqH5Xs/NqFiUbxv3nPRv8BClkGo1 ZMeg== MIME-Version: 1.0 X-Received: by 10.42.62.196 with SMTP id z4mr2819629ich.49.1390941402574; Tue, 28 Jan 2014 12:36:42 -0800 (PST) Received: by 10.64.245.243 with HTTP; Tue, 28 Jan 2014 12:36:42 -0800 (PST) In-Reply-To: <20140128035044.GB7975@mx1.yitter.info> References: <20140122222616.GN1271@mx1.yitter.info> <20140123032553.GC1580@mx1.yitter.info> <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com> <20140124193205.GB2065@mx1.yitter.info> <20140128035044.GB7975@mx1.yitter.info> Date: Tue, 28 Jan 2014 15:36:42 -0500 Message-ID: From: Brian Dickson To: Andrew Sullivan Content-Type: multipart/alternative; boundary=90e6ba614a7634363304f10dc803 Cc: dnssd@ietf.org Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 28 Jan 2014 20:36:47 -0000 --90e6ba614a7634363304f10dc803 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jan 27, 2014 at 10:50 PM, Andrew Sullivan w= rote: > Hi Doug, > > On Mon, Jan 27, 2014 at 05:03:34PM -0800, Douglas Otis wrote: > > If not, I think I'll have to give up until I > hear from someone else about whether this point is clear in the draft > (or fail to hear from anyone, in which case I'll infer that the WG > just doesn't care about this problem). > > I'd like to add my support for discussing this issue, and I think this document is a good start. > > The _point_ of the proposal is to say that the first scenario in this > example (t=E9l=E9vision) works fine, but the second one does not, and so > we need a way of making these work together. It's just supposed to > say that, and not presuppose any particular solution. > > I'd like to attempt to articulate where I think the problem resides, and illustrate the location. I have a rough idea on one way to address this, by adding one level of indirection. (NOT using any existing DNS indirection, but rather on the UI side, which necessarily has impact on existing DNS-SD designs - but which I think is fairly clean. I leave it to those doing DNS-SD to address the feasibility of doing this.) Basically, the problem is attempting to wedge a "UI label" into a place where a DNS label is required (per DNS protocol). The location of the problematic stuff is "" component in the DNS-SD ... Clearly, the free-wheeling nature of local user-entered "labels" requires both input and select-from-list to have the entire kitchen sink of potential "labels" available. However, adding one single 1:1 label identifier, provides a clear, clean, interoperable way of supporting the input/selection function, while also preserving a DNS-friendly owner name. This would require some DNS RRTYPE, either existing or new (I recommend new), allowing for a 1:1 (and onto, preferably) mapping of ID to "UI label". In this proposed world, adding something into DNS-SD would require two things to be added (ideally atomic, two-phase commit style addition): .. DNSSDLABEL .. PTR The generation of , and presenting UI_LABEL instead of , would be the responsibility of the DNS-SD domain browser thing, or whatever it is properly called. Having a hash function, would ensure uniqueness in generating . An example hash function would be SHA-224 with base32 encoding, i.e. length=3D56. This would support arbitrary UI_LABELs of arbitrary length. Thoughts? Brian --90e6ba614a7634363304f10dc803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jan 27, 2014 at 10:50 PM, Andrew Sullivan <ajs@anvilw= alrusden.com> wrote:
Hi Doug,

On Mon, Jan 27, 2014 at 05:03:34PM -0800, Douglas Otis wrote:
=A0
If not, I think I'= ;ll have to give up until I
hear from someone else about whether this point is clear in the draft
(or fail to hear from anyone, in which case I'll infer that the WG
just doesn't care about this problem).
=A0

=
I'd like to add my support for discussing this issue, and I = think this document
is a good start.
=A0

The _point_ of the proposal is to say that the first scenario in this
example (t=E9l=E9vision) works fine, but the second one does not, and so we need a way of making these work together. =A0It's just supposed to say that, and not presuppose any particular solution.


I'd like t= o attempt to articulate where I think the problem resides, and illustrate
the location.

I have a rough idea on one = way to address this, by adding one level of indirection.
(NOT using any existing DNS indirection, but rather on the UI side, wh= ich necessarily
has impact on existing DNS-SD designs - but which= I think is fairly clean. I leave it
to those doing DNS-SD to add= ress the feasibility of doing this.)

Basically, the problem is attempting to wedge a "U= I label" into a place where a DNS
label is required (per DNS= protocol).

The location of the problematic stuff = is "<instance>" component in the DNS-SD
<instance>.<service>.<domain>.

<= div>Clearly, the free-wheeling nature of local user-entered "labels&qu= ot; requires both input
and select-from-list to have the entire k= itchen sink of potential "labels" available.

However, adding one single 1:1 label identifier, provid= es a clear, clean, interoperable
way of supporting the input/sele= ction function, while also preserving a DNS-friendly
owner name.<= /div>

This would require some DNS RRTYPE, either existing or = new (I recommend new),
allowing for a 1:1 (and onto, preferably) = mapping of ID to "UI label".

In this pro= posed world, adding something into DNS-SD would require two things to
be added (ideally atomic, two-phase commit style addition):
= <ID>.<service>.<domain> =A0 DNSSDLABEL =A0 =A0<UI_LABE= L>
<ID>.<service>.<domain> =A0 PTR =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 <whatever>
=A0
The generation of <ID>, and presenting UI_LABEL in= stead of <ID>, would be the
responsibility of the DNS-SD do= main browser thing, or whatever it is properly called.

Having a hash function, would ensure uniqueness in generating <ID&g= t;.

An example hash function would be SHA-224 with= base32 encoding, i.e. length=3D56.
This would support arbitrary = UI_LABELs of arbitrary length.

Thoughts?

Brian
--90e6ba614a7634363304f10dc803-- From ajs@anvilwalrusden.com Tue Jan 28 13:02:17 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 3F4851A03B7 for ; Tue, 28 Jan 2014 13:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 iBPElFaF5INV for ; Tue, 28 Jan 2014 13:02:16 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id F04A31A034E for ; Tue, 28 Jan 2014 13:02:15 -0800 (PST) Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 3C5DA8A031 for ; Tue, 28 Jan 2014 21:02:13 +0000 (UTC) Date: Tue, 28 Jan 2014 16:02:12 -0500 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20140128210211.GO8796@mx1.yitter.info> References: <20140122222616.GN1271@mx1.yitter.info> <20140123032553.GC1580@mx1.yitter.info> <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com> <20140124193205.GB2065@mx1.yitter.info> <20140128035044.GB7975@mx1.yitter.info> <775DF8F4-D145-4769-8001-D44BD5ACE82B@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <775DF8F4-D145-4769-8001-D44BD5ACE82B@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 28 Jan 2014 21:02:17 -0000 Hi Doug, On Tue, Jan 28, 2014 at 12:01:15PM -0800, Douglas Otis wrote: > > Andrew's concept of a 'single operational convention' for services > outside the ".local." domain I have clearly lost my ability to make myself plain, perhaps because this problem is so obvious to me. Your description already misses the point. The point is that, if people are going to use the same label under mDNS (which implicitly adds the .local. label and resolves via mDNS) and under DNS (with an implicit addition by search path and resolution via DNS), then a single operational convention for naming in both contexts will be necessary. In the example I was using of one that would work, I say that télévision[.local.] works by sending UTF-8 over mDNS in the link-local context, and that xn--tlvision-b1ab[.lang.example.edu.] works by sending LDH-labels over DNS in the global context. This only means that, if you want to use DNS-SD over global DNS and mDNS both, you need to have names that work in both systems, and that means that you have to cleave to certain naming conventions that you otherwise wouldn't need to do. Names like "Doug's Own Universal Translator"[.local.], which work just fine for DNS-SD over mDNS, may not work in the global context; and "Doug's Own Universal télévision"[.local.] seems to me less likely to work when used in a global context, because the label may well be intercepted by a resolver library which tries to treat it as a U-label. Such an attempt will fail because it's not a legal U-label. > publish A-Labels, not U-Labels. I don't know whta that means. Every A-label has exactly one U-label, and conversely. > Andrew's approach is likely to expose cryptic puny-coded labels in a less friendly format nor does it solve the need for ad-hoc local resolutions. > I don't know what you're talking about here. There is no "approach" to begin with, because I'm trying to state a problem, not solve it. But it sounds like you're worried that people are going to see A-labels because the device sent an A-label but didn't know how to do IDNA. That'd be pretty strange. It seems more likely that, if some devices do DNS-SD in the global DNS but don't speak IDNA, they're going to send UTF-8. If that's the case, then we have an even bigger problem: now we need to maintain parallel DNS trees, which turns out to be less reliable than people might like. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From kerlyn2001@gmail.com Tue Jan 28 13:05: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 E090F1A03C4 for ; Tue, 28 Jan 2014 13:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.268 X-Spam-Level: ** X-Spam-Status: No, score=2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FB_WORD2_END_DOLLAR=3.294, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 Qz_Tg8kDuCwt for ; Tue, 28 Jan 2014 13:05:14 -0800 (PST) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id D8D1D1A03B7 for ; Tue, 28 Jan 2014 13:05:13 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id va2so1012578obc.26 for ; Tue, 28 Jan 2014 13:05:11 -0800 (PST) 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=LW1eSD33GgamUumzpZCzPKG4XQUpC8q2mIJ5JmZSfL8=; b=ZmocBUqIHNr9ofHag2eyqd/PuHIZ6EMvCEz55Mk1xKqmiLMknVoOQB/3KakPgmhYEX IyH23wHaF9MtbilbhKqGkjIUB+ggNzSwhT0vAizQv6PraYrl+84T5VRqKCXcPHmULhV6 /lfc8ydbIsQMyy0fCScDWyzxeUfwnB8IPbcqut0zT69A17mAolVWiuXjUFH9/T2A4nMa kfFjW7/tdnAqIiqZOIjgHrYRPXxp0M02bPtNM3uL7zzWQ4qyR/fA7BA+3X4OdEQ1746b vad02oyx6Gn+qF3QUMT0uGmp83bEyPVusuPmnOGGmCiKG0mPkjg4em/dIK85iBTdpPXN tOrQ== MIME-Version: 1.0 X-Received: by 10.182.112.130 with SMTP id iq2mr1967297obb.57.1390943111113; Tue, 28 Jan 2014 13:05:11 -0800 (PST) Sender: kerlyn2001@gmail.com Received: by 10.60.83.10 with HTTP; Tue, 28 Jan 2014 13:05:10 -0800 (PST) In-Reply-To: <20140128190745.GF8796@mx1.yitter.info> References: <20140122222616.GN1271@mx1.yitter.info> <20140123032553.GC1580@mx1.yitter.info> <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com> <20140124193205.GB2065@mx1.yitter.info> <20140128035044.GB7975@mx1.yitter.info> <20140128190745.GF8796@mx1.yitter.info> Date: Tue, 28 Jan 2014 16:05:10 -0500 X-Google-Sender-Auth: NK-MlaWrtexhIzLxGr7TSAx8dXc Message-ID: From: Kerry Lynn To: Andrew Sullivan Content-Type: multipart/alternative; boundary=089e01229a060a716d04f10e2ef3 Cc: dnssd@ietf.org Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 28 Jan 2014 21:05:16 -0000 --089e01229a060a716d04f10e2ef3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jan 28, 2014 at 2:07 PM, Andrew Sullivan wr= ote: > On Tue, Jan 28, 2014 at 01:48:43PM -0500, Kerry Lynn wrote: > > > Am I correct that in this example you are referring to what is > > conventionally > > called a "host name", that is, the name of the A or AAAA record for a > given > > host? > > If I thought there were really one convention for what is meant by > "host name", I might be able to answer that question. :-/ But in any cas= e, > > I'm just trying to determine where our assumptions agree or differ. Sinc= e you began your example "Suppose we have a device, call it..." I am simply tryin= g to determine if you're referring to the name of an A or AAAA record? That is what I (and RFCs 1033 and 6763 seem to) refer to as a "host name". > > Can we agree that DNS-SD [RFC 6763, section 4.1.3] does not dispute the > LDH > > convention for host names (even though particular implementations may > > currently > > allow local UTF-8 host names). > > we most certainly cannot agree about that. 4.1.3 is perfectly clear > that it recommends that the owner name in the DNS of a Service > Instance Name 'be stored in the DNS, and communicated over the wire, > encoded as straightforward canonical precomposed UTF-8 [RFC3629] > "Net-Unicode" (Unicode Normalization Form C) [RFC5198] text.' That is > quite the opposite of LDH. > > Quoting from RFC 6763, section 4.1.3: Because Service Instance Names are not host names, they are not constrained by the usual rules for host names [RFC1033 ] [RFC1034 ] [RFC1035 ], and rich-text service subdomains are allowed and encouraged I take this to mean that host names and service names are different things (a given host may "host" a great many of services) and that the names of SR= V and TXT records are not subject to legacy _protocol_ constraints that assum= e the LDH convention. Indeed, [RFC 2782] already departs from LDH for SRV RR names when it defines the format of service and protocol labels: An underscore (_) is prepended... to avoid collisions with DNS labels that occur in nature. > We should be more concerned about Service > > Instance Name > > The Service Instance Name in the case of the DNS is the whole name in > question -- in DNS terms what is called the "owner name". > > I haven't any idea what you mean by an "owner name". Let's look at a concrete example (you can try this at home kids): user@ubuntu:~/src/bind-9.9.2/bin/dig$ ./dig -p 5353 @224.0.0.251_http._tcp.local PTR ; <<>> DiG 9.9.2 <<>> -p 5353 @ff02::fb _http._tcp.local PTR ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 0 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 4 ;; QUESTION SECTION: ;_http._tcp.local. IN PTR ;; ANSWER SECTION: _http._tcp.local. 10 IN PTR Officejet\032Pro\0328600\032[A266D6]._http._tcp.local. ;; ADDITIONAL SECTION: Officejet\032Pro\0328600\032[A266D6]._http._tcp.local. 10 IN SRV 0 0 80 HPA266D6.local. Officejet\032Pro\0328600\032[A266D6]._http._tcp.local. 10 IN TXT "" HPA266D6.local. 10 IN A 192.168.1.31 HPA266D6.local. 10 IN AAAA fe80::8634:97ff:fea2:66d6 ;; Query time: 3 msec ;; SERVER: fe80::8634:97ff:fea2:66d6%2#5353(ff02::fb) ;; WHEN: Mon Jan 27 09:50:24 2014 ;; MSG SIZE rcvd: 162 Which of these is an "owner name"? If I were to open Safari and navigate t= o Bookmarks->Bonjour->Printers, I would see "Officejet Pro 8600 [A266D6]" in the list. This is the same name I see in the Print & Scan dialog when I select the destination for my print jobs. When I *select* Bookmarks->Bonjour->Printers->Officejet Pro 8600 [A266D6] i= n Safari, what gets populated in the (web) browser's navigation bar is HPA266D6.local. The only reason this works is that, by convention, we can find the most popular services by dereferencing a host name and using a well known port. I could just as easily access my printer's configuration web page by entering [fe80::8634:97ff:fea2:66d6]in the web browser. One advantage of SRV records is that they allow a service to be found at an arbitrary port. > > A better example that would put this more squarely in our WG's > wheelhouse > > might > > be a service named > > t=E9l=E9viseur1._http._tcp.lang.example.edu< > http://xn--tlviseur1-b4ab.lang.example.edu> > > No, it's the portion of the Service Instance Name that is the > problem. That's why I structured the example as I did. > > As far as I can tell, your example has to do with host names (if we agree on that definition) and not Service Instance Names, which are structured as ... Regards, -K- A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --089e01229a060a716d04f10e2ef3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jan 28, 2014 at 2:07 PM, Andrew Sullivan <aj= s@anvilwalrusden.com> wrote:
On Tue,= Jan 28, 2014 at 01:48:43PM -0500, Kerry Lynn wrote:

> Am I correct that in this example you are referring to what is
> conventionally
> called a "host name", that is, the name of the A or AAAA rec= ord for a given
> host?

If I thought there were really one convention for what is meant by "host name", I might be able to answer that question. :-/ =A0But = in any case,

I'm just trying to determ= ine where our assumptions agree or differ.=A0 Since you
began= your example "Suppose we have a device, call it..." I am simply = trying
to determine if you're referring to the name of an A or AAAA record?=A0= That
is what I (and RFCs 1033 and 6763 seem to) refer to as a "hos= t name".
=A0
> Can we agree that DNS-SD [RFC 6763, section 4.1.3] does not dispute th= e LDH
> convention for host names (even though particular implementations may<= br> > currently
> allow local UTF-8 host names).

we most certainly cannot agree about that. =A04.1.3 is perfectly clea= r
that it recommends that the owner name in the DNS of a Service
Instance Name 'be stored in the DNS, and communicated over the wire, encoded as straightforward canonical precomposed UTF-8 [RFC3629]
"Net-Unicode" (Unicode Normalization Form C) [RFC5198] text.'= =A0That is
quite the opposite of LDH.

Quoting from RFC 6763, sectio= n 4.1.3:
Because Service Instance Names are not host names, they are not
constrained by the usual rules for host names [RFC1033] [RFC1034]

[RFC1035], and rich-text serv=
ice subdomains are allowed and encouraged
I t= ake this to mean that host names and service names are different things
(a given host may "host" a great many of services) and= that the names of SRV
and TXT records are not subject to leg= acy _protocol_ constraints that assume
the LDH convention.=A0= Indeed, [RFC 2782] already departs from LDH for SRV RR
names when it defines the format of service and protocol labels:= 
An underscore (_) is prepended... to avoid collisions with DNS
labels t=
hat occur in nature.
> We should be more concerned about Service
> Instance Name

The Service Instance Name in the case of the DNS is the whole name in=
question -- in DNS terms what is called the "owner name".

I haven't any idea what y= ou mean by an "owner name".=A0 Let's look at a concrete
ex= ample (you can try this at home kids):

user@ubuntu:~/src/bind-9.9.2/bin/dig$ ./dig -p 5= 353 @224.0.0.251 _http._tcp.local PTR ; <<>> DiG 9.9.2 <<>> -p 5353 @ff02::fb _http._tcp.= local PTR
; (1 server found)
;; global options: +cmd
;; Got answer= :
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 0
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 4

;;= QUESTION SECTION:
;_http._tcp.local.=A0=A0=A0 =A0=A0=A0 IN=A0=A0=A0 PTR=

;; ANSWER SECTION:
_http._tcp.local.=A0=A0=A0 10=A0=A0=A0 IN=A0= =A0=A0 PTR=A0=A0=A0 Officejet\032Pro\0328600\032[A266D6]._http._tcp.local.<= br>
;; ADDITIONAL SECTION:
Officejet\032Pro\0328600\032[A266D6]._http._t= cp.local. 10 IN SRV 0 0 80 HPA266D6.local.
Officejet\032Pro\0328600\032[= A266D6]._http._tcp.local. 10 IN TXT ""
HPA266D6.local.=A0=A0= =A0 =A0=A0=A0 10=A0=A0=A0 IN=A0=A0=A0 A=A0=A0=A0 192.168.1.31
HPA266D6.local.=A0=A0=A0 =A0=A0=A0 10=A0=A0=A0 IN=A0=A0=A0 AAAA=A0=A0=A0 fe= 80::8634:97ff:fea2:66d6

;; Query time: 3 msec
;; SERVER: fe80::86= 34:97ff:fea2:66d6%2#5353(ff02::fb)
;; WHEN: Mon Jan 27 09:50:24 2014
= ;; MSG SIZE=A0 rcvd: 162

Which of these is an "owner name"?=A0 If I were to= open Safari and navigate to
Bookmarks->Bonjour->Printe= rs, I would see "Officejet Pro 8600 [A266D6]" in the list.
Thi= s is the same name I see in the Print & Scan dialog when I select the d= estination
for my print jobs.

When I *select* Bookmarks->Bonjour-= >Printers->Officejet Pro 8600 [A266D6] in
Safari, what = gets populated in the (web) browser's navigation bar is HPA266D6.local.=
The only reason this works is that, by convention, we can find t= he most popular
services by dereferencing a host name and using a well k= nown port.=A0 I could just
as easily access my printer's configurati= on web page by entering
[fe80::8= 634:97ff:fea2:66d6]in the web browser.

One advanta= ge of SRV records is that they allow a service to be found at an
arbitrary port.

> > A better example that would put this more squarely in our WG'= s wheelhouse
> might
> be a service named
> t=E9l=E9viseur1._http._tcp.lang.example.edu<http://xn--tlviseur1-b4ab.lang.e= xample.edu>

No, it's the <Domain> portion of the Service Instance Name that i= s the
problem. =A0That's why I structured the example as I did.

As far = as I can tell, your example has to do with host names (if we agree on that = definition)
and not Service Instance Names, which are structured as <= Instance>.<Service>.<Domain>.

Regards, -K-

A

--
Andrew Sullivan
ajs@anvilwalrusden.com
_______________________________________________
dnssd mailing list
dnssd@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dnssd

--089e01229a060a716d04f10e2ef3-- From ajs@anvilwalrusden.com Tue Jan 28 13:11: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 3BCCB1A03F6 for ; Tue, 28 Jan 2014 13:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 MhqavJ5W6GWG for ; Tue, 28 Jan 2014 13:11:55 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE2D1A03B7 for ; Tue, 28 Jan 2014 13:11:55 -0800 (PST) Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 53D7B8A031 for ; Tue, 28 Jan 2014 21:11:52 +0000 (UTC) Date: Tue, 28 Jan 2014 16:11:50 -0500 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20140128211150.GP8796@mx1.yitter.info> References: <20140122222616.GN1271@mx1.yitter.info> <20140123032553.GC1580@mx1.yitter.info> <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com> <20140124193205.GB2065@mx1.yitter.info> <20140128035044.GB7975@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 28 Jan 2014 21:11:57 -0000 On Tue, Jan 28, 2014 at 03:36:42PM -0500, Brian Dickson wrote: > The location of the problematic stuff is "" component in the > DNS-SD > ... No. If that's the only problem, then what Stuart said in the meeting in Vancouver is probably right. DNS-SD resolvers need to ensure that that portion of the owner name does _not_ go through any system resolver and is not treated as a candidate for IDNA processing, and then you can send whatever you like. The alternatives for treating are called out in the draft. I suppose your proposal is a third, but it doesn't deal with the object-name problem (which is a label in the domain part). A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Tue Jan 28 13:32: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 4C4F91A01A2 for ; Tue, 28 Jan 2014 13:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.259 X-Spam-Level: * X-Spam-Status: No, score=1.259 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 4wZ5GJaamMRW for ; Tue, 28 Jan 2014 13:32:14 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id A8F051A0056 for ; Tue, 28 Jan 2014 13:32:14 -0800 (PST) Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D08318A031 for ; Tue, 28 Jan 2014 21:32:11 +0000 (UTC) Date: Tue, 28 Jan 2014 16:32:05 -0500 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20140128213205.GQ8796@mx1.yitter.info> References: <20140122222616.GN1271@mx1.yitter.info> <20140123032553.GC1580@mx1.yitter.info> <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com> <20140124193205.GB2065@mx1.yitter.info> <20140128035044.GB7975@mx1.yitter.info> <20140128190745.GF8796@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 28 Jan 2014 21:32:16 -0000 On Tue, Jan 28, 2014 at 04:05:10PM -0500, Kerry Lynn wrote: > to determine if you're referring to the name of an A or AAAA record? That > is what I (and RFCs 1033 and 6763 seem to) refer to as a "host name". That's not a host name. At least in the DNS, a host name is a DNS owner name that conforms to the old host name syntax (or "preferred syntax"); that is, it's a DNS owner name made up entirely of LDH-labels. It probably (almost certainly) also has an A or AAAA record at that owner name. This is actually made explicit in RFC 1033, and that LDH-label restriction is exactly what RFC 6763 is saying it doesn't use. In many contexts, to be clear, people use "host name" to refer to the left-most label in a DNS name, regardless of whether that label is an LDH-label or a U-label (or for that matter, an A-label). > Because Service Instance Names are not host names, they are not Yes. That is, they don't conform to this rule in RFC 1033: Because of other protocol restrictions, only the following characters are recommended for use in a host name (besides the dot separator): "A-Z", "a-z", "0-9", dash and underscore (Note that 1033 includes underscore rather than just LDH. RFC 1034 is LDH only; see 1034 section 2.3.1.) > I take this to mean that host names and service names are different things They are, but not in the way you seem to think. > the LDH convention. Indeed, [RFC 2782] already departs from LDH for SRV RR > names when it defines the format of service and protocol labels: Yep. > > question -- in DNS terms what is called the "owner name". > > > > I haven't any idea what you mean by an "owner name". Let's look at a The owner name "is the domain name where the RR is found"; see RFC 1034 section 3.6. This is _different to_ a "host name" because of what I say above. Owner names are not constrained to LDH or even LDHU, but can use any series of octets up to 63 octets per label, with an overall restriction of 255. > _http._tcp.local. > Officejet\032Pro\0328600\032[A266D6]._http._tcp.local. > Officejet\032Pro\0328600\032[A266D6]._http._tcp.local. > Officejet\032Pro\0328600\032[A266D6]._http._tcp.local. > HPA266D6.local. > HPA266D6.local. > Which of these is an "owner name"? All of the above, less the quote character. Also, here's an owner name: télévision.lang.example.edu. That owner name, however, is not an IDNA2008 name and won't work with IDNA. It _does_ work with the DNS, just fine. Here's another owner name: télévision.local. That owner name works exactly the same way as the above, except that the resolver library has probably learned to treat the label .local. as a namespace-shifter and therefore sends the query via mDNS instead of DNS. Except when it doesn't; as the root server operators how often. Here's another owner name: xn--tlvision-b1ab.lang.example.edu. This happens to work with IDNA, and is a host name as well as an owner name. > > As far as I can tell, your example has to do with host names (if we agree > on that definition) > and not Service Instance Names, which are structured as > ... Not host names, but the part of the Service Instance Name, which is I believe what the draft says. A -- Andrew Sullivan ajs@anvilwalrusden.com From brian.peter.dickson@gmail.com Tue Jan 28 14:41:29 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 97F6F1A0480 for ; Tue, 28 Jan 2014 14:41:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_IMAGE_ONLY_32=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 7DvNuBUPyXUm for ; Tue, 28 Jan 2014 14:41:27 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 87B5D1A02EC for ; Tue, 28 Jan 2014 14:41:27 -0800 (PST) Received: by mail-ig0-f182.google.com with SMTP id uy17so2963736igb.3 for ; Tue, 28 Jan 2014 14:41:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O5IlqOGCeAqa31jeKhF1oz4nAXDRuJUKPk5mT3dwPa4=; b=HmYOOoNOTs55TeyoLZ/idQgf9ITOnQnapxjmH8NbnEYgrpsLmZGkuudFZCg3o/YDTM Oz7MSJLD27DcivQ5eWgKSk//kI5Bj0btXrRj8sE7xVqDtmU5RojOrpQq6o8lHbUlNBwG axwEfmU514Dg0BTZ7f4uIy7qUmVvLlcDejDmmr8GF2DUPLWTMPgZbsIGCMGwicVv1p93 IiW/75R3UZRKCI+9yBv1FUQ3nUQLgNRwJVsDsBRNDSg1SzLYCzQHcSlY3fK4E3QyuBrT Z9kq7AT9omGJBFwjow2j272wIglUm1bDM4rgmEcfhPp07T/5ZYHtSm96zfq+3jGoyMBl XOGQ== MIME-Version: 1.0 X-Received: by 10.50.239.162 with SMTP id vt2mr25565728igc.48.1390948884832; Tue, 28 Jan 2014 14:41:24 -0800 (PST) Received: by 10.64.245.243 with HTTP; Tue, 28 Jan 2014 14:41:24 -0800 (PST) In-Reply-To: <20140128211150.GP8796@mx1.yitter.info> References: <20140122222616.GN1271@mx1.yitter.info> <20140123032553.GC1580@mx1.yitter.info> <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com> <20140124193205.GB2065@mx1.yitter.info> <20140128035044.GB7975@mx1.yitter.info> <20140128211150.GP8796@mx1.yitter.info> Date: Tue, 28 Jan 2014 17:41:24 -0500 Message-ID: From: Brian Dickson To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a11348e4a2e690304f10f8680 Cc: dnssd@ietf.org Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 28 Jan 2014 22:41:29 -0000 --001a11348e4a2e690304f10f8680 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jan 28, 2014 at 4:11 PM, Andrew Sullivan wrote: > On Tue, Jan 28, 2014 at 03:36:42PM -0500, Brian Dickson wrote: > > The location of the problematic stuff is "" component in the > > DNS-SD > > ... > > No. If that's the only problem, then what Stuart said in the meeting > in Vancouver is probably right. DNS-SD resolvers need to ensure that > that portion of the owner name does _not_ go through any system > resolver and is not treated as a candidate for IDNA processing, and > then you can send whatever you like. The alternatives for treating > are called out in the draft. I suppose your proposal is a > third, but it doesn't deal with the object-name problem (which is a > label in the domain part). > > [bpd] I think I now see the problem - I overlooked the 4.1.3 bit about wire format and _encouraging_ use of non-IDNA/DNS labels. I think my suggestion might still work, if we just expand the suggestion to apply the same technique to any non-IDNA label in a Service Instance: .._._.... PTR .... NEWRRTYPE "UI_LABEL1" ... NEWRRTYPE "UI_LABEL2" ... NEWRRTYPE "UI_LABEL3" etc .. NEWRRTYPE "UI_LABEL_N" (The presence/absence of NEWRRTYPE distinguishes things, if there is any ambiguity, with 56-byte base32-ish labels.) Ugly, but at least only under the hood. Deterministic, may require extra DNS queries, but backward compatible. Users see UI_LABELs. (Since every is an A-LABEL, it is not incompatible with mDNS, i.e. backward-compatible towards mDNS servers.) This avoids placing limitations on user input, which I believe Andrew's draft (with profiles) does. Brian --001a11348e4a2e690304f10f8680 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jan 28, 2014 at 4:11 PM, Andrew Sullivan = <ajs@anvilwa= lrusden.com> wrote:
On Tue, Jan 28, 2014 at 03:36:42PM -0500= , Brian Dickson wrote:
> The location of the problematic stuff is "<instance>" = component in the
> DNS-SD
> <instance>.<service>.<domain>.

No. =A0If that's the only problem, then what Stuart said in the m= eeting
in Vancouver is probably right. =A0DNS-SD resolvers need to ensure that
that portion of the owner name does _not_ go through any system
resolver and is not treated as a candidate for IDNA processing, and
then you can send whatever you like. =A0The alternatives for treating
<instance> are called out in the draft. =A0I suppose your proposal is= a
third, but it doesn't deal with the object-name problem (which is a
label in the domain part).


[bpd] I think I now see the problem - I overlooked the 4.1.3 bit = about
wire format and _encouraging_ use of non-IDNA/DNS labels.
I think my suggestion might still work, if we just expand the = suggestion to
apply the same technique to any non-IDNA label in a= Service Instance:
<ID1>.<ID2>._<service1>._<transport>.<ID3&g= t;..<ID_N>.<FQDN> PTR <whatever>
<ID1>.&l= t;ID2>...<FQDN> NEWRRTYPE "UI_LABEL1"
<ID2&= gt;...<FQDN> NEWRRTYPE "UI_LABEL2"
<ID3>...<FQDN> NEWRRTYPE "UI_LABEL3"
e= tc
<ID_N>.<FQDN>. NEWRRTYPE "UI_LABEL_N"

(The presence/absence of NEWRRTYPE distinguishes thi= ngs,
if there is any ambiguity, with 56-byte base32-ish labels.)
=
Ugly, but at least only under the hood. Deterministic, may r= equire
extra DNS queries, but backward compatible. Users see UI_L= ABELs.

(Since every <ID_N> is an A-LABEL, it is not inco= mpatible with mDNS,
i.e. backward-compatible towards mDNS servers= .)

This avoids placing limitations on user input, = which I believe Andrew's
draft (with profiles) does.

Brian
<= div>=A0
--001a11348e4a2e690304f10f8680-- From doug.mtview@gmail.com Tue Jan 28 21:53:52 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 8ABE11A0376 for ; Tue, 28 Jan 2014 21:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKRWEVdzy6Ja for ; Tue, 28 Jan 2014 21:53:46 -0800 (PST) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1811A0280 for ; Tue, 28 Jan 2014 21:53:46 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id z10so1299168pdj.33 for ; Tue, 28 Jan 2014 21:53:43 -0800 (PST) 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=e1hCgbWnehMOLSYYN5muuUl4X3Ul0p5nEvZdFPQA6DQ=; b=SyYypR/G3+GYbUQqM4TaTJqu6Fi0AbAYep6Yj8vnZeDjlXUnY11DNnwgNMyV+MmB+X 9NS7stJQKPClVoYJl2CCNBjo8D7vxYbrQpqAx1OmUdmjQ6CrbXY8CV2F+xq6Vo1xLMj6 yzuEqUtfieIPjBGZmlgRImQxjSV6y6NMQLOwRC/tr2DDZhoC8e6ynLAPqrnDBNJZ7Gls UUBoJpje+ST1plJQxQNiQ6oRGwkVZizPVlfHQbiffNVw5fZ+OJnzpsUuWhgnbjdj5oxy Rpt9IRy/QMs3YfGn11i/OYcQr9pauRpT12qeINmDHEdIWsjr0W2CmmI413mqyFl5Hvsf 87CQ== X-Received: by 10.68.171.67 with SMTP id as3mr5790270pbc.105.1390974823630; Tue, 28 Jan 2014 21:53:43 -0800 (PST) Received: from [192.168.2.228] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id id1sm2981745pbc.11.2014.01.28.21.53.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Jan 2014 21:53:41 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Douglas Otis In-Reply-To: <20140128035044.GB7975@mx1.yitter.info> Date: Tue, 28 Jan 2014 21:53:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140122222616.GN1271@mx1.yitter.info> <20140123032553.GC1580@mx1.yitter.info> <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com> <20140124193205.GB2065@mx1.yitter.info> <20140128035044.GB7975@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1827) Cc: dnssd@ietf.org Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 29 Jan 2014 05:53:52 -0000 Dear Andrew, On Jan 27, 2014, at 7:50 PM, Andrew Sullivan = wrote: [] > Suppose we have a device, call it t=E9l=E9viseur1. >=20 > The device is in use in the Dept of Languages at example university. > So its FQDN in the DNS (were it to have one) would be > t=E9l=E9viseur1.lang.example.edu. >=20 > Now, it so happens that Languages is kinda big, and classes have to be > all over campus. But profs in the department want to use their > devices from all over the campus to get back to t=E9l=E9vision, which = is > the department's content server administered by Languages's IT monkey. >=20 > Inside the department network, t=E9l=E9vision works seamlessly. So IT > configures everyone in the department to have a search path of > lang.example.edu, and so when just t=E9l=E9vision is entered, if = there's > no mDNS responder for t=E9l=E9vision.local (in UTF-8) then the label > gets the search path appended after being turned into > xn--tlvision-b1ab, and the lookup is > xn--tlvision-b1ab.lang.example.edu, and everything is good. Disagree. A globally resolvable label in DNS might not satisfy = applications expecting to discover local services. DNS is normally = unable to offer addresses suitable for local links without complex name = hierarchy. On the other hand, mDNS offers answers specifically for = local links. Resolved answers might return globally routable IP = addresses, but such addresses may prove impractical in many situations. > Now, suppose instead that the department's content server is called > instead "Source de T=E9l=E9vision, D=E9partement de Langues". This is = great > in an mDNS context: DNS-SD will find it just fine. But if you enter > "Source de T=E9l=E9vision, D=E9partement de Langues.lang.example.edu", = the > effects are unpredictable. Any domain search list should imply ".local." for names lacking this TLD = and having two or fewer labels. This would ensure local mDNS resolvers = are attempted first with a slight risk of causing a 3 second delay. = Normally users are closely associated with search list domains. Even = so, names invalid for DNS should ideally generate errors locally to = minimize unintended traffic and delay. =20 > On some systems, that will be passed > through to the resolution layer unchanged, and the lookup will match > the octets modulo the 0x20 processing of ASCII characters. On other > systems, it will be intercepted by the application or the system > resolver or both as a potential IDNA label, and processed according to > local IDNA rules. Both IDNA2003 and IDNA2008 have trouble with > spaces, so we'll have some problems no matter what; IDNA2008 will > certainly reject it. If your application is one of those "IDNA2003 > except some new stuff we haven't specified", it's hard to know exactly > what will happen, but probably whatever would happen with IDNA2003 > (because that label's handling ought not to change). Hopefully, applications will perform sanity checks prior to walking up = resolvers. In addition, U-labels complying with RFC5198 will not ensure = valid A-Labels in a conversion process or that results restore to the = original string. IDNA2008 and mDNS RFCRFC5198 are currently not = compatible nor intended to ensure idempotent U-label <<->> A-label = results. =20 > The _point_ of the proposal is to say that the first scenario in this > example (t=E9l=E9vision) works fine, but the second one does not, and = so > we need a way of making these work together. It's just supposed to > say that, and not presuppose any particular solution. Your first example is not fine since the answer may not be suitable even = when a result is produced.=20 >> string for any apparent visually duplicated instance=20 >=20 > This has nothing to do with any of the visual confusion stuff or any > of that. IMHO, this property represents the basic difference between RFC5198 and = IDNA2008. >> Perhaps a protocol prefix could remind users a local namespace is >> involved. >=20 > This requires users to have a theory of namespaces, which is already > very far away from users' needs. A user may not be helped who expects local services that resolve = elsewhere. There should be a preference for .local. >> There are extensions that ensure mDNS instance labels are supported >> by DNS. >=20 > There are some labels that DNS-SD recommends that, I claim, cannot be > supported in DNS using IDNA. That's all this is about. I do not see > how Trill helps this, but I'm sure my ignorance is showing. Trill is able to transparently bridge multicast traffic by encapsulating = packets in a manner that protects against routing loops. DNS-SD recommends use of friendly labels which may prove problematic for = IDNA. IMHO, the best way to protect users from any namespace = uncertainty is to prefer local, especially when doing so makes sense. =20= >> I see the mDNS proxy effort largely aimed at supporting soon to be >> legacy devices. >=20 > Again, to the extent I understand you, this sounds like you're arguing > that the WG is chartered to cover a non-problem. Is that right? No. In the goodness of time spanning tree and IPv4 will be replaced by = simpler and more robust ways of handling moderately complex local = networks. In the meantime, other methods will be needed. Regards, Douglas Otis= From ajs@anvilwalrusden.com Tue Jan 28 22:27: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 B091E1A0373 for ; Tue, 28 Jan 2014 22:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 v28j-3tDLSss for ; Tue, 28 Jan 2014 22:27:33 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 27B671A0193 for ; Tue, 28 Jan 2014 22:27:32 -0800 (PST) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 888A68A031 for ; Wed, 29 Jan 2014 06:27:29 +0000 (UTC) Date: Wed, 29 Jan 2014 01:27:27 -0500 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20140129062726.GB9511@mx1.yitter.info> References: <20140122222616.GN1271@mx1.yitter.info> <20140123032553.GC1580@mx1.yitter.info> <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com> <20140124193205.GB2065@mx1.yitter.info> <20140128035044.GB7975@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 29 Jan 2014 06:27:34 -0000 Doug, On Tue, Jan 28, 2014 at 09:53:20PM -0800, Douglas Otis wrote: > > Disagree. A globally resolvable label in DNS might not satisfy > applications expecting to discover local services. But a significant part of the _reason_ we started this WG was because the services aren't actually local. They're on-campus, but they're not in a link-local context. So far, there are exactly two contexts: link-local and not. You seem to be proposing something further, but if so I really don't know what it is. It'd be nice to get a pointer. > up resolvers. In addition, U-labels complying with RFC5198 will not > ensure valid A-Labels There is no such thing as a U-label that does not generate an A-label, and conversely. This is a property of U-labels and A-labels. If what you're talking about is a non-U-label string that is nevertheless a valid string using 5198, please say that. > A user may not be helped who expects local services that resolve > elsewhere. There should be a preference for .local. You do realise, right, that users never see ".local." on anything? > Trill is able to transparently bridge multicast traffic by encapsulating packets in a manner that protects against routing loops. > Ok. So, you are saying that DNS-SD has to be used onlt with mDNS? That seems contrary to the specification. Also, it's contrary to deployed practice. For instance, printers at IETF meetings are discoverable using DNS-SD in the global DNS. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From bmanning@isi.edu Wed Jan 29 16:26: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 E52BF1A041C for ; Wed, 29 Jan 2014 16:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 zePzr3BJMcP8 for ; Wed, 29 Jan 2014 16:26:44 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 420C61A02F1 for ; Wed, 29 Jan 2014 16:26:44 -0800 (PST) Received: from [124.157.68.180] ([124.157.68.180]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s0U0PL1V010626 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 29 Jan 2014 16:25:33 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=us-ascii From: manning bill In-Reply-To: <20140129062726.GB9511@mx1.yitter.info> Date: Wed, 29 Jan 2014 16:25:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4C4EF3BC-AA8E-421F-BF78-5B11761B06D3@isi.edu> References: <20140122222616.GN1271@mx1.yitter.info> <20140123032553.GC1580@mx1.yitter.info> <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com> <20140124193205.GB2065@mx1.yitter.info> <20140128035044.GB7975@mx1.yitter.info> <20140129062726.GB9511@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1827) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Cc: dnssd@ietf.org Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 30 Jan 2014 00:26:46 -0000 service discovery that is bound to a single broadcast domain must make = certain assumptions, one that is often made, without real justification, is that addressing/labeling is _NOT_ globally = unique. its not clear to me that the induced ambiguity of non-unique = addressing/labeling is worth the cost, particularly given that device = mobility between broadcast domains is becoming the norm. /bill Neca eos omnes. Deus suos agnoscet. On 28January2014Tuesday, at 22:27, Andrew Sullivan = wrote: > Doug, >=20 > On Tue, Jan 28, 2014 at 09:53:20PM -0800, Douglas Otis wrote: >>=20 >> Disagree. A globally resolvable label in DNS might not satisfy >> applications expecting to discover local services.=20 >=20 > But a significant part of the _reason_ we started this WG was because > the services aren't actually local. They're on-campus, but they're > not in a link-local context. So far, there are exactly two contexts: > link-local and not. You seem to be proposing something further, but > if so I really don't know what it is. It'd be nice to get a pointer. >=20 >> up resolvers. In addition, U-labels complying with RFC5198 will not >> ensure valid A-Labels=20 >=20 > There is no such thing as a U-label that does not generate an A-label, > and conversely. This is a property of U-labels and A-labels. If what > you're talking about is a non-U-label string that is nevertheless a > valid string using 5198, please say that. >=20 >> A user may not be helped who expects local services that resolve >> elsewhere. There should be a preference for .local. >=20 > You do realise, right, that users never see ".local." on anything?=20 >=20 >> Trill is able to transparently bridge multicast traffic by = encapsulating packets in a manner that protects against routing loops. >>=20 >=20 > Ok. So, you are saying that DNS-SD has to be used onlt with mDNS? > That seems contrary to the specification. Also, it's contrary to > deployed practice. For instance, printers at IETF meetings are > discoverable using DNS-SD in the global DNS. >=20 > Best regards, >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From ajs@anvilwalrusden.com Wed Jan 29 16:35:00 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 B560A1A041C for ; Wed, 29 Jan 2014 16:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 K2lAgDrDboqr for ; Wed, 29 Jan 2014 16:34:59 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 400FB1A03F8 for ; Wed, 29 Jan 2014 16:34:59 -0800 (PST) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id B9BA38A031 for ; Thu, 30 Jan 2014 00:34:55 +0000 (UTC) Date: Wed, 29 Jan 2014 19:34:51 -0500 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20140130003451.GB10572@mx1.yitter.info> References: <20140122222616.GN1271@mx1.yitter.info> <20140123032553.GC1580@mx1.yitter.info> <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com> <20140124193205.GB2065@mx1.yitter.info> <20140128035044.GB7975@mx1.yitter.info> <20140129062726.GB9511@mx1.yitter.info> <4C4EF3BC-AA8E-421F-BF78-5B11761B06D3@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C4EF3BC-AA8E-421F-BF78-5B11761B06D3@isi.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 30 Jan 2014 00:35:00 -0000 Hi Bill, On Wed, Jan 29, 2014 at 04:25:20PM -0800, manning bill wrote: > its not clear to me that the induced ambiguity of non-unique addressing/labeling is worth the cost, particularly given that device mobility > between broadcast domains is becoming the norm. If I understand this correctly (and I _think_ you're saying something aligned with something Doug Otis was saying, though I believe I understood him less), what you're saying is that ambiguous, not-fully-qualified naming (or labelling -- I assume you mean "IP addressing" above) is just a bad idea in the current Internet, so we shouldn't do it. Is that right? If so (and if I'm right about what Doug was saying -- again, I'm not at all confident in my interpretation), I find this hard to square with the WG charter. Are you saying that the WG is working on a problem that can't actually be solved or shouldn't be solved or something? (I'm prepared to concede that possibility; I'm just trying to understand what we're discussing.) A -- Andrew Sullivan ajs@anvilwalrusden.com From bmanning@isi.edu Wed Jan 29 16:53:58 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 D92B11A0484 for ; Wed, 29 Jan 2014 16:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 nvvwFAvHVP_r for ; Wed, 29 Jan 2014 16:53:57 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8521A0423 for ; Wed, 29 Jan 2014 16:53:57 -0800 (PST) Received: from [124.157.68.180] ([124.157.68.180]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s0U0rDaI012319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 29 Jan 2014 16:53:19 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=windows-1252 From: manning bill In-Reply-To: <20140130003451.GB10572@mx1.yitter.info> Date: Wed, 29 Jan 2014 16:53:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140122222616.GN1271@mx1.yitter.info> <20140123032553.GC1580@mx1.yitter.info> <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com> <20140124193205.GB2065@mx1.yitter.info> <20140128035044.GB7975@mx1.yitter.info> <20140129062726.GB9511@mx1.yitter.info> <4C4EF3BC-AA8E-421F-BF78-5B11761B06D3@isi.edu> <20140130003451.GB10572@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1827) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Cc: dnssd@ietf.org Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 30 Jan 2014 00:53:59 -0000 rants below instead of top posting like God, Microsoft, and Apple = intended=85 :) /bill Neca eos omnes. Deus suos agnoscet. On 29January2014Wednesday, at 16:34, Andrew Sullivan = wrote: > Hi Bill, >=20 > On Wed, Jan 29, 2014 at 04:25:20PM -0800, manning bill wrote: >> its not clear to me that the induced ambiguity of non-unique = addressing/labeling is worth the cost, particularly given that device = mobility >> between broadcast domains is becoming the norm. >=20 > If I understand this correctly (and I _think_ you're saying something > aligned with something Doug Otis was saying, though I believe I > understood him less), what you're saying is that ambiguous, > not-fully-qualified naming (or labelling -- I assume you mean "IP > addressing" above) is just a bad idea in the current Internet, so we > shouldn't do it. Is that right? >=20 mostly. if it was just addressing, then we have RFC 1918 and all the = existence proofs that link-local/single broadcast domains have real = difficultly staying that way. once it involves names/labels, the ability of = multiple parties each claiming to be DC001, each with a divergent view = of its service group will cause havoc. this is a known problem with Appletalk and its successors, DHCP = assigned names, etc. The problem is aggravated when one assigns = security associations with the Fully Qualified Name, which is then overridden in a link local scope. I=92m not saying we = shouldn=92t do it, I=92m suggesting that all previous attempts have had = serious problems that are not being addressed in the current work products. All of this goes away if we mandate/presume globally = unique names/labels. > If so (and if I'm right about what Doug was saying -- again, I'm not > at all confident in my interpretation), I find this hard to square > with the WG charter. Are you saying that the WG is working on a > problem that can't actually be solved or shouldn't be solved or > something? (I'm prepared to concede that possibility; I'm just trying > to understand what we're discussing.) I suggest that the work done to date does not solve the problems stated = in the Charter, as I understand it, >=20 > A >=20 >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From doug.mtview@gmail.com Wed Jan 29 18:44: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 D68C91A052A for ; Wed, 29 Jan 2014 18:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 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, TRACKER_ID=1.306] 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 nO3Hnb5dvgBz for ; Wed, 29 Jan 2014 18:44:46 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6290F1A0525 for ; Wed, 29 Jan 2014 18:44:46 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id w10so2481669pde.20 for ; Wed, 29 Jan 2014 18:44:43 -0800 (PST) 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=ppmDeBHcX7uQV20Wul63FSvmjDiP/coorO70Ghd9mEU=; b=WvKpXaFpKPnQB9bFju4QpycARaTyoWFmKp/jMQS4xeJ9QD/678z6d3kDFGwQmR4iDy +BHvSoAISER9rpAZoQRlygy02OtYnUVwprIweLVSUuaa5e82zGf5f6WJA/cC4XzjQsWa qPoW3Ua2ydd0ldRxKR85VC06YXIBBlANqJT/3ZiUbo5BfP0RZDFB+1/uIDAw2KYQ1a8Y xHa7MuBe3MD+OLJNpkhFVO2NJP8tYulPxdoJTOHTlupkQQRvozKVvxI9V/ReFZiZNRpb ckEE9IbIZUWyKR07TfdoapiPdAApUjwzOCNU7KmKc4tjkx58Njl5DsbWX7HeJqw+3Y64 3emA== X-Received: by 10.68.143.196 with SMTP id sg4mr11654269pbb.155.1391049883437; Wed, 29 Jan 2014 18:44:43 -0800 (PST) Received: from [192.168.2.230] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id cz3sm11882046pbc.9.2014.01.29.18.44.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Jan 2014 18:44:42 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_BE0CB23F-FCA3-406D-8A90-6D1690CE9F68" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Douglas Otis In-Reply-To: <20140129062726.GB9511@mx1.yitter.info> Date: Wed, 29 Jan 2014 18:44:39 -0800 Message-Id: References: <20140122222616.GN1271@mx1.yitter.info> <20140123032553.GC1580@mx1.yitter.info> <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com> <20140124193205.GB2065@mx1.yitter.info> <20140128035044.GB7975@mx1.yitter.info> <20140129062726.GB9511@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1827) Cc: dnssd@ietf.org Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 30 Jan 2014 02:44:49 -0000 --Apple-Mail=_BE0CB23F-FCA3-406D-8A90-6D1690CE9F68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Andrew, Please forgive my awkward summary of what I understood you to be = proposing. Your document does not appear to address the chartered = problem. Clearly you are also unhappy with my use of the term U-Label. = My apologies.=20 See comments inline. On Jan 28, 2014, at 10:27 PM, Andrew Sullivan = wrote: > Doug, >=20 > On Tue, Jan 28, 2014 at 09:53:20PM -0800, Douglas Otis wrote: >>=20 >> Disagree. A globally resolvable label in DNS might not satisfy >> applications expecting to discover local services.=20 >=20 > But a significant part of the _reason_ we started this WG was because > the services aren't actually local. They're on-campus, but they're > not in a link-local context. So far, there are exactly two contexts: > link-local and not. You seem to be proposing something further, but > if so I really don't know what it is. It'd be nice to get a pointer. The goal is to facilitate access to mDNS gateways or proxies for access = to services likely publishing non-global addresses in mDNS which do not = permit direct Internet access and are not on a common network bridge. = Profoundly not the same as transparently resolving global services which = you seem to suggest. Here are some pointers to proprietary products that may help compose a = definition of the problem being solved. Rather than using Rbridge = (RBridge overview), these products use VLANs (RFC5517) into adjacent = network segments. Xirrus_BonjourDirectorAppNotes Aerohive Bonjour Gateway ArubaNetworks AirGroup =20 >> up resolvers. In addition, U-labels complying with RFC5198 will not >> ensure valid A-Labels=20 >=20 > There is no such thing as a U-label that does not generate an A-label, > and conversely. This is a property of U-labels and A-labels. If what > you're talking about is a non-U-label string that is nevertheless a > valid string using 5198, please say that. Read section 1.1 of RFC5895. There are few protocol checks on U-Labels. = U-Label enforcement is normally incumbent on those often called = registrars to ensure compliance with Unicode Standard Annex #15 Unicode = Normalization Forms which was revised three times since 2012. = http://www.unicode.org/reports/tr15/. IDNA2008 takes an anamorphic view of UTF-8 input described as depending = on geographic or cultural factors. As such, it does not offer fixed = translations between user input in UTF-8 form and A-labels. Any such = view has been deprecated along with the changed definition for A-Labels = also prefixed with the same "xn--". It is risky to assume symmetry = between A-Labels and encoded UTF-8 user input. U-Label validity is = assumed when a process defined in RFC3492 encodes A-Labels that resolve = records. Do not assume symmetry between UTF-8 user input and A-Labels = or that symmetry is being enforced by the protocol. Such enforcement is = not practical. Strong statements about U-label and A-label symmetry is = misleading.=20 >> A user may not be helped who expects local services that resolve >> elsewhere. There should be a preference for .local. >=20 > You do realise, right, that users never see ".local." on anything?=20 Users don't see the DNS search list either. A 'single operational = convention' for mDNS/DNS services outside the ".local." domain may have = applications obtaining domain search lists provided by DHCP (v4 = RFC2131, v6 RFC3315) or RA DNSSL (v6 RFC6106). DNS service domains must = be published as A-Labels (RFC5891). Since domain compliance depends on = A-label enforcement by registrars, A-Labels and not U-Labels must be = published in DNS. There is a DNS extension to support the live browse = feature found in mDNS. =20 The suggestion was to recommend an implied ".local." be positioned first = in a domain search list when fewer than 3 labels are entered when = applications make use of search domain lists. This would mean for = users not entering FQDNs they might experience a 3 second delay with the = benefit of better protecting the Internet and the user alike. >> Trill is able to transparently bridge multicast traffic by = encapsulating packets in a manner that protects against routing loops. >=20 > Ok. So, you are saying that DNS-SD has to be used onlt with mDNS? > That seems contrary to the specification. Also, it's contrary to > deployed practice. For instance, printers at IETF meetings are > discoverable using DNS-SD in the global DNS. In specific cases it may be practical to administratively pin services = to specific addresses and then use any number of publishing methods. At = the last meeting the printer's address was published in DNS as = term-printer.meeting.ietf.org and in mDNS within the terminal room. = Have been unable to find evidence DNS-SD had been implemented by the = IETF within DNS, although the charter did mention its use. term-printer.meeting.ietf.org. 3600 IN AAAA = 2001:67c:370:128:200:74ff:fee0:6cf8 term-printer.meeting.ietf.org. 3600 IN A 31.133.128.18 It seems highly doubtful most organizations will want selectively = configured local services exposed to the Internet, unlike the IETF. In my view, Rbridge represents an example that satisfies the WG charter = as does Xirrus, Aerohive, and Aruba products. For all of these = examples, a type of cross-link node filter is likely desired. As such, = one of the work products might include a standard format describing = desired service cross-links via VLAN or Rbridge. =20 Regards, Douglas Otis --Apple-Mail=_BE0CB23F-FCA3-406D-8A90-6D1690CE9F68 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = Andrew,

Please forgive my awkward summary of what I = understood you to be proposing.  Your document does not appear to = address the chartered problem.  Clearly you are also unhappy with = my use of the term U-Label.  My = apologies. 

See comments = inline.

On Jan 28, 2014, at 10:27 PM, Andrew = Sullivan <ajs@anvilwalrusden.com> = wrote:
Doug,

On Tue, Jan 28, 2014 at = 09:53:20PM -0800, Douglas Otis wrote:

Disagree.  A globally resolvable label in DNS = might not satisfy
applications expecting to discover local = services. 

But a significant part of the = _reason_ we started this WG was because
the services aren't actually = local.  They're on-campus, but they're
not in a link-local = context.  So far, there are exactly two contexts:
link-local and = not.  You seem to be proposing something further, but
if so I = really don't know what it is.  It'd be nice to get a = pointer.

The goal is to facilitate = access to mDNS gateways or proxies for access to services likely = publishing non-global addresses in mDNS which do not permit direct = Internet access and are not on a common network bridge.  Profoundly = not the same as transparently resolving global services which you seem = to suggest.

Here are some pointers to = proprietary products that may help compose a definition of the problem = being solved.  Rather than using Rbridge (RBridge overview), these products use VLANs (RFC5517) into adjacent = network segments.

 
up resolvers.  In addition, = U-labels complying with RFC5198 will not
ensure valid = A-Labels 

There is no such thing as a U-label = that does not generate an A-label,
and conversely.  This is a = property of U-labels and A-labels.  If what
you're talking about = is a non-U-label string that is nevertheless a
valid string using = 5198, please say that.

Read section 1.1 of = RFC5895.  There are few protocol checks on U-Labels. =  U-Label enforcement is normally incumbent on those often called = registrars to ensure compliance with Unicode Standard Annex #15 Unicode = Normalization Forms which was revised three times since 2012.  http://www.unicode.org/repor= ts/tr15/.

IDNA2008 takes an anamorphic view = of UTF-8 input described as depending on geographic or cultural factors. =  As such, it does not offer fixed translations between user input = in UTF-8 form and A-labels.  Any such view has been deprecated = along with the changed definition for A-Labels also prefixed with the = same "xn--".  It is risky to assume symmetry between A-Labels and = encoded UTF-8 user input.  U-Label validity is assumed when a = process defined in RFC3492 encodes A-Labels that resolve records. =  Do not assume symmetry between UTF-8 user input and A-Labels or = that symmetry is being enforced by the protocol.  Such enforcement = is not practical.  Strong statements about U-label and A-label = symmetry is misleading. 

A user may not be helped who = expects local services that resolve
elsewhere.  There should be = a preference for .local.

You do realise, right, that = users never see ".local." on = anything? 

Users don't see the = DNS search list either. A 'single operational convention' for mDNS/DNS = services outside the ".local." domain may have applications obtaining = domain search lists provided by DHCP (v4  RFC2131, v6 RFC3315) or = RA DNSSL (v6 RFC6106).  DNS service domains must be published as = A-Labels (RFC5891).  Since domain compliance depends on A-label = enforcement by registrars, A-Labels and not U-Labels must be published = in DNS.  There is a DNS extension to support the live browse = feature found in mDNS.  

The suggestion = was to recommend an implied ".local." be positioned first in a domain = search list when fewer than 3 labels are entered when applications make = use of search domain lists.   This would mean for users not = entering FQDNs they might experience a 3 second delay with the benefit = of better protecting the Internet and the user = alike.

Trill is able to transparently bridge multicast traffic by = encapsulating packets in a manner that protects against routing = loops.

Ok.  So, you are saying that DNS-SD has = to be used onlt with mDNS?
That seems contrary to the specification. =  Also, it's contrary to
deployed practice.  For instance, = printers at IETF meetings are
discoverable using DNS-SD in the global = DNS.

In specific cases it may be = practical to administratively pin services to specific addresses and = then use any number of publishing methods.  At the last meeting the = printer's address was published in DNS as term-printer.meeting.ietf.or= g and in mDNS within the terminal room.  Have been unable to = find evidence DNS-SD had been implemented by the IETF within DNS, = although the charter did mention its use.

term-printer.meeting.ietf.or= g. = 3600 IN = AAAA = 2001:67c:370:128:200:74ff:fee0:6cf8
term-printer.meeting.ietf.or= g. = 3600 IN = A = 31.133.128.18

It seems highly doubtful = most organizations will want selectively configured local services = exposed to the Internet, unlike the IETF.

In my = view, Rbridge represents an example that satisfies the WG charter as = does Xirrus, Aerohive, and Aruba products.  For all of these = examples, a type of cross-link node filter is likely desired.  As = such, one of the work products might include a standard format = describing desired service cross-links via VLAN or Rbridge. =  

Regards,
Douglas = Otis



= --Apple-Mail=_BE0CB23F-FCA3-406D-8A90-6D1690CE9F68-- From ajs@anvilwalrusden.com Wed Jan 29 19:11:55 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 657EA1A046B for ; Wed, 29 Jan 2014 19:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 gY-3euT0_HkA for ; Wed, 29 Jan 2014 19:11:53 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id BFEDC1A0468 for ; Wed, 29 Jan 2014 19:11:53 -0800 (PST) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 3B0F48A031 for ; Thu, 30 Jan 2014 03:11:50 +0000 (UTC) Date: Wed, 29 Jan 2014 22:11:48 -0500 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20140130031147.GB43017@mx1.yitter.info> References: <20140122222616.GN1271@mx1.yitter.info> <20140123032553.GC1580@mx1.yitter.info> <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com> <20140124193205.GB2065@mx1.yitter.info> <20140128035044.GB7975@mx1.yitter.info> <20140129062726.GB9511@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 30 Jan 2014 03:11:55 -0000 Hi Doug, On Wed, Jan 29, 2014 at 06:44:39PM -0800, Douglas Otis wrote: > Please forgive my awkward summary of what I understood you to be proposing. If there's anyone to apologise, it's obviously me, since I've made such a hash of making my meaning clear. > On Jan 28, 2014, at 10:27 PM, Andrew Sullivan wrote: > > The goal is to facilitate access to mDNS gateways or proxies for > access to services likely publishing non-global addresses in mDNS > which do not permit direct Internet access and are not on a common > network bridge. Profoundly not the same as transparently resolving > global services which you seem to suggest. I don't think that's right. Here's what the charter says: The focus of the WG is to develop a solution for extended, scalable DNS-SD. This work is likely to highlight problems and challenges with naming protocols, as some level of coexistence will be required between local zero configuration name services and those forming part of the global DNS. That seems to me to suggest that we have to cope with service discovery in a global context. These are, clearly, not necessarily global services, but I wasn't trying to suggest that. > Read section 1.1 of RFC5895. There are few protocol checks on > U-Labels. So what? We're developing protocol here, and _we_ need to be clear. There is a perfectly good definition of U-label in RFC 5890, section 2.3.2.1. Importantly, that section specifically says that a thing that might be a U-label but that hasn't been determined yet. We sometimes call these "putative U-labels" or something of that sort. It's really important in this conversation to be clear about this distinction, however, or we'll never get clear on what we're talking about. > depending on geographic or cultural factors. As such, it does not > offer fixed translations between user input in UTF-8 form and > A-labels. Of course not. Not all user input is in fact a U-label. For instance, depending on your operating system, your user input may not be UTF-8 in NFC. And that barely gets us started. That's why we have the definition of U-label we have. Yes, this imposes all kinds of stuff on clients, and no, it is not reasonable to expect that everyone will do this correctly. That's why IDNA suggests so strongly that different layers each need to do their own validation. > The suggestion was to recommend an implied ".local." be positioned > first in a domain search list when fewer than 3 labels are entered > when applications make use of search domain lists. This would mean > for users not entering FQDNs they might experience a 3 second delay > with the benefit of better protecting the Internet and the user > alike. Why do you think that the right level is fewer than 3 labels? It seems to me that you're depending in that case on a view about what's "probably actually DNS" and "probably not" that is at least dodgy in the current ICANN policies. > room. Have been unable to find evidence DNS-SD had been implemented > by the IETF within DNS, although the charter did mention its use. Stuart Cheshire has used this repeatedly as an example for DNS-SD, so I encourage you to look through minutes of past meetings. He also has said repeatedly that Apple uses it this way. > It seems highly doubtful most organizations will want selectively configured local services exposed to the Internet, unlike the IETF. Who says they're exposed to the Internet? First, publishing something in the DNS hardly means that the service is available. Second, split horizons are, despite the IETF's lalalala-i-can't-hear-you act, a reality. Regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From bmanning@isi.edu Thu Jan 30 10:24: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 ED2A21A0260 for ; Thu, 30 Jan 2014 10:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 IHbeBm__dqD4 for ; Thu, 30 Jan 2014 10:24:05 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id D74B21A0450 for ; Thu, 30 Jan 2014 10:24:04 -0800 (PST) Received: from [172.17.0.199] (210-86-29-96.adsl.xtra.co.nz [210.86.29.96]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s0UINDKI022247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Jan 2014 10:23:26 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=windows-1252 From: manning bill In-Reply-To: Date: Thu, 30 Jan 2014 10:23:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140122222616.GN1271@mx1.yitter.info> <20140123032553.GC1580@mx1.yitter.info> <779216FA-E974-4C95-A46F-DD55F6FC4F89@gmail.com> <20140124193205.GB2065@mx1.yitter.info> <20140128035044.GB7975@mx1.yitter.info> <20140129062726.GB9511@mx1.yitter.info> <4C4EF3BC-AA8E-421F-BF78-5B11761B06D3@isi.edu> <20140130003451.GB10572@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1827) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Cc: dnssd@ietf.org Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00 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, 30 Jan 2014 18:24:07 -0000 to hammer the point home, this from Krebs blog=85 "Th[e] analysis looked at a malware component used in Target breach that = was uploaded to Symantec=92s ThreatExpert scanning service on Dec. 18 = but which was later deleted (a local PDF copy of it is here). The = ThreatExpert writeup suggests that the malware was responsible for = moving stolen data from the compromised cash registers to that shared = central repository, which had the internal address of 10.116.240.31. The = =93ttcopscli3acs=94 bit is the Windows domain name used on Target=92s = network. The user account =93Best1_user=94 and password =93BackupU$r=94 = were used to log in to the shared drive=94 Shared names & addresses, or networks that facilitate the same have the = side effect of being easier targets for malware built elsewhere. DNSSD = should try and avoid this trap. /bill Neca eos omnes. Deus suos agnoscet. On 29January2014Wednesday, at 16:53, manning bill = wrote: > rants below instead of top posting like God, Microsoft, and Apple = intended=85 :) >=20 > /bill > Neca eos omnes. Deus suos agnoscet. >=20 > On 29January2014Wednesday, at 16:34, Andrew Sullivan = wrote: >=20 >> Hi Bill, >>=20 >> On Wed, Jan 29, 2014 at 04:25:20PM -0800, manning bill wrote: >>> its not clear to me that the induced ambiguity of non-unique = addressing/labeling is worth the cost, particularly given that device = mobility >>> between broadcast domains is becoming the norm. >>=20 >> If I understand this correctly (and I _think_ you're saying something >> aligned with something Doug Otis was saying, though I believe I >> understood him less), what you're saying is that ambiguous, >> not-fully-qualified naming (or labelling -- I assume you mean "IP >> addressing" above) is just a bad idea in the current Internet, so we >> shouldn't do it. Is that right? >>=20 > mostly. if it was just addressing, then we have RFC 1918 and all the = existence proofs that link-local/single broadcast domains have real = difficultly > staying that way. once it involves names/labels, the ability of = multiple parties each claiming to be DC001, each with a divergent view = of its service group will cause havoc. >=20 > this is a known problem with Appletalk and its successors, DHCP = assigned names, etc. The problem is aggravated when one assigns = security associations with the Fully Qualified Name, > which is then overridden in a link local scope. I=92m not saying we = shouldn=92t do it, I=92m suggesting that all previous attempts have had = serious problems that are not being addressed in the current > work products. All of this goes away if we mandate/presume globally = unique names/labels. >=20 >=20 >> If so (and if I'm right about what Doug was saying -- again, I'm not >> at all confident in my interpretation), I find this hard to square >> with the WG charter. Are you saying that the WG is working on a >> problem that can't actually be solved or shouldn't be solved or >> something? (I'm prepared to concede that possibility; I'm just = trying >> to understand what we're discussing.) >=20 > I suggest that the work done to date does not solve the problems = stated in the Charter, as I understand it, >=20 >>=20 >> A >>=20 >>=20 >> --=20 >> Andrew Sullivan >> ajs@anvilwalrusden.com >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >=20