[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Wed, 2 Jul 2003, Bob Hinden & Margaret Wasserman wrote:
> 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.

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

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

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

	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

==> 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 

    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
==> 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.


==> Add IPR considerations and copyrights sections

                       IPv6 Node Information Queries

==> 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

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

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 majordomo@sunroof.eng.sun.com