LLMNR Issue 33 [Was: Re: Revision to resolution of Issue 28]

LLMNR Issue 33 [Was: Re: Revision to resolution of Issue 28]

Post by Mika Liljeber » Sat, 19 Apr 2003 02:45:21




>  > It occurs to me that it would be a whole lot simpler to do the PTR
>  > queries using unicast. The LLMNR resolver could use a TTL=1 when
>  > sending the query. This way it would either get an immediate
>  > no-route response from the local TCPIP stack, a direct response from
>  > the holder of the address, or an ICMP time exceeded reply from the
>  > default router. Either way, the resolver wouldn't have to do any
>  > checking on the address. This approach has several benefits:

>  > 1) Immediate error response if there is no route for the address
>  > 2) Error response from default router if the address is off-link
>  > 3) LLMNR resolver does not need to do any checking on the address
>  > 4) Unicast is easier on the network

> I think that is a good idea.  This is what the Node Information Query
> reverse lookup does.

> When asked to reverse lookup a multicast address what then?  Offhand I
> can't think of a good reason not to just multicast the PTR query to
> the address you are looking up.

I think we have to be careful here. Even though setting TTL=1 would
limit the propagation, I wouldn't want to send a PTR query to the subnet
broadcast address.

The first question is, is it useful to support PTR queries for multicast
and broadcast addresses at all? If yes, we have to define the behaviour
both ways. Does a responder also include its subscribed multicast
addresses to A and AAAA responses? Multicast addresses would also have
to be treated as non-UNIQUE RRs to avoid problems with conflict
resolution.

I would say just return an error to PTR queries for multicast/broadcast
addresses.

        MikaL

--

the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

 
 
 

1. Proposed Resolution to LLMNR Issue 33: PTR via Unicast

Issue 33 is given below. The proposed resolution is as follows:

In Section 3, change:

"[4] A sender SHOULD only send LLMNR queries for PTR RRs
that represent addresses reachable on the link
over which LLMNR is used."

To:

"[4] A sender SHOULD send LLMNR queries for PTR RRs
via unicast over TCP, as specified in Section 2.3."
Note: Acceptance of the proposed resolution to Issue 33 is dependent on
acceptance of the proposed resolution to Issue 34 (to follow).

---------------------------------------------------------------------
Issue 33: PTR via Unicast
Submitter: Mika Liljeberg

Date first submitted: April 17, 2003
Reference:

Document: LLMNR-16
Comment type: T
Priority: S
Section: 3
Rationale/Explanation of issue:

It occurs to me that it would be a whole lot simpler to do PTR
queries using unicast. The LLMNR resolver could use a TTL=1 when
sending the query. This way it would either get an immediate no-route
response from the local TCPIP stack, a direct response from the holder
of the address, or an ICMP time exceeded reply from the default router.
Either way, the resolver wouldn't have to do any checking on the
address. This approach has several benefits:

1) Immediate error response if there is no route for the address
2) Error response from default router if the address is off-link
3) LLMNR resolver does not need to do any checking on the address
4) Unicast is easier on the network

Note that conflict resolution for addresses is taken care by DAD, so
using unicast for PTR shouldn't make any difference there. Another
assumption is that the PTR query is already vulnerable to spoofing on
the local link, so, as long as we use TTL=1 for the query there should
be no perceivable additional risk.

--

the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

2. Digital Physics

3. Proposed Resolution of LLMNR Issue 28

4. How can I insert to PF2K2?

5. LLMNR Issues 33,34,35 threat analysis and proposal [RE: Proposed Resolution to LLMNR Issue 33: PTR via Unicast]

6. Unattended File Transfer OS/2-AS/400

7. Revision to resolution of Issue 28

8. FS: Mac stuff--some of it works

9. Proposed Resolution to LLMNR Issue 37: Conflict Detection Issues

10. LLMNR Issue 33: PTR via Unicast

11. LLMNR Issue 28: Addressing

12. Proposed resolution to LLMNR Issue 39: Name Conflict Detection Algorithm

13. Revised resolution Proposal for LLMNR Issue 38: DNS Proxy undefined