Re: Question about IGMP host implementation

On 13.10.2011 18:44, Bharat Joshi wrote:
> Stig,
>
>         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 destin=
ation 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.

Stig

> Regards,
> Bharat
> ________________________________________
> From: [email protected] [[email protected]] On Behalf Of Stig V=
enaas [[email protected]]
> Sent: Thursday, October 13, 2011 10:40 PM
> To: Thomas Morin
> Cc: [email protected]
> Subject: Re: [magma] Question about IGMP host implementation
>
> On 10/13/2011 1:26 AM, Thomas Morin wrote:
>> Hi,
>>
>> 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 forge=
d 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
>>        option.
>>
>>      o Hosts SHOULD ignore v1, v2 or v3 General Queries sent to a
>>        multicast address other than 224.0.0.1, 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
>>      224.0.0.1, 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 Addr=
ess
>>             ^^^^^^^^^^^^^^^
>>       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...
>
> Stig
>
>>
>> -Thomas
>>
>>
>>
>> Bharat Joshi a =E9crit :
>>> Kunal,
>>>
>>>           What I am suggesting is that though RFC does not explicitly s=
uggest it, it might be better to do this for broadcast interfaces.
>>>
>>>           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.
>>>
>>> Regards,
>>> Bharat
>>> ________________________________________
>>> From: Kunal Shah [[email protected]]
>>> Sent: Wednesday, October 12, 2011 9:17 PM
>>> To: Bharat Joshi;[email protected]
>>> 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.
>>>
>>> Kunal
>>>
>>> -----Original Message-----
>>> From: Bharat Joshi [mailto:[email protected]]
>>> Sent: Wednesday, October 12, 2011 4:20 AM
>>> To: Kunal Shah;[email protected]
>>> Subject: RE: Question about IGMP host implementation
>>>
>>> Hi Kunal,
>>>
>>>           I think to keep the security tight, it is better to not respo=
nd to queries received from a source address which does not fall on a subne=
t on that interface. Please note that this should be done only broadcast in=
terfaces. 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.
>>>
>>> Regards,
>>> Bharat
>>> ________________________________________
>>> From:[email protected]  [[email protected]] On Behalf Of Kuna=
l Shah [[email protected]]
>>> Sent: Wednesday, October 12, 2011 6:08 AM
>>> To:[email protected]
>>> 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 Quer=
y)"
>>>
>>> There is no requirement for the source address to be on the same subnet=
 as the host.
>>>
>>> Thanks,
>>> Kunal
>>>
>>>
>>> **************** CAUTION - Disclaimer ***************** This e-mail con=
tains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use o=
f the addressee(s). If you are not the intended recipient, please notify th=
e 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 per=
son and any such actions are unlawful. This e-mail may contain viruses. Inf=
osys has taken every reasonable precaution to minimize this risk, but is no=
t 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 f=
rom this e-mail address may be stored on the Infosys e-mail system.
>>> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>>> _______________________________________________
>>> magma mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/magma
>>
>>
>>
>>
>> _______________________________________________
>> magma mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/magma
>
> _______________________________________________
> magma mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/magma