Subject: Fwd: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-13.txt

From: Brian Haberman <[email-masked]>
Date: Wed, 4 Jan 2006 16:08:01 -0500

All,
      I have integrated most of the changes I proposed to the ICMP Names
draft.  After my previous note on the subject, I had a lot of input on  
the
tunnel endpoint text and determined that there was not consensus to add
it to the document.

      As this draft is now in the repository, Bob will start a WG Last  
Call so
that we can begin moving it forward.

      Thanks to everyone who has provided input, reviews, and comments.

Regards,
Brian

Begin forwarded message:

> From: [email-masked]
> Date: January 4, 2006 15:50:01 EST
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-13.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> This draft is a work item of the IP Version 6 Working Group Working  
> Group of the IETF.
>
> 	Title		: IPv6 Node Information Queries
> 	Author(s)	: M. Crawford, B. Haberman
> 	Filename	: draft-ietf-ipngwg-icmp-name-lookups-13.txt
> 	Pages		: 15
> 	Date		: 2006-1-4
> 	
> This document describes a protocol for asking an IPv6 node to supply
>    certain network information, such as its hostname or fully-qualified
>    domain name.  IPv6 implementation experience has shown that direct
>    queries for a hostname are useful, and a direct query mechanism for
>    other information has been found useful in serverless environments
>    and for debugging.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name- 
> lookups-13.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of  
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the  
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-ipngwg-icmp-name-lookups-13.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-13.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: David Malone <dwmalone=[email-masked]>
Date: Wed, 4 Jan 2006 21:52:50 +0000

On Wed, Jan 04, 2006 at 04:08:01PM -0500, Brian Haberman wrote:
> the tunnel endpoint text and determined that there was not consensus to add
> it to the document.

Some text seems to have been added to the draft that I don't remember
being discussed here. The diff is:

                         node MAY be configured to discard NI Queries to
    multicast addresses other than its NI Group Address(es) but if so,
-   the default configuration MUST be not to discard them.
+   the default configuration SHOULD be not to discard them.  An
+   exception is made in the previous rule in the case of the All-Routers
+   (FF02::2) and All-Nodes (FF02::1) multicast addresses.  The default
+   configuration for responding to NI Queries to these multicast
+   addresses MUST be to discard them.

All-nodes is one of the most useful addresses to send a node
information query to. If you are trying to find a newly configured
bit of kit you've just plugged in you'll query the all nodes address
and see if it responds with a recognisable name. Requiring that
nodes do not respond by default makes this far less useful.

Also, using the all-nodes address would be the solution if you need
to use NI queries on a network that has a mix of machines using the
old draft and the new draft. I sort of articulated this in this
message:

	http://www1.ietf.org/mail-archive/web/ipv6/current/msg05925.html

without this, I don't see an obvious way to manage such a network
without sending messages to two multicast addresses, which weakens
the argument for changing the multicast range.

(In fact, in the last around of discussions, several people suggested
ditching the hashed name lookups and just keeping the unicast and
regular multicast lookups, so this seems a very strange change to
make.)

	David.

---

From: Brian Haberman <[email-masked]>
Date: Thu, 5 Jan 2006 08:40:23 -0500

Hi David,

> nodes do not respond by default makes this far less useful.

This change was made to address DoS concerns raised with having
the default behavior to respond to queries to the All-Nodes address.
Some people have argued that allowing nodes to respond in this
case simplifies an attacker's ability to map out a victim network.

> the argument for changing the multicast range.

The change in multicast addresses was introduced to conform to RFC
3307.

> regular multicast lookups, so this seems a very strange change to

The primary goal of this work is to document what has already been
implemented.  Making the change to the multicast address was discussed
with people who have already implemented the protocol to ensure it
would not be a big impact.  Eliminating hashed name lookups would
make this protocol a new protocol (in my opinion at least).

Do others have concerns with the document as it is?

Regards,
Brian

---

From: Pekka Savola <[email-masked]>
Date: Thu, 5 Jan 2006 17:38:57 +0200 (EET)

> case simplifies an attacker's ability to map out a victim network.
...
> Do others have concerns with the document as it is?

Yes.  I completely agree with David on this.  A NIQ to the link-local 
all-hosts or all-routers group is a very useful feature (maybe even 
the most useful for ICMP NIQ), and I don't think it's good to forbid 
that.

It doesn't even really give much security.  If you have access to the 
link, you can pretty much observe which nodes are on the link anyway 
using dozens of mechanisms such as:
  - pinging all-routers/all-hosts mcast address and then sending
    individual NIQ's
  - looking at the ND packets that fly by
  - etc.

-- 
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: David Malone <[email-masked]>
Date: Thu, 5 Jan 2006 15:43:14 +0000

> the default behavior to respond to queries to the All-Nodes address.

Echo requests already have this problem. I have a feeling that it
makes no sense to drop queries to ff02::1 unless you also do the
same for all other ICMP types that require a response.

> case simplifies an attacker's ability to map out a victim network.

Currently to get a list of names I issue NI queries by using:

	ping6 -w ff02::1

I get the answer in 1+N packets. After this change to the draft I
do this:

	ping6 ff02::1 > responders
	for $addr in `cat responders`; do; ping6 -w $addr ; done

Now I have the same list of names, I've just had to use 1+3N packets
That won't deter any attacker, but makes the life harder for the
person who actually wants to use NI queries for some legitimate
reason.

Maybe all this has been covered in a discussion somewhere already?
I did spend a while searching for such a discussion, but didn't
turn up anything useful.

> The change in multicast addresses was introduced to conform to RFC

Yes - though I thought part of Ron's motivation for the change was
to avoid sending NI queries to hosts that didn't want them. Regardless,
I'm OK with changing the multicast address range as long as it is
still possible to query ff02::1.

> make this protocol a new protocol (in my opinion at least).

Changing the multicast range or eliminating hashed name lookups
would be easy implementation changes I guess. I'm just trying to
consider the usability of the protocol, which doesn't have much
to do with how hard it is to implement.

	David.

---

From: Bob Hinden <[email-masked]>
Date: Thu, 5 Jan 2006 15:36:16 -0800

> Yes.  I completely agree with David on this.  A NIQ to the link- 
> local all-hosts or all-routers group is a very useful feature  
> (maybe even the most useful for ICMP NIQ), and I don't think it's  
> good to forbid that.

I agree as well.  This is one of the main uses for NIQ.

Bob