I agree with everything you've said. But my point really was geared to, what does the spec say, and how do router implementations handle things. To quote RFC 2236 - "send report" for the group on the interface. The type of report is determined by the state of the interface. The Report Message is sent to the group being reported. I think a router COULD reject an IGMP membership report for group G1 that was actually delivered on group G2. I don't know that any do, but that would seem to still be a compliant implementation. If a router were to implement this policy, then the host implementations must implement an equally strict policy, or else a DOS scenario can arise. I recommended that the host implementation be modified to implement this more strict check because the only negative side effect would be a few extra membership reports and leave messages. Otherwise, perhaps it should be documented that it really doesn't matter to what group membership reports are destined to. That would seem to correctly characterize current host/router implementations. Marty Schoch <mschoch@multicasttech.com> On 6/14/02 7:49 PM, "Nick Roffey" <nick@4thline.net> wrote: > Might be that I'm missing something here, but.... > > In the scenario mentioned, since the IGMP report is still addressed > to a group, any attached routers will receive it, which means they'll > continue to know there's at least one group member on the subnet and > carry on forwarding multicast traffic. > > IGMP doesn't have any effect on what a host recieves or doesn't - > as long as there's at least one member of a multicast group on > a particular segment sending IGMP reports, an attached router will > continue to forward multicast traffic, which all hosts will receive. > > CGMP, which limits multicast forwarding on switches to the ports that > have multicast group members on them, also from my documentation does > not seem to be affected. There appears to be no facility for a single > host to 'leave' via CGMP or to time out - as I understand it, only an > attached router can 'leave' CGMP - done when all IGMP group members have > left or timed out, which deletes the switch state for all members of the > > group. My documentation might be out of date, but it appears that once > a group member is known to CGMP, that switch port will continue to > receive multicast traffic until all group members have gone from the > network. > > The result - the only situation where a DOS could be possible is when > the multicast sender and receiver are on different subnets AND the > multicast receiver is the only group member on that subnet. > > Having said all that, unlikely though it is that this will cause any > major problems, accepting IGMP packets that are not addressed to a > group is pretty poor! > > Nick > > > > > -----Original Message----- > From: Arun D. Qamra [mailto:arun@cs.ucsb.edu] > Sent: 14 June 2002 23:21 > To: Marty Schoch > Cc: bugtraq@securityfocus.com > Subject: Re: IGMP denial of service vulnerability > > > > Thats an interesting scenario. We did test the same, and DOS doesnt take > place, atleast in our test setup. > > In our setup, the router (a Cisco 2514 running IOS ver12.0 in our case) > does process such a report in the scenario you suggested. > > However we agree that the code should be tightened, in all systems. > > > On 14 Jun 2002, Marty Schoch wrote: > >> >> Solution >> --------- >> All IGMP packets that are not multicast ethernet addresses should be >> dropped. > > Depending on the implementation of router R in linked document, couldn't > there still be a problem in the following scenario. > > Host H1 is a member of two groups 230.0.0.1 and 230.0.0.2 > Host H2 sends a membership report for group 230.0.0.1 to group > 230.0.0.2. > > Host H1 will obviously see this report as well. > Looking briefly at the code it appears host H1 may still consider this > an acceptable report from another host. If, and I haven't tested any > router configurations, router R does not consider this a valid report > for the group 230.0.0.1 then the same DOS effect may occur. > > The RFC says that membership reports should be sent to the group for > which the report applies. Why not tighten the code down all the way, to > check not just that the report is multicast, but that all the addresses > match. > > Marty Schoch > <mschoch@multicasttech.com> > > >
