Re: [magma] Question about IGMP host implementation

Bharat Joshi <bharat_joshi@infosys.com> Wed, 12 October 2011 15:53 UTC

Return-Path: <bharat_joshi@infosys.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 9732F21F8B21 for <magma@ietfa.amsl.com>; Wed, 12 Oct 2011 08:53:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 uPqFn8w9M4Lu for <magma@ietfa.amsl.com>; Wed, 12 Oct 2011 08:53:29 -0700 (PDT)
Received: from KECGATE03.infosys.com (kecgate03.infosys.com [122.98.10.31]) by ietfa.amsl.com (Postfix) with ESMTP id BE58721F8B50 for <magma@ietf.org>; Wed, 12 Oct 2011 08:53:25 -0700 (PDT)
X-TM-IMSS-Message-ID: <dd2ad8b000042b59@infosys.com>
Received: from blrkechub04.ad.infosys.com ([10.66.236.44]) by infosys.com ([122.98.10.31]) with ESMTP (TREND IMSS SMTP Service 7.1) id dd2ad8b000042b59 ; Wed, 12 Oct 2011 21:22:09 +0530
Received: from BLRKECHUB05.ad.infosys.com (10.66.236.45) by blrkechub04.ad.infosys.com (10.66.236.44) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 12 Oct 2011 21:22:18 +0530
Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by BLRKECHUB05.ad.infosys.com ([10.66.236.45]) with mapi; Wed, 12 Oct 2011 21:22:17 +0530
From: Bharat Joshi <bharat_joshi@infosys.com>
To: Kunal Shah <kunal.shah@ericsson.com>, "magma@ietf.org" <magma@ietf.org>
Date: Wed, 12 Oct 2011 21:20:11 +0530
Thread-Topic: Question about IGMP host implementation
Thread-Index: AcyId0SCeinZjfcnSnCOOiiZpocqFgAWZnLtAAlSjLAAAB3mLg==
Message-ID: <31D55C4D55BEED48A4459EB64567589A1186EB24EB@BLRKECMBX02.ad.infosys.com>
References: <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3936@EUSAACMS0703.eamcs.ericsson.se> <31D55C4D55BEED48A4459EB64567589A1186EB24E9@BLRKECMBX02.ad.infosys.com>, <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3B7A@EUSAACMS0703.eamcs.ericsson.se>
In-Reply-To: <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3B7A@EUSAACMS0703.eamcs.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Wed, 12 Oct 2011 15:53:29 -0000

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