Subject: Re: Proposed Resolution to LLMNR Issue 21: PTR queries

From: Mika Liljeberg <[email-masked]>
Date: 02 Apr 2003 00:06:04 +0300

Hi,

On Tue, 2003-04-01 at 08:33, Bernard Aboba wrote:
> Given the discussion at IETF 56 and the currently proposed resolutions to
> Issue 28 and 29, I would like to propose that sending of LLMNR queries for
> PTR RRs that represent "off link" addresses should be discouraged. The
> proposed resolution is given below. Comments?

I have no objection to "should be discouraged". However, it should be
realized that on many operating systems this restriction may be very
difficult to implement in practise. Offhand I can't think of an easy way
for an application to check whether a particular address is "on link".

	MikaL

--
> Issue 21: PTR queries
> Submitter: Markku Savela
> Submitter email address: [email-masked]
> Date first submitted: November 4, 2002
> Reference: <[email-masked]>
> Document: LLMNR-12
> Comment type: T
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
> I assume that if you end up doing a address (fe80::1) to name query
> for IPv6, you end up sending a query to IPv6 multicast address
> generated from the hash of
> 
> "1.0.0. ... 0.0.8.e.f.ip6.int"
> 
> and because the hash is taken from the first label, this will be MD5
> from "1"? (basically only 16 different hashes are possible).
> 
> IPv4 side you have for example "1.2.254.169.in-addr.arpa".
> 
> Am I right assuming the "resolvers" on nodes have to deal also with
> these for link local name resolution?
> 
> [BA] Yes, it is expected that senders will send PTR
> queries, and that receivers will respond to them.
> However, it probably doesn't make sense to send a
> PTR query for an address that isn't on the local
> link. Here's the proposed resolution:
> 
> Add the following text to Section 3:
> 
> "[3] A sender SHOULD only send LLMNR queries for PTR RRs that
> are known to be "on link" as defined in Section 2.5."
> 
> [Erik Guttman and Erik Nordmark]:
> 
> The problem is that in practice a host may not know the
> prefixes in use on a particular link. So this restriction
> can't work in practice.
> 
> [Comment from Mark T. Hollinger <[email-masked]>]:
> 
> I think we are being too hasty to throw out this restriction. As I
> metioned in my recent Namedroppers post, supporting your original proposal
> for issue #3, I would like the fallback to LLMNR not to occur at all for
> apparantly non-local prefixes.
> 
> If there is a prefix on your link that you don't know about via your
> routing table, then I don't think LLMNR needs to handle inverse queries
> for that zone. The target user for LLMNR probably won't have multiple
> unadvertised global prefixes in the first place. Anybody sophisticated
> enough to set that up will already have the address of a DNS server
> configured.
> 
> Also, if you don't know about the other guy's prefix, he may not know
> about yours either, in which case he'll get your multicast request but try
> to send a unicast response via the router, which may decrement the TTL
> when forwarding it back onto the same link. I'm not sure LLMNR will work
> in this case (due to the TTL 255 check), but even if it works, I think a
> configuration where hosts have to communicate (even only initially) via a
> router is out-of-scope for LLMNR. Let traditional DNS handle that case; we
> don't need LLMNR there.
> 
> [BA]
> Back of the envelope calculations seem to indicate to me that
> bogus PTR queries can be a significant problem in some cases. Measurements
> show that a significant fraction of DNS queries are not answered, and this
> is particularly true with PTR queries. So we can have a substantial amount
> of bogus LLMNR PTR query traffic. I am particularly worried about wireless
> networks with lots of people like at IETF 56. 5 queries a second from
> 3000 people would end up eating up a significant fraction of the total
> bandwidth of an 802.11 network, particularly if there are lots of folks
> who have to step down to lower rates (1,2,5 Mbps). So there is some reason
> for concern.
> 
> In the discussion at IETF 56, there was concern that it might not be
> possible for a host to know all the networks it was connected to. The
> question then arises as to whether it is ok not to send a PTR query for
> addresses on networks the host doesn't know about. It was pointed out that
> if the host doesn't have a route for that address, then it will route the
> packet to the gateway, which might not have a route for it either.
> 
> In view of the proposed resolution to Issue 28 and 29, it would
> appear that it makes little sense to send queries for PTR RRs
> that aren't "on link".
> 
> 
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 1 Apr 2003 16:24:51 -0800 (PST)

> for an application to check whether a particular address is "on link".

In practice, I think an on-link address is one which corresponds to
link-scope address or an address corresponding to a prefix in the routing
table mapped to an interface.

---

From: Mika Liljeberg <[email-masked]>
Date: 02 Apr 2003 07:55:12 +0300

> table mapped to an interface.

My point is that the latter case is hard for an application to check,
unless the kernel provides a syscall for it. Or is LLMNR supposed to
read the routing information from the kernel and replicate the next hop
selection code in user space?

	MikaL

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 Apr 2003 21:05:13 -0800 (PST)

> selection code in user space?

In practice, I don't think this needs to be required; the issue is about
the networks directly reachable from interfaces receiving or sending
queries, not about replicating next hop selection code.

Perhaps looking at some examples may help make sense of this. Let us
assume that Myhost is attached to two networks, A and B, and that it is
talking to host [1] on net A and host [2] on net B.

net B ----------  ---------- net A
       |      |    |     |
      [2]    [myhost]   [1]

Host [1] sends an LLMNR A/AAAA RR query for "myhost". Should myhost
respond with A/AAAA RRs for addresses on net B? This would be bad
if host [1] only has a LL address, since it would not be able to
reach net B. So I think it makes sense for myhost to only respond
with addresses on the interface from which the query came.

