Re: [MSEC] Review of draft-ietf-msec-tesla-for-alc-norm-05.txt

Vincent Roca <vincent.roca@inrialpes.fr> Fri, 24 October 2008 08:38 UTC

Return-Path: <msec-bounces@ietf.org>
X-Original-To: msec-archive@lists.ietf.org
Delivered-To: ietfarch-msec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D878A3A688E; Fri, 24 Oct 2008 01:38:27 -0700 (PDT)
X-Original-To: msec@core3.amsl.com
Delivered-To: msec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFF7F3A688E for <msec@core3.amsl.com>; Fri, 24 Oct 2008 01:38:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level:
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-zb4Fh9mT0J for <msec@core3.amsl.com>; Fri, 24 Oct 2008 01:38:26 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id BC71C3A6844 for <msec@ietf.org>; Fri, 24 Oct 2008 01:38:25 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,476,1220220000"; d="scan'208";a="18450739"
Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Oct 2008 10:39:45 +0200
Message-ID: <490189D0.7030305@inrialpes.fr>
Date: Fri, 24 Oct 2008 10:39:44 +0200
From: Vincent Roca <vincent.roca@inrialpes.fr>
User-Agent: Thunderbird 2.0.0.16 (X11/20080724)
MIME-Version: 1.0
To: L.Liang@surrey.ac.uk
References: <9AAD79EF034F824CA410417194F5F987097ACB@EVS-EC1-NODE1.surrey.ac.uk>
In-Reply-To: <9AAD79EF034F824CA410417194F5F987097ACB@EVS-EC1-NODE1.surrey.ac.uk>
X-Enigmail-Version: 0.95.0
Cc: H.Cruickshank@surrey.ac.uk, msec@ietf.org, vincent.roca@inria.fr, aurelien.francillon@inria.fr, faurite@lcpc.fr
Subject: Re: [MSEC] Review of draft-ietf-msec-tesla-for-alc-norm-05.txt
X-BeenThere: msec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast Security List <msec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/msec>, <mailto:msec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/msec>
List-Post: <mailto:msec@ietf.org>
List-Help: <mailto:msec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/msec>, <mailto:msec-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: msec-bounces@ietf.org
Errors-To: msec-bounces@ietf.org

Dear Lei,

Thanks a lot for your interest in TESLA and support.

Concerning your proposal, we don't agree with your idea,
but maybe we can discuss this offline.

Best regards,

  Vincent


L.Liang@surrey.ac.uk wrote:
> Dear Vincent, Aurelien and Faurite,
>   My name is Lei Liang from University of surrey, UK. As my colleague
> Dr. Haitham Cruickshank talked with Vincent in the last IETF meeting, we
> are working on a new TESLA synchronization method while integrating with
> FLUTE, which is built on ALC, in a UK EPSRC project called
> Satellite-Based Secure Multicast employing Hybrid Reliability. We think
> your ID is definitely very interesting and we used it as a very
> important reference in our study. So you have our support here :).
>   The new synchronization method we proposed is trying to eliminate the
> bidirectional channel requested by the direct synchronization as stated
> in the TESLA RFC because the ALC does not need it, especially in a
> satellite network. It is trying to take use of the FDT function in the
> FLUTE protocol to deliver the TESLA bootstrapping message and the
> information needed for synchronization. This can be achieved as long as
> the FDT is periodically broadcasted or mulicasted to a well-known
> address. This synchronization information is not a strong overhead but
> the interval index in which the source is when sending the bootstrapping
> message. It can also solve the scalability problem on the source when
> the multicast group is big. We published our initial study in ICC'2008
> and are implementing and validating the method now. Please find the
> enclosed pdf version of the paper that has the detailed description. 
>   I hope it can provide some useful thought for your ID and your
> comments are more than welcome.
> 
> 
> Best regards,
> 
> Lei Liang

_______________________________________________
MSEC mailing list
MSEC@ietf.org
https://www.ietf.org/mailman/listinfo/msec