Frédéric Cuppens

Nora Cuppens-Boulahia

Joaquín García-Alfaro

Detection of Network Security Component Misconfiguration by Rewriting and Correlation

Keywords: Network Security, Distributed Firewalls, Filtering Rules, Policy Anomalies

The use of firewalls is the dominant method to guarantee network access control, leading to distributed access control scenarios where the access control role is assigned to more than one component. Firewalls are network security components which provide means to filter traffic within corporate networks, as well as to police incoming and outcoming interaction with the Internet. For this purpose, it is necessary to configure firewalls with a set of filtering rules. Nevertheless, the existence of anomalies between rules, particularly in distributed access control scenarios, is very likely to degrade the network security policy. The discovering and removal of these anomalies is a serious and complex problem to solve. In this paper, we present a set of algorithms for such a management. Our approach is based on the analysis of relationships between filtering rules, in order to detect anomalies, as well as propose policy changes within both single or multi-firewall scenarios.

Introduction

Many companies use firewalls to filter traffic between trusted and untrusted zones of corporate networks, as well as to police their incoming and outcoming interaction with the Internet. Firewalls are security components, with several interfaces associated with the different zones of the network. A company may partition, for instance, its network into three different zones: a demilitarized zone, a private network and a zone for security administration. In this case, one may use a single firewall setup, with three interfaces associated with these three zones, as well as a multi firewall setup, with a firewall protecting each zone.

To apply the filtering policy, it is necessary to configure each firewall with a set of filtering rules. Each filtering rule typically specifies a decision (e.g., accept or deny) that applies over a set of condition attributes, such as protocol, source, destination, and so on. For our work, we define a filtering rule as follows: R i : {condition i } → decision i [START_REF] Adiseshu | Detecting and Resolving Packet Filter Conflicts[END_REF] where i is the relative position of the rule within the set of rules, decision i is a boolean expression in {accept, deny}, and {condition i } is a conjunctive set of condition attributes such that {condition i } equals A 1 ∧ A 2 ∧ ... ∧ A p , and p is the number of condition attributes of the given filtering rules.

In a single firewall scenario (cf. Figure 1(a)), conflicts due to rule overlaps, i.e., the same rule matching more than one filtering rule, can occur. To solve these conflicts, most firewall implementations use a first matching strategy through the ordering of rules. This way, each packet processed by the firewall is mapped to the decision of the rule with highest priority. This strategy introduces, however, new configuration errors, often referred in the literature as intra-firewall anomalies. In multi-firewall setups (cf. Figure 1(b)), on the other hand, different firewalls within the same path may perform different decision to the same network traffic. This problem is often referred in the literature as inter-firewall anomalies.

The discovering and removal of both intra and inter-firewall anomalies is a serious problem which must be solved since, a misconfigured policy, if not handled correctly, is very likely to cause packets to be subject to the wrong actions, and to lead to a weak security policy.

In [START_REF] Cuppens | Detection and Removal of Firewall Misconfiguration[END_REF], we presented an audit process to manage intra-firewall policy anomalies, in order to detect and remove anomalies within the set of rules of a given firewall. This audit process is based on the existence of relationships between the condition attributes of the filtering rules, such as coincidence, disjunction, and inclusion, and proposes a transformation process which derives from an initial set of rules -with potential policy anomalies -to an equivalent one which is completely free of errors. Furthermore, the resulting rules are completely disjoint, i.e., the ordering of rules is no longer relevant. In this paper, we extend our proposal of detecting and removing intra-firewall policy anomalies [START_REF] Cuppens | Detection and Removal of Firewall Misconfiguration[END_REF], to a distributed firewall setup. Our extended approach is based on the hypothesis that not only one firewall ensures the network access control. We assume that this role is assigned to more than one network security component, i.e., a distributed access control. Our main objective is the following. Given a specific distributed access control setup, we want to analyze the existing firewall configurations to check whether there are errors in such a configuration regarding the policy set up of the rest of firewalls which match the same traffic.

The advantages of our proposal are twofold. First, when performing our proposed intra-firewall discovery of anomalies, and after rewriting the rules, one can verify that the resulting configuration of each firewall in the network is free of errors. Each anomalous rule -considered as useless during the audit processwill be removed from the set of filtering rules of each given firewall. Second, when applying our proposed inter-firewall discovery of anomalies, as well as when performing the intra-firewall proposal, the discovering process will provide an evidence of error to the administration console. This way, the security officer in charge of the network can check the network policy, in order to verify the correctness of the whole process, and perform the proper policy modifications to avoid such anomalies. The rest of this paper is organized as follows. Section 2 starts with an analysis of some related work. Sections 3 and 4 present, respectively, our intra and inter-firewall algorithms. Section 5 overviews the performance of our proposed algorithms, and Section 6 closes the paper.

FW1 FW2

Related Work

A first approach to get an access control policy free of errors is by applying a formal security model to express the network policy. In [START_REF] Cuppens | A formal approach to specify and deploy a network security policy[END_REF], for example, we presented a formal model with this purpose. This way, a set of filtering rules, whose syntax is specific to a given firewall, may be generated using a transformation language.

Some other proposals, such as [START_REF] Adiseshu | Detecting and Resolving Packet Filter Conflicts[END_REF][START_REF] Gupta | Algorithms for Routing Lookups and Packet Classification[END_REF][START_REF] Liu | Complete Redundancy Detection in Firewalls[END_REF][START_REF] Al-Shaer | Conflict Classification and Analysis of Distributed Firewall Policies[END_REF], provide means to directly manage the discovery of anomalies from the components' configuration. For instance, the authors in [START_REF] Adiseshu | Detecting and Resolving Packet Filter Conflicts[END_REF] consider that, in a configuration set, two rules are in conflict when the first rule in order matches some packets that match the second rule, and the second rule also matches some of the packets that match the first rule. This approach is very limited since it just detects a particular case of wrongly defined rules in a single firewall configuration, i.e., just ambiguity within a intra-firewall configurations could be detected. It does not provide, furthermore, detection on more complex scenarios, i.e., inter-firewall configurations, where more than one component is intended to perform network access control.

In [START_REF] Gupta | Algorithms for Routing Lookups and Packet Classification[END_REF], two new cases of anomalies are considered. First, a rule R j is defined as backward redundant iff there exists another rule R i with higher priority in order such that all the packets that match rule R j also match rule R i . Second, a rule R i is defined as forward redundant iff there exists another rule R j with the same decision and less priority in order such that the following conditions hold: (1) all the packets that match R i also match R j ; (2) for each rule R k between R i and R j , and that matches all the packets that also match rule R i , R k has the same decision as R i . Although this approach seems to head in the right direction, we consider it as incomplete, since it does not detect all the possible cases of anomalies (as we define in sections 3 and 4). For instance, given the set of rules shown in Figure 2(a), since R 2 comes after R 1 , rule R 2 only applies over the interval [51, 70] -i.e., R 2 is not necessary, since, if we remove this rule from the configuration, the filtering policy does not change. The detection proposal, as defined in [START_REF] Gupta | Algorithms for Routing Lookups and Packet Classification[END_REF], cannot detect the redundancy of rule R 2 within the configuration of such a given firewall.

R 1 : s ∈ [10, 50] → deny R 2 : s ∈ [40, 70] → accept R 3 : s ∈ [50, 80] → accept (a) Set of rules A R 1 : s ∈ [10, 50] → accept R 2 : s ∈ [40, 90] → accept R 3 : s ∈ [30, 80] → deny (b) Set of rules B

Fig. 2: Example of some firewall configurations

To our best knowledge, the firewall policy advisor [START_REF] Al-Shaer | Conflict Classification and Analysis of Distributed Firewall Policies[END_REF] propose the most efficient set of techniques and algorithms to detect policy anomalies in both single and multi-firewall configuration setups. In addition to the discovery process, their approach also attempts an optimal insertion of arbitrary rules into an existing configuration, through a tree based representation of the filtering criteria. Nonetheless, and even though the efficiency of their proposed discovering algorithms and techniques is very promising, we also consider this approach as incomplete.

