draft-ietf-dnsext-mdns-29.txt   draft-ietf-dnsext-mdns-30.txt 
DNSEXT Working Group Levon Esibov DNSEXT Working Group Levon Esibov
INTERNET-DRAFT Bernard Aboba INTERNET-DRAFT Bernard Aboba
Category: Standards Track Dave Thaler Category: Standards Track Dave Thaler
<draft-ietf-dnsext-mdns-29.txt> Microsoft <draft-ietf-dnsext-mdns-30.txt> Microsoft
20 January 2004 17 March 2004
Linklocal Multicast Name Resolution (LLMNR) Linklocal Multicast Name Resolution (LLMNR)
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 17 skipping to change at page 2, line 17
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Requirements .................................... 3 1.1 Requirements .................................... 3
1.2 Terminology ..................................... 4 1.2 Terminology ..................................... 4
2. Name resolution using LLMNR ........................... 4 2. Name resolution using LLMNR ........................... 4
2.1 LLMNR packet format ............................. 5 2.1 LLMNR packet format ............................. 5
2.2 Sender behavior ................................. 8 2.2 Sender behavior ................................. 8
2.3 Responder behavior .............................. 8 2.3 Responder behavior .............................. 8
2.4 Unicast queries ................................. 10 2.4 Unicast queries ................................. 10
2.5 Off-link detection .............................. 11 2.5 Off-link detection .............................. 11
2.6 Responder responsibilities ...................... 12 2.6 Responder responsibilities ...................... 12
2.7 Retransmission and jitter ....................... 13 2.7 Retransmission and jitter ....................... 12
2.8 DNS TTL ......................................... 14 2.8 DNS TTL ......................................... 13
2.9 Use of the authority and additional sections .... 14 2.9 Use of the authority and additional sections .... 13
3. Usage model ........................................... 14 3. Usage model ........................................... 14
3.1 LLMNR configuration ............................. 15 3.1 LLMNR configuration ............................. 15
4. Conflict resolution ................................... 16 4. Conflict resolution ................................... 16
4.1 Considerations for multiple interfaces .......... 18 4.1 Considerations for multiple interfaces .......... 18
4.2 API issues ...................................... 19 4.2 API issues ...................................... 19
5. Security considerations ............................... 20 5. Security considerations ............................... 19
5.1 Scope restriction ............................... 20 5.1 Scope restriction ............................... 20
5.2 Usage restriction ............................... 21 5.2 Usage restriction ............................... 21
5.3 Cache and port separation ....................... 22 5.3 Cache and port separation ....................... 21
5.4 Authentication .................................. 22 5.4 Authentication .................................. 22
6. IANA considerations ................................... 22 6. IANA considerations ................................... 22
7. References ............................................ 22 7. References ............................................ 22
7.1 Normative References ............................ 22 7.1 Normative References ............................ 22
7.2 Informative References .......................... 23 7.2 Informative References .......................... 23
Acknowledgments .............................................. 24 Acknowledgments .............................................. 24
Authors' Addresses ........................................... 25 Authors' Addresses ........................................... 25
Intellectual Property Statement .............................. 25 Intellectual Property Statement .............................. 25
Full Copyright Statement ..................................... 26 Full Copyright Statement ..................................... 26
skipping to change at page 11, line 9 skipping to change at page 11, line 9
[a] A sender repeats a query after it received a response with the TC [a] A sender repeats a query after it received a response with the TC
bit set to the previous LLMNR multicast query, or bit set to the previous LLMNR multicast query, or
[b] The sender queries for a PTR RR of a fully formed IP address within [b] The sender queries for a PTR RR of a fully formed IP address within
the "in-addr.arpa" or "ip6.arpa" zones. the "in-addr.arpa" or "ip6.arpa" zones.
A responder receiving a unicast query MUST send the response with a A responder receiving a unicast query MUST send the response with a
source address set to the destination address field of the IP header of source address set to the destination address field of the IP header of
the query causing the response. the query causing the response.
Unicast LLMNR queries SHOULD be sent using TCP. Senders MUST support Unicast LLMNR queries MUST be sent using TCP. Senders MUST support
sending TCP queries, and responders MUST support listening for TCP sending TCP queries, and responders MUST support listening for TCP
queries. queries.
Responses to TCP unicast LLMNR queries MUST be sent using TCP, using Responses to TCP unicast LLMNR queries MUST be sent using TCP, using
the same connection as the query. If the sender of a TCP query receives the same connection as the query. If the sender of a TCP query receives
a response to that query not using TCP, the response MUST be silently a response to that query not using TCP, the response MUST be silently
discarded. discarded.
Unicast UDP queries MAY be responded to with a UDP response containing Unicast UDP queries MUST be silently discarded.
an empty answer section and the TC bit set, so as to require the sender
to resend the query using TCP.
If an ICMP "Time Exceeded" message is received in response to a unicast If TCP connection setup cannot be completed in order to send a unicast
UDP query, or if TCP connection setup cannot be completed in order to TCP query, this is treated as a response that no records of the
send a unicast TCP query, this is treated as a response that no records specified type and class exist for the specified name (it is treated the
of the specified type and class exist for the specified name (it is same as a response with RCODE=0 and an empty answer section).
treated the same as a response with RCODE=0 and an empty answer
section). The UDP sender receiving an ICMP "Time Exceeded" message
SHOULD verify that the ICMP error payload contains a valid LLMNR query
packet, which matches a query that is currently in progress, so as to
guard against a potential Denial of Service (DoS) attack. If a match
cannot be made, then the sender relies on the retransmission and timeout
behavior described in Section 2.7.
2.5. "Off link" detection 2.5. "Off link" detection
For IPv4, an "on link" address is defined as a link-local address For IPv4, an "on link" address is defined as a link-local address
[IPv4Link] or an address whose prefix belongs to a subnet on the local [IPv4Link] or an address whose prefix belongs to a subnet on the local
link. For IPv6 [RFC2460] an "on link" address is either a link-local link. For IPv6 [RFC2460] an "on link" address is either a link-local
address, defined in [RFC2373], or an address whose prefix belongs to a address, defined in [RFC2373], or an address whose prefix belongs to a
subnet on the local link. subnet on the local link.
A sender MUST select a source address for LLMNR queries that is "on A sender MUST select a source address for LLMNR queries that is "on
skipping to change at page 12, line 4 skipping to change at page 11, line 44
link". The destination address of an LLMNR query MUST be a link-scope link". The destination address of an LLMNR query MUST be a link-scope
multicast address or an "on link" unicast address. multicast address or an "on link" unicast address.
A responder MUST select a source address for responses that is "on A responder MUST select a source address for responses that is "on
link". The destination address of an LLMNR response MUST be an "on link" link". The destination address of an LLMNR response MUST be an "on link"
unicast address. unicast address.
On receiving an LLMNR query, the responder MUST check whether it was On receiving an LLMNR query, the responder MUST check whether it was
sent to a LLMNR multicast addresses defined in Section 2. If it was sent to a LLMNR multicast addresses defined in Section 2. If it was
sent to another multicast address, then the query MUST be silently sent to another multicast address, then the query MUST be silently
discarded. discarded.
In composing LLMNR queries, the sender MUST set the Hop Limit field in Section 2.4 discusses use of TCP for LLMNR queries and responses. In
the IPv6 header and the TTL field in IPv4 header of the response to one composing an LLMNR query using TCP, the sender MUST set the Hop Limit
(1). Even when LLMNR queries are sent to a link-scope multicast field in the IPv6 header and the TTL field in the IPv4 header of the
address, it is possible that some routers may not properly implement response to one (1). The responder SHOULD set the TTL or Hop Limit
link-scope multicast, or that link-scope multicast addresses may leak settings on the TCP listen socket to one (1) so that SYN-ACK packets
into the multicast routing system. Therefore setting the IPv6 Hop Limit will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This prevents
or IPv4 TTL field to one provides an additional precaution against an incoming connection from off-link since the sender will not receive a
leakage of LLMNR queries.
In composing a response to an LLMNR query, the responder MUST set the SYN-ACK from the responder.
Hop Limit field in the IPv6 header and the TTL field in IPv4 header of
the response to one (1). This is done so as to prevent the use of LLMNR
for denial of service attacks across the Internet.
Section 2.4 discusses use of TCP for LLMNR queries and responses. The For UDP queries and responses the Hop Limit field in the IPv6 header,
responder SHOULD set the TTL or Hop Limit settings on the TCP listen and the TTL field in the IPV4 header MAY be set to any value. However,
socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop it is RECOMMENDED that the value 255 be used for compatibility with
Limit (IPv6) set to one (1). This prevents an incoming connection from Apple Rendezvous.
off-link since the sender will not receive a SYN-ACK from the responder.
Implementation note: Implementation note:
In the sockets API for IPv4 [POSIX], the IP_TTL and IP_MULTICAST_TTL In the sockets API for IPv4 [POSIX], the IP_TTL and IP_MULTICAST_TTL
socket options are used to set the TTL of outgoing unicast and socket options are used to set the TTL of outgoing unicast and
multicast packets. The IP_RECVTTL socket option is available on some multicast packets. The IP_RECVTTL socket option is available on some
platforms to retrieve the IPv4 TTL of received packets with platforms to retrieve the IPv4 TTL of received packets with
recvmsg(). [RFC2292] specifies similar options for setting and recvmsg(). [RFC2292] specifies similar options for setting and
retrieving the IPv6 Hop Limit. retrieving the IPv6 Hop Limit.
skipping to change at page 13, line 36 skipping to change at page 13, line 21
answered after the first response is received. A unicast query sender answered after the first response is received. A unicast query sender
considers the query answered after the first response is received, so considers the query answered after the first response is received, so
that it only waits for LLMNR_TIMEOUT if no response has been received. that it only waits for LLMNR_TIMEOUT if no response has been received.
An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT
for each transmission. It is suggested that the computation of for each transmission. It is suggested that the computation of
LLMNR_TIMEOUT be based on the response times for earlier LLMNR queries LLMNR_TIMEOUT be based on the response times for earlier LLMNR queries
sent on the same interface. sent on the same interface.
For example, the algorithms described in RFC 2988 [RFC2988] (including For example, the algorithms described in RFC 2988 [RFC2988] (including
exponential backoff) to compute an RTO, which is used as the value of exponential backoff) compute an RTO, which is used as the value of
LLMNR_TIMEOUT. Smaller values MAY be used for the initial RTO (discussed LLMNR_TIMEOUT. Smaller values MAY be used for the initial RTO
in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO (discussed in (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO
Section 2 of [RFC2988], paragraph 2.4), and the maximum RTO (discussed (discussed in Section 2 of [RFC2988], paragraph 2.4), and the maximum
in Section 2 of [RFC2988], paragraph 2.5). RTO (discussed in Section 2 of [RFC2988], paragraph 2.5).
Recommended values are an initial RTO of 1 second, a minimum RTO of Recommended values are an initial RTO of 1 second, a minimum RTO of
200ms, and a maximum RTO of 5 seconds. In order to avoid 200ms, and a maximum RTO of 5 seconds. In order to avoid
synchronization, the transmission of each LLMNR query and response synchronization, the transmission of each LLMNR query and response
SHOULD delayed by a time randomly selected from the interval 0 to 100 SHOULD delayed by a time randomly selected from the interval 0 to 100
ms. This delay MAY be avoided by responders responding with RRs which ms. This delay MAY be avoided by responders responding with RRs which
they have previously determined to be UNIQUE (see Section 4 for they have previously determined to be UNIQUE (see Section 4 for
details). details).
2.8. DNS TTL 2.8. DNS TTL
skipping to change at page 17, line 47 skipping to change at page 17, line 30
UNIQUE. Uniqueness verification is carried out when the host: UNIQUE. Uniqueness verification is carried out when the host:
- starts up or is rebooted - starts up or is rebooted
- wakes from sleep (if the network interface was inactive during sleep) - wakes from sleep (if the network interface was inactive during sleep)
- is configured to respond to the LLMNR queries on an interface - is configured to respond to the LLMNR queries on an interface
enabled for transmission and reception of IP traffic enabled for transmission and reception of IP traffic
- is configured to respond to the LLMNR queries using additional - is configured to respond to the LLMNR queries using additional
UNIQUE resource records UNIQUE resource records
- detects that an interface is connected and is usable - detects that an interface is connected and is usable
(e.g. an IEEE 802 hardware link-state change indicating (e.g. an IEEE 802 hardware link-state change indicating
that a cable was attached or that an association has occurred that a cable was attached or completion of authentication
with a wireless base station and that any required authentication (and if needed, association) with a wireless base station
has completed) or adhoc network
When a host that has a UNIQUE record receives an LLMNR query for that When a host that has a UNIQUE record receives an LLMNR query for that
record, the host MUST respond. After the client receives a response, it record, the host MUST respond. After the client receives a response, it
MUST check whether the response arrived on an interface different from MUST check whether the response arrived on an interface different from
the one on which the query was sent. If the response arrives on a the one on which the query was sent. If the response arrives on a
different interface, the client can use the UNIQUE resource record in different interface, the client can use the UNIQUE resource record in
response to LLMNR queries. If not, then it MUST NOT use the UNIQUE response to LLMNR queries. If not, then it MUST NOT use the UNIQUE
resource record in response to LLMNR queries. resource record in response to LLMNR queries.
The name conflict detection mechanism doesn't prevent name conflicts The name conflict detection mechanism doesn't prevent name conflicts
when previously partitioned segments are connected by a bridge. In order when previously partitioned segments are connected by a bridge. In order
to minimize the chance of conflicts in such a situation, it is to minimize the chance of conflicts in such a situation, it is
recommended that steps be taken to ensure name uniqueness. For example, recommended that steps be taken to ensure name uniqueness. For example,
skipping to change at page 20, line 44 skipping to change at page 20, line 28
5.1. Scope restriction 5.1. Scope restriction
With LLMNR it is possible that hosts will allocate conflicting names for With LLMNR it is possible that hosts will allocate conflicting names for
a period of time, or that attackers will attempt to deny service to a period of time, or that attackers will attempt to deny service to
other hosts by allocating the same name. Such attacks also allow hosts other hosts by allocating the same name. Such attacks also allow hosts
to receive packets destined for other hosts. to receive packets destined for other hosts.
Since LLMNR is typically deployed in situations where no trust model can Since LLMNR is typically deployed in situations where no trust model can
be assumed, it is likely that LLMNR queries and responses will be be assumed, it is likely that LLMNR queries and responses will be
unauthenticated. In the absence of authentication, LLMNR reduces the unauthenticated. In the absence of authentication, LLMNR reduces the
exposure to such threats by utilizing queries sent to a link-scope exposure to such threats by utilizing UDP queries sent to a link-scope
multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6) multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6)
fields to one (1) on both queries and responses. fields to one (1) on TCP queries and responses.
A TTL of one (1) was chosen so as to limit the likelihood that LLMNR can
be used to launch denial of service attacks. For example, were the TTL
of an LLMNR Response to be set to a value larger than one (1), an
attacker could send a large volume of queries from a spoofed source
address, causing an off-link target to be deluged with responses.
Utilizing a TTL of one (1) in LLMNR responses ensures that they will not Using a TTL of one (1) to set up a TCP connection in order to send a
be forwarded off-link. Using a TTL of one (1) to set up a TCP connection unicast LLMNR query reduces the likelihood of both denial of service
in order to send a unicast LLMNR query reduces the likelihood of both attacks and spoofed responses. Checking that an LLMNR query is sent to
denial of service attacks and spoofed responses. Checking that an LLMNR a link-scope multicast address should prevent spoofing of multicast
query is sent to a link-scope multicast address should prevent spoofing queries by off-link attackers.
of multicast queries by off-link attackers.
While this limits the ability of off-link attackers to spoof LLMNR While this limits the ability of off-link attackers to spoof LLMNR
queries and responses, it does not eliminate it. For example, it is queries and responses, it does not eliminate it. For example, it is
possible for an attacker to spoof a response to a frequent query (such possible for an attacker to spoof a response to a frequent query (such
as an A or AAAA query for a popular Internet host), and by using a TTL as an A or AAAA query for a popular Internet host), and by using a TTL
or Hop Limit field larger than one (1), for the forged response to reach or Hop Limit field larger than one (1), for the forged response to reach
the LLMNR sender. the LLMNR sender.
When LLMNR queries are sent to a link-scope multicast address, it is
possible that some routers may not properly implement link-scope
multicast, or that link-scope multicast addresses may leak into the
multicast routing system.
Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than one
in an LLMNR UDP response may enable denial of service attacks across the
Internet. However, since LLMNR responders only respond to queries for
which they are authoritative, and LLMNR does not provide wildcard query
support, it is believed that this threat is minimal.
There also are scenarios such as public "hotspots" where attackers can There also are scenarios such as public "hotspots" where attackers can
be present on the same link. These threats are most serious in wireless be present on the same link. These threats are most serious in wireless
networks such as 802.11, since attackers on a wired network will require networks such as 802.11, since attackers on a wired network will require
physical access to the home network, while wireless attackers may reside physical access to the home network, while wireless attackers may reside
outside the home. Link-layer security can be of assistance against outside the home. Link-layer security can be of assistance against
these threats if it is available. these threats if it is available.
5.2. Usage restriction 5.2. Usage restriction
As noted in Sections 2 and 3, LLMNR is intended for usage in a limited As noted in Sections 2 and 3, LLMNR is intended for usage in a limited
skipping to change at page 24, line 20 skipping to change at page 24, line 13
Number 5, pp. 589, October 2002. Number 5, pp. 589, October 2002.
[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local [DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
unicast addresses to communicate with recursive DNS servers", unicast addresses to communicate with recursive DNS servers",
Internet draft (work in progress), draft-ietf-ipv6-dns- Internet draft (work in progress), draft-ietf-ipv6-dns-
discovery-07.txt, October 2002. discovery-07.txt, October 2002.
[IPV4Link] [IPV4Link]
Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
of IPv4 Link-Local Addresses", Internet draft (work in of IPv4 Link-Local Addresses", Internet draft (work in
progress), draft-ietf-zeroconf-ipv4-linklocal-10.txt, October progress), draft-ietf-zeroconf-ipv4-linklocal-14.txt, April
2003. 2004.
[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- [POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology --
Portable Operating System Interface (POSIX). Open Group Portable Operating System Interface (POSIX). Open Group
Technical Standard: Base Specifications, Issue 6, December Technical Standard: Base Specifications, Issue 6, December
2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin
[LLMNREnable] [LLMNREnable]
Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
in progress), draft-guttman-mdns-enable-02.txt, April 2002. in progress), draft-guttman-mdns-enable-02.txt, April 2002.
skipping to change at page 26, line 37 skipping to change at page 26, line 37
Open Issues Open Issues
Open issues with this specification are tracked on the following web Open issues with this specification are tracked on the following web
site: site:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
Expiration Date Expiration Date
This memo is filed as <draft-ietf-dnsext-mdns-29.txt>, and expires This memo is filed as <draft-ietf-dnsext-mdns-30.txt>, and expires
August 4, 2004. October 4, 2004.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/