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!