DOCSLIB.ORG

On the Design of Autonomic, Decentralized Vpns

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
On the Design of Autonomic, Decentralized Vpns On the Design of Autonomic, Decentralized VPNs David Isaac Wolinsky, Kyungyong Lee, P. Oscar Boykin, Renato Figueiredo University of Florida Abstract—Decentralized and P2P (peer-to-peer) VPNs (virtual whereas existing decentralized solutions require manual con- private networks) have recently become quite popular for con- figuration of links between peers, which is beyond the scope necting users in small to medium collaborative environments, of Archer’s target users. Current P2P VPN approaches either such as academia, businesses, and homes. In the realm of VPNs, there exist centralized, decentralized, and P2P solutions. Central- lack scalability or proper security components to be useful for ized systems require a single entity to provide and manage VPN VPN approaches. server(s); decentralized approaches allow more than one entity to We began our original foray into user-friendly VPN ap- share the management responsibility for the VPN infrastructure, proaches with IPOP [2]. Previous work on IPOP focused on while existing P2P approaches rely on a centralized infrastructure the routing mechanisms and address allocation with multiple but allow users to bypass it to form direct low-latency, high- throughput links between peers. In this paper, we describe a virtual networks (VNs) sharing a single P2P overlay. Though novel VPN architecture that can claim to be both decentralized a shared has significant drawbacks as misconfigured or ma- and P2P, using methods that lower the entry barrier for VPN licious peers could disable the entire overlay, rendering all deployment compared to other VPN approaches. Our solution VPNs useless, and the system would have to be recreated as extends existing work on IP-over-P2P (IPOP) overlay networks to there exists no methods to remove the peer from the overlay. address challenges of configuration, management, bootstrapping, and security. We present the first implementation and analysis Without a shared overlay, each VPN would need to deploy of a P2P system secured by DTLS (datagram transport layer a P2P infrastructure and security system prior to the VPN security) along with decentralized techniques for revoking user system, at which point, users may reconsider the P2P approach access. and prefer more traditional centralized approaches. To make an easy-to-use, fully decentralized P2P VPN, we I. INTRODUCTION extend the IPOP concept to support bootstrapping from public A Virtual Private Network (VPN) provides the illusion of infrastructures and overlays into private P2P overlays whose a local area network (LAN) spanning a wide area network membership is limited to an individual VPN user base. Our (WAN) by creating secure1 communication links amongst work is based upon Castro et al. [3], suggesting that a single participants. Common uses of VPNs include secure access to overlay can be used to bootstrap service overlays. We present enterprise network resources from remote/insecure locations, a practical implementation and evaluation of this concept. connecting distributed resources from multiple sites, and estab- We then consider security in the overlay and present the lishing virtual LANs for multiplayer video games and media first implementation and evaluation of an overlay with secure sharing over the Internet. communiation both between end points in the P2P overlay The architecture described in this paper addresses usage sce- (e.g. VPN nodes) as well as between nodes connected by narios where VPNs are desired but complexity in deployment overlay edges. Security requires a means for peer revocation; and management limits their applicability. These include col- however, current revocation techniques rely on centralized laborative academic environments linking individuals spanning systems such as certificate revocation lists (CRLs). Our pro- multiple institutions, where coordinated configuration of net- posed approach allows revocation using scalable techniques work infrastructure across different sites is often impractical. provided by the P2P overlay itself. We call the completed Similarly, small/medium business (SMB) environments often system and the interface used to administrate it GroupVPN, desire the ability to securely connect desktops and servers a novel decentralized P2P VPN. across distributed sites without incurring the complexity or The rest of this paper is organized as follows. IPOP along management costs of traditional VPNs. Such a VPN could P2P overlays are introduced in Section II. Throughout the be used to enable extended families to share media among paper, there are two techniques used to evaluate our ap- themselves, such as family videos and pictures, where existing proaches, simulation and real system deployments, these are VPNs may be too complicated and where hosting by central- described in Section III. Section IV describes our techniques ized service may be undesirable for privacy reasons. that allow users to create their own private overlays from The model of a VPN for collaboration considered in this pa- a shared public overlay in spit of NATs. Use of security per is motivated from our Archer [1] project. Archer provides protocols has been assumed in many P2P works though a dynamic and decentralized Grid environment for computer without consideration of implementation and overheads, we architecture researchers to share and access voluntary compute investigate implementation issues and overheads of security cycles with each other. Use of centralized systems would in P2P with emphasis on P2P VPNs in Section V. Without limit the scope of Archer and require dedicated administration, revocation, use of security is limited, in decentralized systems, use of centralized revocation methods do not work, we present 1 For the remainder of this paper, unless explicitly stated otherwise, security novel mechanisms for decentralized revocation in Section VI. implies encryption and mutual authentication between peers. The complete system, GroupVPN, is presented in Section VII. punching [7]. When performing hole punching, peers first Section VIII compares and contrasts our work with related obtain mappings of their private IP address and port to their work. Section IX concludes the paper. public IP address and port and then exchange them over a shared medium, in this case the P2P overlay. The peers attempt II. BACKGROUND to simultaneously form connections with each other, tricking This section describes the core organization of IPOP, a struc- NATs and firewalls into allowing inbound connections, be- tured P2P virtual network, including background on structured cause the NAT believed an outbound flow already exists. In overlays, address allocation and discovery, and connectivity. case peers cannot establish direct connectivity, messages can A. P2P Overlays be relayed through the P2P overlay to each other, though with added latency and reduced throughput. The type of P2P overlay chosen for a VPN has an effect This approach enables peers behind NATs and firewalls to on how easy the VPN is to program, deploy, and secure, seamlessly connect to each other, without requiring peers to on its efficiency, and on its scalability. The two primary host their own bootstrap servers. If a peer were to host their infrastructures for P2P overlays are unstructured and structured own bootstrap servers, they first need a public IP address and systems. Unstructured systems use mechanisms such as global bind the application to a port on that system. At which point, knowledge, broadcasts, or stochastic techniques [4] to search they could share the IP, port pair with other peers in the VPN. the overlay. As the system grows, maintaining and searching However, if they were to go offline or their IP address changes this state may not scale. Alternatively, structured approaches the P2P infrastructure, new users would be unable to join. provide guaranteed search times typically with a lower bound ´ÐÓ Æ µ of Ç , where N is the size of the network. In terms of C. Network Configuration complexity, for small systems, unstructured systems may be In the context of VPNs, structured overlays can handle easier to implement, but as the system grows it may become organization of the network space, address allocation and inefficient. discovery, decentrally through the use of a DHT. Approaches IPOP uses a structured P2P framework named Brunet [5], along these lines have been proposed in [8], [9]. Membership which is based upon Symphony [6], a one-dimensional ring in the VPN includes a matching membership in the structured with a harmonic distribution of shortcuts to far nodes. Struc- overlay, thus all VPN peers have a P2P address. To address tured systems are able to provide bounds on routing and the challenges of having multiple VPNs in the same over- lookup operations by self-organizing into well-defined topolo- lay, each IPOP group has its own namespace, reducing the gies, such as a one-dimensional ring or a hypercube. Links in likelihood of overlap. To enable scalable and decentralized the overlay can be made to guarantee efficient lookup and/or address allocation and discovery, peers store mappings of routing times (e.g. Brunet automatically creates links between IP address to P2P address into the DHT, typically of the ´ · ÁÈ µ È ¾È Ö ×× peers that communicate often to achieve efficiency in IP-over- form × . Thus a peer P2P communication). attempting to allocate an address will insert this (key, value) A key component of most structured overlays is support pair into the overlay. The first peer to do this will be the owner for decentralized storage/retrieval of information such as a of the IP address allocation. Therefore the DHT must support distributed hash table (DHT). The DHT builds upon the atomic writes. existence of a P2P address space. All peers in a structured Mechanisms to self-configure the IP address and network system have a unique, uniformly distributed P2P address. A parameters of the local system can be provided by DHCP (de- DHT maps look up values or keys (usually by a hashing centralized host configuration protocol), manually configuring function) into the P2P address space. While there are various the IP address, or the VPN hooking into O/S APIs.
Load more

