Subject: [secdir] draft-cheshire-dnsext-multicastdns-08.txt

From: Donald Eastlake <[email-masked]>
Date: Sun, 13 Dec 2009 22:55:19 -0500

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  Document
editors and WG chairs should treat these comments just like any other last
call comments.

This informational draft specifies a multicast link-local variant of DNS
which varies in a number of ways from the IETF DNS standard. Much of it is
written in a style to persuade the reader of the merits of the protocol
specified or head off potential complaints about it.

SECURITY COMMENTS:

The Security Considerations section seems reasonable for an informational
document describing an existing link local usage. The following other
sections have security implications which could be briefly mentioned or
referenced in the Security Considerations section.

Section 4 mentions dependence of earlier versions on IP TTL 255 to detect
link local.

Section 14 gives various details related to failing over to multicast DNS
from classic DNS and having the TLD ".local" in ones search list.

Section 21.2 (Arguments for using a different port (UDP port 5353):) point
out that use of 5353 is more convenient for unprivileged clients providing
mDNS on systems where they could not access a low numbered port like 53. But
this seems to imply some sort of security risk of making it easier for a
random unauthorized client doing this.

OTHER COMMENTS:

Section 3.1/3.2. I don't want to comment on the politics of this but it
strikes me as a bad idea to dilute the claim on .local. by giving a bunch of
alternatives. Just stick to .local. I support its use for, well, "local"
names. :-)  And numeric TLDs are a really bad idea, conflicting in commonly
accepted syntax with IP addresses.

Section 3.3 (Maximum Multicast DNS Name Length). As far as I know, and I've
checked with experts, the answer is that the wire encoded limit is 255 bytes
including the final zero value terminating byte that is the length of the
root label. That's clearly what RFC 1034 says. "all label octets and label
lengths" means *ALL*, including the label length for the root label. In this
regard, RFC 2181 is simply confusing/confused. RFC 2181 appears to be
talking about text representations of DNS names, not wire encoding. It talks
about "separators", which are the periods between labels, which have nothing
to do with the DNS length limit which is defined with reference to the wire
encoding. So, "example.com" has 10 bytes of text labels plus 1 byte of text
separator, for a text length of 11. But its wire encoding has length 13, one
for the length of "example", seven for "example", one for the length of
"com", three for "com", and one for the length of the root label (which is
the empty label). So, when RFC 2181 talk about "the zero length name" it is
talking about the number of text bytes in the root label, which is zero, not
the wire encoding length, which is one.

Section 20.14 (Name Compression) is questionable. It gives advice that
implementors should do name decompression in all the rdata for RRs that the
implementor knows about. I guess this is not a problem but, due to the
difficulty in updating every old implementation in the world when a new RR
type comes along that has potentially compressable names in rdata, it just
seems impractical to believe that interoperable name compression can be
provided in the rdata of future RRs. Having an explicit list of RRs where
such compression is done, as is also provided by Section 20.14, is fine and
I think it is OK for this to differ from that for classic unicast DNS.
Other/future RRs should just be handled as in RFC 3597.

Section 8 (Responding), 3rd paragraph, last line. "must not" -> "MUST NOT".

Section 9.2 (Simultaneous Probe Tie-Breaking). I was initially puzzled by
all the stuff about initially comparing the class of answers. When you do a
query, you only get answers for the class you queried. True, there is a
qclass "*" (0x00FF) for any class, but why would you be using that?
Different classes are meant to be completely disjoint spaces. Names are
explicitly local to a class in DNS. However, I concluded you were just
trying to compare the top bit of the rrclass field which this spec
re-defines... Maybe this should be clarified.

Section 20.3 (OPCODE), the parenthetical "(only standard queries are
currently supported over multicast, unless other queries are allowed by some
future extension to the Multicast DNS specification)" is internally
inconsistent. The allowing of something in the future has no effect on the
current state. Suggest just saying "(only standard queries are currently
supported over multicast)".

Section 22 (Summary of Differences Between Multicast DNS and Unicast DNS),
I'm not convinced that all the listed items are actually differences. For
example, defining a clear maximum legal fully qualified domain name size on
the wire is the same but gratuitously different. Its  255 bytes for classic
DNS and you have changed this for mDNS to 256 bytes. Is one byte really
worth the inconsistency?

Section 24.1 (IPv6 Multicast Addresses by Hashing), does this actually not
apply to IPv4? If it does apply to IPv4, some minor rewording of this
section would be called for.

TRIVIA

Section 8 (Responding). "immediately without delay" seems a tad redundant.
Three occurrences, one with a comma. Suggest using one or the other.

Section 17 (Multicast DNS and Power Management), this seems sufficiently
beside the main point of the draft that it could be made an Appendix.

Second paragraph of Section 25, "administered" -> "configured". Administered
could mean anything but configured sounds like you've actually set values.

Thanks,
Donald
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
[email-masked]