Subject: IPv6 w.g. Last Call on "IPv6 Node Information Queries"

From: Bob Hinden & Margaret Wasserman <[email-masked]>
Date: Wed, 02 Jul 2003 15:45:50 -0700

This is a IPv6 working group last call for comments on advancing the 
following document as a Proposed Standard:

	Title		: IPv6 Node Information Queries
	Author(s)	: M. Crawford
	Filename	: draft-ietf-ipngwg-icmp-name-lookups-10.txt
	Pages		: 12
	Date		: 2003-6-27

This document was previously sent to the IESG for Proposed Standard.  The 
IESG responded with a number of comments.  The IESG discussion can be found 
at:

  https://www.ietf.org/IESG/EVALUATIONS/draft-ietf-ipngwg-icmp-name-lookups.bal

The chairs believe that this draft resolves the issues raised by the 
IESG.  Given the time that has elapsed, we thought it was important to have 
another working group last call.  Changes in this draft include:

  - Move applicability statement to start of document and update
    introduction.
  - Removed Qtypes query capabilities
  - Limit returned TTL in node name to zero and removed text describing
    non-zero TTLs.
  - Remove text about A6 records
  - Change to have all new Qtypes require IETF approval
  - Updated security considerations

The reasoning behind this set of changes was to resolve the issues raised 
by the IESG and to maintain comparability with current shipping code.  Node 
Information Queries is shipping in the KAME and USAGI distributions and has 
been found to be very useful for deploying IPv6 service and debugging 
operational problems.

Please send substantive comments to the ipng mailing list, and minor 
editorial comments to the authors.  This last call period will end on 16 
July 2003.

Bob Hinden / Margaret Wasserman

--------------------------------------------------------------------
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: Michael Hunter <[email-masked]>
Date: Tue, 8 Jul 2003 11:38:47 -0700

On Wed, 02 Jul 2003 15:45:50 -0700
Bob Hinden & Margaret Wasserman <[email-masked]> wrote:

[...]
> editorial comments to the authors.  This last call period will end on 16 

This looks like a strong draft.  Several issues exist though.

1) There is no mention of RFC 3041 (privacy enhanced) addresses.  Both
the issue as to if they should be responded with and if they should be
responded to needs to be addressed.

2) The security model is unclear as to the scope of responses.  There
is a sentence in the "Security Consideration" section which states the
implementation should have a default configuration which refuses to
respond to global scope addresses.

If this means that the protocol should be limited to link local
addresses that should be stated directly.  Use of a 1 Hop Limit or 255
Hop Limit with check would enforce this (see LLMNR for example and
reasons).  I think limiting the protocol to the link local reduces
its usefulness.

If its not limited to the link local then this protocol should probably
be filtered at the edge of the administrative domain.

In any case this issue needs to be clarified.

3) (minor)  Site locals are called out.  For historical reasons I can
see maintaining the query, but the historical nature of the request
should be called out.  The handling of IPv4 mapped addresses is
unclear.  If global addresses are requested that probably shouldn't
include IPv4 mapped addresses.

			Michael Hunter

---

From: [email-masked]
Date: Wed, 09 Jul 2003 11:30:08 +0900

>  - Updated security considerations

	thank you very much for updating the document.  as stated in the
	last call announcement we use it heavily in network troubleshooting,
	so would really like to see it documented.

	I would like to see IPv4 address query (Qtype=4) go away.  also i don't
	see a need for IPv4 mapped address (Qtype=3 C bit).  it is a protocol
	for IPv6, afterall (if IPv4 variant is needed, it should be defined
	on IPv4, or the "name lookup" document has to become protocol-
	independent).

	Qtype 3 A bit handling is a little bit complicated.  how about 
	moving the description to the top? (right after the first paragraph
	of 6.3)  without understanding A bit, readers cannot understand the
	interpretation of other bits.

	on page 3, text for NI query code 1 refers to "Supported Qtypes"
	which is no longer there (Qtype=1).  suggestion: remove text starting
	from "as in ....".

