Re: [magma] Question about IGMP host implementation

Stig Venaas <stig@venaas.com> Fri, 14 October 2011 02:43 UTC

Return-Path: <stig@venaas.com>
X-Original-To: magma@ietfa.amsl.com
Delivered-To: magma@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4040E21F8B7E for <magma@ietfa.amsl.com>; Thu, 13 Oct 2011 19:43:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKzdY00hsHxe for <magma@ietfa.amsl.com>; Thu, 13 Oct 2011 19:43:26 -0700 (PDT)
Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFC821F8B33 for <magma@ietf.org>; Thu, 13 Oct 2011 19:43:26 -0700 (PDT)
Received: from [192.168.1.107] (c-67-170-194-177.hsd1.ca.comcast.net [67.170.194.177]) by ufisa.uninett.no (Postfix) with ESMTPSA id E5FD57FE2; Fri, 14 Oct 2011 04:43:21 +0200 (CEST)
Message-ID: <4E97A191.3070800@venaas.com>
Date: Thu, 13 Oct 2011 19:42:25 -0700
From: Stig Venaas <stig@venaas.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Bharat Joshi <bharat_joshi@infosys.com>
References: <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3936@EUSAACMS0703.eamcs.ericsson.se> <31D55C4D55BEED48A4459EB64567589A1186EB24E9@BLRKECMBX02.ad.infosys.com>, <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3B7A@EUSAACMS0703.eamcs.ericsson.se> <31D55C4D55BEED48A4459EB64567589A1186EB24EB@BLRKECMBX02.ad.infosys.com> <4E96A0C3.9010602@orange.com>, <4E971B82.2090508@venaas.com> <31D55C4D55BEED48A4459EB64567589A1186EB24F0@BLRKECMBX02.ad.infosys.com>
In-Reply-To: <31D55C4D55BEED48A4459EB64567589A1186EB24F0@BLRKECMBX02.ad.infosys.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: Thomas Morin <thomas.morin@orange.com>, "magma@ietf.org" <magma@ietf.org>
Subject: Re: [magma] Question about IGMP host implementation
X-BeenThere: magma@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/magma>, <mailto:magma-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/magma>
List-Post: <mailto:magma@ietf.org>
List-Help: <mailto:magma-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Oct 2011 02:43:27 -0000

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@ietf.org [magma-bounces@ietf.org] On Behalf Of Stig Venaas [stig@venaas.com]
> Sent: Thursday, October 13, 2011 10:40 PM
> To: Thomas Morin
> Cc: magma@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@ericsson.com]
>>> Sent: Wednesday, October 12, 2011 9:17 PM
>>> To: Bharat Joshi;magma@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@infosys.com]
>>> Sent: Wednesday, October 12, 2011 4:20 AM
>>> To: Kunal Shah;magma@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@ietf.org  [magma-bounces@ietf.org] On Behalf Of Kunal Shah [kunal.shah@ericsson.com]
>>> Sent: Wednesday, October 12, 2011 6:08 AM
>>> To:magma@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@ietf.org
>>> https://www.ietf.org/mailman/listinfo/magma
>>
>>
>>
>>
>> _______________________________________________
>> magma mailing list
>> magma@ietf.org
>> https://www.ietf.org/mailman/listinfo/magma
>
> _______________________________________________
> magma mailing list
> magma@ietf.org
> https://www.ietf.org/mailman/listinfo/magma