Skip to Content
[CAIDA - Center for Applied Internet Data Analysis logo]
Center for Applied Internet Data Analysis
Science of Internet Security: Technology and Experimental Research
Sponsored by:
Department of Homeland Security (DHS)
Using the versatile Ark measurement platform, we will conduct measurements and analysis for documented explanations of structural and dynamic aspects of the Internet infrastructure relevant to cybersecurity vulnerabilities

Funding source: DHS S&T contract HHSP 233201600012C. Period of performance: May 24, 2016 - May 23, 2018.

Statement of Work

Year 1

Task 1: Support for Macroscopic Security and Stability Monitoring and Analysis
Deliverable: 24/7 Stability measurement and analysis systemsoftwareMay 23, 2017
1.1Generate the target list of prefixesDevelop and implement a system to process and sanitize BGP data from Routeviews and RIPE RIS creating a list of target prefixes based on a 1-week sliding window24/7 monitoring of all Routeviews and RIPE RIS collectors; keeping in memory a 1-week sliding window of targetsSoftware module that continuously interrogates BGP Watcher applicationJul 8, 2016done, paper
1.2Dynamically identify which IPs to probe with tracerouteDevelop and implement selection of the target IP for each prefix in the target list based on the current state of prefixes announced on BGPAbility to perform the selection within 1 hourComponent of the software module developed in the subtask 1.1Sep 8, 2016done
1.3Improve AS path inference strategiesImprove our algorithms to infer AS paths from traceroutes minimizing two artifacts of traceroute measurement: false inferences due to third-party addresses, and missing links due to routers responding with IP addresses from interfaces that hide the presence of an AS hopImprovement of accuracy when comparing inferred AS paths to AS paths announced on BGP respectively from Ark nodes and BGP monitors located in the same ASSoftware implementation of an improved algorithmFeb 8, 2017in progress
1.4Create measurement and data processing pipelineRun the systems to gather the target list, execute traceroutes from vantage points, infer AS paths, and curate resulting data24/7 monitoring of the entire IPv4 routed address spaceSystem in productionMay 8, 2017
1.5Release data sets through IMPACTMake resulting datasets available through IMPACTDatasets indexed in IMPACTDataMay 23, 2017
Task 2: Mapping Peering Interconnections at the Router Level
Deliverable: Software to infer border router ownershipsoftwareNov 23, 2016done
Deliverable: Data set of border mapping inferencesdataJan 23, 2017
2.1Refine algorithms to infer peering interconnections at the router levelExplore which methods yield most accurate inferences and apply heuristics to traceroute data, focusing primarily on the connectivity found in the network of the vantage pointInfer router ownership for all border routers of a VPDocumented heuristics and software to run on traces collected from a probing VP and infer the ownership of the VP's border routersSep 23, 2016done
2.2Deploy border-mapping process on Ark infrastructureDeploy the software from subtask 2.1 on all VPs of the Ark infrastructure to infer the border links of the hosting networksData set indexed in IMPACTOngoing dataset of border mapping inferences from all Ark monitorsOct 23, 2016
2.3Validate border-mapping inferencesMake our inferences publicly available and solicit feedback from operators. Use BGP data for validation when Ark VPs is collocated with a BGP monitor.Maximize a set of validation data; focus on covering the set of networks hosting Ark VPsSet of ground-truth data relating to border router ownershipFeb 23, 2017done
2.4Refine software to support border-mapping on resource- constrained platformsAdapt prober software of our measurement system to accept commands from a remote server, thus reducing the memory footprint on the VPComputationally and memory-efficient probing software, secure, and robust to middlebox-initiate timeouts of idle connectionsUpdated probing softwareMay 23, 2017
Task 3: Mapping Peering Interconnections at the Facility Level
Deliverable: Annotated facility-aware map of peering interconnectiondataMay 23, 2017
3.1Generate map of interconnection facilities and associated peering networksMaintain a detailed map of the interconnection facilities and the network that have presence there by manually assembling it from existing data sources (PeeringDB,PCH)Data set indexed in IMPACTData set compiled from best available data on interconnection facilities and participating networksJul 23, 2016, then continue to updatepre-proposal study
3.2Develop and test method to infer engineering approach to interconnectionDevelop and test new techniques to infer a type of engineering approach to interconnection (private peering with cross-connect, public peering, private interconnects over the public switch fabric, and remote peering)Annotated data set indexed in IMPACTAnnotations of data set from subtask 3.1Feb 23, 2017
3.3Alias resolution of interconnection IP addressesUsing existing state-of-the-art alias resolution techniques and strategically executed traceroute measurements, classify interconnection IP addresses according to router hardware they shareRouter-level topology data set indexed in IMPACTData file of IP addresses and router identifier to which each IP address mapsApr 23, 2017
3.4Facility-aware map of peering interconnectionMerge the techniques developed in subtask 3.2 and 3.3 to produce a richly annotated global map of peering facilitiesAnnotated data set indexed in IMPACTFacility-aware map annotated with peeringMay 23, 2017
Task 4: Measurements of TCP Behavior to Understand Security Vulnerabilities
Deliverable: Report on observed prevalence of TCP vulnerabilitiesreportMay 23, 2017
4.1Establish the scope of studyDescribe set of attacks and defenses we will study, e.g. blind in-window attackWritten description of set of attacksFeb 23, 2017pre-proposal
4.2Provide measurement techniques to test for vulnerabilities described in subtask 4.1Develop and test active measurement techniques to test for the vulnerabilitiesDocumented techniques validated against known systems and/or with network operatorsSet of techniquess to apply for subtask 4.3May 23, 2017
4.3Apply technique to measure TCP ecosystemApply active measurement technique developed and tested in subtask 4.2 to TCP stacks deployed in a web server environmentPublic data setDataApr 23, 2017
4.4Document findingsAssess TCP vulnerabilities of popular web server environment based on measurement, publish results in a peer-reviewed venueDocumentation of vulnerabilitiesPaperMay 23, 2017

