Re: [magma] Question about IGMP host implementation

Thomas Morin <thomas.morin@orange.com> Fri, 14 October 2011 08:01 UTC

Return-Path: <thomas.morin@orange.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 A5FE921F8ABB for <magma@ietfa.amsl.com>; Fri, 14 Oct 2011 01:01:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
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 ccUUlaRCYd1e for <magma@ietfa.amsl.com>; Fri, 14 Oct 2011 01:01:32 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id DB48521F84D7 for <magma@ietf.org>; Fri, 14 Oct 2011 01:01:31 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 98B79858002; Fri, 14 Oct 2011 10:11:10 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 906EA858001; Fri, 14 Oct 2011 10:11:10 +0200 (CEST)
Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 10:01:30 +0200
Received: from [10.193.71.92] ([10.193.71.92]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 10:01:29 +0200
Message-ID: <4E97EC5A.5020400@orange.com>
Date: Fri, 14 Oct 2011 10:01:30 +0200
From: Thomas Morin <thomas.morin@orange.com>
Organization: France Telecom Orange
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Hitoshi Asaeda <asaeda@sfc.wide.ad.jp>
References: <4E971B82.2090508@venaas.com> <31D55C4D55BEED48A4459EB64567589A1186EB24F0@BLRKECMBX02.ad.infosys.com> <4E97A191.3070800@venaas.com> <20111014.123740.41797110.asaeda@sfc.wide.ad.jp>
In-Reply-To: <20111014.123740.41797110.asaeda@sfc.wide.ad.jp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Oct 2011 08:01:29.0633 (UTC) FILETIME=[7AE96910:01CC8A47]
Cc: stig@venaas.com, 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 08:01:32 -0000

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