Subject: LLMNR Issue 35: IP TTL

From: Bernard Aboba <[email-masked]>
Date: Wed, 23 Apr 2003 11:27:04 -0700 (PDT)

Issue 35: IP TTL
Submitter: Christian Huitema
Submitter email address: [email-masked]
Date first submitted: April 22, 2003
Reference:
Document: LLMNR-17
Comment type: T
Priority: S
Section: 2, 2.5
Rationale/Explanation of issue:

The current document is not explicit about use of TTL/Hop Limit
in all circumstances. Assuming that unicast queries and responses
to those queries are sent only over TCP with TTL=1, and that
multicast queries are also sent with TTL=1 so as to avoid possible
propagation beyond the local link, the only issue left is the
TTL setting for responses to multicast queries.

In Section 2, change:

"[3] Upon the reception of the response, the sender verifies that the
packet originated on-link (see Section 2.5 for details). If these
conditions are met, then the sender uses and caches the returned
response. If not, then the sender ignores the response and continues
waiting for the response."

To:

"[3] Upon the reception of the response, the sender performs the checks
described in Section 2.5. If these conditions are met, then the sender
uses and caches the returned response. If not, then the sender
ignores the response and continues waiting for the response."

In Section 2.5, change:

"The source address of LLMNR queries and responses MUST be "on link".
The destination address of an LLMNR query MUST be a link-scope multicast
address or an "on link" unicast address; the destination address of an
LLMNR response MUST be an "on link" unicast address. 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 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.

In composing an LLMNR response, the responder MUST set the Hop Limit
field in the IPv6 header and the TTL field in IPv4 header of the LLMNR
response to 255. The sender MUST verify that the Hop Limit field in
IPv6 header and TTL field in IPv4 header of each response to the LLMNR
query is set to 255. If it is not, then sender MUST ignore the
response.

Since routers decrement the Hop Limit on all packets they forward,
received packets containing a Hop Limit of 255 must have originated from
a neighbor.

Implementation note:

In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket
options are used to set the TTL of outgoing unicast and multicast
packets. The IP_RECVTTL socket option is available on some platforms
to retrieve the IPv4 TTL of received packets with recvmsg().
[RFC2292] specifies similar options for setting and retrieving the
IPv6 Hop Limit."

To:

"The source address of LLMNR queries and responses MUST be "on link".
The destination address of an LLMNR query MUST be a link-scope multicast
address or an "on link" unicast address; the destination address of an
LLMNR response MUST be an "on link" unicast address.
On receiving an LLMNR query, the responder MUST check whether it was
sent to the LLMNR multicast address; if it was sent to another multicast
address, then the query MUST be silently discarded.

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 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.

In composing a response to a unicast LLMNR query, the responder MUST
set the Hop Limit field in the IPv6 header and the TTL field in IPv4
header of the response to 1. Since unicast LLMNR queries and responses
to those queries MUST be sent using TCP, spoofing a response would
require hijacking a TCP connection on the local link.

In composing a multicast LLMNR query, the sender MUST set the
Hop Limit field in the IPv6 header and the TTL field in IPv4
header of the response to 1. Even though 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.
Therefore setting the IPv6 Hop Limit or IPv4 TTL field to one
provides an additional precaution against leakage of LLMNR traffic.

In composing a response to a multicast LLMNR query, the responder
MUST set the Hop Limit field in the IPv6 header and the TTL field in IPv4
header of the response to 1. This is done so as to prevent the use of
LLMNR for denial of service attacks across the Internet.

Implementation note:

In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket
options are used to set the TTL of outgoing unicast and multicast
packets. The IP_RECVTTL socket option is available on some platforms
to retrieve the IPv4 TTL of received packets with recvmsg().
[RFC2292] specifies similar options for setting and retrieving the
IPv6 Hop Limit."

--
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/>