Subject: Re: [MSEC] Re: Can GSAKMP setup TESLA?

From: canetti <[email-masked]>
Date: Tue, 10 Aug 2004 09:28:03 -0400 (EDT)

Hugh,

This sounds like a good solution.

The requirements of TESLA are pretty explicit in the TESLA-SRTP draft
(and also in the TESLA-intro draft). If you run into any problems I'the
authors will be happy to assist.

Thanks,

Ran

On Mon, 9 Aug 2004, Hugh Harney wrote:

> Ran,
>
> I can see adding some text, assuming we get the chance to add text
> during final review, that mentions the collection of specific timing
> information for use by TESLA. I'd generalize this to suggest that TESLA
> is only the first protocol that may need this timing information. This
> way GSAKMP can collect information for the TESLA module to process.
> This would preserve the separation between protocols and I believe
> insure that TESLA had the data it needs collected from GSAKMP.
>
> Can you tell me exactly what data TESLA needs from GSAKMP?
>
> For specific TESLA information about the TESLA data passed by GSAKMP in
> the "vendor specific" payloads (IETF protocols can be vendors) I'd
> rather have the implementors refer to a TESLA specification.
>
> Hugh
>
>
> On Aug 6, 2004, at 3:55 PM, canetti wrote:
>
> >
> > Hugh, I agree with most of what you say, and in particular I agree that
> > any reasonable implementation of GSAKMP should be able to provide what
> > TESLA needs with little effort --- given that it has TESLA in mind at
> > the
> > time of writing the implementation. (Once an implementation is
> > running, it
> > is hard to go back in and add patches.)
> >
> > So, since the GSAKMP document, like most IETF security-related
> > standards,
> > is concerned not only with protocol flow specification but also with
> > internal processing, I think it would be prudent to add a note in the
> > GSAKMP
> > document with tips on what an implementation should do if it wants to
> > be
> > compliant with TESLA.
> >
> > Best,
> >
> > Ran
> >
> > On Fri, 6 Aug 2004, Hugh Harney wrote:
> >
> >> Ran,
> >>
> >>
> >> I'd be happy to review any ASN.1 specification that is needed by
> >> TESLA.
> >> I'm not an expert in ASN.1 Andrea helped me with this spec. If you
> >> look
> >> at the SRTP example, the ASN.1 definition should be easy to copy the
> >> format. That's why I felt we needed an example.
> >>
> >>>
> >>> I'd agree with you 100% if not for the fact that TESLA needs this
> >>> special
> >>> time synch information. At I explained in my previous mails, to
> >>> provide
> >>> that it's not enough to define payloads. The actual GSAKMP processing
> >>> needs to be augmented with measuring local time at cerain moments.
> >>> This indeed results in an unfortunate lack of modularity, but if we
> >>> don't
> >>> do it then I dont see how GSAKMP can support TESLA setup.
> >>
> >> Don't confuse the specification with the software. TESLA may need some
> >> times that are generated within the GSAKMP software, but this doesn't
> >> change the GSAKMP specification. If you look at George's IPSec
> >> proposal
> >> there is a ton of processing that is IPSec specific, but not part of
> >> the core GSAKMP specification. Implementors of GSAKMP for a data layer
> >> protocol XYZ will need to write code to support management of the data
> >> layers.
> >>
> >> What is needed is additional functionality to support "TESLA enabled
> >> GSAKMP implementations". This is fine. This is still focused at the
> >> Data Layer. The TESLA definition needs to specify the local time
> >> measurments that are needed from GSAKMP. Implementors will provide
> >> these TESLA specific measurements as part of the TESLA build. These
> >> measurments are not widely used outside of TESLA, so they can be
> >> documented in the TESLA spec.
> >>
> >> This is a fairly standard way of dealing with support protocols. You
> >> have a core and the unique things that are needed by the consuming
> >> applications are defined in that applications specification.
> >>
> >> In truth I think most every implementor of GSAKMP will be able to
> >> satisfy your need for time data. Everyone will test the performance of
> >> their GSAKMP code. Those times should give you the data needed to
> >> perform your calculations for TESLA.
> >>
> >> Hugh
> >>
> >>
> >
> >
> Hugh Harney							Sparta, Inc.
> [email-masked]						7075 Samuel Morse Drive
> (410) 872-1515 x203					Columbia, MD, 21046
>
>
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec