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
- [MSEC] Review of draft-ietf-msec-tesla-for-alc-no… Brian Weis
- [MSEC] Review of draft-ietf-msec-tesla-for-alc-no… Ramu Panayappan
- Re: [MSEC] Review of draft-ietf-msec-tesla-for-al… L.Liang
- Re: [MSEC] Review of draft-ietf-msec-tesla-for-al… Vincent Roca
- Re: [MSEC] Review of draft-ietf-msec-tesla-for-al… Vincent Roca
- Re: [MSEC] Review of draft-ietf-msec-tesla-for-al… L.Liang