Re: [mdnsext] Discussion of BoF during Berlin IETF

"Albrecht, Harald" <harald.albrecht@siemens.com> Tue, 11 June 2013 09:09 UTC

Return-Path: <harald.albrecht@siemens.com>
X-Original-To: mdnsext@ietfa.amsl.com
Delivered-To: mdnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7051121F8481 for <mdnsext@ietfa.amsl.com>; Tue, 11 Jun 2013 02:09:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.248
X-Spam-Level:
X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZH0FNSEh6YW for <mdnsext@ietfa.amsl.com>; Tue, 11 Jun 2013 02:09:00 -0700 (PDT)
Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by ietfa.amsl.com (Postfix) with ESMTP id 20CC521F89EB for <mdnsext@ietf.org>; Tue, 11 Jun 2013 02:08:53 -0700 (PDT)
Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.13.6/8.13.6) with ESMTP id r5B98mVn012917 for <mdnsext@ietf.org>; Tue, 11 Jun 2013 11:08:49 +0200
Received: from DEFTHW99ET7MSX.ww902.siemens.net ([157.163.145.4]) by mail2.sbs.de (8.13.6/8.13.6) with ESMTP id r5B98mSV005517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <mdnsext@ietf.org>; Tue, 11 Jun 2013 11:08:48 +0200
Received: from DEFTHW99ER5MSX.ww902.siemens.net (139.22.70.77) by DEFTHW99ET7MSX.ww902.siemens.net (157.163.145.4) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 11 Jun 2013 11:08:47 +0200
Received: from DEFTHW99EK5MSX.ww902.siemens.net ([169.254.6.134]) by DEFTHW99ER5MSX.ww902.siemens.net ([139.22.70.77]) with mapi id 14.02.0342.003; Tue, 11 Jun 2013 11:08:47 +0200
From: "Albrecht, Harald" <harald.albrecht@siemens.com>
To: "mdnsext@ietf.org" <mdnsext@ietf.org>
Thread-Topic: [mdnsext] Discussion of BoF during Berlin IETF
Thread-Index: AQHOYSnHoLNfrYhO9UyyRiqKaj691Jkmr/9wgABRSACAA0/1AIAESRgA
Date: Tue, 11 Jun 2013 09:08:47 +0000
Message-ID: <E36F274013087B4EA05E08EB5037503901F483@DEFTHW99EK5MSX.ww902.siemens.net>
References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> <19956.1370353531@sandelman.ca> <E36F274013087B4EA05E08EB5037503901820D@DEFTHW99EK5MSX.ww902.siemens.net> <22635.1370439768@sandelman.ca> <CABOxzu20VrSc1_HGzPZgjQk5=tuGObn+MFjGrCriijhNck6P=w@mail.gmail.com>
In-Reply-To: <CABOxzu20VrSc1_HGzPZgjQk5=tuGObn+MFjGrCriijhNck6P=w@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [139.22.70.55]
Content-Type: multipart/alternative; boundary="_000_E36F274013087B4EA05E08EB5037503901F483DEFTHW99EK5MSXww9_"
MIME-Version: 1.0
Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF
X-BeenThere: mdnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <mdnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mdnsext>, <mailto:mdnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mdnsext>
List-Post: <mailto:mdnsext@ietf.org>
List-Help: <mailto:mdnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mdnsext>, <mailto:mdnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jun 2013 09:09:07 -0000

Kerry,

thank you for the clarification.

Von: kerlyn2001@gmail.com [mailto:kerlyn2001@gmail.com] Im Auftrag von Kerry Lynn
Gesendet: Freitag, 7. Juni 2013 18:18
An: Michael Richardson; Albrecht, Harald
Cc: mdnsext@ietf.org
Betreff: Re: [mdnsext] Discussion of BoF during Berlin IETF
    Albrecht> How true, that's where the devil is in the details. mDNS
    Albrecht> uses UTF-8 encoding on the wire and DNS uses (at least for
    Albrecht> host domain names) ASCII/IDNA-2008. Throw in different
    Albrecht> resolver libs and IDNA support and you are ready for an
    Albrecht> instant recipe disaster.
I will still like someone to generate a very simple example that illustrates the
difficulty so I can include it in the requirements draft.  It is my understanding
that the <Instance> part of a DNS-SD name (i.e. the name of the SRV and TXT
records) can be arbitrary Net-Unicode text [RFC5198] excluding the control chars
0x00-0x1F and 0x7F.  It is silent, so far as I can tell, on host names.  It may be
that OS X allows UTF-8 host names, which subsequently occur in mDNS
packets..

No problem ... at least I hope this example to be sufficient simple enough. I'm illustrating the issue for name-address resolution and not service discovery, but the underlying issue is the same. It is just that name-address resolution is more basic as we always need it and most people are more interested in it as they see immediate use.

My analysis bases on the GNU libc as one example, other implementations may differ very well (and most probably will). Code base is glib 2.17 as available from the FSF ftp servers. I tried to make sure that I did not make any (gross) mistakes in my analysis. However, caveat emptor, and if you find errors in my analysis please explain them to us so I (and maybe others) can learn.

The IDNA "theory" (at least to my understanding from reading the IDNA 2008 RFCs, which are in my opinion very well written) is as follows:
1. a user enters some internationalized domain name, for instance through a UI. Say, she enters "ship.fløtsäm" (with a nod to Peter Gabriel). We don't care about the concrete encoding here, it may be UTF-16 for instance.
2. Feed this into getaddrinfo() - now, we need to use the AI_IDN flag here. So what will happen inside getaddrinfo()?
3. We don't know at this point which specific resolver will resolve the given "ship.fløtsäm", but we have this AI_IDN flag! With glibc, getaddrinfo() (in systeps/posix/getaddrinfo.c) somehow ends up in gaih_inet(), where AI_IDN gets checked for. If it is set and a name present, then IDNA conversion takes place, where the given name in the current locale encoding gets translated into ACE: "ship.xn--fltsm-jra1l".
4. Only later comes the "hosts" lookup, that is, the call to __nss_database_lookup ("hosts",...) where the dispatch to the DNS or mDNS resolver(s) steps in. Unfortunately, we already have IDN invoked.

So what has happened here? ACE (ASCII compatible encoding) gets always invoked if the caller specifies AI_IDN. However, if mDNS is later used for resolving this is not what should have been done: mDNS specifies immediate UTF-8 encoding and not ACE. However, for DNS we need ACE. So we end up in the unfortunate situation that the application has to know in advance what resolver will be used ... but it cannot, as the domain name given may be relative. And yes, the RFCs also say that the DNS server search list is to be applied only to DNS and not mDNS. But this still doesn't help us with the problem that the application has to know whether a domain name belongs to mDNS or not.

At least according to my current (limited) understanding, something seems to be borked here... ;) Any enlightment is highly appreciated!

With best regards,
Harald

Harald Albrecht
Siemens AG
Industry Sector
Industry Automation Division
Industrial Automation Systems
I IA AS CTO DH 1
Gleiwitzer Str. 555
90475 Nürnberg, Deutschland
Tel: +49 911 895-3847
Fax: +49 911 895-2105
mailto:harald.albrecht@siemens.com

Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme; Vorstand: Peter Löscher, Vorsitzender; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Süß; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322