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

1
TESLA for ALC and NORMltdraf-faurite-rmt-tesla-for
-alc-norm-01.txtgtIETF 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 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-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
• its more efficient than the transmission of a
  new Bootstrap Information message each time we
  switch to a new key chain
• its 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

• Thats all!