First, their intra-firewall discovery approach is too weak since, given a misconfigured firewall, their detection algorithms could not detect all the possible errors. For example, given the set of rules shown in Figure 2(b) the approach defined in [START_REF] Al-Shaer | Conflict Classification and Analysis of Distributed Firewall Policies[END_REF] cannot detect that rule R 3 will be never applied due to the union of rules R 1 and R 2 . Second, the authors do not cover an automatic rewriting of rules, as our intra-firewall approach does, to correct the discovered errors. This way, they intentionally point this work to be performed by the security officer, once the discovery process will finish. Third, their inter-firewall discovery approach considers anomalies some situations that, from our point of view, must be suited to avoid inconsistent decisions between firewalls used in the same policy to control the access to different zones. For instance, given the scenario shown in Figure 1(a), their algorithms will wrongly report a redundancy anomaly between filtering rules FW 1 {R 1 } and FW 2 {R 1 }. This is because rule FW 1 {R 1 } matches every packet that also FW 2 {R 1 } does. As a consequence, [START_REF] Al-Shaer | Conflict Classification and Analysis of Distributed Firewall Policies[END_REF] considers rule FW 2 {R 1 } as redundant since packets denied by this rule are already denied by rule FW 1 {R 1 }. However, this conclusion is wrong because rule FW 1 {R 1 } applies to packets from the external zone to the private zone whereas rule FW 2 {R 1 } applies to packets from the DMZ zone to the private zone. So, rule FW 2 {R 1 } is useful and cannot be removed. Summing up, [START_REF] Al-Shaer | Conflict Classification and Analysis of Distributed Firewall Policies[END_REF] is unable to draw this right conclusion because it does not properly model, as we do (cf. Section 4.1), which traffic flows through a given firewall.

Intra-Firewall Analysis

The main objective of the intra-firewall algorithms we proposed in [START_REF] Cuppens | Detection and Removal of Firewall Misconfiguration[END_REF] is the discovering and removal of both redundancy and shadowing anomalies inside an initial set of filtering rules R. These two main intra-firewall anomalies are defined as follows.

Intra-Firewall Redundancy Let R be a set of filtering rules. Then R has redundancy if and only if there exists at least one filtering rule, R i in R, such that when removing R i from R, the filtering result, i.e., the security policy, does not change.

Intra-Firewall Shadowing Let R be a set of filtering rules. Then R has shadowing if and only if there exists at least one filtering rule, R i in R, which never applies because all the packets that R i may match, are previously matched by another rule, or combination of rules, with higher priority in order.

A p ∩ B p ) = ∅) then C[condition] ← C[condition] ∪ 8 {(B1 -A1) ∧ B2 ∧ ... ∧ Bp, 9
(A1 ∩ B1) ∧ (B2 -A2) ∧ ... ∧ Bp, 10
(A1 ∩ B1) ∧ (A2 ∩ B2) ∧ (B3 -A3) ∧ ... ∧ Bp, 11 ... 12
(A1 ∩ B1) ∧ ... ∧ (Ap-1 ∩ Bp-1) ∧ (Bp -Ap)};
(i + 1) to n do 5 if R i [decision] = R j [decision] then 6 R j ← exclusion (R j ,R i ); 7 if R j [condition] = ∅ then 8 R j [shadowing] ← true; 9 /*Phase 2*/ 10 for i ← 1 to (n -1) do 11 R a ← {r k ∈ R | n ≥ k > i and 12 r k [decision] = r i [decision]}; 13 if testRedundancy (R a ,R i ) then 14 R i [condition] ← ∅; 15 R i [redundancy] ← true; else 16 for j ← (i + 1) to n do 17 if R i [decision]=R j [decision] then 18 R j ←exclusion (R j ,R i ); 19 if (¬R j [redundancy] and 20 R j [condition] = ∅) then 21 R j [shadowing] ← true; 22 end 23
Our proposed audit process is a way to alert the security officer in charge of the network about these configuration errors, as well as to remove all the useless rules in the initial firewall configuration. The data to be used for the detection process is the following. A set of rules R as a list of initial size n, where n equals count(R), and where each element is an associative array with the strings condition, decision, shadowing, and redundancy as keys to access each necessary value.

To simplify the algorithms, we assume one can access a linked-list through the operator R i , where i is the relative position regarding the initial list size -count(R). We also assume one can add new values to the list as any other normal variable does (element ← value), as well as to remove elements through the addition of an empty set (element ← / 0). The internal order of elements from the linked-list R keeps with the relative ordering of rules. For reasons of clarity, we split the whole process in three different algorithms. The first algorithm is an auxiliary function whose input is two rules, A and B. Once executed, this auxiliary function returns a further rule, C, whose set of condition attributes is the exclusion of the set of conditions from A over B. In order to simplify the representation of this algorithm (cf. Algorithm 1), we use the notation A i as an abbreviation of the variable A[condition][i], and the notation B i as an abbreviation of the variable B[condition][i] -where i in [1, p]. The second algorithm is a boolean function in {true, f alse} which, in turn, applies the transformation exclusion over a set of filtering rules to check whether the rule obtained as a parameter is potentially redundant. The third algorithm performs the whole process of detecting and removing both redundancy and shadowing, and is also split in two different phases. During the first phase, a set of shadowing rules are detected and removed, by iteratively applying Algorithm 1 -when the decision field of the two rules is different. Let us notice that this stage of detecting and removing shadowed rules is applied before the detection and removal of proper redundant rules. The resulting set of rules is then used when applying the second phase. This stage is performed to detect and remove proper redundant rules, as well as to detect and remove all the further shadowed rules resulting during the latter process.

Correctness of the Intra-Firewall Algorithms

Default policies

Each firewall implements an open or closed default policy. In the open policy, the default policy is to accept a packet when no filtering rule applies. By contrast, the closed policy will reject a packet when no rule applies. After rewriting the rules with the intra-firewall-audit algorithm (cf. Algorithm 3), we can actually remove every rule whose decision is accept if the default policy of this firewall is open (else this rule is redundant with the default policy) and similarly we can remove every rule whose decision is deny if the default policy is closed. Thus, we can consider that our intra-firewall algorithm generates a configuration that only contains accept rules if the firewall default policy is closed and deny rules if the default policy is open.

Inter-Firewall Analysis

The objective of the inter-firewall audit algorithms is the complete discovering of policy anomalies that could exist in a multi-firewall scenario, i.e., to discover and warn the security officer about potential anomalies between policies of different firewalls.

The main hypotheses to deploy our algorithms hold the following: (1) An upstream network traffic flows away from the closest firewall to the origin of this traffic (i.e., the most-upstream firewall) towards the closest firewall to the remote destination (i.e., the most-downstream firewall); (2) Every firewall policy in the network has been rewritten through the algorithms defined in Section 3, i.e., it does not contain intrafirewall anomalies and the rules within such a policy are completely independent between them.

Network Model

The purpose of our network model is to determine which firewalls are crossed by a given packet knowing its source and destination. It is defined as follows. First, and concerning the traffic flowing from two different zones of the distributed access control scenario, we may determine the set of firewalls that are crossed by this flow. Regarding the scenario shown in Figure 1 Let F be a set of firewalls and let Z be a set of zones. We assume that each pair of zones in Z are mutually disjoint, i.e., if z i ∈ Z and z j ∈ Z then z i ∩z j = / 0. We then define the predicate connected( f 1 , f 2 ) as a symmetric and anti-reflexive function which becomes true whether there exists, at least, one interface connecting firewall f 1 to firewall f 2 . On the other hand, we define the predicate ad jacent( f , z) as a relation between firewalls and zones which becomes true whether the zone z is interfaced to firewall f . Referring to Figure 1(b), we can verify that predicates connected(FW 1 , FW 2 ) and connected(FW 1 , FW 3 ), for example, become true, as well as predicates ad jacent(FW 1 , DMZ), ad jacent(FW 2 , private 1 ), ad jacent(FW 3 , DMZ), and so on, also do. We then define the set of paths, P, as follows. Let us now define the functions f irst, last, and the order functor between paths. We first define function f irst from P in F such that if p is a path, then f irst(p) corresponds to the first firewall in the path. Conversely, we define function last from P in F such that if p is a path, then last(p) corresponds to the last firewall in the path. We then define the order functor between paths as p 1 ≤ p 2 , such that path p 1 is shorter than p 2 , and where all the firewalls within p 1 are also within p 2 .

If f ∈ F then [ f ] ∈ P is
Finally, let us conclude this section by defining the functions route and minimal route. We define function route from Z to Z, i.e., {route(z 1 , z 2 ) : Z × Z in 2 P }, such that p ∈ route(z 1 , z 2 ) iff path p connects zone z 1 to zone z 2 . Formally, p ∈ route(z 1 , z 2 ) iff ad jacent( f irst(p), z 1 ) and ad jacent(last(p), z 2 ). Similarly, we define the function minimal route from Z to Z, i.e., {minimal route(z 1 , z 2 ) : Z × Z in 2 P }, such that p ∈ minimal route(z 1 , z 2 ) iff the following conditions hold: (1) p ∈ route(z 1 , z 2 ); (2) There does not exist p ′ ∈ route(z 1 , z 2 ) such that p ′ < p. Thus, and regarding Figure 1

Inter-Firewall Anomalies Classification

