BGP Information Encapsulated
in sFlow Packets
Gregory Blanc1,2, Hiroaki Hazeyama2, and Youki Kadobayashi2 1 ´
Ecole Sup´erieure d’Informatique ´Electronique Automatique
72 avenue Maurice Thorez 94200 Ivry-sur-Seine, FRANCE {[email protected]}
2
Internet Engineering Laboratory Graduate School of Information Science Nara Institute of Science and Technology 8916-5 Takayama, Ikoma, Nara 630-0192, JAPAN
{gregory,hiroa-ha,youki-k}@is.naist.jp
Abstract. DDoS attacks have created a need for components that not only filter out these malicious flows but also track these flows back to their source, even if spoofed. To track back over inter-domain, an Au-tonomous System (AS) has to determine the actual upstream ASes about the targeted flow. Usually, inferring the upstream AS of a flow requires collecting large amount of packets, classifying packets to unique flows and analyzing the upstream ASes of each flow. This method consumes too much storage and wastes much time. To reduce such costs, we propose a new method for inferring flow direction using flow sampling techniques. Through several experiments and improvements, we finally developed a Flow Direction Inferring (FDI) algorithm and an FDI system which al-lows an AS to determine the upstream AS and / or downstream AS of a single packet exported by sFlow on a Border Router (BR), without classifying packets to a flow.
Key words: flow direction inferring, BGP, flow monitoring technology, sFlow, autonomous system, border router, IP traceback
1
Introduction
Malicious flows, especially Distributed Denial of Services (DDoS), constitute serious threats to the Internet. Beyond the damage caused to targeted hosts, the links and Autonomous Systems (ASes) within the attack path may suffer also from congestion and eventually may be unable to provide routing services. In face of the increasing number of malicious flows, many solutions have been developed, such as Intrusion Detection Systems, Intrusion Protection Systems, Firewalls, etc. However, these filtering techniques, though they may help mitigate malicious flows, may also reduce the quality of service if the filters are set too close to the victim site, i.e. far from the attacker nodes. Also, the spoofing property of
DDoS may confuse filtering appliances. Tracing the malicious flows back to their source will then enable setting filters closer to the attacker nodes. Tracking flow is usually a tedious work since it needs to collect a large amount of packets, to classify packets to unique flows and to analyze which neighbor is upsteam. Flow sampling techniques, the so-called xFlows, such as NetFlow or sFlow, are expected not only to infer the direction of a flow but also to reduce such cost of traceback. However, according to our preliminary experiments, merely collecting xFlow packets will not retrieve flow directions.
To infer the direction of each packet, we developed a Flow Direction Inferring (FDI) algorithm. In this paper, we explain the concept of flow direction, why we chose BGP and sFlow to report on flow information, how we implemented the algorithm in the Flow Direction Inferring System (FDIS) based on BGP information provided by sFlow implementation on Alaxala 3630 routers. Finally, we describe the experiments and the results of implementing the algorithm and the FDIS at different stages of its development.
2
Preliminary Experiment on Flow Monitoring
Techniques
2.1 Basic Concept of Flow Direction Inferring
Basically, we consider 3 types of flows: an AS could be the origin of a flow, in which case the flow will be outgoing to a downstream AS, leaving the current AS by a border router; an AS could be the destination of a flow, the flow will be incoming from an upstream AS, entering the current AS by a border router; an AS could be a transit AS for a flow, in which case the flow will be incoming from an upstream AS, entering the current AS by one Border Router (BR), and normally leaving the current AS by another BR to a downstream AS. Flow direction from a BR’s point of view is then the following: a flow isincomingwhen it enters the AS going from the BR to another router or hostinside the current AS; a flow isoutgoingwhen it leaves the AS going from the BR to another router or hostoutside the current AS.
2.2 Basic Requirements for A Flow Direction Inferring System
An FDI system must comply with a list of requirements. Based on the basic concepts of FDI, the BR is clearly the central component. Therefore, the BR should provide information on the direction of a flow. From the concepts of
incoming andoutgoing flows, respectively we can deduce that the flow direction is characterized by the fact that the flow is crossing a BR to remain in the same AS or to enter another AS. That is, anoutgoing flow will induce a change of AS number (ASN) in the AS path while anincoming flow will not. So, first of all, a flow direction inferring system (FDIS) must obtain such information as the AS of the BR and the AS of the next-hop on the AS path, both characterized by an ASN. Second, as the BR is the key component, a FDIS may be implemented,
Table 1.Comparison of network flow information techniques Protos L. 2 L. 3 BGP 4 P ac k e t C ap t u r e In t e r fac e C o u n t e r s P a ck et h ea d er s E th ern et / 8 0 2 .3 IP / IC M P / U D P / T C P I/ O in te rf a ce I/ O p ri o ri ty I/ O V LA N S o u rc e su b n et / p re fi x D es ti n a ti o n su b n et / p re fi x N ex t h o p A g en t A S S o u rc e A S S o u rc e P ee r A S D es ti n a ti o n A S D es ti n a ti o n P ee r A S NetFlowR N N N N Y Y N N N N N P P P P P sFlowR P Y Y Y Y P P P Y Y Y Y Y Y Y Y
entirely or partly, on the BR, or at least, the FDIS may obtain information directly from the BR, to be processed.
2.3 Survey on Flow Monitoring Techniques
In the previous section, we deduced the requirements for our FDIS. Actually, such required attributes as ASNs are used in BGP protocol. The FDIS may then retrieve BGP protocol information from the BR. To retrieve BGP infor-mation, techniques such as flow monitoring techniques (xFlows) can be used. In the manner of SNMP or RMON, xFlows are widely used to monitor flows running through networks, especially high-speed networks. xFlows are imple-mented in routers, whether embedded in the hardware or coded as software. Two techniques are mainly used in this domain : Cisco’s NetFlow [4] and In-Mon’s sFlow [11]. In this survey, we investigate the capability of both xFlows to recover BGP information. To confirm the actual capability of xFlow to recover BGP information, we made preliminary experiments using nProbe, a light probe exporting NetFlow packets [5], and sFlow implementation on Alaxala 3630.
According to the results summarized in Table 1, nProbe did not provide the header of collected packets/flows, while sFlow did, when configured with the extended header packet information. Actually, NetFlow can provide information of the header if it is specified in the template. Layer 2 information was partially recovered by sFlow while NetFlow was only providing network interface SNMP indexes. Regarding next-hop information which is required for the algorithm, it can not be retrieved directly. However nProbe was not able to provide such information even if the next-hop IP address option was specified in the template, while the extended router information option allowed sFlow to export the next-hop IP address to the collector. As for BGP information, sFlow clearly recovered it thanks to the extended gateway information option, while nProbe was hardly able to provide ASNs of the source and destination, even if we provided nProbe
Fig. 1.Overview of The Flow Direction Inferring System
with a text file containing IP addresses of the hosts and their corresponding ASes. Some packets were even displaying only one ASN or the other.
Actually both technologies are implemented on the routers, which was one of our requirements for the FDIS. However in our survey, we were only using GNU-zebra routers for NetFlow, which led to the choice of nProbe as the exporting probe. nProbe, not being installed on routers directly, had to be provided with the AS information directly, which can be a tedious task when you have hundreds of ASes. Moreover, NetFlow packets showed really poor information compared to sFlow and compared to what we had expected. The survey was also biased by the fact that we used sFlow-embedded Alaxala routers for surveying sFlow, and GNU-zebra [8] in a testbed of Sun stations for NetFlow. According to the results, and given the hardware available, we chose Alaxala’s sFlow implementation over nProbe for implementing the FDIS.
3
Flow Direction Inferring System
3.1 Overview of Flow Direction Inferring System
In our research, we designed a system to infer flow direction. From the concepts defined in the previous sections, FDI can be achieved using ASNs, which are provided by BGP protocol. In section 2.3, we conclude the preliminary survey by choosing sFlow as the BGP information exporter for the FDIS. Therefore, in our system (Fig. 1) BRs run sFlow to export BGP information about the flows crossing the ASes. sFlow packets are gathered by a remote collector which should be running a collecting software. We chose sflowtool [7] as a flow collector. sflowtool is a free sFlow collector that simply gathers sFlow packets and can be customized in order to implement the FDI algorithm. Eventually, the processed data will be stored in a MySQL database. Basically, experiments were conducted using a testbed of sFlow-exporting Alaxala 3630S-24T2X routers in restricted topologies. Exported packets were collected by a unique Debian collector (Linux kernel 2.6). The collector was sflowtool version 3.10 written in C, which we modified to implement the FDI algorithm as well as to export packet information and the inferred direction to a MySQL version 5.0.32 database located on the same host. The shell script to parse router configuration files was written in Bourne Shell script language.
3.2 Flow Information to Retrieve The Flow Direction
As shown in the system overview, BRs are responsible for exporting information about crossing flows using sFlow technology. In the survey above (section 2.3), we learned that sFlow was able to provide extended information, for example BGP information such as ASNs and the next-hop IP address. Yet we know that, from a BR’s point of view, a necessary hint on a flow direction is firstly this BR AS, characterized by an ASN, but still not sufficient. Also, the next-hop router from the agent BR (currently, the sFlow exporting BR at time t) is inside the agent BR AS when the monitored flow is incoming, and outside the agent BR AS when the monitored flow is outgoing. Thus, to infer a flow direction, we have to know both the agent BR AS (or agent AS, currently the AS of the agent BR at time t) and the next-hop AS. Actually, sFlow already provides the agent ASN and next-hop IP address. These two should be the key attributes we must focus on to infer the direction of a flow.
3.3 Simple Direction Inferring
Based on findings in the above sections, we designed an FDI algorithm and then confronted it with to a routing topology. In section 3.2, we defined the key attributes of flow direction inferring as the agent BR ASN (also referred to as current ASN) provided by sFlow, and the next-hop ASN. Simply put, from the agent BR’s point of view, if the hop is outside its own AS, i.e. if the next-hop ASN is different from the current ASN, then the monitored flow is leaving
the AS. On the other hand, if the next-hop is inside the AS, i.e. if the next-hop ASN and the current ASN are equal, then the flow may be entering the AS through the agent BR towards the next-hop router. We can sum up the above reasoning with a few lines of the following algorithm:
First algorithm proposed to infer on flow directions
if current_as == next_hop_as then flow_direction := incoming else flow_direction := outgoing
Intuitively, we could have thought of comparing agent ASN with the desti-nation peer ASN (instead of the next-hop ASN), but this does not always work. For example, if the flow is incoming through the agent BR and leaving through the next-hop, then the next-hop ASN would be equal to the agent ASN, while the source peer ASN would not.
For the first experiment, the following assumptions were made:
– FDI can know only the current ASN and the next-hop ASN;
– As sFlow only provides the next-hop IP address, the collector can retrieve the next-hop ASN.
The experiment was performed on the topology described in Figure 3. Details of the topology are the following :
Table 2.Samples of the first experiment
case type agent IP src IP src peer dest IP dest peer next-hop IP direction
ASN ASN ASN ASN ASN ASN
1 normal 192.168.255.222 10.3.2.7 10.1.3.3 10.1.3.3 incoming 65001 65003 65002 0 0 65001 2 normal 192.168.255.225 10.3.3.9 10.1.3.3 10.1.255.2 outgoing 65002 65003 65004 65001 65001 65001 3 malformed 192.168.255.224 10.2.255.10 10.2.2.5 10.2.3.6 incoming full 65002 0 0 0 0 65002 4 malformed 192.168.255.231 10.2.3.6 10.4.255.8 10.4.255.8 outgoing half 65004 65002 65002 0 0 65004 5 unknown 192.168.255.231 10.4.3.12 10.1.255.2 10.4.4.10 incoming 65004 0 0 65001 65002 65004
– All networks were assigned a Class C network address;
– AX02 as 10.1.3.2 shared VLAN 1020 with AX03 as 10.1.3.3;
– AX02 as 10.2.2.5 shared VLAN 1050/2040 with AX05 as 10.1.255.5;
– AX05 as 10.2.2.5 shared VLAN 2010 with AX06 as 10.2.2.6;
– AX05 as 10.2.4.5 shared VLAN 2030 with AX04 as 10.2.4.4;
– AX06 as 10.2.3.6 shared VLAN 2010 with AX04 as 10.2.3.4;
– AX04 as 10.2.255.4 shared VLAN 2050/4040 with AX10 as 10.2.255.10;
– AX10 as 10.4.2.10 shared VLAN 4010 with AX12 as 10.4.2.12;
– AX10 as 10.4.4.10 shared VLAN 4030 with AX11 as 10.4.4.11;
– AX12 as 10.4.3.12 shared VLAN 4020 with AX11 as 10.4.3.11;
– AX11 as 10.4.255.11 shared VLAN 4050/3050 with AX08 as 10.4.255.8;
– AX08 as 10.3.3.8 shared VLAN 3020 with AX09 as 10.3.3.9;
– AX08 as 10.3.4.8 shared VLAN 3030 with AX07 as 10.3.4.7;
– AX07 as 10.3.2.7 shared VLAN 3010 with AX09 as 10.3.2.9.
Each BR was exporting sFlow packets to a remote sflowtool-running collector. As sflowtool does nothing more than collecting sFlow packets, a function was added to sflowtool to store collected packets into a MySQL database. Following the assumptions we made, the unique collector will determine the AS of any next-hop IP address that the collector processes. We therefore designed another function in sflowtool to resolve ASNs using a text file containing IP addresses and their corresponding ASN. Test flows were ICMP echoes generated between routers of different ASes. On a first trial, the collector gathered 29 packets which were inferred correctly by the collector. However, for 8 packets, ASNs were not recovered properly. On a second trial, the collector gathered 19 packets, the direction of 18 of which was correctly inferred; 1 was erroneous. Among the 18 correct inferences, 5 packets had malformed ASNs, similar to the previous trial. Table 2 shows a sample of packets in this experiment. There was no difficulty in inferring the direction of flows described by well-constructed packets.3
3
In Table 2, a value of 0 for an ASN corresponds to an ASN equal to agent BR ASN, complying with sFlow notation. However, next-hop ASN does not comply to this rule as it is an output of the collector’s processing.
On the first trial, though inferences were correct for all packets gathered, mal-formed packets were observed. Their ASNs were not recovered properly. Though the origin of the error might be the same for all of the malformed packets, we divided them into: case 4 in Table 2, i.e. packets that were neither originated by the agent AS nor directed to the agent AS (thus, source and destination ASNs are different from agent ASN). The source or the destination ASN was provided with the value0 by sFlow, indicating, respectively, the source AS or the destina-tion AS, as the agent AS. Actually, this is wrong; case 3 in Table 2, i.e. packets that either originated from agent AS or are directed to the agent AS. Therefore, the source ASN or the destination ASN, should be respectively filled with 0. In fact, however, both source and destination ASNs are filled with the value0. Although, packets were malformed because ASNs (source and/or destination) were not properly recovered, the FDI algorithm was correct each time. This is due to the fact that inferring is done using the next-hop ASN, which is indeed outputted from the collector that has previously processed a properly recovered next-hop IP address.
Concerning malformed packets, we can notice that they are likely to be mal-formed when the source or the destination of the monitored flow is, respectively, a BR and the agent BR is the next-hop or the previous-hop on the AS path. Actually, this is documented in the Alaxala 3600 series router configuration man-ual [9]. The section about sFlow packet format provides among other things, a table of the extended gateway data type format. Concerning the source, source peer, destination and destination peer ASes, a note specifies that in the case the source AS BR or the destination AS BR is linked directly to the agent AS BR using a shared VLAN, an OSPF or iBGP route, then the source AS BR or the destination AS BR, respectively, will be reported as0 by sFlow packets. On the second trial, apart from the positive results and the malformed packets, one collected packet turned down the FDI. Table 2 case 5 shows the incriminated record. Yet the BGP information was properly recovered. To understand what happened, we drew Figure 2 based on Table 2 case 5. The present FDI algorithm only compares next-hop AS with agent AS. Thus, in this example, the next-hop router (AX10) being in the same AS as the agent router (AX11), the algorithm infers flow direction asincoming. However, AX12 being the source of this flow, the direction must have been outgoing. Therefore, we should have interpreted this case differently (see Section 3.4). To a certain extent, the FDI algorithm was able to infer correctly the collected packets, even when information such as source or destination ASNs was not neatly provided. Nevertheless, in further work, the algorithm will be complexified in order to consider new cases, such as the one encountered in the experiment. As for the malformed packets, a note in the manufacturer manual makes correction nearly impossible. Therefore, we will ignore the issue in future experiments.
3.4 Automating Side Tasks for The FDI Algorithm
The previous algorithm was not able to detect flow originated by the agent AS and outgoing the AS indirectly, via another BR. That is, the agent AS was also
AX10 AX11 AX12 VLAN 4010 OSPF VLAN 4030 iBGP VLAN 4020 OSPF to VLAN 4010 OSPF to VLAN 4050 eBGP source router agent router next-hop router
Fig. 2.A forgotten case in the algorithm
the source AS, i.e. their ASNs were equal. To deal with such case, the second algorithm compares the source ASN with the agent ASN to distinguish whether the agent AS originated the flow or not. This must be done, of course, before run-ning the previous algorithm. Also we have to take into account flows directed to the agent AS. Such flows are characterized by a destination ASN equal to the agent ASN. FDI merely runs the first algorithm when the agent AS is the source AS or the destination AS. According to the first experiment, FDI usu-ally requires additional processing to recover the next-hop ASN. Therefore, the second algorithm can be described as follows:Improved flow direction inferring algorithm
# 0 refers to a value equal to agent ASN # are the agent AS and the source AS the same? if source_as == 0 and destination_as != 0 then flow_direction := outgoing
# are the agent AS and the destination AS the same? else if source_as != 0 and destination_as == 0 then flow_direction := incoming
# the agent AS is neither the source AS nor the destination AS else if next-hop_as == 0
then direction := incoming else direction := outgoing
As said above, the algorithm first tests whether the agent AS is the source or the destination AS of the targeted flow, to avoid further processing in those cases. Therefore, if the agent AS happens to be the source AS then the flow is obviously outgoing from the agent AS. On the other hand, the agent AS being the destination AS would mean that the flow is actually incoming to the agent AS. In the case that the agent AS is neither the source AS nor the destination one, then, looking at the next-hop AS will help infer the direction of the flow. Indeed, if the next-hop AS is the agent AS (the flow is going from the agent AS BR to an internal hop), then the flow is incoming to the AS. On the contrary, a next-hop AS different from the agent AS (the flow is going from the agent AS BR to an external node) characterizes an outgoing flow.
AX03 AX02 AX05 AX06 AX04 AX11 AX12 AX10 AS 65001 AS 65002 AS 65004 AX07 AX09 AX08 AS 65003
Fig. 3. Four ASes are exchanging BGP and OSPF information.
In this experiment, the following assumptions were made:
– Malformed packets should be ignored;
– Next-hop AS will be recovered after the collector has processed gathered packets, allowing the collector to automatically associate a next-hop IP ad-dress to its AS.
As for the topology, we were still using that described in Figure 3. Different from the previous experiment was, besides the algorithm, the way we recovered the next-hop ASN. Formerly, sFlow provided the next-hop IP address and matched it with a static list containing all IP addresses of the topology and their corre-sponding network. The task done this way was tedious. We then used jointly two
tools to recover the ASN of the next-hop: in sflowtool, a new routine was written to infer the ASN of the next-hop. Provided by sFlow, the next-hop IP, sFlow agent IP and agent ASN were processed by a routine that returns the next-hop ASN. This routine then matched the next-hop IP with a file containing neighbors or local networks of agent AS as well as ASNs (0 for local networks, to comply to sFlow notation).Content of the file used in next-hop AS recovery
<IP address of neighbor/network> <mask> <ASN>
This file was created by the second tool used in this experiment. In fact, such information as next-hop ASNs are available on routers. A collector, in order to be aware of this information, may backup every border router configuration file. But configuration files are heavy to read for a quick processing. Therefore a shell script was written to read a batch of configuration files and then output a file designed in the above fashion. The sflowtool’s custom routine would then compare the next-hop IP address with the listed IP addresses of BGP neighbors or would check if the next-hop IP address is in the range of local networks of the listed IP addresses, then would return the associated ASN.
Table 3 gives a sample of inferences by the new algorithm. The collector gathered 43 sFlow packets, among which 13 were malformed packets. Among these 13 malformed packets, the new algorithm happened to infer wrong on 5 records. Among the correctly inferred records, one appeared to be of the case 5 in Table2 (illustrated by Figure 2). Thanks to our improvements on the new algorithm, this case was then correctly inferred as an outgoing flow as shown in Table 3 (case 1).4
Though malformed packets used to be inferred correctly 4
Table 3.Samples of the second experiment
case type agent IP src IP src peer dest IP dest peer next-hop IP direction
ASN ASN ASN ASN ASN ASN
1 new 192.168.255.231 10.4.3.12 10.1.255.2 10.4.4.10 outgoing case 65004 0 0 65001 65002 0 2 malformed 192.168.255.230 10.2.3.6 10.4.255.8 10.4.4.11 incoming correct 65004 65002 65002 0 0 0 3 malformed 192.168.255.225 10.1.255.2 10.4.3.12 10.2.4.4 outgoing wrong 65002 0 0 65004 65004 0
by our algorithm, some records were inferred wrongly in this experiment. This only affected flows originated by, or directed to, the agent BR AS. These flows were added as new cases in the new algorithm, therefore it was obvious that such incidents would happen, since we ignore the malformed packets issue (Tab. 3 case 3). Previously, malformed packets were inferred using the calculated next-hop ASN in the first algorithm.
This experiment has validated the new algorithm, though it has brought to light new issues concerning malformed packets. Moreover, next-hop AS recovery is now completely automated.
3.5 Handling Transit Cases
Until now, we had experiments in the same network topology. Next, we discuss and revise the FDI algorithm with considering various network topologies. Basi-cally,transit direction, concerning routers, is a direction that no one can decide on. A transit direction from a router’s point of view is not only incoming or out-going. It is both, or neither. So far, two types of transit cases have been detected. A simple one is the following : from the BR’s point of view, the flow comes from an external AS and is immediately transferred to another AS, without reaching another router inside the current AS. Thus, one can not tell that the flow is incoming since it only reached the BR, and nor is it outgoing from the AS since it was never inside (in Fig. 4 (a), R1 is the current sFlow agent).
Another example, that is harder to detect, occurs when, on a same AS, a flow is going through several BRs or internal routers consecutively, before leaving the current AS. If between the ingress BR and the egress BR, the flow goes through another BR (present agent BR), then, from the agent BR’s point of view the monitored flow is seen as coming from an internal node (e.g., ingress BR), whether using iBGP or OSPF, to then be propagated to another internal node until it reaches the egress BR and leaves the AS. From the agent BR’s point of view, although the next-hop router has the same ASN, deciding that the flow is incoming could be wrong, since the flow was already incoming from a previous BR. On the other hand, the agent BR is also not the router the monitored flow is outgoing from. (in Figure 4 (b), R1 is the current sFlow agent).
As the above cases may lead to a wrong inference, the flow direction algorithm must take into account such unusual flow paths. Knowing the next-hop AS is
R1 R2 R3 AS 300 AS 100 AS 200 flow X is incoming flow X is outgoing (a) external R1 R2 R3 flow X is incoming flow X is outgoing AS 100 (b) internal
Fig. 4.Transit cases.
necessary but not sufficient. For example, in theexternal transit case, inferring on the next-hop AS number will lead the algorithm to tag the flow direction as outgoing, though the previous-hop was already from an external AS. Then, it becomes clear that, to avoid this misunderstanding, the collector must have some information about the previous-hop, from the agent BR’s point of view. A reliable hint concerning the previous-hop, in the information provided by sFlow packets, may be the incoming VLAN number not the peer source ASN, since that refers to the immediately previous peer AS (which may be different from the previous-hop AS). This VLAN refers to the link between the agent BR and its previous-hop router. Now, we can distinguish between two cases : one is that of the VLAN being shared between two ASes (previous-hop AS and agent AS), when in the external transit case, the flow direction is both incoming to the agent BR using this shared VLAN and outgoing to another AS from the agent BR; the other is that of the VLAN being internal to the AS, whether an iBGP or OSPF route, when in the internal transit case, the flow direction is neither incoming since the previous-hop is from the same AS, nor outgoing since the next-hop router is still in the agent AS. This reasoning was transcribed in the new FDI algorithm :
Flow direction inferring algorithm including transit cases
# is the agent AS equal to the source AS? if (source_as == 0 and destination_as != 0) then flow_direction := outgoing
# is the agent AS equal to the destination AS? else if (destination_as == 0 and source_as != 0) then direction := incoming
# the agent AS is neither the source nor the destination AS else if (next_hop_as == 0)
# the next-hop is internal but is the incoming VLAN shared? then if (vlan_in.isShared == 0)
# if yes, the flow is transiting through the agent BR then direction := transit
# if no, the flow is incoming else direction := incoming else if (vlan_in.isShared == 1) then direction := transit
else direction := outgoing
The shared characteristic of a VLAN is not provided directly by sFlow, as was the next-hop AS in the previous experiments. However, the incoming VLAN number is available information provided by sFlow. Therefore, the collector must process this information to obtain the shared characteristic of the incoming VLAN. In this experiment, the following assumptions are made:
– The collector can determine the shared characteristic of a VLAN directly connected to an agent BR;
– Malformed packets are ignored.
In this experiment, the following processing was developed: first, using what was already done concerning how the next-hop AS is determined, a shell script would look through the BR configuration file and list any link to the BR (networks, neighbors in OSPF, BGP or RIP); once this list has been built, only external peers would be short-listed; then as VLANs are targeted, a list is also built in the same fashion, in order to match the external peers short-list with existing VLANs; finally, a new file, with the shared VLANs written in it, is created for the collector to compare it to the incoming VLANs stored in the database. The transit cases being very specific, the current topology is not relevant for the purpose of an experiment. It has therefore been modified in order to integrate such paths as targeted by the transit cases. Figure 5 describes the new topology used in this experiment. Details of the topology are as follows:
– in AS 65001, VLAN 1020 links AX02 as 10.1.3.2, AX03 as 10.1.3.3, AX09 as 10.1.3.9 and AX04 as 10.1.3.4, 1030 links AX02 as 10.1.4.2 and AX04 as 10.1.4.4;
– between AS 65001 and AS 65002, VLAN 1050/2040 links AX02 as 10.1.255.2 and AX05 as 10.1.255.5;
– in AS 65002, VLAN 2010 links AX05 as 10.2.2.5, AX06 as 10.2.2.6 and AX07 as 10.2.2.7;
– between AS 65002 ans AS 65004, VLAN 2050/4040 links AX05 as 10.2.255.5 and AX10 as 10.2.255.10;
– in AS 65004, AX10 shares 4010 as 10.4.2.10 with AX12 as 10.4.2.12, 4090 as 10.4.10.10 with AX08 as 10.4.10.8, 4030 as 10.4.4.10 with AX11 as 10.4.4.11; AX11 shares 4020 as 10.4.3.11 with AX12 as 10.4.3.12 and 4080 as 10.4.9.11 with AX08 as 10.4.9.8;
AX08 shares 4060 as 10.4.7.8 with AX12 as 10.4.7.12;
– between AS 65004 and AS 65001, VLAN 4050/1040 links AX11 as 10.4.255.11 and AX04 as 10.4.255.4.
In this topology, AX05 was the target forexternal transit case, while on AX08, was expected to occur the internal one. Obviously, there were some obstacles in testing these cases as, for example, in the AS 65004, iBGP speakers were full meshed. This led to the flow denying the route through AX08 each time, favoring direct links between AX10 and AX11. In order to avoid such undesired
AX03 AX09 AX02 AX04 AX11 AX10 AX08 AX12 AX05 AX07 AX06 AS 65001 AS 65002 AS 65004
Fig. 5.New topology. This includes paths to simulate transit direction cases.
Table 4.Samples of the third experiment
case type agent IP VLAN src IP dest IP next-hop IP direction
ASN ASN ASN ASN
1 normal 192.168.255.228 4080 10.1.3.3 10.2.2.7 10.4.10.10 transit internal 65004 65001 65002 0 2 normal 192.168.255.225 2040 10.1.3.3 10.4.3.12 10.2.255.10 transit external 65002 65001 65004 65004 3 malformed 192.168.255.225 2040 10.1.3.9 10.2.255.10 10.2.255.10 incoming wrong 65002 65001 0 65004 4 normal 192.168.255.228 2040 10.1.3.9 10.2.255.10 10.2.255.10 incoming disputable 65004 65001 0 0
side-effects, we designed static routes to focus on the transit cases. Since the gen-erated flows consisted only in ICMP echo flows, going through the different ASes, the following routes were decided : from AX03 to AX07 (10.2.2.7), going through AX04, AX11, AX08, AX10 and AX05 and from AX03 to AX12 (10.4.2.12), go-ing through AX03, AX05, AX10, AX08 and AX11. These routes were likely to observe transit cases. To ensure that the above paths would be respected, the fol-lowing static routes were used : from AX03 to 10.2.2.0/24 through 10.1.3.4; from AX04 to 10.2.2.0/24 through 10.4.255.11; from AX11 to 10.2.2.0/24 through 10.4.9.8; from AX03 to 10.4.2.0/24 through 10.1.3.2; from AX02 to 10.4.2.0/24 through 10.1.255.5. In Table 4, results show that the algorithm has been able to detect transit cases. Of course, the collector still captures malformed packets. Moreover, as long as the destination and source IP addresses are not BR ones, inferring is done correctly. However in previous trials of this experiment, we have encountered errors (Table 4 case 3), especially in the external transit case, in which the ping previously targeted AX10 (BR) and not AX12, making AX10 look like an iBGP speaker from AX05’s point of view (not to forget that the next-hop AS in the record is calculated).
On the other hand, as far as the internal transit case is concerned, obviously, if the destination AS is different from AX08’s AS, then it is likely that AX08 is a transit point rather than an ingress one. But, on the contrary, if the next-hop router turns out to be among internal neighbors, then AX08 will be tagged as ingress point, which can be misleading in a traceback purpose. Table 4 case 4 shows such kind of flow.
Table 5.Comparison of traceback techniques
approach key technique object classification filters applied sync
among agents
Link Testing link-testing burst flow Needed Needed Yes
RTBH filtering BCP 38 burst flow,
fil-tered packet
Needed Needed Yes
Pushback pushback burst flow Needed Not needed Yes
Packet Marking PPM burst flow Not needed Not needed No
Trajectory Sampling hash-digest flow Not needed Not needed Yes
xFlow flow monitoring burst flow Not needed Not needed Yes
xFlow + FDIS FDIS packet Not needed Not needed No
SPIE hash-digest packet Not needed Not needed No
The flow direction algorithm can now deal with the large amount of flows that can occur in a network’s lifetime. Throughout this survey, we avoided confronting malformed packets, even if they were correctly inferred in most cases. Actually, these cases depict flows directed to the BRs, which, if not compulsory protocol flows, might be of a malicious nature. This will be investigated in future work.
4
Related Work
IP traceback is a name given to any method for reliably determining the ori-gin of a packet on the Internet [1]. In Table 5, we compare different traceback technologies with our FDIS. A weakness found in most of the existing traceback technologies is the burst flow detection filters, i.e. these technologies tend to gather enough packets before issuing a traceback request whether because they tolerate DoS-like flows to a certain threshold as in the link-testing method [6], the Remote Triggered BlackHole (RTBH) filtering method [3] or the pushback method [12]. Worse than that, the link-testing method may modify the filter rules to test links and thus may occasion congestion or loss of the quality of service. On the contrary, once a packet has been sampled by a BR and is still present in the database of the FDI system, any request of a traceback system will be able to recover it. Other traceback technologies will also need to synchronize ASes to proceed with a traceback request as it is the case for Packet Marking [13], the SPIE [2] or Trajectory Sampling (TS) [10] based techniques. On the other hand, the FDI in itself is an innovation since it will allow traceback systems not to rely on other ASes. In fact, given the direction of a targeted flow, there is then no need to wait for other ASes to send their information as the traceback request can be brought on directly to the AS(es) designated as upstream by the FDI algorithm. These ASes can even have informations about the direction of the targeted flow already written in their own FDI system database. Not to forget, that the FDI system uses xFlows which makes it a low-cost technology in terms of CPU and storage consumptions, and also reduces the used bandwith which is
not the case for the packet-marking method [13] packets which carries an over-head. Therefore, using FDI based system, traceback can be triggered with only one packet collected.
5
Conclusion
In this article, we designed both an algorithm and a system to infer the direction of a packet by sFlow. The main contribution is the algorithm itself, which has been improved throughout this research. Finally, our FDI algorithm can retrieve the direction of every sampled packet by sFlow without gathering and classifying several sampled packets as a flow, except for a few cases. Besides the sampling feature, processing on flow inferring of FDIS does not require much information, thus, our FDIS will ease the CPU overhead and / or reduce the required storage size for tracking packet or flow in the long past.
In future work, we will try to implement FDI algorithm using sFlow with other manufacturers devices to clarify the issue of malformed packets. We will also implement the FDIS using other flow monitoring techniques such as NetFlow or IPFIX. Obviously, we will use NetFlow-supporting routers and sflowtool may therefore be substituted by a NetFlow collector. As for the transit cases, we will consider experimenting with more complex internal topologies, such as those including route reflectors and route clients.
References
1. A. Belenky, et.al. On IP Traceback. IEEE Communications Magazine, 41(7):142–
153, July 2003.
2. A.C. Snoeren, et.al. Single-packet IP traceback. IEEE/ACM Trans. on Netw.,
10(6):721–734, 2002.
3. Cisco Systems Inc. Remotely Triggered Black Hole Filtering - Destination Based and Source Based. White Paper., 2005.
4. B. Claise. Cisco Systems NetFlow Services Export Version 9. RFC 3954 (Informa-tional), october 2004.
5. L. Deri. nProbe page of the ntop official website.
6. H. Burch, et.al. Tracing Anonymous Packets to Their Approximate Source. In
Proceedings of 14th USENIX Systems Administration Conference ’00, dec 2000. 7. InMon. Descriptive page of the sFlow Toolkit including sflowtool.
8. K. Ishiguro, et.al. GNU Zebra official website.
9. A. Networks. Alaxala 3600S Configuration Manual Vol. 2.
10. N.G. Duffield, et.al. Trajectory Sampling for Direct Traffic Observation. In
Pro-ceedings ACM SIGCOMM 2000, 2000.
11. P. Phaal, et.al. InMon Corporation’s sFlow: A Method for Monitoring Traffic in Switched and Routed Networks. RFC 3176 (Informational), september 2001. 12. S. Floyd, et.al. Pushback Messages for Controlling Aggregates in The Network.
Internet Draft, july 2001.
13. S. Savage, et.al. Network support for ip traceback. IEEE/ACM Trans. Netw.,
