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
  AS237
  
• 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 laws requirements
• Was cost effective and practical
• Were 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 opensource
  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
• Reaggregation of traffic
• Other

5
No Transcript
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
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
  190225Mbps 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 oncampus
• Price/performance comparison with commercial
  offerings e.g. ENDACE hardware solution
  
• Perhaps have a combination of build buy