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

From: "Pashby, Ronald W CTR NSWCDD-B35" <[email-masked]>
Date: Tue, 20 Sep 2005 13:37:12 -0500

Brian,

I agree with the suggestion. My understanding is that this is used for on-link queries (especially the name lookup) which is a link local multicast.

We also need to get comments on the proposal of limiting the multicast id to 0xFF000000 - 0xFFFFFFFF (overlaying the Solicited Node range). Here is my comments on the multicast range.

I would like to support this draft, because it provides enhanced network management capabilities. However with the current multicast address selection, I cannot recommend that any equipment with this implemented to be connected to any mission critical networks (e.g. nuclear reactor control, combat systems, navigation control, real-time financial) that utilize multicast.

The problem with MD5 hashing the name and using the 32 bits directly for the lower 32 bits of the multicast address is that, an unsuspecting host can be flooded with multicast traffic, just because it joined the multicast group for name lookup queries. This could cause the host to fail in performing its real-time mission critical task.  A small probability of this occurring is not acceptable, if making it zero is easily accomplished by limiting the range.

The solution is to map the hashed name into a range of multicast ids that will not collide with other "real" multicast streams. I recommend that 24 bits of the hash are used and a 0xFF be appended, mapping it into the Solicited Node range. I have another draft, draft-pashby-mboned-mc-scoped-addr-00 that further defines the ranges that are specified by RFC3307. These further breakdowns, will isolate other multicast traffic colliding with the Solicited Node range. This draft was scheduled to be discussed in the mboned wg, but was not discussed when mboned wg and imad bof were combined. 

I understand this breaks implementations, but I would rather break implementations that are written to a draft, rather than allow implementations that could cause catastrophic problems in real-time mission critical networks.

Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian Haberman
Sent: Tuesday, September 20, 2005 13:13
To: IPv6 WG
Subject: Re: IPv6 WG Last Call:
<draft-ietf-ipngwg-icmp-name-lookups-12.txt>

On Aug 1, 2005, at 2:08, Pekka Savola wrote:

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

I would like to solicit opinions from the working group on the 
suggestions
above.  Specifically, the proposal would render existing implementations
non-conformant to the spec.  The primary goal of this work has been to
document what the existing code bases support, so I will not make this
change unless I see a true consensus to do so.

Please provide comments by Sept. 28, 2005.

Regards,
Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 21 Sep 2005 18:15:02 +0100

In the light of the previous discussion I had with Ron on this subject, 
it occurs to me that it would address Ron's issue if responders joined 
both the old 32 bit and the Solicited Node related multicast addresses.  
Queriers that are worried about real time issues can use the new 
Solicited Node related address and the 32 bit address could be 
deprecated.  Configuration could allow the old address to be switched 
off if a network has multicast resource issues in routers.

Regards,
Elwyn