So far so good. However, the question is "what if myhost does the wrong
thing?" This is harder because host [1] may not have network B in its
routing table. It therefore will not know how to reach network B. Since
the point of LLMNR is to allow link-local name resolution, if host [1]
doesn't know how to reach net B on the local link then RRs containing that
address are not useful.

Perhaps the right thing to do here is to say that "addresses that are
reachable on the local link are preferred" by host [1]. That way, if
myhost only returned an address on network B, host [1] can try to connect
to that, possibly without success. But since there is no choice, what harm
can it do?

Another question is what happens if myhost attempts to connect to host
[1], using a source address on net B. In this case host [1] may attempt to
send a PTR RR query using LLMNR, for the address on net B. In this case,
myhost might respond to the query with the name myhost which is valid
on the interface. No harm is done. However, one might argue that
host [1] should not send such a query, and that if received,
myhost should not respond to it.

---

From: Mika Liljeberg <[email-masked]>
Date: 03 Apr 2003 10:17:38 +0300

Bernard,

> queries, not about replicating next hop selection code.

It's true that the route search is constrained to a single interface but
this does not essentially simplify the next hop selection algorithm. A
full route search is still required to do on-link determination (unless
you make some severe assumptions about the kind of routes that can lead
to a specific physical interface).

> Perhaps looking at some examples may help make sense of this.

Ok. I think your example addresses a different case from the one
discussed in issue 21 (PTR queries), but let's look at the example
first.

>  Let us

Right. Issue 29 clarifies this. I agree with the proposed resolution.

> thing?"

I don't think the multihomed and broken [myhost] is a very common case
but otherwise I agree with what you say:

>  This is harder because host [1] may not have network B in its

Agreed. To weed out the unusable address, the LLMNR resolver on [1]
should somehow check whether there is a route to it. On many operating
systems you can do this by attempting to connect a UDP socket to the
destination address. If there is no route, the connect() syscall will
fail.

Note that having a route to a destination is not the same thing as
knowing that the destination is on-link.

> reachable on the local link are preferred" by host [1].

The LLMNR resolver doesn't *know* which addresses are on-link, so it
can't prefer them.

>  That way, if

By host [1] do you mean the LLMNR responder of host [1] or the
applicaiton running on host [1]?

The LLMNR resolver can, on many operating systems, check the existence
of a route (e.g. by doing a UDP connect() to the address). However, what
it *cannot* do (as far as I can see), is check whether the destination
address is on-link.

In IPv6 the DNS resolver is already required to prefer reachable
addresses as part of default address selection [RFC3484].

> [1], using a source address on net B.

The only way this can happen is if a) [myhost] is badly broken, or b)
[myhost] uses the Weak ES model [RFC1122] and the addresses in question
are not link-locals. [zeroconf] forbids Weak ES model for link-locals.

>  In this case host [1] may attempt to

The more realistic example, the one which I thought was being dicussed
in the context of issue 21, is the following:

Internet ----------  ---------- net A
          |      |    |     |
         [2]    [router]   [1]

Host [2] is not in the global DNS. It connects to host [1], which tries
to make a PTR query to DNS with the address of [2]. [1] receives no
response from DNS (whatever the reason) and falls back on LLMNR. LLMNR
naturally fails as well.

As you say, no harm is done, but it would nice to skip the unnecessary
LLMNR query. I agree with the intent. I just don't see a good way to
actually implement it.

	MikaL

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 Apr 2003 23:22:42 -0800 (PST)

> The LLMNR resolver doesn't *know* which addresses are on-link, so it

Can it prefer responses that correspond to addresses it has routes for?

> application running on host [1]?

I mean the LLMNR responder.

> it *cannot* do (as far as I can see), is check whether the destination

I think this may be good enough. If a response doesn't have a
corresponding route then it can be ignored.

> addresses as part of default address selection [RFC3484].

That seems like a reasonable guideline to adopt here, too.

> LLMNR query. I agree with the intent. I just don't see a good way to

Yes. By your logic host [1] will have a route to [2] and so will send the
LLMNR query, even though it cannot succeed. My concern is that this will
happen very frequently and will needlessly consume bandwidth; on a
wireless network like IETF's this could have a significant (negative)
effect.

Perhaps the right thing is not to allow PTR RR queries in LLMNR at all?
Couldn't ICMP node information queries be a more appropriate substitute?

---

From: <[email-masked]>
Date: Thu, 3 Apr 2003 11:58:17 +0300

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Bernard,

> From: ext Bernard Aboba [mailto:[email-masked]]

> Can it prefer responses that correspond to addresses it has 

Yes, that would be my proposal.

> corresponding route then it can be ignored.

Agreed.

> wireless network like IETF's this could have a significant (negative)

Well, in general one should be able to rely on one's local recursive DNS server to return an error when it times out on a query. Especially in IETF meetings. :)

> Perhaps the right thing is not to allow PTR RR queries in 

Unfortunately this would break a number of applications that do reverse queries. I'd rather err on the side that doesn't break applications even if there is a small performance impact: if in doubt, do the PTR query. I.e., the LLMNR resolver should do the query if the host has a route for the address in question.

> Couldn't ICMP node information queries be a more appropriate 

Err, I'm not exactly sure how node information queries relate to LLMNR. As far as I'm concerned, it is a completely separate name/address resolution protocol which may or may not be used by IPv6 nodes in the future. I don't think it's wise to create a dependency between the LLMNR specification and node information queries. (And it won't solve the issue of PTR queries for IPv4 addresses).

	MikaL