Re: Question about IGMP host implementation
Stig Venaas <stig <at> venaas.com>
2011-10-14 02:42:25 GMT
On 13.10.2011 18:44, Bharat Joshi wrote:
> I think GTSM does solve the issue of forwarding IGMP messages but as you mentioned its only for unicast.
> Till now, I have not seen any implementation using Unicast destination address for IGMP messages. So I am
not sure if someone will really be interested in this work.
> May be there are some legacy or customized implementation which I am not aware of and we need to see if these
people would be interested in this.,
I know one implementation at least. But note that even if no one sends
them, the RFC says they should be accepted. So we do have a problem if
someone intentionally spoofs unicast packet.
If almost no one sends them, then changing to GTSM will be easier.
> From: magma-bounces <at> ietf.org [magma-bounces <at> ietf.org] On Behalf Of Stig Venaas [stig <at> venaas.com]
> Sent: Thursday, October 13, 2011 10:40 PM
> To: Thomas Morin
> Cc: magma <at> ietf.org
> Subject: Re: [magma] Question about IGMP host implementation
> On 10/13/2011 1:26 AM, Thomas Morin wrote:
>> Obviously there is no legitimate case where a query would come from
>> another subnet.
>> The question is how to avoiding such queries from being processed...
>> IGMPv3 specs talks a bit about this aspect ; RFC3376, section 9.1,
>> Security Considerations, Query message:
>> There are three measures necessary to defend against externally forged Queries:
>> o Routers SHOULD NOT forward Queries. This is easier for a router to
>> accomplish if the Query carries the Router-Alert option.
>> o Hosts SHOULD ignore v2 or v3 Queries without the Router-Alert
>> o Hosts SHOULD ignore v1, v2 or v3 General Queries sent to a
>> multicast address other than 220.127.116.11, the all-systems address.
>> If a host enforces these rules, AFAICT there is no case were it would
>> process a Query from another subnet.
>> Even though RFC2236 is silent on this aspect, an RFC3376 host
>> implementation in IGMPv2 compatibility mode would be expected to apply
>> these checks.
>> On the other hand, RFC3376 also says, in 4.1.12. IP Destination
>> Addresses for Queries:
>> In IGMPv3, General Queries are sent with an IP destination address of
>> 18.104.22.168, the all-systems multicast address. Group-Specific and
>> Group-and-Source-Specific Queries are sent with an IP destination
>> address equal to the multicast address of interest. *However*, a
>> system MUST accept and process any Query whose IP Destination Address
>> field contains *any* of the addresses (unicast or multicast)
>> assigned to the interface on which the Query arrives.
>> This rule contradicts the third rule above (which would in itself
>> deserve a discussion), but the two first rules are possibly enough: if
>> an attacker forges a Query, under the assumption that at least one
>> Router on the path to the victim supports the Router Alert option and
>> implements IGMP and enforces the first of the three rules above, if
>> hosts apply the second rule, then no forged packet will be processed by
>> hosts... The issue is that it may not be reasonable to count on all this
>> to be true (eg. there are IGMP Querier implementations in the wild that
>> do not set the RA option in Query messages...).
>> The most reasonable thing to do, as suggested below, is to drop Queries
>> whose source address is from another subnet.
>> A nicer solution would be to apply GTSM (RFC5082) to IGMP, but
>> transitioning to it is absolutely not trivial.
> Yes, I have been thinking whether GTSM should be used for unicast IGMPv3
> messages. I don't think transitioning to that is all that hard. It
> depends a bit how common it is to do unicast IGMP today. Checking GTSM
> on the receiving end would have to be something that can be configured
> until one can expect all senders to do it.
> If there is some support for GTSM, we could try a draft updating the
> IGMPv3 RFC perhaps...
>> Bharat Joshi a écrit :
>>> What I am suggesting is that though RFC does not explicitly suggest it, it might be better to do this for
>>> But yes, RFC does not suggest anything on this so a host can process a query message with a source address
from any other subnet as well.
>>> From: Kunal Shah [kunal.shah <at> ericsson.com]
>>> Sent: Wednesday, October 12, 2011 9:17 PM
>>> To: Bharat Joshi;magma <at> ietf.org
>>> Subject: RE: Question about IGMP host implementation
>>> Hi Bharat,
>>> The security consideration addresses the processing of a report from a different subnet on the router.
My question pertains to the processing of a Query from a different subnet on the host.
>>> -----Original Message-----
>>> From: Bharat Joshi [mailto:bharat_joshi <at> infosys.com]
>>> Sent: Wednesday, October 12, 2011 4:20 AM
>>> To: Kunal Shah;magma <at> ietf.org
>>> Subject: RE: Question about IGMP host implementation
>>> Hi Kunal,
>>> I think to keep the security tight, it is better to not respond to queries received from a source address
which does not fall on a subnet on that interface. Please note that this should be done only broadcast
interfaces. It may not work on point-to-point links.
>>> If you look at the security consideration in RFC 2236, it is mentioned that for reports, the above check
should be done.
>>> From:magma-bounces <at> ietf.org [magma-bounces <at> ietf.org] On Behalf Of Kunal Shah [kunal.shah <at> ericsson.com]
>>> Sent: Wednesday, October 12, 2011 6:08 AM
>>> To:magma <at> ietf.org
>>> Subject: [magma] Question about IGMP host implementation
>>> Hi all,
>>> Can an IGMPv2 host respond to a general query originated from a subnet other then its own?? RFC 2236 states:
>>> ""query received" occurs when the host receives either a valid
>>> General Membership Query message, or a valid Group-Specific
>>> Membership Query message. To be valid, the Query message must be
>>> at least 8 octets long, and have a correct IGMP checksum. The
>>> group address in the IGMP header must either be zero (a General
>>> Query) or a valid multicast group address (a Group-Specific Query)"
>>> There is no requirement for the source address to be on the same subnet as the host.
>>> **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND
CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended
recipient, please notify the sender by e-mail and delete the original message. Further, you are not to
copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are
unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize
this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should
carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to
monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from
this e-mail address may be stored on the Infosys e-mail system.
>>> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>>> magma mailing list
>>> magma <at> ietf.org
>> magma mailing list
>> magma <at> ietf.org
> magma mailing list
> magma <at> ietf.org