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(_at_)ietf(_dot_)org or ietf(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf