A Peer-to-Peer Architecture for Social Networking Applications

MISSING IMAGE

Material Information

Title:
A Peer-to-Peer Architecture for Social Networking Applications
Physical Description:
1 online resource (143 p.)
Language:
english
Creator:
St Juste, Pierre Tony
Publisher:
University of Florida
Place of Publication:
Gainesville, Fla.
Publication Date:

Thesis/Dissertation Information

Degree:
Doctorate ( Ph.D.)
Degree Grantor:
University of Florida
Degree Disciplines:
Electrical and Computer Engineering
Committee Chair:
FIGUEIREDO,RENATO JANSEN
Committee Co-Chair:
FORTES,JOSE A
Committee Members:
LI,XIAOLIN
CHEN,SHIGANG
POE,JAMES MICHAEL,II

Subjects

Subjects / Keywords:
cybersecurity -- peer-to-peer -- social-networking -- socialvpn -- virtual-private-networking -- vpn
Electrical and Computer Engineering -- Dissertations, Academic -- UF
Genre:
Electrical and Computer Engineering thesis, Ph.D.
bibliography   ( marcgt )
theses   ( marcgt )
government publication (state, provincial, terriorial, dependent)   ( marcgt )
born-digital   ( sobekcm )
Electronic Thesis or Dissertation

Notes

Abstract:
The immense popularity of social networking services such as Facebook, Twitter, and Google Plus has increased the demand for social networking applications. Currently, the majority of social networking applications uses the common client-server model due to its design simplicity and controllability. However, centralized social networking applications need a substantial amount of costly infrastructure in order to service a large number of users. The centralized approach also suffers two other well-known shortcomings: lack of privacy and single point of failure. This dissertation develops a peer-to-peer architecture which provides a trusted social messaging layer that developers can utilize to design and deploy their social networking applications. In this environment, social peers are able to share content directly with each other rather than through a centralized backend. The goal is to create an architecture that simplifies the development of social networking applications while leveraging the benefits of peer-to-peer networking. This approach provides users with self-sustaining social networking services that can run entirely on their own personal devices. This dissertation makes several contributions in the area of virtual private networking. It is the first to integrate social networking (e.g. Facebook, GoogleHangouts) with virtual networking to enable seamless establishment of encrypted end-to-end virtual IP links. This approach, dubbed SocialVPN, reuses XMPP overlays to bootstrap trusted connections using both structured and unstructured P2P libraries. By exposing the Berkeley sockets API as the basis for communication, my research enables design simplicity for social application development that is unavailable in traditional P2P frameworks. Beyond IP connectivity, this work also demonstrates the design of a decentralized domain naming system called SocialDNS. This naming service is designed specifically for P2PVPNs, such as SocialVPN. SocialDNS allows nodes to set their own domain names, perform lookups on each other's DNS caches, and resolves domain name conflicts using a social ranking heuristic. Finally, there is Litter, a P2P microblogging system implemented to show the applicability of leveraging SocialVPN for the deployment of P2P social networking applications.
General Note:
In the series University of Florida Digital Collections.
General Note:
Includes vita.
Bibliography:
Includes bibliographical references.
Source of Description:
Description based on online resource; title from PDF title page.
Source of Description:
This bibliographic record is available under the Creative Commons CC0 public domain dedication. The University of Florida Libraries, as creator of this bibliographic record, has waived all rights to it worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law.
Statement of Responsibility:
by Pierre Tony St Juste.
Thesis:
Thesis (Ph.D.)--University of Florida, 2014.
Local:
Adviser: FIGUEIREDO,RENATO JANSEN.
Local:
Co-adviser: FORTES,JOSE A.

Record Information

Source Institution:
UFRGP
Rights Management:
Applicable rights reserved.
Classification:
lcc - LD1780 2014
System ID:
UFE0046637:00001


This item is only available as the following downloads:


Full Text

PAGE 1

APEER-TO-PEERARCHITECTUREFORSOCIALNETWORKINGAPPLICATIONS By PIERREST.JUSTE ADISSERTATIONPRESENTEDTOTHEGRADUATESCHOOL OFTHEUNIVERSITYOFFLORIDAINPARTIALFULFILLMENT OFTHEREQUIREMENTSFORTHEDEGREEOF DOCTOROFPHILOSOPHY UNIVERSITYOFFLORIDA 2014

PAGE 2

c r 2014PierreSt.Juste 2

PAGE 3

Idedicatethistomymother,AlicitaAtus,forsacricingsomu chformyeducation. 3

PAGE 4

ACKNOWLEDGMENTS ItisclearthatIwouldnothaveattainedaPhDwithoutmyadvis orDr.RenatoJ. Figueiredo.Hedecidedtotakeachanceonmedespitemyownla ckofself-condence inmytechnicalabilities.Underhistutelage,Ihavelearne dthevalueofcollaboration andtheimportanceofmeetingtheneedsoftheresearchcommu nity.Hispatienceand steadyguidanceservedasafundamentalpillarofmyworkall owingmethefreedomto explorevariousavenues.Hisencouragementandpositiveou tlookalwayskeptmein goodcheerthroughoutmyPhDtenure.Iwillforeverbeinhisgr atitudeandfeelagreat senseofprideandhonorforservingashisstudent. IamalsoextremelythankfulforDr.JoseFortes'involvemen tinmydegree.He hasalwaysbeenreadytoprovidemuchneededadviceformywor kandhassteered metowardsthepathofclarity.Heisalwaysreadytolightent hemoodwithhumorand madetheACISlabanextremelywelcomingenvironment.Iamal sothankfulforDr.P. OscarBoykin'sinuenceonmyPhDwork.Hewasalwaysavailable andreadytoexplain complexconceptsandpushedmetotackletechnicallychalle ngingproblems.Iwas continuallyinspiredbyhisdeeptheoriticalandpractical knowledgeofcomputingandthe fundamentallawsthatgoverntheeld.Ihavebenetedtreme ndouslyfromhiscandid natureandinclusiveattitude.Moreover,Iamalsoverygrat efultohaveDr.Xiaolin Li,Dr.ShigangChen,andDr.JamesPoeserveonmyPhDcommittee .Theircritical feedbackhasallowedmetonetunemydissertationandmeett hehighestexpectations ofscholarlyresearch.IwouldalsoliketothankallofmyACI Scolleaguesforbeingsuch greatfriendsandcollaborators. Iwouldalsoliketoacknowledgethemanyfundingagenciesan dorganizations thathavepromotedandfundedmyPhDcareer.First,Iwouldlik etothanktheMcNair ScholarsProgramforintroducingmetoundergraduateresearc handforplanting theseedofadoctoratedegreeinmymind.Iwouldthenliketot hanktheMcKnight Fellowshipfoundationforfunding5yearsofmyPhD,Itrulydo notthinkIwouldhave 4

PAGE 5

obtainedthisdegreewithouttheirnancialsupport.Moreo ver,Iwouldliketothankthe SouthEastAllianceforGraduateEducationandtheProfessoriate forsupplementing myfundingformultipleyearsduringmyPhD.Myworkhasalsobe enfundedbyvarious grantsfromtheNationalScienceFoundationthroughvarious awardsIIP-0758596, CCF-0622106,0910812,0855031,and1127965. Finally,Iwouldliketomakeaspecialacknowledgementtomy family,specically mymotherAlicitaAtus,mybrothers,RobertSt.JusteandEricarl Rincher,andmy step-father,ErickRincher.Theyhavealwaysbeensupportiv eofmyeducational aspirationsandhavebeenmymostardentcheerleadersthrou ghthisprocess.This doctoratedegreewouldnotmeananythingwithoutthemandit alsobelongstothemas well.ThankyouallandIameternallygrateful. 5

PAGE 6

TABLEOFCONTENTS page ACKNOWLEDGMENTS .................................. 4 LISTOFTABLES ...................................... 9 LISTOFFIGURES ..................................... 10 ABSTRACT ......................................... 12 CHAPTER 1INTRODUCTION ................................... 14 1.1BackgroundandRelatedWorks ....................... 16 1.2DesignModels ................................. 18 1.2.1IntegratedClient-ServerModel .................... 19 1.2.2DecoupledClient-Servermodel .................... 20 1.2.3DecentralizedFederatedModel .................... 22 1.2.4TraditionalPeer-to-PeerModel .................... 24 1.3TheProposedPeer-to-PeerVPNAlternative ................ 26 1.3.1CryptographicKeyExchanges ..................... 28 1.3.2PrivateIPNetworking ......................... 29 1.3.3UserDenedNaming ......................... 30 1.4CaseStudy:DesigningaPeer-to-PeerMicrobloggingServi ce ....... 31 1.5Contributions .................................. 32 1.6Outline ...................................... 32 2SECURINGIPCONNECTIONSTHROUGHSTRUCTUREDOVERLAYS ... 34 2.1BackgroundandRelatedWorks ....................... 36 2.1.1KeyManagement ............................ 37 2.1.2SupportforLegacyApplications .................... 38 2.1.3IPv4ConnectivityandAddressLimitations .............. 38 2.1.4ExistingVirtualPrivateNetworks ................... 39 2.2Design ...................................... 40 2.2.1StructuredOverlayRouting ...................... 41 2.2.2PeerDiscoveryandCerticateExchange .............. 41 2.2.3EstablishingPrivateConnections ................... 45 2.2.4IPConnectivitythroughaStructuredOverlay ............ 46 2.2.5DynamicIPAllocationandTranslation ................ 48 2.2.6TheP2PVPNSocialGraph ...................... 51 2.3Experiments .................................. 51 2.3.1LinkCreationTime ........................... 52 2.3.2BandwidthCost ............................. 56 2.3.3ServerLoadonBackend ........................ 57 6

PAGE 7

2.3.4PrototypePerformance ......................... 57 2.4Summary .................................... 59 3BOOTSTRAPPINGCONNECTIONSWITHUNSTRUCTUREDOVERLAYS .. 61 3.1BackgroundandRelatedWorks ....................... 64 3.2Design ...................................... 66 3.2.1Endpoint-HostedComponents ..................... 67 3.2.2Internet-HostedComponents ..................... 69 3.2.3ControllerPolicies ........................... 70 3.3Implementation ................................. 74 3.3.1Endpoint-HostedComponents ..................... 74 3.3.2Internet-HostedComponents ..................... 75 3.3.3BootstrappingPrivateTinCanLinks .................. 76 3.3.4Multi-hopRouting ............................ 78 3.4Analysis ..................................... 79 3.4.1BandwidthCosts ............................ 81 3.4.2NetworkPerformance ......................... 82 3.4.3EncapsulationOverhead ........................ 83 3.4.4MobilePowerConsumption ...................... 84 3.4.5ZeroInfrastructureExperiments .................... 87 3.5Summary .................................... 87 4ENABLINGUSER-DEFINEDDOMAINNAMES .................. 89 4.1BackgroundandRelatedWorks ....................... 90 4.2Design ...................................... 93 4.2.1EnablingShortDomainNames .................... 93 4.2.2DecentralizationandBroadcasting .................. 94 4.2.3SimpleUserInterfaceandManagement ............... 94 4.2.4NameResolution ............................ 97 4.2.5ProtectionagainstDNSattacks .................... 99 4.3Analysis ..................................... 99 4.3.1ReducedConictsintheSocialScope ................ 100 4.3.2ExpectedBandwidthCost ....................... 101 4.3.3AnticipatedLatency ........................... 102 4.3.4ExperimentalLatency ......................... 103 4.4Summary .................................... 106 5CASESTUDY:DESIGNINGADISTRIBUTEDMICROBLOGGINGSERVICE 107 5.1Motivation .................................... 109 5.2RelatedWorks ................................. 110 5.2.1DecentralizedMicroblogging ...................... 110 5.2.2DecentralizedOSNs .......................... 111 5.2.3Publish-subscribeSystems ...................... 112 5.3Background ................................... 113 7

PAGE 8

5.3.1P2PVPNsandIPMulticasting ..................... 113 5.3.2TheP2PVPNSocialOverlay ..................... 114 5.3.3MicrobloggingPrivacybyDefaultinP2PVPNs ............ 115 5.4Design ...................................... 115 5.4.1MulticastPushtoFollowers ...................... 116 5.4.2MulticastPullbyFollowers ....................... 119 5.4.3Random-walkPushtoDistantFollowers ............... 120 5.4.4Random-walkPullbyFollowers .................... 121 5.4.5MessagePrivacyandVerication ................... 122 5.5Implementation ................................. 122 5.6Analysis ..................................... 124 5.6.1GraphCharacteristics ......................... 124 5.6.2BandwidthCostsofTwo-hopPush/PullPublishing ......... 125 5.6.3MessageReplicationTowardsHighDegreeNodes ......... 127 5.7Summary .................................... 129 6CONCLUSIONANDFUTUREWORK ....................... 130 REFERENCES ....................................... 135 BIOGRAPHICALSKETCH ................................ 143 8

PAGE 9

LISTOFTABLES Table page 3-1ExperimentalSetupSummary ........................... 81 3-2VPNNetworkPerformance ............................. 82 5-1Thefourtypesofmessagesinthesystem ..................... 116 9

PAGE 10

LISTOFFIGURES Figure page 1-1SummaryofP2PVPNAlternative ......................... 26 2-1CerticateExchangeModels ............................ 42 2-2SocialVPNArchitecture ............................... 47 2-390thPercentileTimefordeployments ....................... 53 2-4DHTRetrievalTimesfordeployments ....................... 54 2-5ConnectTimefordeployments ........................... 55 2-6Bandwidthcostassocialnetworksizeincreases ................. 56 2-7SocialVPNUserInterface .............................. 58 3-1TinCanComponentsandOverview ......................... 67 3-2InteractionbetweenTinCanModules ........................ 70 3-3VPNTopologies ................................... 73 3-4BootstrappingConnectionsthroughXMPP .................... 77 3-5BootstrappingConnectionsthroughSocialGraph ................. 78 3-6EnablingMulti-hopSocialRouting ......................... 79 3-7CDFof1450ConnectionTimes ........................... 84 3-8FileTransferPercentageOverhead ......................... 85 3-9CPUEngergyConsumptiononMobile ....................... 86 3-10WiFiEnergyConsumptiononMobile ........................ 86 4-1MulticastDNSinLANandP2PVPNenvironments ................. 91 4-2SocialDNSAJAXWebInterface ........................... 95 4-3DistributionofNumberofFriendsin2-hopRadius ................ 100 4-4CDFofOne,Two,andThreehopeQueries .................... 101 4-5ImpactofQueryTimeouts .............................. 103 4-6CDFofUserRequestTimes ............................ 104 4-7TimeTakentoBroadcasttoVariousSizeNetworks ................ 105 10

PAGE 11

5-1Multicastpushpullmechanism ........................... 118 5-2Randompushandpullmechanism ......................... 118 5-3Screenshotofthemicrobloggingservice ..................... 123 5-4Bandwidthcostoftwo-hopbroadcasts ....................... 125 5-5Probabilitydistributionofwalks ........................... 128 11

PAGE 12

AbstractofDissertationPresentedtotheGraduateSchool oftheUniversityofFloridainPartialFulllmentofthe RequirementsfortheDegreeofDoctorofPhilosophy APEER-TO-PEERARCHITECTUREFORSOCIALNETWORKINGAPPLICATIONS By PierreSt.Juste May2014 Chair:RenatoJ.FigueiredoMajor:ElectricalandComputerEngineering Theimmensepopularityofsocialnetworkingservicessucha sFacebook,Twitter, andGooglePlushasincreasedthedemandforsocialnetworkin gapplications. Currently,themajorityofsocialnetworkingapplications usesthecommonclient-server modelduetoitsdesignsimplicityandcontrollability.How ever,centralizedsocial networkingapplicationsneedasubstantialamountofcostl yinfrastructureinorder toservicealargenumberofusers.Thecentralizedapproach alsosufferstwoother well-knownshortcomings:lackofprivacyandsinglepointo ffailure. Thisdissertationdevelopsapeer-to-peerarchitecturewh ichprovidesatrusted socialmessaginglayerthatdeveloperscanutilizetodesig nanddeploytheirsocial networkingapplications.Inthisenvironment,socialpeer sareabletosharecontent directlywitheachotherratherthanthroughacentralizedb ackend.Thegoalistocreate anarchitecturethatsimpliesthedevelopmentofsocialne tworkingapplicationswhile leveragingthebenetsofpeer-to-peernetworking.Thisap proachprovidesuserswith self-sustainingsocialnetworkingservicesthatcanrunen tirelyontheirownpersonal devices. Thisdissertationmakesseveralcontributionsintheareao fvirtualprivate networking.Itisthersttointegratesocialnetworking(e .g.Facebook,Google Hangouts)withvirtualnetworkingtoenableseamlessestab lishmentofencrypted end-to-endvirtualIPlinks.Thisapproach,dubbedSocialVPN, reusesXMPPoverlaysto 12

PAGE 13

bootstraptrustedconnectionsusingbothstructuredandun structuredP2Plibraries.By exposingtheBerkeleysocketsAPIasthebasisforcommunicatio n,myresearchenables designsimplicityforsocialapplicationdevelopmentthat isunavailableintraditional P2Pframeworks.BeyondIPconnectivity,thisworkalsodemons tratesthedesignof adecentralizeddomainnamingsystemcalledSocialDNS.This namingserviceis designedspecicallyforP2PVPNs,suchasSocialVPN.SocialDNSallo wsnodestoset theirowndomainnames,performlookupsoneachother'sDNSc aches,andresolves domainnameconictsusingasocialrankingheuristic.Fina lly,thereisLitter,aP2P microbloggingsystemimplementedtoshowtheapplicabilit yofleveragingSocialVPNfor thedeploymentofP2Psocialnetworkingapplications. 13

PAGE 14

