1 / 18

RMT Meeting

RMT Meeting. IETF 71 st – Philadelphia, March 2008 Vincent Roca. INRIA Rhône-Alpes - V. Roca -. Outline. RMT Security TESLA for ALC/NORM status Simple Authentication Schemes RMT securityI-D: what’s next? FCAST status why should it be considered? next steps.

berke
Download Presentation

RMT Meeting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Outline • RMT Security • TESLA for ALC/NORM status • Simple Authentication Schemes • RMT securityI-D: what’s next? • FCAST • status • why should it be considered? • next steps INRIA Rhône-Alpes - V. Roca -

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

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

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

  6. Simple Auth Schemes for ALC/NORM • no progress... • at IETF’70 the decision was to wait feedback from NRL guys who worked on NORM security • NORMS proposal is based on asymmetric crypto for downstream flow ⇒ it’s what the above I-D enables • NORMS 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 -

  7. RMT security discussion I-D • no progress... • we (authors/group) clearly need to decide what we want to do with this doc... • our proposal: • restrict its scope a little bit... • it’s not a survey of all possible security aspects! • and 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 -

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

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

  10. 1- Is FCAST lighter? • is it really lighter? • yes 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? • the specifications... a little bit • the implementation and processing overhead... yes • because 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 -

  11. Is FCAST lighter? (cont’) • because 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 • because the meta-data format/processing are simpler • in <draft-ietf-rmt-pi-alc-00>, there is no XML format but a simple list: <field>:<value>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 -

  12. Is FCAST lighter? (cont’) • because 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 -

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

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

  15. Is it more efficient... (cont’) • Rod’s suggestion to improve FLUTE’s behavior (email 01/24/08): • bundle meta-data (or subset) within an aggregate object • yes we can streamline the FDT Instance (and send it more often) and move a subset of meta-data in the aggregate objects... • ... 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 -

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

  17. 4- It bypasses Nokia’s IPR claim • if we stay inline with the initial proposal, as already said: • FCAST is described in the first ALC I-D: • http://tools.ietf.org/html/draft-ietf-rmt-pi-alc-00 • published on March 8th, 2000 • whereas Nokia’s IPR claim: • DATACAST FILE TRANSMISSION WITH META-DATA RETENTION • https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=733 • priority date: January 31, 2003 INRIA Rhône-Alpes - V. Roca -

  18. What’s next? • a final comment: • FLUTE 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... • Brian and myself propose a mature -01 version for IETF’72 • other volunteers are still welcome INRIA Rhône-Alpes - V. Roca -

More Related