itojun

---

From: [email-masked]
Date: Wed, 09 Jul 2003 11:34:58 +0900

>responded to needs to be addressed.

	just FYI from implementation POV: KAME implementation does not
	include RFC3041 addresses in the response by default.  there's a
	configuration flag bit which makes the responder to include RFC3041
	addresses as well.

	i guess that sensible default would be not to include RFC3041 addresses.

>reasons).  I think limiting the protocol to the link local reduces

	i really would like to keep it usable globally (= do not limit
	it to link-local only).  we use the protocol to query name of
	intermediate routers, which is several hops away, for debugging
	purposes.

>be filtered at the edge of the administrative domain.

	it is up to administrator of the domain, therefore i think
	recommendation like "SHOULD filter" is too strong.  how about
	"may want to filter" or something like that?

itojun

---

From: Robert Elz <[email-masked]>
Date: Wed, 09 Jul 2003 15:51:28 +0700

Date:        Wed, 09 Jul 2003 11:34:58 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	i really would like to keep it usable globally (= do not limit
  | 	it to link-local only).  we use the protocol to query name of
  | 	intermediate routers, which is several hops away, for debugging
  | 	purposes.

I agree with this, there is nothing about the protocol itself that
requires (or demands) that its usage be limited.

  | 	it is up to administrator of the domain, therefore i think
  | 	recommendation like "SHOULD filter" is too strong.  how about
  | 	"may want to filter" or something like that?

yes, exactly - after all, it isn't as if there are any great secrets
being revealed here in any case.   Anyone can filter anything that they
need to filter from entering or leaving their network - that may decrease
the usefulness of their net, there's always that tradeoff.   We don't
need instructions to tell people that there's something specially dangerous
here that requires special filtering - there isn't.

kre

---

From: Michael Hunter <[email-masked]>
Date: Wed, 9 Jul 2003 10:55:46 -0700

> 	i guess that sensible default would be not to include RFC3041 addresses.

Or respond to requests to RFC3041 addresses.

[...]
> 	"may want to filter" or something like that?

Removing the "SHOULD have a default configuration which refuses to
answer queries from global-scope" and replacing that with a
recommendation ("may want to filter") that this protocol be filtered
seems reasonable to me.

                         mph

---

From: Alain Durand <[email-masked]>
Date: Thu, 10 Jul 2003 11:21:18 -0700

> 	i guess that sensible default would be not to include RFC3041 

Including RFC3041 addresses in the list of global addresses returned is 
one part of the issue.
The other one is: if a NIQ is send to a RFC3041 address, do you reply 
to it?
My take is that by default, you should not and have a switch to 
override.

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 11 Jul 2003 08:00:36 +0300 (EEST)

> Including RFC3041 addresses in the list of global addresses returned is 

I can certainly see this..

> The other one is: if a NIQ is send to a RFC3041 address, do you reply to
> it? My take is that by default, you should not and have a switch to
> override.

But I fail to see any use for this.  Typically when you implement these, I
think they'll listen to all addresses ("any incoming packet").  It seems
that disabling one set of addresses and even giving users a toggle of
rather little value would be useless.  But of course, one might have to 
implement differently too.

But the spec could say e.g. that NIQ's don't need to be answered at 
RFC3041 addresses, and leave at it that.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Alain Durand <[email-masked]>
Date: Fri, 11 Jul 2003 07:42:17 -0700

> RFC3041 addresses, and leave at it that.

That would be enough, the rest is implementation detail.

	- Alain.

---

From: Michael Hunter <[email-masked]>
Date: Fri, 11 Jul 2003 11:12:09 -0700

On Fri, 11 Jul 2003 08:00:36 +0300 (EEST)
Pekka Savola <[email-masked]> wrote:

[...]
> implement differently too.

The association between RFC3041 addresses and other addresses is what you
want to protect.  If you let a 3rd party discover that association with
NIQ then you've removed the little usefulness that RFC3041 addresses have.

