DOCSLIB.ORG

The Center for Autonomic Computing

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Center for Autonomic Computing Peer-to-peer Virtual Private Networks and Applications Renato Jansen Figueiredo Associate Professor Cloud and Autonomic Computing Center/ACIS Lab University of Florida Visiting Researcher at VU Backdrop Virtual machines in cloud computing On-demand, pay-per-use, user-configurable Federated environments End-to-end Internet connectivity hindered by address space and presence of NATs, firewalls Network virtualization – seamlessly connecting virtual machines across multiple providers Applications Distributed virtual private clusters Education, training in distributed computing Private communication among Internet users extending online social networks 2 Rationale Virtualization techniques for decoupling, isolation, multiplexing also apply to networking E.g. VLANs, VPNs However, there are challenges in configuration, deployment, and management Peer-to-peer techniques provide a basis for scalable routing, and self-management Software routers, integration at network end-points enables deployment over existing infrastructure Architecture, design needs to account for connectivity constraints, and support TCP/IP efficiently; optimize for common cases 3 Application Examples Cloud-bursting Run additional worker VMs on a cloud provider Extending enterprise LAN to cloud VMs – seamless scheduling, data transfers Federated “Inter-cloud” environments Multiple private clouds across various institutions Virtual machines can be deployed on different sites and form a distributed virtual private cluster Hands-on laboratories for classes Deploy your own cluster Connecting devices of social network peers Media streaming, file sharing, gaming, … 4 Talk - Outlook Background Architecting self-organizing virtual networks Topology, routing, tunneling, addressing, NAT traversal, performance Applications in Grid/cloud and end-user environments Virtual Private Clusters Social VPNs Applications in education FutureGrid 5 Resource Virtualization Virtual machines (Xen, VMware, KVM) paved the way to Infrastructure-as-a-Service (IaaS) Computing environment decoupled from physical infrastructure Pay-as-you-go for computing cycles Virtual networks complement virtual machines for increased flexibility and isolation in IaaS VMs must communicate seamlessly – regardless of where they are provisioned Traffic isolation; security, resource control 6 Virtual Machines and Networks Virtual V2 Infrastructure V3 V1 VMM + VN Physical Infrastructure Domain B WAN Domain A Domain C 7 Virtual Networks Single infrastructure, many virtual networks E.g. one per user, application, project, social network… Each isolated and independently configured Addressing, protocols; authentication, encryption Multiplexing physical network resources Network interfaces, links, switches, routers 8 Network Virtualization – Where? Virtualized endpoints Software Software Network Network Fabric Network Device Device (Virtual) (Virtual) machine machine Virtualized Fabric (e.g VLAN, OpenSwitch) 9 Landscape Peer-wise Internet connectivity constrained IPv4 address space limitations; NATs, firewalls Challenges - shared environment Lack of control of networking resources Cannot program routers, switches Public networks – privacy is important Often, lack privileged access to underlying resources May be “root” within a VM, but lacking hypervisor privileges Dynamic creation, configuration and tear-down Complexity of management 10 Peer-to-Peer Virtual Networks Overview User-level IP overlays deployable on Internet end resources (software routers, virtual NICs) Why virtual? Hide complexities associated with NAT traversal, IPv4 address space constraints from applications Support unmodified applications Why peer-to-peer? Self-organizing - reduce management complexity and cost Decentralized architecture for scalability and robustness 11 The IP-over-P2P (IPOP) Approach Isolation Virtual address space decoupled from Internet Packets picked, encapsulated, tunneled and delivered within the scope of virtual network Self-organization Overlay topology, routing tables Autonomously deals with joins, leaves, failures Decentralized P2P messaging architecture No global state, no central point of failure Tunnels (UDP, TCP, …), routing Decentralized NAT traversal No need for STUN server infrastructure [IPDPS 2006, Ganguly et al] 12 IPOP: Architecture Overview Unmodified applications Capture/tunnel, scalable, Connect(10.10.1.2,80) resilient, self-configuring Routing; object store Application Virtual Router VNIC 10.10.1.1 Wide-area Virtual Application Overlay network Router Isolated, private virtual VNIC address space 10.10.1.2 P2P Overlay (Brunet) Bi-directional ring ordered by 160-bit IPOPid’s Structured connections: • “Near”: with neighbors n4 IPOPid • “Far”: across the ring n3 n5 n2 n6 Multi-hop path n1 n7 between n1 and n7 Far n12 n8 Near n11 n9 n1 < n2 < n3 <……. < n13 < n14 n10 Overlay: Edges and Routing Overlay edges Multiple transports: UDP, TCP, TLS NAT traversal (UDP hole-punching) Greedy routing Deliver to peer closest to destination IPOPid Constant # of edges per node (average k) O((1/k)log2(n)) overlay hops On-demand edges Created/trimmed down based on IP communication 15 Creating Overlay Edges Overlay path CTM request CTM reply Link request A B A’s endpoint URIs: B’s endpoint URIs: tcp://10.5.1.1:3000 tcp://172.16.2.1:5000 (local) udp://129.15.56.9:6000 udp://128.227.56.9:4433 (NAT – learned) • A sends a Connect-to-me (CTM) request to B’s IPOPid • Contains all its URIs (UDP/TCP IP:port endpoints) • Routed over P2P overlay to B • B sends CTM reply with its URIs – overlay routed • B initiates “linking” with A • Attempts linking with parallel requests to A’s URIs 16 NAT Traversal Direct edge between A and B A B Technique for “cone” UDP NATs: A’s link request message to B creates ephemeral state in A’s NAT allowing messages from B to pass through NAT (and vice-versa) Overlay: manage keep-alives so NAT mapping “holes” stay open; re-link if NAT mappings expire 17 Naming and Multiplexing One P2P overlay can multiplex multiple VNs E.g. multiple virtual clusters from different projects IP routing within the scope of a namespace User-provided string identifies IPOP namespace Each IPOP node is configured with a namespace IP-to-P2P address resolution: DHT-Get(namespace:IP) -> IPOPid 18 Managing Virtual IP Addresses Address assignment: static, or dynamic Supports DHCP Store configuration (including base address, mask) on DHT entry bound to namespace DHCP proxy runs on each IPOP node Pick DHCP request Lookup DHCP configuration for namespace Guess an IP address at random within range Attempt to store in DHT; wait for majority to acknowledge; retry upon failure 19 Optimization: On-demand edges At each node: Count IP-over-P2P packets to other nodes When number of packets within an interval exceeds threshold: Initiate connection setup; create edge Trimming on-demand edges no longer in use Overhead involved in connection maintenance 20 Optimization: Tunnel Edges Peers X, Y may not be able to communicate directly if they are behind symmetric NATs X, Y exchange list of neighbor URIs Each attempts to create edge to common intermediary Z to serve as proxy Routing – abstracted as regular overlay edge X-Y connected by virtual edge Useful to maintain ring topology in the face of failures (routing outages, symmetric NATs) 21 Implementation IPOP open-source system C# user-level router Tap virtual network device Performance 1GbE physical LAN Latency (ms) Bwidth (Mb/s) Mem (KB) Host 0.27 941 n/a IPOP 0.52 284 38312 IPOP+sec 0.75 55 50976 22 Performance (WAN) EC2/UF EC2GoGrid UF/GoGrid Netperf stream 89.2 35.9 30.2 native (Mbps) Netperf stream 75.3 19.2 25.7 IPOP (Mbps) Netperf RR 13.4 11.1 10.0 trans/s native Netperf RR 13.3 10.7 9.8 trans/s IPOP Related Work There exist several VPN technologies: Enterprise VPNs (e.g. Cisco); Open-source (e.g OpenVPN); Consumer/gaming/SMB (e.g. Hamachi) Not easily applicable to federating cloud resources Proprietary code; difficulty in configuration/management Research work in the context of Grid/cloud computing VNET (Northwestern University), VIOLIN (Purdue University), Private Virtual Cluster (INRIA), ViNe (Tsugawa, Fortes @ UF) Smartsockets @ VU 24 IPOP Social Networks Users now commonly manage relationships to social peers through Online Social Networks Facebook, Google+ Communication hindered by OSN provider APIs, privacy concerns A generic IP network can enable existing and new social network applications But users don’t have public IPs, don’t want to necessarily open NATs/firewalls to all users Users don’t want to configure and discover network services manually 25 Social VPNs Alice's Compute Node Alice's Friend's Compute Node Bob's Compute Node on EC2 IP-over-P2P Tunnel OSN XMPP Alice Bob Carl Social VPNs From a user’s perspective: it’s simple My computer gets a virtual network card It connects me directly to my social peers All IP packets: authenticated, encrypted, end-to-end Leverage well-known PKI techniques No configuration besides establishing social links All I need to do to is log in to a web based social network Applications, middleware work as if the computers were on the same local-area network Including multicast-based resource discovery – UPnP, mDNS 27 Applications Social VPN is not the application It is not tied to an application either It enables applications that are of interest for collaboration Security – needed beyond network layer Authenticated
Load more

