Subject: LLMNR Issue 75 (AD Review): Miscellaneous

From: Bernard Aboba <[email-masked]>
Date: Thu, 2 Sep 2004 10:57:29 -0700 (PDT)

The list of LLMNR Issues and resolutions is available here:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html

The text of Issue 75 is enclosed below.  The proposed resolution is as
follows:

In Section 2.1, change:

"When in doubt a maximum packet size of 512 octets SHOULD be used.  LLMNR
implementations MUST accept UDP queries and responses as large as
permitted by the link MTU."

To:

"When in doubt a maximum packet size of 512 octets
SHOULD be used.  LLMNR implementations MUST accept UDP queries and
responses as large as 8192 octets."

In Section 2.1.1, change:

"The ID field in a query SHOULD be set to a pseudo-random value."

To:

"The ID field in a query SHOULD be set to a pseudo-random value.  For advice on generation
of pseudo-random values, please consult [RFC1750]."

Add to non-normative references:

[RFC 1750]  Eastlake, D., Crocker S. and J. Schiller,
"Randomness Recommendations for Security", RFC 1750, December 1994.

-----------------------------------------------------------------------
Issue 75: Miscellaneous
Submitter: Thomas Narten
Submitter email address: [email-masked]
Date first submitted: August 27, 2004
Reference:
Document: LLMNR-34
Comment type: T
Priority: S
Section:  Various
Rationale/Explanation of issue:

> packet size of 512 octets SHOULD be used. LLMNR implementations MUST
> accept UDP queries and responses as large as permitted by the link
> MTU.

Some links support ridiculous MTUs (e.g., 65K). Would it be useful to
place an upper bound on the max size to something big, but not
ridiculous? E.g., 5K? 10k?

> queries. The ID field in a query SHOULD be set to a pseudo-random
> value.

Does this need to be unpredictable for security? If so, say so, and
perhaps cite the relevant RFC.

> Since the responder may order the RRs in the response so as to
> indicate preference, the sender SHOULD preserve ordering in the
> response to the querying application.

this is a change from DNS.

> Routable addresses MUST be included first in the response, if
> available. This encourages use of routable address(es) for
> establishment of new connections.

hmm.

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