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
- [magma] Question about IGMP host implementation Kunal Shah
- Re: [magma] Question about IGMP host implementati… Indranil Bhattacharya
- Re: [magma] Question about IGMP host implementati… Beeram, Suresh KumarReddy
- Re: [magma] Question about IGMP host implementati… Bharat Joshi
- Re: [magma] Question about IGMP host implementati… Bharat Joshi
- Re: [magma] Question about IGMP host implementati… Indranil Bhattacharya
- Re: [magma] Question about IGMP host implementati… Indranil Bhattacharya
- Re: [magma] Question about IGMP host implementati… Kunal Shah
- Re: [magma] Question about IGMP host implementati… Bharat Joshi
- Re: [magma] Question about IGMP host implementati… Thomas Morin
- Re: [magma] Question about IGMP host implementati… Stig Venaas
- Re: [magma] Question about IGMP host implementati… Bharat Joshi
- Re: [magma] Question about IGMP host implementati… Stig Venaas
- Re: [magma] Question about IGMP host implementati… Hitoshi Asaeda
- Re: [magma] Question about IGMP host implementati… Thomas Morin
- Re: [magma] Question about IGMP host implementati… V, Magesh (Magesh)
- Re: [magma] Question about IGMP host implementati… Hitoshi Asaeda