TARP: Ticket-based address resolution protocol

4324 W. Lootah et al. / Computer Networks 51 (2007) 4322–4337approximately 20 min, with the option of resettingthe expiry timer after each use [16].Since hosts implicitly trust the address associationsresiding in the ARP cache, if an adversarycan influence these values, the host can be manipulatedinto sending packets to the wrong hardwareaddress. The lack of authentication of address associationdata leaves hosts susceptible to reply spoofingand cache entry poisoning, commonly referredto as cache poisoning. In fact, freely available toolsare designed to exploit these vulnerabilities [51].Most IP stacks are designed to ignore unsolicitedARP replies. However, this does little to preventcache poisoning. An adversary can coerce a hostinto requesting a specific address by spoofing anInternet Control Message Protocol (ICMP) pingmessage. The spoofed message contains the targetedIP address, requiring the host to resolve the MACaddress to reply. By spoofing replies and poisoningthe cache of network hosts, an adversary can performboth Denial of Service (DoS) and Man in theMiddle (MITM) attacks [24]. Although such attackswere identified a decade and half ago [14], they stillexist today [15].Cache poisoning can be used to mount varioustypes of DoS attacks. In the simplest case, theadversary replaces the MAC address of a particularhost with another value. When the victim attemptsto communicate with that remote host, all traffic issent to the wrong MAC address. This effectivelydenies service to the remote host. If this remote hosthappens to be the gateway, the host will be unableto communicate with hosts outside of the subnet.Finally, if the adversary knows the IP address ofall nodes on the subnet, cache entries can be craftedso that the victim cannot communicate with anyremote hosts.While DoS is a serious concern, cache poisoningresulting in a MITM attack is more dangerous. Thisattack, as shown in Fig. 1, not only allows theadversary to insert messages into the communicationchannel, but more importantly, it often goesundetected. Furthermore, cache poisoning used inthis manner allows eavesdropping even on a layer-2 switch. In order to launch this attack, the adversarymust effectively manipulate the caches at bothends of a conversation. Once both ends believe theadversary is the correct remote destination, manipulatingpacket streams is trivial.3. Related Work3.1. External solutionsSeveral attempts have been made to address thesecurity issues posited above. Some attempts usemethods external to the protocol. These methodsdo not use cryptography and do not modify the protocolin any way. For example, it has been proposedthat hosts be configured with static ARP entries [1].While this is viable for very small and static networks,it leads to considerable administrative overheadfor large dynamic networks.Port security [17], a security feature available inrecent switches, restricts the use of physical portsto configured MAC addresses. This approach onlyprevents certain kinds of MAC hijacking, but doesnothing to prevent MITM attacks. Hence, it is onlya partial (and in many ways limited) solution.Dynamic ARP Inspection (DAI) [19], a securityfeature available on some recent network switches,is another solution external to the protocol. DAIprovides security by preventing invalid or maliciousARP packets from being forwarded on the network.When DAI is enabled on a network switch, theswitch inspects ARP packets before forwardingthem. ARP packets are compared to a database ofvalid IP-to-MAC address bindings. If an ARPpacket contains a valid binding, it is forwarded;otherwise, it is dropped. Clearly, key to the properTrafc intendedfor BobMalloryMallory forwardsto BobAliceMallory forwardsto AliceTrafc intendedfor AliceBobIP Bob= MAC MalloryIP Alice= MAC MalloryFig. 1. Example of a man-in-the-middle attack in progress.

W. Lootah et al. / Computer Networks 51 (2007) 4322–4337 4325operation of DAI is the IP-to-MAC address bindingdatabase. A system administrator can maintain thisdatabase manually, or preferably it can be builtusing DHCP snooping [18]. DHCP snooping, alsoa security feature, can be used in concert withDAI. With DHCP snooping, the port on whichthe network DHCP server is connected is labeled‘‘trusted,’’ while all other ports are labeled ‘‘untrusted.’’Only DHCP server packets that originatefrom a ‘‘trusted’’ port are forwarded, while all otherDHCP server packets are dropped. When DHCPsnooping is enabled on a switch, it acts as a firewallfor DHCP traffic. It also builds and maintains adatabase of IP-to-MAC address bindings frominformation in DHCP packets. This database canthen be used with DAI to provide security againstARP-based attacks.Although DAI with DHCP snooping can provideeffective security against ARP based attacks,it is not widely available on commodity layer-2switches. Moreover, the overhead of inspectingpackets at layer-2 can be prohibitive. The overheadof deep inspection increases latency and has a negativeimpact on throughput. It is also important tonote that DAI and DHCP snooping are not availablefor wireless environments, where physical portsecurity is not available due to the shared medium.However, this technique is applicable for wirelessnetworks that create virtual ports, e.g., IEEE802.1X [4]. Note that 802.1X alone does not solvethe ARP security problem; it simply authenticateshosts that attach to the network. In many cases,even authenticated hosts pose a significant threat.A final class of external solutions attempt todetect misbehavior, rather than prevent it. ARP-Watch [33], a network-level detection device, detectsmalicious ARP packets by monitoring MAC/IPaddress pairings occurring on a subnet. Conversely,host-level detection services differ in that each hoston the network attempts to detect malicious messagesarriving at the local interface [52]. This isachieved by detecting duplicate and/or unsolicitedARP packets. Detection techniques are punitive bydefinition, and hence are of limited utility in manyenvironments.from injecting malicious messages, it does not preventauthorized, but untrustworthy hosts, frominjecting malicious messages. SLL is an example ofa solution that provides message authenticity butno proof of IP address ownership.In another approach, Gouda and Huang [26]propose the Secure Address Resolution Protocol.A secure server in this protocol shares secret keyswith each host on a subnet. The server maintainsa database of IP-to-MAC address mappings thatis updated periodically through communicationwith each host. All ARP requests and replies occurbetween a host and the server, and replies areauthenticated using the shared pair keys. Note thatthe server represents a singular point of failure andcongestion, which make it a poor match for mostnetworks.Another ARP security scheme, S-ARP [16],depicted in Fig. 2, uses asymmetric cryptographyto provide authenticity of ARP replies. Hosts useself-generated public/private key pairs certified bya local trusted party. Each host registers its publickey with the Authoritative Key Distributor (AKD)server. The server’s public key and MAC addressare also securely distributed to all hosts during abootstrapping process. S-ARP requests proceed asnormal ARP requests. However, S-ARP repliesare signed by the sender’s private key. Upon receivinga reply, the signature is verified using the sender’spublic key. If the receiver does not have thesender’s public key, or if the signature cannot beverified by the keys currently in its key ring, thepublic key of the sender is requested from theAKD. The AKD sends it to the requesting host ina signed message. If the new public key verifies thesignature, the reply is accepted and the public keyis cached; otherwise, it is rejected. To avoid replayattacks, messages are time-stamped and synchronizationmessages are exchanged with the AKD.AliceRequest(MAC Bob)Sig Bob(Reply(MAC Bob) || T1)Bob3.2. Cryptographic solutionsRequest(PublicKey Bob) || NSig AKD(Reply(PublicKey Bob) || N || T2)AKDA number of cryptographic protocols have targetedsecurity issues in ARP. In the Secure LinkLayer (SLL), all link layer traffic is authenticatedand encrypted. While this prevents authorized hostsFig. 2. S-ARP address resolution. Alice broadcasts a request forBob’s MAC address. Bob sends Alice a signed reply. Alicerequests Bob’s public key from the AKD. The AKD respondswith a signed reply.