We classify in this section the complete set of anomalies that can occur within a multi-firewall setup. Our classification is based on the network model presented in Section 4.1. An example for each anomaly will be illustrated through the distributed access control setup shown in Figure 3. Referring to this figure, we assume that a network traffic flows from the most-upstream firewall (which is the closest firewall to the flow source's zone) to the most-downstream firewall (which is the closest firewall to the flow destination's zone). Inter-Firewall Reflexivity A filtering rule in a multi-firewall setup is reflexive if both source and destination address are within the same zone, and its decision is accept. Thus, the reflexive rule will never match network traffic since it does not flow through this firewall. For instance, referring to Figure 3, rule FW 1 {R 1 } is reflexive since the source of this address, external network, as well as its destination, is the same.

Inter-Firewall Irrelevance An irrelevance anomaly occurs when a firewall is not within the minimal route that connects the source zone, concerning the irrelevant rule which causes the anomaly, to the destination zone. Hence, the rule is irrelevant since it matches traffic which does not flow through this firewall. Rule FW 1 {R 2 }, for example, is irrelevant since firewall FW 1 is not in the path which corresponds to the minimal route between the source zone private 1 to the destination zone DMZ.

Inter-Firewall Spuriousness A spuriousness anomaly occurs if the most-upstream firewall denies, completely or partially, network traffic that, in turn, is accepted by a downstream firewall. The first case, full spuriousness anomaly, is when the most-upstream firewall denies all the traffic. As we can see in Figure 3, rule FW 4 {R 1 } shows an example of full spuriousness anomaly with rule FW 2 {R 2 }. The second case, partial spuriousness anomaly, happens when the most-upstream firewall denies just a part of the traffic that is accepted by the firewall where the anomaly is detected. Rules FW 4 {R 2 } and FW 2 {R 2 } show an example of partial spuriousness anomaly.

Inter-Firewall Redundancy A redundancy anomaly occurs if a downstream firewall completely or partially blocks traffic that is already blocked by the most-upstream firewall. Rules FW 4 {R 3 } and FW 3 {R 1 } show proper of full redundancy, whereas rules FW 4 {R 4 } and FW 3 {R 2 } show an example of partial redundancy. Sometimes, this kind of redundancy is expressly introduced by network administrators to guarantee the forbidden traffic will not reach the destination. Nonetheless, it is important to discover it since, if such a rule is applied, we may conclude that at least one of the redundant firewalls is wrongly working.

Inter-Firewall Shadowing

A full shadowing anomaly occurs if the most-upstream firewall completely blocks network traffic that, in turn, is permitted by a downstream firewall. Rule FW 1 {R 3 } shows an example of full shadowing anomaly with rule FW 3 {R 3 }. On the other hand, a partial shadowing anomaly occurs if the most-downstream firewall denies just some network traffic that, in turn, is permitted by an upstream firewall. Rule FW 1 {R 4 } is a proper example of partial shadowing anomaly with rule FW 3 {R 4 }.

Inter-Firewall Accessibility

To guarantee the flow of network traffic may reach the destination, all upstream firewalls must permit, explicitly with a rule, or implicitly through the default open policy, any traffic that is also permitted along the downstream firewalls chain. Otherwise, a completely or partially accessibility anomaly will occur if one of the following conditions holds:

(1) The traffic is permitted by a downstream firewall, but not permitted -explicitly or implicitly -by the most-upstream firewall. Rules FW 1 {R 5 } and FW 1 {R 6 } show an example of this first case of full and partial accessibility anomaly, respectively, with the upstream firewall FW 2 .

(2) The traffic is permitted by an upstream firewall, but not permitted -explicitly or implicitly -by the following downstream firewall. Rules FW 2 {R 3 } and FW 2 {R 4 } show an example of this second case of full and partial accessibility anomaly, respectively, with the downstream firewall FW 1 .

Inter-Firewall Misconnection

A filtering rule in a distributed firewall setup is misconnected if this rule blocks traffic which is not explicitly blocked by the most-upstream firewall and, at the same time, the default policy of such a firewall is open. A proper example of this anomaly is rule FW 4 {R 5 }, since it blocks traffic which is not explicitly specified within the firewall FW 3 -which, in turn, has an open default policy.

Inter-Firewall Analysis Algorithms

For reasons of clarity, we split the whole analysis process in four different algorithms. The input for the first algorithm (cf. Algorithm 4) is the set of firewalls F, such that for all f w ∈ F, we note f w[rules] as the set of filtering rules of firewall f w, and f w[policy] ∈ {open, close} as the default policy of such a firewall f w. In turn, each rule r ∈ f w[rules] consists of a boolean expression over the attributes szone (source zone), dzone (destination zone), sport (source port), d port (destination port), protocol, and decision (accept or deny).

We then define the functions source(r) = szone and dest(r) = dzone. Thus, we compute for each firewall f w ∈ F and for each rule r ∈ f w[rules], each one of the source zones z 1 ∈ Z s and destination zones z 2 ∈ Z d -whose intersection with respectively szone and dzone is not empty -which become, together with a reference to each firewall f w and each rule r, the input for the second algorithm (i.e., Algorithm 5).

The first verification Algorithm 5 does is to check whether both z 1 and z 2 are the same. If this case occurs, and the decision of this rule is pointing to accept, it warns the security officer about the occurrence of a reflexivity anomaly (cf. Section 4.2). Otherwise, it computes the minimal route of firewalls that connects zone z 1 to z 2 , i.e., [FW 1 , FW 2 , . . . , FW n ] ∈ minimal route(z 1 , z 2 ). Once computed the set of paths, the second verification of Algorithm 5 is to check whether current firewall f w is not within such a path. If so, it warns the security officer about the occurrence of an irrelevance anomaly (cf. Section 4.2). Otherwise, it decomposes the set of firewalls inside each path in upstream path (path u ) and downstream path (path d ).

To do so, we use the implicit functions head and tail. Then, the first firewall w ∈ path d , and the last firewall f w u ∈ path u are passed, respectively, as argument to the last two algorithms (i.e., Algorithm 6 and Algorithm 7) in order to conclude the set of necessary checks that guarantee the audit process ‡ .

Algorithm 4: inter-firewall-audit(F ) Let us conclude this section by giving an outlook to the set of warnings send to the security officer after the execution of Algorithm 4 over the scenario of Figure 3:

foreach f w ∈ F do 1 foreach r ∈ f w[rules] do 2 Z s ← {z ∈ Z | z ∩ source (r) = ∅}; 3 Z d ← {z ∈ Z | z ∩ dest (r) = ∅};
(Reflexivity) on FW 1 {R 1 } (Irrelevance) on FW 1 {R 2 } (Full Shadowing) on FW 1 {R 3 } with FW 3 {R 3 } (Partial Shadowing) on FW 1 {R 4 } with FW 3 {R 4 } (Full Accessibility) on FW 1 {R 5 } with FW 2 (Partial Accessibility) on FW 1 {R 6 } with FW 2 {R 1 } (Full Accessibility) on FW 2 {R 3 } with FW 1 (Partial Accessibility) on FW 2 {R 4 } with FW 1 {R 7 } (Full Spurious) on FW 4 {R 1 } with FW 2 {R 2 } (Partial Spurious) on FW 4 {R 2 } with FW 2 {R 2 } (Full Redundancy) on FW 4 {R 3 } with FW 3 {R 1 } (Partial Redundancy) on FW 4 {R 4 } with FW 3 {R 2 } (Misconnection) on FW 4 {R 5 } with FW 3
Ú ‡ The operator "∽" within algorithms 6 and 7 denotes that two rules r i and r j are correlated if every attribute in R i has a non empty intersection with the corresponding attribute in R j .

Correctness of the Inter-Firewall Algorithms

To prove the correctness of the inter-firewall algorithms, we first define what is a deployment without anomalies for a set of filtering rules. For this purpose, let us consider a set R of filtering rules to be deployed over a set F of firewalls that partitions a network into a set Z of zones. We also assume that F has be rewritten by applying the intra-firewall-audit algorithm showin in Section 3.

Let us now consider a rule r ∈ R and let us assume r to a source zone z 1 and a destination zone z 2 , i.e., s = z 1 ∩ source(r) = / 0 and d = z 2 ∩ dest(r) = / 0. Let r ′ be a rule identical to r except that source(r ′ ) = s and dest(r ′ ) = d. Finally, let us assume that [FW 1 , FW 2 , ..., FW k ] ∈ minimal route(z 1 , z 2 ).

By keeping with all these statements, and based on our deployment algorithm (cf. Algorithm 8), we can now prove the following theorem.

Theorem 4.1 Let F be a set of firewalls. The inter-firewall algorithms presented in Section 4 do not detect any anomaly in the configurations of F iff there is a set R of filtering rules such that configurations of F are obtained by applying the above deployment algorithm § .

Performance Evaluation