[...]

I think it should be as strong as the statement about replying with
RFC3041 addresses in NIQs.  The reason for not wanting either is that
both allow for the association between RFC3041 addresses and other
addresses.  I can't see making a statement about the two cases with
differing levels of strength.

			mph

---

From: Alain Durand <[email-masked]>
Date: Fri, 11 Jul 2003 12:06:43 -0700

Section 8:
    Note that the address selection mechanisms of [ADDSEL], and in
    particular the policy override mechanism replacing default address
    selection, are expected to be used on a site where Local IPv6
    addresses are configured.

==> This will not scale as there is currently no standardized mechanism
         to distribute a policy table to all the nodes within a site.

		- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 11 Jul 2003 22:40:29 +0300 (EEST)

> NIQ then you've removed the little usefulness that RFC3041 addresses have.

Please re-read what you write.

What you're implying is that those you're worried about would learn your 
"true identity" and not RFC3041 would ones allowed to send NIQ's to you 
and you'd actually answer them?

Never.  Never.

I'd go as far as state that off-link NIQ's MUST be disabled by default and 
MUST NOT be enabled unless there are acccess controls specific to the 
requester (e.g. IPsec SA) which allow that.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Jul 2003 16:25:51 +0200

>          to distribute a policy table to all the nodes within a site.

That is a problem that has to be solved anyway. I don't see why it is
specific to Bob's draft.

   Brian

---

From: [email-masked]
Date: Sat, 12 Jul 2003 23:40:37 +0900

>That is a problem that has to be solved anyway. I don't see why it is

	i don't think so.  introducing limited-scope (local) IPv6 address is
	problematical in multiple ways (DNS lookup, can't use as referrals,
	leakage, just like site-local), so technology that needs "distribution
	of policy table" is not recommended.

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Jul 2003 17:08:40 +0200

>         of policy table" is not recommended.

I don't see the connection. 

We will have two-faced DNS, unreferrable addresses, and leakage
anyway. They are part of life on the Internet these days. Having
unique local addresses reduces the damage.

    Brian

---

From: Pekka Savola <[email-masked]>
Date: Sun, 13 Jul 2003 09:45:29 +0300 (EEST)

> editorial comments to the authors.  This last call period will end on 16 

I've already commented on NIQ LC on other threads, but I'm sending in some
other comments now..

The fundamental issues we should get consensus on quickly seem to be:
 - how much backward-compatibility we want preserve
   a) in the spec
   b) as possibilities in the existing implementations
 - how "good" (architecturally, design-wise, etc.) we want the NIQ mechanism
to be

Now, from my point of view, there are two options.

 1) going for Experimental with a smaller amount of changes
   ==> and possibly revise later, _then_ breaking backward compat.

 2) going for Proposed Standard with, if necessary, breaking backward
compatibility

IMHO, going for PS with the current spec is unacceptable.

That aside, I honestly believe that something similar to Node Information
queries (just a LOT simpler) is very useful e.g. in debugging and
diagnostics operations, and possibly some other restricted scenarios (I work
for an ISP NOC ;-).  Likely, on-link queries, and queries restricted to
specific requesters (e.g. those whose source address belongs to your site,
or whose IPsec SA is good enough for you).

major issues
------------

A lot of features should be removed; the spec seems to have enjoyed from a
very extensive feature creep.. 

(On the other hand, by some modifications one might be able to evolve --
if we so desire -- NIQ's also to the direction of a
replacement/augmentation of router-router discovery protocol like CDP, or
to evolve to a generic router/host discovery protocol.)

1) NI Query ICMP codes and Qtypes implement similar functionality, leading to
potential complications:

    Code        For NI Query:

                0   Indicates that the Data field contains an IPv6
                    address which is the Subject of this Query.

                1   Indicates that the Data field contains a name which
                    is the Subject of this Query, or is empty, as in the
                    case of a NOOP or Supported Qtypes query.

                2   Indicates that the Data field contains an IPv4
                    address which is the Subject of this Query.