4326 W. Lootah et al. / Computer Networks 51 (2007) 4322–4337S-ARP requires, at minimum, a single signaturegeneration and verification per address resolution.As illustrated in Section 6, this cost can be significant.3.3. Neighbor discoveryNeighbor Discovery (ND) [43] bridges the linkand network layer in IPv6. Among other tasks,ND performs address resolution. Similar to anARP request, an ND host sends a multicast NeighborSolicitation (NS) to determine the MACaddress of a peer. Upon receiving an NS, an NDhost replies with a Neighbor Advertisement (NA)asserting the association between its IP and MACaddresses. Unfortunately, the ND protocol specificationassumes no malicious hosts on the local networkand therefore is susceptible to the sameshortcomings as ARP.Since its inception, there have been a number ofsuggestions to secure Neighbor Discovery. IPv6relies on ND to perform a number of tasks in additionto address resolution, e.g., router discovery. Wefocus on those mechanisms related to securingaddress resolution in ND.The initial Neighbor Discover RFC [43] suggestedusing IPsec for message authentication. IPsec[31] requires IKE [28] to establish keys required toset up security associations between hosts. However,IKE uses IP addresses, therefore, key negotiationscannot occur until each host knows the MACaddress of its peer. Hence, IKE does not work forestablishing security associates for ND messages.Short of manually configuring security associationson all hosts, ND cannot use IPsec to secure addressresolutions.To address the security problems with ND,Kempf et al. propose using Address Based Keys(ABK) [30], which uses identity-based cryptography.In this scenario, IP addresses are used as publickeys. However, contemporary identity-based systemsrequire one or more heavyweight cryptographicoperations per signature generation orvalidation. Hence, their cost is prohibitive for manyresource poor devices. Furthermore, ABK is notappropriate for IPv4 due limited address space. IfIP addresses are reassigned and the public cryptographicparameters remain unchanged, multiplehosts have knowledge of the private key.Cryptographically Generated Addresses (CGA)[13] has also been proposed to address the securityin Neighbor Discovery. In CGA, a host createdpublic key and network address are combined withadditional parameters and hashed to create theinterface portion (lower 64 bits) of the IPv6 address.This provides immediate binding between a host’sIP address and its public key, which allows a hostto claim ownership of an IP address by demonstratingthat it posses the private/public key pair associatedwith that IP address.Secure Neighbor Discovery (SEND) [12] wasdesigned to provide security to ND. SEND includessupport for CGA. Along with nonce and RSAoptions, secure address resolution is addressed.When using SEND, the target host includes aCGA parameters option, a nonce option, and anRSA option in the NA message. The RSA optionincludes a signature that is generated using thehost’s private key. The host receiving the reply validatesit by first validating the CGA parametersoption, which insures that the target address wascryptographically generated using the included publickey. Second, the nonce is checked for freshnessand finally the signature in the RSA option is verified.If the reply is valid, the host uses the addressassociation to direct messages to the target host.SEND relies on CGA, which has undergone revisionsince its proposal. Initially, the public key washashed and truncated to produce the lower 62 bitsof the IPv6 address. As indicated by Arkko et al.[11], this technique is susceptible to brute forceattacks, and the current CGA RFC [13] defines amore complex transform. IPv4 addresses are only32 bits. Even if CGA used the full 32 bits, it wouldbe vulnerable to brute force attacks.The above mentioned solutions are either partialor limited in scope. None of the solutions simultaneouslyaddress both the compatibility and performancerequirements of current networks. As wewill show in the following section, TARP successfullyachieves resilience to cache poisoning and compatibilitywith ARP, at virtually no cost.4. A ticket-based approachThe security flaws in ARP stem from the followingfacts: (1) ARP messages lack guaranteed integrityand authenticity; and (2) ARP messages do not provideproof of IP address ownership. Therefore, addingauthentication alone to ARP messages does notsolve the problem. Authentication must also be combinedwith a means to prove address ownership.We address these requirements through theTicket-based Address Resolution Protocol (TARP)

