The IESG has reviewed this document and has a number of concerns.
General concerns:
1) The applicability statement limits the scope to diagnostic and
debugging and states that the mechanism is for name lookups
independent of the the DNS. However, there are still places in the
document where the use of name lookups suggests that it might be OK to
mix DNS operations with ICMP name lookup operations (specific examples
given below).
The IESG believes that the name space as provided by the DNS should
not be mixed or "contaminated" with name resolutions performed using
the ICMP mechanism. Doing so raises complex security and trust issues
that have not been explored.
The document should make it clear that name lookups using the icmp
mechanism described in this document are never to be mixed with DNS
name lookups. That is, no queries made to the DNS (or implicitely
assumed to be going to the DNS) should get back responses that have
been learned through the ICMP name lookup mechanism.
Note: the IESG notes with concern that some recent comments on the
IPng mailing list indicate that there is some feeling that using the
icmp mechanism as a replacement for DNS operations is a desirable
direction to go in. We have significant concerns with this
view. Giving just one example, there is a model for securing DNS data
via DNSSEC; there is no apparent model for securing ICMP name lookups.
2) The document doesn't specify security issues around RFC 3041
temporary addresses and how they can be ameliorated. But queries for
names and addresses can be used to discover the relationship between
more permanent DNS names and IP addresses and the temporary addresses
(and names).
Stating this threat in the security considerations is needed.
Presumably the threat can be avoided by requiring that nodes separate
the temporary addresses from other addresses and names e.g. by
- having queries sent to a temporary destination address or
for a temporary subject address not return non-temporary addresses
or domain names
- having queries for non-temporary addresses or for domain names not
return temporary addresses.
While there might be a policy knob to override this, the setting of
that knob must default to the above separation.
3) This protocol is a bit loaded with options and features. It
supports a number of different queries, leaves a fair amount of
flexibility in how such information is obtained (e.g., proxies are
supported) and is rather easily extensible, including in proprietary
ways. The IANA Considerations Section indicates that anyone can obtain
code points to extend the protocol as they please without the need for
even a basic sanity review. As one reviewer noted:
As an example, the original idea -- that you ask a host for its
own name -- is a good one, and for lots of reasons it may be far
better than using PTR records. But this draft has mutated to
take on aspects of the Kitchen Sink Protocol
There does not appear to be a readily applicable security model for
how one can secure the protocol or the information it returns. This
would lead one to prefer a more narrowly scoped protocol that can't
easily be extended in inappropriate ways, especially for a Standards
Track protocol. It is strongly suggested that the document should
restrict extensions to the protocol to RFC-approved new queries and a
small space for private use.
================
More detailed comments from various reviewers:
Many application implementations do a reverse DNS lookup on an IP
address to learn the DNS Name of the connecting system. This name is
then used to make access control decisions. Some may believe that this
mechanism can be used to replace the reverse lookup. However this
introduces a new security vulnerability, which is to say that a bogus
host could connect to a service and when queried with this protocol it
would provide the DNS Name that the server is expecting and therefore
make an inappropriate access control decisions.
The Security Considerations section should have words in it to the
effect that the FQDN information (and other information) provided
cannot be trusted for making security relevant decisions unless some
other mechanism beyond the scope of this document is used to
authenticate that information.
================
The applicability statement is ok, but there appears to be
text that, counter to the applicability statement, talk about DNS resolvers
using this mechanism to answer DNS queries.
Section 5.3
If the Query was sent by a DNS server on behalf of a DNS
client, the result may be returned to that client as a DNS response
with TTL zero. However, if the server has the matching AAAA record,
either in cache or in an authoritative zone, then the TTL of that
record may be used as the missing TTL of the NI Node Name Reply and
the information in the reply may be cached and used for that period.
It would be an implementation choice for a server to perform a DNS
query for the AAAA or A6 records that match a received NI Node Name
Reply. This might be done to obtain a TTL to make the Reply
cacheable or in anticipation of such a DNS query from the client
that caused the Node Name Query.
This seems to take about some interaction between DNS and icmp name lookups
which is out of scope per the applicability statement.
Section 5.4:
If
the Query was sent by a DNS server on behalf of a DNS client, the
result may be returned to that client as a DNS response with TTL
zero.
Ditto.
Section 5.5
If
the Query was sent by a DNS server on behalf of a DNS client, the
result may be returned to that client as a DNS response with TTL
zero.
Ditto.
Also, the "serverless environments" in the abstract can lead folks
to believe the applicability is larger than stated.
---
Nits:
Section 3 talks about a "Reply Data" field but the field in the packet
is called "Data".
Section 4 talks about the MD5 hash to construct a multicast address
from a name. It would aid interoperability if that section contained
an example name and the resulting hash value and multicast address.
Section 4 talks about returning errors when the Qtype is unknown.
I think the intent is that those errors, just like other replies
be subject to random delay for responses to multicast packets.
But this isn't obvious from the text.
E.g. adding "subject to the random delay as specified below."
would be helpful.
================
A separate applicability section is appended at the end of the
document. Since the introduction also talks a bit about applicability,
it would be better to merge the two texts into one place near the
front.
Append the first 32 bits of that 128-bit hash to the prefix
FF02:0:0:0:0:2::/96. The resulting multicast address will be termed
the "NI Group Address" for the name.
Uses an awfully big range of multicast addresses, i.e., all of the
"unique" bits that are used to form the corresponding link-layer
multicast link-layer address in Ethernet. Is this reasonable? Note
that both ND and SLP do similar things, but use smaller independent
ranges, so there are no collision in the mapping for different
uses. Wouldn't it be be more conservative to carve out a smaller range
that doesn't immediately collide with other ranges?
If the Query was sent to an anycast or multicast address,
transmission of the Reply MUST be delayed by a random interval
between zero and MAX_ANYCAST_DELAY_TIME, as defined by IPv6 Neighbor
Discovery [2461].
I understand the delay for multicast, but why anycast? There should be
only one anycast response, so why delay?
> 5.1. NOOP
Not that great a name... It is really an echo, because the responder
must respond... Maybe call this "Liveness"? "Capability Query"?
> This NI type has no defined flags and never has a Data field. A
> Reply to a NI NOOP Query tells the Querier that a node with the
> Queried Address is up and reachable, implements the Node Information
> protocol, and incidentally happens to reveal whether the Queried
> Address was an anycast address. On transmission, the ICMPv6 Code in
> a NOOP Query must be set to 1 and the Code in a NOOP Reply must be
> 0. On reception of a NOOP Query or Reply, the Code must be ignored.
Anycast comment is a bit cryptic. Is the assumption that if source
address in response is not same as original dest, responses was
anycast? If so, would be good to just say so.
A 1-valued bit indicates support for the corresponding Qtype. The
lowest-order four bits in the first 32-bit word must be set to 1,
showing support for the four mandatory Qtypes defined in this
specification. Thus the Data field of a NI Supported Qtypes Reply
probably should say something about bit order and endianness here.
================
extremely vulnerable to many kinds of attacks, e.g. adress spoofing.
---
just when we have dnssec heading for the door, along comes nice
totally insecure reverse lookup.
---
5.1. NOOP
This NI type has no defined flags and never has a Data field. A
Reply to a NI NOOP Query tells the Querier that a node with the
Queried Address is up and reachable, implements the Node Information
protocol, and incidentally happens to reveal whether the Queried
Address was an anycast address.
the whole subject of whether an anycast address should be
differentiable is, or should be, undecided.
---
The compressed form of the Reply Data consists of a sequence of
blocks, each block consisting of two 16-bit unsigned integers, nWord
and nSkip, followed by nWord 32-bit bitmasks describing the
Responder's support for 32 consecutive Qtypes. nSkip is a count of
32-bit words following the included words which would have been
all-zero and have been suppressed. The last block MUST have nSkip =
0. As an example, a Responder supporting Qtypes 0, 1, 2, 3, 60, and
4097 could express that information with the following Reply Data
(nWord and nSkip fields are written in decimal for easier reading):
how clever, and i do not mean that as a compliment. just how many
qtypes does this intend?
---
a6 resource records, now deprecated, are supported.
---
there is nothing keeping these queries local or limiting them to
zeroconf environments.
================
5.3 How can a DNS TTL be returned? TTLs depend on the original
value and how long it's been since an authoritative server
sent out the information. Besides, how does a typical
kernel (the entity that usually processes ICMP messages)
know anything about DNS replies or dhcp lease time? I can
imagine a DHCP client installing the current lease expiration
every time it does a rebind or renew, but on what basis
should a host do DNS queries? I think the "use once" semantics
mentioned are far better.
The document speaks of A6. Should it?
5.4 It speaks of truncation for space reasons. How large can
the reply be?
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
