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

From: Bill Fenner <[email-masked]>
Date: Tue, 3 Jun 2003 22:50:35 -0700

For some reason, this went to the wrong address.  The IESG has approved
the SSM overview draft.

  Bill

----- Begin forwarded message:

From: The IESG <[email-masked]>
Subject: Document Action: An Overview of Source-Specific
         Multicast(SSM)  Deployment to Informational
Date: Thu, 29 May 2003 09:40:39 -0400
To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board
    <[email-masked]>, [email-masked]

The IESG has approved the Internet-Draft 'An Overview of Source-Specific 
Multicast(SSM) Deployment' <draft-ietf-ssm-overview-05.txt> as an 
Informational RFC.  This document is the product of the Source-Specific 
Multicast Working Group.  The IESG contact persons are Bill Fenner and 
Alex Zinin.
 
COMMENTS:
=========
Scott:
9 authors is kinda over the guidelines otherwise a useful document

RFC Editor Note:

Replace the author list with:

                                                                  Supratik
Bhattacharyya (Editor)
                                                                            
                                       Sprint

Section 6.1, para 1, line 4:

  OLD:
    policies being proposed [20], which recommends ...
                                                      ^^
  NEW:
    policies being proposed [9], which recommends ...

Section 6.4, para 1, line 6:

  OLD:
    provided by IGMP version 3 [3] and MLD version 2 [22]. These
                                                                            
                           ^^

  NEW:
    provided by IGMP version 3 [3] and MLD version 2 [20]. These

Section 7, para 2, line 4:

    OLD:
    [20] states ...
      ^^

    NEW:
    [9] states ...

Section 9. Acknowledgments

  ADD right after the section name:

      Christophe Diot, Leonard Giuliano, Rob Rockell, John Meylor,
      David Meyer, Greg Shepherd, and Brian Haberman were the major
      contributors to the document.

Section 10

  Change section name to "Informative References"

Section 12. Author information:

  Leave only info for Supratik.

  Put information about others in a new section called "13. Contributors"

----- End forwarded message:
_______________________________________________
ssm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ssm

---

From: Jon Zeeff <[email-masked]>
Date: Fri, 06 Jun 2003 14:52:33 -0400

Where is a good source of information on the details of migrating to SSM on 
real-world
LANs?

I've seen switches that crash when they see a IGMPv3 packet.  Apparently XP 
doesn't send
IGMPv3 packets when it sees certain traffic on an existing LAN.  Apparently 
routers
stop using IGMPv3 when they see IGMPv2 traffic (sounds an easy inadvertent 
DOS attack).

Please tell me I'm wrong and that a gradual migration from ASM to SSM is 
easy....

---

From: Jon Zeeff <[email-masked]>
Date: Fri, 06 Jun 2003 14:52:33 -0400

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 6 Jun 2003 13:19:36 -0700

On Fri, Jun 06, 2003 at 02:52:33PM -0400, Jon Zeeff wrote:
> real-world LANs?

You may have found a good place already.

>From my experience, windows XP does send IGMPv2 reports if it sees IGMPv2 queries.
It MUST do this according to the IGMPv3 spec.  Wether or not other hosts send
IGMPv2 membership reports does not seem to change windows XP behaviors if i
remember it correctly. It is allowed to do this according to the IGMPv3 spec,
and this certainly is the best and luckily also the easiest option to implement
on the host side.

> Please tell me I'm wrong and that a gradual migration from ASM to SSM is 

Unfortunately, this was never an argument in the design of IGMPv3. SSM itself
was never an argument for the design of IGMPv3. IGMPv3 started out as being
source filtering for ASM at a time when SSM was not even invented. Then it 
lingered around quite some time (years?) in the IETF, and then people started
to see that one could do a cool thing called SSM by leveraging IGMPv3. That's
when more work was put into pushing IGMPv3 through the IETF. Unfortunately is
was only pushing, it was never really any redesign for the benefit of SSM.
We already had a hard time to get certain protocol details out of IGMPv3
that were extremely detremental to SSM (hosts announcing EXCLUDE mode if the
source list became too long and the like).

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. The best i can offer
you is to recommend talking to your vendors of choice and ask them what their
solution offers in support of such operational requirements. There is quite
a bit of leeway in what implementations can do, specifically in the IGMP Snooping
arena and that's where there might be one or the other competitive differentiation
which is maybe not best discussed on an open mailing list.

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 6 Jun 2003 13:19:36 -0700

Cheers
	Toerless

---

From: Jon Zeeff <[email-masked]>
Date: Tue, 10 Jun 2003 09:04:52 -0400

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

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

---

From: Jon Zeeff <[email-masked]>
Date: Tue, 10 Jun 2003 09:04:52 -0400

Thanks for the info.

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 10 Jun 2003 15:59:31 +0200 (MEST)

> in some special cases (example: one host per vlan).

In fact, and unfortunately, you are right.
There was some lack of important statements in IGMPv3.

One is a following sentence:
	"the Querier continues to send IGMPv3 queries, regardless of
	 its Multicast Address Compatibility Mode."
