create new tag
view all tags

RIPPS: Detecting Rogue Wireless Networks at the Network Edge

RIPPS Recent advances in simplifying home networks have made the placement of wireless access points (WAPs) trivial to undertake. As a result, an employee with even the most basic computer skills can purchase an inexpensive WAP and quickly configure/install it into many corporate networks. The RIPPS (Rogue Identifying Packet Payload Slicing) tool is based on the following premise: is it possible to detect wireless connectivity for the purpose of detecting rogue WAPs (RWAPs) simply and inexpensively through in-network traffic characteristics at the edge of the network without end host modifications? To put it more succinctly (i.e. not in academic speak), can one create a firewall-like device at the network edge that detects illegal wireless connectivity within milliseconds of usage?

The RIPPS tool-suite offers a robust suite of open-source tools for the rapid assessment and reaction to unauthorized and/or unsecured WAPs in the enterprise. RIPPS has been validate extensively for its accuracy across multiple end host operating systems (Windows, Mac, Linux), various network configurations (congested, uncongested, heterogeneous speeds), different applications (web browsing, ssh, ftp, e-mail), and network connectivity (Gig E, Fast Ethernet, Ethernet, 802.11b, 802.11g, 802.11-draft-n, MIMO). Our most recent paper in ACM TISSEC has the complete experimental studies.

The work on RIPPS was part of a project at the NetScale Laboratory in the Department of Computer Science and Engineering at the University of Notre Dame directed by Dr. Striegel. The work was supported through fellowship grants by the university (Schmitt, University) and the National Science Foundation (CNS 03-47392). The project shares roots with parallel efforts in the lab on transparent bandwidth conservation that trades Quality of Service for efficiency, basic wireless networking research, and security. In the process of developing RIPPS, we also developed the CheapLogger (aka CLog), a full payload packet logging system that offers high speed packet logging on a budget.

The RIPPS code is now part of the larger ScaleBox architecture with future development included in the overarching ScaleBox code base.

How RIPPS works

RIPPS Packet Slicing RIPPS is based on techniques for traffic conditioning that can still exist in-band without modifying the client but yet offer a significantly accelerated and improved mechanism. The RIPPS traffic conditioning technique is based on packet slicing from the perspective of the TCP payload (TCP packet slicing is distinct from fragmentation of the IP packet in that successful delivery is no longer an all or nothing proposition). Packet slicing has three vital properties which make it an excellent solution for wireless connectivity assessment. First, packet slicing dramatically increases the percentage of network data which can be best utilized in assessing the connectivity type (i.e. small packets). Second, it maintains the deployment simplicity of passive monitoring techniques as out-of-band communication with suspect hosts is not required (i.e. still TCP). Finally, packet slicing eliminates the temporal spacing problem (i.e. small TCP data packets are located infrequently together), resulting in an increased ability to quickly and accurately identify wireless connectivity.

The general concept of packet slicing is simple, yet it improves transmission medium identification capabilities many fold. As noted in various network traffic studies, very small (64 byte) and very large packets (approaching MTU) tend to make up the vast majority of network traffic. For simple clients employing only web browsing and e-mail access, this is especially true. Packet slicing takes these dominant large ingress data packets and conditions them for use in LRTT metrics by slicing payloads and creating many new smaller packets. Packet slicing spreads a single large TCP payload over multiple packets, attaching each payload slice to an appropriate header. The headers from the original packet are used to easily create valid headers for each new packet. The Ethernet header is unchanged from the original, and the IP and TCP headers are modified slightly to validate the newly created packet. After modifying appropriate header fields, including checksums, the slices are re-ordered, shaped, and forwarded. From the viewpoint of any applications running on internal hosts, data is still delivered as normal. From the perspective of hosts outside of the network, the packet slicing device will take special care to hide its presence by gobbling superfluous ACKs, thus presenting an identical packet flow on the WAN (external Internet). Additional details regarding the nuances of packet slicing (shaping, re-ordering) and the thresholds for successful validation can be found in the TISSEC paper.

Quick Links

  • FAQ for RIPPS
  • Read our the near final version of our ACM Transactions on Information System Security (TISSEC)
  • Visit the RIPPS software webpage to download the latest version. The current instantiation of RIPPS is based on libpcap and should be capable of being used on most UNIX-based systems.
  • Read the two page marketing version of RIPPS as a PDF PDF
  • Read Chad Mano's Ph.D thesis on his work on developing the core of RIPPS including analysis of the Notre Dame network
  • Skeptical? Take a look at our raw data yourself to see it for yourself. Yes, it really is our raw data from the TISSEC paper to encourage others to continue in this area.
  • Take a look at on-going work with research ideas derived from RIPPS that go well beyond RIPPS code development
  • Would you like to license RIPPS to develop it further or sell a product? RIPPS is available via open-source but it would shine best inside an embedded device. If your company would like to license RIPPS, we would be happy to work with you in developing a fully deployed solution. Contact Dr. Striegel for more information.

Extended Problem Overview

RIPPS The past few years have seen remarkable improvements in the ease of which network access can be offered by the home user. The emergence of robust and streamlined wizard-based systems guide even the most basic computer users through the creation of sophisticated local networks offering a broad range of wired and wireless connectivity options. Unfortunately, while this streamlining offers considerable benefits to the home user, it creates serious security concerns for the enterprise network.

