calea compliance a feasibility study october 25 2006 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
CALEA Compliance – A Feasibility Study October 25, 2006 PowerPoint Presentation
Download Presentation
CALEA Compliance – A Feasibility Study October 25, 2006

Loading in 2 Seconds...

play fullscreen
1 / 14

CALEA Compliance – A Feasibility Study October 25, 2006 - PowerPoint PPT Presentation


  • 141 Views
  • Uploaded on

CALEA Compliance – A Feasibility Study October 25, 2006. Mary Eileen McLaughlin Director – Networking Merit Network, Inc. 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'CALEA Compliance – A Feasibility Study October 25, 2006' - bernad


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
calea compliance a feasibility study october 25 2006

CALEA Compliance – A Feasibility StudyOctober 25, 2006

Mary Eileen McLaughlin

Director – Networking

Merit Network, Inc.

overview
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
goals of experimental framework
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.

goals of experimental framework cont
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
hardware software
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
experiment architecture

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

experiment methodology
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
10 sec expt 200mbps load
10 sec Expt (~ 200Mbps Load)

Avg Test Traffic Data Rate: ~380Kbps

Avg Transfer: ~ 500KB

5 min expt 200mbps load
5 min Expt (~200Mbps Load)

Avg Test Traffic Data Rate: ~390Kbps

Avg Transfer: ~ 14.1MB

30 min expt 200mbps load
30 min Expt (~200Mbps Load)

Avg Test Traffic Data Rate: ~390Kbps

Avg Transfer: ~ 83MB

5 min expt 400mbps load
5 min Expt (~400Mbps Load)

Avg Test Traffic Data Rate: ~393Kbps

Avg Transfer: ~ 14.1MB

preliminary conclusions and discussion
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
discussion and next steps
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