In this section, we present an evaluation of the performance of MIRAGE (which stands for MIsconfiguRAtion manaGEr), a software prototype that implements the intra and inter-firewall algorithms presented in sections 3 and 4. MIRAGE has been developed using PHP language. MIRAGE can be locally or remotely executed by using a HTTP server (e.g., Apache server over UNIX or Windows setups) and a web browser. We evaluated our approach through the following experiments ¶ . We first measured the memory and time processing needed to perform Algorithm 3 over several sets of filtering policies for a first IPv4 network, according to the three following security officer profiles: beginner, intermediate, and expert -where the probability to have overlaps between rules increases from 5% to 90%. The results of these measurements are plotted in Figure 4(a) and Figure 4(b). We conducted, in a second phase, similar experiments to measure the performance and scalability of Algorithm 4 through a progressive increment of rules, firewalls and zones for a second IPv4 network. The results of these measurements are plotted in Figure 5 In this paper we presented an audit process to set a distributed access control policy free of anomalies. Our audit process has been presented in two main blocks. We first presented, in Section 3, a set of algorithms for intra-firewall analysis, according to the discovering and removal of policy anomalies over single-firewall environments. The detection process is based on the existence of relationships between the condition attributes of the filtering rules, such as coincidence, disjunction, and inclusion. Then, our proposal uses a transformation process which derives from an initial set of rules -potentially misconfigured -to an equivalent one which is completely free of misconfiguration. We then presented, in Section 4, a set of algorithms for inter-firewall analysis, in order to detect and warn the security officer about the complete existence of anomalies over a multi-firewall environment. Some advantages of our approach are the following. First, our intra-firewall transformation process verifies that the resulting rules are completely independent between them. Otherwise, each redundant or shadowed rule considered as useless during the process is removed from the configuration. Second, both intra and inter-firewall discovering processes provide an evidence of error to the administration console. This way, the security officer check the security policy is consistent, in order to verify the correctness of the whole process.

We presented in Section 4.1 a network model to determine which firewalls are crossed by a given packet knowing its source and destination. Thanks to this model, our approach better defines all the set of anomalies studied in the related work, and it reports, moreover, three new anomalies (reflexivity, misconnection, and irrelevance) not reported, as defined in this paper, in none of the other approaches. Furthermore, and as pointed out in Section 2, the lack of this model in [START_REF] Al-Shaer | Conflict Classification and Analysis of Distributed Firewall Policies[END_REF] leads to wrong decisions. Finally, the implementation of our approach in a software prototype demonstrates the practicability of our work. We shortly discussed this implementation, and presented an evaluation of its performance. Although these results show that our algorithms have strong requirements, we believe that these requirements are reasonable for off-line analysis, since it is not part of the critical performance of a firewall.

FW1{R1}Fig. 1 :

 1 Fig. 1: Example of some firewall setups

Algorithm 1 : 1 C 2 C 3 C 4 C

 11234 exclusion(B,A) begin [condition] ← ∅; [decision] ← B[decision]; [shadowing] ← f alse; [redundancy] ← f alse; 5 forall A[condition] and B[condition] do 6 if ((A 1 ∩ B 1 ) = ∅ and (A 2 ∩ B 2 ) = ∅ and ...

1 test ← f alse; 2 i ← 1 ; 3 temp ← r; 4 while 7 test ← true; 8 i

 1213478 ¬test and (i ≤ count(R)) do 5 temp ← exclusion(temp, R i ); 6 if temp[condition] = ∅ then

Theorem 3 . 1

 31 Let R be a set of filtering rules and let Tr(R) be the resulting filtering rules obtained by applying Algorithm 3 to R. Then the following statements hold: (1) R and Tr(R) are equivalent; (2) Ordering the rules in Tr(R) is no longer relevant; (3) Tr(R) is free from both shadowing and redundancy † .

  (b), for example, the set of firewalls crossed by the network traffic flowing from zone external network to zone private 3 equals [FW 1 ,FW 2 ,FW 4 ], and the set of firewalls crossed by the network traffic flowing from zone private 3 to zone private 2 equals [FW 4 ,FW 2 ,FW 3 ].

Fig. 3 :

 3 Fig. 3: Example of a distributed network policy setup

4 foreach z 1 ∈ Z s do 5 foreach z 2 ∈ Z d do 6 audit 7 Algorithm 5 : 6 else if f w ∈ p then 7 path 16 Algorithm 6 : 1 R 5 Algorithm 7 : 1 Rud 3 if 5 else if R ua = ∅ then 6 warning 7 else 22 Algorithm 8 : 1 foreach f w ∈ minimal route(z 1 , z 2 ) do 2 if f w[policy] = close then 3 f 4 f

 4152675671661571356722811234 (f w,r,z 1 ,z 2 ); audit(f w,r,z 1 ,z 2 ) if (z 1 = z 2 ) and (r[decision] ="accept") then 1 warning ("Reflexivity"); 2 else if z 1 = z 2 then 3 foreach p ∈ minimal route (z 1 ,z 2 ) do 4 if f w / ∈ p and r[decision] ="accept" then 5 warning ("Irrelevance"); d ← tail (p,f w); 8 path u ← header (p,f w); 9 if path d = ∅ and r[decision] ="accept" 10 then f w d ← first(path d ); 11 downstream (r,f w,f w d ); u ← last(path u ); 15 upstream (r,f w,f w u ); downstream(r,f w,f w d ) if f w d [policy] = close then da ← {r d ∈ f w d | r d Ú r ∧ r d [decision] = accept}; 2 if R da = ∅ then warning ("F ull Accessibility "); 3 else if ¬ testRedundancy (R da ,r) then 4 warning ("P artial Accessibility"); upstream(r,f w,f w u ) Rua ← {ru ∈ f wu | ru Ú r ∧ ru[decision] = accept}; ← {ru ∈ f wu | ru Ú r ∧ ru[decision] = deny}; 2 if r[decision] ="deny" then testRedundancy (R ua ,r) then 4 warning ("F ull Spurious"); ("P artial Spurious"); if testRedundancy (R ud ,r) then 8 warning ("F ull Redundancy"); 9 else if R ud = ∅ then 10 warning ("P artial Redundancy"); 11 else if R ua = ∅ and R ud = ∅ and 12 f w u [policy] = open then warning ("Misconnection"); 13 else 14 if testRedundancy (R ud ,r) then 15 warning ("F ull Shadowing"); 16 else if R ud = ∅) then 17 warning ("P artial Shadowing"); 18 else if R ua = ∅ and f w u [policy] = close then 19 warning ("F ull Accessibility"); 20 else if ¬ testRedundancy (R ua ,r) and 21 f w u [policy] = close then warning ("P artial Accessibility"); deployment(r,z 1 ,z 2 ) if r[decision] = accept then w[rules] ← f w[rules] ∪ r ′ else w ← f irst(minimal route(z 1 , z 2 )) 5 if f w[policy] = open then 6 f w[rules] ← f w[rules] ∪ r ′

  (a) and Figure 5(b).

  Fig.4(a). Memory space evaluation for the intra-firewall algorithms

  This way, we can notice that, concerning Figure 1(b), [FW 1 , FW 2 , FW 4 ] ∈ P and [FW 1 , FW 3 ] ∈ P.

an atomic path. Similarly, if [p. f 1 ] ∈ P (be "." a concatenation functor) and f 2 ∈ F, such that f 2 / ∈ p and connected( f 1 , f 2 ), then [p. f 1 . f 2 ] ∈ P.

  (b), we can verify that the minimal route from zone private 3 to zone private 2 equals [FW 4 , FW 2 , FW 3 ], i.e., minimal route(private 3 , private 2 ) = {[FW 4 , FW 2 , FW 3 ]}.

† A set of proofs to validate Theorem 3.1, as well as a complexity analysis for the intra-firewall algorithms, is provided in[START_REF] Cuppens | Detection and Removal of Firewall Misconfiguration[END_REF].

§ This theorem guarantees the correctness of the anomalies detected by our inter-firewall algorithms. ¶ The whole of these experiments were carried out on an Intel-Pentium M 1.4 GHz processor with 512 MB RAM, running Debian GNU/Linux 2.6.8, and using Apache/1.3 with PHP/4.3 configured.

Acknowledgements

This work was supported by funding from the French ministry of research, under the ACI DESIRS project, the Spanish Government project TIC2003-02041, and the Catalan Government grant 2003FI126.


J G Alfaro

Evaluation of Anonymized ONS Queries

Keywords: Radio Frequency Identification (RFID), Domain Name System (DNS), Network Security, Onion Routing, Anonymity

