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

Hugh Holbrook <> Tue, 10 June 2003 17:39 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id NAA10350 for <>; Tue, 10 Jun 2003 13:39:58 -0400 (EDT)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h5AHd9B11881; Tue, 10 Jun 2003 13:39:09 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h5AHc0B11840 for <>; Tue, 10 Jun 2003 13:38:00 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id NAA10324 for <>; Tue, 10 Jun 2003 13:37:56 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19Pn2H-0000qH-00 for; Tue, 10 Jun 2003 13:35:53 -0400
Received: from ([]) by ietf-mx with esmtp (Exim 4.12) id 19Pn2G-0000q0-00 for; Tue, 10 Jun 2003 13:35:52 -0400
Received: from ( []) by (8.12.9/8.12.6) with ESMTP id h5AHb4jc025963; Tue, 10 Jun 2003 10:37:15 -0700 (PDT)
Received: by (Postfix, from userid 500) id 61C9910B7A7; Tue, 10 Jun 2003 10:36:50 -0700 (PDT)
From: Hugh Holbrook <>
To: Toerless Eckert <>
Cc: Jon Zeeff <>, Toerless Eckert <>, Bill Fenner <>,
In-reply-to: <>
Subject: Re: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational
Message-Id: <>
Date: Tue, 10 Jun 2003 10:36:50 -0700
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Source-Specific Multicast <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Jon, Toerless:

This problem has not been ignored by the IETF; see

Section 3.5 states that a router should not revert to IGMPv2 (or
MLDv1) compatibility mode in the SSM range in response to IGMPv1/v2 or
MLDv1 reports.  So this protects against v1 and v2 reports in the SSM
range.  That is if a v2-only host sends a v2 report for some SSM
address, it won't deny ssm service to everyone else.  To deny SSM
service, you have to either plug in a v2 *router*, or you have to have
a malicious attacker that is sending v2 queries.

I think the current rules (MUST log an error on the v3-capable router)
are good enough to detect benign misconfigurations when you have a v2
router on the LAN.  You see the log, go find the bad router, and fix

For *malicious* attacks, we considered a requirement on hosts to
ignore v2 queries in the SSM range.  The -03 revision of the draft, in
fact, included text specifically nothing this as a MAY.  But this (a)
contradicts RFC3376, it is only is useful if the *routers* also refuse
to revert to v2 compatibility mode (for the SSM range) in the presence
of a v2 querier, and it results in a situation that is not addressed
at all in RFC3376.  Our assessment was that there were too many
complicated scenarios to get this right, and so we did not call this
out as an option.

If you want to suggest something else, pleaes bring your concerns
forward now.  Hitoshi, if you have implementation experience that
indicates that this works, that would also be useful to know.  The
ssm-with-igmpv3/mld document has just gone through a magma wg last
call, and mostly passed -- we're pretty close to shipping it to the

An alternative solution to address the problem is to filter v2 queries
at the ingress physical port -- basically implement a layer 2 security
policy that prevents queries from unauthorized hosts.  A number of
vendors make products that are capable of this, at least in the wired

The right way for hosts to learn the SSM range is to use the MRD SSM
Range option, IMO.


> > I see similar lack of concern about real world security in
> > wireless routing protocols (and DHCP and IPv6 and PIM and ...).
> Well, it's as simple as this: IGMPv3 was NOT MADE for SSM, so it's a
> bit hart to shift the blame onto it completely. Once there is sufficient
> interest in SSM and people come to realize that SSM alone is sufficient
> in many cases on hosts, one could make much stronger statements about an SSM
> subset (and extensions) of IGMPv3 implementations in hosts:
>    subset: - Ignore all IGMPv1/v2 queries
> 	   - Don't implent any exclude mode reports
>    extension: - trigger unsolicited IS_INCLUDE mode reports after
> 	        60 seconds without a query.
> Makes a really simple & safe SSM only implementation, and is completely
> compatible with IGMPv3 routers. But as long as the host needs to support
> both ASM _and_ SSM, it is really hard to strip down the complexity: Even
> that part of "which group is SSM, which is ASM" is contentuous. I for
> once am a strong proponent of using SSM also within 239/8 because of admin
> scoping, so how does a host determine wether a group is SSM or not ?
> MSNIP SSM range ? Well, that's another requirement for a host stack,
> and if i look at how long it takes for new requirements to be implemented
> into host stack *oh well*...
> Cheers
> 	Toerless
ssm mailing list