Download - Department of Computer Science | CSU – Department of ...massey/pubs/journal/massey_jiss07.pdf · Title: 1 Author: administrator Created Date: 9/3/2007 4:56:10 PM

Transcript
  • adfhJISS ec 3 (2 ) 2007

    www.jissec.o rg

    Journal of Information System

    Security

    A Framework to Facilitate ForensicInvestigation of Falsely Advertised

    BGP Routes

    Indrajit RayEunjong Kim

    Daniel MasseyComputer Science Department

    Colorado State UniversityFort Collins, CO 80523

    Abstract

    Nearly all network applications rely on the global Internet routinginfrastructure to compute routes and deliver packets. Unfortunately, falseInternet routes can be maliciously introduced with relative ease into the rout-ing infrastructure. This is because Border Gateway Protocol (BGP), theInternet's global routing protocol, lacks basic authentication and monitoringfunctionalities. If false routes are introduced, it can lead to total collapse ofpacket forwarding leading to denial of service or misdirected traffic.Currently, it is impossible to prevent such malicious injection of false trafficroutes. We believe that an ability to identify false paths through efficientvalidation, proper recording and forensic analysis of routing data, willconsiderably help in the prosecution of the miscreant and will act as a strongdeterrent. In this work we propose such a mechanism. We use ICMP (InternetControl Message Protocol) traceback message with AS-PATH informationand link connectivity information for each path. Our path verification tech-nique is proportional to the amount of traffic carried on a path, uses efficientoff-line verification technique with which each router independently anddynamically keeps track of local database, and allows a destination to

  • adfhmonitor its routes, detect false paths used by remote sites, and record rout-ing data for later forensic analysis in the event of an attack. Last but not theleast, our approach does not require modifications to the BGP protocol andhence can be easily deployed.

    Keywords: Internet routing, security, routing forensics, BorderGateway Protocol, ICMP traceback

    Introduction

    The Internet plays an increasingly important role in commerce,government, and personal communication. A large-scale attack or even anunintended operational error can seriously disrupt critical services and havea major impact on the economy. In response, a variety of end system securitytechniques such as encrypted connections and virtual private networks (VPNs)have evolved. However, almost all such systems rely on the un-securedInternet infrastructure to compute routes and deliver packets. If the Internetinfrastructure fails to deliver data packets, there is very little the end systemscan do to recover. In this paper, we examine techniques for detecting invalidroutes in the Internet infrastructure and present an effective approach forgathering and extracting routing data from the network that can be used laterfor forensic analysis.

    At the global infrastructure level, the Internet consists ofthousands of AUTONOMOUS SYSTEMS (AS) (Braun 1989; Hawkinson andBates 1996). An AS can be viewed as a group of links and routers that areunder the same administrative control. Each AS is assigned a uniquenumber. For example, Colorado State University is AS 12145 and AT&T is AS7018. There are currently over 18,000 active Autonomous Systems on theInternet (Bates et al. 2006). The Autonomous Systems are ultimatelyresponsible for routing traffic through the Internet. The BORDER GATEWAYPROTOCOL (BGP) (Rekhter and Li 1995) is the de facto inter-AS routingprotocol; it is used to exchange reachability information between Autono-mous Systems. BGP is designed to cope with events that alter the structureof the Internet such as addition of new links and new Autonomous Systems,the failure (temporary or long lasting) of links, and changes in routingpolices (Stewart 1999). However, BGP presents several interestingchallenges for path validation and routing forensics.

    BGP contains very limited security mechanism (Murphy 2004) andimplicitly assume that routers advertise valid information. For example,suppose that AS 12145 (Colorado State University) incorrectly (maliciously)reports that it has direct connection to www.largecompany.com. Other BGProuters (at least those in AS 12145's neighborhood) will believe this route,and portions of the Internet will select this path as the best route towww.largecompany.com. When traffic arrives at AS 12145, the packets maysimply be dropped or someone may attempt to imitate (spoof) thewww.largecompany.com website. As a result of this false routewww.largecompany.com may notice a significant drop in traffic. However, it

    33Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhwill not be able to identify the reason for this lost traffic. If AS 12145 laterithdraws its false route, BGP routers at some point will simply switch back tothe valid path. Unfortunately, it will take a considerably long time for thechanges to propagate throughout the Internet. In addition, owing to the largenumber of BGP destinations and the large volume BGP routing changes, aparticular BGP path change is unlikely to trigger any alarms at remote sites.Thus such false announcement of BGP paths (whether unintentionally ormaliciously) has the potential to cause significant damage to the affectedsites.

    Note that the above problem is not at all hypothetical. One such failureoccurred on April 25, 1997 (Barrett, Haar and Whitestone 1997). A smallInternet service provider (ISP) in Virginia, USA, had a misconfigured BGProuter that injected incorrect routing information into the Internet. The injectedinformation claimed that the particular ISP had the optimal connectivity to allother Internet destinations. As a result a major portion of the Internet trafficwas delivered to this ISP. It overwhelmed the ISP's router and a number ofintermediate ones that forwarded packets to the misconfigured router andeffectively crippled the Internet for almost two hours.

    In this paper, we present an approach for monitoring, gathering andvalidating the route information to a destination. Our technique enables eachAS to determine if an advertised route to itself is a valid one. The techniqueworks briefly as follows. Suppose AS1 has incorrect path information for des-tination AS2. This can be owing to one of several causes like malicious adver-tisement of wrong path information by a neighboring AS of AS1, or mis-con-figuration at AS1 and so on. With our approach, AS2 will know within a shortamount of time that AS1 has incorrect path information about AS2. In addition,AS2 has the potential to know what other Autonomous Systems have invalidpath information about itself. If AS1 (or the other Autonomous Systems) isreachable from AS2, then AS2 can alert these ASes about the incorrect infor-mation (via some protocol which is, however, outside the scope of the currentwork).

    Our approach is based on exploiting the ICMP (Internet ControlMessage Protocol) traceback message (Bellovin 2000). As data packets flowthrough routers, occasional packets triggers the generation of an ICMPtraceback message. These traceback messages allow a destination toreconstruct the path used to reach the destination. Unlike other approachesthat attempt to monitor or validate all paths, we focus on paths that are ac-tively carrying data traffic. There are almost 18,000 different ASes that havesome path to a particular AS (based on the current number of ASes (Bates,Smith and Huston 2006)), but relatively few of these sites may be activelysending data traffic. (If a host within a particular AS is not communicating withanother host in a different AS at a particular instance, then there is no packetflowing between these two ASes.) By exploiting the ICMP traceback mecha-nism, we only send monitoring and validation messages for paths that areactively in use. We enhance the ICMP traceback message with AS-PATH1

    34 Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhinformation, and link connectivity information. Since there can be maliciousASes along the AS-PATH that can potentially modify this information, we alsosend a copy of each traceback message dispersed into fragments alongsomen (ideally disjoint) paths. The dispersal process is such that if any m ofthe n fragments reach the destination, the entire traceback message can bereconstructed. This reduces the probability that packets are unavailable be-cause they were (maliciously or otherwise) dropped or corrupted. The netresult allows a router to dynamically keep track of paths used to reach thedestination, monitor routing changes for the actively used paths to thisdestination, and provide a log that can be used to reconstruct routes in theevent of a suspected attack.

    Our goal in this paper is to develop a protocol that allowsforensic investigation of falsely advertised BGP routes. Automaticallyextracting enough routing information from the network so as to be able toidentify the reason for lost traffic (namely, that it has been triggered by someAS announcing an invalid path information) is quite challenging with currenttechniques. Nonetheless, such a facility is extremely useful. Our approachis one step in this direction. It can form the basis of an alarm triggeringmechanism that significantly increases the effectiveness of infrastructureadministration. As a side effect our approach provides a more fault-tolerant,fault-resilient, reliable and secure BGP routing protocol for the entire Internetinfrastructure.

    The rest of the paper is organized as follows. In the next section, weprovide a brief overview of the BGP threat model. Section 3 reviews some ofthe better-known solutions proposed by other groups. Section 4 describesour approach, and in Section 5 we summarize and conclude our suggestedapproach. Unsolved problems and future works are discussed in Section 6.

    BGP Vulnerabilites

    BGP (Rekhter and Li 1995) is a path vector routing algorithm, whereeach router advertises its best route to a destination. The route to a destina-tion includes the full path of Autonomous Systems used to reach the destina-tion (the AS-PATH). A router does not learn the full Internet topology but onlyone (possibly best) path to each destination. Given this partial topology infor-mation, it is hard to confirm the validity of a particular path and BGP routerstend to accept any path that is advertised. This leads to the following pos-sible problems in routing information.

    1. False origin: A false origin occurs when an AS announces a desti-nation prefix that it does not have a direct connection with or that itis not authorized to announce. Suppose AS1 announces that it isthe origin for destination prefix 129.82/16 which is reality belongsto Colorado State University. Some portions of the Internet mayprefer and adapt the path using AS1 to reach 129.82/16. They may,thus, begin to send data traffic to AS1 instead of to Colorado State

    35Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhUniversity. A faulty AS causing a false origin disrupts communica-tion between the real origin and other ASes.

    2. False path: In a false path, some routing table entries do not matchthe paths of corresponding nodes. For example, let AS1 announcesits path to AS2 as AS1 −Y − Z − AS2 . That is, AS2 is reachablefrom AS1 via Y and Z, in that order. However, let some other AS3 hasa path AS3 −W − AS1 −Y − AS2 . That is AS2 is reachable fromAS3 via W, AS1 and Y. This path is different from the one AS1 an-nounced.

    3. False data path: A false data path occurs if the path that data pack-ets actually take is different from the path found in the routing table.For example, AS1 has a path AS1 −Y − Z − AS2 to AS2. AS1 for-wards a packet for AS2 to Y. However, Y, instead of forwarding thepacket to Z, sends to another autonomous system, A, which has adifferent path to AS2, namely, A − B − Z − AS2 .

    Routing problems can be the result of mis-configuration,software and hardware errors, intentional attacks, and even simple routingdynamics. Software and hardware errors are easily detected and fixed at thelocal level. Routing problems due to routing dynamics are, in general,self-healing. They occur due to transient delays in routing convergence. Forexample, a router may withdraw a link from a path and thus a path thatoriginally used this link, now becomes a false path. However, eventually thisinformation will be propagated to other ASes and the problem will be fixed.We are, thus, more interested in trying to detect problems due to mis-con-figurations and deliberate attacks. Note that it is extremely difficult to deter-mine remotely if a problem is due to mis-configuration or deliberate attack. Infact, it may be impossible. Thus we do not aim at determining the root causeof the problem. Our focus is more towards alerting a destination AS to someproblem in a path to itself from another AS.

    Mis-configuration - Globally visible BGP mis-configurations was firststudied by Mahajan, Wetherall and Anderson (2002). They define two types ofBGP mis-configuration. The first is origin mis-configuration. This involves thefollowing: (i) accidental injection of routes into global BGP tables such asinjecting one or many more-specific prefixes (de-aggregation), (ii) announc-ing part of someone else's address space (hijacks) and (iii) propagatingprivate network prefixes. The second is export mis-configuration. This is theaccidental export of routes in violation of an ISP's policy. Mis-configurationsincrease routing load by generating unnecessary BGP updates. The incor-rect announcement can disrupt connectivity either partially or globally.

    Deliberate attacks - Two major attacks on the network routinginfrastructure are falsification and denial-of-service (DoS). A falsification isdefined as the introduction of a bogus BGP protocol message that differs

    36 Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhfrom a message that a correctly configured router would have sent (Hu,Perrig and Sirbu 2004). Attackers can falsify withdrawn routes, path attributesand network layer reachability information (NLRI). These are components ofthe BGP UPDATE message. The blackhole attack is a general attack thatrelies on falsification. In a blackhole attack, a malicious AS injects wrongrouting information to attract traffic that would otherwise not flow through it,thus gaining control of a path. The blackhole attack can occur not only byfalsification but also bymis-configuration. Denial-of-service (DoS) is aresource exhaustion type attack. In such an attack, the attacker causes arouter to perform resource-intensive operation, such as public-key verifica-tion or signature generation. These operations cause the router to slowdown. The AS may then accidentally filter out routes it otherwise announces.To the remote observer, this denial-of-service is indistinguishable from afailure.

    Related Work

    Perlman (1988) was among the first to examine the problem of rout-ing security. She defines two different types of failures namely, simple failurewhich consists of a node or link becoming inoperative and ceasing to func-tion completely, and Byzantine failures which are caused by nodes or linksthat continue to operate, but maliciously. By her definition, a node with Byzan-tine failure may corrupt messages, forge messages, delay messages, orsend conflicting messages to different nodes. Pei, Massey and Zhang (2004)summarize the various problems in Internet routing. They review variousapproaches for improving the resiliency of the routing infrastructure. Basedpartially on their observations we categorize these approaches into two broadclasses: Cryptography based approaches and Non-cryptographic ap-proaches. However, the distinction between these broad classes is some-what fuzzy. Many of the so-called non-cryptographic approaches do use somecryptographic techniques to provide support services to the main protocol.

    Cryptography Based Approaches

    Correct operation of the BGP routing infrastructure depends on theintegrity, authenticity, and timeliness of the routing information that BGP dis-tributes via UPDATEs. Using cryptography keying material provides strongauthorization and authentication capabilities to BGP control traffic. Most of thecryptography-based protocols make use of digital signatures and public keycertification. For these protocols, path validation is significantly expensivebecause of the large amount of data and large number of signatures andsigners.

    SECURE BGP: Kent, Lyn and Seo (2000) proposed Secure BGP(S-BGP) as a comprehensive security solution for BGP. It addresses most ofBGP's architectural security problems. Public key infrastructure (PKI) is usedto provide proper protection to the BGP routinginformation and validation.

    37Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhS-BGP protects the entire BGP UPDATE message by adding (i) Public KeyInfrastructure (PKI) to authorize prefix ownership and validate routes, (ii) anew attribute that ensures the authorization of routing UPDATEs, as well asroute modification at intermediate BGP speakers, and (iii) IPSec to providerouting message confidentiality. S-BGP uses certification hierarchies - anaddress space PKI, and an AS ownership and router PKI. It protects theAS-PATH from modification and truncation, and unauthorized advertisementsof an IP prefix.

    SECURE ORIGIN BGP: Ng (2002) proposes Secure Origin BGP(soBGP) to verify the origin of route advertisements and therebypreventing the advertisement of unauthorized prefixes. All information per-taining to security is handled by a new SECURITY message. This messageis used to distribute three types of certificates. The entity certificate binds anode or router in the network to a public key. Authorization certificates areused to verify if an AS is authorized to advertise an address block. Finally,policy certificates provide details on policy or performance. Proper validationof all certificates provides necessary guarantees about the origin of routeadvertisements. However, as in S-BGP, such verification and validation ofcertifiates is computationally heavy.

    SECURE PATH VECTOR: Hu, Perrig and Sirbu (2004) proposedSecure Path Vector (SPV) for securing against the truncation andmodification attacks. SPV improves on S-BGP by using more efficientcryptographic techniques. SPV is configurable to allow tradeoffs betweensecurity and CPU usage. With S-BGP, the performance overhead to verify andsign each UPDATE is unacceptable and the space overhead to store thepublic key is also significant. Since not only security but also performance isvery important concern for the Internet, SPV uses high-speed signaturealgorithms and verification tasks based on cryptographic hash functions toprovide very good performance.

    INTERDOMAIN ROUTING VALIDATION: Goodell et al. (2003) proposeInterdomain Routing Validation (IRV) as a receiver driven protocol. Theauthors formalize the semantics of address delegation and use on the Internet,and develop and characterize broad classes of origin authentication proofsystems. According to the authors "all ownership of IPv4 address is del-egated by IANA (the Internet Assigned Numbers Authority (http://www.iana.org))to organizations which may delegate further. Addresses are assigned to anAS for advertisement via BGP". Such delegation is represented by delegationgraphs and they are digitally signed. Recipients of BGP UPDATE messagescan corroborate the received information by this protocol. IRV is independentof the routing protocol and is used in conjunction with BGP.

    A major problem with S-BGP, soBGP, SPV and IRV is that all of themrequire a significant use of digital signatures. This is why we categorize themas cryptographic techniques. Generation and validation of digital signaturesare computationally intensive. A BGP router typically needs to process a hugenumber of packets at any given instance. Having to validate signatures on

    38 Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhevery packet unnecessarily burdens the router even more. A second majorproblem of these three protocols is their reliance on an established PKI.Without such a PKI, none of these protocols will work. A PKI requires a singletrusted root authority for proper functioning. On a global Internet basis it is amajor challenge determining any single such authority. Thus, from a practi-cal aspect, none of these protocols appear feasible. Assuming such a PKI isavailable, the three protocols face a third big challenge. For proper validationof any digital signature, a hierarchy of certifying authorities need to beaccessed potentially all the way to the root of the PKI. This involves availablenetwork connections. Thus the overall problem becomes circular in nature.For these protocols we need a network functioning in the proper manner. Forthe network to function in a proper manner we need the protocols to workproperly. Last but not the least, each of these protocols require significantchanges to the basic BGP protocol. Thus, it appears that these cannot bereadily deployed over existing infrastructure.

    Non Cryptographic Approaches

    Although cryptographic approaches provide strong security guaran-tee, problems with public key infrastructures and concerns over overhead,and correct implementation have prevented these techniques from beingwidely adopted. None of these cryptographic techniques is currently de-ployed in the Internet. Non-cryptographic based solutions, on the other hand,may provide fewer security guarantees, but can be deployed more readily intoday's network. Hence, they have been actively pursued to secure BGP.

    MULTIPLE ORIGIN AS: Zhao et al. (2001) look into the problem ofmultiple origin AS (MOAS). This is a type of conflict that occurs when multipleASes announce themselves as the origin of a particular prefix. It can arise forvarious reasons including mis-configuration, multi-homing and exchangepoints, or malicious attacks. Zhao et al. (2002) propose using the BGP com-munity attribute for a list of valid originating ASes to detect false route an-nouncement and prefix hijacking. Any AS which is not in the MOAS list isregarded invalid and alarm is triggered. Further verification process is re-quired at this stage. Note that since the emphasis is on detection rather thanreal-time prevention, the performance of the protocols is not a big issue.

    ROUTE FILTERING: Route filtering is a common way to control BGPmessages. With proper filters, bad route announcements can be preventedfrom propagating much beyond to its source. This reduces the impact to asmall portion of the Internet. Attackers have lesser opportunity of introducingroutes on the fly to the whole Internet and launch attacks. This localizes theimpact of bad routes and reduces the weakness, which potentially can beexploited by attackers. Wang et al. (2003) propose route-filtering approachesfor protecting BGP routes to the top level DNS servers. Their approach is

    1 An AS-PATH is a sequence of intermediate ASes between source and destinationrouters

    39Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhpractical for the top-level DNS servers (or for the well-known destinations)since their approach depends on the high degree of redundancy and stabilityin network connectivity to the server locations. However, the approach is notuniversally adoptable.

    ROUTING PATH VERIFICATION: In (Pei, Massey and Zhang 2003) theauthors develop a simple and effective approach to detecting invalid routingannouncement in the Routing Information Protocol (RIP). Their solutionuses probing message for invalid route verification. RIP is a distance vectorprotocol, which is a shortest path routing protocol. BGP, on the other hand, isa policy based path vector protocol. Thus, this approach cannot be employeddirectly to address the BGP route validation problem. However, the approachholds promise. If we verify the UPDATE message in a proper manner, falsepaths can be detected before it propagates and poisons other nodes.

    SOURCE TRACING: Padmanabhan and Simon (2003) argue thatensuring the robustness of packet forwarding is equally as important toincreasing the security of routing protocols as validating route updatemessages and ensuring their authenticity. The authors propose sourcetracing for this purpose. The key idea behind source tracing is to securelytrace the path of existing traffic, to prevent adversaries from misleading thetracer. Secure traceroute responses are authenticated using message au-thentication codes, to verify their origin and prevent spoofing or tampering.This requires a shared secret between communicating nodes. The authorspropose public key cryptographic techniques for this purpose. However, sincethis is done in an off-line manner, the computational overhead is much lessthan the so-called cryptographic techniques. Nonetheless, it remains to beseen if the protocol can be used in the scale of the Internet. This is because,as the authors point out, their protocol is successful in investigating faulty ormalicious routes only when the routing disruption is not too widespread - forexample, when there is only a single faulty router.

    ICMP TRACEBACK: In the original ICMP Traceback proposal (Bellovin2000) iTrace messages are defined to carry information on routes that anIP packet has taken. This mechanism is used to deal with denial-of-serviceattacks by verifying the source IP. When an IP packet passes through a router,iTrace is generated with a low probability of about 1/20000 and sent to thedestination. Lee et al. (2003) proposes using cumulative IP information toverify the true IP packet origin. When a router receives a IP packet andforwards it, it generates an iTrace message and appends its own IP addressto this iTrace message before sending it to the next hop. To improve theefficiency and usefulness of original iTrace, Mankin et al. (2001) propose theenhanced intension-driven iTrace with information about usefulness of theiTrace messages. However, at best these messages simply record the pathof links and routers that packets may have taken. They provide no informationon why a router selected a particular next hop.

    Our protocol is philosophically similar to IRV in the sense that it isdetached from the routing protocol. Our goal, as in MOAS, is to detect falsely

    40 Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhadvertised paths. Given the size and complexity of the global Internet routinginfrastructure and considering issues such as deployability, we believe de-tection is the best strategy. Moreover, detection can be performed in an off-line manner. Since our protocol does not affect the operation of the regularBGP protocol, we are currently not concerned with performance of thisprotocol.

    Out Protocol - Enhanced BGP ITrace

    To provide reliable and fault-tolerant BGP routing protocol, we need toadd appropriate mechanisms for monitoring and validating paths. As wereviewed in the last section, cryptography-based protection mechanisms,such as S-BGP, so-BGP and SPV, require significant computation and spaceoverhead in the router. It is too heavy to be deployed in the current Internetalthough they can be argued as being more robust against deliberateattacks. On the other hand, non cryptography-based protection techniques,such as path filtering, ICMP Traceback etc, which utilize certain propertiesfrom the network infrastructure to guard against faults and attacks, are gen-erally more deployable than cryptography-based techniques. There is, thus,no single complete solution to provide security and resilience to routinginfrastructure.

    Path vector protocols are similar to distance vector protocol, excepteach routing update includes a list of routers on the route instead of using themetric. Path information provides routers with partial information abouttopological connectivity. By default, a path vector protocol will choose a routewith the shortest path but policies may specify specific routers to preferor to avoid. Therefore, a node may want to verify each hop that the routingupdate has traversed as recorded in the path. A general way to performverification is as follows: each node adds authentication information in thepacket and the recipient individually verifies each authentication information.This approach requires the network overhead to carry a message authenti-cation code (MAC) and to verify it for each node in the path. We want to avoidusing this approach.

    BGP is a policy-based routing protocol (Traina 1995) and each ASchooses the path among the multiple routes it receives from its neighbors forthe same prefix according to its own criteria. An AS also can apply policy whenexporting a route. Generally, ASes filter incoming or outgoing announce-ments to implement policies such as peering and transit. Filtering can beimplemented using prefix filters, access lists, and route maps. Using thesebasic primitives and a few others, an AS can control the flow of announce-ments between its routers and their BGP peers (Mahajan, Wetherall andAnderson 2002). We use the advanced filtering technique with well-definedfiltering rules and ICMP traceback to provide both path and origin validation.However, adding more functionality into routers is not a recommendableapproach since routers already handle many complicated functions. Hence,

    41Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhour approach suggests using a separate server or a process to providesecurity.

    We model the Internet as a directed graph G = V ,E( ) ,whereV = Vn ∪Vd and E = En ∪ Ed . The nodes inVd represent desti-

    nation prefixes, and Vn is the set of ASes that are not destination nodes.

    Each edge in En connects two non-destination nodes and roughly corre-sponds to a BGP session. That is, a BGP session can be modeled as

    a,b( )∈En where a,b ∈Vn . Each edge in connects a destination prefixto a non-destination node and is given by. Each destination prefix d ∈Vdshould attach to at least one non-destination node a ∈Vnvia an edge in

    Ed . Multi-homed destination prefixes attach to multiple non-destination nodes

    in Vnvia edges in Ed .We model the BGP routing protocol as a simple path vector

    protocol (SPVP). SPVP is a single path routing protocolthat permits a node to select only one path as the best pathfor a destination and advertise it to neighboring nodes. A path from

    node to destination d, Pathv d( ) , is a sequence of nodes!vkvk−1K v1v0d, where ∀i, 1≤ i ≤ k, vi ,vi−1( )∈En and v0 ,d( )∈Ed.A path can also be the empty path, denoted by ε . When a node learnsmultiple paths to the same destination prefix v from different neighboringnodes, it selects the best path based on its routing policy. A node does nothave to announce every path it knows. Routing policy allows for a node toannounce only those paths it wants to announce. After complete routing tableis shared between neighbors, a route is incrementally updated only when anode's best path changes.

    AS-PATH Verification with ICMP Traceback Messages

    Routers need a mechanism to authenticate each routing informationthat is received from its peers not only for dynamic filter information update,but also for both origin and path validation. Ideally, each router should au-thenticate every route announcement and update message before acceptingit to detect false routing information. However, authentication of both routeannouncements and update messages is resource consuming and is notutilized in the current BGP protocol.

    42 Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhOur approach to path validation uses a modified version of the origi-

    nal ICMP Traceback (iTrace) message (Bellovin 2000). Instead of authenti-cating BGP announcement messages and update messages, we use ac-tual data traffic to collect proper connectivity information and AS-PATH infor-mation for AS-PATH and prefix origin validation. When data packets traversealong the route, each router on the path generates iTrace messages. TheseiTrace messages have the information of traced packet's source and desti-nation address, previous link, and the AS-PATH, which each router finds in itsown routing table to reach the destination. This solution fully relies on theInternet topology and efficiently verifies the AS-PATH and prefix origin withoutusing any cryptography. ICMP Traceback message is carried in an ICMPpacket.

    Figure 1 presents the current ICMP traceback (iTrace) message for-mat. The ICMP traceback message body consists of a series of individualelements. Figure 2 shows the individual element structures.

    Figure 1: ICMP traceback message format

    Figure 2: iTrace message element structure

    We modify the iTrace message to include important BGP information.This consists of the router's previous link information and the AS-PATH fromthe iTrace generator to the destination which is found in the AS's routingtable. We introduce three new tags to carry this information - tag 0x10 forTraced Packet Source Address, tag 0x11 for Traced Packet Destination Ad-dress and 0x12 for AS-PATH information. Table 1 lists the updated list of tagswith our new tags shown in the last three rows of the table.

    43Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

    VALUE 1 byteLENGTH (2 bytes)TAG (1 byte)

    Type (1 byte) Code = o (1 byte) Checksum (2 bytes)

    M essage Body

  • adfh!ag Value Element Name

    0x01 Back Link0x02 Forward Link0x03 Interface Name0x04 IPv4 Address Pair0x05 IPv6 Address Pair0x06 MAC Address Pair0x07 Operator-defined Link Identifier0x08 Timestamp0x09 Traced Packet Content0x0A Probability0x0B Router ID0x0C HMAC Authentication Data0x0D Key Discloser List0x0E Key Discloser0x0F Public-key Information0x10 Traced Packet Source Address0x11 Traced Packet Destination Address0x12 AS-PATH Information

    Table 1: Updated list of ICMP traceback message tags

    TRACED PACKET SOURCE ADDRESS (Tag = 0x10) / TRACEDPACKET DESTINATION ADDRESS (Tag = 0x11): This element contains thetraced packet source address / destination address, which is 4-octet for IPV4address or 6-octet for IPV6, address; hence the LENGTH field is 4-octet(0x0004) or 6-octet (0x0006). The traced packet source address elementformat is shown in Figure 3. The traced packet destination address elementformat is similar.

    AS-PATH INFORMATION (Tag = 0x12): This element contains AS-PATHinformation, which is found in BGP routing table. The length of the element isvariable since the number of ASes on the path is not fixed. The elementformat is almost same as in Figure 3 except the fields LENGTH and VALUEare variable in length.

    We use the BACK LINK element for link connectivity information fromthe perspective of the iTrace message generator. In the value field we add ASnumber pair for one of the sub-elements.

    44 Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfh

    Figure 3: Traced packet source address element format

    Figure 4 shows how our solution to the BGP path validationproblem works. In this example, the CSU web server (129.82.100.64) isconnected to AS1. AS-PATH from UCLA (131.179.96.130) to CSU web serveris AS8 − AS7 − AS6 − AS1 . When UCLA client sends data to CSU webserver, the data traffic traverses this path (represented by a solid line witharrows in figure 4). When a client sends a data packet from a UCLA machine,all routers along the path (AS8, AS7, AS6, AS1) have opportunities to generateiTrace messages. Each will generate a message with probability of 1/20000(as in the original iTrace specification). When the data packet traverses theAS7 router, it generates iTrace messages with the data packet's source ad-dress - 131.179.96.130 in our case - and the data packet's destination ad-dress - 129.82.100.64, it's previous link - (AS8, AS7) and the AS-PATH fromitself to the destination - AS7 − AS6 − AS1 . This AS-PATH is found in AS7'sBGP routing table. When AS7 forwards the data packet, it generates twoidentical iTrace messages. One iTrace message is attached to ICMP headerthat has as source, AS7 itself, and as destination, the data packet's destina-tion - 129.82.100.64. The other iTrace message is attached to the ICMPheader that has source as AS7 itself, but has as destination an arbitrary node(in our example, it is AS3). We assume that hopefully AS3 has a different pathto reach the destination. When AS3 receives the iTrace message, it simplychanges the ICMP header to send the iTrace message to the data packet'sdestination. The new ICMP header has as source AS3 and as destination129.82.100.64. Other intermediate ASes do exactly same thing as AS7 doeswhen they propagate the data packet to the destination. However, the iTracemessages generated by each AS carry slightly different information. TheiTrace message that is received by AS3 traverses along the path

    AS3 − AS2 − AS1 to reach the destination. The other iTrace message, which

    is directly sent to the destination, follows the path AS7 − AS6 − AS1 . Whenthe data packet arrives in AS6, the router does same thing as AS7 did togenerate and send iTrace messages. All other routers (AS4, AS5, AS9, AS10,AS11) never see either data packets or iTrace messages.

    At the destination, the BGP router first checks each iTrace message'ssource field. It finds three different iTrace messages with the same source,

    45Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

    TAG 0x10 LENGTH = 0X0004 or 0x0006

    Traced Packet Source Address (4 or 6 bytes)

  • adfh131.179.96.130. The first iTrace message has been generated by AS6, thesecond by AS7, and the third by AS8. The router constructs the path fromsource to destination based on link information and path information. Thelink information are link = () (this means that the client is directly connected),link = (AS8, AS7) and link = (AS7, AS6). The path information is AS8 - AS7 - AS6 -AS1, AS7 - AS6 - AS1, and AS6 - AS1. If there is no AS-PATH conflict, the routerregards AS-PATH AS8 - AS7 - AS6 - AS1, as a valid path from UCLA(131.179.96.130) to CSU web server (129.82.100.64).

    Figure 4: Path validation with ICMP traceback message

    The destination router may construct either a path tree or a path set forall source and destination pairs. If the destination uses a path tree, the routerbuilds a path tree based on the information collected from all iTrace mes-sages received. The path tree has root as itself and leaves as the sources ofdata packets. Each path on the tree from the root to a leaf corresponds to

    46 Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfheach AS-PATH. If the destination uses a path set, it makes a collection ofpaths from all sources. The decision between constructing all paths fromsources to this node and building one path tree is an implementation issue.

    Whenever the destination node receives iTrace messages, it com-pares new information with previous information. Any inconsistency triggersan alarm. There are three different situations and the reaction of the destina-tion should be different based on inconsistency types and reasons. The firstone is AS-PATH not directly connected to the destination.

    Figure 5: Example of invalid path with false origin

    For example, the destination node, AS3, gets the iTrace messagewith AS-PATH AS1 - AS2 - AS3 and AS2 is not its next hop neighbor. This is a veryserious situation since it is an obvious sign of an attack. In this case, therouter immediately sets a flag and sends an emergency message to a sys-tem operator. The second one is AS-PATH is not consistent; this means thatthe AS-PATH information does not match any previous AS-PATH information.This case can be interpreted in three possible ways. One is an attack/mis-

    47Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhconfiguration case, in which a false origin or malicious router is sending awrong reachability information to its neighbors. The other is routing conver-gence problem. This occurs when a link or a node fails. For both cases, thedestination produces a warning message and more verification processesare required to determine the reason. The third one is one router on the pathannouncing wrong AS-PATH information to make the AS-PATH longer thanthe real one. This scenario occurs when a router mis-configures the path toreach the destination or intentionally injects wrong reachability information.In this case, our approach detects the false AS-PATH based on missing pathderivation. Since real data traffic does not traverse routers that are not on thepath, the destination never gets the iTrace messages from them. Next twoexamples show what are the possible scenarios for last two cases and howAS-PATH validation with iTrace works to detect them.

    Example 1: Figure 5 presents a possible attack scenario. AS13 is afalse origin, which impersonates as the owner of the CSU web server. In thiscase, the AS-PATH to reach the destination 129.82.100.64 is announced as

    AS8 − AS7 − AS12 − AS13 . The data traffic from UCLA (131.179.96.130)uses this false path. Even though the correct path in this example isAS8 − AS7 − AS6 − AS1 , the intermediate routers on the false path simplyforward all the data packets that are sent from UCLA to the wrong destination.

    This is because these intermediaterouters cannot ever see the entirenetwork topology. All the routers generate iTrace messages with the wrongpath information. AS7, in particular, generates two iTrace messages with thewrong AS-PATH AS7 − AS12 − AS13 . One of these iTrace messages issent towards the false destination AS13, and the other to the neighboringnode AS11. AS11 forwards this iTrace message to the correct destination. Thelatter then detects a path inconsistency. It is quite possible that AS11 sends aniTrace message to the false destination. However, because of the richconnectivity of the Internet, there is high probability that some iTrace mes-sage is sent to a node that has a path to the correct destination. Indeed, if aniTrace message is sent as far as possible from the iTrace generator, themessage has a good chance of reaching the correct destination.

    When the iTrace message reaches the correct destination, the routernotes that the AS-PATH to it is AS7 − AS12 − AS13 . The router recognizesthat this information is generated by AS7. It also concludes that this informa-tion is incorrect as AS13 is not itself and AS12 is not its NEXT-HOP. A flag is setin this case and a report is sent to the system operator. Thus, with this iTracemessage, the destination node is not only able to identify an incorrect AS-PATH, but also detect and locate the false origin.

    Example 2: Figure 6 shows another example. Here the AS-PATH fromUCLA to CSU is AS6 − AS5 − AS4 − AS3 − AS2 − AS1 .Somehow AS4 believes that the AS-PATH to reach CSU web server is

    48 Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhAS4 − AS8 − AS7 − AS3 − AS2 − AS1 . Based on this reachabilityinformation, AS5 has the AS-PATH to reach the same destination asAS4 − AS8 − AS7 − AS3 − AS2 − AS1 . When data packets are sent fromUCLA, all routers along the path generate iTrace messages. AS1 collectsthese iTrace messages and examines each. The resulting accumulated AS-PATH information at AS1 is shown in Table 2. Nothing is inconsistent but thedestination never gets iTrace message originating from AS7 or AS8. After asufficiently long time if the destination does not receive any direct AS-PATHinformation from both AS7 and AS8, the destination suspects that neither AS7nor AS8 are on the path that data packets traverse. The plausible causes atthis stage are either AS4 getting wrong reachability information from itsneighbors or injecting it itself. Based solely on the AS-PATH information, thecause cannot be precisely determined. In this case, thedestination triggers an alarm and notifies the operator. Furtherinvestigation is required at this stage to figure out the problem.

    Figure 6: Example of invalid path with false reachability

    iTrace Generator AS-PATHAS2 AS2 − AS1AS3 AS3 − AS2 − AS1AS4 AS4 − AS8 − AS7 − AS2 − AS1AS5 AS5 − AS4 − AS8 − AS7 − AS2 − AS1

    Table 2: Accumulated AS-PATH information at the destination

    49Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

    AS6AS5AS4AS3AS2AS1

    Origin

    129.82.100.64(CSU Web Server)

    131 .179 .96.130(UCLA)

    AS7 AS 8

  • adfh

    AS-PATH and Origin Validation

    Our AS-PATH validation technique is different from other AS-PATH vali-dation techniques that try to authenticate AS-PATH information in BGP routingannouncement or update messages. These techniques need an additionalmechanism to validate the prefix origin since AS-PATH validation does notguarantee the authentication of prefix origin. With our approach, the destina-tion router independently derives AS-PATH from iTrace messages, based onreal data traffic. Each AS-PATH information from iTrace messages providescomplete or partial view of path from source to destination. Since a prefixorigin corresponds to the last router of AS-PATH, our approach does notrequire any separate validation process.

    Filtering

    Effective filtering techniques help enhance BGP security since BGP ispolicy based protocol and uses routing filtering to enforce various routingpolicies. Applying filters to incoming BGP route advertisement is very com-mon technique for routing configuration with using optional BGP attributessuch as weight, local preference, and so on. These filters prevent the router

    Figure 7: Advanced path filter design

    from accepting inappropriate route announcements, which violate the poli-cies. However, getting complete routing filters is very difficult since it requires

    50 Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

    ASi ASj

    Peer 1 Peer 2 Peer 3 Peer 4

    BG P R o utin g Process F ilters

    candidatepaths

    upd atevalidpaths

    re je ct inva lid p aths

    new paths

    LocalD ata base

    iTrace M e ssages

    BG PU P D AT E

  • adfh

    Table 3: Algorithm for AS-Path validation

    51Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhto know all routing policies and relationship of ASes, and to view a global AStopology.

    When a router receives UPDATE messages, ingress filters are usedto check the validity of the information. Similarly when UPDATE messagesare sent to peers, egress filters are used to control which routes are an-nounced (Nordstrom and Dovrolis 2004). Bellovin et al. (2001) applied filtersto control the growth of BGP routing tables. Their filtering rules are related toprefix allocation rules; these are decided by the Regional Internet Registries(RIRs) or operators. To identify the owner of each address block, InternetRouting Registries (IRRs) are commonly used. However, one of the prob-lem of using IRR is its databases are not well maintained and updatedbecause it is difficult to keep track of the lists for the large number of routers.Hence the records in IRR are often inaccurate.

    In the current work, we use the route filtering technique that was origi-nally proposed by Wang et al. (2003). In that work, the authors proposed pathfiltering approach to protect BGP routes to top-level DNS servers. They usedpath filtering to block invalid routes by restricting the routes to top-level DNSservers to change within a set of established routes, based on statisticalanalysis over history. Their approach can be deployed only for the top-levelDNS servers (or for the well-known destinations) since their approach trulydepends on the high degree of redundancy in the top-level DNS system andthe stability in network connectivity to the server locations. This schemeeffectively filters out potentially invalid paths based on the route history. Thepath filtering restricts the changes of the routes to the top-level DNS serverswithin a set of verified persistent routes. It provides resilient network infra-structure since it does not rely on the cryptographic techniques and IRRs.However, their verification mechanism, which is used to identify new validpaths, only works for DNS system since it utilizes the redundancy of the DNSsystems.

    We cannot directly use this approach for all BGP routers becauseBGP routers may not have high redundancy and network connection stability.For the general BGP routing protection, our design improves this limitationwith more practical verification technique with ICMP Traceback. Suggestedroute filters verify not only AS-PATH but also the origin AS of a route to whichthe prefix really belongs. The destination independently constructs AS-PATHwith its perspective based on iTrace messages and it does not depend onBGP announcement messages and UPDATE messages. We use almostthe same filtering processes that have been proposed by Wang et al. (2003).Figure 7 shows our overall approach. Each BGP router has a separate filterand a local database. The filter verifies all BGP UPDATE messages in anaggressive manner, based on general policies, path history, MOAS conflictinformation, and ICMP traceback messages. Only verified new path is addedto the BGP routing table and updated in the local database.

    52 Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhProtecting BGP iTrace Messages

    The iTrace message with AS-PATH information allows the destinationto learn the path a packet took through the network. Based on collectediTrace messages the path can be determined. However, a mis-configurationor an attack may prevent the iTrace message from reaching the true destina-tion. Thus we need to modify the protocol presented so that the probability ofan iTrace message reaching the destination increases. In addition, sincefalse iTrace messages can easily be injected in the Internet and/or existingiTrace messages can be easily modified we need to include some degreeof message authentication services and integrity services to the protocol.

    Figure 8: Network topology exemplifying problem withrelay location

    Strong authentication can be provided using a digital signaturescheme. However, as mentioned earlier in section 3.1, existing digitalsignatures schemes are not easily deployable because they need awell-established public key infrastructure (PKI). Such a PKI is currentlyunavailable for the Internet routing infrastructure. Additionally, before per-forming the cryptographic operation involving the public key, a certificatemust be validated. This increases the communication overhead. The otherway to provide authentication is to use secret key based messageauthentication codes. In order to use message authentication codes, how-ever, a secret key needs to be shared between the communicating parties.

    53Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

    D ata path before a ttack

    D ata path after a ttack

    R1

    R2

    R 3

    R 4R 5

    R 6

    R 7

    R 9 R 10

    D estin ation

    A ttacker

    So urce

    R 0

    R 8

  • adfhOver the Internet this requires using public key cryptography to establishsecure channels for distribution of secret keys.

    To make it more difficult for the attacker to compromise theintegrity and availability of the iTrace message we propose a unique schemebased on establishing relay points to transport a copy of the iTrace mes-sage. The relay points are nothing but some specially designated ASes. Wegenerate an identical copy of the iTrace message at the same time theregular iTrace message is being sent. We split this copy into n fragments insuch a manner that some m < n of those fragments can reconstruct theiTrace message but no l < m fragments can do so. The idea is that with a highdegree of probability, either the original iTrace message or the relayed onewill reach the destination. This is because in order to compromise the copyof the iTrace message, the attacker needs to compromise at least (n-m+1)fragments.

    To prevent an attacker from injecting a false iTrace message into theInternet we use an identity based signature scheme like the ones proposedby Shamir (Shamir 1984). Identity based cryptography is an asymmetric keytechnique in which encryption (signature) is done by a public key (private key)of the recipient (sender) and decryption (validation) is done by the receiver's(sender's) private (public) key. Like conventional PKI based signatureschemes, identity based signatures schemes use a trusted authority calledthe Private Key Generator (PKG). The PKG is responsible for generatingand distributing a private key corresponding to a particular entity. The privatekey is derived from the entity's identity. Thus unlike conventional certificatebased signature schemes there is no need of public key certificates bindinga public key to its owner. This significantly reduces the system complexityand the cost for establishing and managing the public key infrastructure.

    We use the tuple AS# , IP-address, router-MAC-adress as the identityof iTrace sources. Identity based encryption requires the signer of a mes-sage to obtain its private key from the PKG. The private key needs to betransmitted over a secret channel from the PKG. We solve this problem bysplitting the private key when its being transmitted from the PKG to the desti-nation, in the same manner as the iTrace message is fragmented and trans-mitted. Since our contribution is not in developing the particular identitybased scheme, we do not discuss this any further. Instead we focus onrelaying the iTrace message in the next section. For this discussion weassume that before the iTrace message is fragmented it is signed by thesource.

    Relaying iTrace Messages

    Every source of an iTrace message generates an exact copy of themessage before fragmenting and forwarding the copy to the relay points. Wecall each fragment of the duplicate message an iRelay message to differen-tiate it from the original iTrace message. We assume that the source has

    54 Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhalready identified a set of relay points that can be used. The challenge is howto select the relay points. The effectiveness of the BGP iTrace protocol de-pends on the location of the relay points in a given network topology. Weaddress the issue of selecting relay points in section 5.1.1.

    The source of the iTrace message uses Rabin's InformationDispersal Algorithm (IDA) (Rabin 1989) to split the copied iTracemessage into n pieces such that the message can be re-constructedfrom some subset of m pieces. Each fragment is distributed to a relay point.Since no relay point has the complete iTrace message, loss or modificationof one fragment carried by one relay point does not damage the iTrace mes-sage. In fact, use of this scheme makes the iTrace message tolerant to(n-m+1) failures. The destination collects m iRelay messages to reconstructthe original iTrace message. By selecting the parameters n and m in anappropriate manner we can control the space overhead for transmission ofiRelay messages. Rabin shows that if F is the original (iTrace) message and

    |F| be its size, then after the dispersal the size of each fragment will be Fm

    ; that is, the total size of the dispersed message is n ⋅ Fm

    . Since n can be

    chosen to make !nm : 1, Rabin's IDA is space efficient. Additionally, the maincomputation in IDA (both message fragmentation and reassembly) is matrixmultiplication, which requires O (m2) operations. Finally, if p is the probabilitythat a fragment reaches the destination then the probability that the entireiTrace message is available at the destination is .

    Placing and selecting relay points

    The effectiveness of our approach depends on the location of therelays in a given topology. This is illustrated by the following example. Werefer to the topology shown in figure 8.

    In Figure 8 the source R0 and destination R1are exchangingmessages. The attacker, R0 announces that it owns R1 's IP address block bysending bogus BGP announcement messages to its neighbors. Since theattacker is located nearer to the source, the source will begin to communi-cate with the attacker following this attack. However, with the same topology,if the attacker is R2, the attack does not affect the communication between R0and R1. This is because R2 is farther from the source than the destination R1.We regard the first case as a successful attack and the second one as afailed attack. Under a successful attack, iTrace messages may not reach thedestination. With certain selected relay points, such as R10 , a relayed iTracemessage would reach the destination. Under more serious attack, such aschanging the iTrace message contents or sniffing the iTrace packet, the

    55Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhintegrity of iTrace message can be compromised. This is because R10 iscloser to the real destination than the attacker. However, with poorly selectedrelay points, such as R5, relayed iTrace messages will not reach thedestination.

    Figure 9: False origin under different tier 1

    The ideal location for relay points is the next hop(s) from the destina-tion, for example R3 or R10 . This is because wherever anattacker is located iTrace messages will always reach the destination andprovide useful information. Moreover, it is very difficult for an attacker todisrupt the relayed iTrace messages. The best location for an attacker isexactly opposite of this - the next hop from the source, for example, R7 or R8.In this case, almost all relayed iTrace messages are sent to the attacker.Both successful attacks and successful relays require specific conditionsrelated to the network topology and the locations of the victim and an attackerover time. However, normally we do not have such specific information. Un-der this condition, the objective of placing a relay is to find a node whose pathto a destination is disjoint from the path from any source to the destination.

    Relay placement with the shortest path policy: Let usassume that we do not consider any routing policies other than shortestpath. Let the distance between a node x ∈Vn to another node y ∈Vd ( (Vnand Vd ) has been defined earlier in section 4.) be given by d (x, y) and repre-

    56 Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

    tie r (R ) = 16

    R 7R 3

    R 6

    R 8

    R 1

    R2

    R 4

    R 9

    R 5

    Relay node

    Attacker

    Source node

    Destination10.1.0.0/24

    tie r (R ) = 15

    tier (R ) = 39

    tier (R ) = 27 tier (R ) = 11

    tier (R ) = 12

    tier (R ) = 24

    tier (R ) = 13

    tier (R ) = 28

  • adfhsent the number of hops from x to y. To break ties, we give different weights tothe edges along this path. In such case, the distance is the sum of theweights of edges along the path. For source s, destination d, relay r, andattacker a, our system detects an attack if and only if d(r, d) 1 . An instance of the relay placementproblem can be reduced to an instance of the set-covering problem as fol-lows. Let X = Vd − a and !Y1,Y2 ,K ,Ym be the sets in F. Create a graph forthe relay placement problem that has one vertex x for each element of X andone vertex yi for each set Yi . Let Y denote !y1, y2,K , ym . For each yi ,assign an edge of weight 1 to each member of X that is contained in Yi . Inaddition, place an attacker a with edges of weight 1.1 to all elements of X.

    If there is a placement of relays that makes our system detect anattack for all destinations and that places a relay on a member x ∈X , thenthe vertices that are closer to x than to a, are x and its neighbors in Y. Move therelay at x to any neighbor of x in Y. The relay will now be at distance 1 to x,which is closer than the distance 1.1 that x is to a, and at distance 2 to theneighbors of x, which is closer than the distance 2.1 that they are from a. Thenew placement of relay is closer to all destinations than the attacker.Repeating this operation on all relays in X results in a satisfactory assign-ment where all relays are in Y.

    We just showed that there is a placement of R relays that allows oursystem to detect an attacker for all destinations, if there is a set cover of sizeR in the set-covering problem. Henceforth, we can consider only placementsof relays where they are all in Y. If the instance of the set covering problem hasa solution !Y1,Y2 ,K ,Yk , then !y1, y2,K yk is a solution to the instance ofthe relay placement problem. Since every member of X is an element ofsome Yi , every member of X is a neighbor of a relay and is at a distance 1

    from some relay and at distance 1.1 from the attacker a. Let yi be a destina-

    tion in Y. If yi contains a relay, it is covered. Otherwise, since every neighbor

    57Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhof yi in X has a relay as a neighbor, it is at distance 2 from some relay, whichis closer that its distance 2.1 from the attacker. That is, every destination iscloser to some relay that it is to the attacker.

    Figure 10: False origin under different tier 1

    Conversely, suppose there is no solution to the original instance ofthe set-covering problem. By the discussion above, it suffices to show thatthere is no solution where all relays are in Y. Since our instance of the set-covering problem is not satisfiable, there is no placement of relays in Y suchthat every member of X is a neighbor of a relay. This means that somex ∈X is at a distance greater than 1.1 from every relay. However, x is at

    distance 1.1 from the attacker. Every vertex in X − x{ } is at distance greater

    than 1.1 from x. Since X > 1 , our system does not detect at least onedestination.

    58 Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

    R 7R 3

    R 1R 4

    tie r (R ) = 25

    Relay node

    Attacker

    Destination10.1.0.0/24

    Source node

    R 6

    R 2

    R 5

    R 9

    tie r (R ) = 12

    tier (R ) = 4 2

    tier (R ) = 13

    tier (R ) = 11tier (R ) = 27

    tier (R ) = 28

    tier (R ) = 39

    tier (R ) = 6 3

    R 8

  • adfhRelay placement with no-valley policy: Relays can be placed using

    the ``no-valley'' policy. The policy can be described as follows. Eachnode v ∈Vn is assigned an integer tier value, denoted by v ∈Vn . A tier valueof 1 is considered the highest tier level and each successive integer providesa lower tier level. We assume that every node knows the value of v ∈Vn forall v. We say that a path is valley-free if

    ∃i ∉tier v j+ i( )≥ tier vj( ),∀j > i and tier v j( )≤ tier vj−i( ),∀j ≤ i .Given a set of paths !p1, p2 ,K , pk to a destination d ∈Vd , a node vselects the valley-free shortest path after prepending itself to each path in theset.

    This policy changes the relay placement problem and solution in avery different way. The problem and its solution are not only related to theabsolute location of relays, attackers and destinations, but also to the tiereach node belongs to. What tier 1 nodes believe, significantly affects how ourapproach works. Given some tier 1 nodes believe false origin and some donot, the cases can be categorized into two cases:

    i. Case 1: The true origin and a false origin are located under differ-ent tier 1 nodes

    ii. Case 2: The true origin and a false origin are located under thesame tier 1 node and the parent AS of the true origin believes afalse origin.

    These two scenarios are shown in figures 9 and 10.For the first case, the true origin gets the path reports as long as one

    tier 1 node containing at least one relay node believes the real true origin.Refer to figure 9. An attacker is located under R1. Two other tier 1 nodes,R2, R3have the correct path to the correct destination 10.1.0.0/24. In this case, thedestination detects the attack based on the path report generated by anyintermediate node on the path from the data source to the attacker. With ourexample, R8 use the path R8 -R1 -R7 -R9 -10.1.0.0/24 to send data packets. R8generates the path report R8 -R1 -R7 -R9 -10.1.0.0/24 while R8 generates R1-R7 -R9 -10.1.0.0/24 and R7 generates R7 -R9 -10.1.0.0/24. All of them sendthe path reports to relay R5. Since both R2 and R1 have the correct paths to thedestination 10.1.0.0/24, the path report is received by the destination and theattack is detected.

    For the second case, no relay can work unless the relay islocated downstream of the true origin. Figure 10 shows an example of thisscenario. When the origin's upper tier believes an attacker, no path report isdelivered to the true destination. In this case, the origin has effectively beencut off from the Internet and thus may detect the problem by noticing that thetraffic coming from upstream has dropped considerably.

    59Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhRelay selection The main function of a relay is to receive the path

    report from iTrace generators and forward them to the destinations. Thereare two main strategies for selecting relays: (i) use a pre-defined static relayset that has been identified by some optimal algorithm that take into accountapplication requirements, communication structure and requirements andnetwork status, and (ii) randomly select relays. Using static, pre-defined setof relays does not require every node to understand how to handle pathreports. Only the nodes belonging to the set, need to know what to do whenthey get path reports that are not destined to themselves. A lot of work hasbeen done in determining such optimal algorithms in the context of intercon-nection networks for parallel and distributed systems (Foster and Kessekman1997; Grimshaw et al. 1997; Lowekamp et al. 1998; Subhlok et al. 1999).However, the ability to get network status information for a complex and dy-namic network as the Internet is a major challenge. It is extremely difficultdetermining the best set of relays because of the dynamic nature of theInternet. Additionally, this approach is vulnerable to attacks because an at-tacker can easily modify the set of predetermined relays by spreading falsestatistics. Using random selection reduces the computation overhead forrelay selection since we are not concerned with the optimal placement. Fur-ther, this strategy is less vulnerable to malicious attacks since the attackernever knows the exact location of the relays. However, it assumes that everynode understands how to relay path reports and can itself be a relay. Thisassumption is a considerable strong assumption. Functioning as a relayrequires additional resources that some nodes may simply not have. Inaddition, as a commercial strategy there is not much incentive to being arelay other than good citizenship. Thus a hybrid approach based on a localdetermination of a set of relay nodes by an iTrace generator followed by arandom selection as required, seems to a be better strategy. The only way todecide is to test each strategy with real data. We are currently investigatingthis approach. Results will be disseminated to the community as and whenavailable.

    Discussion and Conclusion

    In this paper, we present an approach for monitoring, gathering andvalidating the route information to a destination. Our technique enables eachAS to determine if an advertised route to itself is a valid one. The techniqueworks briefly as follows. Suppose AS1 has incorrect path information for des-tination AS2. This can be owing to one ofseveral causes like maliciousadvertisement of wrong path information by a neighboring AS of AS1, ormis-configuration at AS1 and so on. With our approach, AS2 will know within ashort amount of time that AS1 has incorrect path information about AS2. Inaddition, AS2 has the potential to know what other Autonomous Systems haveinvalid path information about itself. If AS1 (or the other Autonomous Systems)

    60 Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhis reachable from AS2, then AS2 can alert these ASes about the incorrectinformation (via some protocol which is, however, outside the scope of thecurrent work).

    The suggested approach is an integration of several existing partialsolutions that have been proposed in previous works. While none of themprovides a perfect solution for secure, reliable, robust, and fault-tolerant BGPprotocol, the combination of them may provide a more effective, efficient andconcrete solution. We propose using a separate process or server withrouters to make BGP protocol more secure and reliable. The proposedapproach verifies the UPDATE messages with well-defined filtering tech-niques and filtering rules, similar to that suggested by Wang et al. (Wang2003). However, filtering itself does not guarantee the complete correctnessof each path information, which is received by neighbors. To provide efficientpath validation mechanisms, we use ICMP traceback (iTrace) message withsome minor modification. Our suggested iTrace message has importantBGP information, such as Source AS, link connectivity information, and AS-PATH information to probe the validity of the paths. The important differencebetween our approach and other path validation approaches is it uses realdata traffic to validate the correct path. Path and origin verification work in afully distributed manner in our approach and guarantees good availabilityand scalability. We minimize real-time use of conventional public key crypto-graphic techniques; there is no need to contact an on-line trusted certifyingauthority for signature verification. Our solution truly depends on the distrib-uted nature of the Internet to spread the correct information and to corrobo-rate them. It utilizes the Internet topology to detect impersonated routes andinvalid paths.

    At this stage, we are in the process of evaluating our approach. Whilea network simulator can be used to simulate an interdomainrouting protocol like BGP, it is extremely difficult to simulate modelparameters like the scale and complexity of the Internet, errors inconfiguration and operation and requirements of incremental deployment.Thus for any evaluative study to be meaningful in the context of BGP securityreal world data from ASes are required. A major hurdle in the process is thatof obtaining such data

    Our approach has several limitations that need to be explored further.First, the protocol works when the iTrace messages containing the pathreports are properly delivered to the destination. Thus it depends on a goodnumber of relays to cover enough portions of the Internet. The approach forplacing relays depends on the tier relationships among nodes and there aresome corner cases in which our system may fail to detect false origins. Weobserve that more relays detect more such corner cases; however, thisincurs significant overhead. In addition, our approach relies considerably onhow efficiently relays work. Since the incentive to be a relay is not clearlyidentified as yet, we cannot claim with conviction that our approach will be

    61Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhwidely adopted. We need to develop models in which ASes will have theincentive to function as a relay.

    Second, in our approach each destination has the responsibility andright to monitor and detect the paths from any data source that actually senddata traffic. However, this may not be very convenient for very smalldestination ASes that have very limited resources. Although selective, on-demand monitoring and validation may reduce this overhead, we believe thatsmaller destinations have as much need for our protocol as larger ASes, ifnot more. Smaller ASes have less stable path than more popular / largerASes (Rexford et al. 2002). Thus they are more vulnerable to misbehaviorsand selective monitoring and validation may fail to detect many more.

    Third, we have proposed accumulating path reports forvalidation purposes. Accumulated path reports cause delayedvalidation since some nodes on the path cannot immediately report theirpaths and the destination needs to wait until those reports are available.However, this may be exploited by an attacker to launch a denial of serviceattack. Each path report that is sent to a destination causes some bufferspace to be allocated and held until the entire path is reconstructed. If anattacker sends many path reports without complete information to rebuild apath, it will exhaust available memory at the destination resulting in denial ofservice. Note however, an appropriate timer value will alleviate the problemconsiderably. Selective validation of paths may also help.

    Finally, transient routing dynamics may incorrectly trigger false pathreports. For example, a node may withdraw a link and thus a path that usesthis withdrawn link becomes a false path. Owing to update propagation de-lays and routing convergence delays, it may take some time before all rout-ers learn that the link is no longer available. However, the transition period isusually very short and the problem is resolved after the path has stabilized.Moreover, if an unstable route generates a lot of false path reports it mayactually be better for the destination to detect and record these chronicallyunstable routes. This is because the destination can then request the rel-evant ASes to fix this problem source link.

    We view our approach as a proper security mechanism withoutoperational degradation of BGP protocol. We are currently trying to validateour approach using real data from ASes. Results from this study will bedisseminated as and when they are available to us. We hope our workprovides some improvement for BGP routing protocol with incrementaldeployability and scalability to adapt well to the real world.

    62 Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhReferences

    Barrett, R., Haar, S. and Whitestone, R. (1997). Routing Snafu CausesInternet Outage. Interactive Week. April 1997.

    Bates, T., Smith, P. and Huston, G. (2006). CIDR Report StatusSummary for 14 September 2006, URL: http://www.cidr-report.org, 14September 2006.

    Bellovin, S. M. et al. (2001). Slowing Routing Table Growth by FilteringBased on Address Allocation Policies, URL: http://www.research.att.com/jrex/, June 2001.

    Bellovin, S. M. (2000). ICMP Traceback Messages, IETF NetworkWorking Group Internet Draft, March 2000.

    Braun, H. W. (1989). The NSFNET Routing Architecture, IETF NetworkWorking Group Request for Comments RFC 1093, February 1989.

    Foster, I. and Kessekman, K. (1997). "Globus: A MetacomputingInfrastructure Toolkit," Journal of Supercomputing Application 11(2): 115-128.

    Goodell, G., et al. (2003). "Working around BGP: An IncrementalApproach to Improving Security and Accuracy of Interdomain Routing".Proceedings of the 10th ISOC Annual Symposium on Network and DistributedSystems Security, February 2000, San Diego, California.

    Grimshaw, A. et al. (1997). "The Legion Vision of a Worldwide VirtualComputer," Communications of the ACM 40(1): 39-45.

    Hawkinson, J. and Bates, T. (1996). Guidelines for Creation, Selectionand Registration of an Autonomous System (AS), IETF Network WorkingGroup Request for Comments RFC 1930, March 1996.

    Hu, Y. C., Perrig, A. and Sirbu, M. (2004). "SPV: Secure Path VectorRouting for Secure BGP". Proceedings of the 2004 ACM SIGCOMM Conferenceon Applications, Technologies, Architectures and Protocols for ComputerCommunications, August-September 2004, Portland, Oregon.

    Kent, S., Lynn, C. and Seo, K. (2000). "Secure Border Gateway Protocol(S-BGP)," IEEE Journal on Selected Areas in Communications, Special Issueon Network Security 18(4): 582-592.

    Lee, H. C. J. et al. (2003). "ICMP Traceback with Cumulative Path: AnEfficient Solution for IP Traceback". Proceedings of the 5th InternationalConference on Information and Communications Security, October 2003,Huhehaote City, Inner Mongolia.

    Lowekamp, B. et al. (1998). "A Resource Query Interface for Network-Aware Applications". Proceedings of the 7th IEEE Symposium on High-Performance Distributed Computing, July 1998, Chicago, Illinois.

    Mahajan, R., Wetherall, D. and Anderson, T. (2002). "UnderstandingBGP Misconfiguration". Proceedings of the 2002 ACM SIGCOMM Conferenceon Applications, Technologies, Architectures and Protocols for ComputerCommunications, August 2002, Pittsburgh, Pennsylvania.

    Mankin, A. et al. (2001). "On Design and Evaluation of Intention-DrivenICMP Traceback". Proceedings of the 10th IEEE International Conference onComputer Communications and Networks (ICCCN), October 2001,Scottsdale, Arizona.

    63Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhMurphy, S. (2006). BGP Security Vulnerabilities Analysis, IETF Network

    Working Group Request for Comments RFC 4272, January 2006 .Ng, J. (2002). Extensions to BGP to Support Secure Origin BGP, IETF

    Network Working Group Internet Draft, October 2002.Nordstrom, O. and Dovrolis, C. (2004). "Beware of BGP attacks," ACM

    SIGCOMM Computer Communications Review 34(2): 1-8.Padmanabhan, V. N. and Simon, D. R. (2003). "Secure Traceroute to

    Detect Faulty or Malicious Routing," ACM SIGCOMM ComputerCommunication Review 33(1): 77-82.

    Pei, D., Massey, D. and Zhang, L. (2004). "A Framework for ResilientInternet Routing Protocol," IEEE Network 18(2): 5-12.

    Pei, D., Massey, D. and Zhang, L. (2003). "Detection of Invalid RoutingAnnouncements in the RIP Protocol". Proceedings of the 2003 IEEE GlobalCommunication Conference (Globecom), December 2003, St. Louis,Missouri.

    Perlman, R. (1988). "Network Layer Protocols with ByzantineRobustness". Massachusetts Institute of Technology, Boston, Massachusetts,Unpublished Ph.D. Dissertation.

    Rabin, M. (1989). "Efficient Dispersal of Information for Security, LoadBalancing and Fault Tolerance," Journal of the ACM 36(2): 335--348.

    Rekhter, Y. and Li, T. (1995). Border Gateway Protocol 4, IETF NetworkWorking Group Request for Comments RFC 1771, March 1995.

    Rexford, J. et al. (2002). "BGP Routing Stability of Popular Destinations".Proceedings of the 2nd ACM SIGCOMM Internet Measurement Workshop,November 2002, Marseille, France.

    Shamir, A. (1984). "Identity-Based Cryptosystems and SignatureSchemes". Proceedings of CRYPTO 84 on Advances in Cryptology, August1984, Santa Barbara, CA. Lecture Notes in Computer Science 491, Springer-Verlag.

    Stewart, J. (1999). BGP4: Inter-Domain Routing in the Internet. Addison-Wesley, Reading, Massachusetts.

    Subhlok, J. et al. (1999). "Automatic Node Selection for HighPerformance Applications on Networks". Proceedings of the 7th ACM SIGPLANSymposium on Principles and Practice of Parallel Programming, May 1998,Atlanta, Georgia.

    Traina, P. (1995). BGP-4: Protocol Analysis, IETF Network WorkingGroup Request for Comments RFC 1774, March 1995.

    Wang, L. et al. (2003). "Protecting BGP Routes to Top Level DNSServer," IEEE Transactions on Parallel and Distributed Systems 14(9): 851-860.

    Zhao, X. et al. (2001). "An Analysis of BGP Multiple Origin AS (MOAS)Conflicts". Proceedings of the 1st ACM SIGCOMM Workshop on InternetMeasurement, November 2001, San Francisco, California.

    Zhao, X. et al. (2002). "Detection of Invalid Routing Announcements inthe Internet". Proceedings of International Conference on DependableSystems and Networks (DSN 2002), June 2002, Bethesda, Maryland.

    64 Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec

  • adfhAuthor Biographies

    Dr. Indrajit Ray is an Associate Professor in the Computer ScienceDepartment at Colorado State University. He received his doctorate fromGeorge Mason University. Dr. Ray's main research interests are in the areasof security models, database and network security and computer forensics.He is the current chair of the IFIP TC-11 Working Group 11.9 on Digital Foren-sics. He is on the editorial board of the Digital Investigation Journal. He hasalso served on the program committees of a number of national and interna-tional conferences. Dr. Ray is a member of the IEEE, IEEE Computer Society,ACM, ACM Special Interest Group on Security, Audit and Control, IFIP WG 11.3on Data and Applications Security and IFIP WG 11.9 on Digital Forensics.

    Eunjong Kim is a graduate student in the Computer Science Depart-ment at Colorado State University. Her research interests are in computersecurity, forensics and computer networks.

    Dr. Dan Massey is an Assistant Professor at Computer ScienceDepartment of Colorado State University. Dr. Massey received his doctoratefrom UCLA, He is a senior member of the IEEE, IEEE CommunicationsSociety, and IEEE Computer Society. His research interests include protocoldesign and security for large-scale network infrastructures and he is cur-rently the principal investigator on research projects investigating techniquesfor improving the Internet's naming and routing infrastructures.

    65Indrajit Ray, Eunjong Kim, Daniel Massey , JISSec