Internet2 launching its own “IRB”
October 10th, 2008 by kcI (and others) have spent a bit of time over the last year encouraging Internet2 to take a more proactive role in supporting network research. So I was delighted to see the proposal of a new network research review council, which I reckon will amount to a network-research-dedicated IRB for Internet2.For most researchers, Internet2 has the closest they will get to real large-scale network operators. Internet2 operators are more willing to expose pain points and obstacles they encounter, and Internet2 provides more data about itself to the public, than any other network I know, public or private. Even better, Internet2 management is also more capable of fostering effective, cross-disciplinary, scientific Internet research than the private sector, simply by virtue of their incentive structure.
And yet even Internet2 recognizes its data sharing limits, rooted in three obstacles: (1) user privacy concerns; (2) fear of lawsuits from hollywood over file-sharing activity or from commercial peers over non-disclosure-laden peering agreements; and (3) economics — operational costs of storage, bandwidth and data management resources. As a result of these legitimate concerns, both operators and researchers in the community are unable to pursue a variety of questions — including in the increasingly important area of network security — due to economic and policy issues, rather than anything scientific or technical.
To protect individual privacy, Internet2’s current method of anonymizing data is to zero out the lower 11 (of 32) bits of the IPv4 address in netflow data it collects. This technique protects individual privacy, but also eliminates the ability to do any research on individual flows, even anonymized flows. Furthermore, Internet2 uses equipment that can only keep up with netflow via packet sampling, so there is no unsampled flow data to provide to researchers, and sampled flow data is difficult to use without a baseline understanding of the impact of sampling, which the research community lacks any way to obtain. Internet2’s current netflow capability also does not count IPv6 packets, so there is no way to track anything about this emerging protocol. There is no more detailed traffic data available from Internet2 to calibrate against any of the sampled, anonymized netflow data.
Internet2 needs a way of navigating these issues; I believe the proposed review board is a first step in the right direction. (please email me or matt if you are interested in participating.)
Internet2’s link to network research review council description (and full text below)
[disclosure: DHS S&T is funding caida’s participation on internet2’s research advisory council.]
Proposal for a RAC Network Research Review Committee
2008-10-08
Internet2 and its Research Advisory Council propose a network research review committee under the RAC, to make recommendations for Internet2 priorities in network research consistent with the Internet2 strategic plan, to vet and recommend prioritization of requests that come in from network researchers, and to make policy recommendations in the network research space. Note that Internet2 supports many forms of academic research, and network research is just one. However, Internet2 can play a unique role in network research because it runs a backbone network. One goal of the committee is to change Internet2’s network research stance from being just reactive to having a set of prioritized goals, providing focus.
Internet2 Priorities in Network Research
Internet2 has not had specific goals with respect to supporting network research, although it has tried to be responsive to researcher requests and expressed interests in particular data or architectural support. Establishing a more formal framework for communicating research priorities and operational or budgetary constraints in meeting them will equip both Internet2 and the research community to make more effective use of their own resources. An articulated set of priorities can guide Internet2 decisions in several areas: handling of unsolicited requests from network researchers, deciding which grant opportunities to pursue, and planning equipment upgrades and data collection. A simple list of priorities could also inspire new requests from network researchers and granting agencies in these areas, and elicit partnership opportunities that might otherwise be missed.
Request Review and Prioritization
The committee will discuss unsolicited requests — and potential future requests based on stated priorities — from network researchers. The committee will provide two functions:
- Vetting: verify scientific merit of project, including independent review
- Prioritization recommendations (how projects fit together given limited resources)
The committee will review requests to ensure there is some research merit, and verify that it is appropriate for Internet2 to fulfill the request; provide external review to ensure requests are treated fairly. In the event that there are multiple requests outstanding, or not enough resources to fulfill all requests, recommend a prioritization among requests.
For projects that might affect the running network, and for equipment placement requests that use scarce space and power, we anticipate additional operational network review. A researcher request might also kick off a policy discussion, if the request is important and against enters unexplored policy space.
Policy
Recommend changes or additions to Internet2 network research support policies.
There is a current strong need to discuss policy regarding passive measurements and privacy. The current unwritten policy is “do not record any data that might identify an individual, or reveal any packet payload transferred.” This policy has been relaxed for a narrow set of operational security reasons — in particular, to identify and stop network attacks. There is good reason to adjust the policy for network security research, and for network characterization research. However, there are a number of questions. How do you balance the need for science against privacy concerns, and concerns that certain data is more desirable for use in lawsuits that tie up equipment or resources? Are there different anonymization techniques that balance privacy and the need to disambiguate endpoints for research? Are there such techniques along with policy (such as you can only do this research as an employee, or only do it under a strict MOU, or only do it under the evolving PREDICT framework, or Internet2 runs code for you and returns results) that can minimizes risk for great potential reward?
One of the first tasks of the committee is to look at this set of policy questions, and suggest a course of action. It might be easier to do this after setting some priorities for network research for Internet2, but there have been many recent requests of Internet2 for data, and this work can proceed in parallel.
Potential Committee Composition
It is envisioned that there will be a core consisting of members of three different groups: RAC (~3), Internet2 (~3), Network researchers (~3). In addition, there will be some specialists. It is envisioned that the committee will bring in specialists where needed, perhaps especially with respect to policy questions. For example, initially the committee will be dealing with outstanding requests that require examining policy with respect to collecting and releasing or using unanonymized, or structurally anonymized passive data, including netflow and packet header traces. Thus, we will need legal and policy expertise as well as insights from others who have released data. These specialists will help craft particular recommendations, and are not necessarily as permanent members. Suggested example participants:
- RAC: kimberly claffy, Dave Farber
- Internet2: Rick Summerhill, Matt Zekauskas
- Network researchers: TBD
- Specialists, including lawyers retained by Internet2
Background on Internet2 Network Research Support
Internet2 supports research in several ways. The most visible is the Internet2 Observatory, where researchers can request data from the Internet2 Network, and they can also propose that equipment be placed inside the Internet2 Network. Some data requests are fulfilled with no Internet2 staff interaction — the data is simply available from a web site. Some requests require significant resources, either in staff time, new equipment, programming, or scarce space and power inside Internet2 Network PoPs.
To date, Internet2’s support for network research has been largely reactive. Staff chat at networking conferences, and talk with researchers, but largely we wait for a researcher to come to us with an idea. However, the current Internet2 Observatory data collections are a result of trying to be as open as possible with network measurement, since a universal researcher request is for more data and commercial networks generally do not release data for competitive reasons. Before designing the current Internet2 Observatory incarnation, Internet2 also interviewed researchers in 2004 and 2005 as part of a NSF small grant with the University of Virginia (Leveraging Internet2 Facilities for the Network Research Community), which basically said “more data”, with network researchers wanting some form of access to unanonymized packet headers and some to full packet traces. They also advocated partnerships with researchers (working with researchers to provide appropriate facilities), and not a “build it and they will come” approach (for either data supplied or equipment available). This committee can help guide Internet2 forward and not have Internet2 simply be reactive; with thoughtful choices as to the research to support.
Existing data collection that is readily available include: utilization, results of active throughput and latency measurements, BGP data collection, IS-IS data collection, sanitized syslog streams from routers, and a host of router configuration data. It is anticipated that as regular operational data is collected from the optical equipment, it too will be made available. The one data collection that we request a proposal to access is our 11-bit anonymized netflow feed (IPv4 only currently, and last 11 bits of non-multicast IPv4 addresses are zeroed).
The Internet2 Observatory web pages invite researchers at member institutions to request data, suggest new collections, and also to propose equipment placement in the case where that is valuable.
Some past projects initiated by network researchers that might have been reviewed by this committee include the NLANR passive “router clamp” around Indianapolis, the placement of AMP monitors into PoPs, tuning of router buffers, and the researcher-requested collection of IS-IS router data.