Security and RMT Protocols: Discussions and Guidelines

1. <draf-adamson-roca-rmtsec-issues-00.txt>IETF 67th – San Diego meeting, November 2006 Brian Adamson (NRL), Vincent Roca (INRIA) Security and RMT Protocols: Discussions and Guidelines

2. Goals of this document • first goal is to state the problem • define the general security goals: • what do we want to protect? network versus protocol versus content • identify the elementary security services: • can be generic (e.g. object/packet integrity), or specific to CDP (e.g. congestion control security) • list the security BBs: • they provide the desired security services • highlight the CDP and use-case specificities that will impact the solution proposed • e.g. there might be no back channel…

3. general security goals relies on impacts… elementary security services impacts… relies on security BBs Goals of this document… (cont’) • can be depicted as follows: CDP and use-case specificities

4. Goals of this document… (cont’) • a goal is to detail (all?) threats of current CDP • it’s probably a long list that will remain open… • Question: move list of threats to the CDP docs? • a goal is to help choosing the right solution for a given use case • provide guidelines when feasible

5. Goals of this document… (cont’) • a goal is to make sure that nothing is missing in current CDP specifications • for instance provide the appropriate Header Extensions • as already done with the EXT_AUTH HE of LCT • Question:something else needed? Probably… • leave the door open for future CDP security extensions…

6. Non goals of this document • this doc is NOT meant to: • go into the details • we don’t want to make it a 200+ page I-D that (almost) nobody reads • solve all problems • identifying open points is already a first step • use existing BBs, and if something is missing, then do the work in a separate I-D

7. Problem space • the RMT-sec problem space is huge… • CDP * use-cases * desired security * security BBs • example: • stock market secure and confidential delivery with NORM to a set of 100 known receivers, over a high speed network • FLUTE/ALC content secure delivery with integrity checks to a set of ~100,000s of receivers, unknown to the server and quickly changing, over a unidirectional, lossy DVB-H channel

8. Problem space… (cont’) • several points of view are possible • e.g. the network provider versus the service provider versus the content provider • will impact the solutions to set up! • consequence: no single answer will fulfill all situations • just like RMT protocols…

9. Potential pitfalls • try to remain open-minded • content security is typically the responsibility of the content provider… • …but offering some content-related security services can be the responsibility of the transport layer • example: content integrity • can be done within the application by a signed hash of the object  content provider ‘s responsibility • can be done by checking integrity of every packet received for the object  CDP responsibility

10. Potential pitfalls… (cont’) • do not escape too much from the RMT domain of expertise • e.g. some solutions are typically part of the routing area (reliable and secure forwarding), or application area (e.g. object encryption)

11. What I-D version 00 contains • we essentially focused on the problem statement • many sections remain to be filled • we didn’t give any thought on many aspects yet

12. To conclude… • please join and contribute to this document and discussion • George, Gorry, Mark, others… • questions, contributions, comments, etc.