[...]
    The following Qtypes are defined.  Qtypes 0, 2, and 3 MUST be
    supported by any implementation of this protocol.  Qtype 4 SHOULD be
    supported by any implementation of this protocol on an IPv4/IPv6
    dual-stack node and MAY be supported on an IPv6-only node.

    0   NOOP.
    1   (unused)
    2   Node Name.
    3   Node Addresses.
    4   IPv4 Addresses.

==> For example, what about NI code=0 w/ Qtype=2, or NI code=1 w/ Qtype=3?

This seems like a totally unnecessary complexity to me.  Whole Qtypes (or
different ICMP codes for NI, just always use zero) could probably be
removed completely.

2) Unnecessary complexity relating to IPv4 addresses.  Itojun already
pointed this out, but I believe everything returning IPv4 addresses (or
requesting) should go away; in particular:

 - section 4, Code 2
 - section 6, the last sentence of the first paragraph
 - section 6.3, flag C; last paragraph of this section
 - section 6.4 in entirety 

3) Node names Qtype/generic syntax supports returning multiple node names. 
This seems like a completely useless feature: a node does not have multiple
host names.  Remove it; in particular:
 - section 6.2, s/Names/Name/ in the diagram; reword "Each name" in "Node
Names; second paragraph at the end of page 6 and the beginning of page 7

4) The second paragraph of section 5 describes quite a complex mechanism
to use for the formation of the NI Group Address.  This seems useless; I
assume it has originally been devised as a mechanism of filtering traffic
on LAN's with a lot of nodes for not to overload them.  I do not think
that at least *this* is anything to be worried about.  One could just use
all-nodes link-local address, or just reserve another link-local address
which all nodes implementing NIQ's would listen to.  Plain & Simple.

5) The node addresses flags described in 6.3 are mostly useless.  They seem
only useful in scenarios where there are too many addresses that they don't
fit in one response message.  In that case, we may have to devise a
mechanism to serialize messages or fragment them anyway.  Otherwise, the
only useful flag seems like an indication of whether to receive:

 - the addresses on this link, and virtual addresses on top of that *)
 - all addresses of the node

Note: reporting link-local addresses should not be done except with the
first option only.

*)  the definition could be like:
"Address independent of any network interface (for example those assigned on
the loopback interface)"

6) In Node Addresses, separate 32-bit TTL for each address is useless and
could be removed.  This is not a big source of complication though, just a
remnant for backward compat.  (Similarly, a single TTL in 6.2 is in a
similar state.)

.....

Another big issue is clarifying the area of applicability and consequently
revising the security mechanisms connected to it.

IMHO, the following might be adequate:
 
Queries would be sent with Hop Count = 255.
 1) link-local (those whose Hop Count is 255) queries are always answered.  
These include those to link-local scope addresses, and those to global
addresses that just happen to be your neighbors.

 2) off-link queries which have Hop Count smaller than 255 have to be
separately authorized/authenticated somehow, otherwise the default MUST be
disabled.  Possibly good ones include:

 a) source address belongs to a list of allowed prefixes (default could be
to allow your own site, if that information (ie. the prefix length) is
easily obtainable) [note that this is OK because the reply goes to the
same address as source, if you spoof your source, it doesn't matter]

 b) an IPsec security association

.. in particular, answering a query from basically anyone in the Internet by
default MUST NOT be enabled unless explicitly configured.

In particular, the current security considerations text is rather weak:

    This protocol has the potential of revealing information useful to a
    would-be attacker.  An implementation of this protocol SHOULD have a
    default configuration which refuses to answer queries from global-
    scope [3513] addresses.

    The information learned via this protocol SHOULD not be trusted for
    making security relevant decisions unless some other mechanisms
    beyond the scope of this document is used to authenticate this
    information.

