Software releases

release of the cryptopANT library for IP address anonymization

cryptopANT v1.0 (stable) has been released (available at

cryptopANT is a C library for IP address anonymization using crypto-PAn algorithm, originally defined by Georgia Tech. The library supports anonymization and de-anonymization (provided you possess a secret key) of IPv4, IPv6, and MAC addresses. The software release includes sample utilities that anonymize IP addresses in text, but we expect most use of the library will be as part of other programs. The Crypto-PAn anonymization scheme was developed by Xu, Fan, Ammar, and Moon at Georgia Tech and described in“Prefix-Preserving IP Address Anonymization”, Computer Networks, Volume 46, Issue 2, 7 October 2004, Pages 253-272, Elsevier. Our library is independent (and not binary compatible) of theirs.

Despite this being the first release as a library, the code has been in use for more than 10 years in other tools.  It had been part of our other software packages, such as dag_scrubber for years.  By popular request, we’re finally releasing it as a separate package.

The library is packaged with an example binary (scramble_ips) that can be used to anonymize text ips.

See also the crypto-PAn page at Georgia Tech here.

Publications Software releases Technical Report

new technical report “LDplayer: DNS Experimentation at Scale”

We released a new technical report “LDplayer: DNS Experimentation at Scale”, ISI-TR-722, available at

ldplayer_overviewFrom the abstract:

DNS has evolved over the last 20 years, improving in security and privacy and broadening the kinds of applications it supports. However, this evolution has been slowed by the large installed base with a wide range of implementations that are slow to change. Changes need to be carefully planned, and their impact is difficult to model due to DNS optimizations, caching, and distributed operation. We suggest that experimentation at scale is needed to evaluate changes and speed DNS evolution. This paper presents LDplayer, a configurable, general-purpose DNS testbed that enables DNS experiments to scale in several dimensions: many zones, multiple levels of DNS hierarchy, high query rates, and diverse query sources. LDplayer provides high fidelity experiments while meeting these requirements through its distributed DNS query replay system, methods to rebuild the relevant DNS hierarchy from traces, and efficient emulation of this hierarchy of limited hardware. We show that a single DNS server can correctly emulate multiple independent levels of the DNS hierarchy while providing correct responses as if they were independent. We validate that our system can replay a DNS root traffic with tiny error (+/- 8ms quartiles in query timing and +/- 0.1% difference in query rate). We show that our system can replay queries at 87k queries/s, more than twice of a normal DNS Root traffic rate, maxing out one CPU core used by our customized DNS traffic generator. LDplayer’s trace replay has the unique ability to evaluate important design questions with confidence that we capture the interplay of caching, timeouts, and resource constraints. As an example, we can demonstrate the memory requirements of a DNS root server with all traffic running over TCP, and we identified performance discontinuities in latency as a function of client RTT.

Software developed in this paper is available at



Software releases

mtracecap: New utility for multi-point capture released

mtracecap v0.1 (beta) has been released (available at

This tool is designed to capture packets from multiple sources and write its output to a single file.  Its build requires a local install of libtrace library (version 4.0 or older) and supports all sources supported by the library, such as pcap based interfaces, linux-specific ring interfaces, pcap and erf outputs and many more!  See them all listed when you run mtracecap with -H option.  DAG device capture is optional, depending on local DAG libraries being present.

An important feature of this tool is being able to roll output into multiple files either based on either maximum file size (e.g.  “-S 100” option will make it write output in 100MB chunks), or system time (e.g. “-G 180” option will rotate output every 180 seconds).

Finally, the tool can use external commands to work on the input before writing it to a file using a pipe (see –pipeout option).  This can be useful if you want to compute some statistics on the fly or compress output using an external compressor.  Using this option will eliminate extra disk read-write operations if all you want to do is to compress the output.

Software releases

timefind v1.0.3 released with recursion support

timefind v1.0.3 has been released (available at

indexer and timefind will handle the indexing and selection of multiple network data types given some time range.

Major changes in 1.0.3 include:

  • new file processors for .csv, .fsdb, syslog, and BGP/MRT files
  • timefind and indexer now support traversing the file hierarchy with recursive processing
  • index entries now have a “last modified” column timestamp: existing entries will be reindexed if that file was modified after index creation.

Many thanks to Paul Ferrell (LANL) and Paige Hanson (LANL) for their contributions in timefind extensions.

Software releases

new software dnsanon_rssac

We have released version 1.3 of dnsanon_rssac on 2016-06-13, a tool that processes DNS data seen in packet captures (typcally pcap format) to generate RSSAC-002 statistics reports.

Our tool is at, with a description at .  Our tool builds on dnsanon.

The main goal of our implementation is that partial processing can be done independently and then merged. Merging works both for files captured at different times of the day, or at different anycast sites.

Our software stack has run at B-Root since February 2016, and since May 2016 in production use.

To our knowledge, this tool is the first to implement the RSSAC-002v3 specification.


Software releases

timefind v1.0.2.2 released

timefind v1.0.2.2 has been released (available at

Scientists at Los Alamos National Laboratory and at USC/ISI have developed two tools to handle indexing and selection of multiple network data types: indexer and timefind.

Most of us have processed large amounts of timestamped data. Given .pcap spanning 2010-2015, we might want to downselect on a time range, e.g., 2015-Jan-01 to 2015-Feb-01. An existing way to downselect would be to build fragile regexes and walk the directory tree for each search: inefficient and inevitably re-written.

indexer will walk through all your data and index the timestamps of the earliest and latest records.

timefind will then use the indexes and retrieve the filenames that overlap with the given time range input. To downselect 2015-Jan-01 to 2015-Feb-01 on “dns” data, use:

timefind --begin="2015-01-01" --end="2015-02-01" dns

It’s that simple and consistent.

Software releases

Digit tool for T-DNS privacy updated to match current internet-draft

Digit is our DNS client side tool that can perform DNS queries via different protocols such as UDP, TCP, TLS. This tool is primarily designed to evaluate the client side latency of using DNS over TCP/TLS.

IANA has allocated port 853 to use TLS/DTLS for DNS temporarily in the most recent version of Internet draft “DNS over TLS: Initiation and Performance Considerations” (draft-ietf-dprive-dns-over-tls-01).

To track the current specification, we have updated Digit to do direct TLS on port 853 by default, with TCP. STARTTLS and other protocols as options for comparison.

These changes are available as Digit-1.4.1 at

Software releases

Digit-1.1 release

Digit-1.1 has been released  (available at from 2014-11-08 16:17:45).  Digit is a DNS client side tool that can perform DNS queries via different protocols such as UDP, TCP, TLS. This tool is primarily designed to evaluate the client side latency of using DNS over TCP/TLS, as described in the technical report “T-DNS: Connection-Oriented DNS to Improve Privacy and Security” (

A README in the package has detailed instructions about how to use this software.

Software releases

Software to Generate IP Hitlists with Hadoop Now Available

We are happy to release the set of map/reduce processing scripts that run in Hadoop to consume our Internet address censuses and output hitlists, as described in the paper “Selecting Representative IP Addresses for Internet Topology Studies“.

These scripts depend on our internal Hadoop configuration and so will require some modification to work elsewhere, but we make them available and encourage feedback about their use.

Announcements Collaborations Software releases

ANT extensions for bzip2-splitting to appear in Hadoop

The ANT project is happy to announce that our extensions to Hadoop to support splitting of bzip2-compressed files have been accepted to appear in the next Hadoop release (will be 0.21.0).

Support for compression is important in map/reduce because it reduces the amount of I/O, and because important input files (for us, our Internet address censuses) are provided in compressed format.

Splitting is important in map/reduce, because splitting allows many computers to process parts of a few big files.  Since the whole point of Hadoop and map/reduce is processing big files (for us, 4GB or more) with many computers (for us, dozens to hundreds), splitting is really essential.

Until now, Hadoop did not support splitting of compressed files.  Instead, if input data was compressed, you get at most one computer per file.  Some work-arounds were possible, but basically unpleasant, and often requiring that one rewrite all the input data is some other format.

Our extensions (see HADOOP-4012 and MAPREDUCE-830, plus HADOOP-3646 that went into 0.19.0) support Hadoop execution over bzip2 files with automatic splitting.  Getting this done was trickier than one might expect:  Hadoop really wants to decide where to split files, yet bzip2 can only support splits at specific locations that are different, and users don’t care about either of these but instead only about their record boundaries.  Fortunately, we were able to align all of these constraints, and deal with the corner cases that inevitably arise.  (What if the bzip2 marker appears in normal data?  What happens when markers exactly align, or are off-by-one?)

Abdul Qadeer did this work in 2008, working with Yuri Pradkin and me (John Heidemann), and continued to work with the patch through its getting committed.  We especially thank Chris Douglas at Yahoo for shepherding patch through the Hadoop bug tracking system, including helping clean it up and add test cases.  And we thank Doug Cutting for initially suggesting bzip2 as a splittable compression scheme.

This work was supported by NSF through the MR-Net research project (CNS-0823774).