Subject: IESG comments on draft-ietf-ipngwg-icmp-name-lookups-09.txt

From: Thomas Narten <[email-masked]>
Date: Wed, 26 Jun 2002 14:38:02 -0400

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-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Thu, 27 Jun 2002 03:59:38 +0900

>even a basic sanity review. As one reviewer noted:

	I can't agree more.  The initial proposal was simple and robust
	(which was just a name lookup).  I personally think Qtypes other than
	"Node name" are unnecessary.

>make an inappropriate access control decisions.

	This part, I have a major objection.

	This view is completely opposite from concerns raised in
	draft-ietf-dnsop-inaddr-required-03.txt - DNS PTR records should
	not be used as sort-of authenticity, therefore, it is not recommended
	to be used as an access control mechanism.

	In my understanding, the threat imposed by malicious responses to
	ICMPv6 node information query (Qtype = node name) is equal to
	setting up DNS PTR records without forward zone administrators'
	knowing.  For instance, anyone can set up DNS PTR records that returns
	"www.ietf.org".  Similarly, anyone can respond with ICMPv6 node
	information reply with "www.ietf.org".

itojun

---

From: Thomas Narten <[email-masked]>
Date: Wed, 26 Jun 2002 15:09:03 -0400

Let me clarify...

> 	to be used as an access control mechanism.

The above suggests that the IESG comment was implying that doing
reverse lookups for some sort of security check is a good idea;
actually, the IESG view is the opposite. It believes it is generally a
bad idea.

However, it is also the case that people seem to do this. Thus, the
suggestion to put in  explicit text saying this is an even worse idea
than if one was just using the DNS record.

But the issue is more nuanced I think. I *thought* that what
implementations did was

a) do a lookup of address -> name
b) do a lookup of name -> address

If the later returns the first address, that is somehow a good enough
check. So, one can imagine doing ICMP name lookups for a), but still
do b) via the DNS. The issue here would be different than just doing
a) via lookups or doing both a) and b) via lookups.

> 	information reply with "www.ietf.org".

Yep.  This would all be appropriate to better explain in the security
considerations section.

Thomas

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Jun 2002 22:11:11 +0300 (EEST)

> 	information reply with "www.ietf.org".

That anyone setting DNS PTR records must be the administrator of an IP 
address block, and that IP address block must have been assigned to him.  
Seems like a big difference IMO.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Alain Durand <[email-masked]>
Date: Wed, 26 Jun 2002 12:21:52 -0700

> been learned through the ICMP name lookup mechanism.

I do not understand this comment.
Vendors have long learned how to integrate different name services:
DNS, NIS, NIS+, LDAP, Flat files....
ICMP NI would just be one more service to integrate.

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Jun 2002 22:25:46 +0300 (EEST)

> DNS, NIS, NIS+, LDAP, Flat files....

These services have some reasonable security models ..

> ICMP NI would just be one more service to integrate.

.. this has not.

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Jun 2002 16:04:45 -0400

> DNS, NIS, NIS+, LDAP, Flat files....

I think that should be 'vendors have long attempted to integrate
different name services'.  Unfortunately, they still haven't learned
NOT to do it - and this applies equally to NIS* and WINS.
Both cause fits for system administrators.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 26 Jun 2002 13:54:35 -0700

Thomas Narten wrote:
> ...

THere is no reason a node would respond to this query if its intent is
to remain anonymous. On top of that there are no 'security issues'
raised here, though there may be some authentication issues.

> Stating this threat in the security considerations is needed.

What threat? Is the concern that some implementer would be stupid enough
to reveal a private address? Stupidity can't be legislated against.

> that knob must default to the above separation.

Why should there be a policy knob for revealing a 3041 address to name
mapping? That is absolutely absurd. Either the node is allowed to use
the addresses 'privately' or the node is not allowed to use those
addresses at all. The policy knob belongs on the decision to use the
format, not on requiring disclosure if they are used. Personally I would
leave the querier hung in a timeout, but the politically correct thing
to do might be to pretend the node doesn't know its name and return a
null list with ttl=0.

> small space for private use.

Again there is no 'security' in the information returned, but there may
be some concern about authenticity.

The potential security issue that has been missed in this set of
responses is the ability to use this to seed a dos attack against the
complete set of addresses without tripping an IDS frequency counter. It
also doesn't make any sense to use a mechansim that is clearly getting
packets to the dst node to ask it for other addresses that might be used
to get packets to it. THe only possible use I can see would be to allow
shifting to a different pair for route selection reasons, but that
implies global usage which is itself a bad idea.

The best way to restrict the applicability of this protocol is to limit
it to link-scope or site-scope addresses. Since an answer from outside
the local administrative scope can't be trusted anyway, there is no
reason for the protocol to escape that scope. Once the connection
exceeds the bounds of a site, either there is no trust, or there is some
authentication infrastructure support. If there is authenticated
infrastructure, it makes more sense to use DNSsec than create something
new.

Tony

BTW: if the document maintains its Kitchen-Sink flavor, the IPv4 query
type should be removed and IPv4 addresses should be returned in
IPv4-mapped IPv6 format.

---

From: Randy Bush <[email-masked]>
Date: Wed, 26 Jun 2002 14:00:46 -0700

> DNS, NIS, NIS+, LDAP, Flat files....

and users are still having fun debugging the resulting behavior.
"was it a funny dns result, an error in the hosts file, yellow
plague, ...?  there goes 10-30 minutes <sigh>"

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 28 Jun 2002 16:18:57 +0900

>>>>> On Wed, 26 Jun 2002 22:11:11 +0300 (EEST), 
>>>>> Pekka Savola <[email-masked]> said:

> Seems like a big difference IMO.

It's true, but please concentrate on the main point of this discussion.

The point, IMO, is that even DNS PTR responses are not reliable enough
for access control purposes, as described in
draft-ietf-dnsop-inaddr-required-03.txt.  With this fact it does not
matter that DNS PTRs are much more reliable than node information
replies.  We can only use the responses/replies just as a hint anyway.
(DNSSEC may change the difference significantly, but it is not widely
deployed at least for now.)

In my understanding, the IESG comments do not oppose to using node
information replies as a replacement/alternative of (insecure) DNS
PTRs.  They just suggest better wording about the applicability and
implication.  I think the comment is reasonable.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Fri, 28 Jun 2002 10:31:34 +0300 (EEST)

On Fri, 28 Jun 2002, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote:
> draft-ietf-dnsop-inaddr-required-03.txt.  

The draft does not descibe that adequately.

The only places I see are in:

4:

   [...] The use
   of IN-ADDR, sometimes in conjunction with a lookup of the name
   resulting from the PTR record adds no real security, [...]

and

5:

   By recommending applications avoid using IN-ADDR as a security
   mechanism this document points out that this practice, despite its
   use by many applications, is an ineffective form of security. 
   Applications should use better mechanisms of authentication.  

I would not call this a "description", I call it FUD.

>With this fact it does not

I would agree that if a security mechanism checks only PTR, and _not_ the 
resulting address to match that PTR, the security level is roughly the 
same.

But no self-respecting implementation does that.

In any case, I regard PTR+name lookup as a (relatively strong) hint, not
an only form of authentication.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 28 Jun 2002 16:49:30 +0900

>>>>> On Fri, 28 Jun 2002 10:31:34 +0300 (EEST), 

> I would not call this a "description", I call it FUD.

So the point is whether it is reasonable to rely on PTRs (+name) for
access control, rather than about the usage of node information as a
replacement of PTRs (assuming that PTRs are insecure too).  If we can
agree to the sense of the "inaddr-required" draft, the usage of node
information will also be acceptable.  Otherwise, the usage of node
information will also be unacceptable.

In my understanding, draft-ietf-dnsop-inaddr-required-03.txt is based
on some consensus in the dnsop group, and it seems to me the IESG also
agrees on this according to a previous message from Thomas.  I
basically agree, too.  If you think it a FUD, please convince them
(including me) and make an opposite consensus.

					JINMEI, Tatuya

---

From: Pekka Savola <[email-masked]>
Date: Fri, 28 Jun 2002 10:59:39 +0300 (EEST)

> information will also be unacceptable.

The reality is not always black and white (hence the applicability 
statements..).
 
> (including me) and make an opposite consensus.

I do not disagree with the conclusions as much as I disagree with the way
they were reached; the draft does not discuss the actual insecurity at
all.  

I'll send specific comments to the draft to dnsop and you later;  unless I
hear otherwise, I'm not sure whether it's useful to include ipng in this
discussion.

---

From: Randy Bush <[email-masked]>
Date: Fri, 28 Jun 2002 07:43:06 -0700

> on some consensus in the dnsop group,

i fear the draft does not have wg consensus, at least not yet, and it
has been a while.

randy