Year 2

Task 5: Identifying Grey Market IPv4 Address Transfers
Deliverable: Software to infer address transfers from BGP datasoftwareAug 23, 2017
Deliverable: Monthly lists of candidate transferred prefixesdataMay 23, 2018
5.1Refine BGP-based filtersRefine the set of BGP-based filters to rule out candidate transfers due to Provider-Aggregatable space. Iteratively validate the results against the set of transfers reported to RIRs, and modify filters to eliminate false negativesMinimize number of false negatives in the algorithm based on the lists of transfers reported by the RIRsAlgorithms and software to analyze BGP data to detect candidate transfers and filter out transfers due to legitimate reasonsAug 23, 2017
5.2Use DNS lookups of the entire routed address space to detect transfersSet up regular and frequent reverse DNS lookups of the entire routed IPv4 address space capturing both DNS names and SOA records to reveal information about the ownership of IP prefixes. Develop techniques to detect transfers using the DNS data. High-frequency (at least once a month) DNS lookups of the entire routed address spacePeriodic reverse DNS scans of the routed address space (data); algorithms/software to extract information about prefix transfers from DNS dataNov 23, 2017
5.3Use IP-level data to detect transfersDevise a strategy for consistent and frequent probing of routed prefixes from Ark monitors. Build a history of router-level paths and RTT information from Ark monitors toward routed prefixes. Use collected data to develop data-plane signatures for prefix transfers, and for prefix movements due to other causes such as non-BGP speakers changing upstream providers. Use collected RTT data for constraint-based geolocation to identify prefix transfersFrequent (at least once a week) measurements of IP paths and RTTs from each Ark monitor toward transferred prefixesDatabase with history of IP paths and RTTs toward routed prefixes (data); algorithms/software to extract signatures of prefix transfers from the IP path dataApr 23, 2018
5.4Combine, curate, and validate results from all methodsCombine the techniques developed in subtasks 5.1. 5.2, and 5.3 for detection of transfers and filtering of candidate transfers due to legitimate reasonsProduce monthly lists of candidate transferred prefixes, with low false negatives and false positivesPeriodic lists of transferred prefixesMay 23, 2018
Task 6: Internet Router-Level Topology Mapping on Demand
Deliverable: Software and API for the on-demand alias resolutionsoftwareFeb 23, 2018
Deliverable: Database of known alias datadatabaseMay 23, 2018
6.1Improve fault-tolerance of MIDAR's Estimation stage probingIf a monitor has rebooted, restart the Estimation probing on just the rebooted monitor; if a monitor is down for an extended period, either (i) restart Estimation stage with the down monitor excluded, or (ii) let the Estimation stage finish, accepting that data from the down monitor may be lostAutomated execution of the Estimation stageAutomatic recovery from monitor failures during the Estimation stageJul 8, 2017
6.2Improve fault-tolerance of MIDAR's Discovery stage probingWhether a monitor has rebooted due to a brief power outage or suffered an extended outage, restart the Discovery stage with the down monitor excludedAutomated execution of the Discovery stageAutomatic recovery from monitor failures during the Discovery stageAug 8, 2017
6.3Improve fault-tolerance of MIDAR's Elimination and Corroboration "one-src" probingWhen probing "one-src" candidate alias sets that can be probed entirely from a single monitor, if a monitor has rebooted, restart the Elimination/ Corroboration probing on just this monitor; if a monitor is down for an extended period, redistribute its target list to the remaining monitors and conduct a follow-on Elimination/ Corroboration probing round on these previously failed targetsAutomated execution of "one-src" probingAutomatic recovery from monitor failures during "one-src" probingOct 23, 2017
6.4Improve fault-tolerance of MIDAR's Elimination and Corroboration "multi-src" probingWhen probing "multi-src" candidate alias sets (that must be probed from two or more monitors due to constraints of the "indir" probing method), modify the multi-src driver program to automatically detect and dynamically skip over down monitors. Investigate the feasibility of conducting a follow-on Elimination/ Corroboration probing round on the alias sets involving the down monitor, after redistributing these alias sets to remaining monitorsAutomated execution of "multi-src" probingAutomatic recovery from monitor failures during "multi-src" probingJan 23, 2018
6.5Scriptable API for on-demand alias resolutionImplement a scriptable command-line tool and/or a RESTful web API for submitting addresses for on-demand alias resolution and for retrieving resultsUser control for the on-demand alias resolution systemProgrammable API for interacting with the on-demand alias resolution systemFeb 23, 2018 (overlaps with 6.3 and 6.4)
6.6Query interface for known aliasesImplement a database backend for our known alias data (discovered by prior on-demand measurements or from ITDKs), and a scriptable command-line tool and/or a RESTful web API for querying known aliases of user-submitted addresses.Query interface for currently known alias dataDatabase of our alias resolution dataMay 23, 2018
Final Report
Deliverable: Final Report reportMay 23, 2018

Acknowledgement of awarding agency's support

This material is based on research sponsored by the Department of Homeland Security (DHS) Science and Technology Directorate, Cyber Security Division (DHS S&T/CSD) via contract number HHSP233201600010C.

  Last Modified: Wed Nov-30-2016 12:41:36 PST
  Page URL: