Multicast & Anycast Group Membership (magma)

headers Kunal Shah | 12 Oct 2011 02:38

_______________________________________________
magma mailing list
magma <at> ietf.org
https://www.ietf.org/mailman/listinfo/magma

_______________________________________________
magma mailing list
magma <at> ietf.org
https://www.ietf.org/mailman/listinfo/magma

_______________________________________________
magma mailing list
magma <at> ietf.org
https://www.ietf.org/mailman/listinfo/magma

_______________________________________________
magma mailing list
magma <at> ietf.org
https://www.ietf.org/mailman/listinfo/magma

How is a switch has two different subnets on its two ports? Typically switch divides the broadcast domain. Right?

Regards,
Bharat
________________________________________
From: magma-bounces <at> ietf.org [magma-bounces <at> ietf.org] On Behalf Of Indranil Bhattacharya [myselfindranil <at> gmail.com]
Sent: Wednesday, October 12, 2011 2:05 PM
To: Kunal Shah
Cc: magma <at> ietf.org
Subject: Re: [magma] Question about IGMP host implementation

Hi Kunal,

             Yes it should. The scenario that I have in mind is a switch whose mrouter interface is in vlanA and igmp joins
are received on an interface in vlanB. In this case, query coming from vlanA(different subnet) has to be
answered by hosts in vlanB.

Thanks,
Indranil

On Wed, Oct 12, 2011 at 6:08 AM, Kunal Shah
<kunal.shah <at> ericsson.com<mailto:kunal.shah <at> ericsson.com>> wrote:
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.

Thanks,
Kunal

_______________________________________________
magma mailing list
magma <at> ietf.org<mailto:magma <at> ietf.org>
https://www.ietf.org/mailman/listinfo/magma

**************** 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
https://www.ietf.org/mailman/listinfo/magma

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.

Regards,
Bharat
________________________________________
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.

Thanks,
Kunal

**************** 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***

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: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.

Regards,
Bharat
________________________________________
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.

Thanks,
Kunal

**************** 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***