Electronic Product Code (EPC) is the basis of a pervasive infrastructure for the automatic identification of objects on supply chain applications (e.g., pharmaceutical or military applications). This infrastructure relies on the use of the (1) Radio Frequency Identification (RFID) technology to tag objects in motion and (2) distributed services providing information about objects via the Internet. A lookup service, called the Object Name Service (ONS) and based on the use of the Domain Name System (DNS), can be publicly accessed by EPC applications looking for information associated with tagged objects. Privacy issues may affect corporate infrastructures based on EPC technologies if their lookup service is not properly protected. A possible solution to mitigate these issues is the use of online anonymity. We present an evaluation experiment that compares the of use of Tor (The second generation Onion Router) on a global ONS/DNS setup, with respect to benefits, limitations, and latency.

Introduction

Electronic Product Code (EPC) is a low-cost technology, based on passive Radio Frequency IDentification (RFID), and acclaimed as the successor of today's omnipresent bar codes. The EPC technology, originated at the MIT's Auto-ID Center (now called the Auto-ID Labs). It has been further developed by different working groups at EPCglobal Inc [EPC07]. It represents the basis of an ubiquitous architecture, called the EPCglobal Network (or EPC network for short), for the automatic identification of objects in motion on supply chains and industrial production applications. Using RFID, a globally unique number is assigned to every tagged object. This number is used to get further information through Internet services. The information about an object is not stored on a given RFID tag, but instead supplied by distributed services on the Internet.

Before deploying an infrastructure based on EPC networks, a security system must be designed and evaluated. This system must follow security policies. These policies must be determined by the organization executives and senior managers. They decide the scope of their security, incident plans, and assets that must be protected according to laws and regulation issues -not only within their own country, but also with their trading partners in other countries [START_REF] Myerson | RFID in the Supply Chain: A Guide to Selection and Implementation[END_REF]. Threats to the EPC network must be examined for every underlying technology. At the lowest level, threats to the RFID service are well addressed in the literature. In [START_REF] Cole | Networked RFID Systems and Lightweight Cryptography -Raising Barriers to Product Counterfeiting[END_REF], for example, a complete review of available mechanisms, such as lightweight authentication protocols and anti-forgery procedures, can be found. These solutions can be included in current EPC networks to countermeasure existing security and privacy weaknesses of RFID devices. Similarly, at the highest level, threats to the Information Service based on Web technologies are also well addressed in the literature (e.g., threats and countermeasures for e-commerce Web services [START_REF] Desmet | Threat modelling for web services based web applications[END_REF]). To the best of our knowledge, threats to the lookup service of the EPC network have not been deeply analyzed and discussed in the literature. We believe that the current specification of the Object Name Service (ONS) of EPCglobal Inc. [EPC07], based on the use of underlying Domain Name System (DNS) queries, introduces clear risks on corporate infrastructures based on EPC networks if such a service is not properly secured. We outlined in [START_REF] Garcia-Alfaro | Analysis of Threats to the Security of EPC Networks[END_REF] these threats and reviewed security and privacy issues of the ONS service of the EPC network architecture. In this paper, we extend this work by evaluating the benefits and limitations when managing privacy invasions on the ONS using the anonymity infrastructure of Tor [START_REF] Dingledine | Tor: the second-generation onion router[END_REF]. We present a practical experiment based on a real ONS setup. Through this experiment, we analyze the overhead causing service latency in a Tor network. We demonstrate that the use of the infrastructure-based anonymity of Tor decreases the risk of a privacy threat while holding the performance of a service, such as the ONS, at an acceptable level. However, Tor cannot guarantee strong privacy. Existing attacks in the literature show how the anonymity offered by Tor can be compromised by an attacker controlling network nodes. We analyze the amount of anonymity that we should expect for our experimental scenario.

Paper Organization. Section 2 introduces the EPC network architecture and its lookup service. Section 3 outlines the privacy invasion of such a lookup service and presents our experimental results. Section 4 reviews related works. Section 5 concludes the paper.

The EPC Network Architecture and the ONS Service

The EPC network is a highly layered service oriented architecture specified by EPCglobal [EPC07] that provides a pervasive infrastructure to link objects, information, and organizations via Internet technologies. At the lowest layer of this architecture, an Identification System based on passive RFID tags and readers provides the means to access and identify objects in motion. On a different layer, a middleware composed of several services (such as filtering, fusion, aggregation, and correlation of events) performs real time processing of tag event data and collects the identifier of objects interrogated by associated RFID readers at different time points and locations. Information gathered by other sensors, such as temperature and humidity, can also be aggregated at the middleware layer within these events. The middleware forwards the complete set of events to a local repository where they are persistently stored (e.g., into a relational or XML database). At the highest layer of the architecture, EPC Information Services (EPCISs) offer the means to access the data stored on each EPC network's repositories. These EPCISs are intended to be implemented using standard Web technologies like the Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL). Two additional services are necessary before accessing the EPC Information Service of a given EPC network from external applications: a lookup service to bind object identifiers and EPCIS, called the Object Name Service (ONS); and a discovery service (EPCDS) to perform searches with high semantics (i.e., similar to Web engines when looking for Web pages). We discuss more in detail the use of the ONS service in the sequel. We do not cover however the EPCDS service since it has not yet been disclosed by EPCglobal.

Lookup of EPC Information Services via ONS

The Object Name Service (ONS) provides a lookup service for EPC networks. EPCglobal aims at implementing the ONS service through Domain Name Service (DNS) technologies. The ONS, as defined in [EPC07], is in fact a convention for the translation of EPC numbers into domain names; and then, using traditional DNS tools, to retrieve lists of EPCISs associated with a given tag. More specifically, EPCglobal uses a particular type of DNS records, called Naming Authority Pointer (NAPTR) (cf. RFC 2915). Instead of resolving host or service names into IP addresses, the ONS service translates EPCs into Uniform Resource Locators (URLs) embedded within NAPTR records. These URLs are the locators of EPC Information Services (EPCISs) that contain information about EPC tagged objects. An ONS service does not contain actual data related to a given EPC. It is intended for the resolution of EPCs into lists of authoritative EPCIS services. By authoritative, we mean that the entity that controls the information about the EPC stored in an ONS record is the entity that assigned the EPC to the item. This implies that URLs returned by ONS only point to manufacturer EPCISs. The EPC structure supports codes widely-used today (e.g., EAN.UCC barcode system) or even self defined conventions. The Tag Data Standard (TDS) [EPC07] defines encoding of an EPC on a tag and encoding for use in the layers of the architecture. For The Header value 00110000 indicates that the tag is encoded using the SGTIN-96 (Serialized Global Trade Item Number) format. The Filter value is additional data used for fast filtering and pre-selection of basic logistics types. The value 000 means that the tagged object does not match any of the logistic types defined in TDS [EPC07]. The Partition value is an indicator of the length of the subsequent Company Prefix and Item Reference numbers. Company Prefix may vary from 40 to 20 bits (12 to 6 decimal digits); and the Item Reference number may vary from 24 to 4 bits (1 to 7 decimal digits). The value 101 indicates that Company Prefix number is encoded using 24 bits (7 decimal digits); and the Item Reference number is encoded using 20 bits (6 decimal digits). Finally, the Serial Number value is encoded using the last 38 bits (12 decimal digits).

The Data Translation Standard (TDTS) shows how a specific representation of an EPC tag can be automatically validated and translated into a different representation. In order to translate the 96 bit representation of the EPC shown above, an ONS resolver based on TDTS performs the following operations. First of all, the EPC in binary form is converted into a Uniform Resource Identifier (URI) which is in turn represented as a Uniform Reference Name (URN) (cf. RFC 2141), using the URN Namespace epc. The URI of a sgtin representation is encoded in ASCII as follows: urn:epc:id:sgtin:CompanyPrefix.ItemReference.SerialNumber. The EPC shown above is encoded as urn:epc:id:sgtin:0434687.075861.274877906943. To generate the ONS query, the ONS resolver needs to transform such an URI into a domain name. To do so, EPCglobal has reserved the subdomain onsepc.com for ONS resolution. The procedure to construct the complete query is the following: (1) remove urn:epc from URI; (2) remove serial number; (3) invert order of the fields; (4) replace ":" with "."; (5) append subdomain onsepc.com. In the above example, the result of translating the EPC tag urn:epc:id:sgtin:0434687.075861. 274877906943 Let us analyze the response returned by dig. NAPTR records (cf. RFC 2915) support the use of regular expression pattern matching. In case a series of regular expressions from distinct NAPTR records need to be applied consecutively to an input, the field Order should be used. However, the mechanism of regular expressions is not currently used in ONS. For this reason, the Order value of each NAPTR record returned by dig is set to zero. Similarly, the field Flag is set to the value u to indicate that the field Regexp contains the URI associated to the requested EPC tag; and the field Replacement contains the operator '.' to indicate to the ONS client that the final URL is indeed the string placed between the markers '!ˆ.*$!' and '!'. The field Service indicates the kind of EPCIS that can be found in such an URI. This field must contain the string 'EPC+' followed by the name of a service, such as xmlrpc and html. If there are different URIs for the same service, the field Pref. can be used by the ONS resolver to choose the preferred one (i.e., the service with lowest value).

