INRIA Rhône-Alpes - V. Roca - RMT Meeting IETF 71 st – Philadelphia, March 2008 Vincent Roca

INRIA Rhône-Alpes - V. Roca - Outline RMT Security mTESLA for ALC/NORM status mSimple Authentication Schemes mRMT securityI-D: what’s next? FCAST mstatus mwhy should it be considered? mnext steps

INRIA Rhône-Alpes - V. Roca - RMT Security Discussion

INRIA Rhône-Alpes - V. Roca - TESLA for ALC/NORM status basically mIMHO the specification is now stable mready for WGLC? ( ⇒ wednesday MSEC meeting) mwe implemented most of it to cross-check the specification... mseems to work but we did not test it thoroughly, though ma serious test campaign is planned

INRIA Rhône-Alpes - V. Roca - TESLA for ALC/NORM status... (cont’) what we did in new version, in short mnew bootstrap information message format that contains a “key chain commitment” rather than disclosing a key ⇒ in line with some authentication tags madded a “crypto function type” field/IANA registry to be used with digital signatures mfinished description of the steps needed to authenticate incoming packets mclarified the use of multiple key chains metc. See (03/09/08) for technical details

INRIA Rhône-Alpes - V. Roca - Simple Auth Schemes for ALC/NORM no progress... mat IETF’70 the decision was to wait feedback from NRL guys who worked on NORM security mNORMS proposal is based on asymmetric crypto for downstream flow ⇒ it’s what the above I-D enables mNORMS proposal for upstream traffic is based on a (private?) TTP (Trusted Third Party), not necessarily a PKI certification authority. IMHO the proposal is not sufficiently mature at this level, but may contain interesting ideas to further develop ⇒ needs further discussion with the authors...

INRIA Rhône-Alpes - V. Roca - RMT security discussion I-D no progress... mwe (authors/group) clearly need to decide what we want to do with this doc... mour proposal: mrestrict its scope a little bit... it’s not a survey of all possible security aspects! mand decide that either we can come to IETF’72 with a consolidated document or we give up the work

INRIA Rhône-Alpes - V. Roca - FCAST Discussion

INRIA Rhône-Alpes - V. Roca - FCAST what has been done so far? minitial I-D in March 2007 ma few discussions on the mailing list ma call for volunteers (still open...) m...and that’s all for the moment why another file transfer application? 1. it’s lighter (this is one of the goals) 2. it’s efficient with both ALC and NORM 3. it addresses more efficiently simple use-cases 4. it bypasses Nokia’s IPR claim on FLUTE

INRIA Rhône-Alpes - V. Roca - 1- Is FCAST lighter? is it really lighter? myes if we remain in line with the 2000 proposal, i.e., append the meta-data to the file being sent in an aggregate object what is supposed to be lighter? mthe specifications... a little bit mthe implementation and processing overhead... yes mbecause there’s no need to keep a database of the session’s objects and their meta-data the meta-data of an object are processed immediately

INRIA Rhône-Alpes - V. Roca - Is FCAST lighter? (cont’) mbecause meta-data is processed only once, just on time whereas “FDT Instances can be equal to, a subset of, a superset of, or complement any other FDT Instance” ⇒ requires to process each and every FDT Instance mbecause the meta-data format/processing are simpler in, there is no XML format but a simple list: : CR as for the HTTP object metainformation ⇒ no need for an XML parser even with an XML format (other option) there would be fewer elements/attributes

INRIA Rhône-Alpes - V. Roca - Is FCAST lighter? (cont’) mbecause the sender does not have to care about the optimal transmission strategy for meta-data whereas with FDT Instances in on-demand: what tx rate for FDT Instance? how often (even with static session)?

INRIA Rhône-Alpes - V. Roca - 2- Is FCAST efficient with ALC and NORM? I implemented FAST/ALC/NORM it in the past mthe same application was running on top of both protocols without problem, with very minor per protocol adaptations msee for more info and a (very old!) open-source implementationhttp://planete-bcast.inrialpes.fr FCAST/NORM is more efficient than FLUTE/NORM in on-demand mode mwith FLUTE/NORM the FDT Instance is sent periodically mwith FCAST/NORM meta-data is sent once, just on time

INRIA Rhône-Alpes - V. Roca - 3- Is it more efficient with simple use-cases? use-case considered: meach receiver is interested by all the objects sent in the LCT channel(s) he has joined why is it more efficient? mFLUTE limited by FDT Inst/object interdependency mthe object cannot be processed before processing the associated meta-data in an FDT Instance mFCAST is not mbecause meta-data is directly attached to the object

INRIA Rhône-Alpes - V. Roca - Is it more efficient... (cont’) mRod’s suggestion to improve FLUTE’s behavior ( 01/24/08): mbundle meta-data (or subset) within an aggregate object myes we can streamline the FDT Instance (and send it more often) and move a subset of meta-data in the aggregate objects... m... but: it adds one more layer of complexity: composite objects it does not solve totally the interdependency problem since processing the FDT Instance is needed to know it’s a composite object

INRIA Rhône-Alpes - V. Roca - Is it more efficient... (cont’) another good point for FCAST mmeta-data benefits from the FEC encoding of the object mwhereas an FDT Instance fits within a small # of packets which makes their protection difficult m ⇒ repetition is often the only solution to improve robustness with FLUTE

INRIA Rhône-Alpes - V. Roca - 4- It bypasses Nokia’s IPR claim if we stay inline with the initial proposal, as already said: mFCAST is described in the first ALC I-D: mpublished on March 8th, 2000 mwhereas Nokia’s IPR claim: mDATACAST FILE TRANSMISSION WITH META-DATA RETENTION i?ipr_id=733https://datatracker.ietf.org/public/ipr_detail_show.cg i?ipr_id=733 mpriority date: January 31, 2003

INRIA Rhône-Alpes - V. Roca - What’s next? a final comment: mFLUTE is a versatile tool whereas FCAST is more specialized, with a more narrow scope. It’s important to keep this in mind while reading the previous slides... if the group agrees... mBrian and myself propose a mature -01 version for IETF’72 mother volunteers are still welcome