Kunal,

        What I am suggesting is that though RFC does not explicitly suggest 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 [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.

Kunal

-----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.

Regards,
Bharat
________________________________________
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.

Thanks,
Kunal

**************** 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
https://www.ietf.org/mailman/listinfo/magma

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 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
>       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 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...

Stig

>
> -Thomas
>
>
>
> Bharat Joshi a écrit :
>> Kunal,
>>
>>          What I am suggesting is that though RFC does not explicitly suggest 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 [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.
>>
>> Kunal
>>
>> -----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.
>>
>> Regards,
>> Bharat
>> ________________________________________
>> 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.
>>
>> Thanks,
>> Kunal
>>
>>
>> **************** 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
>> https://www.ietf.org/mailman/listinfo/magma
>
>
>
>
> _______________________________________________
> magma mailing list
> magma <at> ietf.org
> https://www.ietf.org/mailman/listinfo/magma

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 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.,

Regards,
Bharat
________________________________________
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:
> 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 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
>       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 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...

Stig

>
> -Thomas
>
>
>
> Bharat Joshi a écrit :
>> Kunal,
>>
>>          What I am suggesting is that though RFC does not explicitly suggest 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 [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.
>>
>> Kunal
>>
>> -----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.
>>
>> Regards,
>> Bharat
>> ________________________________________
>> 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.
>>
>> Thanks,
>> Kunal
>>
>>
>> **************** 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
>> https://www.ietf.org/mailman/listinfo/magma
>
>
>
>
> _______________________________________________
> magma mailing list
> magma <at> ietf.org
> https://www.ietf.org/mailman/listinfo/magma

_______________________________________________
magma mailing list
magma <at> ietf.org
https://www.ietf.org/mailman/listinfo/magma

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 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.

Stig

> Regards,
> Bharat
> ________________________________________
> 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:
>> 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 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
>>        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 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...
>
> Stig
>
>>
>> -Thomas
>>
>>
>>
>> Bharat Joshi a écrit :
>>> Kunal,
>>>
>>>           What I am suggesting is that though RFC does not explicitly suggest 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 [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.
>>>
>>> Kunal
>>>
>>> -----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.
>>>
>>> Regards,
>>> Bharat
>>> ________________________________________
>>> 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.
>>>
>>> Thanks,
>>> Kunal
>>>
>>>
>>> **************** 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
>>> https://www.ietf.org/mailman/listinfo/magma
>>
>>
>>
>>
>> _______________________________________________
>> magma mailing list
>> magma <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/magma
>
> _______________________________________________
> magma mailing list
> magma <at> ietf.org
> https://www.ietf.org/mailman/listinfo/magma

>>         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.

I think using unicast query is not well defined and considered in
rfc3376 and 3810.
Although it would be useful for some environment, e.g. resource
sensitive wireless link, it may cause some security concern. And also,
unicast query is not used standalone. Multicast query must be also
coexist.
Please check Appendix A. in;
http://tools.ietf.org/html/draft-ietf-multimob-igmp-mld-tuning-01

Regards,
--
Hitoshi Asaeda

p.s. I'd appreciate any comment for above draft. Please post your
comment to the multimob ML if you have.

2011-10-14, Hitoshi Asaeda:
 >Stig:
 >>Barat:
>>>          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.
>
> I think using unicast query is not well defined and considered in
> rfc3376 and 3810.

It may or may not be the same as the one Stig knows, but I also know 
about one equipment that has a useful feature that relies on this.

> Although it would be useful for some environment, e.g. resource
> sensitive wireless link, it may cause some security concern.

Well, even if no Querier would use it, an IGMP host implementation may 
accept them. So it seems to me that working on this issue, or even 
encouraging the use of unicasted Queries, does not make any problem 
worse. Documenting how to do GTSM with IGMP would somehow improve security.

> And also, unicast query is not used standalone. Multicast query must be also
> coexist.
>

There are context where you could use only unicasted Queries.

-Thomas

>> I think using unicast query is not well defined and considered in
>> rfc3376 and 3810.
> 
> It may or may not be the same as the one Stig knows, but I also know
> about one equipment that has a useful feature that relies on this.

RFC3376 and 3810 do not disallow unicast query. I said that it is
useful for some condition, but it is not generally used and should've
been more precisely specified in these RFCs.

>> Although it would be useful for some environment, e.g. resource
>> sensitive wireless link, it may cause some security concern.
> 
> Well, even if no Querier would use it, an IGMP host implementation may
> accept them.

Because these RFCs do not disallow unicast query, hosts may accept
it. I don't deny this possibility. But the question is whether such
host implementation is (or should be) common or not.

> So it seems to me that working on this issue, or even
> encouraging the use of unicasted Queries, does not make any problem
> worse. Documenting how to do GTSM with IGMP would somehow improve
> security.

GTSM or some other technique should be used together if you use
unicast query secure. The point we need to know is there is no such
requirement mentioned in these RFCs.

>> And also, unicast query is not used standalone. Multicast query must
>> be also
>> coexist.
> 
> There are context where you could use only unicasted Queries.

I don't know. Please read Appendix A in the following IGMP/MLD tuning
draft,
http://tools.ietf.org/html/draft-ietf-multimob-igmp-mld-tuning-01

and if you have comments for this draft, please tell us or post to the
ML. Thank you.

Regards,
--
Hitoshi Asaeda

_______________________________________________
magma mailing list
magma <at> ietf.org
https://www.ietf.org/mailman/listinfo/magma

Question about IGMP host implementation

Re: Question about IGMP host implementation

Re: Question about IGMP host implementation

Re: Question about IGMP host implementation

Re: Question about IGMP host implementation

Re: Question about IGMP host implementation

Re: Question about IGMP host implementation

Re: Question about IGMP host implementation

Re: Question about IGMP host implementation

Re: Question about IGMP host implementation

Re: Question about IGMP host implementation

Re: Question about IGMP host implementation

Re: Question about IGMP host implementation

Re: Question about IGMP host implementation

Re: Question about IGMP host implementation

Re: Question about IGMP host implementation

Re: Question about IGMP host implementation