draft-bryan-p2psip-reload-03

draft-bryan-p2psip-reload-03 Cullen Jennings Bruce Lowekamp Eric Rescorla Jonathan Rosenberg Salman Baset Henning Schulzrinne 3/14/2008

Outline • History of merged draft • Goals of draft • Terminology • Architecture • Security • Clients • Encoding • Routing • NAT Traversal • Usages • Open Issues

reload-01 tunnels, encoding ASP usages, via-lists P2PP unstructured overlays, diagnostics reload-02 new encoding, better nat traversal reload-03 History of Merged Draft • ASP, reload-01, and P2PP features merged into reload-03 (approx 300 pages merged into 115). • Key point: The authors agree on most of the fundamental aspects of the peer protocol • Incorporates lessons learned from at least four peer protocol implementations. Not exactly like any one of them.

Open Issues • This is very much a work-in-progress. • There are still open issues. • The authors don’t agree on everything that’s in the draft. • Some aspects (e.g. unstructured) not completed. • We hope the document is correct, but repeated merges have not made it clearer. • Many open issues raised in draft. • Name itself is an open issue! • More on those later…

Goals (1 of 2) • Base peer protocol capable of supporting demands of different application scenarios • Very small number of drafts specify a working system • ICE for non-SIP (NICE) and SIP Usage intended to be split • Avoid the hitchhiker’s guide problem • Pluggable components • DHT, service discovery • Functional, implementable base components • Favor implementation simplicity over completeness • Open issue where the group wants to go here

Goals (2 of 2) • Secure • Certificates to authenticate peers and resources • Working assumption that peers are untrusted • Reputation models not currently in base draft • Interoperate with HIP • HIP offers exciting benefits to applications in a P2P setting • Several proposals with different architectures • Ongoing effort to ensure compatibility for future • Implementation does not require HIP

Terminology • Three sources • draft-ietf-p2psip-concepts • IETF terminology (security areas, etc) • p2p community • Terminology from these three areas is often conflicting and not always consistent. • We still need ongoing effort to update p2psip-concepts.

Security • Base security on CA/enrollment server certificates • Enrollment server issues random Peer ID(s) • Enrollment server assigns resource ownership (AoR) • Data sent in a STORE request is versioned and signed • Signature is returned with the FETCH • No trust of the responsible peer is required (although responsible peer SHOULD enforce permission model) • Peers are identified by certificates specifying Peer ID • Restricts the form of attacks • Security of P2P overlays still probabilistic • Open Issue: Data (STORE/FETCH/TUNNEL) secrecy not specified • Considering CMS for signatures and secrecy

Clients • Support for clients to do STORE/FETCH • Still allows them to provide services that are discovered in the overlay • Other purposes (data storage) left out for now as out of scope per IETF70 • Clients enroll in same manner as peer (have certificates) • Messages signed just as peer • Don’t actually participate in DHT routing • No special “client protocol” • Two reachability options • Reach through responsible peer (based on client’s ID) • Contact any peer in overlay • relies on source-based routing and multi-hop destination lists • Open Issue: or don’t authenticate client device, but only user/resource • Open Issue: client model needs more description in draft

Encoding • Binary Protocol • Evolved from TLV • T and L only when not known from context • Major components • Forwarding header (source, dest, etc. more on next slide) • Body • Common header describes type of message, dictates remaining encoding • Signature over message • Body and portions of the header

Routing • Header contains Destination and Via list • Destination list allows source-routing • Via-list allows symmetric responses • Route-log for recording/authenticating path separate • Preferred routing is symmetric • Like everything else, subject to WG decision • Has virtue of always working (NATs, joining, healing, etc)* • Other options possible (for example semi-recursive) • need to encode IP address(es) in all messages • need fallback to symmetric when response not directly returnable • Simplicity vs optimization • Expect that different DHT plug-ins and deployments will have different solutions (a global-scale system may only admit peers with public unfiltered IP addresses and use semi-recursive or iterative routing) *See Freedman et al Worlds’05 and Wu, Tian, and Wing IEEE P2P’06

NAT Traversal • ICE • Subset of features, as envisioned by NICE • All peers implement STUN server • Overlay can be provisioned with STUN servers • Peers build list of useful STUN servers from connections • CONNECT method for peer protocol and applications • SIP session establishment • TUNNEL for applications • TURN servers • Open Issue: need for service discovery usages! • Open Issue: require capable peers to be TURN servers?

Usages • STORE/FETCH <data> not enough • who can write, who can read (REGISTER vs voicemail) • what exactly is it, what format? • single value vs list (need atomic operations?) • Usages define kind-ids (type# in encoding), data structure, access control, size limits, Unhashed-ID, merger rules • Many to Many • Applications to Usages • Usages to Kind-ids • SIP Usage • SIP-REGISTRATION kind: AoR -> Contact (GRUU if on a peer) • SIP uses for CONNECT and TUNNEL for SIP dialogs • Depends on Certificate Store usage and TURN usage

Open Issues • Service Discovery • Draft currently has (overly?) simple model • Scalability, locality, capacity • May not want in base draft • Simplicity vs Optimization • DHT • Routing • Transport Layer • Fragmentation, TCP over UDP • Hop-by-hop and end-to-end retransmissions • Data model • Fundamental storage types (more from Henning later)

draft-bryan-p2psip-reload-03