CALEA Compliance – A Feasibility Study October 25, 2006

1. CALEA Compliance – A Feasibility StudyOctober 25, 2006 Mary Eileen McLaughlin Director – Networking Merit Network, Inc.

2. Overview • Merit believes it will need to be “Gateway compliant” for CALEA • Will need to have a device at the ingress/egress points of our network • In other words, where traffic enters or leaves AS-237 • About 9 sites including private peering points • We wanted to see if we could develop an architecture that • Met what we see today as the law’s requirements • Was cost effective and practical • We’re not talking the legal pros/cons, or the expectations of law, or challenges

3. Goals of Experimental Framework • Build a modest packet capture platform • Based on simple hardware and open-source software • Test ability to capture a single data stream • In the presence of a moderate amount of background traffic • Measure performance • Packet loss • Make decision on just how good performance has to be for Merit to say it is in conformance with the law cont.

4. Goals of Experimental Frameworkcont. • Where will this solution ‘break’ • Or, until what level of aggregate bandwidth usage is this solution functional • How well might this solution work with 10G cards compared to price/performance of commercial solutions • Testing only traffic capture functionality, not • Transfer to law enforcement device • Re-aggregation of traffic • Other

6. Hardware/Software • Dell Precision GX260 Workstation, 2 GIGE interfaces for management and sampling • Pentium 4 3GHz • 1GB RAM • 7200 RPM disk • Gentoo Linux OS • Tcpdump/tethereal for packet capture -- both depend on pcap library • Testing whether tcpdump can handle the data rates • Iperf as the traffic generator • Some custom wrapper software to make it easier to manage the data collection activity

7. IPERF Source Experiment Architecture Merit SBC Fiber Cogent Ameritech Merit Building Switch DSL Out to net Mirror Port Merit LAN IPERF Sink Traffic Capture Device

8. Experiment Methodology • Background traffic for the duration of the test: ~ 190-225Mbps (Sunday evening load), repeat for higher traffic load ~400Mbps (Monday afternoon) • Phase 1 test: • Send data from source to sink using iperf • Attempt to capture traffic stream at capture device at Merit building • Measure actual number of packets transmitted at the source and compare with number of full packets captured • Measure for Short / medium / large TCP flow

9. 10 sec Expt (~ 200Mbps Load) Avg Test Traffic Data Rate: ~380Kbps Avg Transfer: ~ 500KB

10. 5 min Expt (~200Mbps Load) Avg Test Traffic Data Rate: ~390Kbps Avg Transfer: ~ 14.1MB

11. 30 min Expt (~200Mbps Load) Avg Test Traffic Data Rate: ~390Kbps Avg Transfer: ~ 83MB

12. 5 min Expt (~400Mbps Load) Avg Test Traffic Data Rate: ~393Kbps Avg Transfer: ~ 14.1MB

13. Preliminary Conclusions and Discussion • At a load of roughly 200Mbps there are less than 1% (0.006% - 0.007%) of the packets missing at the capture device • This seems to hold at least up to an aggregate load level of 400Mbps (bidirectional traffic mirrored onto a single port) • But what about VoIP (UDP)? How does our lost packets compare with what might normally happen to a datastream across the same datapath? • A UDP stream along the same path at 380Kbps experienced roughly 1.5% packet loss • Thus, less than 1% packet loss for our mirrored traffic is well within a “normal” range • Should be sufficient for law enforcement

14. Discussion and Next Steps • Simple hardware/software holds promise for at least the lower rate uplink capacities (definitely for OC3, GIGE type rates) • Need to repeat experiments, systematically, and at different (higher) loads • Future work includes • Examining 10Gig cards • Multiple sites concurrently; possibly on-campus • Price/performance comparison with commercial offerings, e.g., ENDACE hardware solution • Perhaps have a combination of build & buy