Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
Iljitsch van Beijnum <iljitsch@muada.com> Tue, 30 August 2005 21:48 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EADy8-0007v1-U7; Tue, 30 Aug 2005 17:48:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EADy5-0007uQ-OV; Tue, 30 Aug 2005 17:48:33 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11317; Tue, 30 Aug 2005 17:48:30 -0400 (EDT)
Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EADzi-00073O-1K; Tue, 30 Aug 2005 17:50:14 -0400
Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id j7ULm7P8026869 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 30 Aug 2005 23:48:07 +0200 (CEST) (envelope-from iljitsch@muada.com)
In-Reply-To: <E1E2vc4-0005tK-3G@newodin.ietf.org>
References: <E1E2vc4-0005tK-3G@newodin.ietf.org>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <FF02984E-5095-412D-B3C3-3DF1C4B8E5A6@muada.com>
Content-Transfer-Encoding: 7bit
From: Iljitsch van Beijnum <iljitsch@muada.com>
Date: Tue, 30 Aug 2005 23:48:07 +0200
To: iesg@ietf.org
X-Mailer: Apple Mail (2.734)
X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org, IETF General Discussion Mailing List <ietf@ietf.org>
Subject: Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
On 10-aug-2005, at 20:47, The IESG wrote: > The IESG has received a request from the DNS Extensions WG to > consider the > following document: > - 'Linklocal Multicast Name Resolution (LLMNR) ' > <draft-ietf-dnsext-mdns-42.txt> as a Proposed Standard > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2005-08-24. Sorry for the delay. After the discussion on the IETF list I thought it prudent to do a more thorough review of the draft. This statement: [a] Responders MUST listen on UDP port 5355 on the link-scope multicast address(es) defined in Section 2, and on UDP and TCP port 5355 on the unicast address(es) that could be set as the source address (es) when the responder responds to the LLMNR query. Seems to be in conflict with: Unicast LLMNR queries MUST be done using TCP and the responses MUST be sent using the same TCP connection as the query. Senders MUST support sending TCP queries, and responders MUST support listening for TCP queries. If the sender of a TCP query receives a response to that query not using TCP, the response MUST be silently discarded. Unicast UDP queries MUST be silently discarded. Why would a responder be required to listen on unicast UDP and then have to silently discard anything that comes in? Section 2.4 discusses use of TCP for LLMNR queries and responses. In composing an LLMNR query using TCP, the sender MUST set the Hop Limit field in the IPv6 header and the TTL field in the IPv4 header of the response to one (1). The responder SHOULD set the TTL or Hop Limit settings on the TCP listen socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This prevents an incoming connection from off-link since the sender will not receive a SYN-ACK from the responder. For UDP queries and responses, the Hop Limit field in the IPv6 header and the TTL field in the IPV4 header MAY be set to any value. However, it is RECOMMENDED that the value 255 be used for compatibility with Apple Bonjour [Bonjour]. Why not REQUIRE that UDP queries/responses have a TTL of 255. Then the receiver of a packet can determine with almost complete certainty that the packet didn't traverse any routers by checking if the received packet has a TTL of 255. (See (amongst others) ICMPv6 for how this works.) Since LLMNR queries can be sent when DNS server(s) do not respond, an attacker can execute a denial of service attack on the DNS server(s) and then poison the LLMNR cache by responding to an LLMNR query with incorrect information. Couldn't have said it better myself. LLMNR takes the approach of intermingling the locally resolved namespace with the globally resolved namespace. This will lead to security problems such as the one mentioned above (the security considerations section is way too cavalier), but also unduly puts strain on both the local and the global mechanisms in the expected common case where a host will first try to resolve a name globally and failing that, try to resolve the name locally. For instance, when a user configures a name that doesn't exist in the global namespace on a locally reachable device, and then references that device by name, this will involve the global DNS unnecessarily. Since the intended result does materialize, the user doesn't see a failure condition and the situation persists. Alternatively, whenever there is a failure in the global DNS, for instance because of lack of reachability, unavailability of a DNS server or the user typing an incorrect name, this will result in a local multicast query. On some links this is very undesirable. Low- bandwidth links such as cell phone data services are an obvious example. Another one is IEEE 802.11x. Due to its one-to-many nature broadcasts and multicasts must be sent at an artificial low bitrate on these links, using up an inordinate amount of link bandwidth relative to the packet size. I suggest that the IESG either send back the draft to the wg to fix these problems or at most approves publication as an experimental RFC and NOT a standards track RFC. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stuart Cheshire
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Margaret Wasserman
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stuart Cheshire
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Harald Tveit Alvestrand
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Marc Manthey
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stuart Cheshire
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Keith Moore
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Margaret Wasserman
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stuart Cheshire
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stuart Cheshire
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stuart Cheshire
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Margaret Wasserman
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Margaret Wasserman
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stephane Bortzmeyer
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Marc Manthey
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stephane Bortzmeyer
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Russ Allbery
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Brian E Carpenter
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Bill Manning
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Marshall Eubanks
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Keith Moore
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Ian Jackson
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Iljitsch van Beijnum
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Russ Allbery
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Bill Manning
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Rob Austein
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Marc Manthey
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Steven M. Bellovin
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Pete Resnick
- Re: Last Call: 'Linklocal Multicast Name Resoluti… bmanning
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Brian E Carpenter
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Russ Allbery
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Ian Jackson
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Brian E Carpenter
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stuart Cheshire
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stuart Cheshire
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Margaret Wasserman
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- RE: Last Call: 'Linklocal Multicast Name Resoluti… Christian Huitema
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Margaret Wasserman
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stuart Cheshire
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Iljitsch van Beijnum
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Ned Freed
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Russ Allbery
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Russ Allbery
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Iljitsch van Beijnum
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Jeffrey Hutzelman
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Spencer Dawkins
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Henrik Levkowetz
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Bill Manning
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Marc Manthey
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Brian E Carpenter
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Steven M. Bellovin
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Jeroen Massar
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Brian E Carpenter
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Single DNS root (Re: Last Call: 'Linklocal Multic… Harald Tveit Alvestrand
- RE: Last Call: 'Linklocal Multicast Name Resoluti… Christian Huitema
- Alternative roots (was: Re: Last Call: 'Linklocal… Paul Hoffman
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Paul Hoffman
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Christian de Larrinaga
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Eric A. Hall
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Ned Freed
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Ned Freed
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Eric A. Hall
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Ian Jackson
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Ned Freed
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Ian Jackson
- RE: Last Call: 'Linklocal Multicast Name Resoluti… Ian Jackson
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Tony Finch
- RE: Last Call: 'Linklocal Multicast Name Resoluti… Stuart Cheshire
- RE: Last Call: 'Linklocal Multicast Name Resoluti… Christian Huitema
- RE: Last Call: 'Linklocal Multicast Name Resoluti… Dave Singer
- Re: Single DNS root JFC (Jefsey) Morfin
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Keith Moore
- RE: Last Call: 'Linklocal Multicast Name Resoluti… Jeroen Massar
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Frank Ellermann
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Jeroen Massar
- Name ownership and LLMNR (Re: Last Call: 'Linkloc… Harald Tveit Alvestrand
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Ian Jackson
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Keith Moore
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Henning Schulzrinne
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Iljitsch van Beijnum
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Tony Finch
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Alan Barrett
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Iljitsch van Beijnum
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Tony Finch
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Paul Vixie
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stephane Bortzmeyer
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Paul Vixie
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Ian Jackson
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Harald Tveit Alvestrand
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Jeroen Massar
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Iljitsch van Beijnum
- Re: Single DNS root John C Klensin
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Daniel Senie
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Jeffrey Hutzelman
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Harald Tveit Alvestrand
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Iljitsch van Beijnum
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Bill Manning
- Re: Single DNS root JFC (Jefsey) Morfin
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Tony Finch
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Steven M. Bellovin
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Tony Finch
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Masataka Ohta
- Re: Last Call: 'Linklocal Multicast Name Resoluti… JFC (Jefsey) Morfin
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Harald Tveit Alvestrand
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Daniel Karrenberg
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… JFC (Jefsey) Morfin
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Andrew Sullivan
- RE: Last Call: 'Linklocal Multicast Name Resoluti… Stuart Cheshire