[magma] draft-daley-magma-smld-prob-00 comments

Pekka Savola <pekkas@netcore.fi> Sun, 01 August 2004 15:21 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06053; Sun, 1 Aug 2004 11:21:38 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrICJ-0004ae-93; Sun, 01 Aug 2004 11:24:27 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrI16-0001lD-A9; Sun, 01 Aug 2004 11:12:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrHmB-0002wL-3q for magma@megatron.ietf.org; Sun, 01 Aug 2004 10:57:27 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04754 for <magma@ietf.org>; Sun, 1 Aug 2004 10:57:25 -0400 (EDT)
Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrHoq-0004FK-Rs for magma@ietf.org; Sun, 01 Aug 2004 11:00:13 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i71Eut931813 for <magma@ietf.org>; Sun, 1 Aug 2004 17:56:55 +0300
Date: Sun, 01 Aug 2004 17:56:55 +0300
From: Pekka Savola <pekkas@netcore.fi>
To: magma@ietf.org
Message-ID: <Pine.LNX.4.44.0408011756040.31045-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Subject: [magma] draft-daley-magma-smld-prob-00 comments
X-BeenThere: magma@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:magma@ietf.org>
List-Help: <mailto:magma-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=subscribe>
Sender: magma-bounces@ietf.org
Errors-To: magma-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36

Hi,

First, I think this is a very useful document; even if we didn't end up
taking up serious effort for securing MLD, it is (IMHO) very useful to spell
out the problems it has.

You might be interested in draft-ietf-mboned-mroutesec-02.txt -- it's
already past the IESG evaluation, and all the issues have been addressed.
It discusses, to some extent, the effect of MLD/IGMP -generated state
in the inter/intra-domain multicast routing protocols (you refer to that a
couple of times).  There is no overlap with these documents; mroutesec
explicitly rules out any on-link communications with MLD/IGMP.  (That's why
I as co-author am especially interested to see a good document describing
MLD/IGMP issues -- these together form a relatively good picture of 
multicast security.)

semi-editorial
--------------

Additionally, bogus Multicast Router TerminateM  
   messages received on the same port as a router may be used to haltM  
   reception of all multicast data by the router[6].

==> is there such a port-specific provision?  I don't seem to recall it --
maybe I should re-read the mrdisc spec.. (the same for nodes in the next
paragraph)

6.   Existing protocol formats and messagesM
7.   Comparisons to other Signalling ProtocolsM
8.  Comparisons to other Multicast Security MechanismsM

==> these gave useful information, but 1st was just a re-cap and would
definitely need to go to an Appendix; the other two seemed slightly out of
scope for the body as well, and could live in the appendix.  Maybe section 8
would still be appropriate in the body of the document.

editorial
---------

   The Multicast Listener Discovery (MLD) is used by IPv6 routers toM
   discover the presence of multicast listeners (i.e.  nodes that wishM
   to receive multicast packets) on their directly attached links, andM
   to discover which multicast addresses are of interest to thoseM
   neighbouring nodes.

==> you made this sound a bit like that it's not nodes responsibility to
*report* such interest (but rather, routers would have active role in
discovering it -- rather than a passive one, as it is now).  I flinched
slightly when reading this for the first time, but it seems to be
pedantically correct though.

   cause the router to use Any-Source-Multicast (ISM) routing instead ofM
   Single-Source-Multicast in the short term.  This is described in theM

==> s/ISM/ASM/
==> s/Single-Source-/Source-Specific /

   Where host suppression is not in use [5], a router specifying a veryM
   small Maximum Response Code (Timer) in its Query may cause multicastM
   report bombing at fine granularity with a single message.  In someM
   cases, this may have severe consequences in terms of packet loss orM
   delay on other data sources or signalling.M

==> could you write out how many pps that bombing could be at worst, for
those of us that don't remember the exact timer values? :-)

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


_______________________________________________
magma mailing list
magma@ietf.org
https://www1.ietf.org/mailman/listinfo/magma