Layer 1-Informed Internet Topology Measurement

Total Page:16

File Type:pdf, Size:1020Kb

Layer 1-Informed Internet Topology Measurement Layer 1-Informed Internet Topology Measurement Ramakrishnan Durairajan Joel Sommers Paul Barford University of Colgate University University of Wisconsin-Madison [email protected] Wisconsin-Madison [email protected] [email protected] ABSTRACT 1. INTRODUCTION Understanding the Internet's topological structure continues Studies that aim to map the Internet's topological struc- to be fraught with challenges. In this paper, we investigate ture have been motivated for many years by a number of the hypothesis that physical maps of service provider infras- compelling applications including the possibilities of improv- tructure can be used to effectively guide topology discov- ing performance, security and robustness (e.g., [19]). While ery based on network layer TTL-limited measurement. The these motivations remain as compelling as ever, the ability goal of our work is to focus layer 3-based probing on broadly to accurately and comprehensively map the Internet has, for identifying Internet infrastructure that has a fixed geographic the most part, remained beyond our grasp. location such as POPs, IXPs and other kinds of hosting fa- The primary challenges to thoroughly mapping the In- cilities. We begin by comparing more than 1.5 years of TTL- ternet stem from its enormous size, distributed ownership, limited probe data from the Ark [25] project with maps of and constantly changing characteristics. Faced with these service provider infrastructure from the Internet Atlas [15] challenges, the most widely used approach to Internet map- project. We find that there are substantially more nodes ping has been based on gathering data from network-layer and links identified in the service provider map data ver- measurements using TTL-limited probes1. Great progress sus the probe data. Next, we describe a new method for has been made on solving some of the specific problems re- probe-based measurement of physical infrastructure called lated to using these network layer measurements for under- POPsicle that is based on careful selection of probe source- standing Internet topological characteristics. However, the destination pairs. We demonstrate the capability of our fact remains that layer 3 data are inherently tied to the method through an extensive measurement study using ex- management policies and operational objectives of service isting \looking glass" vantage points distributed throughout providers, which may be at odds with comprehensive and the Internet and show that it reveals 2.4 times more phys- accurate mapping of the Internet. ical node locations versus standard probing methods. To So, just what do we mean by an \Internet map"? At the demonstrate the deployability of POPsicle we also conduct lowest level, the Internet is composed of physical conduits tests at an IXP. Our results again show that POPsicle can that contain bundles of optical fiber, and that terminate at identify more physical node locations compared with stan- buildings that house routing and switching equipment. We dard layer 3 probes, and through this deployment approach refer to the collection of these data and their geographic lo- it can be used to measure thousands of networks world wide. cations as \physical maps" of the Internet. Several recent projects have begun to assemble repositories of physical In- Categories and Subject Descriptors ternet maps [15, 29]. These maps are valuable because they reflect a ground truth perspective of service provider infras- C.2.1 [Network Architecture and Design]: Network topol- tructure. These are in contrast with maps that have been ogy; C.2.3 [Network Operations]: Public networks generated based on layer 3 probes (e.g., [45]), which we re- fer to as \network-layer maps". Ideally, network-layer maps General Terms reflect a timely representation of network topology as well as the dynamic aspects of management and configurations. Algorithms, Design, Measurement In this paper we investigate the hypothesis that physical maps can be used to guide and reinforce the process of col- Keywords lecting layer 3 probe data toward the goal of expanding the Physical Internet, POPsicle probing heuristic scope of physical infrastructure captured in network-layer maps. This conjecture leads directly to two key research Permission to make digital or hard copies of all or part of this work for personal or questions that are the focus of our work: (i) how do phys- classroom use is granted without fee provided that copies are not made or distributed ical layer maps compare and contrast with network-layer for profit or commercial advantage and that copies bear this notice and the full cita- maps? and (ii) how can probe methods used by projects tion on the first page. Copyrights for components of this work owned by others than like Ark [25] be improved to reveal a larger portion of phys- ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re- ical infrastructure? We contend that some of the challenges publish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. 1 IMC’14, November 5–7, 2014, Vancouver, BC, Canada. Maps can also be created using BGP updates or Copyright 2014 ACM 978-1-4503-3213-2/14/11 ...$15.00. application-layer data, however those are not the focus of http://dx.doi.org/10.1145/2663716.2663737. this paper. 381 inherent in generating maps from layer 3 probes can be over- get networks using two core ideas: (i) source-destination come by using the constructive approach of first identifying pairs should be proximal to the target geographically and in key infrastructure (POPs, etc.) and then identifying nodes address space, and (ii) verification of measurements using (identified by disambiguating IP addresses or using DNS multiple sources is required. We verify the identification of names) that reside in those locations. infrastructure using location hints in DNS names and us- Our study begins by considering physical map data from ing records available in PeeringDB [5]. Our analysis shows the Internet Atlas (or Atlas) project and network-layer map that probing between sources and destinations that are both data from the Ark project. We focus specifically on infras- within the same autonomous system as the target(s) reveals tructure in North America. The Atlas repository includes the most physical infrastructure. data from 78 Internet service providers with over 2600 nodes The results of our targeting experiments motivate a new and over 3580 links. Nodes in the Atlas data refer to hosting heuristic algorithm for probe targeting that we call POPsi- centers or points of presence (POPs), with links referring to cle. We show that POPsicle finds 2.4 times as many nodes physical connections between those locations. We use Ark as are identified by Ark. We compare the number of POPs measurements collected from September 2011 to March 2013 found by POPsicle with POPs found using Rocketfuel [45] (approximately the same period over which the Atlas reposi- and in all cases POPsicle performs better. We also found tory has been assembled). We resolve the IP addresses from that IXPs play a critical role in the way probes traverse this corpus to DNS names and then use location hints to a given network. Specifically, sources that are co-located associate these with physical locations (e.g., cities), which with IXPs have the advantage of appearing|from a layer becomes the basis for our comparisons. 3 perspective|as being internal to any/all of the networks Several characteristics are immediately evident in the that are connected at that location. Thus, a single source data. Most prominent is the fact that among the 50 net- that is co-located within an IXP may enhance the identi- works that are the focus of our comparison study, we observe fication of infrastructure across all networks that connect many more nodes and links in the physical maps. There can to the IXP. This has the effect of significantly broadening be a number of explanations for this observation, including the scope of the infrastructure that can be identified using (i) the limitations of exploiting DNS naming conventions, our approach. To validate this idea, we deployed POPsi- (ii) the use of tunneling protocols (e.g., MPLS) or the lack cle at the Equinix IXP in Chicago, USA, and measured the of layer 3 services which can render nodes invisible to probes, number of POPs for 10 ISPs and found that POPsicle re- (iii) the limited perspective of the network mapping infras- veals almost all POPs compared to Atlas and extra POPs tructure and (iv) the fact that layer 3 routing configura- (in certain cases) compared to Ark. We also find through a tions may simply obviate the ability to observe all networks, case study of Cogent network that POPsicle identifies over nodes and links. This supposition is supported by the obser- 90% of the nodes identified in Atlas or by the reverse DNS vation that all Ark probes are confined to a minority subset technique of [21], compared with about 65% of the POPs of networks, with the majority of probes traversing an even identified through Ark, and only 25% identified in the most smaller subset of networks. Despite this, there are still some recently available Rocketfuel data. nodes/locations/links that appear in the network-layer map To summarize, the key contributions of our work are as but are not indicated in the physical map. This can be ex- follows. First, we perform a first-of-its-kind comparison of plained by physical maps that are out of date or are either large repositories of physical and network maps and find intentionally or erroneously incomplete. that physical maps typically reveal a much larger number The differences between the physical and network-layer of nodes (e.g., POPs and hosting infrastructure).
Recommended publications
  • NOAA Technical Report NOS NGS 60
    NOAA Technical Report NOS NGS 60 NAD83 (NSR2007) National Readjustment Final Report Dale G. Pursell Mike Potterfield Rockville, MD August 2008 NOAA Technical Report NOS NGS 60 NAD 83(NSRS2007) National Readjustment Final Report Dale G. Pursell Mike Potterfield Silver Spring, MD August 2008 U.S. DEPARTMENT OF COMMERCE National Oceanic and Atmospheric Administration National Ocean Service Contents Overview ........................................................................................................................ 1 Part I. Background .................................................................................................... 5 1. North American Datum of 1983 (1986) .......................................................................... 5 2. High Accuracy Reference Networks (HARNs) .............................................................. 5 3. Continuously Operating Reference Stations (CORS) .................................................... 7 4. Federal Base Networks (FBNs) ...................................................................................... 8 5. National Readjustment .................................................................................................... 9 Part II. Data Inventory, Assessment and Input ....................................... 11 6. Preliminary GPS Project Analysis ................................................................................11 7. Master File .....................................................................................................................11
    [Show full text]
  • A Longitudinal and Cross-Dataset Study of Internet Latency and Path Stability
    A Longitudinal and Cross-Dataset Study of Internet Latency and Path Stability Mosharaf Chowdhury Rachit Agarwal Vyas Sekar Ion Stoica Electrical Engineering and Computer Sciences University of California at Berkeley Technical Report No. UCB/EECS-2014-172 http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-172.html October 11, 2014 Copyright © 2014, by the author(s). All rights reserved. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission. A Longitudinal and Cross-Dataset Study of Internet Latency and Path Stability Mosharaf Chowdhury Rachit Agarwal Vyas Sekar Ion Stoica UC Berkeley UC Berkeley Carnegie Mellon University UC Berkeley ABSTRACT Even though our work does not provide new active mea- We present a retrospective and longitudinal study of Internet surement techniques or new datasets, we believe that there is value in this retrospective analysis on several fronts. First, it latency and path stability using three large-scale traceroute provides a historical and longitudinal perspective of Internet datasets collected over several years: Ark and iPlane from path properties that are surprisingly lacking in the measure- 2008 to 2013 and a proprietary CDN’s traceroute dataset spanning 2012 and 2013. Using these different “lenses”, we ment community today. Second, it can help us revisit and revisit classical properties of Internet paths such as end-to- reappraise classical assumptions about path latency and sta- end latency, stability, and of routing graph structure.
    [Show full text]
  • Misleading Stars: What Cannot Be Measured in the Internet?
    Noname manuscript No. (will be inserted by the editor) Misleading Stars: What Cannot Be Measured in the Internet? Yvonne-Anne Pignolet · Stefan Schmid · Gilles Tredan Abstract Traceroute measurements are one of the main in- set can help to determine global properties such as the con- struments to shed light onto the structure and properties of nectivity. today’s complex networks such as the Internet. This arti- cle studies the feasibility and infeasibility of inferring the network topology given traceroute data from a worst-case 1 Introduction perspective, i.e., without any probabilistic assumptions on, e.g., the nodes’ degree distribution. We attend to a scenario Surprisingly little is known about the structure of many im- where some of the routers are anonymous, and propose two portant complex networks such as the Internet. One reason fundamental axioms that model two basic assumptions on is the inherent difficulty of performing accurate, large-scale the traceroute data: (1) each trace corresponds to a real path and preferably synchronous measurements from a large in the network, and (2) the routing paths are at most a factor number of different vantage points. Another reason are pri- 1/α off the shortest paths, for some parameter α 2 (0; 1]. vacy and information hiding issues: for example, network In contrast to existing literature that focuses on the cardi- providers may seek to hide the details of their infrastructure nality of the set of (often only minimal) inferrable topolo- to avoid tailored attacks. gies, we argue that a large number of possible topologies Knowledge of the network characteristics is crucial for alone is often unproblematic, as long as the networks have many applications as well as for an efficient operation of the a similar structure.
    [Show full text]
  • PAX A920 Mobile Smart Terminal Quick Setup Guide
    PAX A920 QUICK SETUP GUIDE PAX A920 Mobile Smart Terminal Quick Setup Guide 2018000702 v1.8 1 PAX Technology® Customer Support [email protected] (877) 859-0099 www.pax.us PAX A920 QUICK SETUP GUIDE PAX A920 Mobile Terminal Intelligence of an ECR in a handheld point of sale. The PAX A920 is an elegantly designed compact secure portable payment terminal powered by an Android operating system. The A920 comes with a large high definition color display. A thermal printer and includes NFC contactless and electronic signature capture. Great battery life for portable use. 2018000702 v1.8 2 PAX Technology® Customer Support [email protected] (877) 859-0099 www.pax.us PAX A920 QUICK SETUP GUIDE 1 What’s in The Box The PAX A920 includes the following items in the box. 2018000702 v1.8 3 PAX Technology® Customer Support [email protected] (877) 859-0099 www.pax.us PAX A920 QUICK SETUP GUIDE 2 A920 Charging Instructions Before starting the A920 battery should be fully charged by plugging the USB to micro USB cord to a PC or an AC power supply and then plug the other end with the micro USB connector into the micro USB port on the left side of the terminal. Charge the battery until full. Note: There is a protective cover on the new battery terminals that must be removed before charging the battery. See Remove and Replace Battery section. 2018000702 v1.8 4 PAX Technology® Customer Support [email protected] (877) 859-0099 www.pax.us PAX A920 QUICK SETUP GUIDE 3 A920 Buttons and Functions Front Description 6 1 2 7 3 8 9 4 5 2018000702 v1.8 5 PAX Technology® Customer Support [email protected] (877) 859-0099 www.pax.us PAX A920 QUICK SETUP GUIDE 3.1 A920 Buttons and Functions Front Description 1.
    [Show full text]
  • PAX-It! TM Applications the Paxcam Digital USB 2.0 Camera System
    Digital Imaging Workflow for Industrial From the Makers of PAX-it! TM Applications The PAXcam Digital USB 2.0 Camera System l Affordable camera for microscopy, with an easy-to-use interface l Beautiful, high-resolution images; true color rendition l Fully integrated package with camera and software l USB 2.0 interface for the fastest live digital color preview on the market l Easy-to-use interface for color balance, exposure & contrast control, including focus indicator tool l Adjustable capture resolution settings (true optical resolution -- no interpolation) l Auto exposure, auto white balance and manual color adjustment are supported l Create and apply templates and transparencies over the live image l Acquire images directly into the PAX-it archive for easy workflow l Easy one-cable connection to computer; can also be used on a laptop l Adjustable region of interest means smaller file sizes when capturing images l PAXcam interface can control multiple cameras from the same computer l Stored presets may be used to save all camera settings for repeat conditions Capture Images Directly to PAX-it Image Database Software Includes PAXcam Video Agent for motion video capture l Time lapse image capture l Combine still images to create movie files l Extract individual frames of video clips as bitmap images Live preview up to 40 fps PAX-it! l File & retrieve images in easy-to-use cabinet/folder structure l Store images, video clips, documents, and other standard digital file types l Images and other files are in a searchable database that you
    [Show full text]
  • Recent Results in Network Mapping: Implications on Cybersecurity
    Recent Results in Network Mapping: Implications on Cybersecurity Robert Beverly, Justin Rohrer, Geoffrey Xie Naval Postgraduate School Center for Measurement and Analysis of Network Data (CMAND) July 27, 2015 DHS S&T Cyber Seminar R. Beverly, J. Rohrer, G. Xie (NPS) Advances in Network Mapping DHS S&T Cyber Seminar 1 / 50 Intro Outline 1 Intro 2 Background 3 Project 4 Recent Advances 5 Future R. Beverly, J. Rohrer, G. Xie (NPS) Advances in Network Mapping DHS S&T Cyber Seminar 2 / 50 Intro CMAND Lab CMAND Lab @ NPS Naval Postgraduate School Navy’s Research University Located in Monterey, CA '1500 students, military officers, foreign military, DoD civilians Center for Measurement and Analysis of Network Data 3 NPS professors, 2 NPS staff 1 PhD student, rotating cast of ∼ 5-8 Master’s students Collaborators: CAIDA, ICSI, MIT, Akamai, Cisco, Verisign, ::: Focus: Large-scale network measurement and data mining Network architecture and security R. Beverly, J. Rohrer, G. Xie (NPS) Advances in Network Mapping DHS S&T Cyber Seminar 3 / 50 Intro Output Select Recent Publications (bold DHS-supported): 1 Luckie, Beverly, Wu, Allman, Claffy, “Resilience of Deployed TCP to Blind Off-Path Attacks,” in ACM IMC 2015 2 Huz, Bauer, Claffy, Beverly, “Experience in using Mechanical Turk for Network Measurement,” in ACM C2BID 2015 3 Beverly, Luckie, Mosley, Claffy, “Measuring and Characterizing IPv6 Router Availability,” in PAM 2015 4 Beverly, Berger, “Server Siblings: Identifying Shared IPv4/IPv6 Infrastructure,” in PAM 2015 5 Alt, Beverly, Dainotti, “Uncovering Network Tarpits with Degreaser,” in ACSAC 2014 6 Craven, Beverly, Allman, “A Middlebox-Cooperative TCP for a non End-to-End Internet,” in ACM SIGCOMM 2014 7 Baltra, Beverly, Xie, “Ingress Point Spreading: A New Primitive for Adaptive Active Network Mapping,” in PAM 2014 R.
    [Show full text]
  • Freebsd and Netbsd on Small X86 Based Systems
    FreeBSD and NetBSD on Small x86 Based Systems Dr. Adrian Steinmann <[email protected]> Asia BSD Conference in Tokyo, Japan March 17th, 2011 1 Introduction Who am I? • Ph.D. in Mathematical Physics (long time ago) • Webgroup Consulting AG (now) • IT Consulting Open Source, Security, Perl • FreeBSD since version 1.0 (1993) • NetBSD since version 3.0 (2005) • Traveling, Sculpting, Go AsiaBSDCon Tutorial March 17, 2011 in Tokyo, Japan “Installing and Running FreeBSD and NetBSD on Small x86 Based Systems” Dr. Adrian Steinmann <[email protected]> 2 Focus on Installing and Running FreeBSD and NetBSD on Compact Flash Systems (1) Overview of suitable SW for small x86 based systems with compact flash (CF) (2) Live CD / USB dists to try out and bootstrap onto a CF (3) Overview of HW for small x86 systems (4) Installation strategies: what needs special attention when doing installations to CF (5) Building your own custom Install/Maintenance RAMdisk AsiaBSDCon Tutorial March 17, 2011 in Tokyo, Japan “Installing and Running FreeBSD and NetBSD on Small x86 Based Systems” Dr. Adrian Steinmann <[email protected]> 3 FreeBSD for Small HW Many choices! – Too many? • PicoBSD / TinyBSD • miniBSD & m0n0wall • pfSense • FreeBSD livefs, memstick • NanoBSD • STYX. Others: druidbsd, Beastiebox, Cauldron Project, ... AsiaBSDCon Tutorial March 17, 2011 in Tokyo, Japan “Installing and Running FreeBSD and NetBSD on Small x86 Based Systems” Dr. Adrian Steinmann <[email protected]> 4 PicoBSD & miniBSD • PicoBSD (1998): Initial import into src/release/picobsd/ by Andrzej Bialecki <[email protected]
    [Show full text]
  • A Disjunctive Internet Cartographer∗
    DisCarte: A Disjunctive Internet Cartographer∗ Rob Sherwood Adam Bender Neil Spring University of Maryland University of Maryland University of Maryland [email protected] [email protected] [email protected] ABSTRACT 1. INTRODUCTION Internet topology discovery consists of inferring the inter-router Knowledge of the global topology of the Internet allows network connectivity (“links”) and the mapping from IP addresses to routers operators and researchers to determine where losses, bottlenecks, (“alias resolution”). Current topology discovery techniques use failures, and other undesirable and anomalous events occur. Yet TTL-limited “traceroute” probes to discover links and use direct this topology remains largely unknown: individual operators may router probing to resolve aliases. The often-ignored record route know their own networks, but neighboring networks are amorphous (RR) IP option provides a source of disparate topology data that clouds. The lack of precise global topology information hinders could augment existing techniques, but it is difficult to properly network diagnostics [42, 24, 15, 17], inflates IP path lengths [10, align with traceroute-based topologies because router RR imple- 39, 36, 43], reduces the accuracy of Internet models [46, 25, 16], mentations are under-standardized. Correctly aligned RR and trace- and encourages overlay networks to ignore the underlay [2, 27]. route topologies have fewer false links, include anonymous and Because network operators rarely publish their topologies, and hidden routers, and discover aliases for routers that do not respond the IP protocols have little explicit support for exposing the In- to direct probing. More accurate and feature-rich topologies ben- ternet’s underlying structure, researchers must infer the topology efit overlay construction and network diagnostics, modeling, and from measurement and observation.
    [Show full text]
  • Edge-Aware Inter-Domain Routing for Realizing Next-Generation Mobility Services∗
    Edge-Aware Inter-Domain Routing for Realizing Next-Generation Mobility Services∗ Shreyasee Mukherjee, Shravan Sriram, Dipankar Raychaudhuri WINLAB, Rutgers University, North Brunswick, NJ 08902, USA Email: fshreya, sshravan, [email protected] Abstract—This work describes a clean-slate inter-domain rout- Emerging Internet requirements have motivated several ing protocol designed to meet the needs of the future mobile clean-slate Internet design projects such as Named Data Net- Internet. In particular, we describe the edge-aware inter-domain work (NDN) [4], XIA [5] and MobilityFirst [6]. Previously routing (EIR) protocol which provides new abstractions of aggregated-nodes (aNodes) and virtual-links (vLinks) for express- published works on these architectures have addressed mobil- ing network topologies and edge network properties necessary ity requirements at the intra-domain level [7], [8], but support to address next-generation mobility related routing scenarios for end-to-end mobility services across multiple networks which are inadequately supported by the border gateway protocol remains an important open problem. In this paper, we first (BGP) in use today. Specific use-cases addressed by EIR include motivate the need for clean-slate approaches to inter-domain, emerging mobility service scenarios such as multi-homing across WiFi and cellular, multipath routing over several access networks, and then describe the key features of a specific new design and anycast access from mobile devices to replicated cloud called EIR (edge-aware inter-domain routing) intended to services. Simulation results for protocol overhead are presented meet emerging requirements. The proposed protocol provides for a global-scale Caida topology, leading to an identification new abstractions for expressing network topology and edge of parameters necessary to obtain a good balance between network properties necessary to support a full range of mo- overhead and routing table convergence time.
    [Show full text]
  • Parallel MPI I/O in Cube: Design & Implementation
    Parallel MPI I/O in Cube: Design & Implementation Bine Brank A master thesis presented for the degree of M.Sc. Computer Simulation in Science Supervisors: Prof. Dr. Norbert Eicker Dr. Pavel Saviankou Bergische Universit¨atWuppertal in cooperation with Forschungszentrum J¨ulich September, 2018 Erkl¨arung Ich versichere, dass ich die Arbeit selbstst¨andigverfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich gemacht habe. Mit Abgabe der Abschlussarbeit erkenne ich an, dass die Arbeit durch Dritte eingesehen und unter Wahrung urheberrechtlicher Grunds¨atzezi- tiert werden darf. Ferner stimme ich zu, dass die Arbeit durch das Fachgebiet an Dritte zur Einsichtnahme herausgegeben werden darf. Wuppertal, 27.8.2017 Bine Brank 1 Acknowledgements Foremost, I would like to express my deepest and sincere gratitude to Dr. Pavel Saviankou. Not only did he introduce me to this interesting topic, but his way of guiding and supporting me was beyond anything I could ever hoped for. Always happy to discuss ideas and answer any of my questions, he has truly set an example of excellence as a researcher, mentor and a friend. In addition, I would like to thank Prof. Dr. Norbert Eicker for agreeing to supervise my thesis. I am very thankful for all remarks, corrections and help that he provided. I would also like to thank Ilya Zhukov for helping me with the correct in- stallation/configuration of the CP2K software. 2 Contents 1 Introduction 7 2 HPC ecosystem 8 2.1 Origins of HPC . 8 2.2 Parallel programming . 9 2.3 Automatic performance analysis . 10 2.4 Tools .
    [Show full text]
  • A Technique for Network Topology Deception
    A Technique for Network Topology Deception Samuel T. Trassare Robert Beverly David Alderson Naval Postgraduate School Naval Postgraduate School Naval Postgraduate School Email: [email protected] Email: [email protected] Email: [email protected] Abstract—Civilian and military networks are continually topological deception may provide the perception of a network probed for vulnerabilities. Cyber criminals, and autonomous that resembles, or completely disguises, the underlying true botnets under their control, regularly scan networks in search network by varying attributes such as nodes, node count or of vulnerable systems to co-opt. Military and more sophisticated the redundancy and diversity of links between nodes. adversaries may also scan and map networks as part of re- connaissance and intelligence gathering. This paper focuses on For instance, the outward topology presented to an attacker adversaries attempting to map a network’s infrastructure, i.e., may be chosen to protect high-value nodes or links within the the critical routers and links supporting a network. We develop network. Thus we may cause the adversary to take specific a novel methodology, rooted in principles of military deception, actions, such as attacking highly fault-tolerant nodes that for deceiving a malicious traceroute probe and influencing the appear weak, or avoiding weak nodes that appear highly structure of the network as inferred by a mapping adversary. Our Linux-based implementation runs as a kernel module at fault-tolerant. The methodology accommodates any true input a border router to present a deceptive external topology. We topology, while the deceptive topology can be modified easily construct a proof-of-concept test network to show that a remote and frequently to further confound the adversarys efforts to adversary using traceroute to map a defended network can be identify vulnerabilities in the network infrastructure.
    [Show full text]
  • Release 0.11.0
    mpiFileUtils Documentation Release 0.11.0 HPC Sep 29, 2021 Contents 1 Overview 1 2 User Guide 3 2.1 Project Design Principles........................................3 2.1.1 Scale..............................................3 2.1.2 Performance...........................................3 2.1.3 Portability............................................3 2.1.4 Composability..........................................4 2.2 Utilities..................................................4 2.3 Experimental Utilities..........................................4 2.4 libmfu..................................................4 2.4.1 libmfu: the mpiFileUtils common library...........................5 2.4.2 mfu_flist.............................................5 2.4.3 mfu_path............................................5 2.4.4 mfu_param_path........................................5 2.4.5 mfu_io..............................................5 2.4.6 mfu_util.............................................6 2.5 Build...................................................6 2.5.1 Build everything with Spack..................................6 2.5.2 Build everything directly....................................6 2.5.3 Build everything directly with DAOS support.........................8 2.5.4 Build mpiFileUtils directly, build its dependencies with Spack................8 3 Man Pages 9 3.1 dbcast...................................................9 3.1.1 SYNOPSIS...........................................9 3.1.2 DESCRIPTION.........................................9 3.1.3 OPTIONS............................................9
    [Show full text]