Software Defined Networks Software Defined Networks a Comprehensive Approach

Total Page:16

File Type:pdf, Size:1020Kb

Software Defined Networks Software Defined Networks a Comprehensive Approach Software Defined Networks Software Defined Networks A Comprehensive Approach Paul Göransson Chuck Black AMSTERDAM • BOSTON • HEIDELBERG • LONDON NEW YORK • OXFORD • PARIS • SAN DIEGO SAN FRANCISCO • SINGAPORE • SYDNEY • TOKYO Morgan Kaufmann is an imprint of Elsevier Acquiring Editor: Steve Elliot Editorial Project Manager: Kaitlin Herbert Project Manager: Punithavathy Govindaradjane Designer: Mark Rogers Morgan Kaufmann is an imprint of Elsevier 225 Wyman Street, Waltham, MA 02451, USA Copyright © 2014 Elsevier Inc. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechani- cal, including photocopying, recording, or any information storage and retrieval system, without permission in writing from the publisher. Details on how to seek permission, further information about the Publisher’s permis- sions policies and our arrangements with organizations such as the Copyright Clearance Center and the Copyright Licensing Agency, can be found at our website: www.elsevier.com/permissions. This book and the individual contributions contained in it are protected under copyright by the Publisher (other than as may be noted herein). Notices Knowledge and best practice in this field are constantly changing. As new research and experience broaden our understanding, changes in research methods, professional practices, or medical treatment may become necessary. Practitioners and researchers must always rely on their own experience and knowledge in evaluating and using any information, methods, compounds, or experiments described herein. In using such information or methods they should be mindful of their own safety and the safety of others, including parties for whom they have a professional responsibility. To the fullest extent of the law, neither the Publisher nor the authors, contributors, or editors, assume any liability for any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from any use or operation of any methods, products, instructions, or ideas contained in the material herein. Library of Congress Cataloging-in-Publication Data Application submitted British Library Cataloguing-in-Publication Data A catalogue record for this book is available from the British Library ISBN: 978-0-12-416675-2 Printed and bound in the United States of America 14 15 16 17 18 10 9 8 7 6 5 4 3 2 1 For information on all MK publications visit our website at www.mkp.com This book is dedicated to our families. In praise of Software Networks: A Comprehensive Approach “SDN is here and Görannson’s book will fill a glaring need in the technical education community. It is a new game in town. This useful reference will help get our students up to speed and ready to play in this world of immense new possibilities.” —Brian Capouch, Assistant Professor of Computer Science, Saint Joseph’s College “This book is THE collection of the state-of-the-art in SDN. Göransson and Black have compiled all of the current literature into an easy-to-read text, preparing the reader to be both current in SDN tech- nology and aware of the impact that SDN will have today and tomorrow. This is a must-have on every network technologist’s shelf.” —Scott Valcourt, Director of Strategic Technology, University of New Hampshire “Göransson and Black have truly written a comprehensive book on SDN! This is the book we’ve all been waiting for. Göransson and Black provide an excellent background on SDN, how OpenFlow plays an important role in SDNs and how the close alignment with the open source movement has allowed this technology to progress at lightning speed over the past few years. Anyone who reads this book will walk away with a detailed understanding of SDN, OpenFlow, the SDN Ecosystem and even the busi- ness ramifications of implementing SDN. Personally, I can’t wait to use this book with my students in my SDN course.” —Robert M. Cannistra, NYS Cloud Computing Center - SDN Innovation Lab School of Computer Science and Mathematics, Marist College List of Figures Number Figure Page 1.1 Typical data center network topology. 6 1.2 Roles of the control, management, and data planes. 8 1.3 A packet’s journey through switching hardware. 10 1.4 Control plane consternation in the switch. 14 1.5 Overhead of dynamic distributed route computation. 15 1.6 Centralized programming of forwarding tables. 16 2.1 Networking functionality migrating to hardware. 22 2.2 Example graph of a network for shortest-path calculation. 23 2.3 Server virtualization: creating a new VM instance. 30 2.4 Creating a new network instance in the old paradigm. 31 2.5 Multipath. 33 3.1 Early attempts at SDN: RADIUS. 42 3.2 Early attempts at SDN: orchestration. 43 3.3 Early attempts at SDN: plugins. 45 3.4 ForCES design. 46 3.5 4D principles. 47 3.6 Ethane architecture. 49 3.7 General OpenFlow design. 50 4.1 SDN operation overview. 62 4.2 Controller-to-device communication. 63 4.3 SDN software switch anatomy. 64 4.4 SDN hardware switch anatomy. 65 4.5 SDN controller anatomy. 69 4.6 SDN controller northbound API. 71 4.7 SDN via existing APIs. 75 4.8 Virtualized networks. 76 xv xvi List of Figures 4.9 Encapsulated frames. 77 4.10 Virtual tunnel endpoints. 78 5.1 OpenFlow components. 82 5.2 OpenFlow V.1.0 switch. 84 5.3 OpenFlow controller-switch secure channel. 86 5.4 OpenFlow support for multiple queues per port. 87 5.5 OpenFlow V.1.0 flow table. 88 5.6 Basic flow entry. 88 5.7 Packet paths corresponding to virtual ports. 90 5.8 Controller-switch protocol session. 93 5.9 Controller programming flow entries in V.1.0. 96 5.10 Packet matching function: basic packet forwarding V.1.0. 97 5.11 Switch forwarding incoming packet to controller. 98 5.12 OpenFlow V.1.1 switch with expanded packet processing. 100 5.13 OpenFlow V.1.1 group table. 102 5.14 Packet matching function - basic packet forwarding, V.1.1. 105 5.15 Multicast using group table in V.1.1. 106 5.16 OpenFlow V.1.3 meter table. 111 5.17 Multiple connections and multiple channels from a switch. 113 5.18 V.1.3 flow entry. 114 5.19 Use of meters for QoS control in V.1.3. 115 6.1 Phased deployment of SDN. 120 6.2 Traditional network failure recovery. 121 6.3 SDN network failure recovery. 122 6.4 SDN controller as single point of failure. 122 6.5 Controller high availability and monitoring. 123 6.6 Controller cluster. 126 6.7 Controller hierarchy. 127 6.8 Deep packet inspection. 127 6.9 Stateful awareness for special protocols. 129 List of Figures xvii 6.10 Stateful awareness of application-level transactions. 130 6.11 Overlay operation. 137 6.12 Opening up the device. 140 6.13 SDN alternatives overlap. 142 7.1 MAC address table overflow. 148 7.2 VLAN exhaustion. 149 7.3 VXLAN packet format. 153 7.4 NVGRE packet format. 154 7.5 STT packet format. 155 7.6 Shortest path bridging: Q-in-Q (VLAN). 156 7.7 Shortest path bridging: MAC-in-MAC. 157 7.8 Fat-tree topology. 159 7.9 Optimal path selection by SDN controller. 164 8.1 Ensuring consistent policy configuration. 170 8.2 Google without OpenFlow. 173 8.3 Google with OpenFlow. 174 8.4 Service provider environment. 176 8.5 Service provider and SDN: MPLS (Courtesy [6]). 177 8.6 NAC captive portal application. 181 8.7 DNS blacklist application. 183 8.8 IP address blacklist application. 183 8.9 Mobile service providers. 185 8.10 Load balancers using OpenFlow. 189 8.11 Firewalls using OpenFlow. 190 8.12 Optical offload application overview. 192 9.1 SDN players ecosystem. 196 9.2 ONF vs. OpenDaylight board membership. 205 9.3 Focus of ONF vs. OpenDaylight. 207 10.1 Reactive application design. 214 10.2 Proactive application design. 216 xviii List of Figures 10.3 Blacklist application design. 219 10.4 Tunnels application design. 231 10.5 Offload application design. 233 10.6 NAC application design. 234 10.7 Traffic engineering proactive application design. 235 10.8 Traffic engineering reactive application design. 236 11.1 SDN open source landscape. 240 11.2 Applications of OpenFlow source. 244 11.3 Openstack components and roles. 253 11.4 Openstack plugins. 254 11.5 RouteFlow network topology (Courtesy of CPqD). 255 11.6 RouteFlow architecture (Courtesy of CPqD). 256 12.1 CAPEX on network equipment migrates to OPEX. 260 12.2 Agile environment for network administrators. 276 13.1 Gartner hype cycle. ((Courtesy Gartner, Inc.) [1]). 282 List of Tables Number Table Page 3.1 Precursors of SDN 40 3.2 Open Networking Foundation Working Groups 51 5.1 OFPT Message Types in OpenFlow 1.0 92 5.2 Major New Features Added in OpenFlow 1.1 99 5.3 Major New Features Added in OpenFlow 1.2 107 5.4 Major New Features Added in OpenFlow 1.3 110 5.5 OpenFlow Protocol Constant Classes 117 6.1 SDN Technologies Report Card 143 7.1 Comparison of Alternatives in Addressing Data Center Needs 160 7.2 Data Center SDN Implementations 166 9.1 2013 SDN Commercial Product List by Vendor 198 11.1 Open Source Implementations of OpenFlow: Description 245 11.2 Open Source Implementations of OpenFlow: Details 245 11.3 Open Source OpenFlow Switches: Description 246 11.4 Open Source OpenFlow Switches: Details 246 11.5 Open Source Controllers: Description 247 11.6 Open Source Controllers: Details 248 11.7 Open Source SDN Applications: Description 250 11.8 Open Source SDN Applications: Details 250 11.9 Open Source Orchestration Solutions: Description 251 11.10 Open Source Orchestration Solutions: Details 252 11.11 Open Source Test and Simulation: Description 252 11.12 Open Source Test and Simulation: Details 252 12.1 Major VCs Investing in SDN Startups as of 2013 267 12.2 Major SDN Acquisitions in 2012–2013 268 12.3 Startup Landscape in 2013 271 xix Foreword What is Software Defined Networking, and why has it created so much hype in the networking industry? This seems like a simple question to answer, yet I spent nearly three years traveling the world answering that very question for everyone from undergraduate engineering students to chief technol- ogy officers of major networking vendors.
Recommended publications
  • Technical Impacts of DNS Privacy and Security on Network Service Scenarios
    - Technical Impacts of DNS Privacy and Security on Network Service Scenarios ATIS-I-0000079 | April 2020 Abstract The domain name system (DNS) is a key network function used to resolve domain names (e.g., atis.org) into routable addresses and other data. Most DNS signalling today is sent using protocols that do not support security provisions (e.g., cryptographic confidentiality protection and integrity protection). This may create privacy and security risks for users due to on-path nodes being able to read or modify DNS signalling. In response to these concerns, particularly for DNS privacy, new protocols have been specified that implement cryptographic DNS security. Support for these protocols is being rapidly introduced in client software (particularly web browsers) and in some DNS servers. The implementation of DNS security protocols can have a range of positive benefits, but it can also conflict with important network services that are currently widely implemented based on DNS. These services include techniques to mitigate malware and to fulfill legal obligations placed on network operators. This report describes the technical impacts of DNS security protocols in a range of network scenarios. This analysis is used to derive recommendations for deploying DNS security protocols and for further industry collaboration. The aim of these recommendations is to maximize the benefits of DNS security support while reducing problem areas. Foreword As a leading technology and solutions development organization, the Alliance for Telecommunications Industry Solutions (ATIS) brings together the top global ICT companies to advance the industry’s business priorities. ATIS’ 150 member companies are currently working to address network reliability, 5G, robocall mitigation, smart cities, artificial intelligence-enabled networks, distributed ledger/blockchain technology, cybersecurity, IoT, emergency services, quality of service, billing support, operations and much more.
    [Show full text]
  • Captive Portal Detection Error May Be Triggered If There Is HTTP 302 Response Code Received PRS-325375 While Connecting to IVE
    Pulse Connect Secure Release Notes 8.1 R4 Build 37085: July 2015 Revision 01 Contents Introduction......................................................................................................................... 1 Interoperability and Supported Platforms ............................................................................ 2 Noteworthy changes in 8.1r4 Release ................................................................................ 2 Problems Resolved in 8.1R4 Release ................................................................................ 2 Known Issues in 8.1R3.2 release ....................................................................................... 4 Problems Resolved in 8.1R3.1 Release ............................................................................. 4 Pulse Connect Secure New Features in 8.1R3 ................................................................... 5 Noteworthy changes in this Release................................................................................... 6 Problems Resolved in 8.1R3 Release ................................................................................ 6 Known Issues in this release .............................................................................................. 7 Pulse Connect Secure Access New Features in 8.1R2 Release ........................................ 8 Disable TLS 1.0 ....................................................................................................... 8 New Functionality to create role mapping rules
    [Show full text]
  • Filtering and Identifying Web Activity by User Name
    Wavecrest®TechBrief Filtering and Identifying Web Activity by User Name www.wavecrest.net When a company implements a Web filtering and monitoring solution, it typically wants to filter and monitor the Web traffic flowing through its network by user name versus IP address for various reasons. Some of these reasons include curtailing casual surfing, protecting against security threats, and conserving bandwidth. Furthermore, a company’s Acceptable Use Policy (AUP) is usually based on user names and/or groups of user names. Therefore, the application that enforces and monitors the company’s AUP needs to identify Web activity by user name. IP addresses can be dynamic, and sometimes more than one employee can log on to a computer, and hence, more than one user name will be using the same IP address. Many an IT administrator is tasked with ensuring that the company’s employees are going through the proxy that is in place, so that Web activity can be monitored by user name. To get user names and authenticate users, IT administrators can choose any of the proxy configuration options and authentication methods described below. Depending on the company’s preference, one proxy configuration option may be more favorable than the other. Here, we will discuss applying browser settings manually, pushing out group policies using Active Directory (AD), using a captive portal, and installing client software. We will also touch on the different ways that you can authenticate your Internet users using our CyBlock products. Applying Browser Settings Manually Applying browser settings involves identifying a proxy server which is required if you need user names.
    [Show full text]
  • 9 Caching Proxy Server
    webXaccelerator: Owner's Guide by Luis Soltero, Ph.D., MCS Revision 1.06 February 10, 2010 (v1.2.3.10-RELEASE) Copyright © 2010 Global Marine Networks, LLC Table of Contents 1 Quick Start..............................................................................................................................................5 2 Introduction.............................................................................................................................................8 3 Initial Installation and Configuration......................................................................................................9 3.1 Connections.....................................................................................................................................9 3.2 Power-up..........................................................................................................................................9 3.3 Power-down...................................................................................................................................10 3.4 Web Administrator........................................................................................................................10 3.5 LAN Setup.....................................................................................................................................10 3.6 WAN Setup....................................................................................................................................11 3.7 WAN2 (Backup WAN) Setup........................................................................................................13
    [Show full text]
  • Tunneled Internet Gateway Wi-Fi Access for Mobile Devices in High-Security Environments Table of Contents
    WHITE PAPER TUNNELED INTERNET GATEWAY Wi-FI ACCESS FOR MOBILE DEVICES IN High-SECURitY ENVIRONMENTS TABLE OF CONTENTS THE ChALLENGE: Wi-FI ACCESS FOR MOBILE DEVICES IN high-SECURitY ENVIRONMENTS 3 ARUBA TUNNELED INTERNET GATEWAY SOLUtiON 3 HOW thE TUNNELED INTERNET GATEWAY WORKS 3 APPENDIX 5 TOPOLOGY DIAGRAMS 8 ABOUT ARUBA NETWORKS, INC. 9 WHITE PAPER TUNNELED INTERNET GATEWAY THE CHALLENGE: WI-FI ACCESS FOR MOBILE HOW THE TUNNELED INTERNET GATEWAY WORKS DEVICES IN HIGH-SECURITY ENVIRONMENTS Summary Since the debut of the iPhone in 2007, the private sector The Tunneled Internet Gateway is enabled through software has seen a proliferation of personal mobile devices used in configuration to any new or existing controller-based Aruba the workplace. Government customers, while slower to WLAN. Mobile users connect their devices to the Internet adopt commercially available mobile devices in the gateway SSID, creating an encrypted session with an Aruba workplace, recognize the cost and productivity advantages Mobility Controller deployed in the restricted network. and are looking for ways to increase their usage and speed- up adoption. The controller maintains logical separation between Internet sessions and restricted sessions using a Common Criteria Many civilian and military organizations have already begun EAL4+ validated firewall, then routes Internet traffic through large-scale acquisitions of commercial off-the-shelf (COTS) an additional encrypted data tunnel to a router attached to a mobile devices for distribution to relevant personnel. The commercial Internet service provider. The result is a secure, February 2013 purchase by the U.S. Department of Defense simple and low-cost network overlay with strong separation of 630,000 Apple iOS-based mobile devices is just one between restricted and Internet data.
    [Show full text]
  • Anyconnect Captive Portal Detection and Remediation
    Contents Introduction Prerequisites Requirements Components Used Background Information Captive Portal Remediation Requirements Captive Portal Hotspot Detection Captive Portal Hotspot Remediation False Captive Portal Detection AnyConnect Behavior Captive Portal Incorrectly Detected with IKEV2 Workarounds Disable the Captive Portal Feature Introduction This document describes the Cisco AnyConnect Mobility Client captive portal detection feature and the requirements for it to function correctly. Many wireless hotspots at hotels, restaurants, airports, and other public places use captive portals in order to block user access to the Internet. They redirect HTTP requests to their own websites that require users to enter their credentials or acknowledge terms and conditions of the hotspot host. Prerequisites Requirements Cisco recommends that you have knowledge of the Cisco AnyConnect Secure Mobility Client. Components Used The information in this document is based on these software versions: ● AnyConnect Version 3.1.04072 ● Cisco Adaptive Security Appliance (ASA) Version 9.1.2 The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command. Background Information Many facilities that offer Wi-Fi and wired access, such as airports, coffee shops, and hotels, require users to pay before they obtain access, agree to abide by an acceptable
    [Show full text]
  • Browser History Stealing with Captive Wi-Fi Portals
    Browser History Stealing with Captive Wi-Fi Portals Adrian Dabrowski, Georg Merzdovnik, Nikolaus Kommenda, Edgar Weippl [email protected] Twitter: @atrox_at 2016-05-26 Public Wi-Fi Hotspots ● Like a well in a village Internet ● We gather there, pull up a bucket or two of “Internet” ● Look at the sign from the sponsor ● … and move on. What is a “Captive Portal”? Why Captive Portal ● Omnipresent in Wi-Fi Hotspots ● Used by you probably right now (in this very hotel) ● Has an elevated position on the network ● Man-in-the-Middle by design ● Sponsors of a Wi-Fi want us to see their messages (and accept the disclaimer) ● There is no standard for that ● Let's inject it into your traffic… Browser History Stealing, again? ● Baron, 2002 ● :visited link color TODO: ● Ruderman, 2000 Groundhog ● :visited can load images ● Jang, 2010 ● Sites are actively trying to steal history History, so what? ● Culture & Language ● Amazon.fr, Amazon.jp ● Sexual orientation ● grindr.com, transblog.de ● Other websites that give ● Partnership status interesting insights ● Okcupid.com, parship.com ● Medical conditions ● Employer ● Political campaigns ● intranet.ibm.com ● Religious communities Source: MindSource April 1996 BOF; Client State Tracking with Netscape Cookies; M. Strata Rose; [email protected] Source: MindSource April 1996 BOF; Client State Tracking with Netscape Cookies; M. Strata Rose; [email protected] Cookies (or not enough state for HTTP) ● Two kinds ● Session cookies: usually forgotten when browser closed ● Persistent cookies: stored on disk with expiry date ● Only depend on the FQDN and Protocol ● XSS ● XSRF ● HTTP set cookie also used for HTTPS – Insecure set cookies mixed into the cookies over HTTPS http://cnn.com (+cookies) 302 redirect login.hotspotsys.com/login login.hotspotsys.com/login <html>….
    [Show full text]
  • Captive Portal
    User module Captive Portal APPLICATION NOTE USED SYMBOLS Used Symbols Danger – important notice, which may have an influence on the user’s safety or the function of the device. Attention – notice on possible problems, which can arise in specific cases. Information, notice – information, which contains useful advice or special interest. GPL License Source codes under GPL license are available free of charge by sending an email to: [email protected]. Conel s.r.o., Sokolska 71, 562 04 Usti nad Orlici, Czech Republic Manual issued in CZ, October 6, 2014 i CONTENTS Contents 1 Description of user module 1 2 Configuration 2 2.1 Global ......................................... 2 2.2 Welcome page .................................... 4 2.3 QoS .......................................... 4 3 How to create own welcome page 6 3.1 Simple page ...................................... 6 3.2 Login page ...................................... 6 3.3 Ban page ....................................... 7 3.4 Customized original URL .............................. 7 3.5 Example ........................................ 7 4 Status Overview 9 5 Recommended literature 10 ii LIST OF FIGURES List of Figures 1 Web Interface ..................................... 1 2 Global configuration form .............................. 3 3 Welcome page configuration form ......................... 4 4 QoS configuration form ............................... 5 iii LIST OF TABLES List of Tables 1 Available services .................................. 9 2 Connected customers ................................ 9 iv 1. DESCRIPTION OF USER MODULE 1. Description of user module User module Captive Portal is not contained in the standard router firmware. Uploading of this user module is described in the Configuration manual (see [1, 2]). Please note that this module is compatible only with firmware 4.0.0 or later in v2 routers! The user module is v3 routers platform compatible.
    [Show full text]
  • Captive Portal Authentication Via Facebook
    Grandstream Networks, Inc. Captive Portal Authentication via Facebook Table of Content SUPPORTED DEVICES ................................................................................................ 4 INTRODUCTION ............................................................................................................ 5 CAPTIVE PORTAL SETTINGS ..................................................................................... 6 Policy Configuration Page ................................................................................................................7 Landing Page Redirection ....................................................................................................... 10 Pre-Authentication Rules ........................................................................................................ 10 Post-Authentication Rules ....................................................................................................... 10 Guest Page ................................................................................................................................... 11 CONFIGURATION STEPS........................................................................................... 12 Create Facebook App .................................................................................................................... 12 Configure Captive Portal Policy with Facebook Authentication ....................................................... 17 Using GWN Master GUI (Standalone mode) ..........................................................................
    [Show full text]
  • Browser History Stealing with Captive Wi-Fi Portals
    Browser History Stealing with Captive Wi-Fi Portals Adrian Dabrowski∗, Georg Merzdovnik∗, Nikolaus Kommenday and Edgar Weippl∗ ∗SBA Research, Vienna, Austria Email: [email protected] yTechnische Universitat¨ Wien, Vienna, Austria Email: [email protected] Abstract—In this paper we show that HSTS headers and in public Wi Fi hotspot systems such as cafes,´ restaurants, long-term cookies (like those used for user tracking) are so airports, and hotels. The user is informed about the spon- prevailing that they allow a malicious Wi-Fi operator to gain significant knowledge about the past browsing history of users. sor of the access, possible restrictions as well as potential We demonstrate how to combine both into a history stealing payment methods and has to accept terms and conditions. attack by including specially crafted references into a captive After completion, the user is given access to the Internet. portal or by injecting them into legitimate HTTP traffic. Especially in transit areas the majority of users use hand-held Captive portals are used on many Wi-Fi Internet hotspots to devices such as tablets and smart phones. Additionally, these display the user a message, like a login page or an acceptable use policy before they are connected to the Internet. They are devices automatically connect to known Wi Fi access points. typically found in public places such as airports, train stations, or We specifically elaborate on these cases and their implications. restaurants. Such systems have been known to be troublesome for Public hotspots have been known to be troublesome in many many reasons.
    [Show full text]
  • Web Request Routing and Redirection What’S the Best Option for Your Web Security Deployment?
    Technical Brief Web Request Routing and Redirection What’s the best option for your web security deployment? Web Request Routing and Choosing the right method for redirecting traffic to your secure web gateway is Redirection absolutely essential to maximize protection for users who are accessing the Internet Key routing methods • Browser plug-ins. either on site within the corporate firewall or on the go. How you do it depends • Explicit proxy. on the available configuration options for your web security solution, your unique • Client proxy. IT infrastructure, and your chosen method of deployment. Never before have • Proxy auto-configuration (PAC). organizations of all sizes and infrastructure configurations had so many deployment • Generic routing encapsulation (GRE). choices for multi-layered web security. Flexible implementation options include on-premises appliances and blade servers, Software-as-a-Service (SaaS), or hybrid Key supporting technologies combinations. Secure web gateways in all of these form factors aim to protect users, • Web proxy auto-discovery (WPAD). devices, and networks against increasingly malicious and complex web threats through • VPNs, firewalls, routers, and inbound and outbound web filtering, advanced antivirus and anti-malware, and perimeter devices. policy enforcement. • Mobile device management. • IP anycast proxy URLs. Location. Location. Location. Where are your users and devices when they access the Internet? This is a key consideration in determining the best methods for redirecting web traffic to a secure web gateway solution. Whichever methods you choose, you must take into account user experience in terms of latency (performance degradation), location of the user, the device in use; ease of deployment and management; and above all, level of protection.
    [Show full text]
  • IB7200 - Connectivity in ICT4D
    IB7200 - connectivity in ICT4D Lecture 3 DNS - domain name system Mapping name and ipnumbers. Forward: name to number nic.lth.se. IN A 130.235.20.3 Reverse: number to name 3.20.235.130.in-addr.arpa. IN PTR nic.lth.se. DNS lookup Routing protocols Packets need to find way through net Static routing: Each way is added manually. Normally don’t use, gets messy very soon… Instead use dynamic routing Routing info protocol (RIP) Simple, early protocol. Distance vector. (low overhead) Rip v2 better. Never use rip v1. Avoid rip v2 Dynamic routing - OSPF Open Shortest Path First (OSPF) Used inside organisation. Very stable and compatible between vendors. Uses link state algoritm: All routers know the whole topology. Requires more computational power (no problem today) Border Gateway Protocol (BGP) Used between organizations (borders) Between autonomous systems (AS) Each AS has a number 0-65000 Can decide “policy routing” like not allowing traffic from some AS. My ORG Other ORG BGP OSFP AS y AS x Summary Use OSPF internally + BGP externally External AS2 External AS1 BGP BGP OSFP Multicast Send to many on a network. Internet Group Management Protocol (IGMP). Adresses 224.0.0.0 to 239.255.255.255 PIM - protocol independent multicast Within an organisation Multicast Source Discovery Protocol (MSDP) Between organisations IPv6 128 bit addreses. Written in hex. 2001:6b0:1:1d20:214:c2ff:fe3a:5eec/64 64 bit net + 4 bit host Host is normally 12 bit fill + 48 bit mac-addr Each “nibble” (character) is 4 bit KTH has 2001:6b0:1::/48 2001:06b0:0001 ie we have 2^18 networks each with 2^64 hosts… Wireless Local area - WiFi - WLAN 802.11* Metro - WIMAX 802.16 Wide area - GPRS: GSM, UMTS-3G VSAT - slow expensive but necesary in some places.
    [Show full text]