1 / 8

TESLA for ALC and NORM <draf-faurite-rmt-tesla-for-alc-norm-01.txt> IETF 65 th - Dallas meeting

TESLA for ALC and NORM <draf-faurite-rmt-tesla-for-alc-norm-01.txt> IETF 65 th - Dallas meeting. Vincent Roca , Aurélien Francillon, Sébastien Faurite (INRIA) http://planete.inrialpes.fr/~roca/. Diffs w.r.t. I-D version-00 presented at IETF63. general idea

manju
Download Presentation

TESLA for ALC and NORM <draf-faurite-rmt-tesla-for-alc-norm-01.txt> IETF 65 th - Dallas meeting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TESLA for ALC and NORM<draf-faurite-rmt-tesla-for-alc-norm-01.txt>IETF 65th - Dallas meeting Vincent Roca, Aurélien Francillon, Sébastien Faurite (INRIA) http://planete.inrialpes.fr/~roca/

  2. Diffs w.r.t. I-D version-00 presented at IETF63 • general idea • this I-D is aninstantiation of TESLA for a particular target environment (content delivery protocols) • this I-D is nota specification of the TESLA building block • motivated by: • comments on mailing list (Mike L. and others) mid-2005 • discussions on the possible split of the I-D at IETF63

  3. Diffs w.r.t. I-D version-00… (cont’) • globally much more sound, even if far from perfect… • we re-wrote most parts of the document: • new section 2 “Using TESLA with ALC and NORM” • explains the ALC/NORM specificities that impact the use of TESLA • provides some guidelines on how to perform synchronization, in particular in indirect mode • this section needs to be improved… • updated section 5 “Integration in ALC and NORM” • updated the various message formats • we separate Bootstrap Information from Direct time synchronization replies, etc.

  4. Diffs w.r.t. I-D version-00… (cont’) • we removed some text: • e.g. explanations on how to calculate an upper delay bound in indirect synchronization mode • move it to a (missing) “TESLA Building Block Spec” • some other parts could be moved too (e.g. the Bootstrap Information message format) • and we did many other corrections (including errors) • too long to be presented here…

  5. Open points/questions • we consider the possibility of key chain switch • mentioned neither in “TESLA for SRTP”, nor in RFC4082 • we believe: • it’s more efficient than the transmission of a new Bootstrap Information message each time we switch to a new key chain • it’s not so complex • we now say that bootstrapping can be done either in-band or out-of-band • (novice) question: does it make sense to extend the applicability of the Mikey solution (draft-ietf-msec-bootstrapping-tesla) to “TESLA for ALC/NORM”?

  6. Open points/questions • to do: clarify the use of signature/certificate/ PRF/MAC • consider other possibilities than those mentioned? Consequences? • open point: how to best represent a signed NTP timediff? • Double float (e.g. IEEE754)? Signed integer for the 32-bit second value? Additional flag to give the sign (we chose it)?

  7. Last but not least • move this I-D to the MSEC WG? • the initial choice of having it an RMT document was perhaps not the best one • in any case, both groups will be kept synchronized • presentation in both groups + CC to RMT and MSEC

  8. That’s all!

More Related