W. Lootah et al. / Computer Networks 51 (2007) 4322–4337 4327[34]. TARP implements security by distributing centrallyBarring the inclusion of Ticket H j, the exchange isdistributedH i ! all: Request(MAC j )Request Reply +H j ! H i : ReplyðMAC j ÞkTicket H jgenerated attestations [7,50]. These attesta-tions, called tickets, authenticate the associationbetween IP and MAC addresses through statementsidentical to ARP. The method in which H j obtainsTicket H jdiffers depending on network requirements.A network administrator may choose to staticallysigned by the Local Ticket Agent (LTA). 2 Eachassign IP addresses to hosts. In which case,ticket encodes a validity period represented as astart time and an expiration time. Of course, theuse of time values assumes some form of loose clocksynchronization between the issuing LTA and thevalidating clients. Such synchronization is a commonrequirement for many protocols, and devicesfor its enforcement are well known [40].To securely perform address resolution usingTARP, a host broadcasts an ARP request. The hostwith the requested IP address sends a reply, attachinga previously obtained ticket. The signature onthe ticket proves that the LTA issued it, i.e., theIP-to-MAC address mapping is valid (or at leastwas at the time of issuance – see revocation below).The requesting host receives the ticket, validating itwith the LTA’s public key. 3 If the signature is valid,the address association is accepted; otherwise, it isignored. With the introduction of TARP tickets,an adversary cannot successfully forge a TARPreply and, therefore, cannot exploit ARP poisoningattacks.The remainder of this section discusses the protocolin detail and considers revocation. The followingnotation is used:whenever a host is added to the network, it is configuredwith the network public key, and networkconfiguration parameters including an IP address,and a ticket, as illustrated in Fig. 3. Because theassociations are unlikely to change frequently, itmay be acceptable to set long ticket lifetimes. However,there are security, performance, and administrativeconsiderations related to the selection ofticket lifetimes. We consider these issues in depthin Section 4.3 below.In dynamic IP networks, hosts are assigned IPaddresses and configuration parameters by a configurationserver using the Dynamic Host ConfigurationProtocol (DHCP) [21]. Each host receives alease on an IP address and sends a renewal requestupon expiration. At this time, the DHCP server mayor may not reassign the host the same IP address.In a TARP-enabled dynamic IP network, theDHCP server also performs the functionality of anLTA, as shown in Fig. 4. In response to a DHCPrequest, the server packages a ticket with the configurationinformation. Accordingly, the ticket expiresalong with the IP lease. Note that tickets are by definitionpublic; therefore, a secure communicationchannel is unnecessary. Having the DHCP serverH iA Generic hostplay the role of LTA eliminates the need for additionalticket distribution messages, hence maintain-Request(x)Request for object xReply(x)Reply with object xing simplicity of protocol design. Additionally,Ticket H iH i ’s digitally signed ticketusing this method of distribution is logical, asMAC iH i ’s MAC addressDHCP was designed to distribute configuration4.1. The ticket-based address resolution protocolparameters. Finally, note that if the LTA becomesThe means by which a ticket is created and distributedis dependent on whether the IP addressassignments are static or dynamic. In either case,Alicethe address resolution exchange consists of a broadcastStatic IP Networkrequest and unicast reply as follows:Ticket AliceTickets manuallyBobCarolDave2 The LTA is trusted by all network hosts to make claims aboutIP-to-MAC address mappings.3 The ticket-approach is also appropriate for optimized ARPimplementations that listen to all address resolutions, i.e., anyhost on the network can validate the ticket.Ticket BobTicket CarolTicket DaveFig. 3. Static IP Address Assignment – hosts receive TARPtickets during initial setup, and include them with each ARPreply.

4328 W. Lootah et al. / Computer Networks 51 (2007) 4322–4337AliceRequest Reply +Ticket BobBobtemporarily unavailable, the network will not ceaseto function. TARP resolutions will proceed untiltickets expire.A host requires the LTA’s public key in order toverify tickets. Key distribution is most secure if performedout of band. Another option, although notsecure, is Key distribution through assertion anduser acceptance, similar to that in the Secure Shell(SSH) protocol [53]. In fact, this technique is usedby some 802.1X [4] clients to receive and accept certificatesfor EAP-TLS [5]. Unfortunately, requiringthe user to accept keys allows an adversary newmethods of attack. For this paper, we only considera priori, out of band, manual, distribution of theLTA’s public key, therefore allowing the host toverify responses.4.2. Ticket formatTicket AliceCarolLTATicket BobTicket CarolTicket DaveDaveFig. 4. Dynamic IP Address Assignment – hosts receive TARPtickets during the initial DHCP exchange, and include them witheach ARP reply.Maintaining backwards compatibility with ARPis crucial for the adoption of any enhanced addressresolution protocol. Compatibility is achieved byARP ReplyMagicType SigLenMAC AddrIP AddrIssue TimestampExpiration TimeSignatureFig. 5. TARP Reply Packet Format – the TARP signature coversall fields from the Magic through the expiration time.Ticketintegrating the ticket into the ARP reply; nochanges need take place to the request. As shownin Fig. 5, the ticket is appended as a variablelength payload, with the ticket header modifiedaccordingly.The Magic field in the ticket header is used to distinguisha TARP reply from an ARP reply. In aTARP reply, the magic field is set to 0x789a0102. 4Since TARP has only one message type, the Typefield actually designates the cryptographic algorithm.5 The SigLen field indicates the signaturelength. The remaining fields contain informationrequired to ensure proper operation. The MACAddr and IP Addr fields create the address association.The Expiration Time field indicates how longthe ticket is valid. Issue Timestamp field indicateswhen the ticket was generated and is used for ticketrevocation as discussed below.It is possible to imagine tickets generated withvery short validity periods. In this case, the overheadof TARP approaches the overhead ofS-ARP. In fact, one can think of TARP’s validityperiod as a generalization of the freshness timestampand nonce included in S-ARP (see Fig. 2).That is, in an extreme case the LTA performs asimilar number of signatures as the AKD in S-ARP. However, this analogy is not exact. S-ARPmessages have timestamps on ARP replies andkey exchanges with the AKD. This allows theAKD to use longer timestamp intervals assertingtimestamps, but it must perform one signature perhost per timestamp period, and therefore will notscale as well as TARP.The ticket validity period is a key element in thedesign of TARP. It allows the cost of ticket generationto be amortized over the lifetime of a ticket. Thisconcept is not unique to TARP. DNS Security Extensions(DNSSEC) [8–10], uses a signature inceptionand expiry information in signature resource records(SIG RR). The signature inception and expiry providea validity period for SIG RRs. It is not surprisingthat both DNSSEC and TARP make use ofvalidity periods for signed data, as both protocols’primary objective is to add security to an addressresolution protocol while keeping overhead to aminimum.4 The magic field appeared in S-ARP, and we use it for a similarpurpose.5 As discussed in Section 5, our implementation currently uses1024-bit RSA, but other key sizes and algorithm may be used asappropriate and desirable.

