overview after meeting @inria (29-30/06/2010) proposed architecture proposed technical solutions ...

Overview after meeting @INRIA (29-Overview after meeting @INRIA (29-30/06/2010)30/06/2010)• Proposed Architecture• PROPOSED Technical Solutions

Polito Package (WPF2) DetailsPolito Package (WPF2) Details ActivitiesActivities NAT traversal techniquesNAT traversal techniques

Solution Fixed vs not FixedSolution Fixed vs not Fixed SWOT analysisSWOT analysis Slot for Open discussionSlot for Open discussion

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

04/21/23 2MyMed WPF2 - Polito

MyMedServices(some examples)

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)

MyMenu

MyTranslator

MyAngel MyJam

…

…

MyLocalProducer

…

MyJob

MyCarShare


MyMed Proposed Architecture 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

BB Node located in

France

BB Node located in Italy

Desktop User

Notebook User

SmartPhone User

3G

* Users interaction with the DHT not fully defined yet

FRANCE ITALY

Super Peers

Clients or Peers

Internet


Hot points

Selection algorithm should balance among node reliability, node capacity and user reputation

Login servers must track selected nodes

Phases

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.

Login server and entry point selection algorithm have to guarantee load balancing

Step 1

Step 2

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

• 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

Proposed Solutions

Selected nodes (Peers) joins the DHT and can:

• Become entry point for “external nodes”

• Bear selected content

• Offer a specific service


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

“On exploiting User Nodes”

Leading Point

Facts

Results


Node Profile view by StepsSTEP 1

Load balancingAuthentication

Redirection to a SPContent storage

Rendezvous server Direct DHT AccessServers of ClientsContent storage

Rendezvous server Direct DHT Access

Redundancy storage

STEP 2

Access through SP

Main Functions

- - - Every profile can access MyMed and uses services - - -


Forecast 2012Forecast 2012Results 2010 Q1Results 2010 Q1

SmartPhone Market Share

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 = BlackBerrySource Gartner


MyMed proposed clients architecture

MyMedPeer

BrowserHTML --

AJAX --JSCRIPT --

Local host:80

-- Lite Web Server-- Virtualization

Client-- P2P Client-- Transport-- Reputation Client-- Security

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

MyMedP2P

Notebook

Desktop

BB Node

Internet

MyMedSuperPe

er

-- Web Server-- Virtualization-- P2P BB-- Transport-- Reputation-- Security

SmartPhone

OtherOS

MyMedP2P

Browser

Android I-Phone

Simple Web Client Server

Implementation with SDK

UI

- - Package

s- -

- - Packages - -

MyMedMobile

-- P2P Client-- Transport-- Reputation

Cl.-- Security

Implementation C++/JAVA


My Med draft layered view

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,…)

User Interface

Virtualization

P2P Overlay

Transport Overlay

Transport {TCP, UDP}

IP

MAC {802.3, 802.11, UMTS} My Med

packagesExisting

packages

Security

Reputation


Polito package (WP2) DetailsPolito 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


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

Translation also the port is re-mapped (a.k.a IP

masquerading)

NAPT Example


NAT TypesNAT Type and Description Image

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 NATAs 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 NATLike 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 NATEach 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.


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


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


Traversing NAT with relaying

Relaying consist in exploiting a public server S and use it to relay all the traffic between the peersRelaying Key Idea:Achieve communication through a public server S to which both Clients (Peers) can connect toAdvantages:Works for any NAT implementation given that both client can connect to the serverDrawbacks:Load on server S due to relayed trafficLatency of communication increasesSingle point of failureThe protocol TURN RFC 5766 implements relaying in a secure fashion.

NAPT Example


Connection ReversalConnection 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 forwardThe connection from B to A is achieved by asking A to do a reverse connection to B through S

Connection Reversal Key IdeaUse a well-known rendezvous server S to deliver the Connection request

AdvantagesWorks with any type of NAT

DrawbacksRequires one node to be not NATed

Connection Reversal scenario


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 IdeasUse a well-known rendezvous server S to let the peers know about the other end internal and external endpointOnce 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

AdvantagesWork with both nodes behind a NATDoes not require the rendezvous server S to relay traffic

DrawbacksRequires not symmetric NAT


…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


… Traversing NAT with Hole punching UDP …Scenario 1: A and B are under the same NAT. It works in any NAT condition


… Traversing NAT with Hole punching UDP …Scenario 2: A and B are under different NAT. It works if both NAT are not symmetric


… 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


Traversing NAT with Hole punching TCPSame 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


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


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, port-restricted)

SP A will use a rendezvous Peer or Super Peer P/SP to perform Hole Punching.

Cone NAT

SP ASP A SP BSP B

P/SP P/SP

Session A-P/SP

Session B-P/SP

Direct Session SP A – Direct Session SP A – SP BSP B

Remarks: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

Cone NAT


… Application of NAT traversal in MyMedAssumptions: 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

Symmetric NAT

SP ASP A SP SP BB

P/P/SSPP

Session A-P/SP

Session B-P/SP

Remarks: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

Cone NAT*


* Hole punching could work with a Full Cone Nat and with Address independent filtering (very rare)

… Application of NAT traversal in MyMedAssumptions: 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

CC P/SPP/SP

L L

Session C-L

Session L-S/SP

Direct Session C – Direct Session C – P/SPP/SPCone

NAT Cone

NAT


What the others do? A look into SkypeMAIN 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 nodeUser can become super nodesSkype 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


Solution FIXED vs NOT FIXED

NOT FIXEDNOT FIXEDFIXEDFIXED(PROPOSED)(PROPOSED)

Gen

eral

Spe

cific

* Depending on services specifications

• 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

•Full NAT traversal procedure•Infrastructure less operation

oDissemination*oCaching*

•Italian BB nodes location•Interfaces with other packages

•DHT type and P2P architecture•Virtualization role•Security requirements•User Flows (login, operations)•Other packages services•Start-up services•GNU license type


• 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

• Build a rock solid transport overlay protocol

• Exploit users as rendezvous server

• Measure and gather real stats about today’s NAT

• 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

• Well known and semi-standardized NAT traversal techniques available• STUN• TURN• ICE• …

SWOT Analysis of Polito Package

Opportunities

Strength Weakness

Threats


Free slot for open discussion

1. Integration of the different node profile in the P2P system (login servers, Super Peers, Peers, Clients)

2. Storage system within the DHT3. Security

Login c credentialsCryptography of communications

4. VirtualizationCould this deal with load balancing of login servers and

access points for Clients?


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


overview after meeting @inria (29-30/06/2010) proposed architecture proposed technical solutions ...

Documents

dht algorithm

users interaction

dht type

bb nodes super peers

node reliability

user nodes

set of services

entrythe point of entry