Privacy Invasion Due to the ONS Service

The lookup service of the EPC network architecture is the target of a wide range of security and privacy threats due to inherited underlying DNS mechanisms [START_REF] Fabian | Distributed ONS and its Impact on Privacy[END_REF]. Main threats reported in the literature are to the integrity of the security policies of an EPC system resulting from DNS vulnerabilities. Exploitation of vulnerabilities of DNS-based procedures is a clear way of attacking the ONS service of the EPC network architecture. We can find in RFC 3833 a good analysis of threats to the DNS. The most important threats to DNS technologies can be grouped as follows: (1) authenticity and integrity threats to the trustworthy communication between resolvers and servers;

(2) availability threats by means of already existing denial of service attacks; (3) escalation of privilege due to software vulnerabilities in server implementations. Moreover, the DNS protocol uses clear text operations, which means that either a passive attack, such as eavesdropping, or an active attack, such as man-in-the-middle, can be carried out by unauthorized users to capture queries and answers. Although this can be considered as acceptable for the resolution of host names, it is critical when using the ONS service for the resolution of information queries about physical objects. The information stored on an EPC label is an identification number for a specific object in motion in the supply chain. No additional information beyond the number itself is conveyed in the EPC. Any additional piece of information must be retrieved by an EPC Information Service (EPCIS). Unauthorized users may access this data. They may associate products with organizations. The motivation for doing such an attack is high. It might result in financial gains if the collected information can be offered to competitors or thieves interested in performing unauthorized inventories of products associated with the organization [START_REF] Garcia-Alfaro | Analysis of Threats to the Security of EPC Networks[END_REF]. For retailers, the impact of this threat can be considered as minor or medium if clandestine inventorying is not a concern. However, for the supply chain of organizations that manage trade secrets, it must be considered as high. It may have serious consequences for them if the unauthorized inventory is offered to competitors or thieves, i.e., threats to the privacy of their lookup service can result in financial losses, loss of reputation, or loss of trust to the organization. Finally, the impact of this threat to health care and military scenarios (e.g., medical materiel or munition supply chain) must also be ranked as high.

We present in Figure 1 the simulation of a data interception attack that shows how an unauthorized party can obtain private data associated with an organization. The simulation represents the EPC network of an organization O (cf. Figure 1) composed of the following elements: (1) a set E of RFID based EPC tags; (2) a set R of RFID readers; (3) a filtering middleware M ; and (4) an EPC query application Q which is composed of an URI converter, an ONS resolver, and an information query interface. We show in Figure 1 a flow of interactions in which a reader r ∈ R interrogates an EPC tag e ∈ E. The EPC code e in its binary form is sent to the middleware M which in turn forwards it to the local application Q. The URI converter in Q converts e from its binary form into a URI form. The ONS resolver in Q queries the local ONS service L with the URI. If the associated domain name to e is not found in the local cache of L, then a recursive NAPTR query is sent to the global DNS service G which finally returns a list of NAPTR records containing the URLs of the EPCIS of the manufacturer's EPC network associated to e. These URLs are forwarded from local ONS service L to the ONS resolver in Q. The service with highest preference is selected. The information query interface in Q finally contacts the manufacturer's EPCIS to retrieve information about e. Let us also define the threat model. We first assume that organization O holds a privacy policy P which specifies the set of permissions and prohibitions regarding the disclosure of data related with objects in motion in its supply chain (among them, manufacturer and product class data) to unauthorized partners. Let us assume that data disclosure associated with EPC e (cf. Figure 1) is specified in P with a prohibition. On the other hand, we define a privacy threat T where the objective of an attacker A is to violate the privacy rules in P . We define in turn the attacker A as the specific agent that tries to exploit vulnerabilities in the ONS service to successfully manage the objective of T . We assume that the power of attacker A is limited to remote operations. However, these remote operations allow attacker A to operate from a shared media associated with the organization's network (e.g., via an open access on a wired or wireless network in organization O) and so performing passive eavesdropping of traffic. Attacker A obtains information about the classes of products that are in motion in the supply chain of organization O. We presume that security mechanisms such as physical access control and surveillance of workers are already deployed. Taking into account the scenario shown in Figure 1 and these previous assumptions, let us finally show with the following example how attacker A, by collecting URI queries from the local ONS service L going towards the global DNS service G, can achieve the objective of threat T . Let 0x30141A87FC4A157FFFFFFFFF be the binary form of e. Let 075861.0434687.sgtin.id.onsepc.com be the result of translating e into its URI form (cf. Section 2.1) and sent as a NAPTR query towards the global service G. Attacker A can then isolate from such a query manufacturer 0434687 and product class 075861 which, according to the set of rules in P defined above, must not be disclosed to unauthorized parties. Attacker A violates policy P .

Enhancement of Privacy through Anonymized Queries

Several anonymity designs have been proposed in the literature with the objective of hiding senders' identities. From simple proxies to complex systems, anonymity networks can offer either strong anonymity with high latency (useful for high latency services, such as email and usenet messages) or weak anonymity with low-latency (useful, for instance, for Web browsing). The most widely-used low latency solution is based on anonymous mixes and onion routing [START_REF] Syverson | Anonymous connections and onion routing[END_REF]. It is distributed as a free software implementation known as The second generation Onion Router (Tor) [START_REF] Dingledine | Tor: the second-generation onion router[END_REF]. It can be installed as an end-user application on a wide range of operating systems to redirect the traffic of low-latency services with a very acceptable overhead. Tor's objective is the protection of privacy of a sender as well as the contents of its messages. To do so, it transforms cryptographically those messages and mixes them via a circuit of routers. The circuit routes the message in an unpredictable way. The content of each message is re-encrypted within each router with the objective of achieving anonymous communication even if a set of routers are compromised by an attacker. Upon reception, a router decrypts the message using a private key to obtain the following hop and encryption key of the following router on the path. This path is initially defined at the beginning of the process. Only the entity that creates the circuit -and which remains at the sender's side during all the process -knows the complete path to deliver a given message. The last router of the path, the exit node, decrypts the last layer and delivers an unencrypted version of the message to its target.

Tor provides an excellent way of establishing anonymous channels for a low latency service like the ONS. However, it might still impact its performance. We performed a practical experiment to assess the cause of latency. We review in Section 3.2 a complete set of experiments we did and their results. These tests were intended to measure the latency penalty as well as to estimate the amount of anonymity obtained using Tor. The dynamic disconnection of routers from the Tor network caused some problems during the experiments and forced to repeat some queries. We recall that Tor is a server-based system whose operators are volunteers. Its service is not guaranteed in any way. Although we experienced such a dynamic disconnection of servers, we did not suffer loss of service on the resolution of queries of our experiments. We measured in our experiments the rate of reliability of nodes and tunnels (cf. Section 3.2). We obtained a rate of reliability of nodes of about 88%. This disconnection of nodes does not seem predictable. However, given the possibility of launching multiple DNS/ONS queries in parallel, we consider this reliability acceptable.

To obtain the low impact over the performance of the services tunneled by Tor, it relies on a very pragmatic threat model. Such a model assumes that adversaries can compromise some fraction of the onion routers in the network. If so, adversaries can not only observe but also manipulate some fraction of the network traffic of Tor. A first implication of this assumption is that the exit node has a complete view of the sender's messages. Therefore, without other countermeasures, it could perform a Man-in-the-Middle attack to forge answers. As a result, a malicious onion router acting as the exit router could try to redirect the client to malicious EPCISs or to perform denial of existence. A proper solution for avoiding this problem is to combine the use of Tor with the integrity and authenticity offered by the security extensions of DNSoften referred in the literature as DNSSEC. In this manner, we can guarantee the legitimity of the answers while maintaining an acceptable performance. As we show in Section 3.2, the impact on the latency of the service when using DNSSEC for our experiments is minimal. We therefore consider that this drawback is equally minimal if we can combine the use of Tor with secure DNS queries based on DNSSEC.