This should be included in the RFC. But it was too late. Actually,
since we've found the problem before the MLDv2's last-call, it is
included in Sect.8.3.2 of draft-vida-mld-v2-07.txt, though.

Other is something related to "host compatibility mode" which I post
the problem in MAGMA ML.
<http://www1.ietf.org/mail-archive/working-groups/magma/current/msg00027.html>
But I heard this mail was also too late. Yes, it is also included in
MLDv2's I-D (Sect.10.1) as follows:
	"A forged Version 1 Query message will put MLDv2 listeners on
	 that link in MLDv1 Host Compatibility Mode.  This scenario
	 can be avoided by providing MLDv2 hosts with a configuration
	 option to ignore Version 1 messages completely."

FYI, my IGMPv3/MLDv2 implementations (incl. KAME) support them, anyway.
--
Hitoshi Asaeda

p.s. "IGMPv3 addendum" is the solution?
_______________________________________________
ssm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ssm

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 10 Jun 2003 15:59:31 +0200 (MEST)

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 10 Jun 2003 07:39:54 -0700

> in some special cases (example: one host per vlan).

While i completely agree that IGMPv3 sucks if all you want is SSM
mainly because it's is some orders of magnitue unnecessarily too complex
for that purpose. The actuall attack scenarios can all be solved:

The real issue is in the presence of older routers sending
IGMPv1 or IGMPv2 queries because they cause a host to (MUST) fall back
to IGMPv1/v2 reports, whereas other hosts IGMPv1/v2 reports MAY just
cause this (unlikely given that it makes a host implementation
much more complex).

So, there is definitely a conflict of interest between SSM and backward
compatbility in IGMPv3: You do not want to have an older router on a
network in which you wan to run SSM. Now, for all i care, everything 
RFC3376 says only applies to legally present entities in a network, eg:
Just because RFC3376 demands properties from implementations does not
imply uncontrolled deployment. RFC3376 itself will not ensure complete
protection against DoS attacks by unwanted IGMPv1/IGMPv2 group queries,
- rather the opposite -, but in most deployments you can quite well ensure
such protection.

The magic formula is quite simple: Put an intelligent layer2
switch into the network and connect only one host (or one set of hosts
in a common trust domain) per switched L2 port and solve access control
and DoS protection on the switch. That actually is the most common wired
ethernet deployment today and IGMPv2 queries aren't the only DoS reason
why such deployments are typically considered necessary to guarantee
protection in an even moderately friendly environment. Heck, if you
go into potentially hostile deployments, you even see stronger efforts
of L2 protection, and those have been put into place for much more fundamental
L2 issues than just what we're talking about here (see for example private
VLANs on Cisco Catalyst switches - and likely similar technologies in other
vendor products).

Do all L2 switches provide for good protection against unwanted IGMPv2
queries - heck, no, but most of them could via simple software updates:
Unless security is strongly being taken care of by the IETF protocol
process, it is left up to vendors and actual customer demand. Talk to
your vendor of choice ;-)

Sure, it would have been nicer if the whole IGMPv3 spec process would have
been revisited much harder in the face of IGMPv3 requirements - we tried,
but we clearly reached a wall there given the long time in the process
that was spend without thinking about SSM already. 

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

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

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 10 Jun 2003 07:39:54 -0700

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 10 Jun 2003 07:45:58 -0700

> There was some lack of important statements in IGMPv3.

Well, yes, but that decision was intentional back then by proponents 
that wanted to ensuer maximum automatic backward compatibility.

> included in Sect.8.3.2 of draft-vida-mld-v2-07.txt, though.

Ok, so in MLD i need not only start to send MLDv1 reports, i also have to
have a smaller IP address to win and become the querier ? How much
does this effectively buy me ?

> 	 option to ignore Version 1 messages completely."

Sure, such configuration options will be all over us and make deployment
even more complex. You can pretty much figure that only the default
behaviour will be what 90% of people will have installed. 

> FYI, my IGMPv3/MLDv2 implementations (incl. KAME) support them, anyway.

Is it on by default ? 

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 10 Jun 2003 07:45:58 -0700

Is it on by default ? 

Cheers
	Toerless

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 10 Jun 2003 17:23:32 +0200 (MEST)

> does this effectively buy me ?

Maybe I don't understand your question.. but, there is no change about
querier selection. (What is the relation to my last comment?)

> behaviour will be what 90% of people will have installed. 

I prefer to have an option to fix the problem rather than close my
eyes, even though it may make some additional complexity. (But it's
really complex?)

Anyway, in a README file of IGMPv3 imple., I specify as follws:
	....
	After this static configuration is done, any old IGMP Query
	message doesn't affect to change the compatibility mode.
	Remember this is useful only when correct upstream router(s)
	must be IGMPv3 capable and you want to filter out or ignore
	some bogus or unneeded old version's Report and Query messages
	transfered by irregular nodes. This configuration affects all
	interfaces of the box.
	Note that this configuration is not mentioned in a spec and
	turned off as the kernel's default value.

I've never said host compat is *always* wrong. But we may need to
bypass this automatic mode change *for some cases*. And at this
moment, I don't have other good idea to bypass it.
Or, do you have another solution to bypass the DoS Jon Zeeff mentioned?
Or, ignoring the problem is good for the deployment?