W. Lootah et al. / Computer Networks 51 (2007) 4322–4337 43294.3. RevocationA reality of current networks is the fact that IP/MAC address associations can change; dynamicbindings (e.g., DHCP) or changes in network configurationcan occur before a ticket expires. To besecure, one must provide a revocation mechanismthat securely notifies clients which tickets are nolonger valid. Historical studies of revocation havesought to limit the cost of notification, e.g., CRLsand other data structures [6,29,32,39,44], limit notificationlatency, e.g., OCSP [42], or provide frameworksfor trading off security guarantees andsemantics [6,27,36].Revocation speaks to the central tradeoff ofTARP. Because a revoked ticket may be replayedat any time prior to its expiration, administratorsmay be tempted to keep the lifetimes short. However,ticket issuance costs grow at the linear inverseof the ticket lifetime. The ability to calibrate the balancebetween these competing factors through theselection of ticket lifetimes is a central benefit toits design.The simplest method of handling revocation is toissue certificates that are only valid for a short time.This is similar to the short lived certificates suggestedby Ellison et al. in the SPKI/SDSI system[23,48]. Because the tickets are only valid for ashort time, the vulnerability to replay is limitedand no notification is necessary. Note that a windowof vulnerability to replay also exists in S-ARP. The window that is equal to the cache holdtime of the ARP reply. Users of TARP can providesimilar window by setting the lifetime of the ticketto the ARP cache hold time. However, the burdenof the creating the tickets is on the LTA, ratherthan on the hosts themselves. We experimentallyexplore the costs of the ticket creation and validationin Section 6.ARP associations are long lived in networkswhere IP addresses are assigned manually. For thisreason it may be advantageous to create ticketswhose lifetimes are essentially infinite for these staticassociations. 6 In those rare cases where mappingschange, one can revoke through re-issuance; all clientswould only use the ticket with the latest expirytimestamp. This ‘‘latest ticket wins’’ approachwould be vulnerable to active attacks in which the6 The expiration time field is a 32-bit value. When set to itsmaximum value, the ticket will expire in 2038.adversary can block delivery of the new ticket. Suchattacks represent a powerful adversary within thelocal area network, and may signal larger and moreserious problems. Hence, the risk may be acceptablefor many environments.The most secure solution is to implement a separaterevocation service. Such solutions range fromthe distribution of simple signed certificate revocationlists [29] to instantaneous online verificationof ticket validity [42]. Note that simple solutionslike CRLs are likely most appropriate, as the costsof the complex ones would eclipse the costs ofsecuring ARP. Hence, we expect that simple, lowcost solutions will be used in all networks butthose with the highest security requirements. Wedefer further discussion of the design tradeoffs ofrevocation services to the relevant literature [37,41].An important question is how to recover in thepresence of compromise of the LTA. This issue issimilar to CA recovery in PKI systems. Unlikemany PKI deployments, all TARP clients servicedby an LTA are likely to be under a single administrativedomain. Hence, it is reasonable to expectthat each client can be manually configured with anew certificate as needed. Larger domains may usetechniques to reduce the impact of LTA compromise,e.g., key-splitting [35], issue and revoke LTAkeys through local certificate management services,and may use automated management tools for thedistribution of LTA signing keys.4.4. Attacks against TARPNetworks implementing TARP are vulnerable totwo types of attacks: active host impersonation, andDenial of Service through ticket flooding. In the followingwe discuss these attacks and show how theycan be mitigated.4.4.1. Active host impersonationAn active adversary that can block all communicationbeen two hosts can impersonate its victim byspoofing its MAC address and replaying a capturedticket. While this attack is present in the ARP, withTARP, the adversary can only impersonate the victimas long as the ticket is valid. Furthermore, a variantof this attack is present in any solution that usescaching. Fortunately, this attack can be mitigatedby using a layer-2 switch with port security, therebypreventing MAC address spoofing.

4330 W. Lootah et al. / Computer Networks 51 (2007) 4322–43374.4.2. Ticket floodingIncorporating cryptographic verification into anyprotocol opens the possibility for a processor-boundDoS attack. By flooding the victim with garbagepackets, the adversary causes the victim to devoteresources to cryptographic verification of eachpacket. This attack is made possible by the costimbalance between generating a garbage requestand verifying a request. Generic solutions exist forthis DoS attack, and many secure protocol definitionsdo not address the problem directly. However,we now suggest mitigation strategies for ticketflooding.A novice approach applies a stateful ARP implementation.In such an implementation, a host ignoresARP replies unless it contains a previously requestedIP address. An adversary can circumvent this protectionby preceding ARP replies with an ICMP pingrequest, thereby causing the victim to request a specifiedIP address.Another approach, suggested to solve a similarconcern in CGA [11], causes the host to defer ticketverification of the TARP reply until the informationis needed. In this case, the ARP cache includes a‘‘dirty’’ flag to indicate the entry requires verification.By foregoing ticket verification, the resultingprocessor overhead is limited to that present inexisting ARP implementations. Note, however, thatthis technique is not failsafe, as the adversary caninterleave ICMP ping requests with TARP repliesto invoke verification of dirty cache entries.A third approach addresses the cost imbalancebetween generating and verifying garbage tickets.Client puzzles [38] require the sender to solve asmall puzzle before the host commits resources forverification. Typically, the host has a trapdoor toallow quick verification of puzzle solutions; verifyingpuzzle solutions requires significantly lessresources than a ticket verification. Client puzzleshave been successfully applied to many other protocols,including TLS [20]. Note that an adversary canstill flood its victim with client puzzles, but significantlymore messages are required to achieve detrimentalprocessor loads.Both ticket and client puzzle flooding can be mitigatedthrough rate limitation, e.g., incorporatedinto layer-2 switches. Such switches can limit therate of ARP packets originating from any or allswitch ports, hence alleviating the victim’s processorload. However, while rate limitation reduces processorload, it impedes legitimate requests. There is noway to eliminate all effects of traffic flooding,regardless of the existence of cryptographic operations;ARP alone incurs some overhead. At best, ahost can minimize resource commitment untilrequest legitimacy is reasonably verified.5. ImplementationWe have implemented TARP on Linux, version2.6. The source code is available for download. 7Our implementation has two primary goals: to demonstratethat TARP indeed works and is compatiblewith ARP; and more importantly, to measure theoverhead of TARP and compare it to the overheadof both ARP and S-ARP.Our implementation uses a number of libraries,including libpcap [3] for packet capture, libnet [49]for packet injection, and OpenSSL [2] forcryptographic operations. Similar to S-ARP, ourimplementation, shown in Fig. 6, has two core components:a loadable kernel module, and a userspacedaemon. The kernel module exists to disable kernelprocessing of incoming ARP packets. Once kernelARP processing is disabled, the userspace daemon,tarpd, uses existing system libraries to interfacewith the kernel directly, performing the necessaryprocessing. By implementing the core functionalityin userspace, we gain portability and avoid addingcomplex cryptographic implementations in theLinux kernel. 8When loaded, the userspace daemon instructs thekernel module (through the /proc file system) todisable kernel processing of incoming ARP packetsand waits for ARP packets to arrive. When an ARPpacket arrives, it is processed according to its type.If it is a request, a TARP reply is sent. Otherwise,it is a reply, and the source IP address is comparedto whitelist entries (whitelists are described in Section7.2). If not found, it is treated as a TARP replyand the attached ticket is verified. If the ticket isvalid the ARP cache is updated using a netlinksocket, and the ticket is cached (in a hash table) tospeedup later verifications.The current implementation of TARP uses RSAwith 1024-bit keys. We choose RSA among a numberof alternative signature schemes because of itsfast signature verification and the availability ofhighly efficient open source implementations(OpenSSL). We also choose a 1024-bit key size as7 http://siis.cse.psu.edu/tools.html.8 The current CryptoAPI in the Linux 2.6 kernel does notsupport asymmetric cryptographic operations.

W. Lootah et al. / Computer Networks 51 (2007) 4322–4337 4331TARP DaemonUser Space/proc/sys/net/ipv4/tarplibnetlink libnet libpcapKernelKernel SpaceLoadableKernelModuletarp_modenable/disablekernel processingARP CacheARP LayerNetworkARPrequestsARPrepliesARPrequests &repliesFig. 6. The TARP implementation architecture (similar to S-ARP).it is fit-to-purpose, striking a good balance betweensecurity and performance.Our current version of TARP includes an administrativetool to generate the LTA’s public/privatekey pair as well as tickets for manual distribution.We have also implemented an LTA server fordynamic ticket distribution.During the design phase of the LTA, we haveconsidered two different approaches. In the firstapproach, a DHCP server performs ticket distribution.This requires modification of the DHCP servercode to include LTA functionality. In this case, theDHCP server sends TARP tickets along withDHCP OFFER messages. The ticket is included inthe message as a DHCP option. 9 Similarly, theDHCP client must be modified to parse and usethe ticket embedded in the DHCP OFFER message.Once a DHCP OFFER is accepted and an ACKmessage is received from the DHCP server, theDHCP client sends the ticket to the TARP daemon.This ticket distribution approach does not requireany specific ticket distribution messages; however,it does require significant modifications to bothDHCP server and client code.A second approach modifies neither the DHCPserver nor the client. In this approach, the LTA isseparated from the DHCP server. The LTA is triggeredby the messages exchange between the DHCPserver and client. Once a DHCP OFFER message issent by the server and accepted by the client, theLTA sends a special TARP message. This is anARP message with a special opcode (opcode 5),9 Some DHCP servers allow administrators to configure staticuser defined options; however, the LTA requires the field to bepopulated with a different ticket for each host.containing the ticket and binding the IP address inthe DHCP lease with the MAC address of the clientfor the lease duration. The client TARP daemonreceives the special TARP message and validatesthe ticket for use in future TARP resolutions.We choose the latter approach for implementingthe LTA. This approach has the advantage of notbeing dependent on the source or version of theDHCP server running in an environment, makingit much more deployable. We believe that an opensource TARP aware DHCP server and client arestill needed; however, we leave such an implementationfor future work.Our LTA uses the libpcap library to captureDHCP messages (UDP port 67 and 68). The DHCPoptions in the packet are parsed. Option 53 representsthe DHCP message type. It is used to identifyDHCP ACK messages. Option 51 represents thelease time in seconds and it is used to set the expirytime of the generated ticket. The ticket IP and MACaddress are copied from the fields yiaddr and chaddrfrom the DHCP message header. We use the packetheader provided by libpcap to ensure that theDHCP server generated the packet. This designchoice assumes the LTA process is running on thesame host as the DHCP server; however, givenanother secure method for the LTA to learn of completedDHCP transactions, the LTA and DHCPserver can reside on different hosts. For example, adedicated listener could reside on the DHCP serverand inform the remote LTA of events. Finally, theLTA uses the same libraries (OpenSSL and libnet)as tarpd to generate and send the tarp ticket.Our implementation of the LTA integrates seamlesslywith DHCP without the need for changes tothe protocol or its implementation.

4332 W. Lootah et al. / Computer Networks 51 (2007) 4322–43376. Performance evaluationIn order to understand the cost incurred byTARP, we performed two types of measurements:the macro-benchmark indicates the cost seen byan application, the micro-benchmark evaluates thedelay of the primary operations. For the macrobenchmarks,we compare our protocol to bothARP and S-ARP.Our test environment consists of two desktopPCs and included a laptop as the AKD in the S-ARP measurements. The desktops were equippedwith 2.8 GHz Pentium 4 processors and 1GB ofRAM, while the laptop contained a 1.0 GHz Pentium3 processor and 1GB of RAM. All machinesran version 2.6 of the Linux Kernel and were connectedvia a Gigabit Ethernet switch. Finally,because S-ARP [45] was written for an earlier versionof Linux, small updates were required to compileand run it in our environment.6.1. Macro-benchmarkTARP provides significant advantage overS-ARP due to the decrease in signatures and messageexchanges. The ticket-approach embodies thecentral design tradeoff. As described in Section4.2, the LTA performs significantly less signaturesthan the AKD in S-ARP; however, the genuine performanceadvantage of TARP lies in the client operations.In TARP, the host performs one signatureverification per received ARP reply, and if the ticketwas cached, only a memory comparison is required.In S-ARP, every ARP reply must be signed by oneendpoint and verified by the other endpoint. Futhermore,if the host receiving the ARP reply hasalready verified and cached the public key of thesender, it must also perform an exchange with theAKD and verify the response.We characterize TARP’s improvement over S-ARP by comparing the round trip delay. Measurementswere taken from an application to provide arealistic and consistent characterization of the systemlevel costs of both protocols. Finally, we comparethe round trip delay to ARP, which acts as abaseline for overhead in our test environment.To observe round trip delay from the applicationlevel, we used a custom ping application to flushthe system’s ARP cache after each ICMP echorequest/reply pair. This ensured each measurementincluded the overhead of address resolution. Weperformed five experiments, each consisting of1000 ICMP echo requests. These experiments measuredthe round trip delay for ARP, S-ARP, andTARP with and without caching.Table 1 summarizes the mean, standard deviation,and median of the recorded measurementsfor the protocols operating with caching turned on(best case scenario). The overhead was calculatedfrom the mean. As shown, we observed small standarddeviations for each experiment. This resultedfrom the largely controlled test environment.With caching turned on, the S-ARP reply sendermust perform a signature operation, and the S-ARPreply receiver must perform a signature verification.On the other hand, the TARP reply sender performsno cryptographic operations, and with cachingturned on, neither does the receiver. Table 1 verifiesthis difference. S-ARP observes an overhead ofapproximately 5.4 ms. This is 55 times greater thanTARP, which observes only a 98 ls overhead. Thedelay incurred by TARP is essentially unnoticeable,meeting our low overhead design requirement, andmakes the protocol appropriate even for deviceswith limited computational power.Table 2 summarizes the worst case performancemeasurements: when neither protocol enables caching.Again, the mean was used to calculate the overhead.With caching disabled, the delay introducedby S-ARP doubles, resulting in an overhead of11 ms. This is primarily due the network communicationwith the AKD. On the other hand, TARP istwo orders of magnitude faster, incurring only186 ls of overhead. Hence, when signature verificationis required, the delay incurred by TARPremains virtually insignificant.Table 1Round-trip delay for ICMP echo requests with caching (1000requests)Protocol x (ls) r (ls) Median (ls) x Overhead (ls)ARP 1178.59 259.98 1108 N/AS-ARP 6579.57 415.99 6535 5401.02TARP 1276.54 262.47 1206 97.95Table 2Round-trip delay for ICMP echo requests without caching (1000requests)Protocol x (ls) r (ls) Median (ls) x Overhead (ls)ARP 1178.59 259.98 1108 N/AS-ARP 12479.71 571.47 12176 11319.12TARP 1364.21 253.93 1297 185.62

