320 likes | 456 Views
MyMed. Overview after meeting @INRIA (29-30/06/2010) Proposed Architecture PROPOSED Technical Solutions Polito Package (WPF2) Details Activities NAT traversal techniques Solution Fixed vs not Fixed SWOT analysis Slot for Open discussion. General Information. HIGHLIGHTS
E N D
MyMed Overview after meeting @INRIA (29-30/06/2010) Proposed Architecture PROPOSED Technical Solutions Polito Package (WPF2) Details Activities NAT traversal techniques Solution Fixed vs not Fixed SWOT analysis Slot for Open discussion
MyMed WPF2 - Polito General Information • HIGHLIGHTS • The project MyMed will be deployed within the ALCOTRA region. • MyMed is a network for the exchange of contents in a fixed and mobile environment • 5500 users* • 60 services* • 50 machines (Desktop PC) will be installed and will form the Back Bone (BB) of the system. • 25 PC in France / 25 PC in Italy ALCOTRA Region * Expected figures after 3 years
Remarks: • The services are not fully defined yet • The definition of the first set of services to be implemented is also pending • Proposal: start with MyTranslator & MyAngel (both of them are easy to implement and they can benefit from GPS and possibly geo-localization) MyMed WPF2 - Polito MyMenu MyTranslator MyAngel MyJam … … MyLocalProducer … MyJob MyCarShare MyMedServices(some examples)
MyMed architecture is based on a P2P backbone (BB) based on a DHT algorithm: • DHT type to be finalized (Chord, Kademlia, Cassandra, …) • Users interaction with DHT*: • Login /Logout into MyMed • Add/Remove a Service • Publish a content • Search a content • Subscribe an event • Receive notifications • … • Each Node/User have their own internet connection • Potentially each one in under a different subnet • Users access to the BB with wired, wireless, 3G connections using desktop, laptop or smart phones MyMed WPF2 - Polito MyMed Proposed Architecture FRANCE ITALY Internet 3G BB Node located in France BB Node located in Italy Desktop User Notebook User SmartPhone User Super Peers Clients or Peers * Users interaction with the DHT not fully defined yet
In order to simplify the complexity of the system we propose to divide the implementation in 2 steps. This road map will allow us also to deploy some services in advance, having as a result earlier feedbacks from the users and earlier problem discovery. MyMed WPF2 - Polito Proposed MyMed implementation in 2 steps Phases Proposed Solutions Hot points Login server and entry point selection algorithm have to guarantee load balancing • Only BB nodes (Super Peers from now on) belongs to the P2P • User first authenticates through a Login Server • Login Servers Set is a subset of the Super Peer Set • Once authenticated, users access the DHT through a Super Peer as single point on entry • The point of entry is selected at each session by the Login Server Step 1 Selection algorithm should balance among node reliability, node capacity and user reputation Login servers must track selected nodes • Selected nodes (Peers) joins the DHT and can: • Become entry point for “external nodes” • Bear selected content • Offer a specific service Step 2
The service that runs on MyMed must be 100% reliable, hence we cannot tolerate loss of data • User connection is not always stable (wireless, 3G) • User may decide to disconnect “ungracefully” at any time • User hardware may fail • A strong fault tolerance method with 100% reliability is needed among Super Peers • The storage capability of selected users (Peers) must not be used to store unique data. In other words, user nodes can be used only for redundancy . Of course, their computational power as well their connectivity can be exploited MyMed WPF2 - Polito “On exploiting User Nodes” Leading Point Facts Results
MyMed WPF2 - Polito Node Profile view by Steps STEP 1 STEP 2 Main Functions Load balancing Authentication Redirection to a SP Content storage Rendezvous server Direct DHT Access Servers of Clients Content storage Rendezvous server Direct DHT Access Redundancy storage Access through SP - - - Every profile can access MyMed and uses services - - -
MyMed WPF2 - Polito SmartPhone Market Share Results 2010 Q1 Forecast 2012 • HIGHLIGHTS: • By 2012 Symbian + Androis + iPhone will build up more than 60% of the total smartphone sells • A MyMed specific client should be developed for each of these platform in order to penetrate the market • RIM = BlackBerry • Source Gartner
MyMed WPF2 - Polito MyMed proposed clients architecture UI HTML -- AJAX -- JSCRIPT -- Browser Local host:80 - - Packages- - -- Lite Web Server -- Virtualization Client -- P2P Client -- Transport -- Reputation Client -- Security I-Phone MyMed Peer Notebook -- P2P Client -- Transport -- Reputation Cl. -- Security MyMed Mobile Internet Android MyMed P2P Desktop Implementation with SDK Implementation C++/JAVA Browser - - Packages - - • The architecture is as for Peer. • The MyMedPeer module will be replaced with MyMedSuperPeer • Each package has enhanced functions to manage the Login server and SuperPeer role MyMed SuperPeer -- Web Server -- Virtualization -- P2P BB -- Transport -- Reputation -- Security SmartPhone OtherOS MyMed P2P BB Node Simple Web Client Server
The main objective of this module is to guarantee the connectivity among P2P nodes • Connect(), Disconnect() services • The majority of the hosts are nowadays behind Network Address Translator (NAT) • A Host behind a NAT is not directly reachable, thus P2P application does not work using simple connections. • The connectivity will be guaranteed by Nat Traversal Techniques suitable for P2P systems [1]. However will be required that a certain number of BB nodes have a public and reachable IP (login server, randezvous server,…) MyMed WPF2 - Polito My Med draft layered view User Interface Virtualization Security P2P Overlay Reputation Transport Overlay Transport {TCP, UDP} IP MAC {802.3, 802.11, UMTS} My Med packages Existing packages
Polito will do the following main technical activities: • Development of the transport underlay package for MyMedPeer and MyMedSuperPeer • NAT traversal (STUN [2][3], STUNT[4], ICE[5], … ) • Relaying (TURN[6],…) • Cooperate in service definition and analysis • Mobility support: • Information dissemination through mobile nodes* • Caching techniques on user nodes* • Development of MyMedPeer also for: • Android[7] • Symbian[8] • Cooperate in Testing, User farming, demos MyMed WPF2 - Polito Polito package (WP2) Details * Implementation according to viability and service needs
Definition • Network Address Translation (NAT) is the process of modifying network address information in datagram (IP) packet headers while in transit across a traffic routing device for the purpose of remapping one IP address space into another. • Avoid using public IP addresses for internal space • Greater security as inbound traffic in not allowed • Simple NAT: only the IP address is translated • NAPT/NAP: in Network Address Port Translation also the port is re-mapped (a.k.a IP masquerading) MyMed WPF2 - Polito Network Address Translation (NAT) NAPT Example
MyMed WPF2 - Polito NAT Types
NAT behaviour is not standardized • Actual implementation depends on vendor • The IETF group BEHAVE [9] specify in the RFC 4787 the rules enabling NAT to be “application friendly”. The rules include: • Binding Management • Packet filtering policy • Deterministic behavior MyMed WPF2 - Polito NAT Consideration
Assumptions: We do not consider here the cooperation of NAT hardware with zeroconf protocols such as UPnP Internet Gateway Devices (IGD)[10], Bonjour (Apple), etc.. as they are fragmented (OS dependent) and not widely diffused. Instead, we will consider the following viable options: Relaying Hole punching MyMed WPF2 - Polito How to traverse NAT in a real scenario? Typical Scenario
Relaying consist in exploiting a public server S and use it to relay all the traffic between the peers Relaying Key Idea: Achieve communication through a public server S to which both Clients (Peers) can connect to Advantages: Works for any NAT implementation given that both client can connect to the server Drawbacks: Load on server S due to relayed traffic Latency of communication increases Single point of failure The protocol TURN RFC 5766 implements relaying in a secure fashion. MyMed WPF2 - Polito Traversing NAT with relaying NAPT Example
Connection reversal is a simple technique used to allow direct P2P communication using a well-known rendezvous server S when only one Client is behind a NAT: • The connection from A to B is straight forward • The connection from B to A is achieved by asking A to do a reverse connection to B through S Connection Reversal Key Idea • Use a well-known rendezvous server S to deliver the Connection request Advantages • Works with any type of NAT Drawbacks • Requires one node to be not NATed MyMed WPF2 - Polito Connection Reversal Connection Reversal scenario
UDP hole punching enables two clients to set up a direct peer-to-peer UDP session with the help of a well-known rendezvous server, even if the clients are both behind NATs. Hole Punching Key Ideas Use a well-known rendezvous server S to let the peers know about the other end internal and external endpoint Once the know each other, both peers try to reach each other using both the internal and the external endpoint, creating a “hole” in the NAT Advantages Work with both nodes behind a NAT Does not require the rendezvous server S to relay traffic Drawbacks Requires not symmetric NAT MyMed WPF2 - Polito Traversing NAT with Hole punching UDP…
Suppose client A wants to establish a UDP session directly with client B: A initially does not know how to reach B, so A asks S for help establishing a UDP session with B. S replies to A with a message containing B’s public and private endpoints. At the same time, S uses its UDP session with B to send B a connection request message containing A’s public and private endpoints. Once these messages are received, A and B know each other’s public and private endpoints. When A receives B’s public and private endpoints from S, A starts sending UDP packets to both of these endpoints, and subsequently “locks in” whichever endpoint first elicits a valid response from B. Similarly, when B receives A’s public and private endpoints in the forwarded connection request, B starts sending UDP packets to A at each of A’s known endpoints, locking in the first endpoint that works. The order and timing of these messages are not critical as long as they are asynchronous. Remark: This algorithm does not work with symmetric NAT MyMed WPF2 - Polito …Traversing NAT with Hole punching UDP …
Scenario 1: A and B are under the same NAT. It works in any NAT condition MyMed WPF2 - Polito … Traversing NAT with Hole punching UDP …
Scenario 2: A and B are under different NAT. It works if both NAT are not symmetric MyMed WPF2 - Polito … Traversing NAT with Hole punching UDP …
Scenario 3: A and B are under a common NAT. It work if both NAT are not Symmetric and the common NAT device implements hairpin/loopback translation MyMed WPF2 - Polito … Traversing NAT with Hole punching UDP (iii)
Same protocol of UDP, but: • The sockets must be used with the SO_REUSEADDR option which allows the application to bind multiple sockets to the same local endpoint • On BSD also the option SO_REUSEPORT have to be specified • The application have to open 4 sockets in the same local port • In a view of avoiding to open multiple sockets in parallel, a sequenced hole punching technique can be implemented but it increases the total time for the hole punching procedure • The application have to handle different cases: • NAT active/passive SYN drop • Simultaneous TCP open MyMed WPF2 - Polito Traversing NAT with Hole punching TCP Socket to be opened to implement hole punching
3 well known server must be used: • The client pings S1 and S2. If the external endpoint is conserved, the NAT is address independent (cone NAT) • Otherwise it is a symmetric NAT • Server 2 sends the Client’s endpoint to Server 3, who tries to reach the client. If succeed the NAT is a full Cone NAT MyMed WPF2 - Polito How a node can discover to be behind a NAT?
Assumptions: • The Login Servers and the DHT bootstrap nodes MUST have a public and reachable IP • Each node learns from login servers whether or not it is behind a NAT, and what NAT type it is • Each node records the NAT type of other nodes (learned through login servers, who propagate variations) Scenario 1: • When a super node SP A which is behind a cone NAT joins the DHT, it has to establish connections with other nodes in the tree. Let’s assume his successor SP B is also behind a cone NAT (full, restricted, port-restricted) • SP A will use a rendezvous Peer or Super Peer P/SP to perform Hole Punching. MyMed WPF2 - Polito Application of NAT traversal in MyMed… P/SP SP A SP B Session A-P/SP Session B-P/SP Direct Session SP A – SP B Cone NAT Cone NAT • Remarks: • The tracking and ranking of available rendezvous server is done by Login Servers • In order to avoid delay in DHT operations, Direct Session among SPs have to be maintained with keepalive messages
Assumptions: • Same as before Scenario 2: • When a super node SP A which is behind a cone NAT joins the DHT, it have to establish connections with other nodes in the tree. Let’s assume his successor SP B is behind a symmetric NAT • SP A will use Relaying, through a rendezvous Peer or Super Peer P/SP having a public IP, to get directly in touch MyMed WPF2 - Polito … Application of NAT traversal in MyMed P/SP SP A SP B Session A-P/SP Session B-P/SP Cone NAT* Symmetric NAT • Remarks: • As before but: • This scenario must be avoided as it will potentially delay all DHT GET and PUT. This means that if possible symmetric NAT should be avoided within the DHT enabled Peer • Only SP should be used as relay in order to guarantee reliability * Hole punching could work with a Full Cone Nat and with Address independent filtering (very rare)
Assumptions: • Same as before Scenario 3: • After authentication, the login server L communicates to the Client C the entry point to MyMed Services (Peer /SuperPeerP/SP) • As P/SP is behind a cone NAT, the login server L will act as rendezvous server to allow hole punching, enabling for the direct communication MyMed WPF2 - Polito … Application of NAT traversal in MyMed L C P/SP Session C-L Session L-S/SP Direct Session C – P/SP Cone NAT Cone NAT
MAIN FIGURES from []: • Login server used for first contact, authentication and for first super node discovery • The client connects to super nodes after login • List of well known super nodes is always available • A connection error is generated if the host cannot contact any super node • User can become super nodes • Skype uses super nodes as rendezvous server using an adapted version of TURN/STUN for NAT traversal • Both TCP and connections an Port 80 are exploited in order to get through firewalls • Relaying is used as last chance MyMed WPF2 - Polito What the others do? A look into Skype
MyMed WPF2 - Polito Solution FIXED vs NOT FIXED FIXED(PROPOSED) NOT FIXED • Base MyMed achitecture • Base SuperPeer and Peer Architecture • BB node OS (Ubuntu) • Stepwise implementation of MyMed • User interface technology (HTML, AJAX, JSCRIPT) • Programming languages (Java, C++) • DHT type and P2P architecture • Virtualization role • Security requirements • User Flows (login, operations) • Other packages services • Start-up services • GNU license type General • Approach for NAT Traversal • Hole punching • Relaying • Mobile OS to consider for specific client development • Android, Symbian • Full NAT traversal procedure • Infrastructure less operation • Dissemination* • Caching* • Italian BB nodes location • Interfaces with other packages Specific * Depending on services specifications
MyMed WPF2 - Polito SWOT Analysis of Polito Package • Well known and semi-standardized NAT traversal techniques available • STUN • TURN • ICE • … • Interfaces with other packages not defined yet as their specific content is not clear yet • No past experience with Android SDK and limited on Symbian Strength Weakness • Build a rock solid transport overlay protocol • Exploit users as rendezvous server • Measure and gather real stats about today’s NAT Opportunities • Possibility to assign to BB nodes public IPs not verified yet • Possible traffic increase due to relaying in case of high percentage of symmetric NAT Threats
Integration of the different node profile in the P2P system (login servers, Super Peers, Peers, Clients) • Storage system within the DHT • Security • Login c credentials • Cryptography of communications • Virtualization • Could this deal with load balancing of login servers and access points for Clients? MyMed WPF2 - Polito Free slot for open discussion
[1] FORD, B., SRISURESH, P., AND KEGEL, D. Peer-to-peer communication across network address translators. In Proceedings of the 2005 USENIX Annual Technical Conference (Anaheim, CA, Apr. 2005) [2] RFC 3489, STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs), J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy, The Internet Society (March 2003) [3] RFC 5389, Session Traversal Utilities for NAT (STUN), J. Rosenberg, R. Mahy, P. Matthews, D. Wing, The Internet Society (October 2008) [4] Saikat Guha and Paul Francis. Simple traversal of UDP through NATs and TCP too (STUNT) (http://nutss.gforge.cis.cornell.edu/) [5] J. Rosenberg. Interactive connectivity establishment (ICE), October 2003. Internet-Draft (Work in Progress) [6] J. Rosenberg, C. Huitema, and R. Mahy. Traversal using relay NAT (TURN), October 2003. Internet-Draft (Work in Progress). [7] http://www.android.com/ [8] http://www.symbian.org/ [9] http://tools.ietf.org/html/draft-ietf-behave-nat-udp-08 [10] UPnP Forum. Internet gateway device (IGD) standardized device control protocol, November 2001. http://www.upnp.org/. MyMed WPF2 - Polito Bibliography