1. FCAST update TESLA update IETF 76 – Hiroshima, November 2009 V. Roca (INRIA)

2. FCAST update

3. Modifications WRT July's -05 version a lot of cleanup, especially W.R.T. NORM… removed the possibility of having a streamlined meta-data in the original compound if NORM_INFO is used (since NORM_INFO support is optional) clarified that the NORM_INFO compound object's checksum only encompasses the header clarified that padding is not used when there's no Object Data in a compound object (NORM_INFO and "empty CIO list") added NORM_INFO example (annex A.2) Fcast-CIO-Complete and Fcast-CIO-ID meta-data entries of a CIO are now optional. Goal is to simplify the simple case of a session consisting of a single, complete, carousel instance (the CIO contains no meta-data, just the object list)

4. And now? mFCAST: a simple, elegant and efficient solution for both protocol families (ALC/LCT and NORM) mofficially a WG Item even if -06 is still individual I-D mgo into WGLC ?

5. TESLA update

6. Quick reminder on TESLA ma loss-tolerant, high-throughput, per packet, source authentication and integrity verification protocol mfor "source → receivers" flow only mfor ALC/LCT and NORM with NORM, another mechanism is needed for feedback malong with group MAC/digital signatures, it provides a comprehensive set of techniques msee, now in WGLC, please review ;-)

7. Quick reminder on TESLA… (cont') mTESLA/Group MAC/digital signatures EXT_AUTH header extensions all start with an ASID (Auth. Scheme ID) field several authentication schemes can be used jointly in the same session (e.g. NORM)

8. Situation mTESLA is an MSEC document mpassed WGLC (end 2008) mversion -10 accepted by IESG last week now in "RFC Editor Queue" state mMain recent modifications during IESG review: mremoved several TESLA messages for the sake of simplicity however it remains relatively complex  mcorrected a major mistake in key derivation description m+ many details