> > FYI, my IGMPv3/MLDv2 implementations (incl. KAME) support them, anyway.

No.

Thanks.

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 10 Jun 2003 17:23:32 +0200 (MEST)

No.

Thanks.

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 10 Jun 2003 08:59:24 -0700

> querier selection. (What is the relation to my last comment?)

No, i just interpreted your statement incorrectly out of context. Never mind ;-)
But: I am not sure how much more the stronger statement in MLDv2
buys. After all, it's the IGMPv3 for SSM spec that states you to ignore
any non IGMPv3 (include type) reports within the SSM range, so i am
not too much concerned about group mode behavior on the router, the
only critical elements is host behaviour and illegal lower version queriers.

> eyes, even though it may make some additional complexity. (But it's

And i prefer to have what's needed be enabled by default so that the
90% population that doesn't want to waste understanding this mess still
gets a save and working feature.

> 	turned off as the kernel's default value.

Very nice. Now how many pizzas does it take for you to enable this by
default ? ;-)) (yeah, yeah, i know you can't do this today, see - that's
the problem with config options, they are never enabled when you need them).

Here's what i would recommend for this protection: Define another
kernel flag (maybe force_v3_4_ssm) which you can enable by default.
If it is enabled, then you will force yourself into that IGMPv3 mode
(like with the flag you already have) only whenever there is at least
one active INCLUDE mode membership application running (eg: a socket
with an include source list). There's a higher than 90% chance that
an application using INCLUDE mode memberships is written for SSM, so
there you have your 90% correct by default situation. Sure, this wouldn't
work all too well for servers running a lot of different multicast
application simultaneously, but those are way below the 90% mark too.
And this default could be changed wether or not this is supposed to be
desktop or server installation.

Even if you don't have this flag enabled by default, you can still have
warnings by default: If you're not using IGMPv3 membership reports
(eg: querier is older) but you start an application using INCLUDE mode
reports, this might be worthy of a syslog to console or the like.

There's a lot of things you can do to improve the perception of SSM
application users i think. 

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 10 Jun 2003 08:59:24 -0700

Cheers
	Toerless

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 10 Jun 2003 19:21:41 +0200 (MEST)

Toerless,

> No, i just interpreted your statement incorrectly out of context. Never mind ;-)

Okay. :)

> only critical elements is host behaviour and illegal lower version queriers.

No. I mean, whether the multicast address is within the SSM range or
not, and whether the multicast routers compatibility mode is v3 or
not, IGMPv3 capable router SHOULD always send IGMPv3 General query. It
SHOULD NOT send IGMPv1/v2 query in order to avoid that the host
compatibility mode of IGMPv3 capable node is switched to v1/v2 by such
downgraded General query. Due to this rule, the v3 capable node
switches its compat mode only when v1/v2 router, which means
"non-upgraded router", appears on the link (with sending v1/v2 General
query).
It is in fact no problem for non-upgraded *legal* end-nodes since they
can only look 8 bytes from the top of the query message. So, we would
be able to guarantee the interoperability as well.
Further if you want to avoid the mode switch by the v1/v2 router, then
you can configure the compat mode disable by "statically". But as we
agreed, this should not be the default.
These situations are same of MLDv2.
This is my thought.

...snip...
> application users i think. 

Sounds interesting. I would think it.
Thanks.
--
Hitoshi Asaeda
_______________________________________________
ssm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ssm

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 10 Jun 2003 19:21:41 +0200 (MEST)

Toerless,

Okay. :)

...snip...

---

From: Hugh Holbrook <[email-masked]>
Date: Tue, 10 Jun 2003 10:36:50 -0700 (PDT)

Jon, Toerless:

This problem has not been ignored by the IETF; see
draft-holbrook-idmr-igmpv3-ssm-04.txt.  

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

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

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

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

-Hugh

> > I see similar lack of concern about real world security in
> > wireless routing protocols (and DHCP and IPv6 and PIM and ...).
>

---

From: Hugh Holbrook <[email-masked]>
Date: Tue, 10 Jun 2003 10:36:50 -0700 (PDT)

Jon, Toerless:

-Hugh

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 10 Jun 2003 20:09:02 +0200 (MEST)

Sorry for one typo.

> SHOULD NOT send IGMPv1/v2 query in order to avoid that the host
                  ^^^^^^^^^^^^^^^IGMPv1/v2 General query
--
Hitoshi Asaeda
_______________________________________________
ssm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ssm

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 10 Jun 2003 20:09:02 +0200 (MEST)

Sorry for one typo.

---

From: Jean-Jacques Pansiot <[email-masked]>
Date: Tue, 10 Jun 2003 15:50:16 +0200

Jon Zeeff wrote:
> plugging in a machine running IGMPv2 and SSM breaks.  This probably 
> means that SSM is unimplementable except

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

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

---

From: Jean-Jacques Pansiot <[email-masked]>
Date: Tue, 10 Jun 2003 15:50:16 +0200

Hi

Jean-Jacques