Specifically, wireless access points or WAPs embody the most serious of these security concerns. Whereas the wired network can be constrained by physical access, unsecured wireless networks extend connectivity to areas potentially not under the physical control of the enterprise. With technology as simple as a typical laptop, an option for an external antenna, and a slightly modified Pringles can , the concept of war driving emerged to describe pinpointing and accessing unsecured wireless networks.

While the bandwidth theft that occurs during such access is a cause for concern, the primary risk is that a "backdoor" is available to the network, bypassing the typical perimeter defenses (firewall, IDS) at the gateway for access to the internal 'trusted' network. In short, a 30 to 40 dollar WAP/NAT purchased at the local electronics store (Best Buy, Circut City, Fry's) invalidates tens of thousands of dollars of security equipment and potentially the entire security model of the enterprise.

Although one can posit in a theoretical sense that unauthorized devices should never be allowed to join the network, typically only larger enterprises have the resources to effectively undertake this endeavor. Approaches to preventing unauthorized devices with a reasonable degree of confidence are often perceived to be complicated (802.1X certificates, etc.) and/or expensive (antenna/sensor networks) to deploy. For many small to mid tier enterprises, the cost and overhead of these approaches preclude their adoption. Rather than a robust layered defense, the de facto security mechanisms (if they exist) are often a firewall at the perimeter for external attack prevention with MAC filtering in the internal network enforced via DHCP for host validation. This minimal security effort, aka crunchy on the outside, tasty on the inside, offers minimal resistance to MAC spoofing, a common feature embedded in most current WAP/NAT installation wizards.

Hence, the harried system administrator is often left with the low budget solution: roam the halls occasionally (or pay a consultant) with a laptop or handheld device looking for unknown and potentially rogue SSIDs. Once found and the painstaking process of identification is complete, the employee responsible for the WAP is appropriately disciplined with the realization that the internal network has been exposed for a potentially undetermined amount of time. Data integrity is checked as best as possible, better solutions are examined but not adapted due to cost, and a new reminder of company regulations are distributed to reinforce the existing policy. This series of events appears across countless enterprises at best resulting in the WAP being de-activated, at worst remaining hidden until significant security compromises occur.

The key difficulty that necessitates walking the beat is that the presence of wireless devices cannot be reliably and inexpensively monitored from a central vantage point. Unlike the firewall at the `choke point' (i.e. Internet gateway), wireless monitoring has been a distributed resource monitoring issue. One one hand, antenna-based offer coverage at a high cost with the potential for dead spots in coverage. In a similar vein, agent or host-based systems that convert existing wireless capabilities into sensors reduce deployment cost with an increased potential for dead spots due to resource conflicts and/or mobility. Moreover, both approaches offer the potential for significant false alarms in densely packed areas where wireless ranges can easily overlap physical spaces (i.e. multiple tenant office buildings).

It is this lack of an ability to quickly and reliably monitor from a central vantage point that creates the motivation for this research. Our research is examining methods to create a lightweight, inexpensive, in-network device to meet this need. Our proposed research derives its functionality from novel payload slicing techniques that 1) do not require host-wise modifications nor host-wise deployment (i.e. edge-wise device similar to a firewall), 2) provide fast and accurate assessment of the connectivity medium, 3) operate in-band without interference by the NAT/WAP and 4) are minimally invasive to the network in terms of scalability and quality of service (QoS).

Visible Output

The RIPPS project started back in the spring of 2004 as a humble but rejected paper to USENIX Security. Since then, it has evolved considerably from an initial concept of employing simple ICMP ping measurements to the initial slicing concept by Chad Mano to the slicing/shaping/ordering process that constitutes RIPPS.

  • J PDF C. Mano, A. Blaich, Q. Liao, Y. Jiang, D. Cieslak, D. Salyers, A. Striegel, "RIPPS: Rogue Identifying Packet Payload Slicer Detecting Unauthorized Wireless Hosts Through Network Traffic Conditioning," in ACM Transactions on Information and System Security (TISSEC), vol. 11, no. 2, pp. 1-23, March 2008. DOI BibTeX

Warning: Can't find topic Netscale.DissertationMano06

People Involved

  • Dr. Aaron Striegel - Project Lead - Beta Software Development
  • Dr. Chad Mano - Ph.D Dissertation Topic - Student Lead
  • Andrew Blaich - RIPPS Testing
  • Yingxin Jiang - RIPPS Testing
  • Qi Liao - RIPPS Testing
  • Dave Cieslak - Notre Dame Traffic Analysis
  • Dave Salyers - Initial RIPPS Discussions
  • Jeff Smith - Undergrad REU - Experimental System Feedback (Alpha Version)
  • Patricia Strei - Undergrad Research - Web GUI design for RIPPS management software

Related Work / Efforts

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng Pic-RIPPS.png r1 manage 49.8 K 2007-07-12 - 15:27 AaronStriegel RIPPS Overall Picture
PDFpdf RIPPS-Overview.pdf r1 manage 143.2 K 2007-07-12 - 15:20 AaronStriegel RIPPS Short Overview
PNGpng RIPPS-Quick.png r1 manage 43.1 K 2007-08-28 - 15:43 AaronStriegel RIPPS Quick Overview
PNGpng RIPPS-Slice.png r2 r1 manage 32.8 K 2007-07-12 - 15:45 AaronStriegel How packet slicing in RIPPS works
Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | More topic actions
Topic revision: r8 - 2008-07-22 - AaronStriegel
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback