1. March 2008IETF 71 (P2PSIP)1 Data types in P2P systems Henning Schulzrinne Columbia University

2. March 2008IETF 71 (P2PSIP)2 Data issues What do we store and fetch? How do we protect it? –separate topic: CMS, homebrew,... Analogies –file system (meta data, ACL, blob) some had/have data types (e.g., VMS records) –hash libraries (e.g., hcreate()) –database libraries (e.g., gdbm) –language features such as arrays and dictionaries Tcl, Perl, PHP, Python, Ruby,... data ID crypto wrapper

3. March 2008IETF 71 (P2PSIP)3 Requirements Need to be able to store any data item –of reasonable size New types MUST NOT require rewriting node software –otherwise, little chance to generalize ID (“database key”) must allow non-AOR values –otherwise, doesn’t generalize to VoD and other uses Allow both “standard” data objects and application-specific ones –e.g., SIP registration records and vendor-specific configuration data or I-D 00 experiments Provide access control –e.g., only creator can read –should work with semi-trusted nodes Provide policy control per node or overlay –e.g., maximum size of objects

4. March 2008IETF 71 (P2PSIP)4 Data typing RELOAD -03: 32-bit integer with some TBD allocation scheme –e.g., similar to IANA ports registry compromise between space efficiency and extensibility a “usage” may define one or more data types

5. March 2008IETF 71 (P2PSIP)5 Multiple objects with same “key” (ID) What happens if there’s a hash collision? Possibilities –global space {“egg”} is may cause DOS attacks if ID = AOR –creator e.g., ID space could be local to creator {“egg”, alice} and {“egg”, bob} are two different objects allows “only AOR can register AOR” policy –data type {“egg”, 17, alice} and {“egg”, 42, alice} are two different objects –auxiliary data {“egg”, 17, alice, label1} and {“egg”, 17, alice, label2} are two different objects

6. March 2008IETF 71 (P2PSIP)6 Access control & versioning Basic access control policy: only owner (= creator) can replace (or delete) object –enforced by peer –can’t prevent peer from disobeying policy Do we need more elaborate policies? –similar to Unix ACLs or chmod bits? –unbounded complexity

7. March 2008IETF 71 (P2PSIP)7 Versioning & timestamps Do objects have timestamps? Option 1: Just metadata Option 2: Cannot replace newer object with older one –prevents replay attack –does not require synchronized clock in overlay as long as all instances of owner have roughly synchronized clocks or fetch current value

8. March 2008IETF 71 (P2PSIP)8 Compound data structures Should there be compound data structures? Options (at least) But also STL (see next slide) Scripting languages (PHP, Tcl, Ruby,...) Need data structures AND operations –e.g., enumeration, traversal (iterator), insertion at beginning/end,... Interaction with policies and replication

9. March 2008IETF 71 (P2PSIP)9 Example: STL containers Sequentialvectorfast inserts at end listinserts anywhere dequeinserts start & end Associativemultisetduplicates allowed setno duplicates multimap1-to-many map1-to-1 AdapterstackFILO queueFIFO priority_queuesorted order

10. March 2008IETF 71 (P2PSIP)10 Example: Tcl set name(first) "Mary” Fake two-dimensional arrays: name(a,b) No ordering guarantees –PHP differs, for example (insertion order)

11. March 2008IETF 71 (P2PSIP)11 Proposed simple type Uniquely identified by H(data) –within {“ID”, owner, type} Operations –replace –list all {“ID”, owner, type} hashes (?)

12. March 2008IETF 71 (P2PSIP)12 Other proposals Three types: –singleton –numeric array –dictionary Issues that need to be resolved: –operations beyond single-element –replication –access control for [x] separate from data?

13. March 2008IETF 71 (P2PSIP)13 Example applications registrations –multiple handsets for same AOR voicemail –may generally use a server (announcement), not just storage –multiple writers? –but probably want to hide meta data TURN servers –possibly indexed by some location indication

14. March 2008IETF 71 (P2PSIP)14 Summary Data model independent of DHT and protocol But if more complicated, may need additional operations beyond store & fetch –or at least additional sub-operations (“last”) Security issues -- what gets exposed to the (untrusted) server?