A Social Accountability Framework for Computer Networks

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE Globecom 2010 proceedings.

A Social Accountability Framework for Computer Networks Kang Wang1 , Alexis J. Malozemoff2 , Ning Jia2 , Chunhui Han3 and Muthucumaru Maheswaran3 Advanced Networks Research Lab School of Computer Science McGill University Montreal, Quebec, Canada Email: 1 [email protected] (corresponding author) 2

{firstname.lastname}@mail.mcgill.ca 3 {firstname.lastname}@mcgill.ca

Abstract—We present an accountability framework for the Internet which ties a user’s action to her identity on an online social network. The framework is optional in that users do not need to be accountable at all times, but various web services can force accountability on the part of their users by only allowing accountable users access. Our design is general enough that higher level applications can place additional policies/restrictions on the basic accountability provided. In this paper, we introduce the design, discuss how various applications can be mapped onto our framework, and provide performance numbers from an experimental prototype.

I. I NTRODUCTION The architectural simplicity of the Internet is one reason for its tremendous success, and also for its poor security track record. For example, the use of unauthenticated addresses at the IP layer, while a beneficial design decision, has led to such Internet vulnerabilities as denial-of-service attacks and route hijacking. Such security problems often stem from the lack of accountability on the Internet, i.e., the “ability to associate an action with [its] responsible entity” [1]. In this paper we present a novel accountability framework based on a user’s social links in an online social network. Called the social accountability framework, our system introduces accountability into the preexisting Internet architecture and does not require a major overhaul of the Internet to be useful in practice. Using the social accountability framework, incoming traffic can be classified as accountable or unknown, and packet handling schemes outside our framework can use this classification to prioritize or filter the packets. Our framework is optional in the sense that not everyone is required to be accountable at all times. Rather, the desired level of accountability is left to the services and hosts. For example, a blog may only allow postings from accountable users to avoid defamation while a service such as WikiLeaks (http://wikileaks.org) would like their users to remain anonymous and thus can simply not use our framework. Several studies have previously investigated the problem of accountability on the Internet. Andersen, et al., introduced the Accountable Internet Protocol (AIP), a “clean slate” approach to accountable networking [1]. AIP uses a two-level selfcertifying addressing structure, and is shown to provide solutions to problems such as denial-of-service, source spoofing,

and route forgery. Although AIP makes a compelling case for accountable networking, it is highly unlikely to have a practical impact because it alters the underlying architecture of the Internet in fundamental ways. Another approach aiming for perfect accountability was put forth in [2]. A perfectly accountable system is one in which it is impossible to spoof another entity. The authors’ protocol is similar to ours in that it attaches a cryptographic tag to each packet, but differs in that each router must validate the tag for every packet. It is largely a theoretical proposition for a potential future Internet, and is thus not practical in the current Internet environment. A third attempt at accountability is Pretty Good Packet Authentication (PGPA) [3], a simple accountable framework with the objective of providing a reliable way of verifying whether a packet crossed a particular customer network. Unlike AIP, PGPA cannot be used by intermediate routers to ascertain whether the purported origin of a packet is accurate. However, PGPA can make network forensics a lot easier. Finally, Packet Obituaries [4] is a framework functioning at the autonomous system (AS) level which provides feedback to an AS on the fate of packets sent to destinations outside the given AS. The feedback provided by Packet Obituaries can be used in different ways, including quantifying network neutrality [5]. Both PGPA and Packet Obituaries require involvement from ISPs to deploy the necessary infrastructure. The social accountability framework differs from these four approaches in that it provides an accountability system that is incrementally deployable and based on common Internet protocols, requiring no significant involvement from ISPs. It is also an optional framework in that specific services could require social accountability while others do not. This allows services which require no accountability to exist outside our framework and seamlessly integrate with accountable services. Section II provides an overview of the social accountability framework. We address concerns such as scalability and security in Section III. We discuss possible applications of our work in Section IV, and Section V discusses experimental results from a prototype implementation we have developed. We conclude and describe future work in Section VI.

978-1-4244-5637-6/10/$26.00 ©2010 IEEE


II. T HE S OCIAL ACCOUNTABILITY F RAMEWORK A. Design Objectives The three main guidelines we followed in developing our accountability framework are as follows: • It should be incrementally deployable, i.e., it should be compatible with hosts who do use our framework. • It should provide accountability information to a host’s firewall or user-level applications. • It should work with minimal modifications to the operating systems and/or applications running on the hosts, and should require no changes to the underlying infrastructure of the Internet. To avoid any changes to host applications, or the Internet backbone itself, we must rely on the routing capabilities of the IP layer. As a consequence of this, we need to bind a user to her IP address and thus need a method of handling private IP addresses. This is done by mapping private IP addresses into a virtual IP address range, and will be described in Section II-C. Because of the IP layer’s lack of an identification scheme, we base our framework on online social networks (OSNs), which already connect millions of people and provide the notion of an organization (e.g., LinkedIn Groups). Our framework assumes the use of a single OSN as an identification provider, and will be denoted throughout the paper as “the OSN”. The user’s identity on the OSN is bound to that user’s IP address through IKE’s security associations [6]. Two users communicate via either IPsec AH or UDP encapsulation of IPsec ESP using null encryption1 [7], using the accountable security associations as identity verifiers. Figure 1 depicts the differences between the current Internet architecture and our framework. In order to make our framework incrementally deployable, it must be able to handle legacy hosts. This is done through a probing protocol, which determines whether a given destination is accountable or not. If a destination is found to be a legacy host, our framework resorts to the standard IP to handle the communication.

Fig. 1. Comparison of OSI model of the current Internet (left) with the modifications needed for the social accountability framework (right).

B. System Architecture Figure 2 depicts the overall system architecture of the social accountability framework. There are two main elements in our 1 UDP encapsulation of ESP is necessary for NAT traversal, otherwise AH is used.

framework: the personal gate (pGate) and social gate (sGate), which correspond to people and organizations, respectively. The pGate, running on a personal device, marks outgoing packets from the host and unmarks incoming packets after verification using IPsec AH/ESP. These marks are used to maintain accountability, and will be discussed in detail below. The sGate serves as a middlebox that (a) provides membership proof/vouching for a given pGate in the name of an organization (b) provides source accountability and (c) provides NAT traversal support. Vouching allows an organization to make certain claims about a user, i.e., an organization O can say “Alice is a member of O” to vouch for Alice when she is communicating with Bob. Source accountability means that since every pGate wanting to connect to a pGate with a private IP address must connect to an sGate first, this sGate acts as a witness to the transaction, and thus provides point-inthe-path accountability for pGates with private IP addresses. Finally, NAT traversal support is needed to cross private network boundaries, and is necessary to provide the source accountability mentioned above. The NAT traversal provided by the social accountability framework is similar to those found in [8], and will not be discussed further.

Fig. 2.

The social accountability framework’s overall system architecture.

Each device running within the social accountability framework runs a pGate which binds that device to the user by the user’s private key. Similarly, each server owned by an organization runs an sGate, binding that server to the organization. These sGates must be publicly routable, whereas the pGates can have either public or private IP addresses. A user can of course belong to multiple organizations, and thus a pGate can belong to multiple sGates. In order to integrate our framework with OSNs, we utilize the third-party application framework available on many OSNs, such as Facebook. The first time a pGate/sGate is launched on a machine, the software registers itself on the OSN using the user/organization’s ID, obtaining a device ID under this account. The device ID allows a user to maintain multiple devices under a single OSN account. The software also generates a public/private key pair. The private key is stored locally, while the public key is uploaded to the OSN. Additionally, each pGate keeps a list of friends and associated organizations, and each sGate keeps a list of its members. These lists are periodically updated to maintain consistency

978-1-4244-5637-6/10/$26.00 ©2010 IEEE


with the OSN. Although the pGate and sGate are used for different purposes, they share the same generic architecture. We refer to the generic part as the Gate in the following discussion. The Gate uses a packet interception technique to examine incoming and outgoing packets. Each time a packet is sent from a device, it is intercepted and processed by the Gate. When an unknown destination is encountered for the first time, the Gate initiates a probe to the destination. The probe is basically a way for the Gate to determine whether the destination is a legacy device or a device that is part of the social accountability framework. The connection initiator sends a specially-crafted ICMP Echo Request packet to the receiver, who, if socially accountable, responds with a specially-crafted ICMP Echo Reply packet, and if legacy, responds with the normal ICMP Echo Reply packet2 . The details are unimportant for the discussion below, and thus will not be elaborated in detail. After probing, if the destination host is socially accountable, the two parties establish security associations via the IKE protocol using the public keys retrieved from the OSN, followed by IPsec AH or ESP for the rest of the communication. If the destination host is a legacy device, communication proceeds as normal. C. Addressing and Sessions The addressing and session creation requirements within the social accountability framework are driven by two concerns: (a) the ability to hold every host accountable, whether it has a public or private IP address and (b) the need to establish security associations between Gates wanting to exchange traffic. In order to handle hosts within private networks, we map their IP address into the virtual IP address space 10.0.0.0/8. We chose this address space because it is rarely used in practice, as compared to, e.g., 192.168.0.0/16. In the rare case that 10.0.0.0/8 is used for the physical LAN of some network, a solution based on IPv4-to-IPv6 conversion can address this issue, where IPv4 addresses are mapped to an IPv6 address range, but we will not discuss this method further. Currently there are two types of sessions which are allowed in the social accountability framework: sessions between two pGates and sessions between a pGate and an sGate3 . These differ slightly, in that the sGate is also used for NAT traversal support, but for the discussion below we will consider them one and the same. We consider one of the most common scenarios that can arise: user A wishes to connect to user B over the public Internet, with both A and B having private IP addresses (see Figure 3). We assume that before a session is established between A and B, B has bootstrapped to its sGate C, and 2 Similarly,

specially-crafted TCP SYN/ACK packets can be used to serve the same purpose and are perhaps be reliable, but our prototype uses ICMP, which is why we describe that method here. 3 Since sGates mostly act as intermediaries/witnesses to communications between pGates, it is not necessary that sGates be able to communicate with each other.

Fig. 3. Session establishment between two hosts with private IP addresses, with the connection initiated by A.

has been assigned (by C) an IP address 10.1.X. The virtual IP address mapping is temporary, and once B leaves C it can be reused for another user. This bootstrapping process is essentially the same as session establishment between two pGates. We additionally assume for now that B’s virtual IP address as well as C’s IP address are public knowledge. Denote the visible source IP address and port of B (e.g., the IP address and port of B’s NAT) as BV and BVP , respectively. The steps in the handshake protocol for this case are as follows: • A establishes a session with C and maps all C’s member pGates from 10.1/16 to 10.Y/16, with 2≤ Y ≤255, in order to avoid collisions between members of different sGates. • A sends a probe request to B’s IP address 10.Y.X, which is redirected to 10.1.X by A’s pGate and encapsulated in the tunnel with C. • C sends an IKE request to B through their tunnel, where the source IP and source port are A’s visible IP address AV and visible port AVP . • C also replies to A through their tunnel with a probe response with source IP address and port as BV and BVP , respectively, to notify A that B is social accountable. • B replies to AV and AVP with an IKE response, punching a hole through B’s NAT. • A sends an IKE request to BV and BVP , punching a hole through A’s NAT. Note that two IKE requests are sent during this process; this is required to punch holes through both A and B’s NATs. The IKE protocol uses A and B’s public keys found on the OSN to verify their identities. Upon completion, the communication continues using UDP encapsulation of ESP. Note that A and B can communicate even if A is not a friend (or friend-ofa-friend) of B. The social accountability framework places no restrictions on who can talk to whom across the OSN; instead, this is left to a firewall or higher-level applications. For example, applications can set specific policies regarding which accountable users can access that application. D. Social DNS In the above discussion, we made the assumption that B’s virtual IP address and C’s IP address are known to A. Here, we show how to deal with this issue by introducing the concept of Social DNS. Assume pGate B has bootstrapped to sGate C. In order to be contacted, B publishes its fully qualified domain name (FQDN) as bob.domainC.org, with C set up to act

978-1-4244-5637-6/10/$26.00 ©2010 IEEE


as the authoritative name server for domain domainC.org. C also stores the binding of B’s FQDN to its virtual IP address. Once C receives a DNS query for B’s FQDN, it replies with B’s virtual IP address. Thus, when pGate A wants to contact B, A’s system tries to resolve B’s FQDN first. During this process, A gets the IP address of B’s sGate automatically, whose DNS response reveals B’s virtual IP address. However, the IP address in the DNS response is 10.1.X, not 10.Y.X as expected. Therefore, we use deep packet inspection to modify the IP address to 10.Y.X, where 10.Y/16 is the address space A assigned C’s member pGates to. This work can only be done at A’s end, because the mapping 10.Y/16 is only known to A. Therefore, all A needs is B’s FQDN to connect; the IP address of B’s sGate as well as B’s virtual IP address need not be known a priori. Our social DNS is different from traditional DNS systems in that the DNS data in our system are much more dynamic. It must be updated every time a host has successfully bootstrapped or confirmed to leave. Because this information is needed at any given time, we expect that the changes should take effect instantly. This can be accomplished by using, for example, BIND Dynamically Loadable Zones [9]. E. Vouching Mechanism Besides the end-to-end accountability between users described above, our framework also allows a vouching mechanism, where organizations become involved in the handshake process between users to provide membership proofs, e.g., “user A belongs to organization C”. This membership proof can be a credential signed by the organization’s private key. Whether vouching is needed for an end-to-end connection is up to the settings of the pGate. If required, the other pGate has to transmit membership proofs from some or all of the organizations it belongs to. III. D ISCUSSION Here we address several points that were not covered in the above system architecture description. A. OSN Involvement The social accountability framework relies heavily on an existing online social network (OSN) infrastructure. Since many OSNs (e.g., Facebook) already provide APIs for thirdparty application development, our system can be built directly into the OSN’s pre-existing application framework. Thus, most of the load is handled by the application server, rather than the OSN itself. B. Scalability One obvious concern is that of scalability. As more people use the social accountability framework, it must be able to handle the additional load on the OSN and the sGates (the load on the pGates is largely independent of the size of the network). Each will be discussed in turn below. As more and more hosts become socially accountable, the OSN must be able to handle the added load of retrieving the

public keys for these hosts. Because most of the load is offset to an application server, this server can scale with the increased usage of our framework. Another potential scalability concern is that of the sGates. Each organization may serve anywhere from tens to millions of members, depending on the size of the organization, and this load will be carried over to the sGates. By allowing a single organization to maintain multiple sGates, the ability for an organization to handle additional load is thus similar to scaling, say, a website due to increased traffic. It is easy for an organization to deploy more sGates as the need arises, and thus the scalability of sGates is not an issue. Another scalability issue is that of whether the trust in the system diminishes as the number of users increases. Obviously, this trust is highly dependent on the user herself. While some users may have hundreds of online friends, only several of whom they actually know, others may limit their online friends to those they know in person. Thus, the former user may not be concerned with accountability among her “friends” whereas the latter may desire full accountability. Thus, the trustworthiness in using our framework is highly dependent on each individual user/organization’s policies and is largely independent of the size of the social network as a whole. C. Security analysis Because our protocol is built on pre-existing protocols, its security depends largely on the security of IKE and IPsec. While no protocol can be perfectly secure, these two protocols are largely believed to be “secure enough”. One form of attack is that of trying to make the framework attribute a set of actions incorrectly. For example, a host can spoof the source IP address in its packet to attribute the action to someone else. This attack is infeasible because we bind the security association used in the IPsec protocol to the IP address specified in the IKE protocol. If the attacker modifies the source address between the IKE and IPsec stage, the spoofed address will be detected and the packet will be discarded. Another issue is that of the pGates; because they run on a user’s device, they can of course be tampered with. This is not really an issue because our framework is optional in the first place. If companies would like to force their users to be held accountable, they can of course install the pGates as part of a Trusted NIC [10]. D. Differences with hierarchical PKI and Web of Trust Two of the most popular (and dissimilar) key management systems are the hierarchical public key infrastructure (PKI) and the “web of trust” model that has grown out of PGP [11]. Each will be briefly summarized and compared with the social accountability framework’s key management system. Hierarchical PKI uses a tree of key certificates, where the root node is some trusted organization. Any given node in the tree can be verified by traversing the key-chain leading to it and verifying (and trusting) each of the intermediate nodes. In the “web of trust” model, individual keys are signed by

978-1-4244-5637-6/10/$26.00 ©2010 IEEE


multiple users, and the trust of a given key lies in the trust a user places on its signers.

Fig. 4. Comparison of hierarchical PKI (left) vs. web of trust (middle) vs. social accountability framework (right).

Our framework aligns more closely with the “web of trust” model, as the trustworthiness of a public key is based on the social links of a user on the OSN, rather than the trustworthiness of a hierarchical key-chain. Because of the implicit trust in the social links between users, the same vigilance needed to trust a PGP key is needed in our framework. One significant benefit our system has over the “web of trust” model is that of key revocation; in the social accountability framework one simply uploads a new public key to the OSN, whereas using PGP, a new key must be resigned again from scratch. The differences are depicted in Figure 4. IV. A PPLYING S OCIAL ACCOUNTABILITY Here we describe several scenarios where the social accountability framework could be applied. A. Socially-Aware Firewalls/Applications Because our framework provides an interface for the higher layer applications on the OSI stack, any firewall/application can retrieve the social information of an accountable packet. For example, instead of traditional firewall policies based on the tuple (source IP address, destination IP address, source port, destination port, protocol), a socially-aware firewall could apply policies based on the people and organizations trying to connect. An application could also rely on this information to refine its services. B. Policing Blogs, Chat Rooms, etc. Many Internet services, such as blogs and chat rooms, are often seen as gathering places of various communities. Unfortunately, the discourse on these websites can be greatly effected by spammers and anonymous postings attempting to defame various members of the community. By applying social accountability to these websites, users can be held accountable for their postings. For example, a chat room can form a group on the OSN such that only members of that group can post in the chat room. Any troublemaker can easily be banned by banning that user from the OSN group. Membership to this group can also be tied in with the social links of the members (e.g., a user needs more than three friends within the group to be allowed to be a member). This technique can also be applied to blogs or any other types of meeting places on the Internet. The use of the social accountability framework in these venues will likely aide both the quality of discourse as well as the legal issues that arise from defamation online [12].

C. Controlling E-mail Spam E-mail is one of the services most in need of accountability. Spam is known to constitute a majority of total e-mail traffic, and it is often difficult to fully filter, even with IP address blacklisting. Using the social accountability framework, e-mail servers can be placed behind a pGate, and only e-mails that can be verified (according to some specific policy) would be allowed through. For example, all e-mail coming from a specific user or organization could be allowed through, whereas all other e-mail could be heavily filtered or sent to some other e-mail classification scheme. While there already exist specialized social network enhanced e-mail systems [13], our framework can easily be applied to improve existing servers. D. Social Forensics The large increase in computer-based crime has made the need for packet forensics and tracing that much more necessary [14]. With the social accountability framework, an organization can require all its members to be accountable, and thus can easily track their activities to their online social identity. Using, i.e., a Trusted Platform Module, this optional accountability could be made mandatory for devices owned by an organization which are loaned to its employees. E. Resource Sharing and Usage Control One secondary benefit of our framework is the consolidation of NAT traversal techniques into a single overarching system. This makes resource sharing and usage control much easier, as users behind NATs can be tracked individually rather than grouped together as one entity. V. P ROTOTYPE AND T ESTING R ESULTS We have developed an initial prototype of the social accountability framework which includes everything but the vouching mechanism of the sGates. The pGates and sGates are implemented in C, and use the libipq library (provided by netfilter [15]) to intercept the outgoing and incoming packets. This library captures packets at the kernel level and moves them to the user level for processing. Packets can also be injected from the user to kernel level. Thus, using libipq causes a noticeable degradation in the performance of our system due to the overhead of kernel-to-user and userto-kernel packet copying. This overhead is marked in the tables below. Because sGates acts like gateways for organizations, they can be subjected to significant traffic loads. In the future, to better handle high traffic intensities, we will port the sGate implementations to an in-kernel packet processing module using a system such as Click [16]. We benchmarked our implementation between two machines, one located in McGill University, the other at the University of Manitoba. The initiating machine was behind a NAT and had a private IP address, whereas the receiving machine had a public IP address. All measurements were conducted using iperf [17].

978-1-4244-5637-6/10/$26.00 ©2010 IEEE


The round trip time for both standard connections and connections using the social accountability framework was 32 ms. Table I shows the session establishment time of the social accountability framework. The results are as expected and show the overhead of our framework as compared with IPsec is 33 ms, i.e., the round trip time between the two machines. TABLE I S ESSION ESTABLISHMENT TIME ( PROBE + IKE) OVER 10 RUNS Configuration

Avg

Probe only Probe + IKE

33 ms 108 ms

Table II shows the end-to-end bandwidth between hosts connected by the social accountability framework within the same local area network4 . The overhead of the kernel-touser and user-to-kernel transfer of packets using libipq is roughly 15%. The overhead of our framework compared to the throughput using libipq is 7%, almost equivalent to the overhead caused by IPsec itself (6%). This demonstrates that the degradation in bandwidth of our framework is very similar to the degradation caused by using IPsec, and thus our framework has an acceptable amount of overhead. TABLE II M EASURED BANDWIDTH THROUGH THE GATES Configuration

Avg

Standard IP connection Standard IPsec connection libipq kernel/user transfer Both social accountable (using IPSec AH)

50 47 43 40

Mbps Mbps Mbps Mbps

VI. C ONCLUSION The social accountability framework uses links in an online social network to decide whether incoming traffic is accountable or unknown. The accountable traffic can be further attributed to the particular user who controls the sending host. Using our framework, one can determine who sent a given packet as well as any witnesses of that particular transmission. This is accomplished by (i) securely attributing a packet with its source IP address and (ii) attributing the source IP address to a user identifier on an online social network. In our framework, user participation is voluntary. However, various websites can require that users be accountable in order to access their services. Thus, the social accountability framework introduces accountability when needed while also retaining the baseline anonymity so fundamental to the success of the Internet. To keep the framework simple and friendly to operating systems and legacy applications, we use existing IPv4 addresses and protocols instead of introducing new addressing 4 We were unable to conduct the tests across the NAT due to the difficulty of getting a baseline bandwidth measurement of IPsec using ipsec-tools [18], which currently does not support NAT traversal.

mechanisms. Our framework also handles hosts with either public or private IP addresses by mapping private IP addresses into a virtual address space. The social accountability framework is lightweight and can be deployed on the Internet without requiring changes to its underlying infrastructure. Also, the framework is extensible enough to host a wide range of applications that can leverage accountable communications, such as network forensics and resource sharing. Another benefit of our framework is that legacy applications such as e-mail can readily benefit from it without undergoing any changes. We have implemented an initial prototype and demonstrated promising experimental results. For future work, we will build an in-kernel implementation of the social accountability framework, along with an implementation of the vouching/policy mechanisms. We will also demonstrate practical uses of the framework by building accountability-aware applications and applying the framework to legacy applications such as e-mail and web servers. Acknowledgements: The authors would like to thank Rasit Eskioglu for the use of his machine in benchmarking our implementation. R EFERENCES [1] D. Andersen, H. Balakrishnan, N. Feamster, T. Koponen, D. Moon, and S. Shenker, “Accountable internet protocol (aip),” in Proc. SIGCOMM. Seattle, WA: ACM, August 2008. [2] J. Mirkovic and P. Reiher, “Building Accountability into the Future Internet,” in Proc. 4th Workshop on Secure Network Protocols. Orlando, FL: IEEE, October 2008, pp. 45–51. [3] A. Haeberlen, R. Rodrigues, K. Gummadi, and P. Druschel, “Pretty Good Packet Authentication,” in Proc. 4th Workshop on Hot Topics in System Dependability. San Diego, CA: ACM, December 2008. [4] K. Argyraki, P. Maniatis, D. Cheriton, and S. Shenker, “Providing packet obituaries,” in Proc. 3rd Workshop on Hot Topics in Networks. San Diego, CA: ACM, November 2004. [5] R. Frieden, “A Primer on Network Neutrality,” Intereconomics, vol. 43, no. 1, pp. 4–15, January 2008. [6] D. Harkins and D. Carrel, “The Internet key exchange (IKE),” IETF, Tech. Rep. RFC 2409, November 1998. [7] A. Huttunen, B. Swander, V. Volpe, and L. DiBurro, “UDP Encapsulation of IPsec ESP Packets,” IETF, Tech. Rep. RFC 3948, January 2005. [8] B. Ford, P. Srisuresh, and D. Kegel, “Peer-to-Peer Communication Across Network Address Translators,” in Proc. USENIX, Anaheim, CA, 2005. [9] “BIND Dynamically Loadable Zones,” http://bind-dlz.sourceforge.net/. [10] D. Friedman and D. Nagle, “Building Firewalls with Intelligent Network Interface Cards,” Dept. Electrical & Computer Engineering, Carnegie Mellon University, Pittsburgh, PA, Tech. Rep. CMU-CS-00-173, May 2001. [11] P. Zimmerman, The Official PGP User’s Guide. MIT Press, May 1995. [12] D. Conway, “Defamation in the Digital Age: Liability in Chat Rooms, on Electronic Bulletin Boards, and in the Blogosphere,” Business Law Course Materials Journal, vol. 29, no. 5, October 2005. [13] P. Boykin and V. Roychowdhury, “Leveraging Social Networks to Fight Spam,” Computer, vol. 38, no. 4, pp. 61–68, April 2005. [14] E. Casey, “Network traffic as a source of evidence: tool strengths, weaknesses, and future needs,” Digital Investigation, vol. 1, no. 1, pp. 28–43, February 2004. [15] “netfilter.” [Online]. Available: http://www.netfilter.org [16] “The Click Modular Router Project.” [Online]. Available: http://read.cs.ucla.edu/click/ [17] A. Tirumala, F. Qin, J. Dugan, J. Ferguson, and K. Gibbs, “Iperf: The TCP/UDP bandwidth measurement tool,” 2004. [Online]. Available: http://sourceforge.net/projects/iperf/ [18] “IPsec Tools.” [Online]. Available: http://ipsec-tools.sourceforge.net/

978-1-4244-5637-6/10/$26.00 ©2010 IEEE