Transcript MyMed - eee - Google Project Hosting

 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
4/9/2016
MyMed WPF2 - Polito
2
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
ALCOTRA Region
•
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
* Expected figures after 3 years
4/9/2016
MyMed WPF2 - Polito
3
MyMedServices
(some examples)
MyMenu
…
MyCarShare
MyLocalProducer
MyTranslator
MyAngel
…
MyJob
MyJam
…
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)
4/9/2016
MyMed WPF2 - Polito
4
MyMed Proposed Architecture
FRANCE
ITALY
 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*:
Internet
3G

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

BB Node located in France
BB Node located in Italy
Super Peers
Desktop User
Notebook User
Potentially each one in under a different subnet
Clients or Peers
 Users access to the BB with wired, wireless, 3G
connections using desktop, laptop or smart
phones
SmartPhone User
* Users interaction with the DHT not fully defined yet
4/9/2016
MyMed WPF2 - Polito
5
Proposed MyMed implementation in 2 steps
 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.
Phases
Proposed Solutions
Hot points
 Only BB nodes (Super Peers from now on) belongs to the P2P
• User first authenticates through a Login Server
o Login Servers Set is a subset of the Super Peer Set
Step 1
• 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
Login server and entry
point selection algorithm
have to guarantee load
balancing
Server
 Selected nodes (Peers) joins the DHT and can:
• Become entry point for “external nodes”
Step 2
• Bear selected content
• Offer a specific service
Selection algorithm
should balance among
node reliability, node
capacity and user
reputation
Login servers must track
selected nodes
4/9/2016
MyMed WPF2 - Polito
6
“On exploiting User Nodes”
Leading Point
 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)
Facts
Results
 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
4/9/2016
MyMed WPF2 - Polito
7
Node Profile view by Steps
STEP 1
STEP 2
Main Functions
SP
SP
Load balancing
Authentication
Redirection to a SP
Content storage
&
Login
Servers
&
Login
Servers
Super
Peers
Rendezvous server
Direct DHT Access
Servers of Clients
Content storage
Super
Peers
(SP)
Rendezvous server
Direct DHT Access
Redundancy storage
Clients
(SP)
Peers
Access through SP
Clients
- - - Every profile can access MyMed and uses services - - -
4/9/2016
MyMed WPF2 - Polito
8
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
4/9/2016
MyMed WPF2 - Polito
9
MyMed proposed clients architecture
UI
HTML -AJAX -JSCRIPT --
Browser
Local host:80
Notebook
MyMed
Peer
Internet
Desktop
Android
- - Packages- -- Lite Web Server
-- Virtualization Client
-- P2P Client
-- Transport
-- Reputation Client
-- Security
MyMed
P2P
MyMed
Mobile
I-Phone
-- P2P Client
-- Transport
-- Reputation Cl.
-- Security
Implementation with SDK
Implementation C++/JAVA
- - Packages - The architecture is as for Peer.
 The MyMedPeer module will be replaced with
MyMedSuperPeer
BB Node
 Each package has enhanced functions to
manage the Login server and SuperPeer role
MyMed
SuperPeer
-- Web Server
-- Virtualization
-- P2P BB
-- Transport
-- Reputation
-- Security
Browser
SmartPhone
OtherOS
MyMed
P2P
Simple Web Client Server
4/9/2016
MyMed WPF2 - Polito
10
My Med draft layered view
User Interface
Virtualization
Security
P2P Overlay
Reputation
Transport Overlay
Transport {TCP, UDP}
IP
 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,…)
MAC {802.3, 802.11, UMTS}
My Med packages
Existing packages
4/9/2016
MyMed WPF2 - Polito
11
Polito package (WP2) Details
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
* Implementation according to viability and service needs
4/9/2016
MyMed WPF2 - Polito
12
Network Address Translation (NAT)
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
NAPT Example
Translation also the port is re-mapped (a.k.a IP
masquerading)
4/9/2016
MyMed WPF2 - Polito
13
NAT Types
NAT Type and Description
Full cone NAT
(iAddr:iPort) is mapped to an external address (eAddr:ePort), any
packets from iAddr:iPort will be sent through eAddr:ePort.
Any external host can send packets to iAddr:iPort by sending packets
to eAddr:ePort.
Restricted cone NAT
As Full cone NAT but an external host (hAddr:any) can send packets
to iAddr:iPort by sending packets to eAddr:ePort only if iAddr:iPort
had previously sent a packet to hAddr:any. "any" means the port
number doesn't matter.
Port-Restricted cone NAT
Like an Restricted cone NAT, but the restriction includes port
numbers.
An external host (hAddr:hPort) can send packets to iAddr:iPort by
sending packets to eAddr:ePort only if iAddr:iPort had previously sent a
packet to hAddr:hPort.
Symmetric NAT
Each connection from internal enpoint to an external endpoint is
mapped to a unique external source IP address and port.
Only an external host that receives a packet from an internal host can
send a packet back.
Image
4/9/2016
MyMed WPF2 - Polito
14
NAT Consideration
 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
