Subject: [magma] IGMPv2 and IGMPv1 checksum verification

From: Pavlin Radoslavov <[email-masked]>
Date: Mon, 06 Jun 2005 17:21:23 -0700

The IGMPv2 checksum (as defined in RFC-2236) is calculated over the
whole IGMP message even if it is longer than 8 octets.

However, RFC-1112 defines the IGMPv1 checksum as:

"The checksum is the 16-bit one's complement of the one's complement
sum of the 8-octet IGMP message."

The above text could be interpretated that if the IGMPv1 message is
longer than 8 octets, the checksum should be calculated over the
first 8 octets only.

This creates some ambiguity about what the checksum verification
for IGMPv1 messages that happen to be longer than 8 octets should
be: over the first 8 octets only or over the whole message.

Someone may argue that an IGMPv1 message cannot be longer than 8
octets, but RFC-1112 says that "[Query | Report] message must be at
least 8 octets long" hence implementations must be prepared to deal
with longer messages.

More than 2 years ago I asked a similar question, but for a
different reason
(http://www1.ietf.org/mail-archive/web/magma/current/msg00298.html),
and some of the replies were that calculating the checksum over only
the first 8 octets doesn't seem right, and the checksum should cover
the whole message same way it is defined for IGMPv2 (which I agree
with).

If we are to "Be liberal in what you accept, and conservative in
what you send", then an IGMP router-side implementation
would accept IGMPv1 messages that have valid checkum over either
(a) the whole IGMP payload
OR
(b) only the first 8 octets.

The reason I ask again this IGMPv1-related checksum question is the
following.
I am aware of a public IGMP testsuite document that actually tests
that an IGMP router implementation rejects IGMPv1 report messages
received with invalid IGMPv1 checksum that is actually a valid
IGMPv2 checksum.
Vice-versa, it also tests that a router rejects IGMPv2 reports with
invalid IGMPv2 checksum that is actually a valid IGMPv1 checksum.
[The only meaningful interpretation of valid/invalid IGMPv1/v2
checksum I see in the above context is that they use IGMPv1/v2
messages that are longer than 8 octets, and then they play with how
many octets are covered by the checksum.]

Hence, I am trying to figure-out how appropriate the above tests
are, because it appears the testsuite has chosen a particular
interpretation of what the IGMPv1 checksum should cover and the
testsuite will fail even implementations that have more liberal
interpretation of the spec.

In other words, I need the MAGMA WG input if I am to attempt to
convince the testsuite authors to modify their tests.

Pavlin

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

---

From: Brian Haberman <[email-masked]>
Date: Tue, 7 Jun 2005 10:39:37 -0400

Hi Pavlin,

> sum of the 8-octet IGMP message."

Yes, that is what it says.

> least 8 octets long" hence implementations must be prepared to deal

Yes.  It appears to be ambiguous within RFC 1112.

> the whole message same way it is defined for IGMPv2 (which I agree

I agree as well.

> (b) only the first 8 octets.

I do not know of any implementations that have this flexibility in
them.

> many octets are covered by the checksum.]

Can you provide pointers to this testsuite?

> convince the testsuite authors to modify their tests.

I would put forth that the IGMPv2 style checksum is the correct 
behavior.
Having the checksum protect the entire message, even if the node
cannot parse all of it, is necessary for backwards compatibility 
features
within IGMPv2 and IGMPv3.

Since the query message type has always been 0x11, an IGMPv1
host should be able to correctly parse a General Query from an IGMPv3
router.

This also begs a question for implementors.  How many IGMPv1 code
bases limit the checksum calculation to the first 8 octets?  And a
follow-on: How many have separate logic for checksum calculation
for backwards compatibility to IGMPv1?

Regards,
Brian

---

From: Pavlin Radoslavov <[email-masked]>
Date: Tue, 07 Jun 2005 16:12:53 -0700

> Can you provide pointers to this testsuite?

You can put the following keywords in Google (no quotes):
IGMP revision test suite

The testsuite is one of the top ten matches :)
The particular tests in question are 1.2 (esp. Part B), test 2.8
(Parts A, B), and test 2.9 (Part B).

> within IGMPv2 and IGMPv3.

I agree. This is how it is specified in RFC-2236. Only after I came
across the above testsuite and only after careful reading of
RFC-1112 it became obvious to me that the RFC-1112 wording leaves
space for ambiguity.

> for backwards compatibility to IGMPv1?

Good questions.

If I don't get a clear answer from the WG or if I fail to convince
the testsuite authors on the subject, then there will be at least
one implementation with separate logic for checksum calculation.
I don't like such logic, so it will be configurable by
"igmpv1-8octets-only-checksum" configuration switch :)

Thanks,
Pavlin