Outcomes

Technical reports, working papers, and published papers produced as a result of GMI3S efforts. Papers are listed in chronological order.

Data needs for securing Internet infrastructure

This document catalogs the datasets that we have identified that play a role (or should or could play a role) in improving the security posture of these underlying layers of Internet infrastructure. For each system that we survey, we summarize the known or potential vulnerabilities, and possible mitigations to these vulnerabilities. We discuss the role of data in each of these steps.

• View paper: Data needs for securing Internet infrastructure (v2.4)

Considerations in Running Active Measurements on RouteViews Collectors

The goal of this tech report is to describe how SCAMPER can responsibly conduct data-plane measurements from RouteViews collectors through RouteViews peers, and implications for both collectors and peers. The ability to discover finer-grained (router-level) topology via the RV collector infrastructure offers both operational and research utility

• View paper: Considerations in Running Active Measurements on RouteViews Collectors

BGP2GO provides a graphical interface to explore and compile MRT file information (using the BGP metadata database) to facilitate easy access and sharing of relevant MRT files.

With the web API, users can look up a numeric identifier (e.g., ASN, prefix, community) to quickly obtain MRT file information and share with others.

We need a way to direct measurement traffic through individual Internet exchange point (IXP) members. Systems install a single best route, even when an IXP has many options for a given destination. However, traditional looking glasses do not provide ability to ping or traceroute through a specific IXP member.

Needs

• Researchers want to correlate control and data planes.
• Network Operators want to understand the router-level path to a point in their network from outside their network.
• Network Operators want to support active measurement of their networks without having to support measurement vantage points.
• IXP operators might want to offer performance data for routes available at their IXP to inform network operator policies.

We present three possible approaches:

Transit Source Address: we source measurement traffic using a source address of our transit provider

• Benefit: requires no special action from the member AS
• Issue: member AS does not control the reverse path to the VP

Member Source Address: we source measurement traffic using an address supplied by the IXP member

• Benefit: member AS controls the reverse path
• Issue: member AS has to provision an address and configure routing

Originated Source: we source measurement traffic using addresses in a /24 prefix we announce at the IXP

• Benefit: well understood approach to peering and routing
• Issue: we require address space to originate at each IXP

In all approaches, we would ask individual IXP members for their permission and cooperation.

Overall, researchers gain orders of magnitude more visibility into inter-domain routing. Network Operators gain the ability to debug network performance issues from a variety of network views. IXP operators can offer value-added services, such as data to support performance-aware routing.

Prototype System Requirements

We are seeking a small VM to support prototype development

• Two Network Interfaces: one connected to IXP and one for transit
• 2 cores, 4GB of RAM, 10GB disk, Linux or *BSD

The system will primarily conduct light-weight topology and delay measurements (ping and traceroute) with scamper. We will implement a system to allow IXP member access to the capability and data.