IPv6 Node Information Queries
RFC 4620

Note: This ballot was opened for revision 15 and is now closed.

(Steven Bellovin) Discuss

Discuss (2005-08-18)
Discuss comment transferred from old ballot:

 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?

(Randy Bush) Discuss

Discuss (2005-08-18)
Discuss comment transferred from old ballot:

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.

---

despite saying

        In the global internet, the Domain Name System [1034, 1035] 
	  is the authoritative source of such information and this
        specifcation is not intended to supplant or supersede it.

the folk in the wg admitted that this is part of the exceedingly
underspecified serverless architecture, i.e. meant to replace
dns.

i.e. dig this

	The Querier constructs an ICMP NI Query and sends it to the 
	address from which information is wanted. When the Subject of the 
	Query is an IPv6 address, that address will normally be used as 
	the IPv6 destination address of the Query, but need not be if the 
	Querier has useful a priori information about the addresses of 
	the target node. An NI Query may also be sent to a multicast 
	address of link-local scope [2373].

      When the Subject is a name, either fully-qualified or single-
      component, and the Querier does not have a unicast address for 
	the target node, the query MUST be sent to a link-scope multicast
      address formed in the following way. The Subject Name is 
	converted to the canonical form defined by DNS Security [2535], 
	which is uncompressed with all alphabetic characters in lower 
	case. (If additional DNS label types for host names are created, 
	the rules for canonicalizing those labels will be found in their 
	defining specification.) Compute the MD5 hash [1321] of the first 
	label of the Subject Name -- the portion beginning with the first 
	one-octet length field and up to, but excluding, any subsequent 
	length field. 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.

 so i suggest that this could be a dns end-run and hence needs
 review in dnsext. though this may not be the best time to get calm
 adult review in that wg.

 ---

 the icmp types
         Type 139 - NI Query.
                                 140 - NI Reply.
 are claimed to already be assigned for this protocol. i wonder how.

 ---

 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?

---

someone else already caught the TTL strangeness

---

a6 resource records, now deprecated, are supported.

---

this one is really cool

	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.

so does the server return ad-is-secure to a stub resolver in this
case? :-)

oh, and note that this paragraph and the one following make it
quite clear that this is meant to be part of the dns or a
replacement for part of it.

---

and also

	Because a node can only answer a Node Name Request when it is
      up and reachable, it may be useful to create a proxy responder
      for a group of nodes, for example a subnet or a site.

---

since it is replacing the dns, it is good that it handles ipv4
addresses as well.

---

there is nothing keeping these queries local or limiting them to
zeroconf environments.

-30-

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

(Erik Nordmark) Discuss

(Jeffrey Schiller) Discuss

(Scott Bradner) Yes

(Margaret Cullen) Yes

(Thomas Narten) Yes

(Harald Alvestrand) No Objection

(Brian Carpenter) No Objection

(Bill Fenner) No Objection

(Ned Freed) No Objection

(Patrik Fältström) No Objection

(Ted Hardie) No Objection

Comment (2006-03-01)
No email
send info
I think this is okay for Experimental, but i frankly can't see it ever making the transition to standards track without a very restrictive applicability statement .  The work makes quite a few assumptions about the environment of use that seem unlikely, and its security properties give me the chills.  In a debugging environment, I can see some usefulness, but even in a serverless environment I think the risk vs. reward is skewed.

(Sam Hartman) No Objection

(Russ Housley) No Objection

(David Kessens) (was Discuss) No Objection

(Allison Mankin) (was Discuss) No Objection

Comment (2006-03-01)
No email
send info
The response to my Discuss issues was full.  I'm also see the Security 
Considerations as having good knobs for controlling information exposure
and privacy (responding to the departed ADs' Discusses).  I cleared with
good will.

Bob Hinden's responses to my Discuss:

> My particular concern: there should be much less extensibility.
> I think it would be reasonable to have a small space for
> RFC approved new queries and a small space for private use,
> and that's all.

The current draft is less extensible and only allows new types by
IETF consensus.  From Section 7. IANA Considerations:

    This document defines five values of Qtype, numbers 0 through 4.
    Following the policies outlined in [16], new values, and their
    associated Flags and Reply Data, are to be defined by IETF
    Consensus.

> Also a question: what happens if you send a query for node
> address to the multicast address - what is the target?

In the case of multicast, the query is only processed if the
destination address was sent to a link-local scope multicast address
that the node had joined.  From Section 5 "Message Processing", fifth
paragraph:

    Upon receiving an NI Query, the Responder must check the 
    Query's IPv6
    destination address and discard the Query without further processing
    unless it is one of the Responder's unicast or anycast addresses, or
    a link-local scope multicast address which the Responder has joined.
    Typically the latter will be an NI Group Address for a name
    belonging
    to the Responder.  A node MAY be configured to discard NI Queries to
    multicast addresses other than its NI Group Address(es) but if so,
    the default configuration SHOULD be not to discard them.

Also, the last paragraph of the same section:

    If the Query was sent to a multicast address, transmission of the
    Reply MUST be delayed by a random interval between zero and [Query
    Response Interval], as defined by Multicast Listener Discovery
    Version 2 [10].

> Overall I support others views that a very simple version of
> this is of value (as it is used by KAME, e.g.).

This is what is used by KAME (except for the change of multicast
address assignments as describe in the questionnaire).

(Bert Wijnen) No Objection

(Alex Zinin) No Objection