• Nepenthes24 - Common Server Side Application
• Kippo25- SSH
2.12 Summary
The logical flow of this chapter followed in the outline provided by the goals set in Section 1.2. This chapter began by through defining the purpose for which simulation and emu-lation were created and then brought forth the idea of what is required to route a packet and why one would want to route a packet. Simulation and emulation of packet routing and previous steps that other research in the field had taken were then tied directly into the question of the possibilities of simulating the routing of a packet.
Other ideas and applications of routing simulation and emulation were pointed out and an understanding of the underlying mechanisms of these implementations was drawn.
From this point, this research can now take the knowledge brought to light in Chapter 2 and look towards design and implementation in Chapter 3. Chapter 3 will lay the groundwork onto which this research’s implementation of a routing simulator will be built by defining first what is required of a routing simulator and then what the host platform will be. From this grounding, the manner in which each functionality will be designed and the form they will take will be discussed and selected.
24https://www.shadowserver.org/wiki/pmwiki.php/Involve/BuildAHoneypot
25http://code.google.com/p/kippo/
3
System Design
This chapter presents a theoretical approach to the design of the implemented system.
The aspect of feature objectives and resource management is considered first in Sections 3.1 and 3.2, as the need to define and understand the interactions of the underlying structure of this implementation is important. Without a concrete foundation and clear goal, the errors created through misdirection would propagate into features built on top of this foundation. Each memory structure this implementation can use to represent its network structure is detailed next in Section 3.3.
The following text in Section 3.4 brings up the manner in which the routing process takes is handled and the OS is chosen after this in Section 3.5. Section 3.6 and 3.7 address details around the overheads context switches cause in a user space application and how one can make use of threads within this implementation. Next, Section 3.8, this research fleshes out the details of how interfacing to a physical network is performed and how one would go about configuring this implementation is explained in Section 3.9. Finally, Section 3.11 recaps this chapter by listing the final design choices made for this routing simulator’s implementation.
Each element considered takes into account the many solutions that could perform the task at hand. For this reason the general form of this text is that each solution is detailed
36
3.1. FUNCTIONAL REQUIREMENTS 37
and discussed before a decision is made as to the best solution for this implementation.
The selection for the decision is also discussed so as to keep the reader in line with the authors thought process.
3.1 Functional Requirements
The process of network routing, which is responsible for the way in which network pack-ets are transferred from host to host in the Internet (Savage et al., 1999), has some spe-cific hardware to enable this functionality. This hardware ranges from routers, switches and endpoint hosts, to the medium which carries the bits of one’s packet. The hardware involved in routing, as well as the mediums used, will be focussed on to simulate the general functionality of network routing.
Packet routing, as opposed to circuit switching (Marques et al., 2006), is the main fo-cus of this implementation; this is performed on a node to node basis. Throughputs of greater than 7 Gbps were achieved through this design (see Section 5.3) and the means by which this performance was obtained is further detailed in Section 3.4. There are some behaviours that arise in packet routing that occur naturally due to errors in links and within the processing logic of nodes (Bolot and Jean-Chrysotome, 1993). These be-haviours, which most commonly occur in large scale networks, are:
• Delay - The time between packet emission from source host and arrival at destina-tion host.
• Jitter - A common occurrence within wireless networks leading to packet retries, and thus added delay.
• Packet Loss - The event of an unrecoverable failure in a packet’s transmission.
• Packet Mangling - The event of a packet’s data on arrival not representing the data it was emitted with.
Some further functional additions for this research’s implementation is introduced to allow for offloading workloads as well as network monitoring. These functions are:
• Worm Hole Routing - Hop aggregation to allow process offloading for improved per-formance.
• Packet Monitoring - A mechanism to view packet details at simulation time.
3.1. FUNCTIONAL REQUIREMENTS 38
Figure 3.1: Delays in Typical Node
3.1.1 Network and Propagation Delay
Figure 3.1 describes delay as a combination of four factors. These factors are process, propagation, queue and transmission delays (Jim Kurose, 2010). To better describe each, processing delay is the delay taken to process a packet in node, be it host or router.
Propagation delay is the time it takes for a node to put a packet onto the wire; this should not be confused with transmission delay which is the time taken for a packet to travel across the wire from source to destination. Last is queue delay; this is the time taken for a packet to reach the head of the internal queue for emission onto the physical network medium within a node.
Delay causes a natural physical restraint on large networks and is a point that was taken into consideration in the design of this implementation. The reason for this is that delay has potential adverse effects on continuous connections, such as file transfers or stream-ing (Zheng et al., 2001), as protocols now should know to adapt to longer connections, or periods of no response while a packet is in transit.
3.1.2 Packet Loss
Packet loss is the non-arrival of packets within a network. Causes for such loss can be medium signal fade, network congestion or TTL expiry (Jim Kurose, 2010). The fact that this is a common occurrence in current-day networks is reason enough to include packet loss as a key feature within this network simulator. Such packet loss can lead to failed file transfers, disconnection in streaming sessions, or failures in other connections that
3.1. FUNCTIONAL REQUIREMENTS 39
Figure 3.2: Packet Lost in Transit
Figure 3.3: Example of a Packet Being Mangled
require a lossless data transfer protocol. A visual example of packet loss is given by Figure 3.2. Protocols that help to mitigate this problem, such as TCP, are discussed in Section 3.4.3.
3.1.3 Packet Mangling
Like packet loss, packet mangling is another behaviour of large scale networks, although less common, that can lead to sub-optimum connection link states. In short, a mangled packet is one that has lost context due to the fact that parts of the packet have been modified either prior to, or during transit (Bautts et al., 2005). Figure 3.3 depicts this through an example of the original packet on the left being modified into a mangled state on the right.
3.1. FUNCTIONAL REQUIREMENTS 40
In most modern routers, the common behavioural approach to receiving a mangled packet is simply to drop it, as it has lost context (Jim Kurose, 2010); this is typically checked via the packet’s checksum. This means that the handling of a mangled packet in this manner would lead to the same result as a lost packet. Detection of this packet loss is usually through observation of the packet’s original checksum not equalling what the now modified packet’s checksum should be (Wireshark Foundation, 2013).
There is also intentional packet mangling where a packet is specifically formed or mod-ified in such a way as to disrupt expected functionality of systems. This is achieved through creating packets that look like they are from different sources to achieve anonymity or resource allocation. These are usually created with malicious intent and classify un-der denial of service attacks (McDowell, 2009). These packets are usually targeted at a service or network to use all resources that the service or network provides. With no more resources left for allocation, the service or network can no longer provide a optimal experience for legitimate users; this gives rise to the idea of attack.
As packet mangling, in the sense of packet corruption, does occur in real world physical application, it was also identified as a feature that should be included in this implemen-tation. This will allow for testing of rigidity of protocols and applications set to be tested on this routing simulator in future application.
3.1.4 Jitter
Also known as packet delay variation (Demichelis and Chimento, 2002), jitter in network-ing terms is the variation in latency between two nodes within a network (Comer, 2008).
This is most prominent in wireless connections as packets transmitted over a wireless network have a greater chance of needing to be retransmitted than in a wired connection due to signal strength entropy.
Jitter can lead to problems regarding quality of service as a wide variation of packet arrival can lead to unpredictable transfer speeds, as well as bursts in transmission that could overload specific links or nodes (Demichelis and Chimento, 2002). This can also lead to disruption in streaming of live communications on applications such as Skype1, Youtube, audio streams, video streams or the combination of each found on video on demand sites.
1http://www.skype.com/en/
3.1. FUNCTIONAL REQUIREMENTS 41
Figure 3.4: Example of Worm Holing in a Route
As wireless links do exist in real world application, the inclusion of such a feature within this implementation was considered important. If a new protocol were to be developed, one should have the ability to test it over a simulated wireless link to ensure robustness.
A more subtle function that this feature provides is out of order packet routing. This oc-curs because of the delay of a hop no longer being constant, but rather varying due to the retransmissions caused by this jitter. This can cause packets transmitted subsequently to a packet suffering from this jitter to arrive before the initial packet.
3.1.5 Worm Hole Routing
Worm hole routing is the ability for a packet in simulation to compress a series of hops into a single hop. This takes into account the sum of all delays of all hops to the destined node. The simulation proceeds to process the transmission from the source to arrival at the worm hole destination as a single hop with a delay of the sum of all hops in the route.
In implementation, if criteria are matched while routing a packet, the packet is then scheduled once to hop directly to the node to which it is destined with the preconfigured sum of delays as the delay incurred on the transmission delay of the hop. Figure 3.4 depicts this logic. This allows for lower CPU usage as a single schedule is made to the work queue and this removes the need to manually process all the hops in between.
This ability to source packets from a node and sink them at a node regardless of hops in between allows for the ability to inject packets at a node in the simulated network.