W. Lootah et al. / Computer Networks 51 (2007) 4322–4337 4333In summary, our results show that TARP out-performsS-ARP by at least an order of magnitude in allexperiments, and by as much as two orders of magnitudein some cases. More importantly, the resultsindicate TARP incurs a virtually insignificant overhead.As discussed in our solution criteria, this is vitalto the adoption of a secure replacement for ARP.6.2. Micro-benchmarksOperationally breaking down TARP’s overheadprovides insight into how the protocol will performon different types of devices. TARP message flowbegins by requesting an address association. Sincethe request is identical to that of ARP, no overheadis introduced. When the remote host replies, a ticketis simply appended to a reply. While this requiresadditional system I/O and network traffic, the overheadis negligible. Upon receiving a TARP reply, ahost must verify the ticket signature. This stagerequires an asymmetric cryptographic operationand should therefore be investigated. As TARPoperates in userspace, cache updates result in additionalcontext switches, slowing down operation.Determining this cost foretells the gain resultingfrom a kernel based implementation. Finally, TARPgains significant performance improvements byamortizing the cost of ticket generation.Table 3 summarizes the micro-benchmarks. Theexperimental environment was more controlled thanthat of the macro-benchmarks, therefore, even with100 runs, a small standard deviation was achieved.The ticket signature verification consists mainly ofa 1024-bit RSA signature verification. This operationis only required when a received ticket doesnot exist in the cache. The average time of 119 lscorresponds directly to the difference between thetwo TARP variations measured in the macrobenchmark.The cache update also reflects the valuesmeasured in the macro-benchmark. If TARPwas implemented in kernelspace, 74 ls would be virtuallyeliminated, removing essentially all overheadwhen tickets are cached. Finally, ticket generationrequires 4.5 ms. As the ratio of requests to ticketTable 3Execution times in microseconds for TARP operations (averageof 100 measurements)Operation Average (ls) rTicket signature verification 119.12 2.00Update of ARP cache 74.07 7.15Ticket generation 4535.36 68.33Table 4Execution times in microseconds for ticket distribution operations(Average of 100 measurements)Operation Average (ls) rLTA Ticket Generation 5383.62 984.95New Ticket Verification 151.26 33.75generations approaches one, TARP performs similarlyto S-ARP. This is where the real power ofTARP is introduced.6.3. DHCP integration micro-benchmarksWe also measured the overhead of TARP associatedwith ticket distribution. Ticket distribution inour experiment was done by an LTA. The LTA processis triggered by the DHCP message exchangebetween a DHCP server and client. The LTA extractsthe mapping between IP and MAC addresses fromthe DHCP ACK message, which indicates that anoffer was accepted by the client and further acknowledgedby the server. The LTA generates a ticket andsends it the client in a special TARP message.In our experiment we measured the overheadincurred by the LTA for ticket generation as wellas the overhead incurred by the client for ticket validation.Table 4 summarizes our results. As shown,the results agree with the micro-benchmark findingin Table 3.7. DiscussionIn this section, we briefly discuss TARP withrespect to DHCP, interoperability, and SecureNeighbor Discovery.7.1. DHCPAs previously indicated, TARP does not includekey and ticket distribution messages. Instead of creatinga new distribution protocol, DHCP is used.Clients receiving tickets alongside DHCP repliescan readily authenticate the DHCP reply by verifyingthe signature on the ticket. However, this onlyprovides one-way authentication. In some cases,authenticating clients before distributing DHCPleases and tickets may be required in order torestrict network access or avoid attacks such as IPaddress pool exhaustion.Methods for securing DHCP exist. Suggestionsinclude Authentication for DHCP [22], where theprotocol has been extended with additional security

4334 W. Lootah et al. / Computer Networks 51 (2007) 4322–4337parameters. Of course, such systems need a way totie authentication into a central system. Many networkinstallations already have such devicesdeployed. Applicable back-ends include RADIUS[47], a common authentication database. How andwhen such authentication is performed is the subjectof network policy and influenced by available infrastructure,and hence should be dealt with as operationalneeds dictate.7.2. InteroperabilityThe success of any secure ARP replacement hingeson its ability to interoperate with legacy infrastructure,if only to support some transition period.ARP maps IP addresses to MAC addresses on a localnetwork. Within that network, transition to TARPmay be impeded by the speed of manufacturerupdates, e.g., gateway appliances and print servers.Hence, TARP supports incremental deployment.When operating in a mixed environment, two scenariosof interest result: (1) an ARP host, H a , sends anARP request to TARP-enabled host, H t ; or (2) aTARP host, H t , sends a request to an ARP host, H a .In scenario 1, when H t receives an ARP request, itdoes not know if H a runs the original protocol ornot, because both request packet forms are identical.H t proceeds to return a TARP reply. H a receives thisreply and parses it correctly. This occurs, because toan ARP host, the ticket simply appears as networkgarbage. Hence, H a can successfully resolve H t ’sMAC address and therefore transmit data.In scenario 2, H a receives a TARP request, whichis identical to an ARP request, and replies to H twith an ARP reply (no ticket attached). As H t cannotverify the address association, it ignores thereply. After time elapses, the higher layer protocolson H a time out. The only barrier keeping the mixednetwork from functioning is the verification of anARP reply by a TARP-enabled host. A TARPenabledhost cannot simply accept all ARP replies;this invalidates any security gained from the newprotocol. In order to allow address resolution toproceed in scenario 2, TARP supports whitelists.Whitelist entries are one of two types: whitelistedIP ranges, or static ARP mappings.TARP supports whitelisted IP ranges. Thisallows a DHCP server 10 to distribute IP addresses10 The DHCP server signs the whitelist with the network privatekey.from two different pools – ARP hosts, and TARPhosts. Such a configuration may be necessary for atransition to TARP, as it is needed to specify preciselywhich hosts are participating in the protocol.These lists can also contain hard-coded MACand IP address mappings. While currently notimplemented, this type of whitelist can be distributedby the network administrator or DHCP server.This allows dynamic configuration of static ARPentries for known devices that do not supportTARP. Example devices include embedded hostssuch as routers that require vendor support for protocolupdates.Although TARP is designed to interoperate withARP to facilitate incremental deployment, hostsrunning ARP are not in any way protected byTARP. Moreover, TARP cache entries referencingwhitelisted hosts are also subject to poisoning forspecific addresses. In order to achieve the most fromTARP all hosts on the local area network should bemigrated to TARP.7.3. Secure neighbor discoveryAs described in Section 3.3, the Secure NeighborDiscovery (SEND) [12] protocol was designed toprovide security to ND. SEND adds a number ofoptions to ND that together provide messageauthentication and proof of address ownership.Address ownership is provided by the CryptographicallyGenerated Address (CGA) parameters option,while message authentication is provided by thetimestamp or nonce option along with the RSA signatureoption.SEND uses CGA to add distributed address resolutionsecurity to Neighbor Discovery; there is noneed for a central authority. 11 However, eachaddress resolution includes an RSA signature generationand verification. This overhead is similar to S-ARP with caching. As shown in Section 6, thisapproach results in an order of magnitude greateroverhead than TARP.We propose using tickets to secure Neighbor Discovery.Tickets can be included in ND messages as anew option. The ticket option includes a timestampand validity period. A signature is included as a newRSA signature option. The signature covers theaddress association and the ticket option, and isgenerated using the LTA’s private key. No nonce11 Recall that CGA cannot protect IPv4 address resolution.

