draft-bryan-p2psip-reload-03

1
draft-bryan-p2psip-reload-03

• Cullen Jennings
• Bruce Lowekamp
• Eric Rescorla
• Jonathan Rosenberg
• Salman Baset
• Henning Schulzrinne
• 3/14/2008

2
Outline

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

3
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.

4
Open Issues

• This is very much a work-in-progress.
• There are still open issues.
• The authors dont agree on everything thats 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

5
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 hitchhikers 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

6
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

7
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.

8
Architecture

• Application
• --------------------------------------
  Usage-defined API
• ------- -------
• Usage SIP XMPP ...
• Layer Usage Usage
• ------- -------
• --------------------------------------
  Distributed Storage API
• Overlay Overlay -------------
• Routing Routing ---- -----
• Storage Replication DB Chord ...
  Topology
• Layer Logic ----
  Plugins
• -----
• -------------
• --------------------------------------
• ------ -----
• Forwarding Forwarding STUN ICE
• Layer Encoding Logic ------ -----

9
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

10
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
• Dont actually participate in DHT routing
• No special client protocol
• Two reachability options
• Reach through responsible peer (based on clients
  ID)
• Contact any peer in overlay
• relies on source-based routing and multi-hop
  destination lists
• Open Issue or dont authenticate client device,
  but only user/resource
• Open Issue client model needs more description
  in draft

11
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

12
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 Worlds05 and Wu, Tian, and
Wing IEEE P2P06
13
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?

14
Usages

• STORE/FETCH ltdatagt 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 -gt Contact (GRUU if on
  a peer)
• SIP uses for CONNECT and TUNNEL for SIP dialogs
• Depends on Certificate Store usage and TURN usage

15
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)