Re: IPv6 WG Last Call: <draft-ietf-ipngwg-icmp-name-lookups-12.txt>

[Pekka Savola <[e-mail]>]

On Fri, 15 Jul 2005, Bob Hinden wrote:
> This starts a two week IPv6 working group last call on advancing:
>
>        Title           : IPv6 Node Information Queries
>        Author(s)       : M. Crawford, B. Haberman
>        Filename        : draft-ietf-ipngwg-icmp-name-lookups-12.txt
>        Pages           : 14
>        Date            : 2005-7-14
>
> to Experimental.  Please send substantive comments to the IPv6 mailing list. 
> Editorial comments can be sent to the authors.

Sorry for missing the DL by a couple of days, but here are my comments 
anyway.

I've been very critical of the node information queries in the past, and
still am, but as it's going to Experimental, I'm not as concerned.  However,
I think there are still a couple of very important things which need to be
settled so that a) it can be used safely and b) it won't jeopardize the real
use of IPv6 ICMP messages.

Specifically, I'm very concerned about its use with global addresses, over
the Internet.  This has a potential to turn into a kitchen sink protocol,
which can be used to do query anything at all from a random node.  This is
exactly the thing that makes want to firewall administrators filter out
all ICMPv6 messages just to be sure messages like this won't be used
in the systems.  I don't think we want that.

I have no objection to having a protocol like this used between consenting
adults between link-local addresses or even global addresses if done over a
single link -- but extending it (or providing extendibility) beyond that
seems unwise.

My suggestion how to deal with this is to:
  - add that a node MUST send all non-link-local node information queries
    with Hop Count 255; HC=255 MAY [or SHOULD] be used with other traffic
    as well; and
  - a node MUST, unless explicitly configured otherwise, discard any node
     information queries w/ non-link-local queries which don't have HC=255.

This only breaks backward compat for node information queries sent w/ global
addresses, over one hop away.  I think we could live with that.  It should
provide a sufficiently simple security model for ensuring NIQ's won't be
used inappropriately.

A couple of specific comments below:

substantial
-----------

    The mechanisms defined in this document may have wider applicability
    in the future (for example, name lookups in zero configuration
    networks, global reverse name lookups, etc.), but any use beyond
    debugging and diagnostic tools is left for further study and is
    beyond the scope of this document.

==> it seems inappropriate to mention these non-usages in this document,
especially "global reverse name lookups"; I'd remove that at the very least.

   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.

==> the "should" should be stronger.  I suggest a MUST, because it's
essential for the security.  Otherwise, there needs to be much more text on
not assuming the nonce provides any security.

6.1  NOOP

    This NI type has no defined flags and never has a Data field.  A
    Reply to an 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 last sentence may require rewording as I guess whether it's revealed
or not depends on which version of addr-arch is implemented..?

    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 [3] addresses.

==> I'd say a MUST here, instead of a SHOULD.

editorial
---------

    the domain.  Where necessary, the cases of fully-qalified and single-
    label names will be distinguished.

==> s/qali/quali/

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

==> this case seems a bit like an operational recommendation or something
other than an implementation & interop issue, so uppercasing a MUST may be a
bit inappropriate.

-- 
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 IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------