| A: RIPPS stands for Rogue Identifying Packet Payload Slicer. The root of the Slicer portion comes from how RIPPS slices up the TCP payload into smaller sizes and relies on the automatic re-assembly at the TCP level for the end application. |
| Q: Why not just use sensor-based approaches such as kismet, WiSentry? , or others that use WAPs or hosts as rogue wireless access point sensors? |
| A: RIPPS takes a fundamentally different approach to wireless network detection. Rather than detecting based on the presence of wireless traffic, RIPPS exploits traffic properties to determine if a connection is wireless or wired. Moreover, this is done at the edge of the network, similar to a firewall allowing for a relatively simple deployment. RIPPS will catch any traffic passing through it whereas sensor deployment may be incomplete due to walls or dead spots. RIPPS also functions well in multi-tenant environments (ex. office building) where multiple WAPs may be present that are not all under the same administrative domain (company A, company B, etc.). RIPPS can also provide host identification for SNMP isolation, a feature not possible via sensor-based networks (i.e. the sensors note the presence of the device, not the wired host that is providing the bridge for access. With RIPPS operating on the wired network, it does know the location of the wired host. |
| Q: Does RIPPS replace sensor-based approaches? |
| A: For enterprise networks that do not have the resources to place sensor-based systems, RIPPS can function adequately. However, we view RIPPS as working excellent in tandem with existing sensor-based solutions. |
| Q: How fast is RIPPS? Doesn't the fact it must sample the network mean it runs slow? |
| A: RIPPS is quite fast. In the hybrid approach (sample an extremely limited amount and then follow up if necessary), RIPPS can offer 99% confidence with only the sampling of a single full-sized packet. An average resolution time would be on the order of milliseconds for a highly aggressive network to rapidly contain exposed access points. |
| Q: How much impact does RIPPS have on the network? |
| A: Very limited. RIPPS selectively samples hosts per the direction of the network administrator. With the above mentioned hybrid mechanism (slice 1 full packet, follow up if necessary), the impact is negligible. To give a reference point from the TISSEC paper, a network of 3200 hosts all running through the same link validated once per minute using the hybrid mechanism will incur roughly 0.79 Mb/s overhead, less than 1% on a 100 Mb/s network, less than 0.1% on a Gigabit network. |
| Q: Won't RIPPS cause packet fragmentation? |
| A: No, RIPPS slices the TCP payload and modifies the TCP sequence number to reflect this. The IP fragmentation bit should never be set as a by-product of RIPPS. IP Fragmentation would be especially problematic as the lack of a partial retransmission mechanism would make error recovery quite difficult. |
| Q: I want to use RIPPS now, can I use it in my business? |
| A: Yes, feel free to download the code. We simply ask that in the spirit of open source that you share any bug fixes with us. Our near term plans include placing RIPPS on SourceForge? to enable easier contribution outside of our research group. Our only restriction is that you must license the code if you wish to sell a product. Please see the two page overview or contact Dr. Striegel for information regarding licensing of RIPPS. |
| Q: Do you have a hardware-based version of RIPPS? |
| A: Not at this time. We are looking in bringing RIPPS to the IXP following a successful implementation of our other work on transparent bandwidth conservation on the IXP 2350. We will also be looking at porting RIPPS to the inexpensive Soekris devices. |
| Q: Egads, RIPPS is hard to use. Is there a web-based configuration tool for it? |
| A: Work is slowly progressing on a web-based management tool for RIPPS rather than the command-line toolset. |
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.