From: Mark Andrews Date: Wed, 21 May 2003 23:23:30 +0000 (+0000) Subject: new draft X-Git-Tag: v9.3.4^3~9 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=a3c5866412af704fb5324f9c90465805592d4f4e;p=thirdparty%2Fbind9.git new draft --- diff --git a/doc/draft/draft-ietf-dnsext-mdns-19.txt b/doc/draft/draft-ietf-dnsext-mdns-20.txt similarity index 89% rename from doc/draft/draft-ietf-dnsext-mdns-19.txt rename to doc/draft/draft-ietf-dnsext-mdns-20.txt index f87df7cde95..42cec61dace 100644 --- a/doc/draft/draft-ietf-dnsext-mdns-19.txt +++ b/doc/draft/draft-ietf-dnsext-mdns-20.txt @@ -7,8 +7,8 @@ DNSEXT Working Group Levon Esibov INTERNET-DRAFT Bernard Aboba Category: Standards Track Dave Thaler - Microsoft -12 May 2003 + Microsoft +21 May 2003 Linklocal Multicast Name Resolution (LLMNR) @@ -61,20 +61,20 @@ Esibov, Aboba & Thaler Standards Track [Page 1] -INTERNET-DRAFT LLMNR 12 May 2003 +INTERNET-DRAFT LLMNR 21 May 2003 Table of Contents 1. Introduction .......................................... 3 - 1.1 Requirements .................................... 4 + 1.1 Requirements .................................... 3 1.2 Terminology ..................................... 4 2. Name resolution using LLMNR ........................... 4 - 2.1 Sender behavior ................................. 5 + 2.1 Sender behavior ................................. 4 2.2 Responder behavior .............................. 5 2.3 Unicast queries ................................. 6 2.4 Addressing ...................................... 7 - 2.5 Off-link detection .............................. 8 + 2.5 Off-link detection .............................. 7 2.6 Retransmissions ................................. 8 2.7 DNS TTL ......................................... 9 3. Usage model ........................................... 9 @@ -86,7 +86,7 @@ Table of Contents 5. Security considerations ............................... 15 5.1 Scope restriction ............................... 15 5.2 Usage restriction ............................... 16 - 5.3 Cache and port separation ....................... 17 + 5.3 Cache and port separation ....................... 16 5.4 Authentication .................................. 17 6. IANA considerations ................................... 17 7. Normative References .................................. 17 @@ -121,7 +121,7 @@ Esibov, Aboba & Thaler Standards Track [Page 2] -INTERNET-DRAFT LLMNR 12 May 2003 +INTERNET-DRAFT LLMNR 21 May 2003 1. Introduction @@ -147,19 +147,10 @@ described in Section 2.3. Propagation of LLMNR packets on the local link is considered sufficient to enable name resolution in small networks. The assumption is that if -a network has a home gateway, then the network either has DNS and DHCPv4 -servers or the home gateway provides DHCPv4 and DNS server -functionality. By providing Dynamic Host Configuration Service for -IPv4 (DHCPv4), as well as a DNS server with support for dynamic DNS, -which is also authoritative for the A RRs of local hosts, it is possible -to support resolution of local host names over IPv4. - -For small IPv6 networks, equivalent functionality can be provided by -implementing Dynamic Host Configuration Service for IPv6 (DHCPv6) for -DNS configuration [DHCPv6DNS], as well providing a DNS server with -support for dynamic DNS, which is also authoritative for the AAAA RRs of -local hosts, it is possible to support the resolution of local host -names over IPv6 as well as IPv4. +a network has a home gateway, then the network is able to provide DNS +server configuration and a DNS server is available that is authoritative +for the names of local hosts and can support dynamic DNS. Configuration +issues are discussed in Section 3.2. In the future, LLMNR may be defined to support greater than link-scope multicast. This would occur if LLMNR deployment is successful, the @@ -172,27 +163,27 @@ issues, usability and impact on the network it will be possible to reevaluate which multicast scopes are appropriate for use with multicast name resolution mechanisms. +Service discovery in general, as well as discovery of DNS servers using +LLMNR in particular, is outside of the scope of this document, as is +name resolution over non-multicast capable media. +1.1. Requirements +In this document, several words are used to signify the requirements of +the specification. These words are often capitalized. The key words +"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD -Esibov, Aboba & Thaler Standards Track [Page 3] +Esibov, Aboba & Thaler Standards Track [Page 3] -INTERNET-DRAFT LLMNR 12 May 2003 -Service discovery in general, as well as discovery of DNS servers using -LLMNR in particular, is outside of the scope of this document, as is -name resolution over non-multicast capable media. +INTERNET-DRAFT LLMNR 21 May 2003 -1.1. Requirements -In this document, several words are used to signify the requirements of -the specification. These words are often capitalized. The key words -"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. @@ -230,30 +221,28 @@ A typical sequence of events for LLMNR usage is as follows: Further details of sender and responder behavior are provided in the sections that follow. +2.1. Sender behavior +A sender sends an LLMNR query for any legal resource record type (e.g. +A/AAAA, SRV, PTR, etc.) to the link-scope multicast address. As +described in Section 2.3, a sender may also send a unicast query. An +LLMNR sender MAY send a request for any name. +The RD (Recursion Desired) bit MUST NOT be set in a query. If a +responder receives a query with the header containing RD set bit, the +responder MUST ignore the RD bit. -Esibov, Aboba & Thaler Standards Track [Page 4] - - +Esibov, Aboba & Thaler Standards Track [Page 4] -INTERNET-DRAFT LLMNR 12 May 2003 -2.1. Sender behavior -A sender sends an LLMNR query for any legal resource record type (e.g. -A/AAAA, SRV, PTR, etc.) to the link-scope multicast address. As -described in Section 2.3, a sender may also send a unicast query. An -LLMNR sender MAY send a request for any name. +INTERNET-DRAFT LLMNR 21 May 2003 -The RD (Recursion Desired) bit MUST NOT be set in a query. If a -responder receives a query with the header containing RD set bit, the -responder MUST ignore the RD bit. The sender MUST anticipate receiving no replies to some LLMNR queries, in the event that no responders are available within the link-scope or @@ -272,10 +261,9 @@ the LLMNR query. A host configured as a responder MUST act as a sender to verify the uniqueness of names as described in Section 4. Responders MUST NOT respond to LLMNR queries for names they are not -authoritative for, except in the event of a discovered conflict, as -described in Section 4. Responders SHOULD respond to LLMNR queries for -names and addresses they are authoritative for. This applies to both -forward and reverse lookups. +authoritative for. Responders SHOULD respond to LLMNR queries for names +and addresses they are authoritative for. This applies to both forward +and reverse lookups. As an example, a computer "host.example.com." configured to respond to LLMNR queries is authoritative for the name "host.example.com.". On @@ -292,18 +280,6 @@ and an empty answer section. If a DNS server is running on a host that supports LLMNR, the DNS server MUST respond to LLMNR queries only for the RRSets owned by the host on - - - -Esibov, Aboba & Thaler Standards Track [Page 5] - - - - - -INTERNET-DRAFT LLMNR 12 May 2003 - - which the server is running, but MUST NOT respond for other records for which the server is authoritative. @@ -316,6 +292,18 @@ root. For example the host "host.example.com." is not authoritative for the name "child.host.example.com." unless the host is configured with multiple names, including "host.example.com." and + + + +Esibov, Aboba & Thaler Standards Track [Page 5] + + + + + +INTERNET-DRAFT LLMNR 21 May 2003 + + "child.host.example.com.". As a result, "host" cannot reply to a query for "child" with NXDOMAIN. The purpose of limiting the name authority scope of a responder is to prevent complications that could be caused by @@ -352,29 +340,29 @@ Unicast queries SHOULD be sent when: with the TC bit set to the previous LLMNR multicast query, or b. The sender's LLMNR cache contains an NS resource record that + enables the sender to send a query directly to the hosts + authoritative for the name in the query, or + c. The sender queries for a PTR RR. +If a TC (truncation) bit is set in the response, then the sender MAY use +the response if it contains all necessary information, or the sender MAY +discard the response and resend the query over TCP using the unicast +address of the responder. The RA (Recursion Available) bit in the +header of the response MUST NOT be set. If the RA bit is set in the +response header, the sender MUST ignore the RA bit. -Esibov, Aboba & Thaler Standards Track [Page 6] +Esibov, Aboba & Thaler Standards Track [Page 6] -INTERNET-DRAFT LLMNR 12 May 2003 - enables the sender to send a query directly to the hosts - authoritative for the name in the query, or - c. The sender queries for a PTR RR. +INTERNET-DRAFT LLMNR 21 May 2003 -If a TC (truncation) bit is set in the response, then the sender MAY use -the response if it contains all necessary information, or the sender MAY -discard the response and resend the query over TCP using the unicast -address of the responder. The RA (Recursion Available) bit in the -header of the response MUST NOT be set. If the RA bit is set in the -response header, the sender MUST ignore the RA bit. Unicast LLMNR queries SHOULD be sent using TCP. Responses to TCP unicast LLMNR queries MUST be sent using TCP, using the same connection @@ -383,9 +371,9 @@ using TCP, the response MUST be silently discarded. Unicast UDP queries MAY be responded to with an empty answer section and the TC bit set, so as to require the sender to resend the query using TCP. Senders MUST support sending TCP queries, and Responders MUST support listening for -TCP queries. The Responder SHOULD set the TTL or Hop Limit settings on +TCP queries. 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 +(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. @@ -394,10 +382,10 @@ UDP query, or if TCP connection setup cannot be completed in order to send a unicast TCP query, this is treated as a response that no records of the specified type and class exist for the specified name (it is treated the same as a response with RCODE=0 and an empty answer -section). The UDP sender receiving an ICMP "Time Exceeded" message +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 +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.6. @@ -410,20 +398,6 @@ sends queries, is 224.0.0.251. The IPv6 link-scope multicast address a given responder listens to, and to which a sender sends all queries, is TBD. - - - - - -Esibov, Aboba & Thaler Standards Track [Page 7] - - - - - -INTERNET-DRAFT LLMNR 12 May 2003 - - 2.5. Off-link detection The source address of LLMNR queries and responses MUST be "on link". @@ -438,6 +412,18 @@ For IPv4, an "on link" address is defined as a link-local address 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 address, defined in [RFC2373], or an address whose prefix belongs to a subnet on the + + + +Esibov, Aboba & Thaler Standards Track [Page 7] + + + + + +INTERNET-DRAFT LLMNR 21 May 2003 + + local link. A sender SHOULD prefer RRs including reachable addresses where RRs involving both reachable and unreachable addresses are returned in response to a query. @@ -472,18 +458,6 @@ delayed by a time uniformly distributed between 0 and 200 ms. If an LLMNR query sent over UDP is not resolved within the timeout interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of - - - -Esibov, Aboba & Thaler Standards Track [Page 8] - - - - - -INTERNET-DRAFT LLMNR 12 May 2003 - - the query in order to assure that it was received by a host capable of responding to it. Since a multicast query sender cannot know beforehand whether it will receive no response, one response, or more than one @@ -495,10 +469,22 @@ waits for LLMNR_TIMEOUT if no response has been received. LLMNR implementations SHOULD dynamically estimate the timeout value (LLMNR_TIMEOUT) based on the last response received, on a per-interface -basis, using the algorithms described in [RFC2988], with a minimum -timeout value of 300 ms. Retransmission of UDP queries SHOULD NOT be -attempted more than 3 times. Where LLMNR queries are sent using TCP, -retransmission is handled by the transport layer. +basis. The algorithms described in [RFC2988] are suggested, with a +minimum timeout value of 300 ms. Retransmission of UDP queries SHOULD +NOT be attempted more than 3 times. Where LLMNR queries are sent using + + + +Esibov, Aboba & Thaler Standards Track [Page 8] + + + + + +INTERNET-DRAFT LLMNR 21 May 2003 + + +TCP, retransmission is handled by the transport layer. 2.7. DNS TTL @@ -532,18 +518,6 @@ additional restrictions: [2] Where a DNS server is configured, by default a sender SHOULD send LLMNR queries only for names that are either unqualified or exist within the default domain. Where no - - - -Esibov, Aboba & Thaler Standards Track [Page 9] - - - - - -INTERNET-DRAFT LLMNR 12 May 2003 - - DNS server is configured, an LLMNR query MAY be sent for any name. @@ -558,6 +532,18 @@ INTERNET-DRAFT LLMNR 12 May 2003 RRs returned in LLMNR responses MUST only include values that are valid on the local interface, such as IPv4 or IPv6 addresses valid on the local link or names defended using the mechanism described in Section 4. + + + +Esibov, Aboba & Thaler Standards Track [Page 9] + + + + + +INTERNET-DRAFT LLMNR 21 May 2003 + + In particular: [1] If a link-scope IPv6 address is returned in a AAAA RR, that @@ -588,9 +574,23 @@ to resolve unqualified host names. 3.2. LLMNR configuration LLMNR usage MAY be configured manually or automatically on a per -interface basis. By default, LLMNR responders SHOULD be enabled on all +interface basis. By default, LLMNR Responders SHOULD be enabled on all interfaces, at all times. +Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is +possible for a dual stack host to be configured with the address of a +DNS server over IPv4, while remaining unconfigured with a DNS server +suitable for use over IPv6. + +In these situations, a dual stack host will send AAAA queries to the +configured DNS server over IPv4. However, an IPv6-only host +unconfigured with a DNS server suitable for use over IPv6 will be unable +to resolve names using DNS. Automatic IPv6 DNS configuration mechanisms +(such as [DHCPv6DNS] and [DNSDisc]) are not yet widely deployed, and not +all DNS servers support IPv6. Therefore lack of IPv6 DNS configuration +may be a common problem in the short term, and LLMNR may prove useful in +enabling linklocal name resolution over IPv6. + @@ -601,35 +601,30 @@ Esibov, Aboba & Thaler Standards Track [Page 10] -INTERNET-DRAFT LLMNR 12 May 2003 +INTERNET-DRAFT LLMNR 21 May 2003 -Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is -possible for a dual stack host to be configured with the address of a -DNS server over IPv4, while remaining unconfigured with a DNS server -suitable for use over IPv6. In these situations, a dual stack host will -send AAAA queries to the configured DNS server over IPv4. - -However, an IPv6-only host unconfigured with a DNS server suitable for -use over IPv6 will be unable to resolve names using DNS. Since -automatic IPv6 DNS configuration mechanisms (such as [DHCPv6DNS] and -[DNSDisc]) are not yet widely deployed, and not all DNS servers support -IPv6, lack of IPv6 DNS configuration may be a common problem in the -short term, and LLMNR may prove useful in enabling linklocal name -resolution over IPv6. - -For example, a home network may provide a DHCPv4 server but may not -support DHCPv6 for DNS configuration [DHCPv6DNS]. In such a -circumstance, IPv6-only hosts will not be configured with a DNS server. -Where a DNS server is configured but does not support dynamic client -update over IPv6 or DHCPv6-based dynamic update, hosts on the home -network will not be able to dynamically register or resolve the names of -local IPv6 hosts. If the configured DNS server responds to AAAA RR +Where a DHCPv4 server is available but not a DHCPv6 server [DHCPv6DNS], +IPv6-only hosts may not be configured with a DNS server. Where there is +no DNS server authoritative for the names of hosts on the local network +or the authoritative DNS server does not support dynamic client update +over IPv6 or DHCPv6-based dynamic update, hosts on the home network will +not be able to dynamically register or resolve the names of local IPv6 +hosts. For example, if the configured DNS server responds to AAAA RR queries sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), then it will not be possible to resolve the names of IPv6-only hosts. In this situation, LLMNR over IPv6 can be used for local name resolution. +Similarly, if a DHCPv4 server is available providing DNS server +configuration, and the DNS server authoritative for the A RRs of local +hosts also supports either dynamic client update over IPv4 or +DHCPv4-based dynamic update, then resolution of the names of local IPv4 +hosts can be provided over IPv4 without LLMNR. However, if there is no +DNS server authoritative for the names of local hosts, or the +authoritative DNS server does not support dynamic update, then LLMNR may +prove useful in enabling linklocal name resoltion over IPv4. + Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to configure LLMNR on an interface. The LLMNR Enable Option, described in [LLMNREnable], can be used to explicitly enable or disable use of LLMNR @@ -638,19 +633,24 @@ in which order DNS itself is used for name resolution. The order in which various name resolution mechanisms should be used can be specified using the Name Service Search Option for DHCP [RFC2937]. -3.2.1. Configuration consistency - It is possible that DNS configuration mechanisms will go in and out of service. In these circumstances, it is possible for hosts within an administrative domain to be inconsistent in their DNS configuration. For example, where DHCP is used for configuring DNS servers, one or more -DHCP servers can go down. As a result, hosts configured prior to the +DHCP servers can fail. As a result, hosts configured prior to the outage will be configured with a DNS server, while hosts configured after the outage will not. Alternatively, it is possible for the DNS configuration mechanism to continue functioning while configured DNS servers fail. +Unless unconfigured hosts periodically retry configuration, an outage in +the DNS configuration mechanism will result in hosts continuing to use +LLMNR even once the outage is repaired. Since LLMNR only enables +linklocal name resolution, this represents an unnecessary degradation in +capabilities. As a result, it is recommended that hosts without a +configured DNS server periodically attempt to obtain DNS configuration. +A default retry interval of two (2) minutes is RECOMMENDED. @@ -661,16 +661,8 @@ Esibov, Aboba & Thaler Standards Track [Page 11] -INTERNET-DRAFT LLMNR 12 May 2003 - +INTERNET-DRAFT LLMNR 21 May 2003 -Unless unconfigured hosts periodically retry configuration, an outage in -the DNS configuration mechanism will result in hosts continuing to -prefer LLMNR even once the outage is repaired. Since LLMNR only enables -linklocal name resolution, this represents an unnecessary degradation in -capabilities. As a result, it is recommended that hosts without a -configured DNS server periodically attempt to obtain DNS configuration. -A default retry interval of two (2) minutes is RECOMMENDED. 4. Conflict resolution @@ -713,40 +705,37 @@ resource record. By default, a host SHOULD be configured to behave as though all RRs are UNIQUE. Uniqueness verification is carried out when the host: + - starts up or + - is configured to respond to the LLMNR queries on an interface or + - is configured to respond to the LLMNR queries using additional + UNIQUE resource records. +When a host that owns a UNIQUE record receives an LLMNR query for that +record, the host MUST respond. After the client receives a response, it -Esibov, Aboba & Thaler Standards Track [Page 12] +Esibov, Aboba & Thaler Standards Track [Page 12] -INTERNET-DRAFT LLMNR 12 May 2003 - - starts up or - - is configured to respond to the LLMNR queries on an interface or - - is configured to respond to the LLMNR queries using additional - UNIQUE resource records. +INTERNET-DRAFT LLMNR 21 May 2003 + -When a host that owns a UNIQUE record receives an LLMNR query for that -record, the host MUST respond. After the client receives a response, it MUST check whether the response arrived on another interface. If this is the case, then the client can use the UNIQUE resource record in response to LLMNR queries. If not, then it MUST NOT use the UNIQUE resource record in response to LLMNR queries. The name conflict detection mechanism doesn't prevent name conflicts -when previously partitioned segments are connected by a bridge. In such -a situation, name conflicts are detected when a sender receives more -than one response to its LLMNR multicast query. In this case, the -sender sends the first response that it received to all responders that -responded to this query except the first one, using UDP unicast. A host -that receives a query response containing a UNIQUE resource record that -it owns, even if it didn't send such a query, MUST verify that no other -host within the LLMNR scope is authoritative for the same name, using -the mechanism described above. Based on the result, the host detects -whether there is a name conflict and acts accordingly. +when previously partitioned segments are connected by a bridge. In order +to minimize the chance of conflicts in such a situation, it is +recommended that steps be taken to ensure hostname uniqueness. For +example, the hostname could be chosen randomly from a large pool of +potential names, or the hostname could be assigned via a process +designed to guarantee uniqueness. 4.1. Considerations for Multiple Interfaces @@ -773,22 +762,27 @@ to respond with a host RR for "myhost" on the interface on the right (see Figure 1). The multi-homed host may, however, be configured to use the "myhost" name on the interface on the left. +Since names are only unique per-link, hosts on different links could be +using the same name. If an LLMNR client sends requests over multiple +interfaces, and receives replies from more than one, the result returned +to the client is defined by the implementation. The situation is +illustrated in figure 2. -Esibov, Aboba & Thaler Standards Track [Page 13] -INTERNET-DRAFT LLMNR 12 May 2003 +Esibov, Aboba & Thaler Standards Track [Page 13] + + + + + +INTERNET-DRAFT LLMNR 21 May 2003 -Since names are only unique per-link, hosts on different links could be -using the same name. If an LLMNR client sends requests over multiple -interfaces, and receives replies from more than one, the result returned -to the client is defined by the implementation. The situation is -illustrated in figure 2. ---------- ---------- | | | | @@ -802,11 +796,6 @@ send LLMNR queries on both interfaces. When host myhost sends a query for the host RR for name "A" it will receive a response from hosts on both interfaces. -Host myhost will then send the first responder's response to the second -responder, who will attempt to verify the uniqueness of host RR for its -name, but will not discover a conflict, since the conflicting host -resides on a different link. Therefore it will continue using its name. - Host myhost cannot distinguish between the situation shown in Figure 2, and that shown in Figure 3 where no conflict exists. @@ -833,17 +822,6 @@ structure exposes the scope within which each scoped address exists, and this structure can be used for both IPv4 (using v4-mapped IPv6 addresses) and IPv6 addresses. - - -Esibov, Aboba & Thaler Standards Track [Page 14] - - - - - -INTERNET-DRAFT LLMNR 12 May 2003 - - Following the example in Figure 2, an application on 'myhost' issues the request getaddrinfo("A", ...) with ai_family=AF_INET6 and ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both @@ -854,6 +832,18 @@ both hosts responding to the name 'A'. Link-local addresses will have a sin6_scope_id value that disambiguates which interface is used to reach the address. Of course, to the application, Figures 2 and 3 are still indistinguishable, but this API allows the application to communicate + + + +Esibov, Aboba & Thaler Standards Track [Page 14] + + + + + +INTERNET-DRAFT LLMNR 21 May 2003 + + successfully with any address in the list. 5. Security Considerations @@ -891,7 +881,17 @@ exposure to such threats by utilizing queries sent to a link-scope multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6) fields to one (1) on both queries and responses. +While this limits the ability of off-link attackers to spoof LLMNR +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 +as an A/AAAA query for a popular Internet host), and using a TTL or Hop +Limit field larger than one (1), for the forged response to reach the +LLMNR sender. There also are scenarios such as public "hotspots" where +attackers can 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 physical access to the +home network, while wireless attackers may reside outside the home. @@ -901,20 +901,9 @@ Esibov, Aboba & Thaler Standards Track [Page 15] -INTERNET-DRAFT LLMNR 12 May 2003 +INTERNET-DRAFT LLMNR 21 May 2003 -While this limits the ability of off-link attackers to spoof LLMNR -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 -as an A/AAAA query for a popular Internet host), and using a TTL or Hop -Limit field larger than one (1), for the forged response to reach the -LLMNR sender. There also are scenarios such as public "hotspots" where -attackers can 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 physical access to the -home network, while wireless attackers may reside outside the home. Link-layer security can be of assistance against these threats if it is available. @@ -952,18 +941,6 @@ cache, once poisoned, would take precedence over the DNS cache, eliminating the benefits of cache separation. As a result, LLMNR is best thought of as a name resolution mechanism of last resort. - - - -Esibov, Aboba & Thaler Standards Track [Page 16] - - - - - -INTERNET-DRAFT LLMNR 12 May 2003 - - 5.3. Cache and port separation In order to prevent responses to LLMNR queries from polluting the DNS @@ -976,6 +953,17 @@ decreases reliance on it. LLMNR operates on a separate port from DNS, reducing the likelihood that a DNS server will unintentionally respond to an LLMNR query. + + +Esibov, Aboba & Thaler Standards Track [Page 16] + + + + + +INTERNET-DRAFT LLMNR 21 May 2003 + + 5.4. Authentication LLMNR does not require use of DNSSEC, and as a result, responses to @@ -1012,29 +1000,29 @@ allocation of a link-scope multicast IPv6 address. [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. +[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. +[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. +[RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. -Esibov, Aboba & Thaler Standards Track [Page 17] +[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission + Timer", RFC 2988, November 2000. +Esibov, Aboba & Thaler Standards Track [Page 17] -INTERNET-DRAFT LLMNR 12 May 2003 -[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 2373, July 1998. -[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 - (IPv6) Specification", RFC 2460, December 1998. -[RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. +INTERNET-DRAFT LLMNR 21 May 2003 -[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission - Timer", RFC 2988, November 2000. 8. Informative References @@ -1073,24 +1061,28 @@ INTERNET-DRAFT LLMNR 12 May 2003 draft (work in progress), draft-ietf-zeroconf- ipv4-linklocal-07.txt, August 2002. +[LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", Internet draft + (work in progress), draft-guttman-mdns-enable-02.txt, + April 2002. +[NodeInfo] Crawford, M., "IPv6 Node Information Queries", Internet + draft (work in progress), draft-ietf-ipn-gwg-icmp-name- + lookups-09.txt, May 2002. -Esibov, Aboba & Thaler Standards Track [Page 18] -INTERNET-DRAFT LLMNR 12 May 2003 +Esibov, Aboba & Thaler Standards Track [Page 18] -[LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", Internet draft - (work in progress), draft-guttman-mdns-enable-02.txt, - April 2002. -[NodeInfo] Crawford, M., "IPv6 Node Information Queries", Internet - draft (work in progress), draft-ietf-ipn-gwg-icmp-name- - lookups-09.txt, May 2002. + + + +INTERNET-DRAFT LLMNR 21 May 2003 + Acknowledgments @@ -1135,13 +1127,21 @@ EMail: dthaler@microsoft.com + + + + + + + + Esibov, Aboba & Thaler Standards Track [Page 19] -INTERNET-DRAFT LLMNR 12 May 2003 +INTERNET-DRAFT LLMNR 21 May 2003 Intellectual Property Statement @@ -1201,7 +1201,7 @@ Esibov, Aboba & Thaler Standards Track [Page 20] -INTERNET-DRAFT LLMNR 12 May 2003 +INTERNET-DRAFT LLMNR 21 May 2003 Open Issues @@ -1213,7 +1213,7 @@ http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html Expiration Date -This memo is filed as , and expires +This memo is filed as , and expires November 22, 2003.