W. Lootah et al. / Computer Networks 51 (2007) 4322–4337 4335or timestamp ND options are needed. By using thenew RSA and ticket options with ND, the cost ofsignature generation is amortized over the lifetimeof the address association.7.4. Wireless networksInsecure wireless network deployments haverekindled interest in ARP security. Increasing thebarrier of entry, e.g., using IEEE 802.1X [4] withEAP-TLS [5], prevents outsiders from affecting legitimatehost ARP caches, but it does not address thevulnerability in ARP. Frequently, network administratorsmust allow partially trusted hosts to join thenetwork. Therefore the security concern remains.TARP’s security model assumes an untrustedlocal network. This model is consistent with bothprotected and unprotected wireless networks.TARP operates between the link and network layers,therefore it is agnostic to the physical transmissionmedium and will operate unmodified onwireless networks.8. ConclusionsARP is essential to the proper operation of IPnetworks. However, the lack of authentication andproof of address ownership in ARP leads to a rangeof serious security vulnerabilities. Previous solutionsto ARP have failed to simultaneously address thecompatibility and cost requirements of current networks.We have introduced TARP: a Ticket-basedAddress Resolution Protocol, and detailed its implementation.Built as an extension to ARP, TARPachieves resilience to cache poisoning. We haveshown experimentally that TARP reduces cost byas much as two orders of magnitude over existingsolutions for security issues in ARP.ARP vulnerabilities will remain a serious networksecurity problem until a viable alternative isaccepted. We have shown TARP to be viable, butmuch work remains before our implementationcan be broadly used. Acceptance by the Internetcommunity and implementation of TARP not onlyin popular operating systems but also in networkdevices is needed to make ARP based attacks athing of the past.AcknowledgmentsWe would like to thank Patrick Traynor and KevinButler for their editorial comments as well as theSIIS Lab as a whole for their many suggestions inthe design of this work.References[1] Anatomy of an ARP poisoning attack, (accessed June2005).[2] The OpenSSL library, .[3] The packet capture library, .[4] IEEE standards for local and metropolitan area networks:Port based network access control, June 2001.[5] B. Aboba, D. Simon, PPP EAP TLS authentication protocol,Internet Engineering Task Force, March 1998. RFC2716.[6] C. Adams, and R. Zuccherato, A general, flexible approachto certificate revocation, (accessed June 1998).[7] W. Aiello, J. Ioannidis, P. McDaniel, Origin authenticationin interdomain routing, in: Proceedings of the 10th ACMConference on Computer and Communications Security,ACM, Washington, DC, 2003, pp. 165–178, October.[8] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, RFC4033, DNS Security introduction and requirements, InternetEngineering Task Force (March) (2005).[9] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, RFC4034, resource records for the DNS security extensions,Internet Engineering Task Force (March) (2005).[10] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, RFC4035, protocol modifications for the DNS security extensions,Internet Engineering Task Force (March) (2005).[11] J. Arkko, T. Aura, J. Kempf, V. Antyl, A. Nikander, M.Roe, Securing IPv6 neighbor and router discovery, in: theACM Workshop on Wireless Security, September 2002.[12] J. Arkko, J. Kempf, B. Zill, P. Nikander, Secure neighbordiscovery (send), RFC 3971, March 2005.[13] T. Aura, Cryptographically generated addresses (CGA),RFC 3972, March 2005.[14] S.M. Bellovin, Security problems in the TCP/IP protocolsuite, Computer Communications Review 2 (19) (1989) 32–48. April.[15] S.M. Bellovin, A look back at ‘‘security problems in theTCP/IP protocol suite’’, in: 20th Annual Computer SecurityApplication Conference (ACSAC), December 2004, pp. 229–249.[16] D. Bruschi, A. Orgnaghi, E. Rosti, S-ARP: a secure addressresolution protocol, in: Proceedings of the 19th AnnualComputer Security Application Conference (ACSAC), 2003.[17] Cisco Systems, Catalyst 4500 Series Switch Cisco IOSSoftware Configuration Guide, 12.1(19)EW, (accessedMay 2005).[18] Cisco Systems, Configuring DHCP Snooping, (accessed April 2006).[19] Cisco Systems, Configuring Dynamic ARP Inspection,, (accessed April 2006).[20] D. Dean, A. Stubblefield, Using client puzzles to protectTLS, in: USENIX Security Symposium, 2001, pp. 1–8.