4/9/2016
MyMed WPF2 - Polito
15
How to traverse NAT in a real scenario?
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
Typical Scenario
4/9/2016
MyMed WPF2 - Polito
16
Traversing NAT with relaying
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.
NAPT Example
4/9/2016
MyMed WPF2 - Polito
17
Connection Reversal
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
Connection Reversal scenario
4/9/2016
MyMed WPF2 - Polito
18
Traversing NAT with Hole punching UDP…
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
4/9/2016
MyMed WPF2 - Polito
19
…Traversing NAT with Hole punching UDP …
Suppose client A wants to establish a UDP session directly with client B:
1.A initially does not know how to reach B, so A asks S for help establishing a UDP session with B.
2.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.
3.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
4/9/2016
MyMed WPF2 - Polito
20
… Traversing NAT with Hole punching UDP …
Scenario 1: A and B are under the same NAT. It works in any NAT condition
4/9/2016
MyMed WPF2 - Polito
21
… Traversing NAT with Hole punching UDP …
Scenario 2: A and B are under different NAT. It works if both NAT are not symmetric
4/9/2016
MyMed WPF2 - Polito
22
… Traversing NAT with Hole punching UDP (iii)
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
4/9/2016
MyMed WPF2 - Polito
23
Traversing NAT with Hole punching TCP
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
Socket to be opened to implement hole punching
4/9/2016
MyMed WPF2 - Polito
24
How a node can discover to be behind a NAT?
3 well known server must be used:
1.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
2.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
4/9/2016
MyMed WPF2 - Polito
25
Application of NAT traversal in MyMed…
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, portrestricted)
 SP A will use a rendezvous Peer or Super Peer P/SP to perform Hole Punching.
P/SP
SP A
Cone NAT
Session A-P/SP
Session B-P/SP
Direct Session SP A – SP B
SP B
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
4/9/2016
MyMed WPF2 - Polito
26
… Application of NAT traversal in MyMed
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
P/SP
SP A
Session A-P/SP
Session B-P/SP
Cone NAT*
SP B
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)
4/9/2016
MyMed WPF2 - Polito
27
… Application of NAT traversal in MyMed
Assumptions:
 Same as before
Scenario 3:
 After authentication, the login server L communicates to the Client C the entry point to MyMed
Services (Peer /SuperPeer P/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
L
C
Session C-L
Session L-S/SP
P/SP
Direct Session C – P/SP
Cone NAT
Cone NAT
4/9/2016
MyMed WPF2 - Polito
What the others do? A look into Skype
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
28
4/9/2016
MyMed WPF2 - Polito
29
Solution FIXED vs NOT FIXED
FIXED
NOT FIXED
Specific
General
(PROPOSED)
•
•
•
•
•
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++)
• Approach for NAT Traversal
• Hole punching
• Relaying
• Mobile OS to consider for specific client
development
• Android, Symbian
•
•
•
•
•
•
•
DHT type and P2P architecture
Virtualization role
Security requirements
User Flows (login, operations)
Other packages services
Start-up services
GNU license type
• Full NAT traversal procedure
• Infrastructure less operation
o Dissemination*
o Caching*
• Italian BB nodes location
• Interfaces with other packages
* Depending on services specifications
4/9/2016
MyMed WPF2 - Polito
30
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
Opportunities
Threats
• Build a rock solid transport overlay
protocol
• Exploit users as rendezvous server
• Measure and gather real stats about
today’s NAT
•
•
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
4/9/2016
MyMed WPF2 - Polito
Free slot for open discussion
Integration of the different node profile in the P2P
system (login servers, Super Peers, Peers, Clients)
2. Storage system within the DHT
3. Security
1.
 Login c credentials
 Cryptography of communications
4. Virtualization
 Could this deal with load balancing of login servers and access
points for Clients?
31
4/9/2016
MyMed WPF2 - Polito
32
Bibliography
[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/.