Recommended publications
  • Enabling TPM Based System Security Features
    Enabling TPM based system security features Andreas Fuchs <[email protected]> Who am I ? ● 13 year on/off TPMs ● Fraunhofer SIT: Trustworthy Platforms ● TCG-member: TPM Software Stack WG ● Maintainer – tpm2-tss: The libraries – tpm2-tss-engine: The openssl engine – tpm2-totp: Computer-to-user attestation (mjg’s tpm-totp reimplemented for 2.0) 2 The hardware stack ● Trusted Platform Module (TPM) 2.0 – Smartcard-like capabilities but soldered in – Remote Attestation capabilities – As separate chip (LPC, SPI, I²C) – In Southbridge / Firmware – Via TEEs/TrustZone, etc – Thanks to Windows-Logos in every PC ● CPU – OS, TSS 2.0, where the fun is... 3 The TPM Software Stack 2.0 ● Kernel exposes /dev/tpm0 with byte buffers ● tpm2-tss is like the mesa of TCG specs ● TCG specifications: – TPM spec for functionality – TSS spec for software API ● tpm2-tss implements the glue ● Then comes core module / application integration – Think GDK, but OpenSSL – Think godot, but pkcs11 – Think wayland, but cryptsetup 4 The TSS APIs System API (sys) Enhanced SYS (esys) Feature API (FAPI) • 1:1 to TPM2 cmds • Automate crypto for • Spec in draft form HMAC / encrypted • TBimplemented • Cmd / Rsp sessions • No custom typedefs U serialization • Dynamic TCTI • JSON interfaces s • No file I/O loading • Provides Policy e • No crypto • Memory allocations language r • No heap / malloc • No file I/O • Provides keystore S p TPM Command Transmission Interface (tss2-tcti) p a Abstract command / response mechanism, • No crypto, heap, file I/O a Decouple APIs
    [Show full text]
  • Master Thesis
    Master's Programme in Computer Network Engineering, 60 credits MASTER Connect street light control devices in a secure network THESIS Andreas Kostoulas, Efstathios Lykouropoulos, Zainab Jumaa Network security, 15 credits Halmstad 2015-02-16 “Connect street light control devices in a secure network” Master’s Thesis in Computer Network engineering 2014 Authors: Andreas Kostoulas, Efstathios Lykouropoulos, Zainab Jumaa Supervisor: Alexey Vinel Examiner: Tony Larsson Preface This thesis is submitted in partial fulfilment of the requirements for a Master’s Degree in Computer Network Engineering at the Department of Information Science - Computer and Electrical Engineering, at University of Halmstad, Sweden. The research - implementation described herein was conducted under the supervision of Professor Alexey Vinel and in cooperation with Greinon engineering. This was a challenging trip with both ups and downs but accompanied by an extend team of experts, always willing to coach, sponsor, help and motivate us. For this we would like to thank them. We would like to thank our parents and family for their financial and motivational support, although distance between us was more than 1500 kilometres. Last but not least we would like to thank our fellow researchers and friends on our department for useful discussions, comments, suggestions, thoughts and also creative and fun moments we spend together. i Abstract Wireless communications is a constantly progressing technology in network engineering society, creating an environment full of opportunities that are targeting in financial growth, quality of life and humans prosperity. Wireless security is the science that has as a goal to provide safe data communication between authorized users and prevent unauthorized users from gaining access, deny access, damage or counterfeit data in a wireless environment.
    [Show full text]
  • N2N: a Layer Two Peer-To-Peer VPN
    N2N: A Layer Two Peer-to-Peer VPN Luca Deri1, Richard Andrews2 ntop.org, Pisa, Italy1 Symstream Technologies, Melbourne, Australia2 {deri, andrews}@ntop.org Abstract. The Internet was originally designed as a flat data network delivering a multitude of protocols and services between equal peers. Currently, after an explosive growth fostered by enormous and heterogeneous economic interests, it has become a constrained network severely enforcing client-server communication where addressing plans, packet routing, security policies and users’ reachability are almost entirely managed and limited by access providers. From the user’s perspective, the Internet is not an open transport system, but rather a telephony-like communication medium for content consumption. This paper describes the design and implementation of a new type of peer-to- peer virtual private network that can allow users to overcome some of these limitations. N2N users can create and manage their own secure and geographically distributed overlay network without the need for central administration, typical of most virtual private network systems. Keywords: Virtual private network, peer-to-peer, network overlay. 1. Motivation and Scope of Work Irony pervades many pages of history, and computing history is no exception. Once personal computing had won the market battle against mainframe-based computing, the commercial evolution of the Internet in the nineties stepped the computing world back to a substantially rigid client-server scheme. While it is true that the today’s Internet serves as a good transport system for supplying a plethora of data interchange services, virtually all of them are delivered by a client-server model, whether they are centralised or distributed, pay-per-use or virtually free [1].
    [Show full text]
  • NAT Traversal About
    NAT Traversal About Some difficulties have been encountered with devices that have poor NAT support. FreeSWITCH goes to great lengths to repair broken NAT support in phones and gateway devices. In order to aid FreeSWITCH in traversing NAT please see the External profile page. Some routers offer an Application Layer Gateway feature which can prevent FreeSWITCH NAT traversal from working. See the ALG page for more information, including how to disable it. Using STUN to aid in NAT Traversal STUN is a method to allow an end host (i.e. phone) to discover its public IP address if it is located behind a NAT . Using this method requires a STUN server on the public internet and a client on the phone. The phone's STUN client queries the STUN server for it's own public IP and transmits the information it has received in it's connection information in the SIP packets it sends to the SIP server. Enable and configure STUN settings on your phone in order correctly to report your phone's contact information to FreeSWITCH when registering. Unfortunately, not all phones have a properly working STUN client. STUN servers This site contains a list of public STUN servers: https://gist.github.com/zziuni/3741933 stun.freeswitch.org is never guaranteed to be up and running so use it in production at your own risk. There are several open source projects to run your own STUN server, e.g. STUNTMAN Using FreeSWITCH built-in methods to aid in NAT Traversal nat-options-ping This parameter causes FreeSWITCH to regularly (every 20 - 40s) send an OPTIONS packet to NATed registered endpoints in order to keep the port on the clients firewall open.
    [Show full text]
  • NAT and NAT Traversal Lecturer: Andreas Müller [email protected]
    NAT and NAT Traversal lecturer: Andreas Müller [email protected] NetworkIN2097 - MasterSecurity, Course WS 2008/09, Computer Chapter Networks, 9 WS 2009/2010 39 NAT: Network Address Translation Problem: shortage of IPv4 addresses . more and more devices . only 32bit address field Idea: local network uses just one IP address as far as outside world is concerned: . range of addresses not needed from ISP: just one IP address for all devices . can change addresses of devices in local network without notifying outside world . can change ISP without changing addresses of devices in local network . devices inside local net not explicitly addressable, visible by outside world (a security plus). NetworkIN2097 - MasterSecurity, Course WS 2008/09, Computer Chapter Networks, 9 WS 2009/2010 40 NAT: Network Address (and Port) Translation rest of local network Internet (e.g., home network) 10.0.0/24 10.0.0.1 10.0.0.4 10.0.0.2 138.76.29.7 10.0.0.3 All datagrams leaving local Datagrams with source or network have same single source destination in this network NAT IP address: 138.76.29.7, have 10.0.0/24 address for different source port numbers source, destination (as usual) NetworkIN2097 - MasterSecurity, Course WS 2008/09, Computer Chapter Networks, 9 WS 2009/2010 41 NAT: Network Address Translation Implementation: NAT router must: . outgoing datagrams: replace (source IP address, port #) of every outgoing datagram to (NAT IP address, new port #) . remote clients/servers will respond using (NAT IP address, new port #) as destination addr. remember (in NAT translation table) every (source IP address, port #) to (NAT IP address, new port #) translation pair -> we have to maintain a state in the NAT .
    [Show full text]
  • Peer-To-Peer Protocol and Application Detection Support
    Peer-to-Peer Protocol and Application Detection Support This appendix lists all the protocols and applications currently supported by Cisco ASR 5500 ADC. • Supported Protocols and Applications, page 1 Supported Protocols and Applications This section lists all the supported P2P protocols, sub-protocols, and the applications using these protocols. Important Please note that various client versions are supported for the protocols. The client versions listed in the table below are the latest supported version(s). Important Please note that the release version in the Supported from Release column has changed for protocols/applications that are new since the ADC plugin release in August 2015. This will now be the ADC Plugin Build number in the x.xxx.xxx format. The previous releases were versioned as 1.1 (ADC plugin release for December 2012 ), 1.2 (ADC plugin release for April 2013), and so on for consecutive releases. New in this Release This section lists the supported P2P protocols, sub-protocols and applications introduced in the ADC Plugin release for December 1, 2017. ADC Administration Guide, StarOS Release 21.6 1 Peer-to-Peer Protocol and Application Detection Support New in this Release Protocol / Client Client Version Group Classification Supported from Application Release 6play 6play (Android) 4.4.1 Streaming Streaming-video ADC Plugin 2.19.895 Unclassified 6play (iOS) 4.4.1 6play — (Windows) BFM TV BFM TV 3.0.9 Streaming Streaming-video ADC Plugin 2.19.895 (Android) Unclassified BFM TV (iOS) 5.0.7 BFM — TV(Windows) Clash Royale
    [Show full text]
  • Peer-To-Peer NAT-Traversal for Ipsec
    Peer-to-Peer NAT-Traversal for IPsec y Anonymized peer registration y Endpoint discovery and relaying y Peer-initiated hole punching y IKEv2 Internet draft in preparation [email protected] [email protected] IKEv2 Mediation IKEv2 Mediation Server Mediation Connection Connection NAT Router NAT Router 1.2.3.4:1025 5.6.7.8:3001 IKEv2 Mediated Connection 10.1.0.10:4500 10.2.0.10:4500 Direct IPsec Tunnel using NAT-Traversal Peer Alice Peer Bob www.strongswan.org The double NAT case - where punching holes counts! ● You are selling automation systems all over the world. In order to save on travel expenses you want to remotely diagnose and update your deployed systems via the Internet. But security counts – thus IPsec is a must! Unfortunately both you and your customer are behind NAT routers so that no direct VPN connection is possible. You are helplessly blocked! ● You own an apartment at home, in the mountains or even abroad. You want to remotely control the heating or your sophisticated intrusion detection system via ADSL or Cable access. But since you and your apartment are separated by two NAT routers your are helplessly blocked. How it works! ● Two peers want to set up a direct IPsec tunnel using the established NAT traversal mechanism of encapsulating ESP packets in UDP datagrams. Unfortunately they cannot achieve this by themselves because neither host is seen from the Internet under the standard IKE NAT-T port 4500. Therefore both peers need to set up a mediation connection with an IKEv2 mediation server. In order to prevent unsolicited connection attempts by foreign peers, the mediation connections use randomized pseudonyms as IKE peer identities.
    [Show full text]
  • Problems of Ipsec in Combination with NAT and Their Solutions
    Problems of IPsec in Combination with NAT and Their Solutions Alexander Heinlein Abstract As the Internet becomes more and more a part of our daily life it also evolves as an at- tractive target for security attacks, often countered by Internet Protocol Security (IPsec) to establish virtual private networks (VPNs), if secure data communication is a primary objective. Then again, to provide Internet access for hosts inside Local Area Networks, a public IP address shared among all peers is often used, achieved by Network Address Translation (NAT) deployment. IPsec, however, is incompatible with NAT, leading to a variety of problems when using both in combination. Connection establishments origi- nating from the outside are blocked and NAT, as it modifies the outer IP header, breaks IPsec’s security mechanisms. In the following we analyze problems of NAT in combination with IPsec and multiple approaches to solve them. 1 Introduction The current TCP/IP protocols originate from a time where security was not a great concern. As the traditional Internet Protocol (IP) does not provide any guarantees on delivery, the receiver cannot detect whether the sender is the same one as recorded in the protocol header or if the packet was modified during transport. Moreover an attacker may also easily replay IP packets or read sensitive information out of them. In contrast, today, as the Internet becomes more and more a part of our everyday life, a more security aware protocol is needed. To fill this gap the Internet Engineering Task Force (IETF) worked on a new standard for securing IP, called Internet Protocol Security (IPsec).
    [Show full text]
  • The Impact of Network Address Translation on Peer-To-Peer Live Video Streaming Systems
    The Impact of Network Address Translation on Peer-to-Peer Live Video Streaming Systems by Zhonghua Wei M.Sc., University of London, 2006 B.Eng., Beijing Univ. of Posts and Telecommunications, 2005 A Thesis Submitted in Partial Fulfillment of the Requirements for the Degree of MASTER OF SCIENCE in the Department of Computer Science c Zhonghua Wei, 2011 University of Victoria All rights reserved. This thesis may not be reproduced in whole or in part, by photocopying or other means, without the permission of the author. ii The Impact of Network Address Translation on Peer-to-Peer Live Video Streaming Systems by Zhonghua Wei M.Sc., University of London, 2006 B.Eng., Beijing Univ. of Posts and Telecommunications, 2005 Supervisory Committee Dr. Jianping Pan, Supervisor (Department of Computer Science) Dr. Kui Wu, Departmental Member (Department of Computer Science) iii Supervisory Committee Dr. Jianping Pan, Supervisor (Department of Computer Science) Dr. Kui Wu, Departmental Member (Department of Computer Science) ABSTRACT Video streaming over the Internet can be very difficult under the traditional client-server model. Peer-to-peer (P2P) systems, in which each participating peer contributes its upload bandwidth to other peers while it downloads data, have been successful in file-sharing applications, and they appear to be promising in delivering video contents, too. However, the existence of network address translation (NAT) is always considered as a challenge to peer-to-peer systems. NAT has been a practical solution to the Internet Protocol version 4 (IPv4) address exhaustion problem, as it reduces the usage of IP addresses by allowing multiple private hosts to share a single public IP address, but NAT can degrade the performance of a peer-to-peer system as it limits the direction of connectivity.
    [Show full text]
  • On the Design and Implementation of IP-Over-P2P Overlay Virtual Private
    DOI:10.1587/transcom.2019CPI0001 Publicized:2019/08/05 This article has been accepted and published on J-STAGE in advance of copyediting. Content is final as presented. 1 Invited Paper On the Design and Implementation of IP-over-P2P Overlay Virtual Private Networks Kensworth Subratie†, Saumitra Aditya†, Vahid Daneshmand†, Kohei Ichikawa††, and Renato Figueiredo† SUMMARY The success and scale of the Internet and its protocol IP has protocols (e.g. TLS [2], [3]). As a result, distributed spurred emergent distributed technologies such as fog/edge computing and applications that run across the Internet often must deal with new application models based on distributed containerized microservices. The Internet of Things and Connected Communities are poised to build on devices without public IPv4 addresses that are behind these technologies and models and to benefit from the ability to various NAT and firewall middleboxes and must create communicate in a peer-to-peer (P2P) fashion. Ubiquitous sensing, actuating secure transport sessions for communication. While these and computing implies a scale that breaks the centralized cloud computing issues are relatively easy to handle with client-server model. Challenges stemming from limited IPv4 public addresses, the need applications, they place a burden to applications where peer- for transport layer authentication, confidentiality and integrity become a burden on developing new middleware and applications designed for the to-peer communication is needed. network’s edge. One approach - not reliant on the slow adoption of IPv6 - Emerging distributed applications in edge/fog [4], [5] is the use of virtualized overlay networks, which abstract the complexities computing are poised to benefit from the ability for IoT and of the underlying heterogeneous networks that span the components of edge nodes to communicate in a peer-to-peer fashion.
    [Show full text]
  • The Difficulties of a Peer-To-Peer VPN on the Hostile Internet
    The difficulties of The difficulties of a peer-to-peer a peer-to-peer VPN on the hostile Internet VPN on the hostile Internet Guus Sliepen Brussel, February 6, 2010 Introduction Communicating over the Internet The problem of NAT The problem of MTU Other problems Authentiation and authorization The end Guus Sliepen [email protected] 1.1 Tinc development started in September 1997, after The difficulties of introduction of ethertap in Linux 2.1.53. a peer-to-peer VPN on the hostile Internet Current features: Guus Sliepen • Connects multiple sites together • Can act as router (layer 3) or switch (layer 2) Introduction Communicating • Full support for IPv6 over the Internet The problem of • No central server NAT • You configure some endpoints, tinc will do the rest The problem of MTU Modus operandi: Other problems Authentiation and • Metadata exchanges via TCP authorization The end • VPN packets directly via UDP • Fall back to TCP if UDP is not possible 1.2 The competition: The difficulties of a peer-to-peer y VPN on the • CIPE hostile Internet • VTuny Guus Sliepen • IPsec • OpenVPN Introduction Communicating • Hamachi over the Internet The problem of But also: NAT The problem of • GVPE MTU • CloudVPN Other problems Authentiation and • SocialVPN authorization • n2n The end • VDE 1.3 Network before VPN is configured: The difficulties of a peer-to-peer VPN on the hostile Internet Guus Sliepen Introduction Communicating over the Internet The problem of NAT The problem of MTU Other problems Authentiation and authorization The end Blue cloud: the Internet
    [Show full text]
  • Internet Telephony PBX System IPX-2200/IPX-2500
    Internet Telephony PBX System IPX-2200/IPX-2500 Internet Telephony PBX System IPX-2200 IPX-2500 1 Internet Telephony PBX System IPX-2200/IPX-2500 Copyright Copyright (C) 2016 PLANET Technology Corp. All rights reserved. The products and programs described in this User’s Manual are licensed products of PLANET Technology. This User’s Manual contains proprietary information protected by copyright, and this User’s Manual and all accompanying hardware, software, and documentation are copyrighted. No part of this User’s Manual may be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine-readable form by any means by electronic or mechanical including photocopying, recording, or information storage and retrieval systems, for any purpose other than the purchaser's personal use, and without the prior written permission of PLANET Technology. Disclaimer PLANET Technology does not warrant that the hardware will work properly in all environments and applications, and makes no warranty and representation, either implied or expressed, with respect to the quality, performance, merchantability, or fitness for a particular purpose. PLANET has made every effort to ensure that this User’s Manual is accurate; PLANET disclaims liability for any inaccuracies or omissions that may have occurred. Information in this User’s Manual is subject to change without notice and does not represent a commitment on the part of PLANET. PLANET assumes no responsibility for any inaccuracies that may be contained in this User’s Manual. PLANET makes no commitment to update or keep current the information in this User’s Manual, and reserves the right to make improvements to this User’s Manual and/or to the products described in this User’s Manual, at any time without notice.
    [Show full text]