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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