4336 W. Lootah et al. / Computer Networks 51 (2007) 4322–4337[21] R. Droms, Dynamic host configuration protocol, RFC 2131,Mar. 1997.[22] R. Droms, W. Arbaugh, Authentication for DHCP messages,RFC 3118, June 2001, .[23] C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, T.Ylonen, RFC 2693, spki certificate theory, Internet EngineeringTask Force (1999), September.[24] B. Fleck, J. Dimov, Wireless access points and ARP poisoning:Wireless vulnerabilities that expose the wired network, .[25] J. Galvin, Public Key Distribution with Secure DNS, in:Proceedings of the 6th USENIX Security Symposium, July,1996, pp. 161–170.[26] M. Gouda, C. Huang, A secure address resolution protocol,Computer Networks 41 (January) (2003) 860–921.[27] C.A. Gunter, T. Jim, Generalized certificate revocation, in:POPL’00: Proceedings of the 27th ACM SIGPLAN-SIGACTsymposium on Principles of programming languages, ACMPress, New York, NY, USA, 2000, pp. 316–329.[28] D. Harkins, D. Carrel, The Internet key exchange, InternetEngineering Task Force (November) (1998), RFC 2409.[29] R. Housley, W. Ford, W. Polk, D. Solo, RFC 2459, InternetX.509 public key infrastructure certificate and CRL profile,Internet Engineering Task Force (January) (1999).[30] J. Kempf, C. Gentry, A. Silverberg, Securing IPv6 neighbordiscovery using address based keys (abks), http://www.watersprings.org/pub/id/draft-kempf-abk-nd-00.txt. draftkempf-ipng-secure-nd-00.txtwork in progress.[31] S. Kent, R. Atkinson, Security architecture for the Internetprotocol, Internet Engineering Task Force (November)(1998), RFC 2401.[32] P. Kocher, On certificate revocation and validation, in: R.Hirschfeld (Ed.), Financial Cryptography FC’98, vol. 1465,Springer, Anguilla, British West Indies, 1998, pp. 172–177,February.[33] L.B.N.L. (LBNL), ARPWatch: Ethernet monitor program,, (accessed May 2005).[34] W. Lootah, W. Enck, P. McDaniel, TARP: Ticket-basedaddress resolution protocol, in: Proceedings of the 21stAnnual Computer Security Application Conference(ACSAC), 2005.[35] M. Malkin, T.D. Wu, D. Boneh, Experimenting with sharedgeneration of RSA keys, in: Proceedings of Network andDistributed Systems Security, Internet Society, San Diego,CA, 1999, February.[36] P. McDaniel, S. Jamin, Windowed certificate revocation, in:Proceedings of IEEE INFOCOM 2000, IEEE, Tel Aviv,Israel, 2000, pp. 1406–1414, March.[37] P. McDaniel, A. Rubin, A response to ‘can we eliminatecertificate revocation lists?’, in: Proceedings of FinancialCryptography 2000, International Financial CryptographyAssociation (IFCA), Anguilla, British West Indies, 2000,February.[38] R. Merkle, Secure communications over insecure channels,Communications of the ACM (April) (1978) 294–299.[39] S. Micali, Efficient Certificate Revocation. Technical ReportTechnical Memo MIT/LCS/TM-542b, Massachusetts Instituteof Technology, 1996.[40] D.L. Mills, RFC 1301, network time protocol (version 3)specification, implementation, Internet Engineering TaskForce (March) (1992).[41] M. Myers, Revocation: options and challenges, in: R.Hirschfeld (Ed.), Financial Cryptography FC’98, vol. 1465,Springer, Anguilla, British West Indies, 1998, pp. 165–171,February.[42] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams,RFC 2560, X 509 Internet public key infrastructure onlinecertificate status protocol – OCSP, Internet EngineeringTask Force (June) (1999).[43] T. Narten, E. Nordmark, W. Simpson, Neighbor discoveryfor IP version 6 (IPv6). RFC 2461, Dec. 1998.[44] M. Noar, K. Nassim, Certificate revocation and certificateupdate, in: Proceedings of the 7th USENIX SecuritySymposium, January, 1998, pp. 217–228.[45] A. Ornaghi, S-ARP: a secure address resolution protocol,,(accessed May 2005).[46] D.C. Plummer, An Ethernet address resolution protocol orconverting network protocol addresses to 48.bit Ethernetaddress for transmission on Ethernet hardware, RFC 826,Nov. 1982.[47] C. Rigney, S. Willens, A. Rubens, W. Simpson, RFC 2865,remote authentication dial in user service (RADIUS),Internet Engineering Task Force (June) (2000).[48] R. Rivest, B. Lampson, SDSI a simple distributed securityinfrastructure, 1996, October, .[49] M. Schiffman, The libnet packet construction library,.[50] K. Seo, C. Lynn, S. Kent, Public-key infrastructure for thesecure border gateway protocol (S-BGP), in: Proceedings ofDARPA Information Survivability Conference and ExpositionII, IEEE, 2001, June.[51] D. Song, dsniff: a collection of tools for network auditingand penetration testing, , (accessed May 2005).[52] M.V. Tripunitara, P. Dutta, A middleware approach toasynchronous and backward compatible detection andprevention of arp cache poisoning, in: 15th Annual ComputerSecurity Application Conference (ACSAC), 1999, pp.303–309.[53] T. Ylonen, SSH – secure login connections over the internet,in: Proceedings of the 6th USENIX UNIX Security Symposium,USENIX Association, San Jose, CA, June, 1996, pp.37–42.Wesam Lootah graduated with a Masterof Science Student from the PennsylvaniaState University’s Department ofComputer Science and Engineering inMay 2006. He graduated from the OhioState University in 1997 with a BS inComputer and Information Science.After graduating with his BS, he wasemployed by the Government of Dubai,The United Arab Emirates and stillholds the position of Head of ApplicationServices. He managed one of the largest ERP implementationprojects in the Middle East for the Government of Dubai.The project entailed the design of a core model and the rollout of20 modules across 6 Government entities with over 40,000employees.

W. Lootah et al. / Computer Networks 51 (2007) 4322–4337 4337William Enck is a Ph.D. candidate in thedepartment of Computer Science andEngineering at the Pennsylvania StateUniversity. He received a B.S. (withhighest distinction and honors) and M.S.in Computer Science and Engineeringfrom the Pennsylvania State Universityin 2004 and 2006, respectively. His currentresearch efforts include operatingsystems security, network and telecommunicationssecurity, and secure hardwarearchitectures.Patrick McDaniel is an Associate Professorin the Computer Science andEngineering Department at the PennsylvaniaState University and co-director ofthe Systems and Internet InfrastructureSecurity Laboratory. His research effortscentrally focus on network, telecommunications,and systems security, language-basedsecurity, and technical andpublic policy issues in digital media. Hewas awarded the National ScienceFoundation CAREER Award and has chaired several top conferencesin security including, among others, the 2007 and 2008IEEE Symposium on Security and Privacy and the 2005 USENIXSecurity Symposium. He is also an associate editor of the journalsACM Transactions on Information and System Security, IEEETransactions on Software Engineering, and ACM Transactionson Internet Technologies. Prior to pursuing his Ph.D. in 1996 atthe University of Michigan, he was a software architect andprogram manager in the telecommunications industry.