Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational

Jean-Jacques Pansiot <Jean-Jacques.Pansiot@crc.u-strasbg.fr> Fri, 13 June 2003 08:14 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24783 for <ssm-archive@lists.ietf.org>; Fri, 13 Jun 2003 04:14:45 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CHmWa11759; Thu, 12 Jun 2003 13:48:32 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ADoVB23279 for <ssm@optimus.ietf.org>; Tue, 10 Jun 2003 09:50:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00009 for <ssm@ietf.org>; Tue, 10 Jun 2003 09:50:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PjU8-0006Or-00 for ssm@ietf.org; Tue, 10 Jun 2003 09:48:24 -0400
Received: from ns1.u-strasbg.fr ([130.79.200.1]) by ietf-mx with esmtp (Exim 4.12) id 19PjU7-0006Ok-00 for ssm@ietf.org; Tue, 10 Jun 2003 09:48:24 -0400
Received: from crc.u-strasbg.fr (crc.u-strasbg.fr [130.79.201.129]) by ns1.u-strasbg.fr (8.12.6p2/jtpda-5.4) with ESMTP id h5ADoGHT026714 ; Tue, 10 Jun 2003 15:50:16 +0200 (CEST)
Received: from crc.u-strasbg.fr (sixnet.u-strasbg.fr [130.79.90.153]) by crc.u-strasbg.fr (8.12.9/jtpda-5.4) with ESMTP id h5ADoGXc090189 ; Tue, 10 Jun 2003 15:50:16 +0200 (CEST)
Message-ID: <3EE5E218.9020108@crc.u-strasbg.fr>
Date: Tue, 10 Jun 2003 15:50:16 +0200
From: Jean-Jacques Pansiot <Jean-Jacques.Pansiot@crc.u-strasbg.fr>
Organization: ULP LSIIT & Departement d'Informatique
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020811
X-Accept-Language: fr, en-us
MIME-Version: 1.0
To: Jon Zeeff <jzeeff@internet2.edu>
CC: Toerless Eckert <eckert@cisco.com>, Bill Fenner <fenner@research.att.com>, ssm@ietf.org
Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational
References: <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> <200306040550.h545oaD08547@windsor.research.att.com> <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu> <5.1.0.14.2.20030610085539.023c1740@mail.internet2.edu>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Antivirus: scanned by sophos at u-strasbg.fr
Content-Transfer-Encoding: 7bit
Sender: ssm-admin@ietf.org
Errors-To: ssm-admin@ietf.org
X-BeenThere: ssm@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=unsubscribe>
List-Id: Source-Specific Multicast <ssm.ietf.org>
List-Post: <mailto:ssm@ietf.org>
List-Help: <mailto:ssm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Jon Zeeff wrote:
> 
> 
>> From my experience, windows XP does send IGMPv2 reports if it sees 
>> IGMPv2 queries.
>> It MUST do this according to the IGMPv3 spec.
> 
> 
> So if I do manage to get my LAN completely IGMPv3 capable and thus allow 
> the use of SSM, all it takes is one person
> plugging in a machine running IGMPv2 and SSM breaks.  This probably 
> means that SSM is unimplementable except
> in some special cases (example: one host per vlan).

Hi
this is not my understanding of IGMPv3 (and MLDv2).
The problem you describe occurs only if a router runs IGMPv2,
which should not be the case in a well managed network.
If all routers are running IGMPv3 (or MLDv2)
then the compatibility "downgrade" is per group (ie per multicast address) :
that is a group may use IGMPv2 if one member host is IGMPv2 only,
and another group on the same LAN may use IGMPv3 if all member hosts use IGMPv3.
Moreover, although it is not completely clear to me,
I think IGMPv3 capable hosts and routers should not downgrade to IGMPv2
for a multicast address in the SSM range.

I suppose that the main problem arises when a malicious user
runs a fake IGMPv2 router.

Jean-Jacques


> 
>> So, as far as easy gradual migration to SSM with DoS attack prevention 
>> is concerned,
>> this has almost completely been ignored by the IETF process.
> 
> 
> I see similar lack of concern about real world security in wireless 
> routing protocols (and DHCP and IPv6 and PIM and ...).
> 
> Thanks for the info.
> 
> _______________________________________________
> ssm mailing list
> ssm@ietf.org
> https://www1.ietf.org/mailman/listinfo/ssm



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