O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
P2P SIP Tutorial Part 2: P2P overlay networks Henry Sinnreich Alan Johnston March 17, 2008
Overview <ul><li>Part 1: What are SIP, RTP and P2P? </li></ul><ul><ul><li>RFC 3261 SIP and the aftermath </li></ul></ul><u...
Part 1: Overview of SIP and P2P Little time to discuss high complexity
The Session Initiation Protocol (SIP) and  the Real Time Transport Protocol (RTP) <ul><li>Discover the remote (called) par...
The ugly, later parts in SIP <ul><li>NAT impedes Internet transparency </li></ul><ul><li>Session border controllers breaks...
Problem: VoIP infrastructure complexity <ul><li>DNS, ENUM (tel number mapping): Sever operations, cost of services  </li><...
Overall carrier wire & wireless IMS architecture  - Other IP Networks IP Transport (Access and Core) T - MGF I - BGF UPSF ...
The complexity of SIP The impact of cable & wireless industries, telephony DB, SBC
Solution: Application level overlay network Application Transport Network Data link Physical Application Transport Network...
Major P2P Projects Planet Lab infrastructure   http://www.planet-lab.org/ 645 nodes over 310 sites. Academic, industrial, ...
The P2P overlay network <ul><li>Essentially* no network servers or infrastructure </li></ul><ul><li>Self organizing: </li>...
Motivating scenarios for P2P SIP networks  <ul><li>Small deployments </li></ul><ul><ul><li>Security (don’t want to use a c...
Other P2P Overlay Network Applications <ul><li>P2P computation (grids) </li></ul><ul><li>Content distribution: SW, audio/v...
Business model items for the P2P network <ul><li>Sharing the DHT between applications </li></ul><ul><ul><li>Bootstrap node...
Latest news about commercial P2P <ul><li>Bittorent: Movies, TV, MP3, games </li></ul><ul><ul><li>http://www.bittorrent.com...
P2P SIP Protocol Layers Overlay Network Internet SIP applications L4 Transport (UDP, TCP) L3 IP Network Legend DHT: Distri...
SIP Session Setup Options <ul><li>Discovery of remote address </li></ul><ul><li>Setting up the session </li></ul>Legend DN...
CS (a) and P2P (b) SIP Location Discovery Legend SRV: DNS Server Resource Locator (RFC 2782) NAPTR: Network Authority Poin...
P2P SIP System Legend CN: Client node PN: Peer (various functions) Proxy: SIP proxy server, is another PN Concepts and Ter...
Some requirements for global markets <ul><li>Standards based: Interoperates with global SIP services and devices </li></ul...
Simple usage scenario for SIP <ul><li>An alternative to present SIP CS usage (complex) </li></ul><ul><li>Tool set for impl...
What P2P SIP IS NOT is just as important <ul><li>Not another VoIP softphone or IM client </li></ul><ul><li>Not another VoI...
Part 2: P2P Overlay Networks and Distributed Hash Tables (DHT)
Secure Hash Algorithm SHA-1 “it is computationally infeasible 1) to find a message that corresponds to a given message dig...
DHT Example: Chord <ul><li>A virtual ring of the size 2 ^m  is used for the routing of messages between the nodes </li></u...
Frequent Joins and Leaves in Chord <ul><li>Join (of node n) </li></ul><ul><li>Keys previously assigned to the successor of...
Joining Procedure in Chord <ul><li>The joining node n computes its node ID </li></ul><ul><li>Node n calls find_successor t...
Chord Extensions for Robustness Against Node Failure <ul><li>Correctness of Chord relies in each node knowing its direct s...
Comparing P2P Overlays - 1 <ul><li>Basic classification of P2P networks </li></ul><ul><ul><li>Pure P2P </li></ul></ul><ul>...
Comparing P2P Overlays - 2 <ul><li>Maturity (from a commercial product perspective) </li></ul><ul><ul><li>More than just b...
Comparing Routing Geometries and Algorithms <ul><li>DHT design choices </li></ul><ul><li>Geometry and algorithm </li></ul>...
The limitations of DHT overlays <ul><li>DHT’s are suitable for two important application domains: </li></ul><ul><li>Store ...
Example Deployment Scenarios for P2P SIP There is a large deployment area service providers and IT for stable peers to sup...
Performance measurements on the openDHT http://www.arl.wustl.edu/~jst/cse/570/files/10-2-2006a-Andrew_Wan.pdf a. Long runn...
Pastry routing from peer 37A0F1 with key B57B2D Live peers B581F1 Route to:  B57B2D 1. Match prefix 2. Closest match for s...
Lookup performance for Pastry “ Pastry: Scalable, decentralized object location and routing” by A. Rowstron and P. Drusche...
Lookup (routing) in Pastry and Bamboo “ Handling Churn in a DHT”: http://srhea.net/papers/bamboo-usenix-talk.ppt <ul><li>L...
Routing table of Pastry peer with nodeID 37A0x … 37AFx 37AEx 37ADx 37ACx 37ABx … 37A2x 37A1x 37A0x … 37Fx 37Ex … 37Bx 37Ax...
Routing state of a Pastry peer b=4, L=16, M=32 (IP addresses are not shown) “ A Survey and Comparison or Peer-to-Peer Over...
Pastry: Node addition  d46a1c Route(d46a1c)? d46 2ba d4 213f d 13da3 65a1fc d46 7c4 d4 71f1 New node : d46a1c
Part 3: High Performance P2P
Bamboo  A variation of Pastry <ul><li>OpenDHT service (well optimized) </li></ul><ul><li>Modules </li></ul><ul><ul><li>Rou...
Interfaces to Bamboo in the openDHT <ul><li>Routing interface:  General access to the gateway node and to each node along ...
Interfaces to Bamboo in the openDHT <ul><li>Storage interface*:  Support for only put(key, value) and get(key) operations ...
Routing Styles in DHT Routing control at source Is slower Can check routing integrity: better security Higher message traf...
The use of routing styles in Bamboo (delay aware routing) <ul><li>The basic algorithm routes greedily through the key spac...
Reducing the DHT latency due to slow nodes “ Fixing the Embarrassing Slowness of openDHT on PlanetLab” by S. Rhea et all. ...
Non-transitive connectivity in DHTs <ul><li>Invisible Nodes: Node learns about another node but cannot reach it </li></ul>...
Handling Churn and Failures in Bamboo <ul><li>New approach based on extensive simulations and trials on OpenDHT </li></ul>...
Performance with smart timeouts Estimating when it is time to route around a failed node “ Handling Churn in a DHT”: http:...
Smart recovery of neighbor list  Reactive recovery is expensive under churn Excessive bandwidth consumption leads to overl...
Security for structured P2P overlays Ref: “Secure routing for structured peer-to-peer overlay networks” by M. Castro et al...
Routing security Model and simulation results for the probability of reaching all correct replica roots using redundant ro...
Design for P2P Interface Security in the OpenDHT <ul><li>Attacks </li></ul><ul><li>Squatting: Use a valuable key (“coca-co...
Skype security: Enrollment system <ul><li>Central server has private signing and public verification key pair: S S  and V ...
Skype session security <ul><li>Proprietary peer-to-peer key agreement protocol:  </li></ul><ul><ul><li>Symmetric to both p...
A: Contributions to P2PSIP at the 70 IETF  (in no particular order for non-HIP based) <ul><li>Peer-to-Peer Protocol (P2PP)...
A: Contributions to P2PSIP at the 70 & 71 IETF  (continued) <ul><li>P2PSIP Clients </li></ul><ul><li>draft-pascual-p2psip-...
Questions and discussion
Próximos SlideShares
Carregando em…5
×

Sinnreich Henry Johnston Alan Pt 2

  • Entre para ver os comentários

  • Seja a primeira pessoa a gostar disto

Sinnreich Henry Johnston Alan Pt 2

  1. 1. P2P SIP Tutorial Part 2: P2P overlay networks Henry Sinnreich Alan Johnston March 17, 2008
  2. 2. Overview <ul><li>Part 1: What are SIP, RTP and P2P? </li></ul><ul><ul><li>RFC 3261 SIP and the aftermath </li></ul></ul><ul><ul><li>The non-scalable complexity of client-server </li></ul></ul><ul><ul><li>The new opportunities provided by the P2P network </li></ul></ul><ul><li>Part 2: Intro to DHT P2P Networks </li></ul><ul><ul><li>Overview </li></ul></ul><ul><ul><li>DHT examples </li></ul></ul><ul><ul><li>DHT behavior </li></ul></ul><ul><li>Part 3: High performance P2P </li></ul><ul><ul><li>DHT performance design </li></ul></ul><ul><ul><li>DHT Security </li></ul></ul><ul><ul><li>Trust architecture for P2P </li></ul></ul>Note: The Internet and real time communications are very complex Disruptions such as P2P have solid reasons This is a best effort to fit the content into less than three hours
  3. 3. Part 1: Overview of SIP and P2P Little time to discuss high complexity
  4. 4. The Session Initiation Protocol (SIP) and the Real Time Transport Protocol (RTP) <ul><li>Discover the remote (called) party </li></ul><ul><li>Negotiate session params (codecs, etc.) </li></ul><ul><li>Establish session </li></ul><ul><li>Modify session </li></ul><ul><li>End session </li></ul><ul><li>Services </li></ul><ul><ul><li>Telephony (PBX-like, for agents, etc.) </li></ul></ul><ul><ul><li>Presence </li></ul></ul><ul><ul><li>IM </li></ul></ul><ul><ul><li>Conferences </li></ul></ul><ul><ul><li>Chat rooms </li></ul></ul><ul><li>SIP can provide the applications (services) “ in the network ” using servers, or end-to-end </li></ul><ul><li>XMPP and H.323 services are only “ in the network ” </li></ul>1 REGISTER 2 INVITE SIP Srv SIP Srv SIP UA SIP UA sip:alice@atlanta.com sip:bob@biloxi.com DNS biloxi.com? IP Bob? Loc DB IP of Bob 3 INVITE 4 INVITE 5 RTP voice, video, text
  5. 5. The ugly, later parts in SIP <ul><li>NAT impedes Internet transparency </li></ul><ul><li>Session border controllers breaks transparency </li></ul><ul><li>VoIP and IM networks are closed vertical stacks </li></ul><ul><li>(pay for roaming, hide from competitor, emulate telephone net) </li></ul>Legend: NAT: Network address translation SBC: Session border controller SIP Srv SIP Srv SIP UA SIP UA sip:alice@atlanta.com sip:bob@biloxi.com DNS biloxi.com? IP Bob? Loc DB IP of Bob RTP media NAT NAT SBC SBC Internet SBC SBC SIP
  6. 6. Problem: VoIP infrastructure complexity <ul><li>DNS, ENUM (tel number mapping): Sever operations, cost of services </li></ul><ul><li>SIP registrar and proxy server (farms - several locations) </li></ul><ul><li>Presence servers </li></ul><ul><li>Component servers: </li></ul><ul><ul><li>Announcements, voice mail, media servers, conference servers </li></ul></ul><ul><li>Session border controllers </li></ul><ul><li>Softswitches: Local switch emulation, PBX </li></ul><ul><li>Media servers </li></ul><ul><li>Network elements for QoS </li></ul><ul><li>Policy servers </li></ul><ul><li>Network management </li></ul><ul><li>Voice quality monitoring probes </li></ul><ul><li>Network engineering (no automatic SIP routing protocol) </li></ul><ul><li>System integration and regression testing after every change </li></ul><ul><li>VoIP network IT systems for all the above </li></ul><ul><li>Customer data placement in network elements (with customer churn) </li></ul>The sum of all = IMS ( IP Multimedia Subsystem for 3G wireless)
  7. 7. Overall carrier wire & wireless IMS architecture - Other IP Networks IP Transport (Access and Core) T - MGF I - BGF UPSF P - CSCF I/S - CSCF BGCF SLF Charging Functions IWF PSTN Emulation (R2) Mw Mw/Mk/Mm Mr Mg Mj Mi Mp Mn Gm Gq ' ISC Cx Dx Dh Sh Ic Rf /Ro Rf /Ro Ib Iw Gq ' PSTN/ISDN MRFC MGCF MRFP e4 Ie Mw IBCF Mk Mk Application Servers Rf /Ro AGCF e2 P1 P2 P3 UE CNG MG IMS / PSTN Simulation Gq ' SPDF A-RACF Resource & Admission Control Resource & Admission Control SPDF Network Attachment Subsystem Re Ia RCEF BGF Ut Ut SGF
  8. 8. The complexity of SIP The impact of cable & wireless industries, telephony DB, SBC
  9. 9. Solution: Application level overlay network Application Transport Network Data link Physical Application Transport Network Data link Physical Application Transport Network Data link Physical Application layer IP Routing Nothing in the middle Back to the Internet as it was designed: e2e
  10. 10. Major P2P Projects Planet Lab infrastructure http://www.planet-lab.org/ 645 nodes over 310 sites. Academic, industrial, and government institutions Open DHT OpenDHT is a publicly accessible distributed hash table (DHT) service . Clients of OpenDHT do not need to run a DHT node in order to use the service. http://www.opendht.org/index.html P2P SIP New IETF WG formed: P2PSIP Several P2P SIP projects and Internet Drafts (P2P IP PBX: Avaya and Peerio, prestandard) http://p2psip.org
  11. 11. The P2P overlay network <ul><li>Essentially* no network servers or infrastructure </li></ul><ul><li>Self organizing: </li></ul><ul><ul><li>No IT systems for infrastructure and its user data </li></ul></ul><ul><ul><li>No network operations are required </li></ul></ul><ul><li>All infrastructure costs are moved to the user </li></ul><ul><li>Same single piece of peer software is everywhere </li></ul><ul><li>Scaling to Internet size: The bigger, the better it works </li></ul><ul><li>*Two server types are required in small numbers: </li></ul><ul><ul><li>Customer licensing like for any other e-commerce </li></ul></ul><ul><ul><li>Overlay bootstrap and media relays </li></ul></ul><ul><ul><li>The value for the developer community (hold this thought) </li></ul></ul>
  12. 12. Motivating scenarios for P2P SIP networks <ul><li>Small deployments </li></ul><ul><ul><li>Security (don’t want to use a central provider) </li></ul></ul><ul><ul><li>Lack of resource (can’t run servers) </li></ul></ul><ul><li>Limited or no Internet connectivity </li></ul><ul><ul><li>Emergency scenarios, remote locations </li></ul></ul><ul><li>Sharing media among portable devices </li></ul><ul><li>Ad-Hoc and ephemeral groups, battlefield </li></ul><ul><li>Global decentralized communications </li></ul><ul><ul><li>Works with the rest of the (SIP) world </li></ul></ul>Ref: “P2P SIP Standards” by D. Bryan and H. Sinnreich, Paris 2007 http://www.upperside.fr/sip2007/sip2007program.htm#day1
  13. 13. Other P2P Overlay Network Applications <ul><li>P2P computation (grids) </li></ul><ul><li>Content distribution: SW, audio/video (TV) </li></ul><ul><li>Events-news (using RSS) </li></ul><ul><li>Distributed databases (user data, location) </li></ul><ul><li>DNS replacement* (can still interwork with DNS) </li></ul><ul><li>Application layer multicast (conferences) </li></ul><ul><li>RT communications: Presence, IM, A/V </li></ul><ul><li>The ‘Voice’ application </li></ul>TBD by market and business model * “A Layered Naming Architecture for the Internet” by H. Balakrishnan et al. http://nms.lcs.mit.edu/papers/layerednames-sigcomm04.pdf VON topic today
  14. 14. Business model items for the P2P network <ul><li>Sharing the DHT between applications </li></ul><ul><ul><li>Bootstrap nodes </li></ul></ul><ul><ul><li>Relay servers for NAT traversal </li></ul></ul><ul><ul><li>Client side ReDiR library for app specific lookups </li></ul></ul><ul><li>Sharing the DHT between clients (different customers) </li></ul><ul><ul><li>Fairness without economic incentive – Fair Space-Time (FST) </li></ul></ul><ul><li>Storage: </li></ul><ul><ul><li>Load balancing and fair disk usage </li></ul></ul><ul><li>DHT as a service: New application without deploying any nodes at all </li></ul><ul><li>New: </li></ul><ul><li>The application layer Internet service at L5, analog to the L3/L4 Internet service </li></ul><ul><li>Move all infrastructure costs to the end user: Computing, BW, electricity, real estate and maintenance+configuration. </li></ul><ul><li>Developers don’t have to worry how to be admitted on the network. </li></ul><ul><li>No server farms: P2P is green </li></ul>
  15. 15. Latest news about commercial P2P <ul><li>Bittorent: Movies, TV, MP3, games </li></ul><ul><ul><li>http://www.bittorrent.com/ </li></ul></ul><ul><li>Skype: P2P VoIP and multimedia with >250 million subscribers </li></ul><ul><ul><li>http://skype.com </li></ul></ul><ul><li>Pando: Content Delivery </li></ul><ul><ul><li>http://pando.com/ </li></ul></ul><ul><li>Ooma: P2P VoIP in Adapter with RJ11 to PSTN </li></ul><ul><ul><li>http://www.ooma.com/ </li></ul></ul><ul><li>Vudu: P2P TV in set-top/tivo-like box </li></ul><ul><ul><li>http://www.vudu.com/ </li></ul></ul><ul><li>P4P Cooperative Control Between P2P and ISP </li></ul><ul><ul><li>http://www.dcia.info/documents/P4P_Overview.pdf </li></ul></ul><ul><ul><li>http://cs-www.cs.yale.edu/homes/yong/publications/P4PVision_P4PWG.ppt </li></ul></ul><ul><li>Major carriers pursue P2P: Verizon and P2P </li></ul><ul><ul><li>http://telephonyonline.com/access/news/telecom_verizon_pursues_pp/ </li></ul></ul><ul><li>IEEE (P2PHD) P2P for Handheld Devices: Motorola, Nokia and others </li></ul><ul><ul><li>research.nokia.com/events/ p2p .html </li></ul></ul>
  16. 16. P2P SIP Protocol Layers Overlay Network Internet SIP applications L4 Transport (UDP, TCP) L3 IP Network Legend DHT: Distributed Hash Table IM: Instant Messaging DHT Layer TCP/IP VoIP, Video Presence IM File Transfer Applications L5
  17. 17. SIP Session Setup Options <ul><li>Discovery of remote address </li></ul><ul><li>Setting up the session </li></ul>Legend DNS: (Internet) Domain Name System PBX: Private Branch Exchange URI: Uniform Resource Identifier SIP messages: INVITE, 180, 200 OK, ACK <ul><li>Get URI of destination out of band: </li></ul><ul><li>Business card </li></ul><ul><li>E-mail </li></ul><ul><li>Phone call </li></ul>Query DNS for IP address Query one SIP proxy server (PBX) Query chain of SIP proxy servers (service providers) Query another SIP peer node in P2P SIP Caller Called INVITE 200 OK ACK RTP media packets 180 Ringing (or 183 Session Progress) Caller IP/port for media and codec choices Called IP/port for media and selected codec Time until callee answers
  18. 18. CS (a) and P2P (b) SIP Location Discovery Legend SRV: DNS Server Resource Locator (RFC 2782) NAPTR: Network Authority Pointer (RFC 3403) ENUM: E164 Telephone Number Mapping Service (RFC 3764) SIP UA Outbound Proxy SIP UA Inbound Proxy DNS DNS SRV & A queries ENUM: NAPTR, SRV & A queries DB query INVITE INVITE INVITE Caller Called a. Location DB b. Location INVITE 1 2 3 4 5 6 Caller Called API SIP SIP SIP SIP DHT DHT DHT DHT
  19. 19. P2P SIP System Legend CN: Client node PN: Peer (various functions) Proxy: SIP proxy server, is another PN Concepts and Terminology for Peer to Peer SIP, < draft-ietf-p2psip-concepts > P2P SIP Peer protocol Client protocol PN PN PN CN CN CN CN CN CN CN CN CN Proxy DNS CS SIP Enrollment Server Bootstrap Server(s) other PSTN PN
  20. 20. Some requirements for global markets <ul><li>Standards based: Interoperates with global SIP services and devices </li></ul><ul><li>SIP/RTP gateways to wireline and wireless networks </li></ul><ul><li>Fully auditable security </li></ul><ul><li>Logs for usage statistics </li></ul><ul><li>All market segments: Internet companies, enterprise networks, consumer devices </li></ul><ul><li>Global footprint – Internet style </li></ul>Note: Telecom carriers and cable operators have mostly local markets Internet companies have the global market
  21. 21. Simple usage scenario for SIP <ul><li>An alternative to present SIP CS usage (complex) </li></ul><ul><li>Tool set for implementations includes NAT traversal, ID, encryption </li></ul><ul><li>Applicable for CS and P2P SIP </li></ul><ul><li>SIP for message routing only (~10 ref’s + info’s) </li></ul><ul><li>All applications reside in endpoints </li></ul><ul><li>Eliminate all “network services” </li></ul><ul><ul><li>All extensions to support business models (roaming charges, Centrex, SBC, etc.) </li></ul></ul><ul><ul><li>Ever new business models: </li></ul></ul><ul><ul><ul><li>Is not scalable, </li></ul></ul></ul><ul><ul><ul><li>Not applicable for everyone </li></ul></ul></ul><ul><ul><li>Avoid complexity in SIP routing: Unaware of apps </li></ul></ul><ul><ul><li>Avoid any awareness of user data and the associated policies in network elements </li></ul></ul>http://www.ietf.org/internet-drafts/draft-sinnreich-sip-tools-01.txt
  22. 22. What P2P SIP IS NOT is just as important <ul><li>Not another VoIP softphone or IM client </li></ul><ul><li>Not another VoIP network </li></ul><ul><li>Not another IM network </li></ul><ul><li>Not a proprietary vertical stack </li></ul><ul><li>No shortcuts in network protocols </li></ul><ul><li>Not a customized product* </li></ul><ul><li>No multiple models* </li></ul>Multimedia communications (voice) is a convenient “killer” application, there are however many other * The GUI and the communications apps are accessible via the API
  23. 23. Part 2: P2P Overlay Networks and Distributed Hash Tables (DHT)
  24. 24. Secure Hash Algorithm SHA-1 “it is computationally infeasible 1) to find a message that corresponds to a given message digest, or 2) to find two different messages that produce the same message digest. Any change to a message will, with a very high probability, result in a different message digest.” When a message of any length < 2^64 bits is input, the output is a message digest of 160 bits. Ref: RFC 3174 and http://en.wikipedia.org/wiki/SHA-1 A word equals a 32-bit string which may be represented as a sequence of 8 hex digits. To convert a word to 8 hex digits each 4-bit string is converted to its hex equivalent. Example: 1010 0001 0000 0011 1111 1110 0010 0011 = A103FE23 The SHA1 hash function exhibits good avalanche effect. When a single bit is changed the hash sum becomes totally different
  25. 25. DHT Example: Chord <ul><li>A virtual ring of the size 2 ^m is used for the routing of messages between the nodes </li></ul><ul><li>m=160 bits for Chord </li></ul><ul><li>The size for 2 ^160 is N=1,461,501,637,330,900,000,000,000,000,000,000,000,000,000,000,000 </li></ul><ul><li>Every node in the ring is responsible for storing the content for the keys having a nodeID that is in value between its predecessor and itself </li></ul><ul><li>The key is the SHA-1 hash of the content. </li></ul><ul><li>Same hash space for IP addresses and any other data: </li></ul><ul><ul><li>Content = IP address of a peer node, or </li></ul></ul><ul><ul><li>Content = some other data </li></ul></ul>Ref: http://pdos.csail.mit.edu/chord/ http://pdos.csail.mit.edu/papers/chord:sigcomm01/chord_sigcomm.pdf Examples: key: H{ alice@example.com} Returns content: IP address key: H{ voice_mail@example.com} Returns content: an audio file Responsibility of node n Responsibility of node n Node ID=n Predecessor of node n Node ID=n Predecessor of node n Node ID=n Predecessor of node n 2 ^m-1 0 2 ^m-1 0 2 ^m-1 0
  26. 26. Frequent Joins and Leaves in Chord <ul><li>Join (of node n) </li></ul><ul><li>Keys previously assigned to the successor of node n are now assigned to n </li></ul><ul><li>Leave (of node n) </li></ul><ul><li>Keys assigned to n are reassigned to its successor on the ring </li></ul><ul><li>Stabilization procedure </li></ul><ul><li>Each node runs a frequent stabilization procedure </li></ul><ul><li>Updating the finger table and the pointer to the successor </li></ul><ul><ul><li>Ask successor about its predecessor </li></ul></ul><ul><ul><li>Check predecessor </li></ul></ul><ul><ul><li>Fix the routing table entries: Find the successor of (n+2 k-1 ) </li></ul></ul>Ref: Security considerations for P2P-SIP by Jan Seedorf http://www.informatik.uni-hamburg.de/SVS/research/projects/voip/index.php
  27. 27. Joining Procedure in Chord <ul><li>The joining node n computes its node ID </li></ul><ul><li>Node n calls find_successor to find the node currently responsible for its ID, this node is s n </li></ul><ul><li>Node n notifies its successor s n it is the predecessor and s n enters n in its routing table </li></ul><ul><li>The predecessor of n, p n learns about n the next time it runs the stabilize procedure and enters it in its routing table </li></ul><ul><li>p n notifies n as its predecessor and n enters p n as its predecessor </li></ul>Ref: Security considerations for P2P-SIP by Jan Seedorf
  28. 28. Chord Extensions for Robustness Against Node Failure <ul><li>Correctness of Chord relies in each node knowing its direct successor </li></ul><ul><li>Robustness against node failure can be increased by the following </li></ul><ul><ul><li>Store the first redirect successors in the routing table </li></ul></ul><ul><ul><li>Replicate all content in r direct successor nodes </li></ul></ul><ul><ul><li>If the immediate successor fails, the next successor can be used </li></ul></ul><ul><ul><li>If each node fails independently with probability p, then all successor nodes fail with probability p r </li></ul></ul><ul><ul><li>The higher r, the smaller p r </li></ul></ul>Ref: Security considerations for P2P-SIP by Jan Seedorf
  29. 29. Comparing P2P Overlays - 1 <ul><li>Basic classification of P2P networks </li></ul><ul><ul><li>Pure P2P </li></ul></ul><ul><ul><ul><li>Hybrid, with a central server (Napster) </li></ul></ul></ul><ul><ul><ul><li>Pure; no central server (KaZaA) </li></ul></ul></ul><ul><ul><li>Structure </li></ul></ul><ul><ul><ul><li>Unstructured (Gnutella) </li></ul></ul></ul><ul><ul><ul><li>Structured (CAN, Chord, Kademlia, Pastry, Tapestry) </li></ul></ul></ul><ul><ul><ul><li>Hybrid centralized and decentralized (JXTA) </li></ul></ul></ul><ul><ul><ul><li>Windows P2P networking (Vista) </li></ul></ul></ul>Wikipedia, http://en.wikipedia.org/wiki/P2P_network “ A Survey and Comparison of Peer-to-Peer Overlay Network Schemes” by E. K. Lua at al., IEEE Communications Survey, March 2004. http://www.cl.cam.ac.uk/teaching/2005/AdvSysTop/survey.pdf “ A performance vs. cost framework for evaluating DHT design tradeoffs under churn” by J. Li et all. MIT, 2002. http://pdos.csail.mit.edu/papers/dhtcomparison:infocom05/paper.pdf http://www.microsoft.com/technet/network/p2p/default.mspx
  30. 30. Comparing P2P Overlays - 2 <ul><li>Maturity (from a commercial product perspective) </li></ul><ul><ul><li>More than just basic routing </li></ul></ul><ul><ul><ul><li>Neighbors in the ID space (leafs) </li></ul></ul></ul><ul><ul><ul><li>Neighbors by various metrics (delay, hop count, bandwidth) </li></ul></ul></ul><ul><ul><ul><li>Robustness </li></ul></ul></ul><ul><ul><ul><ul><li>Churn </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Network impairments </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Non-transitive connectivity </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Instabilities </li></ul></ul></ul></ul></ul><ul><ul><ul><li>Security </li></ul></ul></ul><ul><ul><ul><ul><li>Threat models </li></ul></ul></ul></ul><ul><ul><ul><ul><li>% of evil nodes that can be tolerated </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Designing for security </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Constrained P2P routing </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Strong authentication </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Trust </li></ul></ul></ul></ul></ul><ul><ul><li>Platform for various applications: The openDHT* </li></ul></ul>*http://opendht.org/pubs.html
  31. 31. Comparing Routing Geometries and Algorithms <ul><li>DHT design choices </li></ul><ul><li>Geometry and algorithm </li></ul><ul><ul><li>Tree </li></ul></ul><ul><ul><li>Hypercube (n-dimensional grid) </li></ul></ul><ul><ul><li>Butterfly (emulates butterfly switch) </li></ul></ul><ul><ul><li>Ring </li></ul></ul><ul><ul><li>XOR metric </li></ul></ul><ul><li>Static resilience: How well DHT works before routing state is restored </li></ul><ul><ul><li>Data replication: No data loss </li></ul></ul><ul><ul><li>Routing recovery: Repopulate tables </li></ul></ul><ul><li>Path Latency </li></ul><ul><ul><li>PNS closest by latency </li></ul></ul><ul><ul><li>PRS tradeoff hops vs. latency </li></ul></ul><ul><li>Local convergence: Underlying latency </li></ul><ul><ul><li>Overlay multicast: Length of paths </li></ul></ul><ul><ul><li>Caching: Neighbor use cached content </li></ul></ul><ul><ul><li>Server selection: Using stored pointers </li></ul></ul>K. Gummadi et al: “The Impact of DHT Routing on Resilience and Proximity”.SIGCOMM’03, August 2003, Karlsruhe, Germany <ul><li>DHT design categories </li></ul><ul><li>Routing behavior in choosing neighbors and routes </li></ul><ul><li>System behavior is everything else such as iterative/recursive, caching and replication </li></ul><ul><li>The DHT Selection criteria is the flexibility in the selection of neighbors and routes </li></ul><ul><li>“ The ring geometry allows the greatest flexibility and achieves the best resilience and proximity performance” </li></ul>
  32. 32. The limitations of DHT overlays <ul><li>DHT’s are suitable for two important application domains: </li></ul><ul><li>Store small amounts of data with high availability for peers with highly dynamic membership , or </li></ul><ul><li>Large data repository with low maintenance cost for relatively stable nodes as in the openDHT </li></ul>“ openDHT: A Public DHT Service, Ph.D. Thesis by Sean C. Rhea, 2005 http://srhea.net/papers/rhea-thesis.pdf Bandwidth = S/NT Average node lifetime in seconds T Total data stored, S = rD S Unique data bits stored D Redundancy to fault tolerance r Size of the system in number of nodes N
  33. 33. Example Deployment Scenarios for P2P SIP There is a large deployment area service providers and IT for stable peers to support big data sets Low Short High Mobile phone, PDA None Client Battery WiFi Phone & GWY Desktop PBX phone BEHAVE compliant Enterprise IAD Residential GWY Phone adapter High Long Low Stable PC Low Short Medium Any Peer Moving Laptop IP Quality Session time Churn Rate NAT Scenario DHT Protocol Critical Operation Deployment Scenario hard easy
  34. 34. Performance measurements on the openDHT http://www.arl.wustl.edu/~jst/cse/570/files/10-2-2006a-Andrew_Wan.pdf a. Long running performance and availability of the openDHT for about one year on about 210 nodes b. Latency of ReDirR lookups and openDHT gets
  35. 35. Pastry routing from peer 37A0F1 with key B57B2D Live peers B581F1 Route to: B57B2D 1. Match prefix 2. Closest match for same prefix “ A Survey and Comparison or Peer-to-Peer Overlay Network Schemes” by E. K. Lua at al., IEEE Communications Survey, March 2004. B 24EA3 B5 324F B57 3AB 37A0F1 Where is B57B2D ? B57B2D B57 3D6
  36. 36. Lookup performance for Pastry “ Pastry: Scalable, decentralized object location and routing” by A. Rowstron and P. Druschel. ACM, Heidelberg, Nov. 2001 b=4, L=16, M=32 for 200,000 lookups (close to log 2 b (N) steps) L=16, 100k random queries, 100k nodes
  37. 37. Lookup (routing) in Pastry and Bamboo “ Handling Churn in a DHT”: http://srhea.net/papers/bamboo-usenix-talk.ppt <ul><li>Long hop routing </li></ul><ul><li>Routing Table </li></ul><ul><li>Greedy, efficient routing </li></ul><ul><li>Successive longer prefixes </li></ul><ul><li>O(log 2 b (N)) hops </li></ul><ul><li>Each node has two sets of neighbors: </li></ul><ul><li>Immediate leaf neighbors in the key space </li></ul><ul><ul><li>Important for correctness </li></ul></ul><ul><li>Long hop neighbors </li></ul><ul><ul><li>Several metrics </li></ul></ul><ul><ul><ul><li>Latency </li></ul></ul></ul><ul><ul><ul><li>Routing hops </li></ul></ul></ul><ul><ul><ul><li>Bandwidth </li></ul></ul></ul>0… 10… 110… 111… Leaf set and proximity neighbor selection (PNS) Find this node
  38. 38. Routing table of Pastry peer with nodeID 37A0x … 37AFx 37AEx 37ADx 37ACx 37ABx … 37A2x 37A1x 37A0x … 37Fx 37Ex … 37Bx 37Ax … 372x 371x 370x … 3Fx 3Ex … 38x 37x … 32x 31x 30x … Fx Ex Dx … 4x 3x 2x 1x 0x IP addresses are not shown “ A Survey and Comparison or Peer-to-Peer Overlay Network Schemes” by E. K. Lua at al., IEEE Communications Survey, March 2004.
  39. 39. Routing state of a Pastry peer b=4, L=16, M=32 (IP addresses are not shown) “ A Survey and Comparison or Peer-to-Peer Overlay Network Schemes” by E. K. Lua at al., IEEE Communications Survey, March 2004. 199ABC 28989C 267221 221145 19902D 16228A 122167 11345B 5213EA 510A0C 290A0B 279DE0 490CDE 4881AB 477810 46710A 3912CD 390AF0 37890 3612AB 2670AB 245AD0 1B3467 1A223B Neighborhood set M 37A0FE 37A0FC 37A0FB 37A0FA 37A0F8 37A0F6 37A0F4 37A0F2 Leaf set (larger) 37A077 37A066 37A055 37A044 37A033 37A022 37A011 37A001 Leaf set (smaller) nodeID 37A0F1
  40. 40. Pastry: Node addition d46a1c Route(d46a1c)? d46 2ba d4 213f d 13da3 65a1fc d46 7c4 d4 71f1 New node : d46a1c
  41. 41. Part 3: High Performance P2P
  42. 42. Bamboo A variation of Pastry <ul><li>OpenDHT service (well optimized) </li></ul><ul><li>Modules </li></ul><ul><ul><li>Router: routing-table, leaf-set, cache. Iterative+recursive. </li></ul></ul><ul><ul><li>Messages: join-request/response, leaf-set-changed, routing-table-request, ping-request, neighbor-announce, … </li></ul></ul><ul><ul><li>DHT: put, get, remove. Fairness for disk quota </li></ul></ul><ul><ul><li>Gateway: for clients to use the service </li></ul></ul><ul><ul><li>DataManager: replication of stored data on leaf set </li></ul></ul><ul><ul><li>DB: high-performance, embedded database library from Berkeley </li></ul></ul><ul><ul><li>Network: congestion controlled UDP </li></ul></ul><ul><ul><li>Async event architecture </li></ul></ul><ul><ul><li>ReDiR: client side library for service interface </li></ul></ul><ul><li>Soft-state: Failures and timeouts </li></ul><ul><li>Proximity neighbor selection for various metrics: </li></ul><ul><ul><li>Latency </li></ul></ul><ul><ul><li>Routing hops </li></ul></ul><ul><ul><li>Bandwidth </li></ul></ul><ul><li>… </li></ul>Ref: Kundan Singh, Adobe Systems, 2007
  43. 43. Interfaces to Bamboo in the openDHT <ul><li>Routing interface: General access to the gateway node and to each node along the routing path </li></ul><ul><ul><li>This is the most general interface and can support DHT-based multicast </li></ul></ul><ul><ul><li>Possible the greatest potential for innovative P2P SIP applications </li></ul></ul><ul><ul><li>Requires security against malicious peers </li></ul></ul><ul><li>Lookup interface: General access only to the DHT node responsible for the input key </li></ul><ul><ul><li>Useful as a query interface for SIP, file systems, indirection services, other apps </li></ul></ul>Ref: OpenDHT: “A Public DHT Service and Its Uses” by S. Rhea et al. http://www.intel-research.net/Publications/Pittsburgh/092620050725_326.pdf
  44. 44. Interfaces to Bamboo in the openDHT <ul><li>Storage interface*: Support for only put(key, value) and get(key) operations by routing them to the node responsible for the input key </li></ul><ul><ul><li>Least flexible but very useful for such as data storage, voice mail </li></ul></ul><ul><ul><li>Public storage facility with refresh and garbage collection </li></ul></ul><ul><ul><li>Content distribution </li></ul></ul><ul><ul><li>Simple for programmers, simple to support in clients </li></ul></ul><ul><ul><li>Recursive Distributed Rendezvous (ReDiR) for greater flexibility and similar functionality to the lookup interface can support a variety of applications** </li></ul></ul><ul><ul><li>Easiest to secure </li></ul></ul><ul><ul><li>Soft state using TTL (known refresh) or expiration time t depending on the interface type (t for authenticated use) </li></ul></ul><ul><li>Other: </li></ul><ul><ul><li>smart DNS interface to openDHT: Find openDHT nearest to you using the Oasis*** overlay </li></ul></ul>*http://www.intel-research.net/Publications/Pittsburgh/092620050725_326.pdf **http://www.arl.wustl.edu/~jst/cse/570/files/10-2-2006a-Andrew_Wan.pdf ***http://www.opendht.org/users-guide.html
  45. 45. Routing Styles in DHT Routing control at source Is slower Can check routing integrity: better security Higher message traffic at Source Hop by hop routing* Is faster Cannot check routing integrity higher vulnerability Lower message traffic at Source *Routing control is possible through the data interface in ReDiR Source A Root B Iterative routing A B Source Root Recursive routing
  46. 46. The use of routing styles in Bamboo (delay aware routing) <ul><li>The basic algorithm routes greedily through the key space </li></ul><ul><li>Node selects neighbors based on application-level pings </li></ul><ul><ul><li>Burst load may make a neighbor suddenly to become slow </li></ul></ul><ul><ul><li>Maintenance algorithm adapts to such changes (gradually for stability) </li></ul></ul><ul><li>Design: </li></ul><ul><ul><li>Greedy routing for RTT<100 ms </li></ul></ul><ul><ul><li>Minimize per hop delay routing for >100ms </li></ul></ul><ul><ul><li>Iterative routing allows to parallelize and avoid a slow peer: A gateway into the overlay can maintain several outstanding searches. </li></ul></ul><ul><ul><li>Reduction of RTT from 4s for recursive routing to 0.4s using iterative routing on Planet Lab. </li></ul></ul>Ref: “Fixing the Embarrassing Slowness of OpenDHT on PlanetLab” by S. Rhea et. al. Proceedings of Worlds ’05. http://srhea.net/papers/opendht-worlds05.pdf
  47. 47. Reducing the DHT latency due to slow nodes “ Fixing the Embarrassing Slowness of openDHT on PlanetLab” by S. Rhea et all. WORLDS ’05 Conference, http://srhea.net/papers/opendht-worlds05.pdf <ul><li>There is a variable population of slow nodes due to heavy sharing </li></ul><ul><li>Slow disk reads and slow RSA key computations have a long tail into seconds </li></ul><ul><li>Modifying the Bamboo algorithm to cope with slow nodes: </li></ul><ul><li>Delay aware routing: Greedy for <100ms RTT + minimize per hop delay for >100 ms </li></ul><ul><li>Iterative routing – several outstanding requests simultaneously, use the fast response </li></ul><ul><li>Use multiple gateways in parallel </li></ul>Experimental results on Planet Lab 332 196 62 86 Greedy p=2 Iterative 1-3 8,113 490 186 434 Original algorithm 99th 90th 50th Average Mode parallel I/R Gwys Latency (ms) Routing parameters
  48. 48. Non-transitive connectivity in DHTs <ul><li>Invisible Nodes: Node learns about another node but cannot reach it </li></ul><ul><li>Routing loops: Lookup skips the target – routing proceeds around the ring </li></ul><ul><li>Broken return path: No direct route from root back to source </li></ul><ul><li>Inconsistent roots: Lookup from different sources produces different routes </li></ul><ul><li>Routing fixes have been developed at the expense of higher delay & complexity </li></ul>A can communicate with B B can communicate with C C cannot communicate with A Example for a 300 node Chord overlay: Each pair of adjacent nodeIDs have 0.1% chance of no communications 1-0.999 300 ~ 26% chance that some pair will not communicate 0.999 2 of both nodes have a chance to communicate w. immediate predecessor Ref: “Non-Transitive Connectivity and DHTs”, http://srhea.net/papers/ntr-worlds05.pdf A B C
  49. 49. Handling Churn and Failures in Bamboo <ul><li>New approach based on extensive simulations and trials on OpenDHT </li></ul><ul><li>Choose neighbors for network proximity </li></ul><ul><ul><li>Minimizes latency </li></ul></ul><ul><li>Route quickly around suspected failures </li></ul><ul><ul><li>Abnormal latency indicates failure or congestion </li></ul></ul><ul><ul><li>Route around it before we can tell the difference </li></ul></ul><ul><li>Recover failed neighbors periodically </li></ul><ul><ul><li>Keeps network load independent of churn rate </li></ul></ul><ul><ul><li>Prevents positive feedback cycles </li></ul></ul>“ Handling Churn in a DHT”: http://srhea.net/papers/bamboo-usenix-talk.ppt
  50. 50. Performance with smart timeouts Estimating when it is time to route around a failed node “ Handling Churn in a DHT”: http://srhea.net/papers/bamboo-usenix-talk.ppt The best results were obtained with TCP-style timers, by keeping a history of past timeouts and use this to compute timeouts for new requests. This approach works best for recursive lookups where peers are talking only to their neighbors and as a consequence there is only a small and current history to deal with.
  51. 51. Smart recovery of neighbor list Reactive recovery is expensive under churn Excessive bandwidth consumption leads to overload and long latencies “ Handling Churn in a DHT”: http://srhea.net/papers/bamboo-usenix-talk.ppt Bandwidth consumption Latency Two 20 minute churn periods of 47 and 23 minute median session times separated by 5 minutes without churn
  52. 52. Security for structured P2P overlays Ref: “Secure routing for structured peer-to-peer overlay networks” by M. Castro et al. http://www.cs.rice.edu/~dwallach/pub/osdi2002.pdf <ul><li>Mutually distrusting parties with conflicting interests must be able to join </li></ul><ul><li>A fraction of nodes act maliciously: </li></ul><ul><ul><li>Misroute, corrupt or drop messages and routing information </li></ul></ul><ul><ul><li>False identities </li></ul></ul><ul><ul><li>Corrupt or delete data </li></ul></ul><ul><li>DHT secure routing requirements </li></ul><ul><li>Secure nodeID assignments: NodeIDs cannot be controlled by attacker </li></ul><ul><ul><li>Solution: nodeID certificates obtained at enrollment </li></ul></ul><ul><ul><li>Preventing Sybil attacks (obtaining many certs): Charging, trust, strong ID </li></ul></ul><ul><li>Secure routing table maintenance </li></ul><ul><ul><li>Solution: Constrained, verifiable table (IP+cert) for both types of neighbors </li></ul></ul><ul><li>Secure message forwarding </li></ul><ul><ul><li>Solution: Detect faults with failure tests (probabilities) and use diverse routes </li></ul></ul><ul><li>Self certifying data can reduce the overhead for secure routing </li></ul>
  53. 53. Routing security Model and simulation results for the probability of reaching all correct replica roots using redundant routing. The probability of success is greater than 0.999 for the fraction of faulty nodes <0.3 Ref: “Secure routing for structured peer-to-peer overlay networks” by M. Castro et al. http://www.cs.rice.edu/~dwallach/pub/osdi2002.pdf
  54. 54. Design for P2P Interface Security in the OpenDHT <ul><li>Attacks </li></ul><ul><li>Squatting: Use a valuable key (“coca-cola.com”), similar to domain names </li></ul><ul><li>Drowning: Putting a vast number of values for the same key </li></ul><ul><li>Authentication </li></ul><ul><li>Assumes the existence of a private + public crypto key pair K s , K p </li></ul><ul><li>Verify that an authorized and/or trusted entity wrote a value </li></ul><ul><li>A node protects its own value from overwriting </li></ul><ul><li>Put security </li></ul><ul><li>Key k, value v, nonce n for later removal, expiration time t, digital signature with private key (K s ): σ={H(k,v,n,t)} Ks . H is the SHA-1 function. </li></ul><ul><li>Single key k for all values makes the DHT robust against squatting </li></ul><ul><li>Expiration time t prevents expired puts to be replaced by malicious clients </li></ul><ul><li>Get security </li></ul><ul><li>Key k, hash of public key H(K p ) – prevents drowning </li></ul><ul><li>Remove security </li></ul><ul><li>Remove request with k, H(v), n – need to know k, v and n </li></ul>Ref: OpenDHT: “A Public DHT Service and Its Uses” by S. Rhea et al. http://www.intel-research.net/Publications/Pittsburgh/092620050725_326.pdf
  55. 55. Skype security: Enrollment system <ul><li>Central server has private signing and public verification key pair: S S and V S </li></ul><ul><li>User selects name A and password P A </li></ul><ul><li>User agent generates RSA key pair S A and V A </li></ul><ul><li>S A and H(P A ) are securely stored on the local platform </li></ul><ul><li>Central server operations: </li></ul><ul><ul><li>Checks if user name A is unique and stores A, H(H(P A )) in a database </li></ul></ul><ul><ul><li>Forms and signs an ID certificate IC A for A containing {A, V A } S and the key identifier for S S </li></ul></ul><ul><ul><li>IC A is returned to the user agent A </li></ul></ul><ul><ul><li>Premium services (such as SkypeOut) are issued CA signed with longer keys </li></ul></ul><ul><ul><li>service class is determined by crypto keys </li></ul></ul>http://www.skype.com/security/files/2005-031%20security%20evaluation.pdf
  56. 56. Skype session security <ul><li>Proprietary peer-to-peer key agreement protocol: </li></ul><ul><ul><li>Symmetric to both parties </li></ul></ul><ul><ul><li>64-bit nonce signed with private key for playback protection </li></ul></ul><ul><ul><li>Peers exchange IC and verify their validity </li></ul></ul><ul><ul><li>Peers encrypt messages using RSA </li></ul></ul><ul><ul><li>Each party contributes 128 bits to the 256-bit session key </li></ul></ul><ul><li>Peer-to-peer key agreement with a session key SK AB </li></ul><ul><li>All traffic is encrypted with the session key SK AB , </li></ul><ul><li>Different streams in the session have slightly different 256-bit AES salt </li></ul><ul><li>Various attack scenarios have been analyzed and tested: </li></ul><ul><ul><li>Man in the middle (MITM) attack </li></ul></ul><ul><ul><li>Replay attack </li></ul></ul><ul><ul><li>Password guessing </li></ul></ul><ul><ul><li>Side channel attacks in the UA platform </li></ul></ul><ul><ul><li>Weaknesses reported: ASN1-like parsing of payloads, CRC similar to WEP </li></ul></ul>http://www.skype.com/security/files/2005-031%20security%20evaluation.pdf
  57. 57. A: Contributions to P2PSIP at the 70 IETF (in no particular order for non-HIP based) <ul><li>Peer-to-Peer Protocol (P2PP) </li></ul><ul><li>draft-baset-p2psip-p2pp </li></ul><ul><li>REsource LOcation And Discovery (Reload) </li></ul><ul><li>draft-bryan-p2psip-reload </li></ul><ul><li>A Kademlia-based DHT for Resource Lookup in P2PSIP </li></ul><ul><li>draft-cirani-p2psip-dsip-dhtkademlia </li></ul><ul><li>Service Extensible P2P Peer Protocol </li></ul><ul><li>draft-jiang-p2psip-sep </li></ul><ul><li>An ID/Locator Architecture for P2PSIP </li></ul><ul><li>draft-matthews-p2psip-id-loc </li></ul><ul><li>Extensible Peer Protocol (XPP) </li></ul><ul><li>draft-marocco-p2psip-xpp </li></ul><ul><li>XPP Extensions for Implementing a Passive P2PSIP Overlay Network based on the CAN DHT </li></ul><ul><li>draft-marocco-p2psip-xpp-pcan </li></ul>Search at http://www.rfc-editor.org/idsearch.html Avaya Cisco Ericsson Network Resonance Nokia Huawei SIPeerio Telecom Italia Universities (3)
  58. 58. A: Contributions to P2PSIP at the 70 & 71 IETF (continued) <ul><li>P2PSIP Clients </li></ul><ul><li>draft-pascual-p2psip-clients </li></ul><ul><li>P2PSIP Client Protocol </li></ul><ul><li>draft-zheng-p2psip-client-protocol </li></ul><ul><li>Diagnose P2PSIP Overlay Network Failures </li></ul><ul><li>draft-zheng-p2psip-diagnose </li></ul><ul><li>Security requirements in P2PSIP </li></ul><ul><li>draft-matuszewski-p2psip-security-requirements </li></ul><ul><li>The Komondor Peer to Peer Security System </li></ul><ul><li>draft-czirkos-komondor-p2p-security </li></ul><ul><li>P2PSIP bootstrapping using DNS-SD </li></ul><ul><li>draft-garcia-p2psip-dns-sd-bootstrapping </li></ul>Search at http://www.rfc-editor.org/idsearch.html
  59. 59. Questions and discussion

×