more or less substantial
------------------------

    The applicability of these mechanics is currently limited to
    diagnostic and debugging tools.  These mechanisms can be used to
    learn the addresses and names for nodes on the other end of a
    point-to-point link or nodes on a shared-medium link such as an
    Ethernet.  

	This is very useful when debugging problems or when
    bringing up IPv6 service where there isn't global routing or DNS
    name services available.  

 	IPv6's large auto-configured addresses
    make debugging network problems and bringing up IPv6 service
    difficult without these mechanisms.  An example of a IPv6 debugging
    tool using IPv6 Node Information Queries is the ping6 program in the
    KAME, USAGI, and other IPv6 implementations [KAME].

==> the middle sentence (highlighted above) appears to assume that there is
no IPv4 at all, and it's IPv6-only or nothing.  A nice requirement in
theory, but practically not so interesting.

==> s/a IPv6/an IPv6/

    Data        In a Query, the Subject Address or Name.  In a Reply,
                Qtype-specific data present only when the ICMPv6 Code
                field is zero.  The length of the Data may be inferred
                from the IPv6 header's Payload Length field [2460], the
                length of the fixed portion of the NI packet and the
                lengths of the ICMPv6 header and intervening extension
                headers.

==> aren't there any data length alignment/padding issues in ICMPv6?

    The Nonce should be a random or good pseudo-random value to foil
    spoofed replies.  An implementation which allows multiple
    independent processes to send NI queries MAY use the Nonce value to
    deliver Replies to the correct process.  Nonetheless, such processes
    MUST check the received Nonce and ignore extraneous Replies.

==> it might also be useful to log a warning in case you receive responses
you haven't queried for (assuming the implementation keeps a short-lived
record of these) -- especially if the response is directed to you and not 
multicast.

    If true communication security is required, IPsec [2401] must be
    used.  Providing the infrastructure to authenticate NI Queries and
    Replies may be quote difficult outside of a well-defined community.

==> which brings us back to the applicability statement: I really don't
think you could honestly deploy NIQ's under it's applicable environment in
the scenario where you couldn't implement IPsec (and keying material in
particular). 
==> s/quote/quite/

    Finally, if the Qtype is known and the response is allowed by local
    policy, the Responder must fill in the Flags and Reply Data of the
    NI Reply in accordance with the definition of the Qtype and transmit
    the NI Reply with an ICMPv6 source address equal to the Queried
    Address, unless that address was an anycast or a multicast address.
    If the Queried Address was anycast or multicast, the source address
    for the Reply SHOULD be one belonging to the interface on which the
    Query was received.

==> isn't the last sentence, at least, redundant in the face of Default
Address Selection (which has overtaken NIQ's, spec-wise, which is why this
draft even mentions this, I guess)

    Implementations SHOULD apply rate-limiting to NI responses to avoid
    being used in a denial of service attack.

==> note that the spec seems to apply rate-limiting only to failed or
negative responses: not positive responses which are responded to.  I think
it might be useful to similarly rate limit positive responses, even though
the rate-limit could be higher.

editorial
---------

==> Add IPR considerations and copyrights sections

                       IPv6 Node Information Queries
                <draft-ietf-ipngwg-icmp-name-lookups-10.txt>

==> s/Node Information/Node Information (NI)/ ?

Internet Draft             ICMP Name Lookups               June 26, 2003

==> "ICMP name lookups" should be updated to be closer to "ICMP Node
Information Queries"

     Address.  A node receiving a NI Query will be termed a Responder

==> s/a NI/an NI/

    without the domain.  Where necessary, the cases of fully-qalified

==> s/qa/qua/

 Five values of Qtype are specified in
                this document.

==> More likely four, or even less (hopefully) [the same in a few other
places in the document, IIRC]

    Data        In a Query, the Subject Address or Name.  In a Reply,
                Qtype-specific data present only when the ICMPv6 Code
                field is zero.

==> s/data/data is/

10.  References

==> split the references