Recommended publications
  • Deploying IBM Spectrum Accelerate on Cloud
    Front cover Deploying IBM Spectrum Accelerate on Cloud Bert Dufrasne Nancy Kinney Donald Mathisen Christopher Moore Markus Oscheka Ralf Wohlfarth Eric Zhang Redpaper International Technical Support Organization Deploying IBM Spectrum Accelerate on Cloud December 2015 REDP-5261-00 Note: Before using this information and the product it supports, read the information in “Notices” on page v. First Edition (December 2015) This edition applies to IBM Spectrum Accelerate Version 11.5 © Copyright International Business Machines Corporation 2015. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . .v Trademarks . vi IBM Redbooks promotions . vii Preface . ix Authors. ix Now you can become a published author, too . xi Comments welcome. xi Stay connected to IBM Redbooks . xi Chapter 1. Introducing IBM SoftLayer and IBM Spectrum Accelerate . 1 1.1 IBM Cloud computing overview. 2 1.2 IBM SoftLayer Cloud overview . 3 1.3 IBM Spectrum Accelerate . 6 1.3.1 IBM Spectrum Accelerate on Cloud . 7 Chapter 2. IBM Spectrum Accelerate on Cloud . 9 2.1 Description of service . 10 2.2 Customer responsibilities . 11 2.3 Configuration types . 11 2.4 Hardware in SoftLayer data centers . 12 2.5 Ordering process. 12 2.5.1 Order process flow . 12 2.6 Changes to the existing configuration . 13 2.6.1 Increasing capacity and performance . 13 2.6.2 Capacity and performance reduction . 13 2.6.3 Termination of service. 13 2.7 Restrictions . 14 2.7.1 Ordering for use in customer SoftLayer account. 14 2.8 Connectivity.
    [Show full text]
  • Distributed Automatic Configuration of Complex Ipsec
    J Netw Syst Manage (2010) 18:300–326 DOI 10.1007/s10922-010-9168-7 Distributed Automatic Configuration of Complex IPsec-Infrastructures Michael Rossberg • Guenter Schaefer • Thorsten Strufe Published online: 30 May 2010 Ó Springer Science+Business Media, LLC 2010 Abstract The Internet Protocol Security Architecture IPsec is hard to deploy in large, nested, or dynamic scenarios. The major reason for this is the need for manual configuration of the cryptographic tunnels, which grows quadratically with the total amount of IPsec gateways. This way of configuration is error-prone, cost-intensive and rather static. When private addresses are used in the protected subnetworks, the problem becomes even worse as the routing cannot rely on public infrastructures. In this article, we present a fully automated approach for the distributed configuration of IPsec domains. Utilizing peer-to-peer technology, our approach scales well with respect to the number of managed IPsec gateways, reacts robust to network failures, and supports the configuration of nested networks with private address spaces. We analyze the security requirements and further desirable properties of IPsec policy negotiation, and show that the distribution of security policy configuration does not impair security of transmitted user data in the resulting virtual private network (VPN). Results of a prototype implementation and simulation study reveal that the approach offers good characteristics for example with respect to quick reconfigu- ration of all gateways after a central power failure (robustness), or after insertion of new gateways (scalability and agility). M. Rossberg (&) Á G. Schaefer Technische Universita¨t Ilmenau, Telematics and Computer Networks Group, Postfach 100565, 98684 Ilmenau, Germany e-mail: [email protected] G.
    [Show full text]
  • Virtuaalikone Ja -Verkkoympäristön Hyödyntäminen Tietoverkkotekniikan Tutkimus- Ja Opetusympäristöjen Rakentamisessa
    Iikka Jaakkola Virtuaalikone ja -verkkoympäristön hyödyntäminen tietoverkkotekniikan tutkimus- ja opetusympäristöjen rakentamisessa Elektroniikan, tietoliikenteen ja automaation tiedekunta Diplomityö, joka on jätetty opinnäytteenä tarkastettavaksi diplomi-insinöörin tutkintoa varten Espoossa 10.5.2010 Työn valvoja: Prof. Jukka Manner Työn ohjaaja: TkL Markus Peuhkuri i AALTO-YLIOPISTO DIPLOMITYÖN TEKNILLINEN KORKEAKOULU TIIVISTELMÄ Tekijä: Iikka Jaakkola Työn nimi: Virtuaalikone ja -verkkoympäristön hyödyntäminen tietoverkkotekniikan tutkimus- ja opetusympäristöjen rakentamisessa Päivämäärä: 10.5.2010 Kieli: suomi Sivumäärä:55+26 Elektroniikan, tietoliikenteen ja automaation tiedekunta Tietoliikenne- ja tietoverkkotekniikan laitos Professuuri: Tietoverkot Koodi: S-38 Valvoja: Prof. Jukka Manner Ohjaaja: TkL Markus Peuhkuri Työn tavoitteena oli selvittää virtuaalisen tutkimusverkkoyhteyden tarvetta, vaatimuk- sia ja toteutuskelpoista tuomista tutkijoiden ja muiden tahojen, kuten opiskelijoiden, käyttöön. Virtuaalinen ympäristö oli tarkoitus rakentaa maksutta saatavilla olevien vir- tuaalikone- ja VPN-asiakasyhteysohjelmistojen varaan ja sen tulisi olla mahdollista asentaa tutkijoiden keskitetysti hallittuihin työasemiin. Lisäksi tutkittiin ratkaisun käyt- tökohteita, joista tärkeimpänä oli testiverkkoihin yhdistäminen. Ratkaisulle asetettavia vaatimuksia selvitettiin tietoturvapolitiikan, loppukäyttäjien, tietojärjestelmien ylläpi- don ja laitteistovaatimusten kannalta. Käyttäjien ja ylläpidon näkemyksiä kyseltiin haastatteluin ja kyselyin.
    [Show full text]
  • Vyos Platform | DATASHEET HOW YOU CAN USE Vyos
    VyOS Platform the power of your environment VyOS is a network operating system which supports most of modern routing protocols and network security features. VyOS runs equally well on bare metal hardware and inside virtual machines, including common cloud platforms. OVERVIEW VyOS is a GNU/ Linux-based operating system which ties many popular open source applications under a single, unified command line interface. VyOS offers features that are inherent to the traditional hardware routers: commit and rollback functionality, built-in configuration versioning and archiving, scripting APIs. At the same time it provides VPN and firewalls options. One of the most popular use cases for VyOS is connecting an existing enterprise network to the cloud infrastructure or connecting networks that hosted at different cloud platform vendors to each other: Benefits: - Open and community-driven nature of development - Enterprise- and service provider networks oriented - Adaptable for any network - from a small office to a data center rack - Arise from the abandoned Vyatta Core system so you can upgrade old Vyatta Core systems to VyOS without reinstallation - Continues to be actively developed and improved by the community. Services offered: - Commercial support - Development services on demand - Private deployments design and configuration for small and medium-sized businesses (ISPs, MSPs and Enterprise users) - Trainings and workshops KEY FEATURES - Wide range of supported VPN technologies: GRE, IPSec, IPSec VTI, OpenVPN, WireGuard - API for working with configuration from shell, Python, and Perl scripts - Physical and virtual hardware supported equally - Command line interface in the style of JunOS - Wide range of COTS hardware and virtual platforms supported - One-step image build process: any users can build custom images for their needs - Support BGP, OSPF routing protocols - QoS for traffic prioritization and shaping - Safe and easy image-based upgrades.
    [Show full text]
  • Cisco ASR900 Series and NCS4200 Series Running IOS-XE 16.9
    Cisco ASR900 Series and NCS4200 Series running IOS-XE 16.9 Preparative Procedures & Operational User Guide for the Common Criteria Certified Configuration Version 1.0 11 October 2019 Americas Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA © 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Cisco ASR900 Series and NCS4200 Series Routers Table of Contents 1 Introduction ........................................................................................................................ 7 1.1 Audience .................................................................................................................... 7 1.2 Purpose ....................................................................................................................... 7 1.3 Document References ................................................................................................ 7 1.4 Supported Hardware and Software ............................................................................ 9 1.4.1 Supported Configurations ...................................................................................... 9 1.5 Operational Environment ......................................................................................... 10 1.6 Excluded Functionality ............................................................................................ 11 2 Secure Acceptance of the TOE ........................................................................................ 12
    [Show full text]
  • User-Defined P2P Virtual Network Overlays for Ad-Hoc Collaboration
    EAI Endorsed Transactions on Collaborative Computing Research Article TinCan: User-Defined P2P Virtual Network Overlays for Ad-hoc Collaboration 1 1 1 2 1 Pierre St Juste∗ , Kyuho Jeong , Heungsik Eom , Corey Baker , Renato Figueiredo 1Advanced Computing and Information Systems Lab, 2Wireless and Mobile Systems Lab Electrical and Computer Engineering, University of Florida, Gainesville, FL, 32611, USA Abstract Virtual private networking (VPN) has become an increasingly important component of a collaboration environment because it ensures private, authenticated communication among participants, using existing collaboration tools, where users are distributed across multiple institutions and can be mobile. The majority of current VPN solutions are based on a centralized VPN model, where all IP traffic is tunneled through a VPN gateway. Nonetheless, there are several use case scenarios that require a model where end-to-end VPN links are tunneled upon existing Internet infrastructure in a peer-to-peer (P2P) fashion, removing the bottleneck of a centralized VPN gateway. We propose a novel virtual network — TinCan — based on peer- to-peer private network tunnels. It reuses existing standards and implementations of services for discovery notification (XMPP), reflection (STUN) and relaying (TURN), facilitating configuration. In this approach, trust relationships maintained by centralized (or federated) services are automatically mapped to TinCan links. In one use scenario, TinCan allows unstructured P2P overlays connecting trusted end-user devices — while only requiring VPN software on user devices and leveraging online social network (OSN) infrastructure already widely deployed. This paper describes the architecture and design of TinCan and presents an experimental evaluation of a prototype supporting Windows, Linux, and Android mobile devices.
    [Show full text]
  • Middleboxes As a Cloud Service
    Middleboxes as a Cloud Service By Justine Marie Sherry A dissertation submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Computer Science in the Graduate Division of the University of California, Berkeley Committee in charge: Professor Sylvia Ratnasamy, Chair Professor Scott Shenker Professor John Chuang Professor Arvind Krishnamurthy Fall 2016 Middleboxes as a Cloud Service Copyright 2016 by Justine Marie Sherry 1 Abstract Middleboxes as a Cloud Service by Justine Marie Sherry Doctor of Philosophy in Computer Science University of California, Berkeley Professor Sylvia Ratnasamy, Chair Today’s networks do much more than merely deliver packets. Through the deployment of middleboxes, enterprise networks today provide improved security – e.g., filtering malicious content – and performance capabilities – e.g., caching frequently accessed content. Although middleboxes are deployed widely in enterprises, they bring with them many challenges: they are complicated to manage, expensive, prone to failures, and challenge privacy expectations. In this thesis, we aim to bring the benefits of cloud computing to networking. We argue that middlebox services can be outsourced to cloud providers in a similar fashion to how mail, compute, and storage are today outsourced. We begin by presenting APLOMB, a system that allows enterprises to outsource middlebox processing to a third party cloud or ISP. For en- terprise networks, APLOMB can reduce costs, ease management, and provide resources for scalability and failover. For service providers, APLOMB oers new customers and business opportunities, but also presents new challenges. Middleboxes have tighter performance de- mands than existing cloud services, and hence supporting APLOMB requires redesigning software at the cloud.
    [Show full text]
  • VPN Openswan
    VPN OpenSWAN VPN OpenSWAN 1 / 3 2 / 3 Openswan is an implementation of IPsec for Linux and a continuation of the FreeS/WAN project (dating back to 1999).. How to configure ipsec site to site vpn server in Linux. Openswan ipsec vpn configuration for interconnecting two remote private networks using .... Configuring OpenSwan client for use with a FortiGate VPN connection. Components. All FortiGate units. FortiOS version 2.8 and 3.0; OpenSwan .... Creating a repeatable, dynamic site to site VPN with OpenSwan on Ubuntu 10.04 from Amazon EC2 - tutorial.md.. A cheaper alternative is to use a “software VPN” like Openswan that runs on a Linux-based EC2 instance. Although the cost of an m4.large instance on a 3-year .... Openswan is an IPsec implementation for Linux. It has support for most of the extensions (RFC + IETF drafts) related to IPsec, including IKEv2, X. 509 Digital Certificates, NAT Traversal, and many others.. OpenSWAN is, without question, the easiest of all the Linux VPN solutions to get operational; but that's not saying much, because the other .... Openswan L2TP/IPsec VPN client setup. From ArchWiki. Jump to navigation Jump to search. Related articles. strongSwan. This article .... In this tutorial we will setup a gateway to gateway IPSec VPN using OpenSwan. The Scenario: The scenario we will use in this guide will be .... This howto explains how to configure an openwrt router to act as an ipsec/l2tp vpn server using openswan and xl2tpd. Introduction. Required .... In the field of computer security, Openswan provides a complete IPsec implementation for Linux ..
    [Show full text]
  • Facilitating the Deployment of Ad-Hoc Virtual Organizations With
    FacilitatingtheDeploymentofAd-hocVirtual Organizations with Integrated Social and Overlay Networks Renato J. Figueiredo, P. Oscar Boykin, Pierre St. Juste, and David Wolinsky Advanced Computing and Information Systems, University of Florida Gainesville, FL 32611 [email protected]fl.edu, [email protected]fl.edu, ptony82@ufl.edu, davidiw@ufl.edu ABSTRACT fact that, while commodity computers have become increas- Deploying virtual organizations (VOs) is difficult for small- ingly cheaper and faster, the management overhead asso- and medium-scale collaborations: the overheads in estab- ciated with deploying cross-organization, wide-area cyber- lishing and managing trust, and in deploying and managing infrastructures can be larger than researchers are able to computational resources distributed across multiple organi- afford. This is often the case in small- and medium-scale zations are daunting to many potential users, presenting a efforts and those involving institutions which do not have barrier to entry that significantly hinders wider deployment extensive personnel to manage the requirements of main- of VOs. We advocate an approach where social networking taining complex computational resources. and self-configuring overlay virtual networks are integrated A key management overhead associated with initiating a in a novel way that allows simple deployment and manage- VO is the establishment of trust among its participating ment of ad-hoc infrastructures for VOs. There are three cen- entities, typically by means of establishing a Public Key tral principles in our approach: (1) user relationships which Infrastructure (PKI) certificate authority. Furthermore, a have been increasingly recorded in social networking systems key management overhead in sustaining a VO is the sys- provide the opportunity to bootstrap trust relationships; (2) tem administration of distributed, cross-domain computing connections established at a social networking layer can effi- resources and associated software and middleware.
    [Show full text]
  • Future After Openvpn and Ipsec
    Ville Korhonen FUTURE AFTER OPENVPN AND IPSEC Computing and Electrical Engineering Master of Science Thesis August 2019 i ABSTRACT Ville Korhonen: Future after OpenVPN and IPsec Master of Science Thesis Tampere University Master’s Degree In Information Technology August 2019 Virtual private networks (VPN) are used to connect private networks of organizations securely over public Internet. Virtual private network offers a secure and encrypted network connection even though the underlying network is public and insecure. In addition to connecting two remote sites with a virtual private network, it is possible to create a virtual private network between a remote worker and an organization site. Virtual private networks allow organizations to build secure connections relatively cheap and fexibly over the Internet. The most widely used virtual private network protocols are IPsec (Internet Protocol Security) and SSL/TLS (Secure Socket Layer/Transport Layer Security) based protocols. IPsec is usually used for connecting two remote sites and SSL/TLS based technologies are used when a remote worker connects to the organization’s resources. Both of these protocols have held a strong po- sition for years even though especially IPsec have been criticized since the day it was born. The goal of this thesis was to investigate are there any alternatives available currently for IPsec and SSL/TLS based virtual private networks and are there protocols or architectures under develop- ment which could be alternatives in the future. Based on the research, IPsec and SSL/TLS based protocols have superseded all older tech- nologies and there aren’t any real alternatives available to them.
    [Show full text]
  • Cisco Catalyst 9200/9200L Series Switches Running IOS-XE 16.12 Common Criteria Operational User Guidance
    Cisco Catalyst 9200/9200L Series Switches running IOS-XE 16.12 Common Criteria Operational User Guidance And Preparative Procedures Version 1.2 17 March 2020 Americas Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA © 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Cisco Catalyst 9200/9200L Series Switches Table of Contents 1. Introduction 9 1.1 Audience 9 1.2 Purpose 9 1.3 Document References 9 1.4 Supported Hardware and Software 12 1.4.1 Supported Configurations 12 1.5 Operational Environment 13 1.6 Excluded Functionality 13 2. Secure Acceptance of the TOE 15 3. Secure Installation and Configuration 17 3.1 Physical Installation 18 3.2 Initial Setup via Direct Console Connection 18 3.2.1 Options to be chosen during the initial setup of the Catalyst 9200/9200L Series Switches 18 3.2.2 Saving Configuration 19 3.2.3 Secure Remote Management 19 3.2.4 FIPS Mode 20 3.2.5 Administration of Cryptographic Self-Tests 20 3.2.6 Administration of Non-Cryptographic Self-Tests 22 3.2.7 Access Control and Lockout 22 3.2.8 Session Termination 24 3.2.9 User Lockout 24 3.3 Network Protocols and Cryptographic Settings 25 3.3.1 Remote Administration Protocols 25 3.3.2 Authentication Server Protocols 27 3.3.3 Routing Protocols 28 3.3.4 MACSEC and MKA Configuration 28 3.3.5 X.509 Certificates 29 3.3.6 IPsec Overview 34 Page 2 of 74 Cisco Catalyst 9200/9200L Series Switches 3.3.7 Configuration of IPsec 35 3.3.8 Session Protection 44 3.4 Logging Configuration 46 3.4.1 Usage of Embedded Event Manager 48 3.4.2 Remote Logging 48 3.4.3 Logging Protection 48 4.
    [Show full text]
  • Private and Censorship-Resistant Communication Over Public Networks
    Private and Censorship-Resistant Communication over Public Networks Michael John Rogers Thesis submitted for the degree of Doctor of Philosophy of UCL Department of Computer Science University College London University of London 2010 1 I, Michael John Rogers, confirm that the work presented in this thesis is my own. Where information has been derived from other sources, I confirm that this has been indicated in the thesis. 2 Abstract Society’s increasing reliance on digital communication networks is creating unprecedented opportunities for whole- sale surveillance and censorship. This thesis investigates the use of public networks such as the Internet to build robust, private communication systems that can resist monitoring and attacks by powerful adversaries such as national governments. We sketch the design of a censorship-resistant communication system based on peer-to-peer Internet overlays in which the participants only communicate directly with people they know and trust. This ‘friend-to-friend’ approach protects the participants’ privacy, but it also presents two significant challenges. The first is that, as with any peer-to-peer overlay, the users of the system must collectively provide the resources necessary for its operation; some users might prefer to use the system without contributing resources equal to those they consume, and if many users do so, the system may not be able to survive. To address this challenge we present a new game theoretic model of the problem of encouraging cooperation between selfish actors under conditions of scarcity, and develop a strategy for the game that provides rational incentives for cooperation under a wide range of conditions.
    [Show full text]