Subject: RE: [magma] draft-holbrook-idmr-igmpv3-ssm-07.txt

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 28 Jul 2004 14:40:28 -0400

> > How does one differentiate between an IGMPv1, v2, or v3 
> query, e.g. in the case
> > of all hosts (general) queries?
> 
> 
> The determination is based on the packet length and the MaxRespCode
> field (second byte).  v1 general queries are 8 bytes and have a zero
> MaxRespCode.-- it was unused in RFC1112 and required to be set to 0.
> v2 queries are 8 bytes and have a non-zero MaxRespCode.  v3 queries
> are 12 bytes.  This is (sort of) summarized in section 7 of RFC3376
> (IGMPv3).
> 
> Section 7 of RFC3376 has lots of references to text like "If an IGMPv1
> general query is heard...".

Hi Hugh. I guess my questions are more with interpreting RFCs 2236/3376 than with your draft. These comments are in line with the types of modifications or clarifications you have described in your draft. I don't think any of what follows does much more than potentially simplify the wording of RFC 2236 and 3376. I've boiled the issues down to this:

As I read it, there should be no way of telling the difference, in principle, between perfectly legitimate IGMPv1 and IGMPv2 queries. The max response code entry can be set to 0 for either of these, and is to be interpreted as 10 seconds when the code is set to 0. Similarly, IGMPv3 queries can have everything after the multicast group filled with 0s (even though the extra four bytes would still be transmitted).

It just seems much more straightforward to base the decision on which IGMP or MLD version to use not on the queries but on the format of reports received. Since the reports are multicast to all group members, all group members will know what is the lowest version report being used by membership of that group. So will the router know. And this would be group by group. The hosts and router can set a state variable, with timer, group-specific, to ensure that hosts send the reports in the correct format for each of their group memberships, and routers filter based on the appropriate semantics.

Since the general query will elicit a series of reports, a basic default query (i.e. one that looks like IGMPv1 or MLDv1) from the router can establish everything the router and hosts need to know about what version of IGMP to use for each multicast group. Even if, for a particular group, two hosts almost simultaneously respond with two different report versions, the lower-version host will soon win out. The lower-version host will not decipher the higher version reports and will therefore always respond to subsequent queries. It will soon be obvious to hosts and routers that the lower version of IGMP/MLD is to be used for that group.

If, for some bizarre reason, a host sends a report to the router's IP address, the router would still know what the lowest common denominator is for the membership of that group, and will therefore know what semantics to accept as filtering criteria and what type of queries are legit for that specific group. And since each host must be capable of operating in compatibility mode, no query for that group should ever be undecipherable.

I agree with what you say about misconfigurartion or security concerns. You might want to force a particular IGMP or MLD version, to prevent a malicious host from denying use of SSM filtering. Just that it seems unnecessary in general to base this scheme on the format of the query. I agree that your wording follows the RFCs. I'm just not sure why the query-dependent paradigm can't be simplified.

Bert

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: Hugh Holbrook <[email-masked]>
Date: Wed, 28 Jul 2004 23:28:16 -0700 (PDT)

> Hi Hugh. I guess my questions are more with interpreting RFCs 2236/3376 than
> with your draft. These comments are in line with the types of modifications or
> clarifications you have described in your draft. I don't think any of what
> follows does much more than potentially simplify the wording of RFC 2236 and
> 3376. I've boiled the issues down to this:
> 
> As I read it, there should be no way of telling the difference, in principle,
> between perfectly legitimate IGMPv1 and IGMPv2 queries. The max response code
> entry can be set to 0 for either of these, and is to be interpreted as 10
> seconds when the code is set to 0. Similarly, IGMPv3 queries can have
> everything after the multicast group filled with 0s (even though the extra four
> bytes would still be transmitted).

Hi, Bert.

RFC2236 doesn't say this that you must not put 0 as the Max Response
Code but it probably should.  If an IGMPv2-speaking router did put 0
in, then all hosts on the LAN would interpret that as an IGMPv1 query
(according to the logic in RFC2236) and revert to v1 compatibility
mode.  So this would not be a good idea, and I really doubt anyone
does this.  I suspect this is a hole in the IGMPv2 spec if it is
allowed at all; maybe Bill remembers this.  A host's IP stack can use
the packet length to identify the IGMPv3 packet even if the data is
zeroed out.  Kinda hacky, but that's how it is.

> It just seems much more straightforward to base the decision on which IGMP or
> MLD version to use not on the queries but on the format of reports
> received. Since the reports are multicast to all group members, all group

Which version of the protocol the router can understand is also a
property of the router version, not just a property of the other
hosts.  An single IGMPv3 host alone on a LAN with an IGMPv1 router
will work if using the logic in RFC2236/3378, but in the scheme you
describe, I don't see how it would.  The host would have no idea that
the router was speaking IGMPv1.

> members will know what is the lowest version report being used by membership of
> that group. So will the router know. And this would be group by group. The
> hosts and router can set a state variable, with timer, group-specific, to
> ensure that hosts send the reports in the correct format for each of their
> group memberships, and routers filter based on the appropriate semantics.

IGMPv3 reports are not sent to all group members, so you wouldn't see
those.  That may not be a problem now, but your scheme breaks as soon
as IGMPv4 is invented.  And practically speaking, IGMP snooping
switches are fairly widespread in many environments, and they prevent
reports from being sent to other hosts on the same LAN, so that would
also break this scheme.

Do you still think a change is warranted?

-Hugh

> Since the general query will elicit a series of reports, a basic default query
> (i.e. one that looks like IGMPv1 or MLDv1) from the router can establish
> everything the router and hosts need to know about what version of IGMP to use
> for each multicast group. Even if, for a particular group, two hosts almost
> simultaneously respond with two different report versions, the lower-version
> host will soon win out. The lower-version host will not decipher the higher
> version reports and will therefore always respond to subsequent queries. It
> will soon be obvious to hosts and routers that the lower version of IGMP/MLD is
> to be used for that group.
> 
> If, for some bizarre reason, a host sends a report to the router's IP address,
> the router would still know what the lowest common denominator is for the
> membership of that group, and will therefore know what semantics to accept as
> filtering criteria and what type of queries are legit for that specific
> group. And since each host must be capable of operating in compatibility mode,
> no query for that group should ever be undecipherable.
> 
> I agree with what you say about misconfigurartion or security concerns. You
> might want to force a particular IGMP or MLD version, to prevent a malicious
> host from denying use of SSM filtering. Just that it seems unnecessary in
> general to base this scheme on the format of the query. I agree that your
> wording follows the RFCs. I'm just not sure why the query-dependent paradigm
> can't be simplified.
> 
> Bert
>