A second implication of the threat model of Tor is the possibility of suffering traffic analysis attacks with the objective of tracing back the sender's origin or to degrade Tor's anonymity. Several traffic analysis attacks against Tor have been reported in the literature. The attack discussed in [START_REF] Wright | An analysis of the degradation of anonymous protocols[END_REF][START_REF] Wright | Passive-logging attacks against anonymous communications systems[END_REF], often referred in the literature as predecessor-attack, assumes that an attacker is controlling routers in the network of Tor to keep track of user's sessions tunneled by Tor. This attack is specially effective to degrade the anonymity of Tor's hidden services. Apart of providing anonymity to its users, Tor can provide its anonymity to host servers to guarantee that their network location is unknown. Resources that are reachable through these hidden services provided by Tor are susceptible to correlation attacks. A predecessor-attack is intended to perform such a correlation. We consider that the communications of our motivation scenario cannot be linked so easily as those reported in [START_REF] Wright | An analysis of the degradation of anonymous protocols[END_REF], mainly based on Web services with long-term cookies or ssh-like applications. Hence, we do not consider relevant to evaluate this attack for our work, as well as some other attacks presented in [START_REF] Overlier | Locating hidden servers[END_REF][START_REF] Murdoch | Hot or not: revealing hidden services by their clock skew[END_REF] which are specially targeted at degrading the anonymity of Tor's hidden services. The attack presented in [START_REF] Murdoch | Low-Cost Traffic Analysis of Tor[END_REF] uses the bandwidth limits of nodes to traceback Tor's circuits without necessity of compromising Tor nodes. It is intended to discover entrance routers rather than sender's identities. The authors assume that the adversary must have complete control over the destination service to which the sender is trying to connect. The attack was presented when the size of the Tor network was still considerably low and it does not seem to be still effective given the current status of Tor [START_REF] Wright | Passive-logging attacks against anonymous communications systems[END_REF]. Furthermore, the authors propose in their work a proper defense to stop their attack. A more appropriate technique that could affect the anonymity of our motivation scenario has recently been presented in [BMG + 07]. The authors propose a traffic analysis attack based on low-cost resources to trace back a sender's origin . They assume that an adversary is gaining control of a sufficient number of entry and exit routers to trace back a sender's origin. When entry and exit routers cooperate, the adversary can try to link communications over the same tunnel. Every router in the network of Tor is indeed connected to a directory service to which they report information such as their available bandwidth. Moreover, the directory service maintains some statistics about the uptime of each router. The attack reported in [BMG + 07] relies mainly on the the injection of false routing data to the directory service of the Tor network in order to increase the chances of being selected. We analyze in Section 3.2 what could the impact of their proposal be over our experimental setup.

Evaluation and Results

This section shows the outcome of our evaluation steered towards measuring the latency penalty due to the use of Tor, as well as an estimation of the average amount of anonymity obtained during our experiments. Our setup simulates the EPC network scenario presented in Figure 1 Each query is implemented as a single process forked from Q or L in a pipelined fashion. The execution of n queries relies on the execution of n independent processes that forked from Q and L. Processes forked from Q communicate with L using TLS/SSL connections that protect their traffic against unauthorized access and eavesdropping. The connection mechanism is implemented using the OpenSSL library (cf. http://www.openssl.org/). X.509 certificates and key pairs are generated by the openssl toolkit.

The Global DNS service (G) is simulated by means of three different hosts: S 1 , that runs on an AMD Duron 1 GHz with 256 MB of memory; S 2 , that runs on an Intel PIII 1 GHz with 512 MB of memory; and S 3 , that runs on an Intel Xeon 2.4 GHz with 1 GB of memory. Servers in G are located on different networks and on different countries: server S 1 is located in North America; and servers S 2 and S 3 are located in Europe. DNS and DNSSEC services configured on each one of these hosts are based on BIND 9.4.2 (cf. http://www.isc.org/products/BIND/). Four different testbed configurations are implemented to simulate the exchange of data between L and G: (1) DNS queries/replies; (2) DNSSEC queries/replies; (3) Tor based (torified for short) DNS queries/replies; and (4) torified DNSSEC queries/replies. For the exchange of messages between L and G, a direct link is used on the two first testbeds. We label them as Direct DNS and DNSSEC tests. An indirect link based on SOCKS4A messages and the Tor network is used on the two last testbeds. For these last testbeds, an onion proxy based on Tor v0.1.2.18 (cf. http://torproject.org) runs on L and redirects the traffic received via SOCKS4a messages to the set of servers configured in G. We label them as Torified DNS and DNSSEC tests.

The configuration of each server in G, for direct and torified DNS tests, consists of three different database record sets. Server S 1 is configured with set A; S 2 with set B; and S 3 with set C. Table 1 summarizes the main properties of each database, i.e., domain names and number of NAPTR RRs. We can see that set A contains three manufacturers (from 0000000.sgtin.id.onsepc.com to 0000002.sgtin.id.onsepc.com) and fifty item references per zone (item 000170 to 000219). It thus contains one hundred fifty Fully Qualified Domain Names (FQDNs). In turn, each FQDN in A contains a minimum of one NAPTR RR, and a maximum of five NAPTR RRs. The distribution of NAPTR RRs on each FQDN is generated at random. The last column of Table 1 shows the exact number of NAPTR RRs in A, i.e., four hundred fifty NAPTR RRs. Similarly, we can see in Table 1 that set B contains ten zones, one hundred item references per zone, and four thousand NAPTR RRs. Finally, set C contains fifty zones, five hundred items per zone, and one hundred thousand NAPTR RRs. On the other hand, the configuration of each server in G for the DNSSEC tests relies on the signature of the database sets of Table 1. We use for this purpose the dnssec-keygen and dnssec-signzone tools that come with BIND 9.4.2. The key sizes are 1200 bits for the generation of Key Signing Keys (KSKs) and 1024 bits for Zone Signing Keys (ZSKs). The generation of Tab. 2: Storage size and signing time associated to each database record set.

keys is based on the RSA implementation of dnssec-keygen. Although the use of ECC signatures seems to reduce the storage space of signed zones [START_REF] Ager | Predicting the DNSSEC overhead using DNS traces[END_REF], the algorithm we use is RSA instead of ECC since the latter is not yet implemented in BIND 9.4.2. Table 2 summarizes the storage size and the time needed to sign the resources of each database record set. We monitored the status of the Tor network during the execution of the tests in order to measure some values such as the bandwidth classes and reliability of its nodes. To do so, we based part of our monitoring process on TorFlow, a set of python scripts written for such a purpose (cf. http://torproject.org/svn/torflow/). Table 3 shows a summary of bandwidth classes associated to the onion routers available in the Tor network during the evaluations. We can appreciate that more than one thousand four hundred onion routers were online during our experiments. The instance of Tor installed at L was set up to be client only (it does not act as another onion router in the Tor network) and configured as default. It therefore chooses best bandwidth routes of length three. The average failure of nodes with a standard deviation of 8% was 12%. According to [START_REF] Borisov | Denial of service or denial of security[END_REF], the reliability of circuits on the network of Tor can be easily determined as follows. Let l be the path length of every circuit (i.e., three onion routers per circuit in our case). Let f be the probability of an onion router being reliable (i.e., 88% of reliability per onion router). We can then calculate the probability of reliability of every circuit as f l . We thus assumed a 68% of reliability for every circuit during our experiments. We show in Figure 2 the results of executing our set of tests. Figure 2(a) shows the execution of direct and torified DNS tests. Figure 2(b) shows the execution of direct and torified DNSSEC tests. Each test is executed multiple times towards cumulative series of fifteen queries generated at random from A, B, and C. Each series is created at random during the execution of the first test (direct DNS test), and persistently stored. It is then loaded into the rest of tests -to allow comparison of results. We can see by looking at the lowest curve of Figures 2(a) and 2(b) that the differences in resolution times using direct DNS or DNSSEC is minimal. During the execution of torified DNS and DNSSEC tests, a different circuit is generated for the resolution of each group of queries in every series. As stated above, the dynamic disconnection of routers from the Tor network caused some problems during the resolution of queries on the torified tests and forced to repeat some queries. This explains the wide confidence intervals in the highest curves shown in Figures 2(a) and 2(b). However, even if we take into account these extreme cases, we can notice that the differences in resolution times are reasonable. Moreover, we confirmed that the reliability of circuits constructed during the experiments was satisfactory and even higher than expected (according to the values measured above). All series of queries were successfully processed and we did not suffer loss of service on the torified tests. We see these results as satisfactory and consider that tunneling of a DNS-like service through the network of Tor has an acceptable impact on its latency. The combination of Tor with DNSSEC has equally an acceptable impact, and it allows us to guarantee security properties not covered by either Tor or DNS like integrity, authenticity, and non-existence proofs. Such properties are essential to detect and prevent man-in-the-middle attacks performed by exit nodes of the network of Tor. We did not experience during our experiments any alteration of signatures from the databases depicted in Table 1. In order to estimate the degree of anonymity offered by the Tor network to our tests, we adopt the same strategy as [BMG + 07] and calculate the degree of anonymity offered by Tor by taking into account the probability distribution over the nodes of the Tor network [START_REF] Díaz | Towards measuring anonymity[END_REF][START_REF] Serjantov | Towards an information theoretic metric for anonymity[END_REF]. Let N be the number of nodes in the Tor network. Let p(x i ) be the probability for a node to be selected for a circuit. Then, we can calculate an entropy based metric as:

H(N ) = - xi∈N p(x i ) log 2 (p(x i ));
If we assume that each node in the Tor network has an equal probability of being included on a path and we normalize H(N ) by dividing it by log 2 (|N |) we then obtain an ideal entropy of 1. However, the path creation algorithm of Tor chooses onion routers taking into account their bandwidth capacity, among other performance information. It is hence not possible for us to measure the proper value of H(N ) since we do not have control over the complete set of nodes of the Tor infrastructure. We approximated such a value using the set of tools included in TorFlow to sort the nodes by their bandwidth capacity, dividing them into different segments, and creating with them several set of circuits in order to estimate their probability distribution. The entropy obtained through TorFlow was approximately 0.89. We consider that this is a very acceptable degree of anonymity. The existence of traffic analysis attacks against Tor degrades however this degree of anonymity. We recall that the threat model of Tor assumes the possibility of adversaries running malicious routers on the network of Tor. They can degrade the anonymity of the system by correlating the traffic that is flowing through them. The main issue for an adversary is to ensure that these nodes are going to be included on a high number of circuits.

According to [START_REF] Dingledine | Tor: the second-generation onion router[END_REF], if an adversary controls m > 1 of N nodes, he can correlate at most ( m N )

2 of the traffic. This model assumes again that each node has an equal probability of being selected to be on a path. The authors in [BMG + 07] demonstrate in their work that by injecting false performance information to the directory services of Tor, it is possible to increase the odds of malicious servers being used. Using their attack, they report an improvement of almost seventy times the analytical expectation calculated with the previous model when the number of compromised nodes introduced in the network goes from 5% to 10%. The same number of compromised nodes means a rather large number of servers in the infrastructure of Tor used during our experiments -from seventy three to more than one hundred compromised nodes. The analytical prediction of compromised paths considering this possibility is between 0.21% and 0.67%. Assuming that the attack presented in [BMG + 07] scales properly for the length of our network, and maintains the reported improvement, we could theoretically expect from 15% to 48% of the paths compromised. This decreases the degree of anonymity of the Tor infrastructure by almost 50%.

Related Work

Privacy threats to the EPC network must be examined for each one of its underlying technologies. Weaknesses and threats to its lowest and highest layers (i.e., identification services based on RFID technologies; and information services based on Web services standards) have received high attention in the current literature. We refer the reader to [START_REF] Cole | Networked RFID Systems and Lightweight Cryptography -Raising Barriers to Product Counterfeiting[END_REF] for a complete review of recent literature and scientific solutions that could be studied in order to handle both critical and major threats to the identification system level of an EPC based RFID setup; and to [START_REF] Desmet | Threat modelling for web services based web applications[END_REF] for a complete analysis of threats and weaknesses of Web services security. However, to the best of our knowledge, little research in current literature addresses the same weaknesses and threats to the lookup service which links both previous layers. Although there exist in the literature studies on DNS threats (cf. RFC 3833), the fact that names resolved through ONS point to physical objects that can be of high value makes necessary a different study of threats and countermeasures beyond DNS security.

Most of the studies about weaknesses at ONS level address availability issues. For example, the use of Peer-to-Peer (P2P) to enhance its performance has been addressed in [DWI + 06, FG07]. In [DWI + 06] the authors, analyze the study of hybrid architectures based on DNS and P2P. However, they do not address security issues further than availability. In [START_REF] Fabian | Distributed ONS and its Impact on Privacy[END_REF] the authors point out to the advantages of using P2P in order to improve the robustness of the service. The work in [START_REF] Fabian | Distributed ONS and its Impact on Privacy[END_REF] also discusses the use of existing security tools (e.g., anonymizers) to handle privacy issues, as well as an obfuscation schema based on hashes and secret key distribution. However, neither specific evaluations nor a specific secret distribution algorithm is presented in [START_REF] Fabian | Distributed ONS and its Impact on Privacy[END_REF]. On the other hand, the use of Privacy Information Retrieval (PIR) [START_REF] Ostrovsky | A survey of single-database private information retrieval: Techniques and applications[END_REF] approaches can also be seen as a mechanism to handle the private distribution of information on the ONS service (e.g., work presented in [START_REF] Zhao | Analysis of Privacy Disclosure in DNS Query[END_REF][START_REF] Zhao | Two-Servers PIR Based DNS Query Scheme with Privacy-Preserving[END_REF]). However, no specific evaluations or practical results are presented in this work. Moreover, the processing and communication bandwidth requirements of a PIR approach seem to be impractical for a low latency service like the ONS [START_REF] Sion | On the Computational Practicality of Private Information Retrieval[END_REF]. Another interesting mechanism to provide private searches on public databases by using encrypted bloom filters is discussed in [START_REF] Bellovin | Privacy-enhanced searches using encrypted Bloom filters[END_REF]. However, no practical results have been provided yet in order to compare this approach with ours.

Conclusion

The use of EPC technologies on supply chain and production applications poses a great challenge when dealing with security and privacy requirements. We analyzed in this paper the lookup service of EPC technologies and invasion of privacy implied by leaking the service when it is not handled properly. We stated that the use of an anonymous communication network based on Tor can handle the service in order to decrease the risk of a privacy threat while holding the performance of the service at an acceptable level. This solution should not be seen however as a silver bullet solution. It does not guarantee strong privacy and must be considered at best as a partial countermeasure. We conclude that more research has to be done on similar directions if we want to fully guarantee privacy requirements on EPC based applications and their lookup service.

Fig. 1 :

 1 Fig. 1: Example of a supply chain setup based on the EPC network architecture.

  . An EPC Query Application (Q) runs on an Intel Core 2 Duo 2 GHz and 1 GB of memory. It is based on the Accada EPC prototyping framework (cf. http://www.accada.org/). The translation of EPCs into ONS domain names is based on the Accada's Tag Data Translation (TDT) implementation. Like in the examples shown in Section 2, the EPC representation that we use in our tests is based on the SGTIN-96 encoding [EPC07]. The Local ONS service (L) runs on an Intel Core 2 Duo 1.8 GHz and 512 GB of memory. It is implemented in the Perl language. The management of DNS and DNSSEC queries at L is based on the module NET::DNS (cf. http://www.net-dns.org/).

Fig. 2 :

 2 Fig. 2: DNS and DNSSEC tests with and without Tor.

  our example, we use a representation based on the 96 bit binary encoding of the serialized version of the EAN/UCC Global Trade Item Number (SGTIN-96). Let us show below the EPC tag used in our examples:

	Header	Filter	Partition	Company Prefix	Item Reference	Serial Number
	00110000	000	101	0x6A1FF	0x12855	0x3FFFFFFFFF

  into an ONS query is therefore encoded as 075861.0434687.sgtin.id.onsepc.com. We can finally run an ONS resolution using DNS tools like nslookup or dig. For example, if we perform an ONS resolution by querying the service with dig -t NAPTR 075861.0434687.sgtin.id.onsepc.com, we can obtain as a result the following NAPTR records [EPC07]:

	Order	Pref.	Flags	Service	Regexp.	Replacement
	0	0	u	EPC+html	!ˆ.*$!http://www.example.com/products/example.asp!	.
	0	0	u	EPC+xmlrpc	!ˆ.*$!http://gateway1.xmlrpc.com/servlet/example!	.
	0	1	u	EPC+xmlrpc	!ˆ.*$!http://gateway2.xmlrpc.com/servlet/example!	.

  Zones, names, and NAPTR Resource Records (RRs) configured in G.

	Set	Starting domain name		Ending domain name	# of RRs
	A	000170.0000000.sgtin.id.onsepc.com	000219.0000002.sgtin.id.onsepc.com	450
	B	001123.0004160.sgtin.id.onsepc.com	001222.0004169.sgtin.id.onsepc.com	4,000
	C	022365.0068760.sgtin.id.onsepc.com	022864.0068809.sgtin.id.onsepc.com	100,000
		Tab. 1: Set	DNS DB size	DNSSEC DB size	Time to sign the DB
		A	42KB		143KB	1.8s
		B	281KB		922KB	13.8s
		C	6MB		22MB	5m16s

  Number of onion routers in the Tor network during the tests.

					Bandwidth class
	996KB/s	621KB/s	362KB/s	111KB/s	59KB/s	29KB/s	20KB/s	19KB/s	10KB/s	5KB/s
	131	63	67	338	315	406	72	68	11	7
		Tab. 3:

Acknowledgments -

The authors graciously acknowledge the financial support received from the following organizations: Natural Sciences and Engineering Research Council of Canada (NSERC), Mathematics of Information Technology and Complex Systems (MITACS), Spanish Ministry of Science and Education (CONSOLIDER CSD2007-00004 "ARES" grant), and La Caixa (Canada awards).