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 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 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

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
  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