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

[Hugh Holbrook <holbrook@cisco.com>]

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 ...).
> 
> 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
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm