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

[Toerless Eckert <[e-mail]>]

On Tue, Jun 10, 2003 at 09:04:52AM -0400, 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).

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.
> 
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ssm