Re: [magma] Question about IGMP host implementation

Hitoshi Asaeda <asaeda@sfc.wide.ad.jp> Sat, 15 October 2011 17:00 UTC

Return-Path: <asaeda@sfc.wide.ad.jp>
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 332D221F84A9 for <magma@ietfa.amsl.com>; Sat, 15 Oct 2011 10:00:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.096
X-Spam-Level:
X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, 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 CeVcaXozzAQJ for <magma@ietfa.amsl.com>; Sat, 15 Oct 2011 10:00:49 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id B60C321F84A7 for <magma@ietf.org>; Sat, 15 Oct 2011 10:00:48 -0700 (PDT)
Received: from localhost (p16206-ipngn201hodogaya.kanagawa.ocn.ne.jp [114.175.255.206]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id BCD952780C2; Sun, 16 Oct 2011 02:00:17 +0900 (JST)
Date: Sun, 16 Oct 2011 02:00:17 +0900 (JST)
Message-Id: <20111016.020017.99553331.asaeda@sfc.wide.ad.jp>
To: thomas.morin@orange.com
From: Hitoshi Asaeda <asaeda@sfc.wide.ad.jp>
In-Reply-To: <4E97EC5A.5020400@orange.com>
References: <4E97A191.3070800@venaas.com> <20111014.123740.41797110.asaeda@sfc.wide.ad.jp> <4E97EC5A.5020400@orange.com>
X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: 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: Sat, 15 Oct 2011 17:00:50 -0000

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