INRIA Rhône-Alpes - Planète research group 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/
INRIA Rhône-Alpes - V. Roca - 2
Diffs w.r.t. I-D version-00 presented at IETF63
general ideathis I-D is an instantiation of TESLA for a particular
target environment (content delivery protocols)this I-D is not a specification of the TESLA building
block
motivated by:comments on mailing list (Mike L. and others) mid-2005discussions on the possible split of the I-D at IETF63
INRIA Rhône-Alpes - V. Roca - 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.
INRIA Rhône-Alpes - V. Roca - 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 modemove 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…
INRIA Rhône-Alpes - V. Roca - 5
Open points/questionswe 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”?
INRIA Rhône-Alpes - V. Roca - 6
Open points/questionsto do: clarify the use of signature/certificate/
PRF/MACconsider 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)?
INRIA Rhône-Alpes - V. Roca - 7
Last but not leastmove 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
INRIA Rhône-Alpes - V. Roca - 8
That’s all!