ebook img

On the Design and Implementation of Structured P2P VPNs PDF

0.27 MB·English
Save to my drive
Quick download
Download
Most books are stored in the elastic cloud where traffic is expensive. For this reason, we have a limit on daily download.

Preview On the Design and Implementation of Structured P2P VPNs

On the Design and Implementation of Structured P2P VPNs DavidIsaacWolinsky∗,LintonAbraham•,KyungyongLee∗,YonggangLiu∗, JiangyanXu∗,P.OscarBoykin∗,RenatoFigueiredo∗ ∗UniversityofFlorida,•ClemsonUniversity Abstract The purpose of these VPNs is to connect large sets of machinesthroughvirtualrouterstoavirtualWANenvi- Centralized Virtual Private Networks (VPNs) when ronment. usedindistributedsystemshaveperformanceconstraints The architecture described in this paper addresses a asalltrafficmusttraversethroughacentralserver. Inre- usagescenariowhereparticipantsdesireVPNconnectiv- cent years, there has been a paradigm shift towards the itywithoutincurringthecomplexityormanagementcost useofP2PinVPNstoalleviatepressureplaceduponthe 0 of traditional VPNs. For instance, in a small/medium central server by allowing participants to communicate 1 business(SMB) environment,itisoftendesirableto in- 0 directlywitheachother,relegatingtheservertohandling terconnectdesktopsand serversacrossdistributed sites, 2 sessionmanagementandsupportingNATtraversalusing relayswhennecessary.Another,lesscommon,approach provideauthenticatedaccessandencryptedtraffictoen- n terprise networkedresources, and secure Internettraffic a usesunstructuredP2Psystemsto removeallcentraliza- J tionfromtheVPN.Theseapproachescurrentlylackthe frommobileusersatuntrustedlocations.Anotherexam- ple is collaborative academic environments linking in- 4 depth in security options provided by other VPN solu- 1 tions,andtheirscalabilityconstraintshavenotbeenwell dividuals belonging to a virtual organization spanning multipleinstitutions,wherecoordinatedconfigurationof studied. ] networkinfrastructureacrossdifferentsites is oftenim- I Inthispaper,weproposeandimplementanovelVPN N practical. Existing approachessuffer from one or more architecture,whichusesastructuredP2Psystemforpeer s. discovery,sessionmanagement,NATtraversal,andauto- limitationsthathindertheirapplicabilityinthesescenar- c nomicrelayselectionandacentralserverasapartially- ios: centralized approaches(e.g. OpenVPN [42]) incur [ the management cost of dedicated infrastructures. Al- automated public key infrastructure (PKI) via a user- ternativeP2P-basedapproaches(e.g. Hamachi[26])are 1 friendlywebinterface. Ourmodelalsoprovidesthefirst v designandimplementationofaP2PVPNwithfulltun- vulnerabletoman-in-the-middleattacksifsessionman- 5 agementishandledbyanexternalprovider;furthermore, nelingsupport,wherebyallnon-P2PbasedInternettraf- 7 they lack the support to tunnel traffic to Internet hosts fic routesthrougha trusted third party and doesso in a 5 throughtheVPN. 2 way that is more secure than existing full tunnel tech- AmongexistingVPNapproaches[42,26,30,19,10, . niques. To verifyour model, we evaluateour reference 1 36],thereisnotasinglesolutionthatprovidesthefollow- implementation by comparing it quantitatively to other 0 ingin an integratedmanner: nodependenceoncentral- 0 VPN technologies focusing on latency, bandwidth, and izedserver(s)forcreation,maintenanceandtear-downof 1 memoryusage.Wealsodiscusssomeofourexperiences : withdeveloping,maintaining,anddeployingaP2PVPN. VPN links; completelysecure fulltunnelingof Internet v traffic;decentralizedrelayselection,whereanypeercan i X potentiallybe a relay; and user-friendly,intuitivemem- r 1 Introduction bershipmanagementinaVPN. a Oursystemsupportsthewell-knownPKI-basedsecu- AVirtualPrivateNetwork(VPN)providestheillusionof rity modelto secure VPN links; for improvedusability, aLocalAreaNetwork(LAN)spanningawideareanet- we employ a semi-automated PKI managed through a work (WAN) infrastructure by creating secure and au- group-based web interface. The interface allows VPN thenticated communication links amongst participants. groupmanagerstoreviewapplicationsintothegroupand Common uses of VPNs include secure access to enter- removemalicioususers. Furthermore,we use the boot- prisenetworkresourcesfromremote/insecurelocations, strapping of a private P2P system off an existing pub- connectingdistributedresourcesfrommultiplesites,and licP2PsystemtocreateatrustedP2Psystemthatspans establishing virtual LANs for multiplayer video games onlythemembersofaVPNgroupprovidingsecureP2P over the Internet. In the context of this paper, we fo- routing and distributed hash table (DHT) storage. We cusonVPNsthatprovideconnectivityamongstindivid- explore the problem of providing full tunneling to P2P ual resourceseach configuredwith VPN software. Our VPNsandprovideaworkingsolutionthatsupportsmul- workissignificantlydifferentinscopefromapproaches tiplegatewaysinasingleVPN.Weprovidemechanisms that define VPNs “as the ‘emulation of a private Wide thatallowpeerstoestablish NATtunnelingtwo-hopre- AreaNetwork(WAN)facilityusingIPfacilities’(includ- laylinksbaseduponnodestability(uptime)andproxim- ing the public Internet or private IP backbones).” [20]. ity(latency)whendirectconnectivityisunavailable(e.g. 1 duetoNATtraversalconstraints).Themaincontribution 2.1 ClientVPNConfiguration ofthispaperisthedesignandevaluationofanovelstruc- In Figure 1, we abstract the common features of all turedP2PVPNoverlayarchitecture. Whilemanyofthe VPNs clients. Thekey componentsofa clientmachine individual components of our solution are not novel in are 1) client software that communicateswith the VPN and of themselves, the integration of these components overlay and 2) a virtual network (VN) device. During andtheirinteractionresultsinauniquesystem. initialization, the VPN software starts by authenticat- The rest of this paper is organized as follows. Sec- ing with an overlay or VPN agent. Then, optionally, it tion 2 gives an overview of current VPN technologies. queriestheagentforinformationaboutthenetwork,such Section 3 provides background on P2P systems. Sec- asthenetworkaddressspace,andfinallytheVNdevice tion4describesthetechniquesusedtocreatestructured is started enabling secure communication amongst par- P2PVPNs. InSection5,wepresentevaluationcompar- ticipants. ingoursystemwithotherVPNs. Ourexperiencedevel- oping, using, and debugging the system is discussed in Section6. Section7discussesrelatedworks,whileSec- tion8presentsconcludingremarks. 2 Virtual PrivateNetworks Thereexistmanydifferentflavorsofvirtualnetworking. Thispaperfocusesonthosethatareusedtocreateorex- tenda virtuallayer 3 network,of whichthere are many typesassummarizedinTable1. Abriefsurveyofpopu- larVPNscomprisingdifferentconfigurationsissumma- rized in Table 2. This section overviews core features of VPN designs, beginningwith client configuration of VPNs, followed by an analysis of differentVPN server configurationsashighlightedinTable1. Figure1: Atypical VPNclient. TheVPNusesaVN device tomake interaction over theVPNtransparent. Packets going Type Description toVPNdestinationsaredirectedtowardstheVNdevice,which Clients communicate through one interfaces the VPN client. The VPN client in turn sends and Centralized ormoreserverswhicharestatically receivespacketsoverthehostsphysicalnetworkdevice. configured Serversprovideauthentication,ses- There are many different mechanisms for communi- Centralized sion management, and optionally cating with an overlay agent. For quick setup, a sys- Servers / P2P relay traffic; peers may communi- temmayrequirenoauthenticationoruseasharedsecret Clients cate directly with each other via such as a key or password. Using accounts and pass- P2PlinksifNATtraversalsucceeds wordswithorwithoutasharedsecretprovidesindividu- No distinction between clients and alizedauthentication,allowinganadministratortoblock Decentralized servers; each member in the sys- allusersifthesharedsecretiscompromisedorindivid- Servers and temauthenticatesdirectlywitheach ualusersif theyactmaliciously. Forthestrongestlevel Clients other;linksbetweenmembersmust ofsecurity,eachclientcanbeconfiguredtohaveaunique beexplicitlydefined signedcertificatethatmakesbruteforceattacksverydif- No distinction between clients and ficult.Thetrade-offscomeintermsofusabilityandman- Unstructured servers; members either know the agement. While the use of signed certificates provides P2P entire network or use broadcast to better security than shared secrets, it can be more diffi- discoverroutesbetweeneachother cult to set up and use. In a system comprising of non- No distinction between clients and experts,thetypicalsetupincludestheuseofasharedse- servers;membersareusuallywithin cretandindividualuseraccounts,wherethesharedsecret Structured O(logN) hops of each other via a is includedwith the installation of the VPN application P2P greedy routing algorithm; use dis- whichisdistributedfromasecuredsite. tributeddatastorefordiscovery TocommunicateovertheVPNtransparently,asystem musthaveaVNdevicedriver,whichprovidesthemech- Table1:VPNClassifications anismstoinjectincomingpacketsandretrieveoutgoing packets from the networking stack, enabling the use of 2 commonnetworkAPIssuchasBerkeleySocketsallow- Most centralized VPNs implement full tunneling ing existing application to work over the VPN without through a routing rule swap, which makes the default modification. TherearemanydifferenttypesofVNde- gatewayanendpointintheVPNsubnetandtrafficforthe vices, thoughduetoourfocusonanopenplatform,we VPNserverisroutedexplicitlytotheLANgateway.For focus on TAP [24]. TAP allows the creation of one or example, in a typical home network, an Internet bound more Virtual Ethernet and / or IP devices and is avail- packetwillberetrievedattheVNdevice,encrypted,and able for almost all modern operating systems including senttotheVPNgatewayviatheLAN’sgateway. Atthe Windows,Linux,MacOS/X,BSD,andSolaris. ATAP VPN gateway, the packet is decrypted and delivered to devicepresentsitselfasacharacterdeviceprovidingread theInternet.AP2Psystemencounterstwochallengesin andwriteoperations.IncomingpacketsfromtheVNare supportingfulltunnels:1)P2Ptrafficmustnotberouted writtentotheTAPdeviceandthenetworkingstackinthe totheVPNgatewayand2)theremaybemorethanone OSdeliversthepackettotheappropriatesocket. Outgo- VPNgateway. Wefurtherdiscussthisissueandprovide ing packets from local sockets are read from the TAP solutionstothisprobleminSection4.3. device. 2.2 CentralizedVPNServers The VN device can be configured manually through OpenVPN is an open and well-documentedplatform static addressing or dynamically through dynamic host for deployingcentralized VPNs. We use it as the basis configuration process (DHCP) [11]. Setting the IP ad- for comparisonwith our approach, as it providesa rep- dress of the VN device causes the system to add a new resentationof featuresfoundin mostcentralizedVPNs. ruletotheroutingtablethatdirectsallpacketssenttothe CentralizedVPNsareresponsibleforauthenticationand VPN address space to be sent to the VN device. Pack- routingbetweenclients, providinga NAT to the servers etsarereadfromthetheTAPdevice,encryptedandsent local resources and Internet (full tunnel), and handling to the overlay via the VPN client. The overlay deliv- inter-servercommunication. ers the packet to another client or a server with a VN CentralVPNserversoperateatwell-knownendpoints stack enabled. Received packets are decrypted, veri- consisting of a hostname or IP address and a port. In fiedforauthenticity,andthenwrittentotheTAPdevice. a system containing multiple servers, a client attempt- In most cases, the IP layer header remains unchanged, ingtologinwillrandomlyattempttoconnecttooneof while VPN configuration determines how the Ethernet theserversuntilsuccessful,implementingasimpleload headerishandled. balance. Once connected, clients obtain an address in The described configuration so far creates what is theVPNaddressspace. Dependingonconfigurationthis known as a split tunnel: a VPN connection that han- willallowaclienttocommunicatewithotherclients,re- dles internal VPN traffic only and not Internet traffic. sources on the same network as the server, or Internet VPNs can also support full tunneling, which allows a hostsviatheVPN.Insuchsituations,itisimportantthat VPN client to securely forward all their Internet traffic theclientandserverbothauthenticatewitheachotherin throughaVPNrouter. Thisprovidesnetwork-layerpri- usingsomeformofchallengeresponseprotocol. vacyandauthenticationwhenauserisinaninsecureen- Allinter-clientcommunicationflowsthroughthecen- vironment,suchasanopenwirelessnetworkatacoffee tral server. In the defaultconfigurationof OpenVPN, a shop, by securely relaying all Internet traffic through a client encrypts a packet and sends it to the server. The trusted third party, the VPN gateway. Both models are serverreceivesthepacket,decryptsit,determineswhere illustratedinFigure2. torelayit, andthenencryptsandsendsthepackettoits destination. This modeldoes not preventa server from eavesdroppingonsuchcommunication. Whileasecond layer of encryption is possible through a shared secret, itrequiresout-of-bandcommunicationandislesssecure thanrelyingonaPKI. Tosupportfulltunnelingorallowtheclienttoaccess theserver’sresources,theservertoomustenableclient- like features by becoming a VPN endpoint with a VN device. Depending on the configuration, the server can Figure 2: A VPN setup expressing both full and split tunnel thenconfiguretrafficfromtheVPNtogothroughaNAT modes. Inbothmodes,packetsfortheserveraresentdirectly priortoroutingittotheLANand/orInternet. totheserver. Insplittunnelmode,Internetpacketsbypassthe OpenVPNallowsadistributionofservers,soastopro- VPNandarerouteddirectlytotheInternet.Infulltunnelmode, videfaulttoleranceandtoalesserdegreeloadbalancing. Internet packets are first routed to the VPN server / gateway, Serversmustbeconfiguredtoknowabouteachotherin andthentotheirInternetdestination. advance and need routing rules established to forward 3 Authentication PeerDiscov- VPNType NATTraversal Availability Method ery Certificates or Central Relay through OpenVPN[42] Centralized passwords with OpenSource server(s) server(s) acentralserver tinc[36] Decentralized PKI Broadcast Relaythroughmesh OpenSource CloudVPN[12] Decentralized PKI Broadcast Relaythroughmesh OpenSource limitedfree-use,limited Centralized Passwordatcen- Central NAT traversal and Hamachi[26] Non-Windows clients, P2P tralserver server centralizedrelay noprivaterelays Centralized Passwordatcen- Central NAT traversal, cen- Windows only, free- GBridge[25] P2P tralserver server tralizedrelay ware,noprivaterelays Centralized Passwordatcen- Central NAT traversal, no Mixed Open / Closed Wippien[30] P2P tralserver server relaysupport source Unstructured NAT traversal, de- N2N[10] Sharedsecret Broadcast OpenSource P2P centralizedrelay Unstructured No NAT traversal, P2PVPN[19] Sharedsecret Broadcast OpenSource P2P decentralizedrelay NAT traversal and Structured PKI or pre- DHT look IPOP relay through physi- OpenSource P2P exchangedkeys up callyclosepeers Table2:VPNComparison packets. Loadbalancingexistsonlyintheprocessofthe acts as a relay, if not, the two machines are unable to client randomly connecting to different servers and po- communicate. Oneconcernisthateach ofthese imple- tentially with a server refusing connection due to load. mentationsusestheirownsecurityprotocolsthatinvolve Thecurrentapproachlacksadistributedloadbalance. usingaservertoverifytheauthenticityandsetupsecure Two examples of systems that assist in distributing connectionsbetweenclients. Mostofthese projectsare loadin VPN systemsare tinc[36] andCloudVPN[12]. closed preventingusers from hosting their own authen- Unlike the decentralized P2P systems, these decentral- tication servers and relays. This model forces users to ized systems lack the ability to self-organize the VPN trust the third-party server to not eavesdrop or perform andrequireexplicitspecificationofwhichlinkstocreate. otherman-in-the-middleattacks. Noneoftheseprovide Thismeansthat,likeOpenVPN,thesesystemscansuffer supportforfulltunneling. VPNoutageswhennodesgooffline. Thedifferencebe- 2.4 P2PVPNClient/ServerRoles ingthatOpenVPNmakesitexplicitwhoisaserverand Unlike centralized systems, pure (or decentralized) who is not, whereas in tinc and CloudVPN anyone can P2P systems have no concept of dedicated servers, beaserveroraclient. InthetypicaltincandCloudVPN thoughitisentirelypossibletoaddreliabilitytothesys- setup, individual users share endpoints with each other tem by starting dedicatedinstances of the P2P VPN. In outof band and then place them in the VPN configura- these systems, all participantsare membersof a collec- tionfile. Duetothelackofself-configuration,members tive known as an overlay. Current generation P2P de- in the system will not replace links as members go of- centralizedVPNsuseunstructuredP2Pnetworks,where fline. therearenoguaranteesaboutdistanceandroutabilitybe- 2.3 CentralizedP2PVPNSystems tweenpeers. TwopopularexamplesofunstructuredP2P Hamachi [26] began the advent of centralized VPNs VPNsareN2N[10]andP2PVPN1[19].Asaresult,par- that went with the ambiguous moniker “P2P VPN”. In ticipants tend to be connected to a random distribution reality,thesesystemswouldbebestclassifiedascentral- of peers in the overlay. Finding a peer requires some izedVPNserverswithP2Pclients. Specifically,thena- formofbroadcasting,eitherannouncementsorsearches, ture of P2P in these [30, 25] types of systems provides to the entire overlay. While unstructured P2P systems directconnectivitybetweenclientsonceauthenticatedby have some scalability concerns, P2P systems in general a centralserver. While directconnectionisdesirable, it 1Duetothesimilarities between thenameP2PVPNandfocus of does not always happen due to firewalls or impenetra- thispaper,weuse“P2PVPN”toreferonlyto [19]and“P2PVPN”to ble NATs. When this happens, the central server either referexplicitlytoourapproach. 4 allowforserver-lesssystems. IntherealmofVPNs, all sorandamessageisroutedthroughitdestinedforthem, client VPNs are also servers with varying responsibili- dependingonthemessagetype,itmayeitherbelocally tiesdependingontheVPNapplication,aswepresentin consumed or thrown away, never arriving at its appro- Table2. priate destination. Thus having multiple peers on both Typically,decentralized,P2PVPNsbeginbyattempt- sides assist in stabilizing when the experiencing churn, ing to connect with well-known endpoints running the particularlywhenpeersleavewithoutwarning. P2P overlay software. A list of such end points can be Overlay shortcuts enable efficient routing in ring- maintainedbyoccasionallyqueryingtheoverlayforac- structuredP2Psystems. Thedifferentshortcutselection tive participantson public IP addressesand distributing methods include: maintaining large tables without us- the list with the application or some other out-of-band ingconnectionsandonlyverifyingusabilitywhenrout- mechanism. InthecaseofP2PVPN,thisinvolvescom- ing messages [34, 28], maintaininga connectionwith a municationwithoneormoreBitTorrenttrackerstofind peereverysetdistanceintheP2Paddressspace[37],or othermembersoftheP2PVPNgroup.N2N[10]requires usinglocationsdrawnfromaharmonicdistributioninthe knowledgeofanexistingpeerinthesystem. Itusesthis nodeaddressspace[27]. endpointtobootstrapmoreconnectionstootherpeersin thesystem,allowingtheapplicationtobeanactivepar- 4 Components ofa P2PVPN ticipantintheoverlayandpotentiallybeabootstrapcon- nectionforotherpeersattemptingtoconnect. Beforepresentingourcontributions,we firstreviewour currentworkasitprovidesthebasisforourP2PVPN.At theheartofoursystemliesaP2PsystemsimilartoSym- 3 Structured Peer-to-Peer Systems phony[27]namedBrunet[4]. Thespecificcomponents of the system that make it interesting for use in a P2P Structured P2P systems provide distributed look up services with guaranteed search time in O(logN) to VPNsysteminclude: STUNNATtraversal[33],system O(log N) time, in contrast to unstructured systems, stability when two nodes next to each other in address 2 space cannotdirectlyconnect[17], proximity-basedse- whichrelyonglobalknowledge/broadcasts,orstochastic lection of shortcuts [17], a distributed data store based techniquessuchasrandomwalks[5]. Someexamplesof upona DHT [18], and self-optimizingshortcutsto sup- structuredsystemscanbefoundin[34,37,27,28,31].In portsingle-hopconnectivitybetweenpeerswhenvirtual general,structuredsystemsareabletomaketheseguar- IPtrafficisdetectedbetweenendpoints[16]. anteesbyself-organizingastructuredtopologysuchasa WehaveimplementedaVNontopoftheBrunetP2P 2Dringorahypercube. librarywiththefollowingfeatures:self-configuring,low ThenodeID,drawnfromalargeaddressspace,must overhead use [41, 15], address configuration through a be unique to each peer, otherwise an address collision virtualDHCP server using DHT [41, 18], ability to be- occurs which can prevent nodes from participating in haveasaVNinterfaceorrouter[41],andsecureend-to- theoverlay. Furthermore,havingthenodeIDswelldis- end(EtE)andpoint-to-point(PtP)links. Ourimplemen- tributed assist in providing better scalability as many tation is portableto any system that supportsTap and a algorithms for selection of shortcuts depend on having C#run-time(e.g.Mono,.Net),andhasbeenusedingrid nodeIDsuniformlydistributedacrosstheentireaddress computingforover3years[14,39,38,40]. space.Asimplemechanismtoensurethisistohaveeach Whilethisframeworkprovidesthebasisforourdesign nodeuseacryptographicallystrongrandomnumbergen- andimplementation,wewillshowinthispaperthatour erator. AnothermechanismfordistributingnodeIDsin- approachgeneralizestootherstructuredP2Psystems. volves the use of a trusted third party to generate node IDsandcryptographicallysignthem[6]. 4.1 Automatingsecurityconfiguration AswithunstructuredP2Psystems,inorderforanin- Our VPN supports the PKI model, where a central- comingnodetoconnectwiththesystemitmustknowof ized CA signs all client certificates and clients can ver- at least one active participant. A list of nodes that are ifyeachotherwithoutCAinteractionbyusingtheCA’s running on public addresses should be maintained and public certificate. However, setting up, deploying, and distributedwith the application,availablethroughsome thenmaintainingsecuritycredentialscaneasilybecome out-of-band mechanism, or possibly using multicast to a non-negligibletask, especially for non-experts. Most findpools[34]. PKI-enabledVPNsystemsrequiretheuseofcommand- Dependingontheprotocol,anodemustbeconnected line utilities, setting up your own methods of securely toeithertheclosestneighborsmaller,larger,orboth.Op- deployingcertificatesandpolicingusers. Allthesetech- timizations for fault tolerance suggest that it should be niquescanbeappliedintheP2PVPNofthispaper,but between 2 to log(N) on both sides. If a peer does not our experiencewith realdeploymentsof oursystem in- knowtheaddressofitsimmediatepredecessororsucces- dicatesthatusabilityisveryimportant,whichiswhywe 5 soughtamodelwitheasytouserinterfaces. Inthissec- smallnetworks,thecostofsuchabroadcastmaybeneg- tion,wepresentoursolution,apartiallyautomatedPKI ligible, but as a network grows, such a broadcast may reliant on a redistributable group based web interface. becomeprohibitivelyexpensive. Although this does not preclude other methods of CA 4.2 BootstrappingPrivateOverlays interaction, our experiencehas shown that it providesa modelthatissatisfactoryformanyusecases. In P2P systems, distributed security may not provide Inordertoobtaincertificates,ausercreatesanaccount thesamelevelofsecurityascentralizedormanagedse- andjoinsagroupthroughaWebinterface,providingrel- curity. A starting point to secure an overlay is to use evantinformationastothereasonforjoiningthegroup. well-known security concepts such as PKI and SSL to Userscan alsocreate VPN groupsoftheir ownthrough encouragewideradoptionofP2Psystems. Oneproblem theinterface,ineffectbecomingtheadministratorofthe with this approachthoughis thatusers who want a pri- VPNgroup.OneormoregroupVPNadministratorscan vateoverlaymaynothavethe resources,i.e. publicad- verifythisinformationandapproveordenytheuserac- dresses, to hosttheir ownoverlays. To addressthis, we cessintothegroup. Ifauserisgrantedaccess, theyare suggestbootstrappingaprivateoverlayfromanexisting then able to download a configuration blob. The blob public overlay [7]. Communication within the private contains VPN network configuration and a shared key overlay is completely encrypted and authenticated with thatuniquelyidentifiestheuserandallowingthemtoau- onlymembersoftheVPNallowedaccess. tomaticallyretrievesignedcertificatesinthefuture. The In this approach, members of the VPN are the only userconfigurestheVPNclientwiththeblob.Uponstart- participantsoftheprivateoverlay,providingamodelthat ing,theVPNclientqueriesthegroupserverusingthein- is synergistic with the group VPN interface described formationintheblobtoauthenticatetheserveranditself earlier.ThispreventsmalicioususersoutsideoftheVPN to the server. After which, the user provides the group from attacking it, and facilitates the removal of misbe- server a certificate request containing the VPN client’s havingpeers,primarilyrootedinthefactthattheuseof node ID, which the server signs and returns. At which abroadcasttosignalacertificaterevocationiswithinthe point, the VPN client can connectto the VPN pooland scopeoftheprivateoverlay. communicatesecurelywithothersinthegroup. Itisim- The process for bootstrapping a private overlay is as perativethatanyoperationsthatinvolvetheexchanging follows.OncetheVPNsoftwarebegins,itstartsbycon- of secretinformation,such as the sharedsecret, be per- necting with the public overlay. It queries the public formed over a secure transport, such as HTTPS, which overlay’s DHT at the key “private:groupname”, where canbedonewithnouserintervention. groupnameistheGroupVPN’sname. Thevaluesstored Unlike decentralized systems that use shared secrets, at the key are the public overlay node IDs of the pri- in which the creator of the VPN becomes powerless to vateoverlaysactivemembers.ThejoiningVPNsoftware controlmalicioususers,aPKIenablesthecreatortoef- will attempt to form private overlay bootstrap connec- fectivelyremovemalicioususers. The methodsthatwe tionswithmembersofthislistusingthepublicoverlay. have incorporated include: use of a certificate revoca- During this process, both peers verify each other’s au- tion list (CRL) hosted on the groupserver, DHT events thenticityandformasecureconnection.Thisconnection requesting notification of peer removal from the group, is then used to bootstrap direct connections with mem- andbroadcastingtotheentireP2Psystemtherevocation bers of the private overlay. The reason why the public ofthepeer. overlaynodeIDsarestoredatthepublicoverlay’sDHT ACRLoffersanoutofbandmechanismfordistribut- key and for usingprivate overlaybootstrapconnections ing user revocations. The CRL assist in cases where a overthepublicoverlayistosupportNATtraversal. This malicious user can use common P2P attacks to prevent modelsupportsreusingBrunet’sunderlyingNATtraver- notificationofcertificaterevocationstransmittedviathe saltechniques.Asamemberofaprivateoverlay,aVPN overlay,asitissignificantlymoredifficulttopreventthe nodecanelectto store informationrelevantto the VPN retrievalofaCRL. intheprivateoverlay’sDHT,relegatingthepublicover- TheDHTmethodactsasaneventnotification.Upona lay for private overlay discovery. VPN traffic can then revocation,theCAretrievesthevaluesataDHTkeyspe- bekepttotheprivateoverlayonlyorthepublicoverlay cifictotherevokedpeer. ThevaluescontainnodeIDsof canbeusedforrelaying,whendirectconnectivityisnot nodeswhowanttoknowoftherevocation.Theproblem possible,thoughthishasnotbeenlookedintoyet. withaDHTisthatitcanbeeasilycompromisedifthey 4.3 FullTunnelingoverP2P havenotbeenimplementedwithsignificantmeasuresto Infulltunnelmode,alltraffictobothVPNandInter- protectagainstmaliciousness. nethostswiththeexceptionofVPN“control”messages Themostrudimentarymechanismisbroadcastingthe routeovertheVPN, asshowninFigure2. Inacentral- certificate revocation over the entire P2P overlay. In ized VPN, these “control”messagesconsistof commu- 6 nicationwiththeVPNserverandfulltunnelgateway.In side of the VPN address space are rejected, unless full a P2P VPN, “control” messages consists of communi- tunnelclientmodeisenabled. Ifitisenabled,theVPN cationbetweenUsingfulltunnelingensuresthatamali- softwarefindsaremotepeertoactasafulltunnelgate- cioususercannoteasilyeavesdropintowhatwouldoth- wayandthensendsthepackettotheremotepeer. erwisebepubliccommunicationbyforwardingallnon- VPNrelatedtrafficsecurelytoathirdpartywhoresides inamoretrustedenvironment. Therearetwokeycom- ponentsto this scheme, a gateway / server or traffic re- layerandaclientoratrafficforwarder. Inthefollowing sections,wepresentmethodsforimplementinggateways andclients. 4.3.1 TheGateway Figure3:ThecontentsofafulltunnelEthernetpacket.PNand VNaredefinedasphysicalandvirtualnetwork,respectively. Configuringamachineasagatewaycanbedonewith NAT software or using IPOP’s built-in NAT stack. For The pathway for packets coming from the overlay example, in Linux this is possible through masquerad- needs to support full tunneling. The source IP address inginiptables, whichautomaticallyhandlesforwarding willnotmatchtheVPNgatewaysIPbutwillbeanInter- packetsreceivedononeinterfacetothenexthopaswell netaddress. Thusthe VPN clientmustconfirmthatthe as receiving packets from the Internet and forwarding sourceisaVPNgateway,otherwisethepacketisthrown thembacktotheappropriateclient,transparentlytaking away. UponwritingapackettotheVNdevice,theuser careofNAT. applicationwillreceiveapacketfromtheInternet. Withagatewayintact,theVPNsoftwarecannowan- Thisleadstotwoissues: howtoselectthemachineto nouncethatitprovidesfulltunneling. Forthatpurpose, use as a gateway and how to configurea network stack we added an enable flag into the VPN configuration to toproperlyroutepacketsandnotdirectallpacketstothe specify that a machine is a full tunnel gateway. When VPNgateway. Ourmodelusesasimplemechanismfor theVPNsoftwarestarts,itwillautomaticallyappendit- determining which gateway to choose: query the DHT selftothelistofknowngatewaysfortheVPN groupin foralistofpotentialgateways,selectarandomonefrom theDHT. the list, and verify liveness via periodicping messages. TheonlyremainingdifferenceinVPNgatewayisthe Forhandlingfaults,wetakeapessimisticapproach,that state machine used in processing packets coming from is,ifaserverislost,wetakenoteofitandonlyquerythe theVPN.Ratherthanrejectingpacketsifthedestination DHTagainuponthenextoutgoingInternetpacket. isnotin theVPN subnet,theyareonlyrejectedifgate- Inthispaper,we focusonthesecondissue: handling waymodeisdisabled.Ifitisenabled,allInternetpackets P2P-routedpackets.InthecentralizedVPNcase,aclient arewrittentotheTAPdevicewiththedestinationEther- communicates directly with a single point in the VPN, netaddressbeingthatoftheTAPdevice. Theremaining which is knownaheadof time and can be implemented configurationisidenticaltoothermembersofthesystem byasimpleroutingruleswappriortostartingtheVPN. as packetsfrom the Internetto the client will automati- The same cannot be done for a P2P system. Due to callyhavetheclientsIPasthedestinationasaproductof thedynamic,self-configuringnatureofP2Psystems,en- theNAT. suringthatallP2Poverlaymessagesarerouteddirectly 4.3.2 TheClient becomes a non-trivial issue as there will be many such routes,mostofwhichwillnotbe knownaheadoftime. VPN Clients wishing to use full tunnelmust redirect IfweappliedthesamemodelusedbycentralizedVPNs, their default traffic to their VN device. In our VPN the client would end up routing both Internet and P2P model,weuseavirtualaddressforthepurposeofprovid- traffic through the gateway machine, creating a central ingdistributedVNservicesDHCPandDNS.Thissame pointoffailure. Wehaveconsideredtwoapproaches,as address can be used as the VPN gateway, which works outlinedbelow. fine because as shown in Figure 3, only the Ethernet headercontainsinformationaboutthegateway. Packets 4.3.3 TheClient–Approach1–AddingRoutes retrieved in the VPN software can then forward the In- Thefirstapproachissimilartothecentralizedversion: ternetpackettoanymachineintheVPN,providinggate- for each P2P link, we add an explicit rule in the rout- way services without changing IP or higher OSI layer ingtablesothatpacketsdestinedforthoseendpointsare changes. routeddirectlytothemviatheLAN’sdefaultgateway.In TheVPN’sstatemachinehastobeslightlymodifiedto ordertoensurethis,weaddedafeaturetothesockethan- handleoutgoingpacketsnotdestinedfora remoteVPN dlingcodethatwould,priortothefirstoutgoingpacket, end point. Incomingpackets destined for a subnet out- indirectlyaddaroutingruletodirectpacketsforthere- 7 mote node’s public address to the LAN gateway. The avoidingtheVPNclient. Thecostofpassingallpackets rule would remain in effect until the VPN closed down through the VPN application is negligible, as shown in orthelinkwasclosed. Thismodelrequiresuniquecode Section 5.4, since they are destined for the wide area, foreachOSplatform;thoughsupportingLinuxandWin- wherethetimetotraversethenetworkwillbeordersof dows was quite trivial. Because outgoing packets bear magnitudelargerthanpassingthroughtheVPN’spacket the source address of the physical network, incoming processor. AddinganEthernetwritertotheP2Psystem packetswillbedeliverednormally. creates an unclean abstraction as a VPN portion of the This method has two major shortcomings. Common systemnowbecomeslibrarydependentandreducesVPN toallVPNsthatemploythestandardrouteswitchtech- softwareportability. nique, all communication, not just VPN, is routed di- 4.4 AutonomicRelays rectlytotheserverinsecurely. SowhiletheVPNtraffic When NAT traversal using STUN [33] fails or there is mostlikely encrypted,a websitehostedby theserver are other connectivity issues some P2P VPNs [26, 25] mightnotbe. AnotherissuethatarisesintheP2Pcaseis supportrelaying,similar to TraversalUsing Relay NAT thatmalicioususers cansend spoofedinitiation packets (TURN) [32] provided by a managed relay infrastruc- whichwilladdextraroutestotheroutingtable,resulting ture. Centralized and decentralizedVPNs do notsuffer in a similar situation as the first, unencrypted commu- fromthisproblemasalltrafficpassesthroughthecentral nication visible to eavesdroppers. This led to a second server or managed links. To address the management approachdescribedbelow. andoverheadconcernsinthesesystems,weproposethe 4.3.4 TheClient–Approach2–EthernetFrames useofdistributed,autonomicrelayingsystembasedupon previouswork[17,29]. Ourpreviousworkinvolvedthe Thissolutionattemptstosolvetheproblemintroduced useoftriangularroutingthatallowedpeersnexttoeach by the first solution, removing any potential for eaves- other in the node ID space to communicate despite be- dropping. In this solution all Internet packets with no ing unableto communicatedirectly becauseof firewall, exceptionaredirectedtotheVNdevice. TheVNisthen NAT,orInternetfragmentationissues. responsible for filtering P2P traffic, encapsulating them Theprocessforforminglocalrelaysor”tunnels”[17] intoEthernetpackets,andsendingtotheLAN’sgateway. begins with two nodes discovering each other via ex- In the VPN application,IncomingIP packets’source isting peers and determining the need to be connected. ports are compared to VPN application’s source ports. If a direct connection attempt fails, the peers exchange Uponamatch,theVPNapplicationmustdirectittothe neighbor sets through the overlay. Upon receiving this LAN’sgateway. Thethreestepsinvolvedinthisprocess list,thetwopeersusetheoverlapintheneighborsetsto are1)translatingthesourceIPaddresstomatchthephys- formatwo-hopconnection. Inthiswork,wefurtherex- icalEthernet’sIPaddress,2)encapsulatingtheIPpacket tendthismodeltosupportcaseswhennodesdonothave inanEthernetpacketwhosesourceisarandomaddress anoverlapset. Thisinvolveshavingthepeersconnectto as described in [41] and destination is the LAN’s gate- eachother’sneighborsetproactivelycreatingoverlap,as way,and3)sendingthepacketviathephysicalEthernet representedinFigure4. device. TheIPswapisrequiredorthegatewaywillnot Additionally, we added the feature to exchange arbi- routethepacketproperly. TheissueofsendingtheEth- traryinformationalongwiththeneighborlist. Sofarwe ernetpacketisnottrivialasWindowslackssupportthis have implemented systems that pass information about operation.Ourplatformindependentsolutionusesasec- nodestability(measuredbytheageofaconnection)and ondTAPdevicebridgedtothephysicalEthernetdevice, proximity (based upon ping latency to neighbors). Ad- allowing Ethernet packets to be sent indirectly through ditionally,whenoverlapchanges,wemakeitoptionalto the Ethernet device via the TAP device. This solution select to use only a subset of the overlap, thus only the currently only works for UDP packets, because all in- fastestormoststableoverlapisusedwithmanymorein comingpackets will be directed towardsthe bridgeand reserve. notthefakedEthernetaddress. TCPpacketswillsenda Toverifytheusefulnessoftwo-hopoveroverlayrout- TCPresetinthisenvironment.Allotherpacketsenterthe ing, we performedexperimentsand share the results in systemsameasbefore.Thismethodhasbeenverifiedto Section5.1. Inalivesystem,weverifytheaccuracyand work on both Linux and Windows using OS dependent usefulnessofourlatency-basedrelayselectionalgorithm TAPdevicesandbridgeutilities. inSection5.2. While this method effectively resolves the lingering problemofensuringthatallpacketsinafulltunnelwill be secure, it raises a couple of issues 1) could the ef- 5 EvaluationofVPN Models fect of having all packets traverse the VPN application beprohibitivelyexpensiveand2)whynothavetheP2P In this section, we evaluate our proposed P2P VPN as applicationwriteLANdestinedEthernetpacketsdirectly described in Section 4 implementing the features into 8 Then this pathway is used as a two-hop relay between sourceandnode. Weonlylookattwooverlayhopsand more,asasinglehopwouldnotnecessarilybenefitfrom theworkandwouldbethecauseofatriangularinequal- ity.Thesimulationswereperformedonadistributedgrid platform,Archer[14],thatusesIPOPforitsvirtualnet- workingcomponent. Figure4: Creatingrelaysacrossthenodeaddressspace,when direct connectivity is not possible. Two members, 0000 and ABCD, desire a direct connection but are unable to directly connect, perhaps due to NATs or firewalls. They exchange neighborinformationthroughtheoverlayandconnecttooneof Figure5: Acomparisonoftheaverageall-to-alloverlayrout- eachother’sneighbors, creatinganoverlap. Theoverlapthen ing, two-hop relay, and direct connection latency in a Struc- becomesarelaypath(representedbydashedlines),improving turedP2Penvironment,Brunet,usingtheKingdataset. performanceoverroutingacrosstheentireoverlay. Our results are presentedin Figure 5. We performed IPOP [41] and Brunet [4]. We present the advantage the tests for varying network sizes. We began our tests ofusingrelaysoveroverlayroutingwhenNATtraversal at 25, because network sizes around 20 and under tend doesnotwork.Thenweexaminetheeffectsofusingdif- to be fully connected due to the connectivity require- ferentrelayselectionmechanisms. Afterwards,weeval- ments of the system. It is not until the network size uate the system overheadsof OpenVPN, Hamachi, and expandspast100andtowards200nodesthatrelaysbe- ourP2PVPNtodeterminetheOSresourcecostsandthe comesignificantlybeneficial. At100nodes,thereisap- cost of each in a distributed environment. Finally, we proximatelya54%performanceincrease,whereasat200 presenta quantitativecomparisonofourtwo fulltunnel thereis an87%increaseandit appearsto growpropor- models. tionately to the size of the pool. The key take away is 5.1 MotivationforRelaysintheOverlay thatlatency-boundapplicationsusingareasonablysized overlaywouldsignificantlybenefitfromtheuseoftwo- Thepurposeofthisexperimentistoquantifytheper- hoprelays. formancebenefits of autonomicrelays. For this experi- mentweusetheMITKingdataset[22],adatasetcon- 5.2 ComparingRelaySelection tainingall-to-alllatenciesbetween1,740well-distributed In this experiment, we share our experience of test- Internethosts. Wereviewedmanydifferentsizesofnet- ingtheuseoflatency-awarerelaysusingourpublicP2P works up to 1,740 nodes, evaluating each network size poolrunningonPlanet-LabaswellasHamachi-Freeand 100 times. Our experiments were executed by running Hamachi-Prorelays. DuetoHamachinotsupportingre- the VPN software in simulated mode, which reuses the lays in Linux, this experiment was performed in Win- code base of IPOP to faithfullyimplementits function- dowsVista 64-bit. The testing platformconsistsof two ality, but using event-drivensimulated times to emulate virtual machine located on the same host with a fire- WAN latencies in a LAN environment. Once at steady wall preventing them from establishing direct connec- state,wethencalculatetheaverageall-to-alllatencyfor tions. All experiments were repeated 5 times using a allmessagesthatwouldhavetakentwooverlayhopsor clean configuration each time. In Hamachi, this meant more,theaverageofourlowlatencyrelaymodel,andthe thattheserverwouldneedtore-evaluateNATtraversing averageofsinglehopcommunication.Inthelowlatency capabilities and the optimal relay to use. In IPOP, this relaymodel,eachdestinationnodeformaconnectionto meantthattheVPNswouldgenerateanewnodeIDand the source node’sphysically closest peer as determined becomepeerswithdifferentmembersoftheoverlay.Our via latency (in a live system by application level ping). resultsarepresentedinTable3. 9 Latency Bandwidth for results that provide interesting data and summarize therestinthetext. (ms) stdev Kbit/s stdev Memory, for the most part, exhibitedan intuitive be- Hamachi-Free 60.8 2.54 40.2 0.87 havior: for each additional connection there was more Hamachi-Pro 60.2 1.68 1000 1.29 memoryused.TheOpenVPNcontrolclientshowedneg- Latency-aware 58.1 35.5 2245 1080 ligible additional memory usage for additional nodes, though the server showed a linear increment, around 1 Table3:Resultsoftheevaluationcomparinglatencyandband- MB, for each additional client in the system, while ac- width of Hamachi relays and IPOP latency-aware autonomic relayselection. tivityhadnegligibleeffectontheresults. Hamachihada baselineofalessthan1MBandlikeOpenVPN,eachad- ditionalclientinthesystemhadalineareffectonmem- ory, on the order of 4 KB, there was no change based As Hamachi was started and figured out that NAT upon activity. The effect of additional inactive nodes traversal was not possible, it began using multiple dif- in an IPOP network had negligible effect on memory, ferent relays as evident by several different ping times. unlike Hamachi and OpenVPN. The only time IPOP’s EventuallyHamachi settled on a relay server and it ap- memoryconsumptionincreasedwasduringactivityand pearedtobethesameoneeverytime,forbothHamachi- itscaledata200KBperadditionalnode. Free and Hamachi-Pro. The only difference between Hamachi-ProandHamachi-FreeisthatinProthereisa bandwidthcap of approximately1 Mbit/s whereasFree islimitedto40Kbit/s. TheP2PsystemIPOPusedhasnodesbothonPlanet- Lab but also dedicated systems for Archer [14]. These machinesareatUniversitiesandthushaveahighband- widthandlowlatencyconnectiontothetestingsite. As witnessedbytheresults,itappearsthatinmostifnotall theseexperimentspeershadalowlatencyconnectionto a Universitycomputeresourceandit was chosenahead ofPlanet-Lab. Thetwoapparenttakeawaysare1)thebenefitofbeing abletodeployyourownrelayserversandtoreusecom- putenodesasrelaysystemsand2)asournetworkgrows, Figure 6: Comparison of bandwidth costs for member activ- wetoomayneedtoimplementsomeformofbandwidth ityversusnetworksize. Asstatedinthetext,Hamachi limits limitatrelaynodes. thesystemtonetworksizesof16,sotoestimatetheHamachi bandwidthweusedthefollowingformulausingalinearregres- 5.3 ComparingSystemOverheads sionmodelbaseduponourdatasets:.049+.002KB/s∗N+ In this experiment, we attempt to understand the .02KB/s∗A,.049thebandwidthinanetworksizeof0,i.e., boundsimposedbyOpenVPN,Hamachi,andIPOP.We keep-aliveswiththecentralserver,Nisthenetworksize,and used Amazon EC2 [2] to dynamically create various Aistheactivelinks. sized networks ranging from 1 to 129 with one client used as the control. In the bootstrap phase, the con- In Figures 6, we present the bandwidth results for trol machine initiates communication with a subset of clientnetworksizesof128. Ourevaluationscaledfrom the remaining clients in the VPN. Once the system has havingthecontrolcommunicatewith0to128clientsex- warmed,thecontrolcontinuespingingthissubsetevery ponentially,thoughasmentionedalready,Hamachionly 15 seconds for the next 10 minutes. We capture bytes supportsnetworksizesof16,soweusedalinearregres- transmitted into and out of the system, as well as the sion to extrapolate the bandwidth results. The results memorysize of the VPN applicationat the end of each aresomewhatpredictableasBrunet,IPOP’sP2Pinfras- stage. Aswetestthevaryingnetworksizes,webeginby tructure,primarilyusesUDPconnectionsandthusmust communicatingwith 0peersandexponentiallyincrease maintain application layer connections and NAT map- theamount(powersoftwo)untilthecontroliscommu- pings. ItisnotobviousthatHamachiisdoingthesame, nicatingwithallmembersoftheVPN.Fortheseevalua- whichmaybeduetothefactthatthepeersallhavepub- tions,weusedalicensedversionofHamachi,butdueto licIPaddresses. Infact,Hamachi’sbehaviorappearsto veryrecentchangesinHamachi,theLinuxclientwillnot besimilartothatofOpenVPN.Additionally,OpenVPN supportnetworkslargerthan16. Duetoamountofdata doesnotneedtomaintainNATmappingsastheservers collected and space limitations, we only presentfigures are location on public addresses, thus a client does not 10

See more

The list of books you might like

Most books are stored in the elastic cloud where traffic is expensive. For this reason, we have a limit on daily download.