CHAPTER1 INTRODUCTION Theimmensepopularityofsocialnetworkingservicessucha sFacebook,Twitter, andGooglePlushasincreasedthedemandforsocialnetworkin gapplications. Hence,thereisatremendousamountofinnovationaimedatin corporatingsocial featuresinmanyapplicationssuchasphoto-sharing,locat ion-basedservicesand search/recommendationsystems[ 1 ].Moreover,thewidespreaduseofInternet-ready mobiledeviceshasalsoincreasedthedemandforsocialnetw orkingapplicationssince theyprovideanarrayofsensorswhichenhanceusers`social experiences(e.g.GPS, camera).Asaresult,overthepastfewyears,theInternethas transformedfroma systemforaccessinginformationandservicestoamediumwh ereusersareconstantly connectedandinstantaneouslysharetheirexperienceswit hfriends. Currently,themajorityofsocialnetworkingapplications usesthetraditional client-servermodelduetoitsdesignsimplicityandcontro llability.Inthisapproach, socialuserscommunicatethroughacentralentitywhichpro videsmostofthenecessary resourcesforprocessing,storage,andcommunication.How ever,centralizedsocial networkingapplicationsneedasubstantialamountofcostl yinfrastructureinorderto servicemillionsofusers.Somemayarguethatcloudcomputin ghasminimizedthe infrastructurecostsbygivingdeveloperstheoptionofsta rtingsmallandscalingupon demandforthenecessaryresources.However,eventhoughcl oudcomputingtakes awaytherequirementofmajorinitialinvestmentsininfras tructure,itstillincurshigh coststosupportmillionsofusersinacentralizedfashion. Thecentralizedapproachalsosufferstwowell-knownshort comingsbesides infrastructurecosts:lackofprivacyandsinglepointoffa ilure.Centralizedsocial networkingservicesfacilitatethesharingofcontentwith friendsandfamilythrough theuseofmassivedatastoresunderthecontrolofprivateen tities.Asaconditionof usingthesesocialservices,mostusershavetorelinquisho wnershipoftheircontentto 14

PAGE 15

thesethird-partyentities[ 2 ].Tooffsetinfrastructurecosts,socialnetworkingservi ces (SNS)providersutilizeuserdataattheirowndiscretiontoge neraterevenuethrough dataminingandtargetedadvertisements.Suchunspeciedus eofprivateuserdata mayviolatetheimpliedtrustthatusersattributetotheses ocialnetworkingservices. Therehasbeengrowingunrest,withsomeofthemostpopularSN Sproviders,on theissueofuserprivacyanddatasharingpracticeswithunk nownthirdpartieswithout userconsent.ThispresentsadilemmaforbothusersandSNSpr ovidersbecauseusers desireacertainqualityofservicethroughthesesocialnet workingserviceswhichisonly possibleiftheprovidersareabletogenerateenoughrevenu etomaintainthenecessary infrastructuretosatisfyuserexpectations.Asaresult,th ereisaconstantstruggle betweenprivacyadvocatesandSNSprovidersinanattempttos triketheproper balanceontheusageofprivateuserinformation.Therearea lsoprivacyconcernsover permanentstorageofuserdata.Varioussources[ 3 ]havereportedthatSNSproviders donotdeleteuserinformationwhenexpected(e.g.deleting aphotooraccount)fora signicantamountoftime.Forsomeusers,thethoughtofhav ingalloftheirinteractions permanentlystoredinacorporatedatabasemayhinderorlim ittheirusageofthese socialnetworkingservices. Finally,thesinglepointoffailurevulnerabilityisthemo stprominentdisadvantages oftheclient-servermodel,thuscentralizedsocialnetwor kingservicesautomatically inheritthisproblem.Duetotheircentralizednature,bloc kingtheseonlinesocial networkingservicesiscommonandthereareamultitudeofwe ll-knowntypesof denialofservice(DoS)attackstoachievethis[ 4 ].Anexampleofthisweaknessis whengovernmentsinpartsoftheworlddenyusersaccesstoce rtainsocialnetworking servicesthroughDNSlteringandIPblacklisting[ 5 ].Therehavealsobeeninstances whereroguehackershavetargetedcentralizedsocialnetwo rkingserviceswith distributeddenialofserviceattacks(DDoS)[ 6 ].Additionally,highproleuseraccounts 15

PAGE 16

oncentralizedsocialnetworkingserviceshavebeenhacked throughman-in-the-middle attacks[ 7 ]. AstheamountofprivateuserinformationaccumulatedbySNSpr ovidersincreases, theirinfrastructuresbecomemoreappealingtargetstomal iciousactorswhoare constantlyattemptingtobreachthesesystemsandstealpri vateuserdata.Asdata miningtechniquesbecomemoreadvancedandwidelyused,use rdataisbecoming agoldmineandservesacrucialroleaspartofacompany'sass ets.Therefore, ensuringtrusteddataaccessandprivacyaretoppriorities andbecomemajortechnical challenges.Consequently,adoptingthetypicalclient-se rvermodelfordeployingsocial networkingapplicationsmaynotonlybecostly,butitrequi resextremecaretoensure dataprivacywhilemaintainingtheabilitytogeneratereve nue.Italsonecessitatesthe foresighttoanticipatetheshortcomingsofthesinglepoin toffailureproblem,aswell astheexpertisetosecuretheinfrastructuretoavoiddatab reachesofvaluableprivate userinformation.Thisdissertationpromotesanalternati vepeer-to-peerparadigmfor designingsocialnetworkingapplicationswhichdealswith theissueofasinglepointof failurewhileprovidingmoreexibilityindealingwithpri vacyconcerns. 1.1BackgroundandRelatedWorks Peer-to-peer(P2P)systemsareknownfortheirindependencef romcentralized backends.File-sharingP2PsystemssuchasGnutella,eMule, FreeNet,andBittorent havebeenaroundforaboutadecadeandexistcompletelyonen d-userresources[ 8 ]. Whenappliedtosocialnetworkingservices,thetwomostcomm onP2Prelated modelsareDHT-basedandDarknet-baseddesigns.Therstty peisthestructured distributedhashtable(DHT)method.AstructuredDHTisawe ll-researcheddistributed storagesystemwhichprovidessimpleput/getprimitives.T heresourcesusedinthis distributedstorageareusuallymadeupofhundredstomilli onsofgeographically dispersedmachinesbelongingtotheusersofthesystem.Thi sapproachscaleswell becauseeachusercontributesresourcestotheoverallinfr astructure.Byreplacingthe 16

PAGE 17

centralizeddatastorewithadistributedalternative,dev eloperscandesignfunctionally equivalentsocialnetworkingserviceswhichsidestepboth thecostofmaintainingan infrastructureaswellasthesinglepointoffailure. However,thedeploymentofafull-edgedsocialnetworking servicesuchas FacebookonaDHTintroducesahostofissueswhicharenonexi stentinthecentralized version.Securityisbyfarthemostcomplexandhardesttohan dle.Sincedevelopers relyonuntrustworthymachinesconnectedtotheInternet,i notherwords,completely outoftheircontrol,itmakesitverydifculttotrustthese end-usernodes.Thishas beenaddressedbyseveralworks[ 9 ]buttheirmaindrawbackistheneedtomanage cryptographickeys. Thereisalsotheissueofheterogeneity.Developerscanexp ectacertainguarantee ontheperformanceofnodeshousedinadatacenter,butsuche xpectationsare unrealisticforend-usermachines.Therefore,thenodesth atmakeuptheinfrastructure foraDHTrangefrompowerfulmulticoreworkstationswithst ablehighbandwidth connectionstolow-powersingle-corethinclientswithint ermittentInternetconnections. Adaptingthesystemtosuchvariabilitywhilemaintainingan acceptablelevelofquality ofservice(QoS)foranonlinesocialnetworkcanbetremendou slychallenging.Afew projectsattemptthismodel[ 10 11 ];however,theysufferfromthebootstrapproblem becausetheyfailtoattractenoughuserstoaccumulatethen ecessaryresourcesto sustaintheservice. Thesecondpeer-to-peerdesignforasocialnetworkingappl icationisthedarknet model.Inthismodel,peersonlyconnecttotrustedfriendst hroughencryptedconnections. Insteadofsharingcontentthroughacentralizedordistrib uteddatastore,theycontact eachotherdirectlyandsynchronizeupdatesthroughgossip /epidemicalgorithms[ 12 ]. Bylimitingcontentdisseminationonlytotrustedpeers,the privacyissuesaremuch simplertohandlebecauseusershavefullaccesscontrolove rtheirdata. 17

PAGE 18

Assumingthatthecryptographickeymanagementproblemisha ndled,the othermajorhurdleforthisapproachisensuringhighdataav ailability,inotherwords, minimizingpropagationlatency.Hereisanexampleofthepr oblem:Alicewantstoshare aphotoofhernewcarwithhertenfriends,butonlyveofthem areonlinewhenshe sharesthephotothroughthepeer-to-peersocialnetworkin gapplication.Bythetimeher remainingvefriendscomeonline,Aliceisofine.Eventuall y,theyallgettheupdate fromAliceonlywhenheronlinetimeoverlapswitheachofherf riends'onlinetime.Asa result,someofAlice'sfriendsmayhavetowaitdaysbeforeth eynoticeAlice'snewcar. SuchadelayhinderstheusageofthistypeofP2Psocialnetwork ingapplication.There arecurrentlyexistingeffortstodevelopsocialnetworkin gservicesusingthismodel[ 13 ], buttheyhavenotbeensuccessfullydeployed. Thechallengesofbuildingpeer-to-peersocialnetworking serviceshavecreatedthe impetusforthisdissertation.Thegoalistoidentitytheco mmonhurdlesthatpreclude thedevelopmentandsuccessfuldeploymentofsocialnetwor kingapplicationsand provideanarchitecturewhichmitigatesthesepitfalls.Bya ddressingissuessuch astrustedconnectivityamongpeers,automaticcryptograp hickeymanagement,a well-knownapplicationprogramminginterface(API),andmul ti-hopsocialroutingthis workaimsatcreatingastrongfoundationthatwilldrastica llylowerthebarriersof designingdistributedsocialnetworkingapplications. 1.2DesignModels Severalprogrammingparadigmsexistforbuildingsocialnet workingapplications. Thischaptercoverssomeofthemorecommonapproachesbysum marizingtheir generalconceptsalongwiththeirmostsalientbenetsands hortcomings.Thegoalis toprovidebriefcontextandbasisforcomparisontotheprop osedP2Papproach.This willallowfordeeperunderstandingofthedirectionofthis dissertation.Thissection describesfourwell-knowntechniquesfordesigningsocial networkingapplications:the 18

PAGE 19

integratedclient-servermodel,thedecoupledclient-ser vermodel,thedecentralized federatedmodel,andthepeer-to-peermodel.1.2.1IntegratedClient-ServerModel Theintegratedclient-servermodelisthemostwidelyusedm ethodforcreatinga socialnetworkingapplication(SNA).Inthismodel,SNAdevelo persrelyprimarilyon componentsundertheiradministrativecontroltoprovidet hekeyfunctionsneededby socialapplications.Therefore,SNAdevelopersusetheirow nservers—althoughthese serversmaybehostedbyathird-partycloudserviceprovide r—tomanageandstore socialrelationships,alongwithnecessaryresourcestoen ablethecontentsharingsuch asupdates,messages,photosandotherformsofmedia.Sincet heserviceistotally independent,developershavetoprovidethecapabilityfor userstondandcreatesocial connectionswithinthesystem.Well-knownexamplesofthis modelareFacebookand Twitter.Forinstance,theusualrststepaftercreatingaF acebookaccountistond friendswhoalreadyhaveaccountsandsendthem friendrequests .Uponacceptance, asocialconnectioniscreatedonthesystemwhichisstoredi nFacebook'sdatabase. Hence,Facebookprovidesallofthenecessaryfunctionalit iestocreateandmanage thesesocialconnections. Themainadvantageofthisapproachistotalautonomyoverth edesignofthesocial networkingservice.Developersarefreetoenableordisabl eanyfeatureattheirown discretion.Theadditionalbenetofthisapproachistheco mpleteownershipofuser datarepresentingtheirsocialrelationships,activities ,andinteractions.Thisinformation isnotonlyaboonforsociologicalresearchbutalsofortarg etedadvertisingrmsand evengovernmentalagencies.Designsimplicityisanothera dvantageoftheintegrated client-servermodel. Therearealsodisadvantagestothisintegratedclient-ser vermodel.Therst commonproblemofanysocialnetworkingserviceistheboots trapproblem.The popularityofonlinesocialnetworkinghascreateddozenso fcompetingsocialnetworking 19

PAGE 20

services.Therefore,generatingthecriticalmassnecessa rytohaveaself-sustaining systemcanbequitechallenging.Mostusersarecomfortable withonlyusingafew popularsocialnetworkingservices(e.g.Facebook,Twitte r)andarenotcompelledto createandmanagesocialrelationshipsacrossdozensofsoc ialnetworkingservices. Thus,acommonkeyrequirementforthesuccessofasocialnet workingserviceisthe recruitmentoflargenumberofusers.Withenoughusers,thed eveloperscanattract additionalinvestmentcapital,andgeneraterevenuethrou ghadvertisements. Thesecondpitfallisthesinglepointoffailureissuewhich plaguesallclient-server-based systems.Forexample,anetworkadministratorcaneasilyde nyaccesstoacentralized socialnetworkingserviceeitherthroughDNSlteringorIP blacklisting.Moreover, sincecentralizedserviceshavewell-knownendpoints,mal iciousagentscantargetthe endpointwithDoSattacks.Theseissuesmakesecuringthece ntralizedbackboneof asocialnetworkingserviceatopprioritybecauseitserves asanattractivetargetfor attackers.1.2.2DecoupledClient-Servermodel SNAdeveloperstypicallywanttosidestepthetaskofrequiri nguserstocreate andmanagesocialconnectionsontheirownsystem.Theypref erreusingexisting relationshipsalreadyidentiedthroughanintegratedsoc ialnetworkingservicesuch asFacebook.Independentsocialnetworkingservices,desc ribedintheprevious section,typicallyexposeanapplicationprogramminginte rface(API)enablingthird-party developersaccesstotheirsocialnetworkingdatabase[ 14 ].Inthisscenario,users havetomanagesocialrelationshipsonlyontheintegrateds ocialserviceandthesocial relationshipsareautomaticallyupdatedthroughothersoc ialnetworkingapplications whicharelinkedtotheiraccounts.Forexample,Alicewantst oplay WordswithFriends anonlinecrosswordpuzzle,whichusestheFacebookAPItoiden tifyherfriendsand sendinvitestoplaythegame.AsAliceaddsorremovesfriendsf romherFacebook account, WordswithFriends automaticallyretrievestheupdatedlistoffriendsthroug h 20

PAGE 21

theFacebookAPI.Inthisdecoupledclient-servermodel,thed evelopersstillusetheir owninfrastructuretoprovidethefunctionalitiesspecic totheirapplication.Social networkingapplicationsbasedonthismodelprimarilydepe ndontheintegratedSNSfor managingfriendsandothermessagingfeatures. Utilizingthismodelbenetsbothdevelopersandusersduet oreducedsocial relationshipmanagement.Fromthedevelopers'perspectiv e,theydonothaveto dedicateextraresourcesformanagingsocialrelationship s.Moreover,theysidestepthe bootstrapproblem.Byleveragingthepopularityofexisting integratedsocialnetworking services,thedeveloperssignicantlyreducethebarriert otheadoptionoftheirsocial applications.Usersalsobenetfromamanagementstandpoi ntbecausetheyarenot requiredtocreatenewaccountsandrepeatthestepsofndin gandcreatingsociallinks oneverySNA.Usersareabletoreusetheirexistingsocialrela tionshipsseamlessly. Thedecoupledclient-serverapproachhoweversuffersfrom afewweaknesses. Thetradeofffornotmanagingsocialrelationshipsandusin ganothersystem'ssocial networkingfeaturesisultimatelytotalrelianceontheAPIan dpolicies.Therefore, changestotheAPIandpoliciescanhaveseriousdetrimentalef fectsonthesocial networkingapplications[ 15 ].Beforechoosingtodependonaparticularsocial networkingAPI,developersneedsomeassurancefromthesocia lnetworkingsystem thattheinterfaceisstableandchangeswillbeslowandincr emental.Thisdecoupled modelalsosuffersthesameweaknessesofanyclient-server modelofprivacy andsinglepointoffailure.Althoughnotallofthecomponent sresideinthesame administrativedomain,itisstillfairlysimpletoblockac cesstoadecoupledclient-server socialapplicationthroughDNSlteringandIPblacklistin g.Also,theprivacyissuemay beexacerbatedbecausetheyarenowtwoentitiesinvolvedin accessingandmanaging auser'ssocialactivitiesandinteractions.Therehasbeen ahistoryofthesetypesof third-partysocialapplicationscausingdataleaksofpriv ateuserinformation[ 16 ]. 21

PAGE 22

1.2.3DecentralizedFederatedModel Thismodelisadeparturefromthetwopreviousapproachesbe causeitdoes notrequireanycentralizedinfrastructurefromthedevelo pers.Itreusesexisting, decentralized,andfederatedmessagingsystems.Exampleso fsuchsystemsarethe ExtensibleMessagingandPresenceProtocol(XMPP),Skype,orIRC.Si nceXMPPis anopenstandardandisadoptedbymostmajormessagingsyste m,itisusedasthe primaryexample.XMPPisthemaininstantmessagingtechnolog yusedontheInternet andissupportedbyGoogle,Facebook,AOL,Windows,andSkype. Althoughitsinitial usewasprimarilyforinstantmessaging,itsextensibility hasallowedittosupportsocial networkingservices.Forexample,thereiscurrentlyanexp erimentalextensiondraftto supportamicrobloggingserviceontopoftheXMPPprotocol[ 17 ]. TheXMPPsystemworksasafederationsimilartotheemailsyste m.Usersare freetochoosetheXMPPprovideroftheirchoice—aslongasthes eprovidersare partofthesamefederationmanagedbytheXMPPfoundation—use rsareableto communicatewitheachother.TheXMPPprotocolrequirelessin frastructurethan theintegratedanddecoupledclient-serverapproaches.XMPP serversmainlyhandle thefollowingfunctions:registrationofusers,storageof buddylists,androutingof XMLmessagesfromsourcetodestination.Theserverscanalso supportadditional functionalitiesbuttheyarenotpartofthecorerequiremen ts. ByrelyingontheXMPPlayerforsocialrelationshipmanagement aswellas messagerouting,SNAdeveloperscandesignservicesthatlev eragetheXMPPlayer forpeerdiscoveryandmessagingwhileutilizingusers'res ourcestoenableadditional features.Thisisakeyadvantagefordevelopersbecausethe ycanessentiallydeploya socialnetworkingapplicationwithouthavingtoprovidece ntralizedresourcestohandle computation,storage,andcommunicationamongpeers.Also, byreusingexisting socialconnectionsavailablethroughthesefederatedsoci alservices,thisapproach minimizessocialrelationshipmanagement.Forexample,if amicrobloggingserviceis 22

PAGE 23

builtontopofXMPP,theuserwillautomaticallysendupdatest opeersinherXMPP buddylistwithouthavingtorecreateexistingsocialconne ctions.Additionally,sincethe messaginglayeriscomposedofamultitudeofXMPPserverscomm unicatingwitheach other,thesinglepointoffailureissueismitigated.Forin stance,Alice@jabberA.com, Bob@jabberB.com,andCarol@jabberC.comarefriends;ifBob' sXMPPserver jabberB.comisbroughtdownduetoafailure,Alice@jabberA.c omcanstillcommunicate withCarol@jabberC.comsinceXMPPserversjabberA.comandjab berC.comare stilloperational.Itrequiresmoreresourcestoattackall oftheXMPPproviders simultaneouslyinordertobringdowntheentiresocialappl ication. Therearealsodrawbackstothisapproachintermsofreliabi lityandqualityof servicebecauseofitsdependencyonunreliableend-userma chines.End-user computingenvironmentsarehighlyheterogeneousrangingf romlow-powersingle corethin-clients,tomulti-coreworkstationsrunningman ydifferentoperatingsystems withvaryingdegreesofbandwidth.Intheclient-servermod el,developerscontrolthe resourceswhichsupporttheessentialcomponentsofasocia lnetworkingapplication andcanthereforeallocatetheadequateamountofCPU,storag eandbandwidthforthe desiredqualityofservice.Moreover,systemadministrato rscontinuouslymonitorthese serverstoensurethattheseservicesrunwithminimumfailu re. Inthedecentralized,federatedmodel,theperformanceoft hesystemishighly dependenttothestabilityofend-userresources.Consider Aliceisusingasocial applicationwhichallowshertosharephotoswithher100fri ends.Intheclient-server model,Alicesimplyuploadsher1MBphototothecentralizedSN Susingonly1MBof heruploadbandwidth.Onceuploaded,her100friendscanvie wthephotowhichutilizes 100MBofthecentralizedsystem'sbandwidth.Thedeveloper sensurethatthereis amplebandwidthtoserveAlice's100friends. Inthefederatedmodel,theXMPPserverssimplyroutedatawith outstoringit. Consequently,Aliceisresponsibleforservingher1MBphoto toher100friendsusing 23

PAGE 24

100MBofheruploadbandwidth.WithatypicalISPconnectionwi thanaverageupload bandwidthofa1MB/secorless,ittakesatleast100secondsto sendthephototoallof Alice'sfriendsincomparisontothecentralizedapproachwh ichtypicallytakeslessthan onesecond.ThereareBittorent-likeswarm-basedtechnique sthatcanamelioratethe situation.However,theperformanceofthesocialapplicat ionbecomesmorecostlyto theclientsduetorelianceontheirrestrictedresources. Anotherissuetoovercomewiththismodeliscontentavailabi lity.Forinstance, Alicesharesthephotowhenonlyhalfofherfriendsareonline ,andbythetimethe otherhalfofherfriendscomeonline,Alicemaybeofine.Inm ostcases,ifAlice's friendsareonline,theseupdatescouldbepropagatedthrou ghfriendsorfriendsof friends.However,ifAliceisnotverypopularorsomeofherfr iendsdonotknoweach other,itmaytakealongtimebeforeallofAlice'sfriendsare abletoseehershared photos.Thesetypesofsocialnetworkingapplicationsthro ughtheXMPPprotocol arepossiblebuttheyarenotverypopularduetotheirpoorqu alityofserviceandlow contentavailability.1.2.4TraditionalPeer-to-PeerModel Finally,therearedecentralizedsocialnetworkingapplic ationsbasedonthe peer-to-peermodel.Inthismodel,theusersprovidealloft heresourcesnecessary tosupportthesocialnetworkingapplication.Unlikethepr eviousthreemodels, whichrequiresomepublicly-hostedinfrastructure,thepe er-to-peermodelhaszero infrastructurecost.Inthepeer-to-peermodel,usersdire ctlyconnectwiththeirtrusted friendstosharecontentwithoutamiddleman.Developersei therwritetheirown P2Pprotocolorbyutilizeexistingpeer-to-peertechnologi es.Oneexampleisthe FreePastrylibrarydevelopedbytheauthorsofthePastryP2P protocol[ 18 ].Thislibrary handlesmessageroutingandNATtraversalamongpeers.Bybui ldingsocialnetworking applicationsontopofthepeer-to-peerlibrary,socialnet workingdeveloperscanensure thatthesystemisself-sustainingwithouttheneedforcost lyinfrastructure. 24

PAGE 25

Inthepreviousfederatedmodel,usersarerequiredtotrust third-partyXMPP serviceproviders,andassumethattheywillnotmonitororr ecordtheirsocialinteractions. Moreover,inthepreviousmodels,censorshipispossiblesi nceagovernmentcan requestspeciccontenttobetakendown,ordemandthatXMPPse rversltercertain content.Inthepeer-to-peermodel,itishardertocensorth esystemsincesocialpeers areconnectingdirectlytoeachotherwithouttheuseofanyh ostedservices. Thepeer-to-peermodelalsohasmanychallengestoovercome .Duetoitsstrict independencefromcentralizedservices,ithastoovercome twobootstrapproblems. Therstbootstrapproblemistheonewhichisnecessaryfort hepeer-to-peersystem tobeself-sustaining.Thereneedstobeenoughbootstrapno deswhoareopenly reachablethroughpublicIPaddressesenablingothernodes behindNATsandrewalls toconnectthroughNATtraversalandrelaying.Bootstrappin gapeer-to-peersystemis notsimple;therefore,mostpeer-to-peersystemsdependon afewwell-knownsetof bootstrapnodeswhichserveacriticalroleinallowingnewn odestojointhepeer-to-peer system.Disablingthesewell-knownbootstrapnodescandis abletheP2Pnetworkand makeitimpossiblefornodestojointhenetwork. Thesecondbootstrapproblemdealswithpeerdiscoveryands ocialrelationship management.InsystemslikePastry[ 18 ]andFreeNet[ 19 ]usershavetoemaileach othercryptographicinformationtocreateencryptedend-t o-endconnections.Because thissystemisindependent,usershavetomanagetheirownso cialconnectionsthrough thepeer-to-peersocialnetworkingapplication.Suchanapp roachcanserveasamajor barriertowidespreadadoptionbecauseitrequiresmultipl estepsbeforeuserscandeem thesocialnetworkingapplicationusable. AsidefromthebootstrapproblemsinherenttoP2Psystems,thi smodelalsoinherits theshortcomingofthedecentralized,federatedmodel.Int ermsofqualityofservice,the socialnetworkingapplicationisatthemercyofend-userre sources.Ifmostusershave astable,high-speedInternetconnectionwithapowerfulmu lti-coremachinewithhigh 25

PAGE 26

Figure1-1.SummaryofP2PVPNAlternative sessiontimes,thenthequalityofservicemaybeclosetotha tofacentralizedsocial networkingapplications.However,iftheend-usernodesha veunstableconnections, thenensuringanyacceptablequalityofservicebecomesqui techallenging.Interms ofdataavailability,thesamecircumstancesofthepreviou sdecentralizedapproach stillapplieswhereusersmayhavetowaitalongtimebeforer eceivingallofthesocial updatesfromfriends.Hence,althoughitispossibletousee xistingP2Ptechnologiesto designasocialnetworkingapplication,theincreasedcomp lexityimpedesthesuccessful deploymentofsuchaservice. 1.3TheProposedPeer-to-PeerVPNAlternative Thisdissertationadvocatesadifferentwayofbuildingsoc ialnetworkingapplications throughtheuseofpeer-to-peervirtualprivatenetworks(P2 PVPN).AP2PVPNcreatesa virtualnetworkwhichtunnelsIPpacketsdirectlytopeerst hroughencryptedP2Ptunnels (seeFigure 1-1 ).TherearecurrentlyvariousP2PVPNsolutionsavailable[ 20 – 22 ]. 26

PAGE 27

HereisaquickdescriptionofhowaP2PVPNcanfacilitateinthede signofasocial networkingapplication. ThemaingoalofaP2PVPNistoprovideusersprivateIPconnectivi tytoeach other.SincemostcommonusersaccesstheInternetfrombehin dNATsandrewalls, theretypicallyisnotawell-knownIPaddressthatapplicat ionscanusetoconnectwith auser.AP2PVPNthereforemakesitpossibleforuserstocontacte achotherdirectly usingprivateIPaddresses.P2PVPNsalsodonotdependonaVPNgatew ayserverlike traditionalVPNsthusmakingitmoredifculttocarryman-inthe-middleattacks. ByleveragingtheprivateIPconnectionsthatbecomeavailab leamongusers,SNA developerscandesignservicesthatcommunicatedirectlyo verIP.Forexample,ina centralizedsocialnetworkingapplication,Alicecontacts Bobbytellingthesystemto postamessageonBob'sinbox.WiththepresenceofaP2PVPN,Aliceisa bletosend BobamessagebyusingBob'sprivatevirtualIPaddresstocreat eaTCP/IPconnection andsendthatmessagedirectlytoBob'smachine.DirectTCP/IP connectivitytousers givedevelopersmoreexibilityinthedesignoftheirsocia lnetworkingapplicationsand canoptimizetheperformanceoftheirapplications. IntheXMPPmodel,applicationscanonlycommunicatethrought heuseofXML messages.SinceXMPPonlysupportstext-basedmessaging,itis inefcienttoshare otherformsofmediasuchasphotothroughtheXMPPlayer.Devel opersarethus requiredtoconvertbinarydatatoastringrepresentation( e.g.base64encoding)before sendingitthroughtheXMPPlayer.Thisprocessincurssomeove rheadinthesocial networkingapplications.Ontheotherhand,throughaP2PVPN,de velopersgetan IPconnectionandarefreetosendrawdataandcanleverageex istingtechniquesfor optimizingmessagetransmissionoverTCP/IPconnections. Thisdissertationdevelopsapeer-to-peerframeworkwhich providesatrusted socialmessaginglayerthatdeveloperscanutilizetodesig nanddeploytheirsocial networkingapplications.Inthisenvironment,socialpeer sareabletosharecontent 27

PAGE 28

directlywitheachotherratherthanthroughacentralizedb ackend.Developerscanthus createaservicewhichhasessentiallyzeroinfrastructure cost.Thegoalistocreatean architecturethatmakesitsimplefordeveloperstocreates ocialnetworkingapplications thatcanleveragetheadvantagesofpeer-to-peernetworkin gandprovidesuserswith self-sustainingservicesthatrunentirelyontheirownres ources. Althoughthereareexistingpeer-to-peerlibrariesthatdev eloperscanintegrate intotheirsocialapplications,theytypicallyfallshorti ntermsofeaseofuse,social peerdiscovery,andcryptographickeymanagement.Themain noveltyofthisworklies inthefactthattheproposedP2Parchitecturehandlesthesec omplexissues.First, byprovidingawell-knowninterfacethroughIPvirtualizat ion,developerscanquickly utilizethisarchitecturebasedonwell-establishednetwo rkprogrammingtechniques (i.e.Berkeleysockets).Theproposedarchitecturealsolet susersimportexistingsocial relationshipsfrompopularsocialnetworkinginfrastruct uressuchasFacebookand GooglePlus.Thisfeatureiscrucialbecauseitenableszerocongurationsocialpeer discoveryandsocialconnectionmanagement.Finally,bypr ovidingsimplemechanisms forcryptographickeymanagement,userscanrestassuredth attheirsocialinteractions areprivate.Theresultisaself-conguring,low-manageme nt,andsecureplatformwhich facilitatesthedeploymentofdecentralizedsocialnetwor kingapplications. 1.3.1CryptographicKeyExchanges Ensuringprivacyisacommonhindrancetobothcentralizedan ddecentralized socialnetworkingservices.Byleveragingexistingtrusted socialnetworkinginfrastructures suchastheXMPPfederation[ 23 ],thisarchitecturemakesitpossibleforpeerstoreuse theirexistingFacebookorGooglePlusaccounts.Italsoauto maticallydiscoverstheir socialpeerswithoutrequiringuserstomanuallyrecreatet hesesocialconnections.The systemworksbyusingtheencryptedconnectiontotheXMPPserv erstoexchange self-signedX.509certicates.Theasymmetricpublickeysw ithinthecerticatesserve asthebasistobootstrapauthenticated,peer-to-peerconn ectionamongsocialpeers 28

PAGE 29

withend-to-endencryption.Thisapproachthussecurelyma kescryptographickey managementseamlesstouserswhichisaveryimportantstepi naddressingtheprivacy issue.1.3.2PrivateIPNetworking Anotherdissuadingfactorindesigningpeer-to-peersocial networkingapplications isthelearningcurveofintegratingwithrapidlychanging, custom,peer-to-peerAPIs.As peer-to-peerlibrariesattempttoprovidemorefeaturesan dserveasagenericplatform, theirAPIstendtogrowincomplexitytosupportthesenewcapab ilities.Moreover,the programmingframeworkcanalsobealimitingfactor.Forexa mple,ifalibraryiswritten inJava,developersareultimatelylockedintothatprogram minglanguagebecause creatingbindingsforanotherprogramminglanguagefurthe rcomplicatesthesituation. Myresearch,dubbedSocialVPN,usesnetworkvirtualizationas themeansto providesecurecommunicationamongsocialpeers.Morespec ically,insteadofusing apeer-to-peerlibraryAPIforcommunicationinthenetwork,d evelopersarepresented withtheabstractionofaprivatenetworkwhichsupportsthe IPprotocolandassigns privateaddressestoendpointsautomatically.Whenasocial networkingapplication sendsapackettoapredenedprivateIPaddressofasocialpe er,itissenttoavirtual networkinginterfaceandtheoperatingsystemhandsthepac ketovertotheP2P architecturewhichtunnelsitoveradirect,encrypted,pee r-to-peerconnection.This mechanismcreatesavirtualprivatenetworkconsistingofo nlytrustedsocialpeers.This abstractionenablesusefulfeaturessuchastheabilitytor eachallfriendsthroughthe useofmulticastorbroadcastIPaddresses.Throughvirtual ization,developersarenot requiredtolearnnewAPIsandcanapplywell-knownnetworkpro grammingtechniques whichgreatlyreducesthecodingcomplexityofsocialnetwo rkingapplications. Anotherkeyadvantagetoprovidingavirtualnetworkmadeupo fsocialpeersis thenaturalsupportforunmodiedlegacyapplications.Con siderauserthatenables iTunesmediasharingoverthesocialvirtualprivatenetwor k;automatically,iTunes 29

PAGE 30

becomesasocialapplicationthatmakesitpossibleforfrie ndstosharemediawith eachother.Thebenetisthat,althoughsocialpeersaregeo graphicallydispersed, nomodicationisrequiredtolegacyapplicationstoextend theirreachfromthelocal areanetworktothewidearea.Byrunningaserviceoverthenet work,itbecomes privatelyaccessibletosocialpeersandformsthefoundati ontoeffortlesslyenablesocial networkingapplications.1.3.3UserDenedNaming PrivateIPconnectivityprovidesabasisforsocialP2Pcommun ication.However, theseIPaddressesaredynamicthereforehinderingtheirus easstaticendpointsto services.PrivateIPaddressesaredynamicduetotheaddress spacelimitationsof IPv4,alongwiththeuseofDHCPtotemporarilymapendpointst oIPv4addresses.A similarsituationexistsintheSocialVPNarchitecturewhereI Paddressesassignedto socialpeershavetobereassignedtoavoidIPconicts.Cons iderAlice'sfriendBob isassigned172.31.23.41ashisprivateIPaddress,thenrea ssignedadifferentIP addressof172.31.115.98.Therefore,discoveringBob'svir tualIPaddressmaybecome aburdensometask.TheadventofIPv6furtherincreasesthene edtoutilizedomain namesratherIPaddressesduetotheirextendedlength.Since theInternetprovides bothIPconnectivityaswellasadomainnamingsystem(DNS)fo rlocationtransparency anduser-friendliness,providingonlyIPaddressesthroug htheproposedarchitectureis notacompletesolution.Consequently,anamingserviceisa lsorequiredtohelpusers refertotheirfriends'servicesusingeasytoremembername s. Toaddressthisissue,theproposedarchitectureprovidesa distributeddomain namingsystemcalledSocialDNS.Byleveragingtheunderlying P2Pmessagingsystem, SocialDNSgivesuserstheabilitytomapsocialpeerstocanon icaldomainnames.The globalDNSsystem,currentlyusedontheInternet,doesnota llowuserscontrolover thedomainnamesassociatedwiththeirmachines.Mostuserm achinesdonothavea domainnamemapping.Ifusersrequiredomainnames,thatusu allyinvolvesanetwork 30

PAGE 31

administratororacomplicatedprocessofrunningaDNSserv er(e.g.BIND)alongwith complexcongurations.SocialDNSletsusersdenetheirown domainnameswithout theneedforanetworkadministratororaDNSserver. ThereareexistingdecentralizedDNSsystemsforthelocala reanetworksuch asApple'smulticastDNS[ 24 ],ortheWindowsInternetNamingService(WINS)[ 25 ]. However,thesesolutionsarenotwellsuitedforP2PVPNsbecause theyassume all-to-allconnectivityamongstallpeersintheprivatene tworkwhichisnotalwaysthe caseinP2PVPNenvironments.Bytransparentlymappingsocialpee rstodomain names,developerscanusepredictableendpointssuchas bob.sdns whichresolves toBob'scurrentvirtualprivateIPaddress,withoutrequiri ngdeveloperstotakeextra unnecessarystepstodiscoverBob'sprivateIPaddress. 1.4CaseStudy:DesigningaPeer-to-PeerMicrobloggingServi ce Microbloggingisasimple,yetpopularsocialnetworkingse rvicewhichhasbecome aprimarymechanismforpublishinginformationinaconcise andpracticalmanner. Theresearchcommunityhasbeendiscussingtheneedforadis tributedmicroblogging serviceinthewakeofthefrequentTwitterblockagesthatha veoccurredintheMiddle EastduetotheArabSpring[ 5 ].Varioussolutionshavebeenproposedbutonlythrough simulationswithoutarealimplementation[ 12 ]whileothersstilldependonacentralized component[ 26 ].Therefore,thismotivatedthecreationofalightweight, resilient,yet user-friendlyservice,calledLitter. ByleveragingthesecureIPconnectivity,multicastsupport andcerticate managementoftheproposedP2Parchitecture,developingLit terinvolvedprimarily writingthecodewhichhandlesthenetworkcommunicationan dthelocaldatabase storage.Designingapeer-to-peermicrobloggingservicew hichleveragedthevarious aspectsofthisarchitectureservedasaprototypetounders tanditslimitations. Theprivatesocialconnectionsandthekeymanagementaided thediscoveryand identicationoffriendsinasimplerfashionthantraditio nalP2Papproaches.Theuse 31

PAGE 32

ofstandardIPcommunicationmadetheLitterdesignmorepor tablebyallowingits deploymentonboththelocalareanetworkandthevirtualpri vatenetworkwithoutany codechanges.Overall,Litterprovidesasolutiontothepro blemofcreatingapractical distributedmicrobloggingserviceandtheavailabilityof theP2Parchitectureprovides moreexibilityandportabilitytothedesign. 1.5Contributions Theprimarycontributionofthisdissertationisacomprehe nsive,peer-to-peer architecturethatfocusesonprovidingaprivatenetworkin genvironmentthatsimplies thedevelopmentanddeploymentofdistributedsocialnetwo rkingapplications.Thisis accomplishedbyprovidingthesenovelcapabilities: Socialpeerdiscoveryandcryptographickeymanagement. Throughtheuseof socialnetworkingAPIs,theproposedarchitectureautomatic allydiscoversexisting socialpeers,exchangesandmanagescryptographicinforma tiontobootstrap securenetworkingconnectionsamongfriends. IPConnectivitywithzero-congurationIPaddressingandr esolution. The useofnetworkvirtualizationcombinedwithadynamicIPtra nslationmechanism makesitpossibleforthesystemtoassignvirtualIPv4addres sestosocialpeers withoutglobalsynchronizationwhichassuresnosubnetcon ictsandaddresses theIPv4addressshortageproblem. Decentralizeddomainnamingsystem. AsocialDNSsystemletsuserschoose shortnameswhichalsoincorporatessocialcontextanduniq ueness,alongwitha rankingmechanismforhandlingDNSconicts. 1.6Outline Therestofthedissertationisasfollows:Chapter2explain sthetechniquesthat handlecryptographicmanagementandsocialpeerdiscovery throughexistingsocial networkingsystemsItalsodiscussesthevirtualizationte chniquesofSocialVPN. Chapter3discussesthesupportofunstructuredoverlaysin cludingenablingdeployments formobiledevices.Chapter4detailsthedesignofSocialDNS whichisaP2Psocial namingsystemcomplementingtheglobaldomainnamingsyste m.Chapter5describes 32

PAGE 33

theimplementationofapeer-to-peermicrobloggingservic easacasestudyforthe framework.Theremainingchallengesandfutureworkaredet ailedinchapter6. 33

PAGE 34

CHAPTER2 SECURINGIPCONNECTIONSTHROUGHSTRUCTUREDOVERLAYS Despitethewidespreadusageofsocialnetworks,directsoc ialconnectivity,inother words,privatepeer-to-peer(P2P)connectivitybetweenfrie nds,isstillamajorhurdlefor socialnetworkingsystemsduetotheheterogeneousstructu reandconstraintsofthe InternetsuchaslimitedIPv4addressspace,NetworkAddressT ranslators(NATs)[ 27 ] andprivatenetworkcongurations.Furthermore,mostofth esesocialnetworking applicationsrequirecentralizedadministrationtoauthe nticate,control,secureand mediateinteractionsamongstpeers.Thesecentralizedarc hitecturesnecessitate complexsupportandmanagementtomeetcontinuousdemandfr omusers,aswellas signicantinfrastructureinvestmentinordertorobustly handlemillionsofusers. Peer-to-peer(P2P)systems,ontheotherhand,arearchitecte dtoachieve scalabilityandavailabilityinadistributedfashionwith outrelyingoncentralizedservers. However,theylackacomparableframeworkforauthenticati on,accesscontrol,and securitywhicharecommonlyavailableincentralizedinfra structures.Thisworkthus advocatesanapproachwheresocialnetworkinginfrastruct uresareutilizedtobootstrap securesocialconnectionsoverP2Poverlaynetworks.Thesyn ergyofthesetwomodels producesascalable,secureandreliablesystemcapableofs upportinglargernumbers ofuserswithsignicantlylessinfrastructuresupportand managementcomplexity. Thiscombinedsystemcanbeperceivedintwoways:eitherase nhancingsocial networkingcapabilitieswithP2PconnectivityorevolvingP2 Poverlaysintosecure, socialnetworkingplatforms. Thischapterpresentstheconceptofasocialvirtualprivat enetwork(SocialVPN), anapproachaimedatbridgingthegapbetweensocialandover laynetworking.Atthe heartofSocialVPNliestheabilitytoautomaticallyestablish directpeer-to-peerLayer 3networklinks asaresultofconnectionsorfriendshipsestablishedthrou ghsocial networkinginfrastructures.Thisworkismainlyconcerned withasocialnetworking 34

PAGE 35

infrastructureasasystemwhichallowsforthediscoveryof peersandthebinding cryptographicpubliccerticates(e.g.X.509certicateso rX.509certicatengerprints) totheseidentities.Hence,asocialnetworkinginfrastruc turecanrangefroma full-edgedonlinesocialnetworksuchasFacebooktoanenc ryptedGoogleHangout chatsession,andevenaPGP-signedemailexchangesamongstpe ers. Assumingtheaforementionedinfrastructuresaretrusted,u serscanseamlessly leveragesocialnetworkingrelationshipstoestablishpri vatenetwork-layerchannels.In thiscontext,socialnetworkingiskeytoenableadecentral izedsystemwhereusersare abletomaintaintheirindividualtrustrelationshipswith friendlyinterfaces.Therefore, P2Poverlaynetworkingbecomestheessentialmessagingsubs trateenablingthe formationandmaintenanceofdirectprivatetunnelswithou tanycentralizedbackend. SocialVPNletsuserscommunicatesecurelyusingexistingTCP/I Papplicationssuch asdesktopsharing(e.g.VNCandRDP),sharedlefolders(e.g. SMBandNFS), audio/video-conferencing,andmulti-usergamesinthepre senceofNATsandrewalls andwithoutmodication,afeaturewhichisnotcurrentlysu pportedbysocialnetworking infrastructures.ByusingprivateIPaddressestocreatedir ectTCP/IPconnectionsto socialpeers,socialnetworkingapplicationdevelopersar enotrestrictedtoanyparticular protocolormessageformat.Suchacapabilityempowersdevel operswithaccesstoall ofthetoolsnecessarytooptimizetheirdesignfortheirspe cicsocialapplications. Towardsthisgoal,theproposedoverlayarchitectureisnov elinthefollowing respects:1)itenablesautomaticassignmentanddynamictr anslationofvirtual privateIPv4addressestohostsinanon-intrusivemannerwhi chavoidsIPconicts withcurrentnetworkdeploymentsandrequiresnousercong uration;2)itsupports automaticexchangeanddiscoveryofpeercredentials(e.g. X.509certicates)through multiplesocialnetworkinginfrastructures,allowingend -to-endauthenticationand encryptionofallcommunicationamongtrustedpeers.Inthi sapproach,theonly congurationrequiredfromusersisthecreationandmanage mentof socialconnections ; 35

PAGE 36

thecongurationandmaintenanceof IPnetworkconnections isself-managingand completelytransparenttousers.TheSocialVPNconnectionsar ethusaccomplished withoutburdeninguserswiththecomplex,error-pronecon gurationtypicallyrequiredto bringuppublickeyandnetworktunnelinginfrastructuresi nVPNs. Thischapteralsodescribesandevaluatesaprototypeimple mentationbasedon theIPOP[ 28 ]virtualnetwork,differentsocialnetworkinginfrastruc tures(includingthe Facebookplatform,aWebback-endbasedontheDrupalconten tmanagementsystem, anPGP-signedemailexchangesbypeers),andanPKI-basedIPpack etencryption securitysystemsusingX.509certicates.Experimentsinbot hlocal-andwide-area networksareusedtodemonstratethecapabilitiesandmeasu retheperformanceof thesesocialIPlinks.Theexperimentsareconductedinreal istic,large-scalewide-area environments,includingover500SocialVPNroutersdistribut edacrossvecontinents overthePlanetLabinfrastructure,andover100SocialVPNvirtu alendpointsdeployed dynamicallyovertheAmazonElasticCloud(EC2)infrastructur e. 2.1BackgroundandRelatedWorks Currentonlinesocialnetworksdonotprovidedecentralize dcommunication amongstpeers.Asaresult,Web-basedsocialnetworks(WBSNs)ag gregateuser contentincentrally-administereddomainsrequiringuser storelinquishcontrolof potentiallyprivatedata.Althoughthiscentralizationfac ilitatespeerdiscoveryand contentsharing,itprecludespoint-to-pointapplication accesssuchasmulti-media streaming,interactivemultiplayergames,anddesktopsha ringbecauseuserscanonly interactthroughthepredenedconstructssupportedbythe WBSNs.Furthermore, WBSNsrequiremassiveinfrastructuresthatcanstorehugeamou ntsofusercontent (e.g.hundredsofmillionsofphotosandvideos)andserveth ehighnumbersof simultaneoususerrequests,furtherincreasingthecostan dmaintenanceofthese socialsystems[ 29 ].SocialVPN'sabilitytosecurelyconnectpeersthroughIP-lay er networklinksinaseamlessandautomaticmannerenablesnew methodsofsharing 36

PAGE 37

aswellasapplicationcommunicationcurrentlynotsupport edbysocialnetworks. Consequently,thispeerconnectivitydrasticallyreduces thecentralizedinfrastructure requirementssinceitnolongerneedstomediateeveryuseri nteraction.Forexample, peerscansharelesdirectlywithoneanotherwhilecontrol lingtheircontentsinceno intermediatestorageisneededonsocialnetworkingbacken ds. 2.1.1KeyManagement Efcientdistributedpeerdiscoveryandcryptographickeym anagementisstill anopenprobleminP2Psystems.Variouskeymanagementmodels exist;someare basedonacentralkeydistributioncenter,othersbasedonI P-multicastordistributed hash-tables[ 30 31 ].Thisworkpresentsseveralkeydistributionschemesfrom asimple PKI-basedmodelwhereallbindingsecuritycredentials(i.e. X.509certicates)are retrievedfromasingletrustedsourcetoaweboftrustmodel whenuserscanperform certicateexchangesoverPGP-signedemails.Fromausabilit ystandpoint,acentralized socialbackendgreatlysimpliesthepeerdiscoveryandkey managementprocess,butit isnotarequirement.(Section 2.2.2 ). Cryptographickeymanagementinpeer-to-peernetworksisa requirementfor formingauthenticatedend-to-endcommunicationchannels andaccesscontrol[ 31 32 ].Previousworkonsecurityframeworksforcollaborativeco mputingprovidesa usage-controlmodelwhichincorporatesahybridmodelbase donattributeacquisition andevent-updatestocontroldecisionsforresourceaccess [ 33 ].Domingo-Ferrer[ 34 ] proposestheuseofpublic-keycryptographyinsocialnetwo rkstoreducetheoverhead ofmanagingprivaterelationshipswhichalleviatesthereq uirementsofthesocial networkinginfrastructure.Previousworkshavenotstudied thepossibilitiesofusinga trustedsocialbackendtosimplifythepeer-to-peerkeyman agementproblem. Inthecaseofpeer-to-peercommunication,twoapproachesa repossible.One approachistoexchangesharedsessionsecretkeysthrought hecentralizedbackend, butthisrequirescommunicationwiththebackendtorefresh sessionkeysperiodically. 37

PAGE 38

Theotheroptionistousethesecurebackendchannelforaone -timepublickey exchange(morespecicallyX.509certicate)betweenthepe ers.Oncethepeers haveobtainedeachother'scryptographicpublickeys,they candirectlynegotiateand generatesymmetricsessionkeysforencryptedpeer-to-pee rcommunication.Thelatter approachisdesirablefrombandwidthandscalabilitystand points,becauseitdoesnot necessitateconstantinteractionwithacentralizedbacke nd,anditistheapproachtaken inthisdissertation.2.1.2SupportforLegacyApplications Overlaynetworkshavebeenverysuccessfulindeliveringco ntentinaP2Pfashion –suchasSkypeforVoIPorBitTorentforlesharing.However,o verlaynetworks typicallyconnectusersattheapplicationlayer,alsoeffe ctivelyprecludingavarietyof legacyapplicationsfrombeingused–forinstance,onecann otstreamiTunesmusicor playamultiplayergamethroughSkype.Therearealargenumbe rofsoftwarepackages basedontheInternetProtocol(IP),throughtheuseoftheBerke leysocketsAPI.These existingandlegacysoftwarecanbeusedwithanewnetworkin gparadigm,suchasone basedonsocialconnections.Bymeansofvirtualnetworking, itispossibletoproducea virtuallocalareanetworkenablingthereuseoflegacyTCP/I Pbasedsoftware. 2.1.3IPv4ConnectivityandAddressLimitations Internetuserstodayareregularlybehindnetworkaddresst ranslation(NAT)devices usingdynamicallyassignedIPaddresses.Eventhoughsoftwa reexiststoenablele transfer,conferencing,andcollaboration,thesetoolsty picallyrequirededicatedcentral serversinordertohandlecaseswhereusersarenotdirectly addressablebyone another.TheproposedoverlaynetworkwithNATtraversalsu pportandself-optimizing directconnectionscandrasticallysimplifythedevelopme ntanddeploymentofsocial networkingapplications. VirtualprivatenetworksrequireuniqueIPaddressesforuse rs.PublicIPv4 addressesarescarceandoftennotavailabletoendusers,an dprivateIPv4addresses 38

PAGE 39

arenotsufcienttoenableeachuserofatypicalsocialnetw orktoobtainaunique virtualIPaddress.Forinstance,thenumberofFacebookuse rs(currentlyover900 million)islargerthanthenumberofIPaddressesavailable inthe10.0.0.0classA privateaddressspace[ 29 ].DespitethefactthattheIPv4addressspacesupportbillio ns ofuniqueaddresses,mostuserswillonlyrequiredirectcom municationwithafewtens orhundredsofusers[ 29 ].Furthermore,thestructureoftheseimplicitcommunicat ion networksishighlyclustered[ 35 ]basedonthesmallworldphenomenon.Thesefacts aboutsocialcommunicationpatternsareleveragedtoenabl eadynamicIPassignment andtranslationschemewhichavoidsIPv4addressspaceconi ctswithexistingnetwork congurationswhilemaintainingsupportforlegacyTCP/IPa pplications(Section 2.2.5 ). 2.1.4ExistingVirtualPrivateNetworks Virtualprivatenetworkshavebeenthepopularchoiceforena blingwide-area accesstoresourceinprivateorganizationalnetworks.Pop ularsoftwareproductssuch asOpenVPN[ 36 ]aregreattoolsthatprovideprivateIPlayertunnelinginw ide-area communicationamongpeers.Thisapproachsuffersfromtwom ajordrawbacks:a singlepointoffailure,anderror-proneconguration.Int hisclient-servermodel,all encryptedIPtunnelingisconductedthroughapubliclyaddr essedVPNserverwhich makesthisapproachhighlycentralized.Also,thecomplexit iesofcongurationandkey distributionmakethisapproachunappealingwhenforminga d-hocvirtualorganizations forwide-areacommunication.Variousvirtualnetworkingp rojectsforgridandcluster computingenvironmentsexist(suchasVINE[ 37 ],VNET[ 38 ],orVIOLIN[ 39 ]),butthey utilizeroutingtablesthataremanagedandnotself-congu ring,makingitdifcultto establishprivateconnectionsamongpeersinanad-hocP2Pfa shion. Recently,P2PVPNssuchasHamachi[ 20 ],N2N[ 40 ],orELA[ 41 ]havebecome popularpeer-to-peeralternativestocentralizedVPNs.InHa machi,backendSTUN-like serversareusedtoenableNATtraversalandestablishdirec tpeer-to-peerconnections amongusers;theseserversalsogeneratesessionkeysforen cryptionandadminister 39

PAGE 40

groupaccesscontrol.ThiscontrolinHamachiisdonethroug hsharedsecretkeyswhere individualusersdonotinitiallycontrolwhohasaccesstot henetwork.Thisapproach differsfromSocialVPNarchitectureintwoways:1)SocialVPN'sNA Ttraversalisnot centralizedbecauseitusesexistingnodesintheoverlayto performUDPholepunching fordirectpeer-to-peerconnectivity,and2)nodesnegotia tetheirownsessionkeysand manageaccesstotheirnetworklocallywithoutacentralize dbackend.N2N,ontheother hand,doesnotrequireacentralizedbackendbutitprovides layer2networkingand usesadifferentpeer-to-peernetworkthanthering-struct uredoverlayinSocialVPN[ 42 ]. TheN2Npeer-to-peernetworkusessupernodesthatactasrel aynodesforedge nodesthatcannotcommunicatedirectlyandtheyalsostoree dgenodeinformation. N2Nalsorequiresmoreconguration;forexample,automati cDHCPcongurationis notavailableandpre-sharedkeysareusedforlinkencrypti on.SocialVPNrequires virtuallynocongurationandprovidesautomaticDHCPandD NSservices.ELAisalso apeer-to-peerVPNwithDHCPsupport;howeveritusesadiffere nt,hierarchicalP2P overlaywhileSocialVPNusesaatring-basedP2Poverlay.Also,t heseVPNsdonot integratewithonlinesocialinfrastructureswhichisoneo ftheSocialVPN'skeystrengths. SocialVPNalsousesadynamicIPtranslationmechanismwhichre quiresnoglobal knowledgeandcoordinationamongthenodesforIPallocatio n.Suchcoordinationis usuallyrequiredtoavoidIPcollisionssinceallendpoints insaidVPNscommonlyuse thesameIPaddressspace. 2.2Design TheSocialVPNarchitecturecontainsthefollowingcomponents :1)connection privacythroughencryptedend-to-endauthenticatedchann els,2)peerdiscoveryand certicateexchangethroughatrustedsocialbackend,3)di rectpeerconnectivityand legacyapplicationsupportthroughIP-over-P2Poverlaynetw orking,and4)dynamicIP allocationandtranslationwhichavoidsnetworkconicts. 40

PAGE 41

2.2.1StructuredOverlayRouting AfundamentalcornerstoneoftheproposedP2Parchitecturei sitsuseofa structuredP2PoverlaycalledBrunet[ 43 ].BrunetisaSymphony-basedstructured overlaythatorganizesallnodesinaringstructurewithsho rtcutconnectionsto guaranteelogarithmicrouting.Themainbenetofusingthe Brunetoverlayistoenable all-to-allconnectivityamongstallthepeersinthesystem ,eventhosebehindnetwork addresstranslators(NATs)andrewalls.Therefore,throu ghtheuseofa160-bitP2P address,anodeisguaranteedapathtoanyothernodeinthepe er-to-peernetwork bysimplyusingagreedyroutingalgorithmtorouteamessage towardsitsdestination. TheSymphony-basedstructuredoverlayalsoguaranteesefc ientroutingthattakes onaverage log(N) hopstoreachitsdestination.Brunetalsoprovidesadistrib uted hashtable(DHT)servicewhichthisworkutilizesasaglobal storagesystemforX.509 certicates;thuseliminatingtheneedtodependonacentra lizedbackendtoprovide thatstoragecapability. Nodes,thatarepartofthestructuredoverlay,canalsocrea tedirectP2Pconnections withsocialpeersoncetheydiscovertheirP2Paddresses.Brun etalsosupports encrypteddirectconnectionsifbothsideshavetheappropr iateX.509certicates; however,themanagementoftheseX.509certicatesarenotde ned.Addingthe capabilitytomanagetheX.509certicatesbyleveragingexi stingsocialnetworking infrastructuresisoneofthekeycontributionsofthisdiss ertation. 2.2.2PeerDiscoveryandCerticateExchange Peerdiscoveryistheprocessofobtainingalistofuniquepe eridentiers(e.g. emailaddresses)thatrepresentsocialpeers.Anysystemtha tcangeneratesuch alistcanthusbeconsideredasocialnetworkinginfrastruc ture,providedthatthe usersofthesystemtrusttheinfrastructure.Oncethesocia lpeersareidentied,the X.509certicatesboundtothepeeridentitiesareobtainedt hroughatrustedbackend, whichmayormaynotbepartofthesamesocialnetworkinginfr astructure.Ingeneral, 41

PAGE 42

Figure2-1.CerticateExchangeModels.Topleft:Inthecent ralizedmodel,thelistof friendsandtheircerticatesareobtainedfromasinglesoc ialnetworking backend.Topright:Inthesemi-centralizedmodel,thelist offriendsandtheir certicatengerprintsareobtainedfromoneormorecentra lizedsocial networkingbackends;certicatesarestoredandretrieved fromadistributed datastore(DHT).Bottom:Inthedecentralizedmodel,thelis toffriendscan beobtainedfrommultiplesocialbackends;certicatenge rprintsare retrievedfrommultipleidentityproviders,andcerticat esareexchanged overtheDHT.Peersthemselvescanverifyidentitieslocall y,e.g.followingon aPGP-basedweboftrustmodel.Inthelasttwocases,thecerti cate ngerprintsareusedtoverifytheintegrityofDHT-acquire dcerticates. theproposedarchitecturerequiresthefollowingcapabili tiesfromsocialnetworking infrastructures:1)theabilitytoqueryforalistofpeers, 2)theabilitytoretrievebinding informationaboutthepeer,3)andtheabilitytoexchangepu blicX.509certicates amongpeers.Thesefeaturesareavailableeitherthroughas ocialnetworkingAPI(e.g. FacebookAPI),orthroughanXMPPlibrarywhichissupportedbymo stofthemajor socialnetworkingsystemssuchasFacebook,GooglePlus,Skyp e,MSN,andsoforth. 42

PAGE 43

Thesecurityoftheproposedarchitectureisbasedonthepub lickeyinfrastructure (PKI)model.PKIsystemsarewell-understood,androbustimplem entationsare available;however,themanagementofkeysiscomplex,erro r-proneandoverwhelming toanenduserwhoisnotfamiliarwithsecurityconcepts.Byqu eryinganonline socialnetworkinginfrastructure,theproposedsystemhan dlesthemanagementand distributionofX.509certicatestransparentlyinasecure manner.Followingisthe descriptionofthreepossiblemethodsofperformingpeerdi scoveryandcerticate exchangethroughthreedifferenttypesofonlinesocialnet workinginfrastructures. CentralizedModel. Inthismethod,peercerticatesareautomaticallyexchang ed throughthetrustedcentralizedsocialbackendtoformdire ct,privateconnections.The centralizedmodelistheeasiesttomanageanddesign,andth isisillustratedwitha Facebookprototype.FacebookisaWeb-basedsocialnetwork (WBSN),anditprovides peerswiththeabilitytocreaterelationships,binddatato theiridentitythroughuser proles,andsharetrustedcontentwiththeirpeers.Throug htheFacebookGraphAPI, peersareabletoauthenticatethemselves,storetheX.509ce rticateontheFacebook datastore,andtheyarealsoabletoretrieveX.509certicat esoftheirsocialpeersas well(seeFigure 2-1 ).Asaresult,theFacebookPlatformcanbeleveragedtoemulat e someofthefunctionsofatypicalPKIallowingforthesecureac quisitionofX.509 certicates.TheX.509certicatecontainstwoeldsofbind inginformationthepeer identier(i.e.email)andtheP2Paddressforoverlayroutin g.Thatinformationservesa crucialrolebecauseitprovidestheidentityaswellasthee ndpointtobootstrapasecure connectiontotheuser. Semi-centralizedModel. Thishybridmethodissimilartothecentralizedmodel exceptforcerticatestorageandthepossibilityofsuppor tingmultiplesocialnetworking infrastructureback-ends.TheX.509certicate'sngerpri ntsaresecurelystoredonthe socialnetworkingback-end.Peersthensharepublicsecuri tycredentials(i.e.X.509 certicates)throughthedistributed-hash-table(DHT)av ailableinP2Poverlay(see 43

PAGE 44

Figure 2-1 ).UsingtheDHTforstorageandonlystoringthengerprints inthetrusted backendallowsforamorescalabledesignbecauselessstora geisrequiredfromthe backend.AssumingtheX.509certicatengerprintsareobtai nedthroughtrusted means,thecerticateexchangecantakeplaceovertheDHTas longasthepublic X.509certicate'sintegritycanbeconrmed.Oncethecerti catesaresafelyacquired andtrustedonbothendsthroughthevericationoftheirng erprints,theyareutilizedto formsecureconnectionsbetweenpeers. DecentralizedModel. Inthedecentralizedmodel,independentcomponentsare utilizedtogethertoserveasanonlinesocialnetworkingin frastructure.Forexample,a listofcontactsuniquelyidentiedbyemailaddresses;the refore,atrustedaddressbook canprovidepeerdiscovery.Thereisalsotheconceptofanid entityprovider[ 44 ],which maybeanyinfrastructurethatprovidesproleinformation basedonauniqueidentier; thisservestomeetthesecondcriterion.Therearecurrentl ymanyidentityproviderson theInternetsuchasWordPress,Paypal,Verisign,justtonam eafew.Throughsecured publicproles,userscanpublishtheircerticatengerpr intsthusallowingotherpeers toobtaintrustedngerprintsfortheseidentityproviders .Withthetrustedngerprints, theDHT-storedcerticatesbecomeveriableallowingfort hebootstrapofsecure connections. Theweboftrustsecuritymodelcanalsobeintegratedinthis architecturetoprovide anotherexampleofadecentralizedcerticateexchangemod el.Inthisscenario,aPGP keyisusedtosignaself-signedX.509certicate.Thereason forthedoublesigning isbecausethePKI-basedandPGP-basedmodelsarenotcompatible witheachother. Thishybridapproachallowstheproposedframeworktotakea dvantageofexisting PKI-basedsecurityinfrastructuresandtoleveragethedecen tralizedbenetsoftheweb oftrustPGPdesign. Toreiterate,therstrequirementforcreatingtrustedP2Pc onnectionsisthe trustedexchangeofX.509certicates.Userscaneasilyemai leachothertheirX.509 44

PAGE 45

certicates,aslongastheemailisPGP-signed.Ifthereceive ralsohasthesender's PGPkeyaspartoftheirPGPkeyring,theycaneasilyverifytheX. 509certicate integritywithPGP.Oncetheemailhasbeenveried,theuserc aninputthetrusted X.509certicatetotheSocialVPNsystemmanuallythroughtheus erinterface.Inthis model,theuserbecomesthesourceforpeerdiscovery,thetr ustedpeer'sPGPkey containstheidentitybindinginformation,andthepublick eyexchangeisdonethrough theemailmessagingsystem.Asintheothertwocases,oncepub lickeycerticatesare exchanged,theprocessofgeneratingandexchangingsymmet rickeysforencrypted communicationistransparentandisaccomplishedbyP2Pmess agingamongthe endpoints,e.g.byfollowingaprotocolsuchasDife-Hellm an.Thissamemodelhas beenappliedtoaninstantmessagingsystemthroughtheuseo ftheXMPPlibrary, whereuserscanshareeachother'scerticatesthroughanen cryptedXMPPchat session.Thecommonthemehereistheestablishmentoftrust ed,andnotnecessarily private,out-of-bandcommunicationchannelsforone-time exchangeofbindingsecurity credentials.2.2.3EstablishingPrivateConnections Connectionprivacyisanecessityforsecurewide-areacoll aboration.Whilevarious optionsarepossibletoinitiateasecureP2Pconnection,thi sapproachisbasedon public-keycryptographywhichsupportsthepublickeyinfr astructure(PKI)model.In doingso,onecanreuseexistingtoolsforprocessingX.509ce rticates,andseamlessly integratewithdatagramsecuritytechnologywhichiswidel yusedsuchasIPSecor DTLS[ 45 ].ThisarchitecturebuildsuponanIPSec-likedatagramsecur itymodelwhich worksasfollows:1)peersexchangeX.509certicatesthroug hatrustedmedium,2)the retrievedX.509certicatesserveasthetrustanchors(list oftrustedCAcerticates)for bootstrappingsecureconnections,3)asymmetricpublicke yshelpgeneratesymmetric sessionkeystoencryptthetrafcbetweenendpoints,using well-knownprotocols andimplementationssuchasDife-Hellmankeyexchange.Th ismodelthusallows 45

PAGE 46

forthecreationofauthenticated,private,end-to-endcon nectionswhichprotectsfrom third-partyintrusions. InordertobootstrapasecureP2Pconnection,self-signedX.5 09certicatesare exchanged.TheseX.509certicatesareself-signedandmust beacquiredthrough trustedmeansbecauseeachpeerultimatelybecomesthecert icateauthority(CA) oftheirowncerticate.InallPKI-basedinfrastructures,ab asicrequirementisthat theCAcerticatesserveasthetrustanchorsandmustbeacqu iredsecurely.Onrst run,anX.509certicateisgeneratedcontainingapeer'ssec uritycredentialssuchas name,email,country,organizationalunit,organization, andtheP2Paddress(inthe SubjectAltNameeld).TheP2Paddressisaunique160-bitident ieruniformlyassigned toeachnodeonthepeer-to-peeroverlay;itformsthebasisf orthepeer-to-peer structureandmessagerouting.Socialpeersareaddedtothes ystembyretrieving theirX.509certicatesfromatrustedsource.Tocreateasoc iallink,bothpeersneed toaddeachother'scerticate,if peer1 adds peer2's certicate,thesecurenetworklink willnotformuntil peer2 adds peer1's certicate.Thereciprocityensuresbothendpoints haveacknowledgedthesocialrelationshipbyexplicitlyad dingeachother'scerticate; thisprocessisautomatedwhentheproposedarchitectureco nnectstoanonlinesocial network.Theinformationinthecerticate,specicallyem ail,P2Paddressandpublic key,areusedbythisarchitecturetocreateanencryptedP2Pl inkboundtoeachsocial peer,meaningtheX.509certicatecontainsallofthecreden tialsnecessaryforthe secureconnection.2.2.4IPConnectivitythroughaStructuredOverlay ThemajorityofnetworkingapplicationsarebasedontheTCP/ IPprotocol;hence, theseapplicationscannoteasilyleverageP2Poverlaynetwo rksforconnectivity,since P2Plibrariesareusuallyincorporatedattheapplicationla yer.Allowingunmodied applicationsnetworkconnectivitythroughaP2Poverlayisa valuablefeaturethatcan expeditethedesignanddeploymentofwide-areasocialsyst ems.Additionally,social 46

PAGE 47

Figure2-2.SocialVPNArchitecture.Afterthepeerdiscoveryand certicateexchange throughasocialbackend,peersformdirect,encryptedchan nelswhere applicationscancommunicatethroughTCP/IP.1)Application ssendIP packetstotap0virtualNICthroughthekernelandtheuser-l evelsocialrouter capturestheIPpackets.2)Socialrouterchecksthedestinat ionIPwhich mapstofriendBob,encryptstheIPpacketwiththesymmetrick ey (previouslyestablishedfortheIP-over-P2Ptunnelafterpub lickeyexchange) andsendstheencryptedIPpacketovertheP2PtunnelthroughBo b's rewall.3)Bob'ssocialrouterreceivestheIPpacket.Itloo ksupinitslocal databaseinformationaboutthesource(includingAlice'ssy mmetrickeyand virtualIPaddress);itthendecryptsit,andupdatesthesou rceand destinationIPaddressesaccordingtheBob'slocalmapping. 4)Bob'srouter sendsthetranslatedIPpackettotheapplicationsthrought hekernel-based virtualNIC. networkingapplicationdeveloperscaninterfacewiththes ystemthroughtheBerkeley SocketsAPIinsteadofsomeobscurepeer-to-peerAPI.WhiletheIP-o ver-P2P(IPOP) layerintheSocialVPNarchitecturecanconceivablybedesigne dontopofvariousP2P substrates,thediscussiontofollowisbasedontheBrunetov erlay[ 28 ].Acapabilityof BrunetthatiskeyintheSocialVPNcontextisdecentralizedNATt raversal;theseand otheraspectsoftheBrunetoverlayaredescribedinprevious works[ 28 42 ]. 47

PAGE 48

Virtualnetworkinterfacescanbeutilizedtocaptureandinj ectIPpacketsfrom andtoahostoperatingsystemkernel[ 46 ].Thesecapturedpacketsarethentunneled asnormalapplicationP2Ptrafcthroughanoptimizedstruct uredoverlay[ 42 ].On thesendingside,thevirtualIProutersareabletoretrieve IPpacketsfromlegacy applicationsthroughthevirtualnetworkinterface,andse ndtheseIPpacketstothe appropriateP2Pnodeontheoverlay.Onthereceivingend,the routerreceivesanIP packetfromtheP2Pnetwork,andinjectsitbackintothehosto peratingsystem;thus enablingLayer3levelcommunicationbetweenapplications .AsshowninFigure 2-2 theSocialVPNvirtualIProutersmaintainamappingofIP-to-P2Pa ddresseswherea P2Paddressisboundtoaparticularpeerbasedoninformation obtainedfromthepeers' credentialsexchange(i.e.X.509certicatescontainingP2P addresses).Therefore,the routerspossessalistofP2Paddressesrepresentingsocialp eersontheP2Pnetwork andwillonlyrouteIPpacketstooracceptIPpacketsmappedt oP2Paddresses. EverySocialVPNnodejoinsastructuredP2PoverlaycalledBrunet[ 43 ],developed attheUniversityofFlorida.ThestructuredP2Poverlaynetw orkmanagestheconnectivity betweenthepeersthroughself-congurationandself-orga nizationasnodesjoin andleavetheP2Pnetwork,andemploysdecentralizedNATtrav ersaltechniquesto connectnodesthatarenotdirectlyaddressableovertheInt ernet[ 42 43 ].Whensocially connectedpeersareidentiedontheoverlaynetwork,direc tIPtunnelsareformedand maintainedtoallowlowlatencyIPcommunicationamongstpe ers.Intheanalysisofthe previouschapter,thecostofmaintainingthesocialconnec tionsontheP2Poverlayis measuredasthenumberofconnectionsincrease.Theanalysi sshowsthecosttobe manageable.2.2.5DynamicIPAllocationandTranslation DeploymentsofSocialVPNsneedtoaccommodateuserbasesthatc anbequite large–therearecurrentlyhundredsofmillionsofusersreg isteredwithWBSNs.This presentsachallengingproblembecauseVPNendpointsrequire uniqueIPaddresses 48

PAGE 49

andisthussubjecttoseveralconstraints.IPv6infrastruct ureandapplicationsarenot widespread;publicIPv4addressspacesarescarce;privateI Pv4addressesdonot scaletolargenumbers,andcancollidewithlocaladdresssp acesofuserswhoare increasinglyboundtoprivatenetworksbehindNATdevices. Intheproposedapproach, throughaddresstranslation,SocialVPNcanscaletonumbersof userslargerthanthe limitimposedbytheIPv4privateaddressrangewhileavoidin gaddressspaceconicts withendusernetworks. Thekeyideabehindthisapproachexploitsthefactthat,whi lethetotalnumberof participantsinanonlinesocialnetworkcanbeverylarge(h undredsofmillionsofusers), thenumberofrelationshipsasingleuserhasatanypointint imeissignicantlysmaller (typicallyhundredstothousands).Nonetheless,whileaus er'snumberofrelationshipsis relativelysmall,itislargerthanthenumberofnetworkint erfacesthatmodernoperating systemscantypicallyhandle.Therefore,asolutionthatmu ltiplexessocialnetworking connectionsintoasinglevirtualnetworkinterfacewithas inglevirtualIPaddressis desirable. SocialVPNaccomplishesthegoalofpresentingasingleIPv4virt ualnetwork interfacewhileavoidingaddressspacecollisions,asfoll ows.SocialVPNmaintains, ateachuser'sendpoint,aprivateIPaddressspacethatissi zedtoaccommodatethe expectednumberofsocialconnectionsausermayhave.Forin stance,a16-bitclassB privateaddressspacesupportstensofthousandsofconnect ions.Thisprivateaddress spaceisdynamicallyassignedlocallybytheSocialVPNrouters uchthatitavoids collisionwithanyexistingnetworkinterfacesofauser'sl ocalmachine. Thefollowingexample(seeFigure 2-2 )illustratestheaddresstranslationprocess. Forexample,ifauserhasaphysicalnetworkinterfacewitha nIPaddress172.16.5.16 withanetmask255.255.0.0,thevirtualnetworkinterfaceu sedbytheSocialVPN routerisautomaticallyconguredtouseanon-conictingI Paddressrangesuchas 172.17.0.2andpeersareallocatedIPaddressesinthe172.1 7.x.yrange.Eachpeeris 49

PAGE 50

alsoassignedanIPaddressintheselectedlocaladdressspa ce;amappingbetween theIPaddresstopeer'sP2PaddressismaintainedbytheSocial VPNrouter.The SocialVPNrouterusestheIP-to-P2PmappingstorouteIPpacketst otheappropriate peersbasedonthedestinationIP(e.g.destinationIP172.1 7.34.231mapstoP2P addressnode:4AB1,soallIPpacketswithdestination172.17. 34.231gotopeerwith thatnodeaddress,seeFigure 2-2 ). BecauseofthedynamicIPallocation,IPpacketsneedtobetra nslatedbythe receivedSocialVPNroutertomatchthereceiver'sIP-to-P2Pmapp ing.Consider AlicehasalocalvirtualIPaddressof172.17.0.2andherfrie ndBobisdynamically assignedtheIPaddress172.17.23.12byherlocalSocialVPNrou ter.OnBob's localSocialVPNrouter,hehasalocalvirtualIPaddressof172. 25.0.2andAliceis dynamicallyassignedavirtualIPof172.25.43.89.WhenAlice communicateswithBob overIP,Alice'sSocialVPNrouterreceivesIPpacketsfromtheho stOSwith172.17.0.2 asthesourceIPand172.17.23.12asthedestinationIP(Bob's address),andtunnels themdirectlytoBobovertheP2Poverlay.Bob'sSocialVPNrouterhe ncereceivesthe IPpacketsfromtheoverlayandchangesthesourceanddestin ationIPaddressesto theappropriateaddressesassignedbyBob'sSocialVPNrouter;m eaningthesource addresschangesfrom172.17.0.2to172.25.43.89,andthede stinationaddressfrom 172.17.23.12to172.25.0.2(seegure 2-2 step4).SinceonlyIPheadersaretranslated, allprotocolsaboveLayer3suchastransportlayerUDPandTC Pportsinformation remainunchanged. Duetothistranslation,IPaddressesarenotgloballyvalid inthevirtualnetwork. Forinstance,AliceandBobbothhaveafriendCarol,Aliceassig nsCarolanIPaddress of172.17.34.231,butBobgivesCarolthe172.25.1.94IPaddr ess.SinceonlyAlice's SocialVPNrouterhasthedistinctlocalIPmappingforCarol,Bob 'sroutercouldnot resolvethe172.17.34.231IPaddresstoCarol'sP2Paddress; inotherwords,ifAlice tellsBobthathecouldpingCarol'smachineat172.17.34.231 ,Bob'spingmessages 50

PAGE 51

wouldneverreachCarol'smachine.Althoughsourceanddesti nationIPaddressesare updated,UDPorTCPportsarenotchanged.Thisissimilartot henetworkaddress translationperformedbyfullconeNATs.Mostclient-serve rapplications(e.g.Web browsing,lesharing,remotedesktop)areabletoworkwith outchangeswithsucha NATbehavior;however,someprotocolswhichexchangeIPadd ressesinthepayload ofmessages(e.g.FTP,SIP,MDNS)requirepacketinspectionan dIPtranslationinthe payloadtoensurecompatibility.2.2.6TheP2PVPNSocialGraph SocialVPNhasaninterestingcharacteristicnotfoundintradi tionalVPNsinthatthe encryptedtunnellinksoftheP2PVPNnetworkrepresenttheedge sofasocialgraph withsmallworldcharacteristics.Forinstance,eventhoug hbothuserBandCarepartof userA'sVPN,itdoesnotimplythatusersBandChaveaVPNlinktoeac hother.This isanalogoustoasocialnetworkwhereAlicecanbefriendswit hbothBobandCarol, butitdoesnotmeanthatBobandCarolarefriends.Forscalabi lityandsecurity,itis importanttoonlyhaveVPNconnectionswithtrustedpeers;the reisnopointofhaving linkswithpeersofnocommoninterest.Thisisadeparturefr omthecommonconceptof privatenetworkssuchaslocalareanetworks(LANs)andtradi tionalVPNswherethere istheexpectancyofall-to-allconnectivityamongnodesin thesamenetwork. 2.3Experiments Thefocusoftheseexperimentsistodeterminetheperforman ceofthesystem whentheDHTisemployedasthecerticatedatastore.Inaddi tion,acentralizedsocial networkingidentity/relationshipproviderwasusedtofac ilitatethebootstrappingof anetworkduringtheexperiments.Somekeymetricsoftheprop oseddesignwere analyzed:1)thetimetoformtheprivatelinkswiththepeers ,2)thebandwidthoverhead costofmaintainingtheseprivateP2Plinks,and3)theserver loadonacentralized socialbackend. 51

PAGE 52

Intheexperimentalsetup,theAmazonElasticCloud(EC2)wasut ilizedtodeploy virtualmachineswithonevirtualcoreand1.7GBofRAMeachto testsocialnetworks ofvaryingsizes.ThesevirtualmachinesarebasedonDebian 5runningthe2.6.26 Linuxkernel.ThesoftwareiswritteninC#;hence,theMono. NETRuntimeversion 1.9.1wasused.EachvirtualmachinerantheP2Parchitecturew hichconnectedtoa pre-deployedP2Poverlaynetworkof500nodesrunningonPlane tLab[ 47 ].Aninitial20 SocialVPNnodeswerealsodeployedinacomputingclusteratthe UniversityofFlorida (UF);thesenodesrepresentedpeersthatarealreadyonline whenothersocialnodes jointhenetworkandalsohelpagainsttheclusteringeffect ofAmazonEC2nodes. Allofthenodesconnectedtothesamesocialnetworkingbacke ndtoobtain peerrelationshipsandpeercerticatengerprints.ADjan go-basedbackendwas implementedwhichprovidedthenecessaryservicesofasoci alnetworkinginfrastructure whichwasdeployedontheGoogleAppEngineCloudInfrastructu re[ 48 ].TheGoogle AppEnginebackendprovidedthetoolstomeasurethenumberofH TTPrequestsmade bythesocialendpoints,aswellasthestorageandCPUrequire mentsonthebackend. Alsointheexperimentalsetup,theX.509certicatengerpri ntswerestoredonthe onlinesocialnetworkingbackend,whiletheactualX.509cer ticateswerestoredonthe DHTtominimizethestoragerequirementsonthebackend.2.3.1LinkCreationTime Theexperimentsalsohelpedanalyzethetimetakentoformdi rect,private connectionsoncepeerswerediscoveredthroughthesocialn etworkingbackend. Twomainstepswereexamined:theX.509certicateretrieval fromtheDHT,andthe formationoftheencryptedconnectionsbetweenpeers,whic hincludestheexchange ofDife-HellmanmessagesovertheP2Poverlaytoestablisha pairofsymmetrickeys. UnderstandingthetimetakentoretrieveanX.509certicate fromtheDHTisimportant toprovethataDHTiscapableofsupportingsuchaloadwithan acceptableretrieval time.Themeasurementstakenwerefromdeploymentsof16,32 ,64,and128nodes 52

PAGE 53

Figure2-3.90thPercentileTimefordeploymentsof4to128n odes.Asnetworksize increases,DHTlookupperformanceremainsaround600milli seconds. deployedonAmazonEC2.TheseAmazonnodeswerebroughtupsimul taneouslyand ranfora50-minuteperiodineachdeploymentscenario.Inal lcases,therewasall-to-all socialconnectivityamongthenodes;inotherwords,with16 Amazonnodes,eachnode has15directconnectionswiththeotherAmazonnodes,plusth eadditional20direct connectionswiththenodesrunningattheUFcluster. Figure 2-3 showsthatasthenumberofpeersincreaseitconsistentlyta kesless than800msfor90%oftheDHTrequests,whichisareasonablet imespantoobtain anX.509certicatefromadistributeddatastore.Figure 2-4 providesahistogram demonstratingthedistributionofthecerticateretrieva ltimesfromtheDHTwiththe variousnetworksizes.Fornetworksizesof16and32,allDHT retrievaltimeswere below1200ms.ADHTrequestperformedonaChord-likestruct ureoverlayhasa complexityof lg(N) hopswhere N isthenumberofnodesintheP2Pnetwork.Hence, 53

PAGE 54

Figure2-4.DHTRetrievalTimesfordeploymentsof16,32,64 ,and128SocialVPN nodes.For16,32nodedeployments,100%ofDHTqueriestookl essthan2 seconds.For64-nodedeployment,98%of5311requeststookl essthan2 seconds.For128nodedeployment,94%of18782requeststook lessthan2 seconds.F1representspercentagewhichfailedonrstatte mpt,attempts succeededafterretries. withaP2Pnetworksizeofaround500to600nodes,ittakesanav erageof9hops toreachthenoderesponsibleforstoringthe < key,value > pair.Also,sincetheP2P networkisdeployedoverPlanetLabwhichhasgloballydisper sednodes,itisnothard toseewhyaDHTrequestmaytakeupto1200millisecondstoret urnavalue.Inthe 64and128deployments,therewasa1%and6%failureratesres pectivelyforrst-time DHTrequestscausedbycaseswherenodesissueDHTlookupsun der < key,value > pairsthathavenotbeensuccessfullystoredintheDHT.This happensbecausewhen64 or128nodesjointheP2Pnetworksimultaneouslyittakeslong erfortheP2Pnetwork 54

PAGE 55

Figure2-5.ConnectTimefordeploymentsof32,64,and128Soc ialVPNnodes. Connectiontimesremainstableasthenetworkincreasesupt o128nodes. N1representspercentagewithmorecomplicatedNATenviron ments,some nodestookuptoseveralminutesbeforetheycouldformdirec tconnections. tostabilizecausingsomeDHTPUTrequesttoinitiallyfail;a llDHTlookupseventually succeededaftersubsequentretries. Figure 2-5 showstheconnectiontimesfornetworksizes32,64,and128. Inall cases,over85%oftheconnectionstooklessthan800ms.Thec onnectiontimeinvolves peerscreatingdirectpathstoeachotherwhereNATtraversa lisperformedwhen necessary.WithAmazonEC2nodes,NATtraversalisnotrequired betweenthesenodes sincetheyareonthesameinternalnetwork.NATtraversalis necessarybetweenthe UFandAmazonnodesbecausetheUFnodesarelocatedbehindaNA T.Ineachcase, between15%to20%oftheconnectionstookoveronesecondtoc onnectduetothe NATtraversalprocessbetweentheUFandAmazonEC2nodes. 55

PAGE 56

Figure2-6.Bandwidthcostassocialnetworksizeincreasesf rom4nodesto128 nodes.ThisisthebandwidthconsumedbytheSocialVPNrouterto maintain thestructuretheP2Pnetworkaswellasthedirectlinksbetwe enpeers. 2.3.2BandwidthCost Thebandwidthoverheadofmaintainingthesocialconnectio nsontheP2P overlaywasalsomeasured.Thecalculatedbandwidthisthea veragenumberof bytestransferredpersecondacrossalltheAmazonEC2nodesfo reach50-minute deployment.Figure 2-6 showsthatthebandwidthcostincreasesproportionallywit h thenumberofpeersinthenetworkstartingat0.2KBytespersec ondto1.2KBytes persecondsfromanetworksizeof4friendsto128friends.Th eP2Poverlayuses bandwidthformaintenancesuchasroutingtableupdates,pr obing,DHToperations, andnodesjoining/leavingtheoverlay.Peersareproactive lyprobed(every15seconds) todeterminethestatusofthenode.Hence,thereisasmallba ndwidthoverheadfor maintainingthestructuredoverlayandthedirectsocialco nnections—afewpercentage pointsofatypicalbroadbandwithaccesstohundredsofKbit/ sbandwidth. 56

PAGE 57

2.3.3ServerLoadonBackend Thisresearcharguesthatthehybridapproachleveragesthe benetsofP2P communicationtoalleviatetheinfrastructuredemandsofo nlinesocialnetworks; therefore,thenumberofHTTPrequestsweremeasured,andba ndwidthconsumedby theexperiments.Thecurrentimplementationessentiallym akesthreetypesofHTTP requeststothesocialnetworkingbackend:getfriends,get ngerprints,andstore ngerprint.ThesethreeHTTPrequestsareperformedevery veminutes,andwhen anewsocialnodejoinsthenetwork,tosynchronizetheremai ningnodes.According totheGoogleAppEnginesitemonitoringtoolstakenovera24-h ourperiodfor38 socialnodes,theserverreceivedatotalof44121HTTPreque stswithabandwidth costof300MBytes.Eachnodemadeanaverageof48HTTPrequests perhour,and consumed293KBytesofbandwidthperhourforcommunicationwi ththesocialnetwork. Thecostofaggregatingalltheworkonasingleserverwascom pared.Theper-node costsaretrivial,butevenforthissmallexample,theserve rbandwidthcostswouldbe non-negligible.2.3.4PrototypePerformance Todate,theSocialVPNrouterhassuccessfullyintegratedwith theFacebookAPI, withanopen-sourceWebback-end(Drupal),andwithsupport formanualentryof self-signedcerticatesthroughtheuserinterface(seeFi gure 2-7 ).Thelatterapproach supportsuserstocopy/pastePGP-signedemailmessagesconta iningSocialVPN certicatesasthemechanismfordiscoveryandpublickeyex change.Theprototype routerleveragestheIPOPoverlay,whichsupportsbothIP-ove r-P2Ptunnelingand aDHT.Theuser-levelrouterisimplementedinC#andworkswi ththeMonoand .NETruntimes,usingthetapvirtualnetworkdevice.Theprot otypeimplementsa user-levelsecuritystackontheoverlaythatisinspiredby theIPsecprotocol.Aprevious implementationthatintegrateswithakernelIPsecstackhas beendemonstratedinprior work.Deploymentsoftheprototypeonhundredsofwide-area PlanetLabnodeshave 57

PAGE 58

Figure2-7.SocialVPNUserInterface. beenrunningcontinuouslyformonths;intheexperimentsde scribedbelow,aseparate overlaywascreatedonresourcesdistributedacrossPlanetL ab,AmazonEC2and resourceswithinthelabattheUniversityofFloridatoasse sstheperformanceofthe prototypeandestablishthefeasibilityoftheproposedapp roachquantitatively. Severalapplicationshavebeenqualitativelyandquantitat ivelyassessedthelatency overheadandbandwidthachievedbytheprototype.Thefollo wingapplicationswere successfullytestedbetweenSocialVPNnodes:VNC-andRDP-based sharedremote desktopsessions,lesharingthroughSMBandNFS,multi-pla yer3DLANgame (Valve'sCounterStrike),HTTPserverwithApache,musicshar ing/streamingthrough iTunes,multicast-basedservicediscovery(MDNS/SD)Bonjour [ 24 ],directP2Pchatwith PidginoverBonjour,VoIPwithEkiga. 58

PAGE 59

ThebandwidthandlatencyofSocialVPNaremeasured.TwoSocialVPN nodesran onthesameclusterconnectedbya1GBEthernetswitch.Thepin gtoolwasusedto measuretheround-triplatenciesof100ICMPrequest/reply packetsandobtainedan averagelatencyof1.1ms.Thebandwidthwasalsocalculated withtheIperfnetwork measurementtoolbymeasuringtheTCPthroughputofa30seco nd-transferand achievedabandwidthof30Mbps.Overall,theobservedperfo rmanceisacceptable forwide-areaenvironmentsusingasocialnetworkingsyste mwhichisthetargetofthe proposedarchitecture.Nonetheless,performanceimprove mentsareactivelybeing pursued. 2.4Summary Socialnetworkinginfrastructurescangreatlyfacilitatet hecongurationand deploymentofsystemsbecausetheyhaveprovenquiteeffect iveinenablingusers todiscoverandassociatewiththeirpeers.Thischaptersho wsanarchitecturewhere socialconnectionsestablishedthroughuser-friendlyWeb -basedinfrastructurescan effectivelyguidethecreationofencrypted,authenticate dconnectionsatthecomputer networklayer.Thisisachievedinauser-transparentmanne randsupportingawealth ofexistingTCP/IPapplicationsontopofexistingnetworkin ginfrastructure.Todate, thisistherstworktointegratesocialnetworksandwide-a reapeer-to-peeroverlay networks.Aprototypeimplementationoftheproposedappro achandexperimentswith adeploymentonPlanetLabandAmazonEC2infrastructurehassho wnthisapproachto befeasibleandpromising. Inthischapter,threemethodsofcryptographickeymanagem entwerediscussed. Throughtheuseoftrustedthird-partysystems,X.509certi cateswereefciently exchangedamongsocialpeers.Thesecerticatesprovidedt hecrucialinformation neededtobootstrapencrypted,peer-to-peerconnectionst osocialpeers.Through integrationwithpopularsocialnetworkingsystems,users areabletoautomatically discoverfriendsandmanagetheirsecuritycredentialsina seamlessway.Additionally. 59

PAGE 60

byadoptingthestandardPKImodeltobootstrapencryptedconn ectionsthroughthe useofX.509certicates,theproposedarchitectureisablet oreusewell-established standardsandprotocolssuchastheDife-Hellmanexchange .Consequently,social networkingapplicationdevelopersdonothavetoreaddress thecomplexitiesof cryptographickeymanagement,socialaccountcreationand relationshipmanagement sincetheyarealreadyprovidedintheproposedarchitectur e.Moreimportantly, developersknowthattheirapplicationswillinheritthein trinsicprivacyofthesystem, sincetheyknowthatallcommunicationisauthenticated,an dencryptedend-to-end. Withtheprivacyissueshandledbythearchitecture,designi ngasocialnetworking applicationbecomeamuchlesscumbersomeventure. Thischapteralsodescribedadecentralizedmethodofimple mentingaself-conguring virtualprivatenetworkwhichtremendouslyfacilitatesso cialnetworkingapplicationsfor socialpeersovertheInternet.SocialVPNcombinesvariousexi stingtechnologiessuch associalnetworkingAPIs,structuredpeer-to-peeroverlays ,andPKIcerticatemodels toprovideaneasy-to-use,scalable,yetsecureIP-levelcom municationlinkamong friends.Bymaintainingastructuredpeer-to-peeroverlaya samessagingsubstrate, peerscaninitiateNATtraversalwhichenablesdirectIPtra fctunnelingamongsttwo peers.Thestructuredpeer-to-peeroverlayalsoprovidesa distributeddatastorethrough aDHTwhichcanbeusedforX.509certicatepublishingandret rieval. 60

PAGE 61

CHAPTER3 BOOTSTRAPPINGCONNECTIONSWITHUNSTRUCTUREDOVERLAYS Theproposedpeer-to-peerarchitecturesofarbuildsupona structuredP2Poverlay calledBrunet[ 43 ].BrunetisaChord-likestructuredP2Pnetworkthatarranges allofthe nodesinthesystemandithasusefulpropertiessuchasselforganizationintheface ofnodechurn,all-to-allconnectivityandefcientroutab ilityamongallnodes.However, therearesomeweaknessestothedependenceonthering-base dstructure.Therst problemisvulnerabilitytoSybilattacks.ASybilattackiswh enamalicioususerina P2Psystemisabletocreatemultipleidentitiesinthenetwor k.ThroughtheuseofSybil nodes,anattackercancontrolandmonitoralargeportionof theP2Poverlay. StructuredoverlaysarealsosusceptibletoDHTlocalizatio nattacks[ 49 ]where maliciousnodescrowdaparticularsourcenodebyselecting theappropriateP2P identiersandinterceptallcommunicationtoandfromthev ictimnode.Structured overlaynetworksarealsovulnerabletounrecoverablenetw orkpartitions.Forinstance, consider1000nodeslocatedinEgyptinastructuredP2Poverla yof100,000nodes locatedallaroundtheglobe.IftheEgyptiangovernmentdisc onnectsthecountryfrom therestoftheInternet,the1000nodesinEgyptaredisconnec tedfromtheP2Poverlay andthereforecannotrouteanymessagesevenamongeachothe r. Thepurposeofthischapteristodescribesupportforanunst ructuredoverlayand providesimilarcapabilitiesasthestructuredoverlay,pr imarilyroutability,anddirect connectivityfrombehindNATs.ThemajorityofthepopularP2 Papplicationsdeployed ontheInternetsuchasGnuNet,FreeNet,Gnutellaandsoonar ebasedonunstructured P2Pnetworking.Thesenetworksachievethegoalsofroutabil ityanddirectconnectivity inavarietyofmethods,wheresomeuseooding,random-walk ing,greedyrouting, andprobabilisticrouting[ 50 ].AlsounstructuredP2Poverlaysaremoreresistantto nodechurnbecausetheydonothavetomaintainanystructure .However,thislackof structuremakesithardertoachievesomeofthefunctionali tythatiseasilyattained 61

PAGE 62

throughastructuredoverlay.Supportformobiledevicesisa lsodiscussedinthischapter duetotheproliferationofmobiledevices,itiskeythatthe proposedP2Pframeworkalso enablesdeploymentsformobilecomputing.Addressingnewpa radigmsofcomputing (i.e.cloudandmobile)requiressomefundamentalredesign ofthepreviouscore componentsbuttheimprovedapproachallowsformoremuche xibility,interoperability, andextensibility. ThischapterpresentstheTinCandesign,aP2PVPNthatallowsex ibleVPN overlaysofdifferenttopologiesthatcanbeinstantiateda topInternetinfrastructurewith lowcongurationandmanagementoverhead 1 .TinCanintegrateswithexistingsocial networkingservicesforpeerdiscoveryandnotication,re ectionandrelayingtoallow deploymentsthatsecurelybootstrapprivatepeer-to-peer tunnels.Theoverlayimplied byprivateend-to-endTinCanlinksexposesIPendpoints,al lowingexistingapplications toworkunmodied,andprovidingabasisforoverlaypeer-to -peerroutingforthevirtual network.TheTinCandesignalsosupportsbothIPv4andIPv6rou tingwithintheVPN whichisimplementedasIPv6packetsencapsulatedwithinUDP packetsandsentover IPv4P2Ptunnels,aswellasIPv4packetswithinIPv6UDPpackets. Akeygoalinthedesignistominimizetheamountofcongurat ionandinfrastructure necessarytosustainthesevirtualprivatenetworks.Becaus eTinCanrunsonendpoints (e.g.VMsorpersonaldevices),itrequireslittleadditiona linfrastructureformaintaining thenetwork.TinCanlinksmakeitpossibleforVMsandmobiled evicestotunnelIP trafcdirectlytoeachother—evenwhenconstrainedbyNATs —whilesimultaneously givingenduserstheexibilitytodenetheIPaddressrange s,subnets,andaccess controlpoliciesfortheirprivatenetwork.TinCanintegra teswithubiquitousmessaging overlaysthatusetheXMPPprotocolforsignaling,alongwithw ell-adoptedtechnologies 1 Thenameisinspiredbytincanphonesthatprovideprivate,a d-hoccommunication linksbetweenfriends 62

PAGE 63

forNATtraversal(STUN,TURN,andICE[ 51 – 53 ])tobootstrapencryptedTinCan links.Inoneusecase,socialpeerscanrunTinCantodeployVPN scomprisedof theirpersonal(mobile)devicesandtheirsocialpeersbyle veragingexistingInternet servicesfordiscoveryandreection(e.g.GoogleHangouts ,Jabber.orgXMPPand STUNservers).TheonlyrequirementfordeployingaTinCanVPNi sanXMPPserver; therefore,enduserscanuseanyfreelyavailableXMPPservice ontheInternet,or deploytheirownprivateXMPPserversuchas ejabberd [ 54 ]. ThenoveldesignofTinCanislogicallydividedintwokeylay ers—reminiscentof theOpenFlowmodelbutappliedtotunnelsoverUDP/TCPlinks: 1)adatapathpacket capture/forwardinglayer,responsibleforcapturing/inj ectingpacketsfromavirtualNIC, andmaintainingTinCanlinks(overUDPorTCP)toneighboring peers,and2)acontrol layer,responsibleforimplementingpoliciesforthecreat ionandtear-downofTinCan links.EachTinCanpeerrunsthetwolayers;communicationac rosslayerswithinanode isachievedthroughaJSON-UDPRPCinterface.TheavailableAPIa llowsforthecontrol ofTinCanlinkcreationanddeletion,mappingIPaddressest oidentitiesandTinCan links,andconguringvirtualnetworkinginterface.Coord inationamongendpointsand overlayroutingispossiblethroughmessageforwardingalo ngTinCanvirtualIPv6links, supportinguser-denedoverlaytopologiesandroutingpol iciesimplementedasa separatemodulefromthecoredatapath. TodemonstratetheapplicabilityofTinCanindifferentuse cases,TinCanimplements acommondatapathbasedonGoogle'slibjingleP2Plibrary[ 55 ],andtwodifferent TinCancontrollers:a“group”controllerthatfollowsatyp icalVPNmodelprovidinga privatesubnet,anda“social”controllerthatautomatical lycreatesVPNlinksfromsocial networkingrelationshipsestablishedthroughanexternal OSNprovider.Withthegroup controller,nodesbindtothesamesubnetinthevirtualnetw orkandcanaddresseach otherusinguniqueprivateIPaddresseswithinthescopeoft heVPN.Insocialmode, eachuserisabletodenetheirownprivateIPrange/subneta ndlocallymapsocial 63

PAGE 64

peerstoIPaddresseswithinthatsubnetthusforminganunst ructuredsocialnetwork graphoverlaytopology. TheanalysisshowsthattheTinCandesignisquitepractical andscalablewithout imposingunrealisticloadontheXMPPserver.Intheexperimen ts,anetworkof300 nodesconsumes29KB/sofbandwidthontheXMPPserver.Themanage mentof theseTinCanlinksusesabout1KB/sofbandwidthperconnectio nandthereisa 14%networkingoverhead.Thisoverheadisduetotheuseofan MTUof1280bytes —selectedtominimizepacketfragmentation—ratherthanth etraditional1500byte MTUalongwiththecostofanadditional40-byteheaderneces sarytoencapsulatethe virtualIPpackets.Tomeasurethemaximumthroughput,anex perimentwasconducted betweentwonodesina1GbpsLANandrantheiperfnetworkingbe nchmarktoobtain thebandwidthmeasurements.Theresultsshowalatencyofle ssthan1msandaTCP bandwidthof64Mbps;sincethetargetistocreatevirtualne tworksacrosstheInternet, formostapplications,thebottleneckwillbethebandwidth limitimposedbytheirlocal ISPs. ThemaincontributionofthischapterisanovelVPNdesignthat leveragesXMPP serverstobootstrapend-to-endVPNtunnels,supportsdecoup ledcontroller/datapath modelandP2Pcommunicationamongcontrollerstoimplementd ifferentVPN membership,addressmappingandoverlaytopology/routing policies,andleverages existingP2Ptechnologies(STUN,TURN,andICE)forestablishi ngdirectandsecure P2PtunnelsforIPconnectivity.ThisisalsotherstP2PVPNdesig nthatallowsmobile devicestomaintaintheirvirtualIPaddressastheymigrate acrossdifferentnetworks whileautomaticallyre-establishingP2Pconnectionswitho thernodesinthevirtual networkwithouttheuseofarelay. 3.1BackgroundandRelatedWorks OverlayVirtualNetworkingResearch. Academicandindustryresearchhave exploredapplicablesolutionsforvirtualnetworkingthat allowgeographically-dispersed 64

PAGE 65

nodestocreatevirtualprivatenetworksacrosstheInterne t.IBMresearchershave developedVirtualWire[ 56 ]whichimplementsalayer2virtualnetworktailoredtothe deploymentoflegacyapplicationsandVMmigrationacrossdi fferentphysicalnetworks. Virtualwireisahypervisor-levelvirtualnetworkintegrat edwiththeXen-Blanket[ 57 ] nestedvirtualizationtechnology,enablingVMmigrationac rosspublicclouds.VIOLIN[ 39 ] usesaverysimilarapproachtoVirtualwireprovidinglayer2 networkingwithcomponents suchasswitchesandroutersimplementedpurelyinsoftware .Adrawbackwiththese approachesisthatusersarestillrequiredtocongurevirt ualswitches,routers,and deploytheirownDHCPandDNSserverswithinthevirtualnetw ork.TheTinCan approachdoesnotnecessitatesettingupadditionalDHCPan dDNSservers. VNET[ 38 ]provideslayer2connectivityacrossdifferentphysicaln etworksanditis alsoimplementedatthehypervisorlevel.Thisisaccomplis hedthroughalayer2proxy thatbridgestwodifferentnetworksacrosstheInternet.All ofthesepreviousworksdo notexplicitlydealwithNATsandrewalls,andassumetheav ailabilityofVPNgateways andvirtualrouterswithpublicIPconnectivity.Asthepoolo fIPv4addressesbecomes morescarce—compoundedbyrecursivevirtualizationandth euseofcontainers— establishingend-to-endvirtualnetworklinksacrossNATconstraineddevicesbecomes increasinglyimportant.VINE[ 37 ]isalayer3virtualnetworkingalternativewhich supportsNAT/rewalltraversalthroughrelaying.However ,itrequiresuserstocongure thevirtualroutersanddoesnotprovideend-to-endtunnels thatbypassarelay/router node.Thisworkenablesdirectend-to-endIPtunnelingwith outtheneedforarouter middlemanbecauseeachnoderunsanIProuterlocally. Host-basedandMobileVirtualNetworking. OpenVPN[ 58 ]isasolutionthat isapplicableinmobilevirtualnetworking.However,OpenVPN followsaclient/server architecturewhereallIPtrafcisroutedthroughacentral gateway.Thisincurshigh latencyandcreatesaresourcebottleneck.Manyothersolut ionsimproveonthe OpenVPNmodel;forinstance,Hamachi[ 59 ]usesaproprietarycentralserverto 65

PAGE 66

setupP2Pconnectionsbetweenhosts,eventhroughNATsandr ewalls.IPtrafc istunneledovertheseencryptedP2Pconnections.Otherappr oachessuchas Tinc[ 60 ],Vtun[ 61 ],andN2N[ 62 ]allcreatemeshVPNswherenodescreatedirect connectionstoeachother,buttheyrequirenodestobeopenl yaccessibleoverthe Internet.Whilethesesolutionscanpotentiallybeusedtoen ablewide-areavirtual networking,theyarenotcurrentlysupportedbymobileplat forms,anddonotprovide aexibleoverlayarchitecturethatsupportsotherVPNtopolo gies,suchasthose impliedbyfriend-to-friendsocialnetworkgraphs.UIA[ 63 ]isaclosely-relateddesign aimedatprovidingad-hocvirtualnetworkingformobiledev ices.Onekeydifferencein TinCanistheuseofexistinginfrastructure,includingOSNp roviders,tomediatepeer discoveryandbootstrapping.Previouswork,IPOP[ 64 ],isapeer-to-peerVPNbased onastructuredP2Poverlayforbootstrappingdirectconnect ionbetweennodes.While sharingsimilargoals,TinCanaddressesseverallimitatio nsoftheIPOPdesign:inIPOP, peerdiscovery,bootstrapping,reection,andrelayingar eprovidedbyanoverlaywhere peer-to-peercommunicationislayeredatopacommonstruct uredP2Plibrary(Brunet). TinCandecouplesdiscovery,reection,relayingandboots trapping,decouplesdatapath fromcontrolmodules,andexposesP2Pcommunicationthrough virtualIPlinks,allowing multipleoverlaytopologies.TheTinCandesigndoesnotdep endonastructuredP2P overlay,itusespubliclyavailableSTUNserversandXMPPserve rstobootstrapP2P connections. 3.2Design ThissectiondescribesthecorecomponentsoftheTinCandes ignwhichincludea packetcapture/forwardingdatapathmodule,anetworkcont rollermodule,adiscovery/notication overlay,reectionandrelayservers.TinCanprimarilyena blesanextensibleframework forbuildingP2PVPNsforvarioustypesofdeployments.WhiletheT inCandesign supportsotherimplementations,currentlyTinCanusesXMPPf ordiscovery/notication, STUNforreection,andTURNforrelaying,andleveragesthel ibjinglelibrary(developed 66

PAGE 67

Figure3-1.TinCanComponentsandOverview byGoogle)toestablishandmaintainP2PTinCanlinksusingth eaforementioned services.Figure 3-1 givesageneraloverviewoftheservicesinvolvedindeployi ngthe system.3.2.1Endpoint-HostedComponents Datapathpacketcapture/forwardingmodule. Thiscomponentisauser-level modulethatrunsontheenduserdevice.Itcreatesavirtualn etworkinginterface(vNIC) onthelocaloperatingsystemtocaptureandinjectIPpacket sto/fromlocalapplications. Italsopossessesthemechanicsofcreating,maintaining,a ndtearingdownencrypted TinCanlinkstopeers,andmanagesalocalroutingtablethat mapsavirtualIPaddress ofanappropriateTinCanP2Plink.Inatypicalpacketowscen ario,thismodulereads anIPpacketfromthevNIConthelocalOS,usesthedestinatio nIPaddresstolookup 67

PAGE 68

whetheramappingtoaTinCanP2Plinkexists.IfaTinCanlinke xists,theIPpacket isencapsulatedandsentdirectlyoverthislinktotherecei vingdatapathmoduleat theotherendpointnode.UponreceivingtheIPpacket,there ceiverdecapsulatesand injectsitinthelocalvNIC(seegure 3-2 ). ThedatapathmoduletracksthestateofthelocalP2Plinks,an dmaintainsa connectiontooneormorenoticationoverlays(e.g.XMPPserv ers).TinCanlinksare typicallytunneledoverUDP—asitismostamenabletoNATtra versal—anduseDTLS forprivacy,authentication,andintegrity.Thedesignals ouseskeep-alivemessagesto determinethestateoflinks,andusesthenoticationoverl aytoverifythatonlinepeers thatareavailabletoacceptTinCanconnectionsrequests.T hismoduleisresponsiblefor implementingthemechanismstomaintainTinCanlinks;howe ver,itdoesnotprescribe thepoliciesassociatedwithlinkcreationandtear-down.T othisend,itexposesanRPC interfacetothecontrollermodule,decouplingmechanismf rompolicy.TheRPCAPI exposesthefollowingfunctionality:1)congurationofth evirtualnetworkinterface,2) creationanddeletionofTinCanlinks,3)registrationinto thenoticationoverlay,and4) addingamappingforadestinationvirtualIPaddress(seeg ure 3-2 ). NetworkController. Thecontrollermoduleimplementsdifferentpoliciesfor managingTinCanlinksandtheoverlaytopology.Throughthe APIexposedbythe datapathmodule,thecontrollerdeterminesthecriteriafo rTinCanlinkcreation,deletion, andthemappingofIPaddresses.Forexample,acontrollerma yimplementapolicy tocreateP2Pconnectionswhenanodejoinsthenetworkforasm all-scaleVPNwith aproactivelinkcreationpolicy,oronlycreateconnection sondemandwhenvirtualIP trafcisdetectedbetweenendpoints.Thecontrolleralsom anagestheconguration ofthevNIC,includingtheIPaddressandnetworkmask.Moreo ver,itmaintainsthe credentialsforconnectingtothediscoveryoverlayforcer ticateexchangeswithpeers forsettingupprivateTinCanlinks.Figure 3-4 showsanexamplecongurationfora controller. 68

PAGE 69

Inadditiontoprogramminglocalforwardingtables,thecon trollerisalsoresponsible forroutingvirtualIPpacketsnotmappedtolocalTinCanlin ksthroughoneormore hops.ThismechanismisusedtoroutepacketswhenadirectTi nCanlinkisnot available,forinstancewhilealinkisbeinginitialized.C ontrollersbindtoanIPv6vNIC thatallowsittocommunicatetoneighboringcontrollersov erTinCanlinks;thisprivate IPv6addressisconguredwithauniquenodeIDwhichcanbeuse dforidentier-based routing.Indoingso,thecontrollerscanusethismechanism toimplementdifferent overlaytopologiesandroutingalgorithmswithoutrequiri ngchangestothecoredatapath (seegure 3-3 ).Finally,thecontrolleralsodeterminesthepoliciesfor variousnetwork eventssuchasnodearrivalanddepartures,TinCanconnecti onrequests,andlink failures.3.2.2Internet-HostedComponents Notication/DiscoveryOverlay. Asstatedabove,thedatapathmodulemaintains acommunicationlinkwithanoticationoverlay(e.g.XMPPser ver)thatallowsfor theadvertisementofnetwork-wideeventssuchasnodearriv alsanddepartures.The noticationoverlayplaystheroleofthetrustedout-of-ba ndchannelforbootstrapping encryptedTinCanconnections(seegure 3-4 ).Whentwonodesdecidetocreatea TinCanconnection,theyexchangealistofcandidateendpoi nts(i.e.publicandprivate IPaddressesandports)andsecuritycredentials(i.e.X.509 certicatengerprints).The noticationoverlayprovidesthefollowingprimitives:1) multicastnoticationtopeers connectedtotheoverlay(e.g.XMPPbuddies),2)unicastmessa gedeliverytoaspecic node,and3)nodeauthenticationandmessageintegrityguar anteeingtrustednode identityandmessagedelivery. ReectionandRelayServers. Therearetwoservicesneededinthepublic networktoenablethebootstrappingofTinCanlinksthrough NATsandrewalls.First, reectionserversareusedtoinformnodesoftheirpublic-f acingIPaddressesandports. NodesarethenabletoexchangetheirpublicIPinformationw ithothernodesthrough 69

PAGE 70

Figure3-2.InteractionbetweenTinCanModules thenoticationoverlaytobootstrapTinCanconnections.Wh ilemostNATsareamenable toUDPNATtraversal,around8%ofthetime[ 55 ],nodesbehindsymmetricNATsor somerestrictiverewallscannotcreatedirectTinCanconn ections(seegure 3-1 ).In thosecases,theyrequiretheassistanceofarelayserverwi thapublicIPaddress.A relayserviceservesasanindirectcommunicationpathwhen adirectTinCanlinkcannot beestablished.3.2.3ControllerPolicies AkeyaspectoftheTinCandesignisextensibility,accompli shedthroughdecoupling ofthecontrolleranddatapath.Thisapproachisinspiredby OpenFlow[ 65 ],butapplies attheIPlayerovertunneledlinks,ratherthanatlayer2ow soverphysicallinks.To illustratetheextensibilityofthedesign,thissectionde scribestwodifferentcontroller models:a“group”VPNforvirtualprivateclusters,anda“soci al”VPNconnectingmobile devicesofsocialpeers(seegure 3-3 ).Fortheformerusecase,thecontrollercreates aVPNwherenodesjointhesamevirtualsubnet(e.g.10.10.0.0/ 16)andIPaddresses areassignedbytheVPNnetworkcreator.VirtualIPaddressesar eboundtonode identierswithinthescopeofthisVPNbyconguringthenodeI Dtobeacryptographic hashfunctionofthevirtualIPaddress.TinCanlinksarecre atedon-demandinresponse 70

PAGE 71

toIPpacketsbeingcapturedbythedatapathmodule;whileli nksaresetup,packets maybedroppedbyacontroller,orroutedthroughoverlayhop s.Inthe“social”VPN model,thecontrollercreatesVPNswhereper-endpointvirtua lnetworkaddressspaces arecreatedateachnode,peersaremappeddynamicallytoIPa ddresseswithinthis namespace,andaddresstranslationishandledtransparent ly.Forinstance,Alicehas friendsBobandCarol;herVPNbindsvirtualIPaddressesofBoban dCaroltoalocal privatesubnet(e.g172.31.x.y).BobandCarolhavetheirown mappingsoffriendsto virtualIPaddresseswithinthelocalIPaddressspace(e.g. Bobuses10.15.x.y,Carol uses192.168.5.y).AlicemaylinktoBobandCarol,whileBoband Carolmaynothave adirectlinktoeachotheriftheyarenotfriends.Sofar,twod ifferentcontrollershave beenimplementedbutothercontrollerscanbedesignedwith variousIPallocationand managementpolicies. NetworkAdmission. Nodesjoiningthenetworkadvertisethemselvesand exchangeconnectioninformationforbootstrappingthroug hatrustednotication overlay.Hence,admissiontothenetworkiscontrolledbyes tablishingidentitiesand membership(e.g.friend-to-friend,orgroups)inthenoti cationoverlay.Inthegroup VPNscenario,eachnodeinthenetworkisgiventhefollowingne tworksettings:a privateIPaddressandnetmask,thenetworkID,theaddresso fthenoticationoverlay service,andausername/passwordforaccessingthegroupth roughtheoverlay.For example,supposeTrentisatrusteduserresponsibleforcre atingaVPN.Trentcreatesa personalVPNanddistributescredentialsforauthentication andnetworkaccessforeach endpointtojointhenoticationoverlay.Alternatively,Tr entmayestablishrelationships (e.g.XMPPbuddies)withotheruserswhoareauthorizedtojoin theVPN.Trentwould thendeterminetheIPaddressrangeandnetmaskforthenetwo rkanddistributethese settingstoeachVMthatjoinsthevirtualnetwork.Inthesoci almobileVPNcase,users havetheirowncustomizedviewofthenetworkandthusdenet heirownpeer-to-peer trustrelationshipsinthenoticationoverlay,andselect theirownlocalprivateIPaddress 71

PAGE 72

andnetmask.Insocialmode,usersarenotrequiredtoshareXM PPcredentialsto othermembersoftheVPNbecauseTinCanleveragesexistingsoc ialrelationshipsto determineadmissionintotheP2PVPN;therefore,onlyauser'sXMPP buddieswillbe partofauser'ssocialVPN. ProactiveLinkestablishment. Ifthecontrollerimplementsa“proactive”linkpolicy, ittriggersaconnectionrequestassoonasanodejoinstheno ticationoverlayand proactivelycreatesTinCanP2PlinkstopeersevenifnoIPpac ketsareowing.This policyhasthebenetofreducinglatencyforpackets,butco mesatthecostofincreased resourceutilization(portsandbandwidth).Theproactive linkpolicyimpliedbythis approachmaybeapplicableforsmalloverlays[ 66 ],butisnotscalable(seegure 3-3 ). On-DemandLinks. Analternativecontrollerpolicyis“on-demandconnections ” whereTinCanlinksareformedwhenthecontrollerreceivesa packetwithadestination IPaddressthatisnotcurrentlymappedtoaTinCanlink.This eventtriggersa connectionrequestthroughthenoticationoverlay,which resultsinanewTinCan linkbeingmappedtothedestinationIPaddress.Suchapolicy causesadelaywhen connectingtonewIPaddresses.Thecontrollerwiththispol icyalsolimitsthenumberof connections,andcanexpirelinkswithinactiveIPows. SocialProleLinks. Anotherconnectionpolicydealsisonewherenodesare onlyinterestedinconnectingwithsocialpeersratherthan everynodeinaparticular group.Inthismodel,peerscreateproactivelinkswithfrie ndsthattheyhavefrequently communicatedwithinpastsessions,andon-demandormultihoproutingthrough commonfriendsfornodesforwhichcommunicationisinfrequ ent.Otherpoliciesmay includeacombinationofon-demandandproactiveconnectio ns,andcreateoverlay topologiesthatattempttomatchcommunicationpatternsex pected(orobserved)by applications(seegure 3-3 ). IPAddressingandTranslation ThecontrollerhastheexibilitytoassignanIP addresstothedeviceandmapfriendstoIPaddressesinasubn etrangethatdoesnot 72

PAGE 73

Figure3-3.VPNTopologies conictwiththelocalnetwork.Eachcontrollerisabletosel ectitsownsubnetrange withoutcoordinatingwithacentralizedentityorcontroll ers.Therefore,in“socialvpn” mode,eachcontrollercanselectadifferentsubnetforthei rnetwork;meaningthat IPaddressesareonlyvalidlocally.Thisisofcrucialimpor tanceforIPv4addresses wherethevirtualaddressspaceislimitedandcanleadtoIPc onicts.Sinceeach userdenestheirownnetwork,theycanfreelyselectIPaddr esseswithoutfearof networksubnetcollisions.ThedatapathmoduleperformsIP packettranslationon incomingpacketswhichensuresnoIPconictfollowingthea pproachdescribedin previouswork[ 67 ].Forexample,Alicemapshermobilephoneto172.31.0.1andm aps Bobto172.31.0.2.Onhismobiledevice,Bob'scontrollermaps hismobiledevice to192.168.0.1andmapsAliceto192.168.0.2.Hence,Aliceisa bletoreachBob's mobilephoneusingthe172.31.0.2IPaddressandtheIPtrans lationperformedby thedatapathmoduleonBob'sphonewouldmakeitseemasifther equestcamefrom 192.168.0.2.Theproposeddesignalsoreadilycreatesapri vateIPv6addressspace andpseudo-randomlyassignsIPv6addressestonodesinthene twork.SincetheIPv6 addressspaceissovast,noIPtranslationisnecessaryduet omuchlowerprobabilities ofcollisionsinthevirtualIPspace. 73

PAGE 74

3.3Implementation ThecurrentTinCanimplementationreusesexistingtechnol ogiesandinfrastructures thatenableP2PconnectionsforbothSIPandWebRTCstandardsb yleveraging Google'slibjingle[ 55 ]P2PlibrarytocreateprivateTinCanlinks.XMPPservers(poss ibly federated)serveasthediscovery/noticationoverlay.Byu singSTUNandTURN serversforreectionandrelayingwhichareInternetservi cesalreadyfreelyaccessible, userscandeploytheirownVPNswithoutanyadditionalinfrast ructure. 3.3.1Endpoint-HostedComponents Packetcapture/forwarding. Thedatapathpacketcapture/forwardingmodule iswritteninC/C++andcurrentlyrunsonLinux,Android,Windo wsandOpenWRT. ThroughtheTUN/TAPkerneldriver,TinCanisabletoreceivea ndsendEthernetframes tothevNIC.TinCanuseslibjingle[ 55 ],leveragingitsadoptioninexistingsoftware(e.g. theChromebrowser).Whilethetypicaluseoflibjingleisfor audio/videostreamingin WebRTC,TinCanusesittotunnelvirtualIPpackets. Controllers. ThecontrollersarewritteninPythonandrunasaseparatepro cesson thelocalmachine.Controllersaccessthedatapathmodule' sAPIthroughaJSON-RPC interfaceoveraUDPsocket.ThecontrollerusestheAPIexpose dbythedatapath moduleto: RegisterwithcredentialstotheXMPPoverlay SetupthelocalvNICwithIPv4/IPv6addresses,andnetmask Create/DeleteaTinCanlinkoverjingle MapanIPaddresstoaTinCanlink QuerythestateofaTinCanlink HandlenoticationsreceivedthroughtheXMPPoverlay(e.g.n ewnodepresence, requesttoconnect) 74

PAGE 75

Handlenoticationsreceivedfromthedatapathmodule(e.g .toforwardvirtualIP packetstoothercontrollerswhenthedestinationisnotmap pedtoalocalTinCan link) ThroughtheAPI,onecanextendTinCantosupportvariouscombi nationsofpolicies anddeploymentsbasedonanticipatedusecases.3.3.2Internet-HostedComponents XMPPNoticationOverlays. Themessagingoverlaysplayacrucialrolein providingaccesstothenetworkandaswellasservingasatru stanchorforsignaling andbootstrappingprivateTinCanlinks.TheXMPPprotocolacc omplishesthisrole bysecurelyroutingXMLmessagesthroughuserauthenticated TLSconnections(see gure 3-4 ).Hence,TinCan-basedVPNsareabletoutilizepublicXMPPprovi ders(such asGoogleHangoutsorJabber.org),aswellasusetheirownXMPP service(e.g.an ejabberdserver)iftheydesirethatlevelofcontrol. STUNandTURNServers. Forthereectionandrelayservers,theSTUN andTURNprotocolsareused,respectively.Thesetechnolog iesareusedinthe SIP/WebRTCcommunitiestoenableP2Pconnectionsforaudioand videoconferencing; asaresult,therearemanypubliclyavailableSTUNserversth atTinCancanutilize whencreatingP2Pconnections.Forsomenodesbehindsymmetr icNATsorrestrictive rewalls,anXMPPserverandSTUNservermaynotbeenoughtoboot strapaTinCan link;therefore,lessthan10%ofthetime[ 68 ],thesenodesrequiretheassistance ofarelayservertohelpproxytheirTinCanconnections.The TURNstandards[ 52 ] providesucharelayingcapability.GoogleHangoutsisanex ampleofanexisting servicethatalreadyprovidessuchacapabilityforitsuser s;thereforeTinCanlinkscan leveragethatforconnectionrelayingthroughlibjingle.T herearealsomanyopen-source implementationsofTURNrelays.Thisworkusesoneofthosei mplementations[ 69 ]for experimentation. 75

PAGE 76

3.3.3BootstrappingPrivateTinCanLinks RendezvousthroughXMPP. TinCanassumesthattheXMPPserverisa thirdpartytrustedforpeerdiscovery,notication,andex changeofPKIcerticates. Userscanconnecttoserverstheytrust,ordeploytheirownp rivateXMPPserver. AllcommunicationfromTinCanmodulestotheXMPPserverisencr yptedatthe socketlayerusingtransportlayersecurity(TLS).Auseraut henticatesherselfwith theXMPPserverandbroadcastsapresenceprobetoallpeers(or buddiesinXMPP terminology)thatarepartoftheirgroup.Therefore,allof thenodeswithinthegroup thatareconnectedtotheXMPPserverreceivethepresenceprob e.Eachnodein thenetworkperiodicallybroadcastsapingmessagetoallot hernodesinthenetwork everytwominutes.Thedatapathmodulemaintainsalistofon linepeersalongwiththe timestampoftheirlastXMPPbroadcastmessage.Oncepeersare abletodiscoverand notifyeachotherthroughtheXMPPserver,theycanproceedtoc reatetrustedTinCan links. Tothisend,aconnectionrequestiscreatedcontainingther equester'sX.509 ngerprint,alistofendpointscontainingprivate/public IPaddresseswithportnumbers, andsecuritycredentialstoensureaccesscontrolfortheco nnection.Therequest isthensenttothepeerovertheXMPPoverlay.Therecipientrep liestotherequest withaqueryresponsemirroringthecontentsoftherequest: X.509ngerprint,listof endpoints,andsecuritycredentials.Oncebothsideshavet henecessaryinformation, theyinitiateaTinCanlinkwitheachotherbysendingpacket sdirectlytothesepublic IPaddressesuntilaresponseisreceived(seegure 3-4 ).Thisprocessfollowsthe InteractiveConnectivityEstablishment(ICE)RFC[ 53 ]. Asmentionedearlier,nodesexchangetheirX.509certicate ngerprintaspartof theconnectionrequest/replymessages.Toencryptthelink ,thelibjinglelibraryuses theOpenSSLDatagramTLS(DTLS)protocolwithpeercerticatev erication.Once thecerticateshavebeensuccessfullyveriedandasymmet rickeyisderivedfrom 76

PAGE 77

Figure3-4.BootstrappingConnectionsthroughXMPP theDife-Hellmanexchange,theDTLSprotocolcanproceedt oencryptdataowing throughtheP2Pchannelbetweenthepeers.IPpacketspickedb ythevNICinterface areencapsulatedintodatapacketssentoverthelink,andth usprotectedbyDTLS.Itis possibletoapplyIPsec-layerend-to-endsecurityatopofth evirtualnetworkoverlayas well. RendezvousthroughSocialGraph. TinCanalsosupportsthebootstrappingof connectionsthroughatrustedpeerincaseswhereanXMPPserve risnotavailable. Inthisscenario,well-knowntrustedpeerswithpublicIPad dressescanbeusedas rendezvouspointsfornodestoinitiateTinCanP2Pconnectio ns(seegure 3-5 ). Therefore,TinCannodescanusethesocialgraphforthesame functionalityasthe XMPPservers.BoththeXMPPserversandthesocialgraphcreatedby TinCan linkscanservetheroleofasocialoverlaywhereusersexcha ngeX.509certicate ngerprintsalongwithadditionalendpointinformation.T hepublicbootstrapnodescan alsorunadditionalSTUNandTURNserverstohelpnodesinthec onnectioncreation process.BydemocratizingtheSTUNandTURNservices,theTinC andeploymentcan becomeself-sustainingwithoutdependingonanyexternals erviceproviders. 77

PAGE 78

Figure3-5.BootstrappingConnectionsthroughSocialGraph 3.3.4Multi-hopRouting TinCan'smodulardesignalsoenablesittosupportmulti-ho proutingthrough controller-to-controllerpacketforwarding.Asmentioned earlier,theTinCandesign consistsofadatapathmoduleandacontrollermodule.Theco ntrollermoduleuses thedatapathmodule'sJSONRPCinterfacetoassignP2PlinkstoI Paddressesinthe network.Thecontrollermodulealsoindicatesaforwarderf orIPaddressesthatare notmappedtoaP2Plink.Inthecurrentimplementation,theco ntrollermoduletells thedatapathmoduletoforwardunmappedIPpacketstoitself .Hence,thecontroller modulecandealwiththeseIPpacketsaccordingtoitspolici es.Formulti-hoprouting, thecontrollercommunicateswithneighboringcontrollers inthesocialP2Pgraphto determinearoutingpathforIPpacketswithoutdirectP2Plin ks.Ifsucharoutingpath exists,thecontrollerforwardstheIPpackettotheappropr iatenexthopcontrolleruntilit reachesitsdestination.Uponreachingthedestinationcon troller,itisinjectedbacktothe datapathmoduleallowingittoreachitsdestinedapplicati on.Therefore,inthisexample, thecontrollersserveasforwardingagentsandunmappedIPp acketsareroutedthrough thisforwardingplaneuntiltheyarecorrectlydelivered.I tisimportanttonotethatIP packetsgoingthroughtheforwardingplanewillhaveworsep erformancewithrespect 78

PAGE 79

Figure3-6.EnablingMulti-hopSocialRouting tolatencyandbandwidthduetotheextraprocessing.Ifcont inuousandlowlatency communicationisrequired,itismoreefcienttocreatedir ectTinCanconnections betweenthecommunicatingnodes. 3.4Analysis Variousexperimentswereconductedtounderstandtheresou rcerequirements oftheTinCandesign.Thisanalysisalsofocusesonmeasurin gtheoverheadof maintainingtheVPNandpacketprocessing,andthepowerconsu mptiononmobile devices.Inordertomaketheseexperimentsreproducible,a llofthesourcecode isopenonGithubathttp://github.com/ipop-project.Tote stscalability,a300-node deploymentwassetuponFutureGrid[ 70 ]usingamixofvirtualmachinesandLinux containers(LXC).FutureGridisanexperimentalInfrastruc ture-as-a-Service(IaaS)cloud environmentthatisavailableforacademicresearch. Byrunninga300-nodeexperiment,itispossibletoanalyzeth ebandwidthusage ontheXMPPserver,aswellasthemaintenancecostofmanagingT inCanP2Plinks. RatherthanreuseexistinginfrastructuresuchasGoogleXMPP andSTUNservers,for 79

PAGE 80

theseexperiments,independent ejabberd XMPPandSTUNserversweredeployedin ordertohavegreatercontroloverthetestingenvironment. Thisexperimentconsisted of8virtualmachines(VMs)runningUbuntu13.10.OneVMranthe noticationoverlay service,the ejabberd [ 54 ]open-sourceXMPPserverwasused.AnotherVMhostedthe reectionandrelayservers,anotheropensourceimplement ationoftheTURNprotocol wasutilizedtoenabletheseservices[ 69 ].Forthesetwodeployments,thebandwidth loadontheXMPP,STUNandTURNserversissummarizedinTable 3.4 Eachoftheremaining6VMsran50instancesoftheTinCanimplem entation throughtheuseofLinuxcontainers(LXC[ 71 ])whichisalightweightvirtualization technology.UsingLXCallowsformoreefcientutilizationo fresourcesbecauseitmakes itpossibletosimulatea300-nodenetworkwithoutneedingt ouse300VMsorpersonal devices.TheLXCenvironmentisconguredtocreateanisolat edvirtualnetworkfor thecontainersresidinginthesameVM;thesecontainersaret henabletoconnectto theoutsideworldthroughtheIPtablessymmetricNAT.Theref ore,thenodesrunningon differentVMshavetorelyontherelayingservice(TURN)beca usethesymmetricNATs donotallowforUDPhole-punchingthusprecludingdirectTi nCanP2Pconnections.In practice,typicalusagescenariosareunlikelytobeascons trainedbysymmetricNATs, noristheuseofaproactiveall-to-allpolicyrecommendedf orallbutsmall-scaleVPNs, sinceitdoesnotscalewell. Forthisexperiment,the“socialvpn”controllerwasutiliz edtorepresenttheuse casewhereenduserswouldliketheirpersonaldevices(e.g. desktops,laptops,tablets, smartphones)alongwiththeirfriends'devicestobelongto thesameSocialVPNand therebyhavingsecurenetworkaccesstoeachother.Inthism odel,socialrelationships aremappedtoTinCanVPNconnections;forexample,ifAlicehasa friendBob,thenif theyrunTinCaninSocialVPNmodeontheirdevices,thesedevice swillautomatically joineachother'ssocialvirtualprivatenetwork.Hence,th eTinCanP2Plinksinthe SocialVPNmodewillresembletheedgesofasocialgraphbecause eachVPNlink 80

PAGE 81

Table3-1.ExperimentalSetupSummary ParameterValue NumberofVMs6NumberofContainerspernode50Numberofnodes300Numberofconnections1475BandwidthCostforTinCanconnection1KB/sAverageTrafcatXMPPserver19KB/sAverageTrafcatSTUNserver27KB/s representsasociallink(seegure 3-3 ).Tosimulatethissocialgraphenvironment, theBarabasi-AlbertmodelfromtheNetworkXgraphlibrary[ 72 ]generateda300-node graphwith1475edges(orTinCanlinks).3.4.1BandwidthCosts Duringthisdeployment,theaveragebandwidthconsumption attheXMPPserver isabout19KB/s;thisshowsthattheTincanprotocolincursver ylittletrafconthe XMPPserver.Thistrafcisprimarilytheperiodicpingmessag esthateachnodein thenetworksendtoeachothertoindicatethattheyarestill alive.Inthecaseofthe reection(STUN)server,theTinCanimplementationrunning ontheend-nodessends a64-byteSTUN bindingrequest andreceivesa72-byteSTUN bindingresponse every 15secondsperconnection.Therefore,thebandwidthcoston theSTUNserverfor supportingthedeploymentof1475TinCanconnectionsisabo ut27KB/s(or0.18KB/s perconnection).AlsotherearenumerousfreelyaccessibleST UNserversontheweb hostedbyGoogleandothersmeaningthattheseresourcescan alsobeleveragedfor thereectionservice.Table 3.4 summarizesthebandwidthcostsofthedeployment. InordertocalculatethebandwidthcostontheTURNrelayser ver,itisimportantto understandthemaintenancecostofeachTinCanconnection. LibjinglesendsaSTUN userrequest every500msandexpectsa SuccessResponse ;theaveragesizeofthese packetsis130bytes.Thesepingpacketshelplibjinglekeep trackofthestateofthe TinCanlinkintermsoflatency,jitter,andlinkfailure.Th erefore,eachTinCanconnection consumesabout1040bytespersecondasconnectionmaintena nceoverhead.When 81

PAGE 82

Table3-2.VPNNetworkPerformance LatencyTCPUDP LAN0.5ms325Mbps320MbpsTinCanDTLS1.07ms64Mbps47MbpsTinCannoDTLS1.07ms84Mbps128Mbps aTURNserverisusedforrelaying,thesepingmessagesarero utedthroughtherelay. AccordingtoGoogleresearch,about10%ofP2Pconnectionsreq uireaTURNrelayand therefore,supportinga300-nodenetworkwith1450edgeswo uldnecessitatearelay serviceforabout145connectionscostingabout145KB/sforco nnectionmaintenance. ItisimportanttonotethattheTURNservicewouldalsohavet orelayIPtrafcbetween thenodesthatitsupportsandthereforedeployingaTURNser vicerequiresthoughtful planningandproperaccesscontrol.TURNimplementationsp rovideuserauthentication makingitpossibletoidentifydifferentconnectionsandap plybandwidthlimitationsper user.Forinstance,itispossibletocongureaTURNservert oonlyallowamaximumof 50KB/sthroughputperconnectionandlimitthenumberofconne ctions.However,since therelayserviceisrequiredinthefaceofsymmetricNATs(i .e.less10%ofthetime)itis possibletosupportupto1000-nodenetworkonasingleTURNs erver.Therearealso commercialofferingssuchasturnservers.comthatprovide thisrelayserviceforafeeif usersdonotwanttodeploytheirownTURNservice.3.4.2NetworkPerformance OneofthedrawbacksoftheTinCandesignisthat,insteadofd edicatedvirtual switchesandrouters,eachnoderunstheirownvirtualroute rthattunnelsIPpacketsto theappropriateTinCanlinks.Therefore,everyIPpacketha stobeencrypted,decrypted, andtranslated.Thisuser-levelpacketprocessingcangrea tlyconstrainnetwork performance.Inthisexperiment,theiperfnetworkbenchma rkingsuitemeasuredthe maximumbandwidthachievablebyTinCanbetweentwonodesin thesamegigabitLAN. Asshownintable 3.4.1 ,TinCanachieves64MbpsforTCPand47MbpsforUDPwith DTLSencryption,butwithoutencryptionthebandwidthincr easesto84MbpsforTCP 82

PAGE 83

and128MbpsforUDP.ApossibleoptimizationforLANenvironm entsistobypassthe overlayandallowTinCannodesinthesameLANtodirectlyrout epacketstoeachother withoutencryption,asdescribedin[ 73 ].TinCansupportsthisrouter-modeofoperation; inthismode,containersorVMsonthesamehostcanallshareas ingleinstanceofthe TinCanrouter.Localnodescanthereforecommunicatedirec tlywitheachotherandonly usetheTinCanpathwaytoprivateconnectwithremotenodeso utsideoftheirLAN.It isalsopossibletorunTinCaninOpenWRT-enabledrouters,th isapproachwouldalso makeitpossibleforlocalnodestocommunicatedirectlywit houttheoverheadofthe localprocessingandtheywouldalsohaveconnectivitytono desintheP2PVPNsince theOpenWRTrouterwouldnowhaveaconnectionintothenetwor k. UnderstandingthetimeittakestocreateaTinCanconnectio niscrucialindesigning acontrollerwhenconsideringaproactiveconnectionpolic yversusanon-demand connectionpolicy.Asshowningure 3-7 ,themedianconnectionsetuptimeisabout6.3 seconds,withthe75%percentileat7.8secondsbutinthewor stcase,itmaytakeupto afewminutestobootstrapaconnectionduetodroppedconnec tionrequests.Therefore, itmaynotbeidealtouseanon-demandconnectionpolicyifan applicationgenerates burstytrafcthatissensitivetohighlatencystart-uptim es. 3.4.3EncapsulationOverhead Theproposeddesignincurspacketoverheadduetotheadditi onalheaders necessaryforIPencapsulation.Anothersourceofoverheadi stheselectionofa relativelysmallMTUforthevNIC.Ethernetdevicestypicall yhaveanMTUof1500bytes, butusinganMTUof1280bytesminimizestheprobabilityofUD Ppacketfragmentation. Moreover,theTinCanimplementationusesa40-byteheaderf oreachpacketconsisting ofa20-bytesourceuniqueidentier(UID)andanother20-by tedestinationUID.The 160-bitUIDscreatesanextralevelofindirectionwhichfac ilitatespacketroutinginthe network.Consequently,asmallMTUandtheextraheaderhasa nadverseimpacton networkperformance. 83

PAGE 84

Figure3-7.CDFof1450ConnectionTimes.75%ofconnections takelessthan8 seconds. Thefollowingexperimentquantiesthenetworkoverhead.F orthissetup,thereis aTinCannetworkofjusttwonodes,aSamsungGalaxyTab10.1an danUbuntu12.04 workstation.Thetablethasa1GHzdual-coreNvidiaTegra2p rocessorand1GBof RAMandtheworkstationisa3.0GHzIntelCore2Duowith8GBofR AM.Byperforming letransfersofdifferentsizesasshowningure 3-8 overbothWiFiandTinCan,the resultsshowanaveragenetworkoverheadof14%.Thisoverhe adcanbereducedby choosingahigherMTUcloserto1500bytesandbyusingasmall erheadersize(e.g. 128-bitUIDsinsteadof160-bit).3.4.4MobilePowerConsumption MobilecomputingsupportisanimportantaspectoftheTinCa ndesign;hence,an experimentontheAndroidtablet,withthenumberofconnecti onsscaledupfrom1to 23,providesinsightinthepowercostsofTinCanP2Pconnecti ons.PowerTutor[ 74 ], asoftware-basedpowermeasuringappavailableforAndroid, calculatedboththe 84

PAGE 85

Figure3-8.FileTransferPercentageOverhead.DuetoMTUof 1280andextra40-byte headerforIPencapsulation,thereisa14%overheadintheex tranumberof bytessentoverthenetworkforthesamelesizewhencompare dtoWiFi. WiFiandCPUenergyconsumption.IntermsofCPUenergyconsumpt ion,gure 3-9 showsasteadyincreaseinenergycostwhichaveragesabout0 .13Joules(J)per 5-minuteintervalrangingfrom4.3Jforoneconnectionto7. 2Jfor23connections.For comparison,theLinPackforAndroidbenchmarkonthesametab letconsumes64.7Jfor thesametimeinterval.TheWiFienergyconsumptioningure 3-10 showsadifferent patternwherethereisasharpenergyincreasefrom1to3conn ectionsfollowedbya steadystate.Asmentionedearlier,aTinCanconnectiongene ratesabout8network packetswithsizesaround130bytespersecondconsumingabo ut1KB/sofbandwidth. ThemobileWiFicardisabletohandlethebandwidthrequireme ntsofoneconnectionin low-powermode.However,oncethereismorethanasingleP2Pc onnection,theWiFi entershigh-powermodewhichincreasestheenergyconsumpt ionby1.5xfrom144Jto 220J(fora5-minuteperiod).SincetheWiFicardremainsinhig h-powerstartingwith twoconnections,thereisnosignicantchangeinenergycon sumptionasthenumberof connectionsincreases. 85

PAGE 86

Figure3-9.CPUEngergyConsumptiononMobile Figure3-10.WiFiEnergyConsumptiononMobile 86

PAGE 87

3.4.5ZeroInfrastructureExperiments ThekeyadvantageoftheTinCandesignistheabilityforause rtocreatetheir ownvirtualprivatenetworkbysimplyrunningthesoftwareo ntheirenddevicesor cloudinstancesandconguringittouseexistingXMPPservice s(e.g.Google.comor Jabber.org).Todemonstratethis,avirtualnetworkconsis tingoftwoAndroiddevices wascreated:aMotorolaPhotonQsmartphoneandaSamgsungGala xyTab7.The smartphonewasconnectedviatheSprint4Gnetworkwhilethet abletconnectedvia WiFinetwork.UsingtheGoogleXMPPservers,thetwodevicescre atedaSocialVPN andthereforehadprivateIPaccesstoeachotherasiftheyar econnectedonthesame LAN.UsingtheCSipSimpleAndroidapp,thetwodevicescouldperf ormSIPcalls betweeneachother.Thecallwasperformedbysimplyusingth edevices'virtualIP addressesastheSIPaddress(i.e.sip@172.31.0.101).Conse quently,secureSIPcalls wereconductedoverTinCanIPlinksthroughboththe4GISPre wallandWiFiNAT withoutanyregistrationorsignalingthroughaSIPserver.By leveragingGoogle'sXMPP servicealongwiththedozensofpubliclyavailableSTUNserv ersontheweb,userscan easilygetprivateIPconnectivitytoeachotheratnocost. 3.5Summary Cloudandmobilecomputinghavecreatedaneedformoreuserdenedoverlay virtualnetworkswhichenablebothnodemobilityandinform ationsecurity.Theproposed TinCandesignleveragesexistingoverlayandP2Ptechnologi essuchasXMPP,STUN, andTURNtherebycreatingasolutionwhereuserscandenean ddeploytheirvirtual networkswithoutneedingadditionalinfrastructure.Addit ionally,unlikeotherexisting solutions,thisapproachdoesnotrequirespecialaccessto thehypervisor,nordo usershavetocongurevirtualswitchesandrouters.Toprov idelayer3connectivity, eachnodeinthenetworkrunstheirownvirtualrouterwhichm apsIPaddressesto TinCanconnections.AnalysisoftheTinCandesignshowsthat anetworkof300 nodesincuracceptablebandwidthloadsontheXMPP,STUN,andTU RNservers.The 87

PAGE 88

experimentsalsoshowthatittakeslessthan10secondstocr eate75%ofTinCanP2P connections.TheadditionalheadersforIPencapsulationa ndsmallervNICMTUcause a14%networkoverhead.Intermsofmobilepowerconsumption ,itseemsidealtoonly maintainoneTinCanconnectionatatimetoavoidrunningthe WiFicardinhigh-power mode. Theevaluationsconsidertheoverheadsassociatedwithasi nglelink,andfor small-scaleVPNsthatcouldbedeployedwithaverysimpletopo logyandconnection policy.Thesearefeasibleforsmall-scaleVPNs,e.g.forsmal lvirtualclusters.ForVPNs scalingtolargernumberofnodes(100sto1000s),itisclear lyarequirementtoreduce thenumberoflinksinordertoreducetrafcatthenoticati on/discoveryandreection services.Oneapproachthatscaleswellandhasbeenusedinp reviousworkistouse astructuredP2Proutingoverlaywithon-demandshortcutcon nections[ 64 ].Thechoice ofascalableoverlayapproachcanbeencodedinthelogicemb eddedinthecontroller. Futureworkwillconsiderdifferenttopologyoptions(e.g. differentstructuredP2P approaches,aswellassocialandrandomgraphs)anddiffere ntpoliciesforon-demand linkestablishment/tear-down. 88

PAGE 89

CHAPTER4 ENABLINGUSER-DEFINEDDOMAINNAMES Inthepreviouschapters,thisdissertationadvocatedfora nenvironmentwhere socialpeershaveprivateIPaccesstoeachother.Socialnetw orkingapplication developersarethusabletoleveragethatconnectivitytocr eatemoresecuresocial applications.However,amechanismtoefcientlydiscover theseprivateIPaddresses isstillnecessaryespeciallysincetheseIPaddressaredyn amic.Thischapterexplains asolutionthatsolvesthisproblemthroughtheuseofthedom ainnamingsystem (DNS).ByaddingaDNSservicetothearchitecture,developers andusersareableto usepredictablecanonicaldomainnamesinsteadofdynamicI Paddressestoinitiate connectionsbetweensocialpeers.Domainnamesprovideloc ationtransparencyand serveasmorestableendpointsthanprivateIPaddresses. ThischapterpresentsSocialDNS,adecentralized,namingse rviceforP2PVPNs (e.g.SocialVPN).P2PVPNsprovideusersIPaccesstoeachinadecent ralizedfashion; however,theredoesnotexistadecentralizedsolutionwhic hallowsendusersthe freedomtochoosefullyqualieddomainnamesfortheirserv ices.Decentralized solutionssuchasmulticastDNS(MDNS)[ 24 ]andWINS[ 25 ]existforprivatenetworks andLANenvironments;however,thesesolutionscannotbeapp liedtotheP2PVPN environmentunmodied.ThisneedisaddressedinSocialDNSb yprovidingan alternativecomparabletodecentralizedsolutionssuchas multicastDNSbutbetter suitedforP2PVPNs. WithSocialDNS,P2PVPNusersareabletoselectshort-namesamongt hemselves fortheirresourcesthroughsocialscopeuniquenessinstea doftheglobaluniqueness enforcedbythenormalDNSsystem.Nameconictscanarisein theSocialDNSsystem iftwopeersdecidetochoosethesamedomainnameforaresour ce.Insuchcases, SocialDNSuseasimplerank-basedmethodtoselectthemappin gwiththehighest popularityinthesocialcircle. 89

PAGE 90

Asocialgraphanalysisofthedesignisprovidedwithestima tesfortheexpected bandwidthcosts,andlatency.Theanalysisisbasedontheas sumptionthatP2PVPNs formasocialgraphwithsmallworldcharacteristicssincee achVPNlinkrepresentsa socialrelationship.AlthoughnotallP2PVPNspossessthisprope rty,thefocusisonly onP2PVPNsthatonlycreatedVPNlinksbasedonsocialrelationship s.Basedonthis assumption,theanalysisisbasedona100,000socialnetwor kinggraphfromOrkutto validatevariousdesignchoices. 4.1BackgroundandRelatedWorks ThemainmotivationforSocialDNSistoprovideend-userswit hthefreedomtoset theirowndomainnamesinP2PVPNenvironments.Domainnamesserv eanimportant roleintheuser-friendlinessoftheInternetandareusedin mostTCP/IPconnections. P2PVPNsmakeitpossibleforenduserstohostservicesontheirpe rsonalresources andprovidenetworklevelaccesstopeersofinterest.Forex ample,anend-user,Alice, canhostablogfromherlaptopthatonlyherP2PVPNfriendscanacc ess,orshare herdesktopthroughaVNCsessiontodoaPowerPointpresentat ion.Animportant requirementforhostingservicesisuser-friendlydomainn amestotheseservicesso thatAlice'scolleaguescanconnecttoherblogbytyping aliceblog.sdns orviewher presentationbytyping alicepc.sdns intheirremotedesktopclients.Domainnamesalso providelocationtransparencyindynamicIPenvironmentss uchasprivatenetworks,and P2PVPNs;thusend-usersarenotrequiredtore-discoverthedyna micIPaddresstoa serviceeverytimethereisachangeinthehost'sIPaddress. Inthepreviousexample, withoutadomainnamingservice,Alice'sfriendswouldhavet odiscoverAlice'sIP addresseverytimetheywanttoaccessherblogorviewherpre sentation.Hence,IP connectivityisnottheonlyrequirementforenablingusers thefreedomtohosttheirown content,adomainnamingsystemisalsonecessarysothatend userscanselectthe namesusedtorefertotheseservices. 90

PAGE 91

Figure4-1. Onleft:MulticastDNSinLANenvironment. All-to-allconnectivityamong nodesallowsmulticastDNStosuccessfullydetectduplicat enames,hence hostBchoosesdomainname leserver2.local becausehostC'smappingof leserver.local isdiscoveredinthroughaprobingphase. Inmiddle: MulticastDNSinP2PVPNenvironment. Lackofall-to-allconnectivity causeshostBtobeunawareofhostC'smappingof leserver.local andthus claimsthesamemapping.ThiscreatesaconictforhostAwho nowhas twopeerinhernetworkwiththedomainnameof leserver.local Onright: SocialDNSinP2PVPNenvironment. SocialDNSusesatwo-hopbroadcast tosearchforduplicatenamesinthesocialcircle.Withthetw o-hop broadcast,hostBdiscovershostC'smappingfor leserver.local and chooses leserver2.local instead.IfhostBstilldecidestopickthesame domainnameashostC,thentheconictresolutionmechanism picksthe mostpopularnameinthesocialcircle. Decentralizednamingservicesareextremelyusefulandcom moninprivate networks(e.g.LANs)becausetheyprovideazero-congurati onsolutiontomapping user-friendlynamestoresources.Forexample,inatypical homenetwork,adecentralized namingservicemakesitpossibletoaccessaleonaWindowsma chineusing thefollowingurl smb:\\mom-pc\SharedDocs\familypic.jpg .Thetwocommonly availabledecentralizednamingsolutionsforprivatenetw orksaretheWindowsInternet NameService(WINS)[ 25 ]byMicrosoftandApple'smulticastDNS[ 24 ]systemcalled Bonjour.Oneapproachwouldbetorunoneofthesenamingsolut ionsontheP2PVPN unmodied.However,asshowninFigure 4-1 ,theseapproachesweredesignedwith theassumptionofall-to-allconnectivityamongstallnode withinthesamenetwork throughacommonnetworkingbackbone(e.g.routersandswit ches).Thelackof 91

PAGE 92

all-to-allconnectivityintheP2PVPNsmakesitimpossibleforWI NSandBonjourto properlydetectnamecollisionsintheirprobingphase.Soci alDNSaimstoaddressthese limitationsfortheP2PVPNenvironment. Therehavebeenvariouspreviousworksaimedatimprovingth eresourcenaming experience.OneoftherstisbyCoxet.al.[ 75 ]whodiscussedtheimplementationof aDNSsystemontopoftheChordDHT.Althoughsuchanapproachw asfeasible,the latenciesofaDHT-basedDNSweremuchhigherthanconventio nalDNS.SocialDNS isnotdependentonastructuredDHTandisdeployedontopofa nunstructuredsocial peer-to-peernetworkthroughtheuseofP2PVPNs. Walshet.al.[ 76 ]suggestedusingsemanticfreereferences(SFR)asareplace ment forDNS-basedURLsontheweb.Theyalsosuggestedusingastru cturedDHTtostore self-certifyingo-recordscontainingpointerstoresourc es.Theirfocuswasondecoupling themnemonicnamesfromtheactualreferenceswhichwere160 -bithashtags,anda wholeseparatemechanism,maybesocial,tomapnamestothec omplextags.TheSFR designthereforesuggestedatotalredesignofreferencing ontheInternet.CoDNS[ 77 ] isasystemwhichautomaticallyforwardspendingDNSreques tstoanotherlocalDNS servertoaremoteadministrativedomain.Therationaleist hatmostDNSfailuresare associatedwithpoorlyconguredlocalDNSserver,bysendi nglongpendingrequests todifferentlocalDNSserverinanotherdomain,itprovides someredundancytolocal DNSfailures.TheSocialDNSsystemreusesthecurrentDNSpro tocolwithoutrequiring anyre-architectingandsimplysupplementscurrentDNSsys tems.SocialDNS.net[ 78 ]is aprojectsimilartodynamicDNSwhichallowsuserstomanage theirowndomains throughtheuseofabrowser-pluginthatcanredirecturlspr exedwithgo://toa servicethattranslatetoaproperHTTPurl.Thisapproachis basedonaclient-server architecturewhileSocialDNSusesapeer-to-peerdesign. Allman[ 79 ]introducedtheconceptofpersonalnamespaces( pnames )toprovide easierreferencestotheiremail,blogs,links,andsoon.Eve ryuserisgivenanNID 92

PAGE 93

whichisacryptographichashofthepublickey.TheseNIDsar esharedamong friendsthroughaone-timeexchangeandareusedtoretrieve themappingsofa user'snamespacefromaDHT.The pnames systemsharemanysimilaritieswith SocialDNS,butitisproposedassecondlevelofindirectiont onameresolutionand theresolutionarenotrestrictedtoDNSrecords.Forexampl e, alice:email would resolveto alice@mailserver.com ,asecondresolutionwouldthenberequiredtoresolve mailserver.com .SinceNIDsarealwaysunique,andthelocaluserdenesthema pping ofnamestoNIDs,nameconictsarenotanissue.SocialDNShas todealwithname conictsandusesasocialconictresolutiontohelprankva riousnames. 4.2Design ThemaindesigngoalsofSocialDNSareshort-namesthroughso cialscope, decentralization,simpleusermanagement,andnameconic tresolutionthroughsocial popularity.TheSocialDNSdesignisalsobasedonthefollowi ngassumptions:1)a P2PVPNcreatesasocialgraphwherelinksrepresentrelationshi psbetweenends users,2)eachP2PVPNtunnelisanauthenticatedandencrypteden d-to-endlinksimilar toanIPSecconnection,and3)theprevioustwoassumptionsmak esitharderfora malicioususertomountaSybilattack.Thethirdassumptioni salsocorroboratedby previouswork[ 80 ]whichhaveshownthatSybilattackscanbemitigatedusingso cial linksinsteadofanonymouslinks.Theauthenticationanden cryptionoftheIPtunnels arediscussedinpreviouschapters.4.2.1EnablingShortDomainNames OneofSocialDNS'skeyrolesistoenableshortdomainnamestor esourcesin theP2PVPN,forexample,Alicecanset alicepc.sdns asthedomainnameforher personalcomputer.Therststepinenablingshortdomainna mesistochoosean unallocatedroot-leveldomainzonetoavoidconictswitht heglobalDNS.SocialDNS choosesanunassignedroot-leveldomainzone;thereforepr eventingphishingattacks basedonaddressesusedonthepublicInterneti.e.bycreati ngafakeDNSmappingfor 93

PAGE 94

www.bankofamerica.com .Asecondrequirementistolimitthescopeforuniqueness. TheglobalDNSsystemprovidesnamingforthewholeworld,po tentiallybillionsofhosts thusmakingshort-namesscare.IntheP2PVPNsetting,uniquenes sisonlyrequired withinapeer'ssocialcirclewhichisusuallycomposedofaf ewhundredoratmostafew thousandhosts.Thereducedscopelessenstheprobabilityo fcollisionforshort-names suchas alicepc.sdns 4.2.2DecentralizationandBroadcasting DecentralizationinSocialDNSisachievedbyrunningalocal DNSserviceoneach peer'smachine;hencethereisnoheadnodeorcentralpointo ffailure.SocialDNS leveragestheunstructuredpeer-to-peersocialgraphcrea tedbyP2PVPNsasthe messagingsubstrateconnectingtheselocalDNSservers.Th elocalDNSservice providesuserswithaninterfacewheretheycaneasilyaddan dremoveDNSmappings. TheSocialDNSnodesuseoneortwo-hopbroadcastmessagestoc ommunicate amongsteachotherthusallowinguserstoperformarbitrary searchesoneachother's SocialDNScaches.Usingbroadcastgreatlysimpliesthedes ignduetoitsstateless natureandtopologyindependence.AsuserscreatenewDNSmap pings,theyareable tofreelysharethesemappingswithsocialpeersovertheP2PVPNs .Therefore,atypical DNSquerycansearchthelocalDNScacheaswellastheDNScach esoffriendsin thesocialcircle.ThisisanalogoustothecommonGnutellaP2 Plesharingparadigm whereeachpeerrunsalocalleserver,andotherpeersareab letobroadcastqueries tosearchforles.IntheSocialDNScase,eachpeerrunsaDNSs erverinsteadofa leserver,broadcastqueriesaresenttosocialpeersinste adofrandompeers,andthe resultsareDNSmappingsinsteadofles.4.2.3SimpleUserInterfaceandManagement ManagingatypicalDNSserversuchasBINDisaseriousunderta king,atask suitedmainlyfornetworkadministrators[ 81 ].Thefocusistoprovidesimplemanagement totheuserwithminimalcongurationandanintuitiveWebin terfaceforcreating, 94

PAGE 95

Figure4-2.SocialDNSAJAXWebInterface.Inthisscreenshot,Bo bdoesawildcard searchforallDNSmappingswiththe *.alice.sdns searchstring.Byclicking onthe Searchyourfriends'cache button,thesearchissenttoallfriends throughtheP2PVPN.Astheresponsesarrivefromfriends,theWebinterfaceisupdatedalongwitharankingforeachmappingon theright.The rankinginformationisusedtosortthemappings,theenduse rmakesthe nalselectiononthemappingtoaddtothelocalcache.Althou ghIP addressesareshownintheinterface,theuserisnotinvolve dintheactual manipulation,whenIPaddressesarechanged,mappingsareu pdated automatically.Existinglocalcachemappingsareshownonth elefthand side. deleting,searching,andsharingDNSmappings.Theuserexp eriencefortheSocialDNS systeminvolvesjustafewsteps.First,byrunningtheSocial DNSserviceonthelocal machine,startupscriptsconguretheoperatingsystem'ss ettingsandpointtothe localserverasoneoftheDNSservers.ThelocalDNSserveron lyresolvesrequests underthe .sdns rootdomainzonetoavoidcommonDNSphishingattacksandtoa llow co-existencewiththeglobalDNS.Theuserthenusestheirwe bbrowsertoaccessthe SocialDNSinterface(seeFigure 5-3 ). CreatingUser-DenedMappings. Userscanaddnewmappingstotheirlocal SocialDNScacheinoneoftwoways.Therstmethodisfortheus ertomanuallycreate aSocialDNSmappingthroughtheWebinterface:forexample,Al iceusestheinputbox tomapthename alicepc.sdns toherlocalPC.Thenewlycreatedmappingwillonlybe acceptedifitfollowsthesecriteria:1)themappingendswi th .sdns ,and2)itpointstoa 95

PAGE 96

virtualIPaddressintheP2PVPNaddressrange.SocialDNSgivesth euserthefreedom topickanyDNSmappingunderthe .sdns rootzone. ImportingMappingsthroughSearch. ThesecondmethodisthroughaSocialDNS searchwhichallowsuserstoqueryeachother'sSocialDNScac hes.Thesearching processresemblesatypicalWebsearch,andtheresultsarep resentedtotheuser sortedbytherankingmethoddescribedbelow.Ausercanchoo setoimportamapping tohis/herSocialDNScachebysimplyclickingonthemapping. Figure 5-3 showsasearchfor *.alice.sdns andtheresultsofthatsearchandthe usercanchoosetoimportthesemappinglocally.Sincethisse archisdoneasatypical ood-basedbroadcastinanunstructuredP2Pnetwork,SocialD NSthereforesupports varioustypesofqueriessuchasexact,nearest,andregular expressionmatching.The searchisdonebybroadcastingtheDNSquerytoallfriendsan dperhapsfriendsof friendsdependingonusersettings.Usingbroadcastquerie swithgreaterhopcounts givesthelocaluseramoreaccurateviewofthepopularityof aDNSmappingatthecost ofgeneratingmoretrafcandhigherlatencies. FreedomtoRedeneDomains. SocialDNSalsogivesuserstheoptionof redeningthedomainnamethatpointtoafriend'sresourcei nhis/herlocalDNS cache.Thisissimilartocreatingabookmarktoawebpage,bu tinsteadofusingthe pagetitleprovidedbythewebsite,theusercancreatehis/h erownreferencetothat weblink.SocialDNSoperatesinasimilarfashionbecausethe usercanimportthe existingmappingdenedbyafriendorcreateanothermappin gathis/herdiscretion.For example,let'ssayBobchooses bobpc.sdns astheSocialDNSnameforhismachine, Alicecaneitherimportthatdomainmappingordeneherownma ppingsuchas bobbypc.sdns forBob'smachine.Consequently,SocialDNSallowsausertocr eatemap multipledomainnamestothesameIPaddress. Creatingadifferentmappingforapeer'sresourceonlymake sthatmapping availabletothelocalSocialDNScache;however,peershavet heoptionofimporting 96

PAGE 97

thatmappingintheirownSocialDNScachethroughthesearchi nterface.Extending thepreviousexample,assumingCarolhasfriendshipswithb othAliceandBob,through aSocialDNSsearch,CarolnoticedthatBobthefollowingmappi ng bobpc.sdns= 172.31.231.23 whileAlicehas bobby-pc.sdns=172.31.231.23 andbothmappingspoint tothesameIPaddress,Carolwillhavetheoptionofchoosing eitherBob'smapping, orAlice'smapping,orboth.Onceagain,DNSmappingsareanal ogoustobookmarks inwebpages,andSocialDNSmakesiteasytocreateanymapping sandshareitwith friends.Asamappingisreplicatedacrosspeers'SocialDNSca ches,itspopularityinthe socialcircleincreasesandthatcreatesthebasisforthera nksystemdescribedbelow. 4.2.4NameResolution SocialDNSperformstwotypesofnameresolution:user-veri edandautomatic. Providinganautomaticmodegivestheendusertheoptionofno thavingtomanually importeachmappingcreatedbysocialpeers,butsupporting auser-veriedmodeis crucialforsomesecureservices.Themodeofoperationisac ongurationtheuseris abletosetatstartuporruntime. User-VeriedNameResolution. Inuser-veriedmode,SocialDNSonlyresolves mappingsthathavebeenexplicitlycreatedorimportedbyth euserthroughtheweb interface.ThisisimportantbecausechangingaDNSmapping from IP1 to IP2 ,which canhappeninautomaticmodewithoutuserintervention,may causeinformation leakageduetowebbrowsercookies.Hence,usersshoulduset heSocialDNSin user-veriedresolutionmodeforinformationsensitivese rvices. Forauser-veriednameresolution,thelocalDNSserveruti lizesitsSocialDNS cacheonlytoresolveincomingDNSqueriesfromtheoperatin gsystem.Inotherwords, whenBobtypes www.alice.sdns inhisbrowser,thebrowseraskstheoperatingsystem toresolvetheDNSname,therequestisforwardedthelocalSoc ialDNSservice,the mappingislookedupinthelocalcache;iffound,theIPaddre ssisreturned,ifnotfound anNXDOMAINresponseissentbacktotheapplication.Inthismo de,thereareno 97

PAGE 98

nameconictsbecausetheyareresolvedbytheuserthrought hewebinterface.For example,ifAlicetriestocreateorimportamappingsuchas www.alice.sdns which alreadyexistsinherlocalSocialDNScache,shewillbeinfor medofthecollisionand requiredtochooseadifferentdomainnamefortheresource. Also,inthewebinterface, iftherecanbemultiplesearchresultswiththesameranking ;inthiscase,theuser makesaselectiononthemappingtheywouldliketoimportthu sresolvingthename conict. AutomaticNameResolution. Inautomaticmode,SocialDNSautomatically searchesthesocialcircleformappingsthatarenotpresent inthelocalcacheandpicks thehighestrankedmapping.Thismodeofoperationisnotass ecureastheprevious modebecauseitcanleadtofrequentchangesinIPaddresstha tistransparenttothe userbecausetheresolutionisbasedonthemostpopularmapp ingatthetimeofthe query.Toperformthisresolution,theSocialDNSsystemsend sasearchtoallfriends, waitsforapredenedtimeintervaltogatherresults,andth ehighestrankedmappingis chosen.Inthecaseofatie,oneoftheSocialDNSmappingisran domlyselected. RankingDomainNames. SocialDNSdoesnotenforceuniquenessduringthe creationoftheDNSmappingsduetotheuseofsocialcontextt ohelpwiththeDNS resolution;therefore, www.alice.sdns canmaptooneIPaddressinonesocialcircle,and toatotallydifferentIPaddressinanothersocialcircle.I nthecasewherebothmappings existinthesamesocialcontext,arankingalgorithmisused toprovidepreferencetoone mappingoveranother.So www.alice.sdns willmaptotheIPaddresswiththehighest ranking,andthelocaluserwillhavetospecifyanalternate namefortheconicting mapping. Thecurrentrankingalgorithmissimple;whenaDNSqueryiss enttoallfriends, thefriendssearchtheirDNScacheformatchingresultsands endtheresponsesback totherequester.Mappingsarerankedbasedonanaggregatio noftheresponses.For instance,ifvefriendsreturnresponsessaying www.alice.sdns mapsto172.32.122.31, 98

PAGE 99

whiletwofriendssaysthatitmapsto172.15.223.112,thent herstmappingwillget arankingofve,andthesecondarankingoftwo.Onceranked, themappingsare presentedtothelocaluserforselection(seeFigure 5-3 ).Withthissimplescheme,the frameworkusesthepresenceofaSocialDNSmappinginapeer's localcacheasavote forthatmapping,themorepeersthathaveamappingintheirc ache,themorevotes thatmappinggets.Thisissimilartotherankingsystemused byDelicious.comwherea bookmark'spopularityincreasesasmorepeopleaddthatboo kmarktotheiraccounts. 4.2.5ProtectionagainstDNSattacks Attackssuchasphishing,sessionhijacking,cachepoisonin ghaveplaguedDNS anditrequirescarefuladministrationandrobustsoftware toprotectagainsttheDNS securityaws.Hence,itisimportantfortheSocialDNSdesig ntoavoidthesesame awscurrentlyplaguingthecurrentDNSsystem.SocialDNS,h owever,benetsfrom inherentnetworklevelsecurityproviderbyP2PVPNs.InaP2PVPNeach tunnel isencryptedandauthenticatedeitherthroughtheuseofIPSec ,oraTCP/IPlevel encryptionsuchasTLSorDTLS.Therefore,everynetworkpac ketcanbeboundtoa peer'sidentitymakingitverydifculttospoofanIPpacket oraDNSresponse.This securityprimitivehencemakesattackssuchasphishingand cachepoisoningfutile becausetheculpritcanbedetectedandbannedfortheP2PVPN. 4.3Analysis Thefocusoftheanalysisistheexplorationofthefollowing aspectsofthedesign: numberofpeersinthesocialscope,bandwidthcost,andlate ncy.Duetotheassumption thattheP2PVPNcreateasocialgraph,theanalysisisbasedona10 0,000nodesocial graphdatasetcapturedfromOrkut.Thedatasetwasprovided bytheauthorsof[ 35 ]. NetworkX[ 82 ],aPythonpackageforcomplexnetworkanalysis,wasusedtos tudythe differentaspectsofthedesignthroughthesocialgraph.Th esocialgraphcontainsthe followingsmall-worldcharacteristics:1)anaverageclus teringcoefcientof0.27,2)and apowerlawdegreedistribution. 99

PAGE 100

Figure4-3.DistributionofNumberofFriendsin2-hopRadiu sofSocialCircle.As showninthisdistribution,auserhasabout 2000 friendsinatwo-hopradius onaverage. 4.3.1ReducedConictsintheSocialScope AmajorstrengthofSocialDNSistheincreasedavailabilityo fshortnamesthrough socialscoping,meaningbecausethereisnoguaranteeofglo baluniquenessasinthe caseofregularDNS,uniquenessisonlyguaranteedwithinth esocialcircle.Sincethe recommendedsocialscopeforuniquenessistwohops,thisan alysisexaminesthe distributionofthenumberoffriendsinatwo-hopradiustog etanideaforthenumber ofpeersthatmaybecompetingforthesamedomainnames.Theo bservationisthat, inatwo-hopradiusofthesocialcircle,theaveragenumbero ffriendsare1,832and amedianof1,150.Therefore,Alicewouldonlyhavetocompete withlessthan2,000 peersonaveragetoclaimthename alice.sdns insteadofthebillionofusersonthe Internettoguaranteeuniquenessinatwo-hopradiusofthes ocialcircle.Thereduced 100

PAGE 101

Figure4-4.CDFofOne,Two,andThreehopQueries.Asthegraph shows,increasing thehopcountforSocialDNSQueriesincreasesthebandwidthc onsumption bytwoordersofmagnitude. numberofpeersmakesndingashortSocialDNSdomainnamemor eprobable. Figure 4-3 showstheactualdistributionofthenumberofhostwithinat wo-hopsocial circle.4.3.2ExpectedBandwidthCost SocialDNSusesbroadcastingastheprimarymethodofcommuni cation;therefore, understandingtheexpectedbandwidthcostshelpsthepredi ctionofthetrafcgenerated bySocialDNSqueries.Figure 4-4 showsthecumulativedistributionfunction(CDF) oftheexpectednumberpacketsgeneratedwhenauserdoesaon e,two,orthree hopsearchforaSocialDNSmapping.Themaximumpacketsizeal lowedintheDNS RFCs[ 83 ]is512bytes.Hence,aone,two,andthreehopSocialDNSsearc hgenerates about42Kbytes,4.5Mbytes,and161Mbytesoftrafconaverag e,withamediansof 101

PAGE 102

25Kbytes,1.7Mbytes,and90Mbytesrespectively.Therefore ,auserisonlyallowed toperformaoneortwohopbroadcastinSocialDNStoavoidcons umingtomuch bandwidthperDNSqueries.Futureworkwilllookatefcient waysofcachingtheDNS mappingstominimizebandwidthconsumption.4.3.3AnticipatedLatency Analyzingthelatencyhelpsthedeterminationofthepropert imeouttosetper SocialDNSquerytogatheradequateresponsesfromsocialpee rs.Therststepin thelatencyanalysisistoexaminetherelationshipbetween friendshipsandgeography. AccordingtoLiben-Nowelletal.[ 84 ],friendshipsinasocialnetworkarebasedona geographicpreferencegivenbytheformula P(d)= 1 d 1.2 +5.0 10 6 ,where P(d) is theprobabilityoffriendshipbetweentwopeersthatareloc atedatdistance d kilometers away.BasedontheworksofBassettetal.[ 85 ],onecanderivelatencyfromdistanceby approximatinglatencyas 4 9 thespeedoflight.AnotherworkbyDischingeretal.[ 86 ]also hasshownthatinresidentialISPs,apacketmaytakeupto2.5mi llisecondsfromthe hostmachinetotheISP'srouterforatotalround-triptimeof5 milliseconds.Usingthese previousworks,thelatencyinmillisecondsisapproximate das: latency= d 10 3 4 9 c +5 10 3 (4–1) where c isthespeedoflightat299,792,458m/s.Hence,SocialDNSuse stheprobability function P(d) toassigndistancesbetweenfriendsandtheequation(1)toa pproximate thelatenciesoffriendshiplinksinthesocialgraphcreate dbytheP2PVPN. Basedontheaforementionedlatencydistribution,themeasu redpercentageof receivedresponsesarebasedontimeoutsof100ms,200ms,an d300msforone-hop queries,and200ms,400ms,and600msfortwo-hopqueries.Fo ratimeoutof100ms foraone-hopbroadcast,thereceivedresponsesarefrom79% offriendsonaverage, 89%for200ms,and99%for300ms.Inthetwo-hopbroadcastsce nariowithtimeout of200ms,400ms,and600msandreceivedresponsesfrom61%,7 8%,and98%of 102

PAGE 103

ATimeoutLatenciesforOne-hopBroadcasts BTimeoutLatenciesforTwo-hopBroadcasts Figure4-5.ImpactofQueryTimeouts.A)TimeoutLatenciesfo rOne-hopBroadcasts. At100msmedianisatabout75%andwehearbackfromallfriends 10%of thetime;themedianat200msisabout90%andwehit100%resul tsabout 16%ofthetime;at300ms,ourmedianisat100%,andwegetallr esults 75%ofthetime.B)TimeoutLatenciesforTwo-hopBroadcast.At2 00ms, weobtainamedianof65%,butweobtain100%lessthan1%ofthe time;at weachieveabettermedianof80%,withbarelyanyimprovemen tatthe 100%mark;at300ms,wegetamuchbettermedianof99%,andweh it 100%about3%ofthetime. friendsonaverage,respectively.Figure 4-5 plotsCDFshowingthedistributionofthe percentageofrespondingfriendswiththevarioustimeouts foroneandtwohopqueries. 4.3.4ExperimentalLatency ThereiscurrentlyaprototypeoftheSocialDNSsystemimplem entedaspartof theproposedP2Parchitecture.SocialVPNisaP2PVPNwhichusessocia lnetworking backendssuchasFacebook,orGoogleChattoautomaticallyc reateP2PVPNlinkswith friends.ThewholesoftwaresuiteiswritteninC#andisavai lableon http://socialvpn. wordpress.com .TheWeb-basedinterfaceisimplementedasasearchenginelike interfacewritteninAJAX(seeFigure 5-3 ). Thefollowingexperimentsassessthefunctionalityandper formanceofthe prototype.TheexperimentsinvolvedbothPlanetLab[ 47 ]andAmazonElasticCloud[ 87 ] (EC2)infrastructures.PlanetLab,aglobalresearchtestbed withnodeslocatedaround theworld,wasusedtodeploy600P2Pnodeswhichformedtheboo tstrapP2Poverlay. 103

PAGE 104

Figure4-6.CDFofUserRequestTimes.Eachofthefourusersen t3000DNSrequests (1000toeachfriend).ThefournodeswerelocatedinVirginia ,California, Florida,andIreland.Wemeasuredtheround-triplatencyof eachDNS query.Ineachcase,over90%ofrequeststakeslessthanones econd. TheP2PnodesonPlanetLabdidnotincludetheSocialDNSsoftwar estack.SocialDNS nodesweredeployedonAmazonEC2becausethesystemrequiresa ddingthelocal SocialDNSservertotheoperatingsystem'sDNSconguration s.ModifyingtheDNS settingsisnotpossibleonPlanetLabnodes,but,thisisposs ibleonAmazonEC2 becauseofthenecessaryrootaccessneededonthevirtualma chine.OntheAmazon EC2nodes,thesystemaddedDNSmappingstothelocalcaches,s earchedand importedDNSmappingsfromsocialpeers,andresolvedDNSma ppingscreatedbythe localuserandfriends.Hence,thedesignprovedfeasiblean dallcomponentsintegrated successfully. ItisalsoimportanttoexplorethelatenciesoftheDNSqueri esthroughthe peer-to-peeroverlayrunningonPlanetLabwithnodeslocate daroundtheglobe. 104

PAGE 105

Figure4-7.TimeTakentoBroadcasttoVariousSizeNetworks.1 00broadcastqueries weresenttoeachnetworksize.95%ofthequeriestooklessth an16 secondsforanetworksizeof600nodes. ThreeSocialDNSnodesweredeployedonthevariousregionsof theAmazonEC2 infrastructurelocatedinVirgina,California,andIreland ;afourthnodewaslocatedin FloridafromaresidentialISP.Figure 4-6 showsthecumulativedistributionfunction (CDF)of3000DNSqueriesconductedateachofthefournodes. Theresultsshow thatmorethan90%oftheDNSrequeststakelessthanonesecon d,irrespectiveofthe geographiclocations. ItisalsodesirabletomeasurethetimetakentobroadcastDN Squeriessimultaneously toallfriendsthroughtheoverlay.Assumingaprivatepeer-t o-peeroverlay[ 88 ]consisting onlyofsocialpeers,thebroadcastingtimewasmeasuredfor queriestoallpeers withnetworksizesof200,400,and600nodes.UsingonlythePl anetLabnodes, 105

PAGE 106

100broadcastqueriesweresenttoeachofthedifferentsize dnetworks.Figure 4-7 showsthe25th,50th,75th,and95thpercentileoftimetaken tobroadcasttothewhole network.The95thpercentileare8,12,and16secondsfornet worksizesof200,400, and600nodes,respectively. 4.4Summary Thischapterpresentsadecentralizeddomainnamingsoluti onsuitedforP2PVPNs. ThisworkmakesthecasethatprovidingIPaccessisnotenoug htoenablesimple implementationanddeploymentofsocialnetworkingapplic ations;theabilityto assigncreateDNSmappingtotheirmachinesandfriendsisal souseful.SocialDNS providesthatfreedomandreusesexistingconceptsfromdec entralizednamingsolutions fromlocalareanetworks.Italsoimprovesuponthecurrentl imitationsofLAN-based decentralizednamingsystemsthatmakesthemunsuitedfora P2PVPNenvironment. TheSocialDNSdesignmakesittrivialtoassignshortdomainn amestoresources inaP2PVPNthroughsocialscoping;meaning,auseronlyhastocom petewithless than2,000otherusersonaverageforadomainname.Forsimpl emanagement,this designprovidesaminimalconguration,easy-to-useAJAXWeb interfacewherea usercansearchhis/herfriends'SocialDNScacheandimportm appingsofinterest.For designsimplicity,broadcastingisusedasthemainmethodo fcommunicationamong SocialDNSnodesintheP2PVPN.Incaseofnamecollisionsduetothe lackofacentral authority,apopularity-basedrankingmechanismisemploy edtopickthemappingwith thehighestpresenceintheSocialDNScachesofthesocialcir cle.Byusingthesocial graphproperties,theanalysispredictedthebandwidthcos tandresponsivenessby assumingaP2PVPNwillformasocialgraph.Theresultsvalidated theSocialDNS designchoicesbecausetheexpectedperformanceispractic al. 106

PAGE 107

CHAPTER5 CASESTUDY:DESIGNINGADISTRIBUTEDMICROBLOGGINGSERVICE Adistributedmicrobloggingservicewasdesignedtomoreco ncretelyexaminethe implicationsandlimitationsoftheproposedarchitecture .Sincemicrobloggingservices areapopulartypeofsocialnetworkingservices,itseemeda goodcandidateapplication toprototypeintheSocialVPNenvironment.Theproposedarchit ectureisessentially apeer-to-peervirtualprivatenetwork;theremainderofth ischapterusestheterm P2PVPNtorefertosystemssimilartothearchitecture.Thischap terdetailsthedesign ofthisdistributedmicrobloggingservicealongwithanaly sisofvariousaspectsofits performance. ThisdissertationpresentsLitter,adecentralizedmicrob loggingservicethat leveragescurrentlyavailablepeer-to-peervirtualpriva tenetworking(P2PVPN) technologies.P2PVPNsprovideprivacyandlow-latencycommuni cationinthe commoncaseofP2Pmessagingamongsocialpeers.Withprivatec onnections andmulticastmessagedeliveryalreadyenabledbyP2PVPNs,this workfocuseson someoftheotherkeyhurdlesofbuildingaprivateanddecent ralizedmicroblogging service,suchascontrollingthescopeofamessageandensur ingdataavailability. TheLitterdesignutilizesbothIPmulticastinganddatarep licationthroughhighdegree nodestoensurethatpeersareabletopublishmessageswithv aryingscopes(i.e. friends,friendsoffriends,and/orthepublic).Theanalys isstudiestheimplicationsof theLitterdatadisseminationmechanismforadecentralize dmicrobloggingservice throughasimulationusinga3-millionusersocialgraphfro mOrkut.Theprototype implementationdemonstratesthefeasibilityofthedesign choicesalongwithan experimentaldeploymentonFutureGridtotestitsperforma nceonthewidearea. Overall,theexperimentalresultsshowthatpeerscaneffec tivelyfolloweachother's updateswithacceptableoverhead. 107

PAGE 108

Theprimarygoalofthisdesignistoenablefast,privateupd atesamongfriends, ratherthantheTwittermodelwhichfocusesmoreonpostingm essagespubliclyon theWeb.ByutilizingSocialVPN[ 67 ],Litterbuildsuponalayerwhereusershave privateIPconnectivitytoeachotheralongwithIPmulticas tsupportthusenabling trustedsocialcommunicationontheInternet(eventhrough NATsandrewalls). P2PVPNsnaturallymaptosocialgraphsandthereforeserveasast rongfoundation forbuildingdecentralizedsocialservicesbecausetheysp ecializeinlowlatency,private communicationbycreatingdirect,encryptedpathsamongfr iends. Thischapterfocusesonunderstandingthecharacteristics ofthesocialoverlay formedbyP2PVPNs–forexample,theabilitytoreachfriendswith aone-hopmulticast IPpacket,andtheimpactofthehighclusteringcoefciento nreplicationanddata availability.Withthisunderlyingsocialoverlay,Litterl etstheusercontrolthepropagation ofapostinthesocialoverlaythroughtheuseofIPmulticast packets.Litteralso leveragesthepropertiesofthesocialgraphinitsdatarepl icationheuristicsinorder toefcientlydisseminatepublicpoststhroughoutthesoci aloverlay.Bydesigningwith privacyasastartingpoint,theproposedmicrobloggingser viceisasystemthatmakes itmoredifculttocensor,disrupt,andinltratewhichult imatelycreatesamorerobust socialnetworkingapplication. Themaincontributionsofthischapterare: Anoveldecentralizedmicrobloggingservicewithprivacya stheprimaryfocusand whichalsousesIPmulticasting,andrandomwalkstopropaga teupdatesthrough asocialoverlayconstructedbyaP2PVPN. Asimulation-basedanalysiswhichpredictsbandwidthcost sandcomparesdata disseminationstrategiesusinga3-millionnodesocialgra phfromarealsocial networkingwebsite. AprototypeimplementationoftheLittermicrobloggingser vicewhichvalidatesits functionalityanddesignchoices. 108

PAGE 109

5.1Motivation Inrecentyears,socialnetworkingservicessuchasTwitter andFacebookhave playedamajorroleasavitalcommunicationtoolaroundthew orld.Forexample,the ArabSpringisattimesdubbedthe“TwitterRevolution”becaus eofthemicroblogging service'skeyroleinconnectingprotesters.Anotherinstan ceisduringthecatastrophic earthquakeinHaiti,whereTwitterupdatespostedthroughm obiledevicesbecamea primarysourceofreal-timeinformation.Microbloggingse rvicesprovideuserswithan intuitivemethodforcommunicatingideas,discontent,and arenowaninvaluablemeans oforganizingrevolts.Asaresult,acommonrststepofgover nmentsseekingtorestore orderduringarevolutionistoblockaccesstotheseInterne t-basedsocialservices.In someextremecases,wholenationshavebeendisconnectedfr omtheglobalInternetin ordertodenythedissidentsaccesstoanyservicethatmayhe lpamplifytheawareness oftheirgrassrootrevolution[ 5 ].Onelessonthatbecameevidenttotheresearch communityistheeasewithwhichauthoritariangovernments caninstantlyblockall IPtrafcowinginandoutofacountry.Forexample,intheca seofEgypt,allofthe country'sBGPprexesdisappearedfromglobalroutersmakin gitimpossibleforthe outsideworldtorouteanyIPpacketstoEgypt[ 5 ].Thiswaseasilyaccomplishedonce thegovernmenttookcontroloftheBGProutersinEgyptandstop pedsendingrouting updatestotherestofBGProutersintheworld. AlthoughitisfairlyeasytodisconnectanationfromtheInte rnetbydisablinga fewkeyconnectionstotheoutsideworld,inmostcases,itre quiresmoreeffortto shutdownacountry'sentireinternalInternetapparatus.T hiswasthecaseinEgypt, afterdisconnectionfromtheInternet;servicesrunningin ternallywherestillaccessible bythepeople.Hence,thisoccurrencemotivatedtheneedfor amicrobloggingservice, thatwouldcontinuetofunctiondespiteadisconnectionfro mtheglobalInternet.A decentralizedapproachalsoprovidesanopportunitytoadd resstheissueofprivacyin 109

PAGE 110

microbloggingespeciallyafterthemanypublicinstanceso fTwitterhandingoverprivate userdatatoauthorities. Thegoalistocreateaservicewhichmakesitpossibleforend -userstosend messagestotheirfollowersdirectlyinapeer-to-peermann erwithouthavingtodepend onacentralizedservice.Hence,disablingsuchaservicewo uldrequiregovernmentsto shutdowntheirinternalInternetinfrastructure,whichma ybeamorecostlyandcomplex endeavor.ByleveragingexistingP2PVPNtechnologies,Litteris basedonaservicethat allowscommunicationamongpeersthroughdirect,encrypte dIPtunnelswithoutthe needofamiddleman.Withprivatemessagingtotrustedpeersa stheprimaryfeature ofaP2PVPN,thiseliminatesmanyoftheshortcomingsofacentral izedapproachby makingithardertoaggregateallmessagesinacentralizedd atabase.Moreover,byonly disseminatingmessagesthroughtrustedfriends,itmakesi tharderforgovernmentsto monitoruseractivityandlimittheirabilitytofreelycomm unicate. 5.2RelatedWorks Inthissection,thefocusisonrecentapproachesfordecent ralizedmicroblogging servicesalongwithsomerecentalternativesforbuildingd ecentralizedsocialnetworks andpublish-subscribesystemsinunstructuredpeer-to-pe ernetworks. 5.2.1DecentralizedMicroblogging FeedTree[ 89 ],andMegaphone[ 90 ]arepeer-to-peermicronews/RSSservices whicharebuiltontopofScribe[ 91 ],wherefollowersjoinamulticasttreethroughthe useofthePastry[ 18 ]structuredoverlay.Bysendingupdatestotherootnodeofth e tree,themessagesarepropagatedthroughallmembersofthe tree.Theseareelegant approachesbecausetheyhaveverylittleoverheadbesideso verlaymaintenance,and guaranteethatallfollowersreceiveupdateswithinalogar ithmicnumberofhopswith respecttothenumberofpeersinthesystem.Themajordiffer encebetweenthese approachesisthatFeedTreeusestheRSSfeedmodeltodissemi natemessageswhile Megaphoneusesthemicrobloggingmodelofdeliveringshort 160-charactermessages. 110

PAGE 111

AlsoMegaphoneusesencryptiontoguaranteethedeliveryoft rustedmessagesbut hastodealwithhandlingkeydistributionandsessionkeys. FortheLitterdesign,this workexploresthefeasibilityofdesigningamicroblogging servicewithoutdependingon astructuredDHT. FETHR[ 92 ]isamorerecentapproachaimedatdeliveringafullydecent ralized HTTP-basedmicrobloggingservice.Peerssubscribetoeacho therbyexchanging canonicalURLsandusetheHTTPGETandPOSTmethodstopullorpus hupdates toeachother.Thisapproachalsorecommendsusinggossip-b aseddisseminationfor userswithahighnumberoffollowers.Theuseoftheubiquito usHTTPprotocolandthe simplicityofthegossipprotocolmakethisaverypractical solution;howeverthereisone keyweakness:theauthorsdonotmentionifuserswillhaveto runtheHTTPservice locallyoriftheywilldependonaserviceprovider.Ifusers havetodependonaservice provider,thenthisapproachbecomesmuchmoresimilartoaf ederatedsystemsuchas emailorXMPP.Ifusersrunthisservicelocally,thenissuessu chasconnectivitythrough NATsandrewallsbecomemajorimpedimentswhicharenotadd ressedinthedesign. TheuseofaP2PVPNwithNATtraversalallowsLittertobypasssuch hindrances. InCuckoo[ 26 ],peersuseaDHTtodiscovereachother'sendpointsandsend follow requestsdirectlytoeachother.Publishersarethenabletos endupdatesdirectlytoa subsetoffollowers,dependingonbandwidthavailability, whiletheremainingfollowers useagossipprotocoltopropagateupdatesamongthemselves .Tohandlechurn, theCuckooapproachreliesonacentralizedbackendwhichst oresallupdatesand followrequestsfromallusersincaseapublisherisnotonli ne.TheuseofaDHTanda centralizedbackendseparatestheLitterdesignfromtheCu ckooapproach. 5.2.2DecentralizedOSNs Adecentralizedmicrobloggingservicecanalsobeconsider edtobeadecentralized onlinesocialnetwork(OSN).Themaindifferenceisthatrath erthanpublishingshort 140-charactermessages,ausercanalsopublishpictures,v ideos,andotherobjects 111

PAGE 112

ofinterest.PeerSoN[ 11 ]isafullydecentralizedOSN.SimilartoCuckoo,peersusea DHTasalookupservicetolocateeachother'sendpoints,the nexchangeencrypted informationdirectlywitheachother.Safebook[ 10 ]isanotherDHT-dependentOSN whichfocusesonanonymitybyaddinganadditionallayerofi ndirectiontomessage requestsbyroutingthemthroughmultiplelayersoffriends andfriendsoffriends.Neither oftheseapproachesmentionsareplicationmechanismtoens urecontentavailability whenusersareofine.Vis-a-vis[ 93 ]isyetanotherdecentralizedOSNproposalwhich reliesonDHT-basedmulticastformessagepropagation.Int hissystem,auserruns avirtualindividualserver(Vis)whichstoresandservesall ofthecontentonbehalfof theuser.Toensurecontentavailability,theusercanrunaVi sonacloudprovidersuch asAmazonEC2.LifeSocial[ 94 ]isatotallyDHT-dependentOSN;everythingauser publishesisstoredintheDHTwhichensuresdataavailabili tyeveninthecaseofchurn. 5.2.3Publish-subscribeSystems StructuredDHTsarewell-knownforsupportingpublish-subs cribesystems(e.g. Scribe[ 91 ]),buttherearealsounstructuredpublish-subscribesyst emswhichcanbe appliedonasocialoverlay.InQuasar[ 95 ],groupmembersadvertisetheirmemberships toallnodeswithinaK-radiuswhichareaggregatedthroughat tenuatedBloomlters. Publishingmessagestogroupmembersinvolvesdoingak-para llelrandom-walkwith thegroupidinthemessage.Asthemessagetravelsthroughthe network,eachnode checksitsBloom-lterforgroupmembersinitsvicinity;ifa memberisfound,the messageisroutedtowardsthatnode,ifnot,themessagecont inuestothenextrandom node.Vitis[ 12 ]isahybridsystemwhichusesbothaDHTandclustersforprop agating updatesbybroadcastingeachother'smessages.Litterdiff ersbyfocusingonprivacy andperformanceandbypushingupdatesdirectlytofriendso verencryptedlinkssince thatisbelievedtobethecommoncase. 112

PAGE 113

5.3Background Theproposedmicrobloggingservicedependsontwobasicnet workingservices:IP multicastingforpushingpoststofriends(andfriendsoffr iends),andUDPunicastingfor datareplicationthroughoutthesocialoverlay.Therefore itisimportanttoprovidesome backgroundontheIPnetworkingcapabilitiesofP2PVPNsandexpl aintheassumption thatP2PVPNsformsocialoverlayswithcharacteristicssimilar tosocialgraphs.Finally, thischapterarguesthatamicrobloggingserviceshouldbeb uiltaroundtheconceptof privatemessaging,whichistheprimarymotivationforstar tingtheLitterdesignwitha P2PVPN.5.3.1P2PVPNsandIPMulticasting AlthoughitiscommonknowledgethattheInternetdoesnotsup portIPmulticasting andUDPtrafcisrewalledinmanycases,therestillexistm ethodsthatcurrently allowpeerstohavedirect,unrestrictedIPconnectivityto oneanother,includingIP multicastingsupport.Virtualprivatenetworkingisthetyp icalsolutiontoproviding unblockedIPconnectionstonodesthataregeographicallyd ispersed.Inthisscenario, virtualIPtrafcistunneledoveraTCPorUDPconnectiontoa VPNgatewaywhich routesthetrafcaccordingly.Hence,peerscangetunrestr ictedIPconnectivityto eachotherbyconnectingtoacommonVPNgateway(e.g.OpenVPN).T hegateway canalsoprovideIPmulticastingsupportbytunnelingmulti castIPpacketstoallpeers connectedtothesamegateway.However,thisisahighlycent ralizedapproachwhichis notscalableandsuffersfromasinglepointoffailure. Apeer-to-peervirtualprivatenetwork(P2PVPN),suchas[ 20 67 ],isapractical decentralizedalternativetocentralizedVPNs.InaP2PVPN,peers leverageP2P technologiestotunnelIPtrafcdirectlytoeachotherinst eadofrelyingonacentralized VPNgateway.VirtualizingaP2PconnectionintoavirtualIPlink isapowerfulconcept becauseapplicationscanbedevelopedindependently,with outanyknowledgeofthe P2Pvirtualnetworkinginfrastructure.Thisisamajordepar turefromcommonP2P 113

PAGE 114

applicationdevelopmentwheretheapplicationisintimate lycoupledwithanapplication layerP2Plibrary.Suchastrongcouplinglimitstheportabili tyandmodularityofthe system. P2PVPNsalsoprovideIPmulticastsupportbytunnelingthemulti castpackets toeachfriendoveranencryptedP2Pconnection.Therehasbee nmuchresearch inapplication-level,P2Pmulticast[ 96 97 ],eachwiththeirownsetofassumptions andrequirements,thusnecessitatingdeveloperstodesign theirsoftwarearound theirtechnicalspecications.InaP2PVPNcase,applicationsj oinamulticastgroup throughthewell-adoptedBerkeleysocketsAPI,andtheyareabl etosenddatatogroup membersbysimplysendingaUDPdatagramtoamulticastIPadd ress.IPmulticast supportthroughP2PVPNsovertheInternetplaysakeyroleintheL itterdesignchoices becauseitdoesnotrequirereinventingthewheelbyhavingt odesignyetanother multicastingstrategyforaP2Papplication.5.3.2TheP2PVPNSocialOverlay ArecurringthemeofthischapteristheassumptionthatP2PVPNsf ormsocial overlayswithsmall-worldcharacteristics.Thisisprimar ilythecasebecauseP2PVPNs suchasHamachi[ 20 ]orSocialVPN[ 67 ]provideameansfortrustedandsocialpeers tocommunicatewitheachotherattheIPlayerinordertocoll aborate(e.g.multiplayer gaming,screensharing,mediasharing,amongothers).Also, inordertoestablishthese encryptedpeer-to-peerconnectionsinaP2PVPN,usersarerequi redtoexchange securitycredentialseitherthroughasharedpassword,ort heexchangeofcryptographic publickeys.Sinceconnectionsarecreatedwithdiligencean dmainlywithtrusted,social peers,theresultingpeer-to-peernetworkisasocialoverl ay.Thisassumptionhasvery importantimplicationsbecauseitisthebasisforlaterana lysisanddesigndecisions.For example,inthesimulationsbelow,awell-establishedsoci algraphgenerationmodels isusedtorepresentthisP2PVPNsocialoverlay.Moreover,theda tadissemination modelisbasedontheassumptionthatpeersprimarilywantto sendupdatestofriends 114

PAGE 115

andfriendsoffriends,andfollowerstendtobesociallyclo seoftheirpublishers.Thus, Litteroptimizesforthecommoncaseofdisseminatingmessa gestosocialpeers.Its replicationstrategyleveragestheclusteringofsocialgr aphstoincreasetheprobability thatsocialdistantpeersarestillabletoobtainpostsfrom apublisher.Finally,thissocial overlayisindependentfromthedirectedsocialgraphcreat edbysubscription-based socialnetworks.Theproposeddesignensuresthatamethodo fmessagedissemination existsamongallpeers,butitgivesprioritytofriends(and friendsoffriends). 5.3.3MicrobloggingPrivacybyDefaultinP2PVPNs Themotivationfordesigningaprivate,decentralizedmicr obloggingserviceisnotto provideapeer-to-peeralternativetoTwitter.Theprimary focusistobuildaframework wherepeerscanprivatelysendstatusupdatestotheirfrien ds(andfriendsoffriends) withoutfearthattheiractivitiesarebeingindenitelyre cordedandmonitoredbyathird party.AP2PVPNallowsdeveloperstoleverageexistingprivateI Ptunnelsthatcan beusedbyavarietyofdifferentapplications,notjustamic robloggingservice.Witha privatemicrobloggingservice,peerscancondentlysendu pdatestofriendsknowing thattheseupdateswillonlybesavedbytrustedpeersinstea dofacentralizeddatabase. Thisassumptionimpliesthatdifferenttypesofusageisexp ectedbetweenLitterand popularmicrobloggingsitessuchasTwitterwherethefocus ismuchmoreonpublishing informationpublicly.TheLitterapproachstartswiththem essagingcapabilitiesofthe P2PVPN,butitalsoprovidesmechanismstomakeitpossibleforpe erstopushupdates toeveryonepubliclyaswell. 5.4Design TheLittermicrobloggingserviceisbuiltontwobasicIPlay ermechanisms:1)IP multicastingtopropagatemessagestotwo-hopsneighborsi nthesocialgraph,2)and UDPdatagramsfortraversingthesocialgraphtodisseminat eupdatestosocialdistant peers.Inordertoenablethisservice,theassumptionistha tusersrunaP2PVPN servicethatprovidespeer-to-peer,encryptedIPtunnelst ofriends,eventhosebehind 115

PAGE 116

Table5-1.Thefourtypesofmessagesinthesystem TypeUIDDestTTLIDTimestampPermPayloadSignature MulticastPush UIDofpostcreator All1or 2 Uid+post YesForPMessage content(140-charmax) Hash(uid,id,timestamp,permissions,payload)thensignedwithprivatekey MulticastPull UIDofpostrequester All1or 2 Randomnumber YesNoneListof (followers,highestpostID) Hash(uid,id,timestamp,permissions,payload)thensignedwithprivatekey RandomPush UIDofpostcreator Any100, 200,400 Uid+post YesForPMessage content(140-charmax) Hash(uid,id,timestamp,permissions,payload)thensignedwithprivatekey RandomPull UIDofpostrequester Any100, 200,400 Randomnumber YesNoneListof (followers,highestpostID) Hash(uid,id,timestamp,permissions,payload)thensignedwithprivatekey NATsandrewalls;andtheP2PVPNservicesupportsIPmulticast. Theprevious chaptersdescribetheSocialVPNsystemwhichmeetsthesecrite ria. 5.4.1MulticastPushtoFollowers MessageFormat. Everypostgeneratedinthesystemcontainsthefollowing information:acreatorUID,adestination,aTTL,atimestam p,apostID,apermission ag,amessage,andasignature(seeTable 5.3.3 ).ThecreatorUIDhelpsthesystem keeptrackofthesourceoftheposts.Thedestinationeldis setto all meaningthat themessageisbroadcastedtoallfriendsthroughIPmultica st.TheTTLeldletsthe systemcontrolthescopeofthemessage,ifauserwouldliket opostmessagestoonly friends,thentheTTLissetto1.Ifauserwouldliketoreachb othfriendsandfriends 116

PAGE 117

offriendsthentheTTLissetto2.Thetimestamphelpskeeptr ackofthecreationtime ofthemessage.Thepostidisanumberwhichincrementsbyone foreachpostauser generates.Thepermissionaghelpcontroltheprivacyofth emessage;peersareonly allowedtoshareupdatesfrompullrequestsifthemessageis settoP(orpublic).The messageistheactualcontentofthepost;currentlythisisl imitedtoamaximumof140 characters.Thesignatureeldiscreatedbyhashingthecre atorUID,thetimestamp, thepostID,andthemessageandsignedwiththecreator'spri vatekey.Therefore thesignatureensurestheintegrityofthemessageandveri esitscreator,assuming recipientshaveaccesstothecreator'spublickey. Amulticastpushisthemostbasicmessagetypeinthesystem. SinceaP2PVPN enablesIPtunnelstofriends,andmulticastsupportwhichm akesitveryeasytocontact allfriendsprivately,implementingthisfeaturesimplyin volvedsendingaUDPpacket toanIPmulticastaddress.However,itisimportanttonotet hatdespiteitssimplicity, itisavitalrststepinallowingpeerstosendupdatespriva tely.Thismulticastpush, whichisviewedasthecommoncase,isefcientbecausemessa gesaresentdirectlyto friends,andtheyareprivatebydefaultbecausetheygothro ughencryptedIPtunnels. Forexample,Alicewantstogobowlingwithherfriends,soshe usestheLitterservice toquicklybroadcastthatmessagetoherone-hopfriendswho arecurrentlyonline.In thisexample,Alicelimitsthescopeofhermessagetoonlyfri ends,whichmeansthatthe TTLwillbesetto1. SupposenowthatAliceisvisitingPortlandandwouldliketokn owifanyofher friendsorfriendsoffriendsknowofanygoodrestaurantsin thearea.BysettingtheTTL to2,sheisabletopropagatethatmessageusingthesamemult icastpushmechanism (seegure 5-1A ).BystartingwiththesocialoverlayformedbyP2PVPNs,sending messagestofriendsandfriendsoffriendsistranslatedtoa UDPdatagramsenttoanIP multicastaddresswithaTTLvaluecontrollingthescope.Un likemanypreviousworks, pushingmessagestoclosefriendsisabetteralternativeto pollingfornewmessages 117

PAGE 118

AMulticastPush BMulticastPull Figure5-1.Multicastpushandpullmechanism.A)MulticastPu sh.Publisher(lledin black):A,Followers(partiallledinblue):B,C,D,F,K,L,S. Publishernode ApushespoststonodesB,C,D,E,F,G,H,J(sincetheyaretwo-h ops away).Somenodesseeduplicateposts(e.g.nodeEfrombothno desAand B).B)MulticastPull.NodesKandLarethreeandfourhopsawayan dthey areabletoreceiveupdatesfrompublishernodeAthroughnod esG,H,and J.WhennodeLdoesatwo-hopmulticastrequest,itreachesnod eGwhich sendsthepostsbacktonodeL. becauseitimprovestheinteractivityofthesystembydeliv eringmessageswithlow latency.Moreover,thesemessagesareencryptedend-to-en dbytheP2PVPNwhich ensuresathird-partyisnotabletointerceptorspooftheda ta.Thus,itisusedasthe primarymechanismtopublishpostsprivatelytoconnectedf riendsinatimelyfashion. ARandomPush BRandomPull Figure5-2.Randompushandpullmechanismfordistantfollo wers.A)RandomPushto DistantFollowers.Publisher(lledinblack):A,Followers( partiallledin blue):B,C,D,F,K,L,S.NodeApushespoststhrougharandompa thto extendthereachofthepostsbeyondfour-hops.Asaresult,no deA'spostis storedatnodesE,J,N,M,P,andR.B)RandomPullbyDistantFollo wers. NodeSdoesarandom-walkandgetsnodeA'spoststhroughnodeN which hascacheditduetonodeA'srandomwalkpush. 118

PAGE 119

5.4.2MulticastPullbyFollowers MessageFormat. Usersdonotonlyrelyonthepublisherstopushmessagesto them,theycanalsoproactivelypullfornewupdatesaswell. Apullrequestcontainsthe followinginformation:arequesterUID,adestination,aTT L,arequestID,atimestamp, thelistoffollowers,andasignature.TherequesterUIDhel psthesystemidentifywho shouldreceiveresponsesforaparticularrequest.Thedest inationeldissetto all to indicatetheuserofmulticasting.TheTTLcanbesetto1or2d ependingifthefollower wouldliketopullupdatesfromfriendsand/orfriendsoffri endsaswell.Eachrequest hasauniqueIDwhichallowsthesystemtokeeptrackofwherea requestoriginated, sothatrepliescanbesentalongtherightpath.Thetimestam phelpsdeterminethe freshnessofarequest;requestsbeyondacertaintimewindo wcanbeignored.Thelist offollowersincludesthepublishersthattherequesterisf ollowingalongwiththelastpost IDforeachfollower.Thatinformationisusedbyeachnodeth atreceivestherequest todetermineifarequesterismissingthelatestpostsfroma particularpublisher.The signatureinthiscaseisthesignedhashoftherequesterUID ,requestID,thetimestamp, andthelistoffollowers.Thesignaturemakesitpossibleto verifythelegitimacyofthe requestandhelpsguardagainstspoofedrequests. Multicastpullsareusedbyfollowersbecausesometimesthe ydonotreceive pushedpostsduetopacketdropsintheP2PVPN,orduetothefollow erbeingofine. CurrentlyintheLitterprototype,thepullrequestsaregen eratedeveryveminutes,but thisperiodiscongurablebytheuser.Themulticastpullsa lsoserveanotherimportant task:itmakesitpossibleforfollowerswhoarefourhopsawa ytoreceivepublicupdates fromapublisher.AsshowninFigure 5-1B ,ifnodeApushesapublicposttofriendsand friendsoffriends,nodeLisabletoretrievethoseupdatest hroughnodeG,eventhough nodesAandLareseparatedbyfoursocialhops.Therefore,wh ennodeApushesa publicposttoallfriendsandfriendsoffriends,thetwo-ho prequestsmakeitpossiblefor 119

PAGE 120

followerswhoarefourhopsawaytoreceiveupdatesthroughc ommonsubsetoffriends offriends. Returningtotheprivacyargument,whenausercreatesapost ,itcanbesetfor friendsonly,friendsoffriends,andeveryone.Friendsand friendsoffriendswillonly sharepublicupdateswithsocialdistantpeers(usersthata refartherthantwohops awayinsocialoverlay)iftheyarepublic.Also,evenifthetw o-hoppushandtwo-hop pullmechanismsprovidefour-hopcoverage,therearestill caseswherefollowersare morethanfourhopsaway.Thislimitationisaddressedwitht hefollowingmessage propagationmechanism.5.4.3Random-walkPushtoDistantFollowers MessageFormat. Themessageformatfortherandom-walkpushisverysimilar tothemulticastpushwithtwomaindifferences.Firstthede stinationeldissetto any insteadof all .Whensettoany,thesystemselectsarandompeertoforwardth e message.Thisisthemostbasicformofablindrandom-walk.Se cond,theTTLvalue issettoalargevalue(e.g.100,200,or400)dependingonthe user'spreference.The TTLservesasthereplicationfactorbecausethemessageiss toredateachnodeit reaches.SelectingahigherTTLincreasesthechancesthatdi stantfollowerswillbeable toreceivetheupdatesofthepublisher. Theneedforarandom-walkpushisnecessarytoensurethatan ypeerinthe networkcouldfolloweachother.Althoughthisisnotthecomm oncase,itisimportantto provideacontrollablemechanisminwhichapublishercould expandthereachoftheir posts.Byreplicatingpoststhroughoutthesocialoverlay,a publishercancontrolthe availabilityofhis/herupdates.However,randomlyreplic atingthemessagesdoesnot ensurethatitisstoredatfollowernodes;followersalsone edtorequestupdatesfrom peersinthenetworktoincreasetheirchancesofobtainingm essages.Forexample inFigure 5-2A ,therandompushmethodreplicatespostsatnodesE,J,N,M,P, and 120

PAGE 121

R.Thenodesarenotfollowernodes,butthehopeisthattheyw illmakeiteasierfor followerstoretrieveupdatesfromnodeA.5.4.4Random-walkPullbyFollowers MessageFormat. Themessageformatfortherandom-pullisquitesimilartoth e multicastpullrequests.However,thedestinationeldisc hangedto any inorderto causearandom-walkinthesocialoverlay.Also,theTTLisset toalargeTTL(e.g.100, 200,or400)toincreasethesearchpathforupdates. Therandompullrequestsarehandledinasimilarmannerasth emulticastpull request;ifapeernoticesthattherequesterdoesnotcontai nthelatestupdates,itreplies withtheseupdates.AsshowninFigure 5-2B ,nodeSisabletopullnodeA'supdates throughnodeNthatholdsareplicaofnodeA'supdatesfromthe randomwalk.NodeN repliestonodeSandforwardstherandompullrequesttothen extnodeinthesystem. Therepliestakethereversepathoftherandom-walk.Therev ersepathisknown becauseeachnodebuildsaroutingtablethatmapsrequestID stoIPaddresses.That informationmakesitpossibletosendareplyalongitsrever sepathinthesystemas longasthereplyhasthesameIDastherequest.Also,arandomp ullrequestcontinues throughthenetworkuntiltheTTLreacheszero.Thisensures thattherequestercan controlthenumberofnodestosamplefornewmessagesfromhi s/herfollowers. Overall,thecombinationoftherandompushandpullmechani smmakesitpossible foranypeerinthesystemtofollowanotherpeeraslongasbot hthepublisherandthe followerusetheappropriateTTLvaluesintheirrequest.Byp rovidingacongurableTTL inthesystem,publishersareabletocontrolhowmuchpublic itytheywantfortheirposts; therefore,ifusersfeeltheyhavesomethingimportanttosa ytothewholenetwork,they cansetahighTTLsuchas400,iftheyonlycareaboutreaching closefriends,theycan setalowerTTLof1or2.Onthepullingside,afollowerisalso abletousetheTTLto increasehis/herabilitytoretrieveupdatesfromsocialdi stantpeersinthenetwork. 121

PAGE 122

5.4.5MessagePrivacyandVerication Messageprivacyisaccomplishedthroughapermissionag.I famessageisset topublic(orP),thenfriendsaretoallowedtosharetheposts whentheyreceiveapull request.WiththepermissionagandtheTTL,theuserisablet ocontrolthescopeof theirupdates.Forfollowerswhoaremultiplehopsawayfrom thepublisher,amessage hastogothroughmultipleintermediatenodesinthesocialg raph.Toensuremessage vericationandintegrity,eachmessagecontainsasignatu reformedbyhashingthe contentsofthepostandsigningitwithaprivatekey.Afollo werisresponsiblefor acquiringapublisher'spublickeythroughatrustedout-of -bandmedium.Dealing withcryptographickeydistributioninpeer-to-peersyste misbeyondthescopeofthis research. 5.5Implementation Anotherkeycontributionofthisworkisaprototypeimplemen tationthatuserscan downloadandprovidefeedback.Thecodeisopensource(http ://github.com/ptony82/litter). Codingsimplicityisoneofthestrengthsoftheproposedapp roach:byleveraging P2PVPNsandreusingBerkeleysocketsAPIandWeb/databasemodulesf oruser interfaceanddatastorage,thecodeisonly1500lines.Litt eralsodifferentiatesitself fromotherpreviousattemptsatamicrobloggingservicebye nsuringeaseofdeployment andusability.Inthissection,thetechnicaldetailsofthe Litterapproachareshowntobe muchmorepracticalthanprevioussolutions. Therstrequirementfordecentralizedmicrobloggingserv iceisaP2PVPNofwhich therearevariouscommercialandopen-sourcesolutionstha tausercaninstall.The implementationiswritteninPythonandusesitscorrespondi ngstandardmodulesto enablethefollowingcapabilities:networkcommunication ,objectserialization,data encryption,datastorage,andHTTPinterface.Networkcomm unicationistherst crucialcomponentanditisbasedontheBerkeleysocketsAPIava ilableinPython. Tocommunicate,theservicerstjoinsanIPmulticastgroup andthenlistensonthe 122

PAGE 123

Figure5-3.Screenshotofthemicrobloggingservice appropriateUDPportforincomingpostsandpullrequests.T osendamulticastpostora pullrequest,thepayloadisencapsulatedinaUDPdatagramt hatissenttothemulticast IPaddressthroughthevirtualnetworkinginterface(NIC)o ftheP2PVPN.TheP2PVPN thensendsthemulticastIPpackettoallconnectedfriends, sothatthelisteningnodes canreceivethemulticastUDPmessage. Theeldsofeachmessagetypeareserializedthroughtheuse oftheJavascript ObjectNotation(JSON)protocol,whichconvertsthecontent softhesemessagetypes intoanormalizedstringwhichbecomesthepayloadoftheUDP datagram.Animportant eldofallthedifferentmessagetypesisthesignature.For generatingthehash,the SHA1hashfunctionsareusedwhicharepartofthestandardPytho nlibrary,andfor signingthehash,theRSAprivatekeyisused.Fordatastorage ,LitterutilizestheSQLite databasemoduleinthePythonstandardlibrary. ThenalcomponentistheHTTPinterfacewhichplaysanimpor tantroleinthe designintermsofinterfacingwiththelocalmicroblogging service.Litterprovidesan HTTPinterfaceprimarilybecauseitmakesitpossibletoint eractwiththemicroblogging servicethroughaWebbrowserinsteadofacustomuserinterf ace.Therefore,Litterhas anAJAXWebinterfacetointeractwiththelocalmicroblogging service(seegure 5-3 ). 123

PAGE 124

Therstexperimenttestsa100nodeFutureGriddeploymentt ostudytheIP multicastperformanceonanopen-sourceP2PVPNontheInternet. FutureGridisan academictestbedforcloudresearchwhichletsusersinstan tiatevirtualmachinesat geographicallydispersedlocations.Asshowningure 5-1 ,allofthelatenciesare below100mswhichdemonstratesthatausercanpushupdatest osocialpeersthatare hundredsofmilesawayfairlyquickly. 5.6Analysis Thissectiondiscussesthebandwidthcostsofthemulticast messages,andalso studiestheimpactofvariousconnectionlimitsandTTLvalu esonthepropagation ofupdatesthroughthesocialoverlay.Thisanalysisisbase dontheassumptionthat P2PVPNsformsocialoverlays;therefore,byanalyzingtheLitte rdesignarepresentative 3-millionusersocialgraphfromOrkut,itispossibletogai nsomeinsightonthe performanceoftheproposedimplementation.5.6.1GraphCharacteristics Thesocialnetworkinggraphutilizedinthisworkwasobtain edfromtheauthors of[ 98 ]andthisisasummaryofitscharacteristicsaccordingtoth eauthors.Itwas collectedduringOctober3rdtoNovember11th2006usingapa rtialbreadth-rst search.Itcontains3millionnodesand223millionedgeswhi chrepresentsabout 11%ofthesocialnetworkatthetime.Thenodedegreedistrib utionisbestestimated asapower-lawdistributionwithacoefcientof1.50withan averagedegreeof106. However,sincepartialBFScrawlstendtooversamplehigh-de greenodes,this power-lawcoefcientisprobablyhigherthanthetruecoef cientofthewholegraph. Finally,thesocialgraphhasanaveragepathlengthof4.25, witharadiusof6,anda diameterof9.Theclusteringcoefciencyis0.171whichisi ntherangeoftypicalsocial networkinggraphs. Oneofthenoveltiesofthisapproachistheuseofsuchamassi vesocialgraphfor conductingtheanalysis.Mostpeer-to-peersimulationpac kagesdonoteasilyscaleto3 124

PAGE 125

millionnodesduetobothtimeandresourceconstraints.For analysis,theLemonGraph Libraryisusedwhichisalightweightandefcientsoftware packageformodelingand optimizingnetworks.ItiswritteninC++andhasasmallfoot printformappingsocial graphsinmemory. ANoCap(PDF) BCap=25(PDF) CCap=50(PDF) DNoCap(CDF) ECap=25(CDF) FCap=50(CDF) Figure5-4.Bandwidthcostoftwo-hopbroadcastsfor3MuserO rkutsocialgraph.The x-axisisthenumberofKBforpush/pullmessagesatatwohopra dius,the y-axisisitsprobability.A)NoCap(PDF).B)Cap=25(PDF).C)Cap =50 (PDF).D)Cap=50(PDF).E)NoCap(CDF).F)Cap=25(CDF).G)Cap=50(CDF) 5.6.2BandwidthCostsofTwo-hopPush/PullPublishing Litterreliesheavilyontheuseofatwo-hopmulticasttopus hmessagestofriends andfriendsoffriends.Italsoutilizesatwo-hopmulticast pulltoguaranteethatfollowers whoarethreeandfourhopsawayinthesocialgraphcanalsore trievemessages uponrequest.Thereforeitisimperativetounderstandtheb andwidthusageofsucha mechanisminthecontextofasocialgraph.Intheanalysis,i tisassumedthateachpost is1KBforsimplicity.Sincepostsareonly140characterswith someadditionalelds 125

PAGE 126

forrouting,authentication,andintegrityverication,i tisexpectedthatthemajorityof messagestofallwellunderthis1024-byteassumption. Figures 5-4A and 5-4D demonstratetheprobabilitydistributionfunction(PDF) andcumulativedistributionfunction(CDF)ofusingatwo-h opmulticastmechanismto publishmessagestofriends.Accordingtothesedistributio ns,therstquartileis4.61 MB,themedianis13.99MB,andthethirdquartileis41.53MB. Theaveragebandwidth costis54.91MB.Suchahighbandwidthcostpermessageisduet othepresenceof manyhighdegreenodesinthesocialgraph.Itisimportantto notethatthisisnotthe bandwidthcostpernode,itisthetotalbandwidthutilizedb ythepublisherandhis/her rsthopfriends.Forexample,assumingAlicehas2friends,Bo bandCarol,whoeach has3friends.Thetotalcostofatwo-hopmulticastfromAlice wouldbe8KB(assuming 1KBposts). Asmentionedinthedesignsection,thesystemleveragesexis tingP2PVPN technologieswhichallowsforthedevelopmentofthisdecen tralizedserviceusingsimple UDPdatagramsandIP-multicastingformessagedisseminatio n.However,P2PVPNs createsanoverlaynetworkwhichrequiresconstantmonitor ingandmaintenanceof eachP2Pconnection.Inarepresentativesocialgraph,anave rageuserwillpossess over100socialconnections.Maintainingsuchalargenumbe rofconnectionsover timecanbecostlyintermsofbothbandwidthandpowerconsum ption.Therefore,this analysisexplorestheimpactofimposingalimitonthenumbe rofsocialconnections thatapeercanmaintain.Theselimitsareimplementedrando mlywherethereisno preferentialtreatmentgiventoanyconnection.Thischapt eralsoanalyzeslimitsof 25and50connectionsperuser.Asseenongures 5-4B 5-4C 5-4E ,and 5-4F ,the implementationoftheconnectionlimitsgreatlyreducesth ebandwidthcostofthe two-hoppropagation.Withalimitof50connections,therst quartileis320KB,the medianis569KB,andthethirdquartileis774KB.Althoughthese aremoreacceptable bandwidthusagenumbers,thetradeoffisthefactthatone-h opfriendscannowbe 126

PAGE 127

two,three,orfourhopsawayinthesocialgraph.Theexperim entsshowthatwitha limitof50connections,over25%offriendsaremorethanfou r-hopsaway.Limitingthe connectionsthereforeincreasethediameterofthesocialg raphthendecreasingthe numberoffollowersthatcanbereachedatafour-hopdistanc eandtherebyincreasing therelianceofothermessagereplicationmechanismstoens urethatsociallydistant followerscanstillretrievemessagesfromanywhereinthes ocialgraph. 5.6.3MessageReplicationTowardsHighDegreeNodes Thedistributedmicrobloggingsystemwasdesignedformess agedistribution forclosefriendsandfriendsoffriends.Theassumptionist hatbyusingatwo-hop push/pullmechanism,Litterguaranteesfour-hopcoverage whichshouldcoverthe majorityofsocialinterestedpeers.However,therearesom ecaseswhereausermight wantanyoneinthesocialgraphtohaveaccesstoasubsetofth eirposts.Insucha scenario,Litterpossessesamechanismwhichallowspostst opropagatebeyondthe four-hopsocialradius.Therstnaiveattemptistouseasim plerandom-walk-based replication.Inthismethod,auserpostsamessagewithahig hTTLvalue(i.e.50,100, 200)representingthereplicationfactorofthemessage.Byi ncreasingtheTTLvalue basedonthesizeofthenetwork,ausercanincreasetheproba bilitythatfollowersthat aremorethan4hopsawaycansuccessfullyretrieveamessage .Inthesimulations,the random-walkapproachwasalmostacompletefailurewithasu ccessrateoflessthan 1%whentheTTL=100. Hence,Litteradoptsadifferentstrategyofreplicatingat thehighestdegreenodes ratherthanrandomnodes.Thismodicationguaranteedthat nodesalwaysretrieve updateswithamaximumTTLof35(seegure 5-5A ).Thealgorithmissimple,ateach hopofthemessage-walk,thecurrentnodeselectstheneighb orwiththehighestdegree thathasnotyetbeenvisited.Therehasbeenmuchresearchab outtheeffectiveness ofpublishinganddoinglookupsthroughhighdegreenodesin power-law(orsocial) networks.Theconsensusisthatincertainwell-denedpowe r-lawnetworks,the 127

PAGE 128

ABWCost-Cap=0(PDF) BBWCost-Cap=25(PDF) CBWCost-Cap=50(PDF) Figure5-5.Probabilitydistributionofwalks.Thex-axisis thenumberofhopsittookto ndthepost,they-axisisitsprobability.A)BWCost-Cap=0(PD F).B)BW Cost-Cap=25(PDF).C)BWCost-Cap=50(PDF). averagenumberofhopsperlookupisonthelogarithmicscale ofthesizeofthenetwork (i.e. O(klogN) where N isthesizeofthenetwork). Byfollowingthissimplerule,gure 5-5A and 5-5B showsthatabout95%ofthe time,afollowcanretrieveamessagereplicatedathighdegr eenodeswithaTTLof30. However,thisisonlyeffectivewhenthesocialgraphisnotc onstrainedbyalimitonthe numberofconnections.Byimposingalimitonthenumberofcon nections,thesuccess ratedropsdowntobelow1%andthereforethismechanismisno tveryeffective. Overall,theanalysissectionprovidestwokeyinsights.Fi rst,usingatwo-hop multicastpushmechanismiscostlyina3millionusersocial graphwhichfollowsa power-lawdistributionwithanaveragecostover50MB.Ther efore,itisrecommended tolimitthenumberofconnectionsperuserinordertouseles sbandwidth.Second,by replicatingmessagesusingapropagationtechniquethatse lectsthehighestdegree neighborasthecandidateformessagereplication,Litterg uaranteesthatanyuserin thesocialgraphcanretrievethemessagewithafairlylowTT L.Butthisapproachonly workswhenthereisnotaconnectionlimit,sincethelimitca ndistortthepower-law propertyofthesocialgraph. 128

PAGE 129

5.7Summary Thischapterdemonstratesthepossibilityofleveragingpr ivateIPlinksandthe socialoverlayformedbyP2PVPNstocreateadecentralizedmicro bloggingservice.The Litterdesignstartswithprivatemessageatthecoreofthep rotocolwhichdifferentiates itfromotherapproaches.Thissolutionalsominimizescodi ngcomplexitybyallowingthe useoftheBerkeleysocketsAPIforcommunicationinsteadofacu stomizedP2Plibrary interface.Therefore,withIPmulticastingandUDP-basedra ndom-walks,itispossible todeliverasystemwhichoptimizesforfast,privateupdate stosocialpeers.Litteralso providesmechanismsforpeerstopublishupdatesbeyondjus tfriends(andfriendsof friends)throughtheuseofahigh-degreenodereplications chemethroughoutthesocial overlay.Theanalysisalsoshowsthatitisimportanttoimpo selimitsonthenumber connectionsthatapeercanmaintaininordertominimizeban dwidthconsumption. However,theconnectionlimitsreducetheeffectivenessof ourreplicationstrategy. 129

PAGE 130

CHAPTER6 CONCLUSIONANDFUTUREWORK Thisdissertationdescribesapeer-to-peerarchitecturea imedatfacilitating thedevelopmentanddeploymentofsocialnetworkingapplic ations.Thegoalof thisarchitectureistoprovidethecorefunctionalitiesth atmostdecentralizedsocial networkingapplicationsdependonsuchas:socialpeerdisc overyandkeymanagement, directIPconnectivityandtranslationamongsocialpeerse venthroughNATsand rewall,user-friendlyreferencestouserendpoints,ands ocialidentitymanagement. ThisresearchthusdescribesSocialVPN,anovelpeer-to-peerv irtualprivate network(P2PVPN)wheresocialrelationshipsaremappedtovirtu alIPconnections. InsteadofanunfamiliarP2Papplicationprogramminginterf ace(API),SocialVPN providesavirtualnetworkinglayerwhichenablesprivateI Pconnectivityamong socialpeersthroughencryptedP2Ptunnels.Thisletsprogra mmersdevelopsocial P2Papplicationsusingthewell-known,andwell-supportedBe rkeleysocketsAPI. Consequently,legacyclient-serverapplicationscanrunw ithminimalmodicationswhile adoptingamorerobustP2Pmodelforsocialapplications. Morespecically,theSocialVPNapproachleveragesexistings ocialinfrastructures toenablead-hocVPNswhichareself-conguring,self-managi ng,yetmaintainsecurity amongsttrustedanduntrustedthirdparties.Thekeyprinci plesoftheSocialVPNdesign are:(1)self-conguringvirtualnetworkoverlaysenables eamlessbi-directionalIP-layer connectivitytosociallyconnectedparties;(2)onlinesoc ialnetworkingrelationships facilitatetheestablishmentoftrustrelationshipsamong peers;and(3)bothcentralized anddecentralizeddatabasesofsocialnetworkrelationshi pscanbesecurelyintegrated intoexistingpublic-keycryptography(PKI)implementation stoauthenticateandencrypt end-to-endtrafcows.SocialVPN,therefore,solvesthekeyc hallengeofbootstrapping trustedP2Pcommunicationlinksamongfriendsandachievest histhroughanovel 130

PAGE 131

cryptographickeyexchangeandvericationmechanismwhic hutilizesexistingsocial networkinginfrastructuressuchasFacebook,orXMPP. AnaturaladditiontoprivateIPchannelsisadomainnamings ystem(DNS)which allowsforaconsistentendpointtonetworkservices.Social DNSenablessucha systeminadecentralizedP2Pfashion.Usersareabletoselec tdomainnamesamong themselvesfortheirresourceswithintheirsocialcirclef oruniquenessinsteadofthe globaluniquenessenforcedbythenormalDNSsystem.Whennam econictsarise intheSocialDNSsystem—twopeersdecidetochoosethesamedo mainnamefor aresource—asocialrank-basedmethodisusedtoselectthem appingwiththe highestpopularityinthesocialcircle.Thisistherstdec entralizeddomainservice whichintroducesasocialaspecttodomainnaminginasecure fashion.Hence,withthe combinationofSocialVPN,whichprovidesIPconnectivity,and SocialDNS,whichallows domainnamemappingstoprivateIPaddresses,thisarchitec turegreatlysimpliesthe developmentofsocialapplications. TodemonstrateSocialVPN'sabilitytoenablesocialnetworkin gapplications, adecentralizedmicrobloggingservicewasdeveloped,dubb edLitter.Theprimary goaloftheLitterdesignistoenablefast,privateupdatesa mongfriends.Byutilizing SocialVPN,LitterbuildsuponalayerwhereusershaveprivateI Pconnectivitytoeach otheralongwithIPmulticastsupportthusenablingtrusted socialcommunicationon theInternet(eventhroughNATsandrewalls).SocialVPNnatur allymapstosocial graphsandthereforeservesasastrongfoundationforbuild ingdecentralizedsocial servicesbecausetheyspecializeinlowlatency,privateco mmunicationbycreating direct,encryptedpathsamongfriends.Withthisunderlying socialoverlay,Litterlets theusercontrolthepropagationofapostinthesocialoverl aythroughtheuseofIP multicastpackets.Italsoleveragesthepropertiesofthes ocialgraphfordatareplication heuristicsinordertoefcientlydisseminatepublicposts throughoutthesocialoverlay. 131

PAGE 132

Thisapplicationservestodemonstratethepracticalbene tsofbuildingsocialP2P applicationsontopofSocialVPN. Theoverallpeer-to-peerarchitecturethereforecontains thefollowingfeatures:1) locallyassignedprivateIPaddressestosocialpeerswhich doesnotrequireglobal uniqueness,2)theabilitytomapdomainnamestoIPendpoint sandsharethose mappingwithfriendswithoutdependenceonathirdparty(i. e.networkadministrator), and3)supportforbothstructuredandunstructuredP2Pnetwo rkswhichadds robustnessandversatilitytothebootstrapofsocialconne ctions.Thesefeaturesmake deployingsocialnetworkingapplicationsmoreexible,an dindependentofexpensive centralizedinfrastructureinvestmentswhichbenetdeve lopersandendusersinthe longrun.Thisdissertationcontributesthedesignofapeer -to-peerarchitectureforsocial networkingapplicationsalongwithaprototypeimplementa tionthatworksinrealistic environments,accompaniedwithquantitativeevaluationo fitsperformance. Forfuturework,itisimperativetosupportroutingoveroth ertypesofnetworking technologiesbeyondthetypicalEthernetorWiFi.Theability toleverageanytypeof connectivityamonguserswillreducethebarrierstodeploy ment.Thechallengeisto providesupportforthenewtypesofnetworkingtechnologie swithoutdisruptingeither thedevelopersortheusers.Thetransitionandadaptabilit yshouldbetransparentin mostcases.Theuseofnetworkingvirtualizationhelpswith programmingtransparency, buttheuserexperienceshouldnotbeaffected.Therefore,i twillbeimportanttocreate anintelligentmechanismthatwilldecidewhentoselectthe appropriatenetwork connectionwithoutcausinganymajordisruptiontoapplica tionperformanceorqualityof service. Acommontypeofnetworkconnectivitythatexistsamongmost userisBluetooth networking.Bluetoothnetworkingisubiquitousrangingfro mcellphonestolaptops. ItisalsoalowerpowermethodofcommunicationthanWiFiandi tdoesnotrequire anyinfrastructurewhichmakesitidealinad-hocsituation s.SupportingBluetooth 132

PAGE 133

connectivityinthearchitecturewillmakeitamorerobusts olutionbecauseitaddsmore connectionoptionstohelpusersshareinformation.Fromth edeveloperstandpoint,no newcodewillberequiredtotakeadvantageofthiscapabilit y. Oneofthefeaturesofthearchitectureismessagerouting.Wi ththeadditionof unstructuredP2Pnetworkingsupportandtheabilitytoroute overothernetworking technologiessuchasBluetooth,thetaskofselectingthemos toptimalroutebecomes morecomplicatedduetotheaddeddimensions.Forexample,t heoptimalroutemaybe onewhichputsmoreweightonpowerconsumptionthanonhopco unt.Inthecurrent architecture,theoptimalrouteistheshortestpath.Infut uredesign,eachroutemay haveasetofparameterssuchasthepowerusageorsocialtrus t.Understandingthe impactofthesenewdimensionsandintegratingthemintothe routingalgorithmisa crucialadditiontothisarchitecture. SocialroutingthroughtheunstructuredP2Psocialgraphform edbySocialVPN linksisanotherpotentialavenueforfuturework.Unstruct uredP2Pnetworksare commoninpopularP2PapplicationssuchasSkype,Bittorent,an dFreenetduetotheir simplicityandrobustnesstoP2Pattacks.However,theuseof anunstructuredP2P networkrequiresaprobabilisticsocialroutingmechanism forpeerdiscoveryinstead ofthegreedyroutingalgorithmavailableinstructuredP2Ps ystems.Byleveragingthe propertiesoftheunstructuredgraph,theappropriaterout ingalgorithmmakesitpossible toefcientlydiscoverpeersinthesocialP2Pnetwork. TheunstructuredSocialVPNP2Pnetworkcanbeabstractedasasoc ialgraphwith thesmall-world,scale-freecharacteristicsofalowdiame terandhighclustering.Also, thenodedegreedistributiontendstohavealongtailrepres entingthesupernodeswhich serveashubsensuringalow-diameterinthesocialgraph.Byl everagingthenatural characteristicsoftheP2Pnetwork,algorithmsandheuristi cscanbedevelopedto optimizetheperformanceofsocialnetworkingapplication s.Byintegratingsocialrouting 133

PAGE 134

directlyintotheSocialVPNarchitecture,anysocialnetworki ngapplicationdeployedon topofthisframeworkinheritsthisenhancementwithoutany codemodication. 134

PAGE 135

REFERENCES [1] I.Paul,“Microsoftbingsocialvs.googlesearchplusyourw orld:Showdown,” http:// www.pcworld.com/article/255476/microsoft bing social vs google search plus your world showdown.html ,May2012. [2] K.Hill,“Facebookprivacypolicychangepaveswayforoff-fa cebook advertising,” http://www.forbes.com/sites/kashmirhill/2012/05/11/ facebook-privacy-policy-change-paves-way-for-off-fa cebook-advertising/ ,May 2012. [3] J.Cheng,“Over3yearslater,”deleted”facebookphotosarestillonline,” http://arstechnica.com/business/2012/02/ nearly-3-years-later-deleted-facebook-photos-are-st ill-online/ ,February2012. [4] E.V.Buskirk,“Denial-of-serviceattackknockstwitterofi ne,” http://www.wired.com/ business/2009/08/twitter-apparently-down/ ,August2009. [5] I.vanBeijnum,“Howegyptdid(andyourgovernmentcould)shu t downtheinternet,” http://arstechnica.com/tech-policy/news/2011/01/ how-egypt-or-how-your-government-could-shut-down-th e-internet.ars ,January 2011. [6] J.P.Mello,“Anonymousclaimsattackonfacebook,” http://www.pcworld.com/article/ 256646/anonymous claims attack on facebook.html ,June2012. [7] D.Tynan,“Facebook's'maninthemiddle'attackonourdata, ” http://www.itworld. com/it-managementstrategy/247344/facebooks-man-midd le-attack-our-data February2012. [8] Y.Chawathe,S.Ratnasamy,L.Breslau,N.Lanham,andS.Shenke r,“Making gnutella-likep2psystemsscalable,”in Proceedingsofthe2003conferenceonApplications,technologies,architectures,andprotocolsf orcomputercommunications ser.SIGCOMM'03.NewYork,NY,USA:ACM,2003,pp.407–418. [9] M.Castro,P.Druschel,A.Ganesh,A.Rowstron,andD.S.Wallac h,“Securerouting forstructuredpeer-to-peeroverlaynetworks,” SIGOPSOper.Syst.Rev. ,vol.36, no.SI,pp.299–314,Dec.2002. [10] L.Cutillo,R.Molva,andT.Strufe,“Privacypreservingsocia lnetworkingthrough decentralization,”in WirelessOn-DemandNetworkSystemsandServices,2009. WONS2009.SixthInternationalConferenceon ,feb.2009,pp.145–152. [11] S.Buchegger,D.Schi ¨ oberg,L.H.Vu,andA.Datta,“Peerson:P2psocial networking:earlyexperiencesandinsights,”in SNS'09:Proceedingsofthe SecondACMEuroSysWorkshoponSocialNetworkSystems .NewYork,NY, USA:ACM,2009,pp.46–52. 135

PAGE 136

[12] F.Rahimian,S.Girdzijauskas,A.Payberah,andS.Haridi,“Vi tis:Agossip-based hybridoverlayforinternet-scalepublish/subscribeenab lingrendezvousrouting inunstructuredoverlaynetworks,”in ParallelDistributedProcessingSymposium (IPDPS),2011IEEEInternational ,may2011,pp.746–757. [13] S.Abbas,J.Pouwelse,D.Epema,andH.Sips,“Agossip-baseddis tributedsocial networkingsystem,”in EnablingTechnologies:InfrastructuresforCollaborative Enterprises,2009.WETICE'09.18thIEEEInternationalWorkshop son ,29 2009-july12009,pp.93–98. [14] “Facebookplatform,” http://developers.facebook.com/ ,2008. [15] C.Cooper,“Linkedinbowstotwitterovertweettrafcdirection,” http://news.cnet.com/8301-1023 3-57464054-93/ linkedin-bows-to-twitter-over-tweet-trafc-directio n/ ,June2012. [16] Z.Whittaker,“Facebookapplicationsleakusers'personaldatatothirdparties,” http://www.zdnet.com/blog/igeneration/ facebook-applications-leak-users-personal-data-to-t hird-parties/9906 ,May2011. [17] P.Saint-Andre,“Xep-0277:Microbloggingoverxmpp,” http://xmpp.org/extensions/ xep-0277.html ,2012. [18] A.I.T.RowstronandP.Druschel,“Pastry:Scalable,decentra lizedobjectlocation, androutingforlarge-scalepeer-to-peersystems,”in ProceedingsoftheIFIP/ACM InternationalConferenceonDistributedSystemsPlatformsH eidelberg ,ser. Middleware'01.London,UK,UK:Springer-Verlag,2001,pp.329 –350. [19] I.Clarke,O.Sandberg,B.Wiley,andT.W.Hong,“Freenet:Adis tributed anonymousinformationstorageandretrievalsystem,”in InternationalWorkshoponDesigningPrivacyEnhancingTechnologies:DesignIss uesinAnonymity andUnobservability .NewYork,NY,USA:Springer-VerlagNewYork,Inc.,2001, pp.46–66. [20] “Hamachi-instant,zerocongurationvpn.” http://https://secure.logmein.com/ products/hamachi/vpn.asp?lang=en ,May2009. [21] “Socialvpn,” http://socialvpn.org/ ,2010. [22] “Thep2pvpnproject,” http://p2pvpn.org/ ,2010. [23] “Thexmppfoundation,” https://xmpp.org/ ,2009. [24] M.Krochmal,“Multicastdnsinternetdraft,” http://les.multicastdns.org/ draft-cheshire-dnsext-multicastdns.txt/ ,September2008. [25] “Multicastdnsinternetdraft,” http://technet.microsoft.com/en-us/library/ cc784180(WS.10).aspx ,2010. 136

PAGE 137

[26] T.Xu,Y.Chen,J.Zhao,andX.Fu,“Cuckoo:towardsdecentraliz ed,socio-aware onlinemicrobloggingservicesanddatameasurements,”in Proceedingsofthe2nd ACMInternationalWorkshoponHotTopicsinPlanet-scaleMea surement ,ser. HotPlanet'10.NewYork,NY,USA:ACM,2010,pp.4:1–4:6. [27] B.Ford,P.Srisuresh,andD.Kegel,“Peer-to-peercommunica tionacrossnetwork addresstranslators,” CoRR ,vol.abs/cs/0603074,2006. [28] A.Ganguly,A.Agrawal,P.Boykin,andR.Figueiredo,“Ipoverp2p :enabling self-conguringvirtualipnetworksforgridcomputing,” ParallelandDistributed ProcessingSymposium,2006.IPDPS2006.20thInternational ,pp.10pp.–,April 2006. [29] “Facebookstatistics,” http://www.facebook.com/press/info.php?statistics ,May2009. [30] F.Qiu,C.Lin,andH.Yin,“Ekm:Anefcientkeymanagementsche mefor large-scalepeer-to-peermediastreaming,”vol.4261.Berl in/Heidelberg: Springer,2006,pp.395–404. [31] S.RafaeliandD.Hutchison,“Asurveyofkeymanagementfors ecuregroup communication,” ACMComput.Surv. ,vol.35,no.3,pp.309–329,2003. [32] X.Liu,H.Yin,C.Lin,andY.Deng,“Efcientkeymanagementand distributionfor peer-to-peerlivestreamingsystem,”282007-Dec.12007,p p.638–641. [33] X.Zhang,M.Nakae,M.J.Covington,andR.Sandhu,“Towardausa ge-based securityframeworkforcollaborativecomputingsystems,” ACMTrans.Inf.Syst. Secur. ,vol.11,no.1,pp.1–36,2008. [34] J.Domingo-Ferrer,“Apublic-keyprotocolforsocialnetwo rkswithprivate relationships,”in LectureNotesinComputerScience ,vol.4617(Modeling DecisionsforArticialIntelligence-MDAI'2007),August20 07,pp.373–379. [35] A.Mislove,M.Marcon,K.P.Gummadi,P.Druschel,andB.Bhattac harjee, “Measurementandanalysisofonlinesocialnetworks,”in Proceedingsofthe 5thACM/USENIXInternetMeasurementConference(IMC'07) ,October2007. [36] “Openvpn-theopensourcevpn.” http://openvpn.net/ ,2009. [37] M.Tsugawa,A.Matsunaga,andJ.A.B.Fortes,“Virtualizationt echnologiesin transnationaldg,”in dg.o'06:Proceedingsofthe2006internationalconferenceo n Digitalgovernmentresearch .NewYork,NY,USA:ACMPress,2006,pp.456–457. [38] A.SundararajandP.Dinda,“Towardsvirtualnetworksforvirt ualmachinegrid computing,” http://citeseer.ist.psu.edu/645578.html ,2004. [39] I.X.Jiang,“Violin:Virtualinternetworkingonoverlay,” http://citeseer.ist.psu.edu/ 714412.html ,2009. 137

PAGE 138

[40] L.DeriandR.Andrews,“N2n:Alayertwopeer-to-peervpn.” http://luca.ntop.org/ n2n.pdf/ ,2008. [41] S.Aoyagi,M.Takizawa,M.Saito,H.Aida,andH.Tokuda,“Ela:afu llydistributed vpnsystemoverpeer-to-peernetwork,”Jan.-4Feb.2005,pp .89–92. [42] A.Ganguly,P.O.Boykin,D.I.Wolinsky,andR.J.Figueiredo,“ Improvingpeer connectivityinwide-areaoverlaysofvirtualworkstation s,”in HPDC'08:Proceedingsofthe17thinternationalsymposiumonHighperfor mancedistributed computing .NewYork,NY,USA:ACM,2008,pp.129–140. [43] P.O.Boykin,J.S.A.Bridgewater,J.Kong,K.Lozev,B.Rezaei,an dV.P. Roychowdhury,“Brunetsoftwarelibrary,” http://brunet.ee.ucla.edu/brunet/ ,2009. [44] “Openid,” http://openid.net/ ,2008. [45] E.RescorlaandN.Modadugu,“Datagramtransportlayersecur ity,” http://www. rfc-editor.org/rfc/rfc4347.txt ,April2006. [46] “Universaltun/tapdriver,” http://vtun.sourceforge.net/tun/index.html ,2008. [47] B.Chun,D.Culler,T.Roscoe,A.Bavier,L.Peterson,M.Wawrzo niak,and M.Bowman,“Planetlab:anoverlaytestbedforbroad-coverage services,” SIGCOMMComput.Commun.Rev. ,vol.33,no.3,pp.3–12,2003. [48] “Googleappenginecloudinfrastructure,” http://code.google.com/appengine/ ,2009. [49] M.VarvelloandM.Steiner,“Trafclocalizationfordht-bas edbittorrentnetworks,”in Proceedingsofthe10thinternationalIFIPTC6conferenceon Networking-Volume PartII ,ser.NETWORKING'11.Berlin,Heidelberg:Springer-Verlag,20 11,pp. 40–53. [50] A.Lindgren,A.Doria,andO.Schel en,“Probabilisticroutinginintermittently connectednetworks,” SIGMOBILEMob.Comput.Commun.Rev. ,vol.7,no.3,pp. 19–20,Jul.2003. [51] “Rfc5389-sessiontraversalutilitiesfor(nat)(stun),”http://tools.ietf.org/html/rfc5389. [52] “Rfc5766-traversalusingrelaysaroundnat(turn):Relaye xtensionstosession traversalutilitiesfornat(stun),”http://tools.ietf.o rg/html/rfc5766. [53] “Rfc5245-interactiveconnectivityestablishment(ice): Amethodology fornetworkaddresstranslator(nat)traversalforoffer/a nswerprotocols,” http://tools.ietf.org/html/rfc5245. [54] “ejabberd-theerlangjabber/xmppdameon,”http://www.ej abberd.im/. [55] “Aboutlibjingle-googletalkfordevelopers,”https://developers.google.com/talk/libjingle/. 138

PAGE 139

[56] H.Jamjoom,“Virtualwire:systemsupportforlivemigrating virtualnetworks acrossclouds,”in Proceedingsofthe7thinternationalworkshoponVirtualizat ion technologiesindistributedcomputing ,ser.VTDC'13.NewYork,NY,USA:ACM, 2013,pp.21–22.[Online].Available: http://doi.acm.org/10.1145/2465829.2465838 [57] D.Williams,H.Jamjoom,andH.Weatherspoon,“Thexen-blank et:virtualizeonce, runeverywhere,”in Proceedingsofthe7thACMeuropeanconferenceonComputer Systems ,ser.EuroSys'12.NewYork,NY,USA:ACM,2012,pp.113–126. [Online].Available: http://doi.acm.org/10.1145/2168836.2168849 [58] “Openvpn-opensourcevpn,”http://openvpn.net/. [59] “Hamachi-instant,zerocongurationvpn,”http://secure.logmein.com/products/hamachi/vpn.asp. [60] “tincwiki,”http://www.tinc-vpn.org/. [61] “Vtun-virtualtunnelsovertcp/ipnetworks,”http://vtun. sourceforge.net/. [62] “n2n,”http://www.ntop.org/products/n2n/. [63] B.Ford,J.Strauss,C.Lesniewski-Laas,S.Rhea,F.Kaashoek, andR.Morris, “Persistentpersonalnamesforgloballyconnectedmobiled evices,”in Proceedings ofthe7thsymposiumonOperatingsystemsdesignandimpleme ntation ,ser.OSDI '06.Berkeley,CA,USA:USENIXAssociation,2006,pp.233–248.[Onl ine]. Available: http://dl.acm.org/citation.cfm?id=1298455.1298478 [64] A.Ganguly,A.Agrawal,P.O.Boykin,andR.Figueiredo,“Ipoverp 2p:enabling self-conguringvirtualipnetworksforgridcomputing,”i n Proceedingsofthe 20thinternationalconferenceonParallelanddistributed processing ,ser.IPDPS'06. Washington,DC,USA:IEEEComputerSociety,2006,pp.49–49.[Onl ine]. Available: http://dl.acm.org/citation.cfm?id=1898953.1898983 [65] “Opennetworkingfoundation,”https://www.opennetworki ng.org/. [66] D.Andersen,H.Balakrishnan,F.Kaashoek,andR.Morris,“Resi lientoverlay networks,”in ProceedingsoftheeighteenthACMsymposiumonOperatingsys tems principles ,ser.SOSP'01.NewYork,NY,USA:ACM,2001,pp.131–145.[Online ]. Available: http://doi.acm.org/10.1145/502034.502048 [67] “Socialvpn-afreeandopen-sourcep2pvpnthatconnectsyout oyourfriends,” http://socialvpn.org,2009. [68] “Importantconcepts-googletalkfordevelopers,”https://developers.google.com/talk/libjingle/import ant concepts. [69] “Turnserver-open-sourceturnserverimplementation,”http://turnserver.sourceforge.net/. 139

PAGE 140

[70] G.Fox,G.vonLaszewski,J.Diaz,K.Keahey,J.Fortes,R.Figu eiredo,S.Smallen, W.Smith,andA.Grimshaw, FutureGrid-arecongurabletestbedforCloud,HPC, andGridComputing ,ser.CRCComputationalScience.Chapman&Hall,04/2013 2013. [71] “Linuxcontainers,”https://linuxcontainers.org/. [72] “Networkx-highproductivitysoftwareforcomplexnetwork s,” http://networkx.lanl.gov/index.html. [73] D.Wolinsky,Y.Liu,P.Juste,G.Venkatasubramanian,andR. Figueiredo,“On thedesignofscalable,self-conguringvirtualnetworks, ”in HighPerformance ComputingNetworking,StorageandAnalysis,Proceedingsofth eConferenceon 2009,pp.1–12. [74] M.DongandL.Zhong,“Self-constructivehigh-ratesystemen ergymodeling forbattery-poweredmobilesystems,”in Proceedingsofthe9thinternational conferenceonMobilesystems,applications,andservices ,ser.MobiSys'11.New York,NY,USA:ACM,2011,pp.335–348.[Online].Available: http://doi.acm.org/10. 1145/1999995.2000027 [75] R.Cox,A.Muthitacharoen,andR.T.Morris,“Servingdnsusing apeer-to-peer lookupservice,”in InIPTPS ,2002. [76] M.Walsh,H.Balakrishnan,andS.Shenker,“Untanglingthewe bfromdns,”in NSDI'04:Proceedingsofthe1stconferenceonSymposiumonNetw orkedSystems DesignandImplementation .Berkeley,CA,USA:USENIXAssociation,2004,pp. 17–17. [77] K.Park,V.S.Pai,L.Peterson,andZ.Wang,“Codns:improving dnsperformance andreliabilityviacooperativelookups,”in OSDI'04:Proceedingsofthe6th conferenceonSymposiumonOpeartingSystemsDesign&Impleme ntation Berkeley,CA,USA:USENIXAssociation,2004,pp.14–14. [78] “Socialdns.netproject,” http://socialdns.net/ ,2010. [79] M.Allman,“Personalnamespaces.”ACMSIGCOMMHotnets2007,N ovember 2007. [80] H.Yu,M.Kaminsky,P.B.Gibbons,andA.Flaxman,“Sybilguard:d efendingagainst sybilattacksviasocialnetworks,”in Proceedingsofthe2006conferenceonApplications,technologies,architectures,andprotocolsforc omputercommunications ser.SIGCOMM'06.NewYork,NY,USA:ACM,2006,pp.267–278. [81] M.D.Bauer,“Securingdnsandbind,” LinuxJ. ,p.2,2000. [82] “Networkx-highproductivitysoftwareforcomplexnetwork s,” http://networkx.lanl. gov/ ,2010. 140

PAGE 141

[83] P.Mockapetris,“Domainnames-implementationandspecic ation,” http://tools.ietf.org/html/rfc1035,1987. [84] D.Liben-Nowell,J.Novak,R.Kumar,P.Raghavan,andA.Tomki ns,“Geographic routinginsocialnetworks.” ProceedingsoftheNationalAcademyofSciencesofthe UnitedStatesofAmerica ,vol.102,no.33,pp.11623–11628,August2005. [85] E.K.Bassett,J.P.John,A.Krishnamurthy,D.Wetherall,T.Anders on,and Y.Chawathe,“Towardsipgeolocationusingdelayandtopolo gymeasurements,” in IMC'06:Proceedingsofthe6thACMSIGCOMMconferenceonInter net measurement .NewYork,NY,USA:ACM,2006,pp.71–84. [86] M.Dischinger,A.Haeberlen,K.P.Gummadi,andS.Saroiu,“Char acterizing residentialbroadbandnetworks,”in IMC'07:Proceedingsofthe7thACMSIGCOMMconferenceonInternetmeasurement .NewYork,NY,USA:ACM,2007,pp. 43–56. [87] “Amazonelasticcomputecloud,” http://aws.amazon.com/ec2/ ,2008. [88] D.I.Wolinsky,P.St.Juste,P.O.Boykin,andR.Figueiredo,“T owardssocialprole basedoverlays,”UniversityofFloriday,Tech.Rep.,Feb20 10. [89] D.Sandler,A.Mislove,A.Post,andP.Druschel,“Feedtree:sha ringwebmicronews withpeer-to-peereventnotication,”in Proceedingsofthe4thinternational conferenceonPeer-to-PeerSystems ,ser.IPTPS'05.Berlin,Heidelberg: Springer-Verlag,2005,pp.141–151. [90] T.PerttandB.Englert,“Megaphone:Faulttolerant,scalab le,andtrustworthyp2p microblogging,”in InternetandWebApplicationsandServices(ICIW),2010Fifth InternationalConferenceon ,may2010,pp.469–477. [91] M.Castro,P.Druschel,A.-M.Kermarrec,andA.Rowstron,“Scri be:alarge-scale anddecentralizedapplication-levelmulticastinfrastru cture,” SelectedAreasin Communications,IEEEJournalon ,vol.20,no.8,pp.1489–1499,oct2002. [92] D.R.SandlerandD.S.Wallach,“Birdsofafethr:open,decentr alized micropublishing,”in Proceedingsofthe8thinternationalconferenceonPeerto-peersystems ,ser.IPTPS'09.Berkeley,CA,USA:USENIXAssociation,2009, pp.1–1. [93] A.Shakimov,H.Lim,R.Caceres,L.Cox,K.Li,D.Liu,andA.Varsha vsky, “Vis-a-vis:Privacy-preservingonlinesocialnetworkingvi avirtualindividualservers,” in CommunicationSystemsandNetworks(COMSNETS),2011ThirdInte rnational Conferenceon ,jan.2011,pp.1–10. [94] K.Graf,C.Gross,P.Mukherjee,A.Kovacevic,andR.Steinmetz ,“Lifesocial.kom: Ap2p-basedplatformforsecureonlinesocialnetworks,”in Peer-to-PeerComputing (P2P),2010IEEETenthInternationalConferenceon ,aug.2010,pp.1–2. 141

PAGE 142

[95] B.WongandS.Guha,“Quasar:aprobabilisticpublish-subsc ribesystemfor socialnetworks,”in Proceedingsofthe7thinternationalconferenceonPeer-topeer systems ,ser.IPTPS'08.Berkeley,CA,USA:USENIXAssociation,2008,pp.2–2. [96] R.ZhangandY.C.Hu,“Borg:ahybridprotocolforscalableapp lication-level multicastinpeer-to-peernetworks,”in Proceedingsofthe13thinternational workshoponNetworkandoperatingsystemssupportfordigit alaudioandvideo ser.NOSSDAV'03.NewYork,NY,USA:ACM,2003,pp.172–179. [97] T.Kusumoto,Y.Kunichika,J.Katto,andS.Okubo,“Tree-base dapplicationlayer multicastusingproactiveroutemaintenanceanditsimplem entation,”in Proceedings oftheACMworkshoponAdvancesinpeer-to-peermultimediast reaming ,ser. P2PMMS'05.NewYork,NY,USA:ACM,2005,pp.49–58. [98] A.Mislove,M.Marcon,K.P.Gummadi,P.Druschel,andB.Bhattac harjee, “Measurementandanalysisofonlinesocialnetworks,”in Proceedingsofthe5th ACM/USENIXInternetMeasurementConference(IMC'07) ,October2007. 142

PAGE 143

BIOGRAPHICALSKETCH PierreTonySt.JustewasborninHaitiontheislandofHispanio la.Attheage of13,hemigratedtotheUSwithhismomandyoungerbrother.O nceintheland ofopportunity,hewasencouragedbyhismothertopursuethe highestacademic achievements.HestartedcollegeinAugust2001attheUnive rsityofFloridaincomputer engineering.Hecompletedhisbachelor'sdegreein2005and hisMasterofScience in2007.HebeganhisdoctorateprograminAugust2007andjoi nedtheAdvanced ComputingandInformationSystemsLaboratoryundertheadvi sementofDr.Renato Figueiredo. HisresearchhasbeenmainlyfocusedonSocialVPN,apeer-to-pe erVPNthat integratesintosocialnetworkinginfrastructuretoprovi deaneasy-to-usetrustednetwork tocommunicatewithfriends.Hisresearchhasledhimtostud ypeer-to-peernetworks, networksecurity,virtualnetworking,cybersecurity,mob ileandcloudcomputing.Asa systemsresearch,Pierrehasdeployedexperimentswithhund redsofvirtualmachines oncloudinfrastructuressuchasAmazonEC2.Healsohasextens iveexperience launchingandmanagingservicesongloballydispersedtest bedssuchasPlanetLab.His workcurrentlyprovidesavirtualnetworkingsolutionthat addressesboththeneedsof inter-cloudnetworkingandmobiledevicecommunication. 143