Policy Anomaly Detection for Distributed IPv6 Firewalls
Claas Lorenz
1,2
and Bettina Schnor
2
1
genua mbh, Kirchheim, Germany
2
Institute for Computational Science, Potsdam University, Potsdam, Germany
Keywords:
Security, Firewalls, IPv6, Model-Checking.
Abstract:
Concerning the design of a security architecture, Firewalls play a central role to secure computer networks.
Facing the migration of IPv4 to IPv6, the setup of capable firewalls and network infrastructures will be neces-
sary. The semantic differences between IPv4 and IPv6 make misconfigurations possible that may cause a lower
performance or even security problems. For example, a cycle in a firewall configuration allows an attacker
to craft network packets that may result in a Denial of Service. This paper investigates model checking tech-
niques for automated policy anomaly detection. It shows that with a few adoptions existing approaches can be
extended to support the IPv6 protocol with its specialities like the tremendously larger address space or exten-
sion headers. The performance is evaluated empirically by measurements with our prototype implementation
ad6.
1 INTRODUCTION
IPv6 has a continiously growing share of the traffic
on the Internet (see (Google, 2015)). The slow but
steady migration from IPv4 to IPv6 is a challenge
for a variety of stakeholders like operators, adminis-
trators and security officials. For organizations with
separated networks the change or upgrade of firewall
technology is not a trivial task and can be accompa-
nied by challenges regarding the consistency and se-
curity of the new firewall rulesets (i.e. see (Caicedo
et al., 2009) p. 40, RFC 6180 (Arkko and Baker,
2011) p. 14). On the other hand, it can also be seen
as a chance to get rid of historically grown and in-
efficient firewall policies and network configurations.
For small policy sets a manual migration might be
sufficient but it is prone to error and thus, the anal-
ysis of large policy sets cannot be achieved this way
and enforces a fully automatic approach. Real world
firewalls in larger organizations tend to have from a
thousand up to several ten thousands of rules which is
far beyond the capability of manual approaches.
This paper focuses on supporting this transition
by verifying properties of firewalls and networks for-
mally and thus, allows to compare the semantical state
of the configuration before and after the migration.
The examined semantical properties are called
anomalies and range from simple but clear misconfig-
urations to security threats. The considered anomalies
Figure 1: Examples for IPv6 Header Chains (originally in-
spired by (Biondi and Ebalard, 2006) p. 61).
are reachability, cyclicity, shadowing and cross-path.
They are defined in (Al-Shaer and Hamed, 2004),
(Yuan et al., 2006) and (Jeffrey and Samak, 2009) and
verbosely introduced as follows:
• A cycle occurs if the control flow through the fire-
wall contains a loop and there exists a packet that
would be handled by this infinite path.
• A rule is unreachable if all possible packets are
filtered by preceding rules. A simple example is
given by the following IPTables script:
i p 6 t a b l e s −P OUTPUT DROP
i p 6 t a b l e s −A OUTPUT −j ACCEPT
210
Lorenz C. and Schnor B..
Policy Anomaly Detection for Distributed IPv6 Firewalls.
DOI: 10.5220/0005517402100219
In Proceedings of the 12th International Conference on Security and Cryptography (SECRYPT-2015), pages 210-219
ISBN: 978-989-758-117-5
Copyright
c
2015 SCITEPRESS (Science and Technology Publications, Lda.)
i p 6 t a b l e s −A OUTPUT −p t c p \
−j ACCEPT
The rule ip6tables -A OUTPUT -j ACCEPT
matches all packets and therefore the succeeding
rule cannot be reached.
• Shadowed rules do not have any effect on the fil-
tering characteristics of the firewall since they are
reachable but there exists no packet that can be
matched by the shadowed rule. This is due to
previous rules that filter all traffic matchable by
the shadowed rule. The following IPTables script
gives a small example:
i p 6 t a b l e s −P OUTPUT DROP
i p 6 t a b l e s −A OUTPUT −p t c p \
−j ACCEPT
i p 6 t a b l e s −A OUTPUT −p t c p \
−−d p o r t 80 −j ACCEPT
The second rule is reachable only by non-TCP
packets, but cannot match them.
• The cross-path anomaly can only occur in
network environments with multiple redundant
routes to a host. If there are firewalls on these
paths which handle the same traffic differently
then this could result in severe security issues be-
cause an attacker would be able to send undesir-
able packets to his target.
output
0
, init
udp
accept
0
, accept
true
drop
0
, drop
true
output
1
tcp
output
2
true
true
false
true
false
true
Figure 2: Example of a decision diagram with a cycle. The
upper part of each node shows propositions representing
meta information of the state while the lower part is its de-
cision term.
We investigated whether these anomalies could
be detected with a model checking approach also for
IPv6 networks. Concerning model checking the chal-
lenges of IPv6 lay in the larger base header which has
320Bit compared to 104Bit in IPv4 (without options).
The question is whether it can be handled efficiently.
The same applies to the extension header chains as
depicted in Figure 1 which allow chains of arbitrary
length. Since these did not occur in IPv4 it must
be shown that a formal approach can model them as
well. Our approach investigates networks with state-
less packet filters (firewalls of the first generation) that
make decisions based on single packets rather than se-
quences.
In the next section, related work for the formal
verification of firewalls is discussed. Afterwards, we
propose a concept for model checking of distributed
IPv6 firewalls and illustrate our approach by an ex-
ample. The practical applicability is shown by perfor-
mance measurements of our prototype ad6. The paper
concludes with a summary and an outlook on future
work.
2 RELATED WORK
2.1 Formal Verification with Model
Checking
Model checking is a family of techniques to ver-
ify properties of a model representation of a sys-
tem automatically. Typically, the properties are ex-
pressed as temporal logical formulas. Famous exam-
ples are the languages Linear Time Logic (LTL, intro-
duced by (Pnueli, 1977)), Computational Time Logic
(CTL, introduced by (Emerson and Halpern, 1986))
or the µ-Calculus (see (Kozen, 1983)). Model check-
ing algorithms often operate on data represenations
known as Kripke Structures. These are essentially di-
rected graphs where the nodes are annotated with so
called atomic propositions. For a formal introduction
see (Kripke, 1963). Figure 2 shows an example of a
Kripke Structure which is interpreted as a decision di-
agram. Each node is divided into an upper and a lower
part. The upper half consists of a set of propositions
that serve as meta information and mark special fea-
tures given to the node. For example the first node
is marked as initial node. The lower half contains a
boolean formula that can be evaluated to decide which
outgoing edge should be taken. If the formula udp is
evaluated to true then the corresponding edge to the
accept node is traversed. Note that both, the usage of
formulas as well as boolean annotation on edges, are
extensions to classical Kripke Structures. Some tech-
niques (i.e. LTL) utilize problem encodings in SAT
(see (Biere et al., 2006)) to benefit from the tremen-
dous efforts made to optimize SAT solvers. SAT is
short for the satisfiability problem of boolean logics.
It is also an archetypical problem in complexity the-
ory where it is proofed by Cook’s Theorem that it is
NP-complete (see (Cook, 1971)).
PolicyAnomalyDetectionforDistributedIPv6Firewalls
211
2.2 Tools for Policy Anomaly Detection
A couple of tools support policy anomaly detection
for IPv4 firewalls. The first systematic approach to
automatize policy anomaly detection with formal ver-
ification techniques was performed by Al-Shaer and
Hamed (i.e. see (Al-Shaer and Hamed, 2003), (Al-
Shaer and Hamed, 2004)). Al-Shaer et al. provided
a classification of anomalies which is used broadly.
Generally, there are two approaches that target dif-
ferent scenarios. The top-down strategy includes a
modeling phase where rules are specified in an ab-
stract language. Afterwards they can be analyzed for
anomalies and compiled into concrete rulesets that
can be deployed in real firewalls. On the other hand,
the bottom-up approach relies on existing rulesets that
are parsed and analyzed.
We did not investigate on data mining approaches
(as suggested in i.e. (Golnabi et al., 2006)) since sta-
tistical methods always have to deal with false posi-
tives and false negatives.
Policy Advisor. The tool Policy Advisor (PA,
see (Al-Shaer and Hamed, 2004)) is a hybrid tool and
uses finite automata to check all rules that lay on a
path through a firewall policy pairwise. It parses a
(limited) firewall language and also supports rule edit-
ing. Most notably the PA has polynomial complexity
for all supported anomalies. This is achieved by uti-
lizing a significantly less expressive rule model than
the other approaches (i.e. no CIDR support). If it had
the same expressiveness, it would be exponential in
space.
Further, related work was provided by Abedin et
al. (see (Abedin et al., 2006)) who introduced an
automatic resolution algorithm for several anoma-
lies. Kotenko and Polubelova (see (Kotenko and Pol-
ubelova, 2011)) applied LTL model checking based
on the classification of Al-Shaer et altera.
FIREMAN. FIREMAN (see (Yuan et al., 2006)) is
a bottom-up approach that relies on incremental up-
dates of sets which are represented by Binary Deci-
sion Diagrams (BDD) while walking along all paths
through the policies and the network configuration.
The absence of cycles is a prerequisite for PA and
FIREMAN because they use lists and trees as mod-
els. Since a cycle check is exponential in space or
time (see (Poole and Mackworth, 2010) p. 6), they
have an exponential flaw. Furthermore, the building
of BDDs has an exponential space complexity.
Jeffrey and Samak. Jeffrey and Samak (see (Jef-
frey and Samak, 2009)) transformed all configura-
tions into a Kripke Structure and applied SAT model
checking. Shadowing and cross-path anomalies are
not supported. In their paper they used a bottom-up
scenario.
In contrast to PA and FIREMAN, Jeffrey and
Samak support only Reachability and Cyclicity. For
a deeper analysis of PA and FIREMAN see (Lorenz,
2014). Jeffrey and Samak’s approach has a very pro-
found theoretical foundation and their model allows
a very natural integration of network scenarios. The
usage of SAT permits profiting from the large efforts
put into solver technologies and the presented runtime
results were encouraging. While this makes it a very
promising candidate for an implementation of policy
anomaly detection for distributed IPv6 firewalls, it did
not support the detection of shadowed rules and cross-
path anomalies.
FirewallBuilder. The FirewallBuilder (see (NetCi-
tadel, 2012)) is an open source tool with a graphical
user interface. It allows both, a top-down approach
by modeling rulesets and networks and a bottom-up
procedure by parsing existing rulesets in various lan-
guages (among others: IPTables, PIX, ASA, PF). It
has a very limited policy anomaly detection support
that allows the detection of shadowed rules. Contrary
to its IPv4 implementation, the tool does not support
address ranges for IPv6 which makes a proper defini-
tion of rules infeasable.
3 MODELLING IPv6 FIREWALLS
This section presents the modelling of IPv6 fire-
walls which follows the previous work of (Jeffrey and
Samak, 2009) for IPv4 firewalls. They support the de-
tection of unreachable rules and cycles. Additionally,
we consider shadowing as clear misconfiguration and
cross-path as potential security threat to be important.
The general approach of Jeffrey and Samak is to
model the firewalls and networks as Kripke Structures
first and transform them into SAT formulas after-
wards. These can be solved by a SAT solver and one
can extract example packets from the results which
exploit a certain anomaly. Also, the results contain
the associated path through the model. If the formula
is not solvable, there exists no such packet and thus
it does not contain the regarded anomaly. The formal
verification workflow is divided into the four phases
Definition, Building, Solving and Reporting. The first
phase includes the definition or adjustment of the fire-
wall policies and the network configuration. Since
our motivation is the support of the migration of net-
works from IPv4 to IPv6 our prototype ad6 imple-
SECRYPT2015-InternationalConferenceonSecurityandCryptography
212
ments a bottom-up strategy. Nevertheless, the archi-
tecture is open for top-down modelling. The build-
ing phase consists of the tasks necessary to abstract
the model from the configuration as Kripke Structure
and to build the SAT formulas for the policy anomaly
detection. These are solved in the following Solving
phase. Finally, the results can be used to generate a
report.
During the introduction of the formal aspects we
will demonstrate their outcome with a small example.
The firewall configuration generated by the script
i p 6 t a b l e s −P OUTPUT DROP
i p 6 t a b l e s −A OUTPUT −p udp −j ACCEPT
i p 6 t a b l e s −A OUTPUT −p t c p −j OUTPUT
inherits a loop. Whenever a TCP packet is handled
the first rule does not match and forwards the packet
to the second rule. Since the filter is correct the packet
is given to the OUTPUT chain where it is handled by
the first rule again. The related decision diagram in
Figure 2 shows this cycle.
3.1 Modelling a Single Firewall
A single firewall is given by the tuple
C = (P , S , γ, δ)
with
• a packet model P ,
• a state model S ,
• a decision function γ : S → B(P × S)
• and a transition relation δ ⊆ S × Bool × S.
The decision function assigns a boolean formula
which represents the matching of a rule body to a
state. The transition relation gives all possible tran-
sitions (s, b, t) between states. Together with the set
of states they form a Kripke Structure with proposi-
tions from the packet model (see (Baier and Katoen,
2008) p.20f for a definition). In this case, the edges
are labeled with boolean values which allows a deter-
ministic transition according to some kind of decision
function.
The packet-field used by the example configura-
tion is the higher protocol field (the next header field
in IPv6) which is 8Bit in size, the packet model can
be defined as
P = {proto
i
= v|i ∈ {0, ..., 7}, v ∈ {0, 1}}
where each bit may have the value 0 or 1. The state
model consists of five states and uses three flags to
indicate the initial, the accept and the drop state
S = {output
0
, output
1
, output
2
, accept
0
, drop
0
,
init, accept, drop}
For the definition of the decision function it is nec-
essary to encode the rules into a SAT representation.
First, the values UDP and TCP can be encoded by
using the binary representation of their protocol val-
ues. For UDP this is 17
10
= 00010001
2
and for TCP
6
10
= 00000110
2
. The propositions of the packet
model are connected as an AND formula for this pur-
pose:
γ(output
0
) =proto
0
= 0 ∧ proto
1
=0 ∧ proto
2
=0∧
proto
3
=1 ∧ proto
4
=0 ∧ proto
5
=0∧
proto
6
=0 ∧ proto
7
=1
γ(output
1
) =proto
0
= 0 ∧ proto
1
=0 ∧ proto
2
=0∧
proto
3
=0 ∧ proto
4
=0 ∧ proto
5
=1∧
proto
6
=1 ∧ proto
7
=0
All other rules are trivially matching and can be rep-
resented as boolean constants:
γ(output
2
) = γ(accept
0
) = γ(drop
0
) = true
Finally, the transition relation can be defined as:
δ = { (output
0
,true,accept
0
),
(output
0
,false,output
1
),
(output
1
,true,output
0
),
(output
1
,false,output
2
),
(output
2
,true,drop
0
)
}
The model itself is easily extensible by increas-
ing the packet or state models. Regarding the chal-
lenges for supporting the bigger IPv6 base-header and
arbitrary header-chains the formalism is expressive
enough. Extending to support the packet model by
one bit introduces two propositions. Therefore, the
packet model grows linearly with the number of bits.
For extension header chains the same principle oc-
curs. For each extension header checked by the fire-
wall the bits that describe the header need to be in-
troduced to the packet model. Therefore, the formal-
ism already covers both challenges. The practical im-
plications, especially if the larger number of proposi-
tions exploits the exponential flaws of SAT, need to be
evaluated experimentally.
3.2 Modelling Networks
We did not modify the modelling of networks as pro-
posed by Jeffrey and Samak. The basic idea is to
model each network node as Kripke Structure and add
states representing incoming and outgoing network
interfaces. These states are connected to the node’s
input, output and forward tables as well as to other
nodes’ network interfaces. For a formal introduction
please refer to (Jeffrey and Samak, 2009) p. 63. Note
PolicyAnomalyDetectionforDistributedIPv6Firewalls
213
that it is possible to introduce nondeterministic be-
haviour by connecting an outgoing network state with
multiple inbound states. For example, this allows to
model wifi networks.
3.3 Kripke Structure
The encoding of the model as Kripke Structure is
done analogously to Jeffrey and Samak’s by con-
structing the formula
trans(C ) =∀(t, c, u) ∈ δ.(
y
(t,c,u)
→ (
(c ↔ trans(t, γ(t)))∧
(trans(t, init) ∨ ∃(s, b, t) ∈ δ.y
(s,b,t)
)
)),
where y
(t,c,u)
is a variable that shows whether the tran-
sition (t, c, u) is true in a run. The implicant of the for-
mula requires that if a transition is true then it must be
motivated. At first, the rule body γ(t) must be evalu-
ated according to the guard value c. This is done by
applying the formula
trans(s, true) = true , trans(s, f alse) = f alse
trans(s, B ∧C) = trans(s, B) ∧ trans(s, C)
trans(s, B ∨C) = trans(s, B) ∨ trans(s, C)
trans(s, ¬B) = ¬trans(s, B)
trans(s, φ) =
φ when φ ∈ P
σ(s, φ) when φ ∈ S
(where σ(s, φ) is true if φ is a proposition of the state
s) which evaluates a boolean formula over atomic
propositions. Afterwards, the state t needs to be
reached. This is the case if either it is an initial state
which is checked by trans(t, init) or it has a predeces-
sor with an outgoing transition (s, b, t) leading to t.
A solution for trans(C ) represents a path through the
model starting at an initial state.
Regarding our example the formula looks like
this:
trans(C ) =(y
(output
0
,true,accept
0
)
→ (
(true ↔ γ(output
0
)) ∧ trans(output
0
, init)
) ∧ (y
(output
0
,false,output
1
)
→ (
(false ↔ γ(output
0
)) ∧ trans(output
0
, init)
) ∧ (y
(output
1
,true,accept
0
)
→ (
(true ↔ γ(output
1
)) ∧ y
(output
0
,false,output
1
)
) ∧ (y
(output
1
,false,output
2
)
→ (
(false ↔ γ(output
1
)) ∧ y
(output
0
,false,output
1
)
) ∧ (y
(output
2
,true,drop
0
)
→ (
(true ↔ γ(output
2
)) ∧ y
(output
1
,false,output
2
)
)
We are now able to further constrain the set of paths
through the model.
3.4 Anomalies
The anomalies discussed in this paper were intro-
duced by different authors. Unreachability and cyclic-
ity were supported by (Jeffrey and Samak, 2009) and
shadowing comes from (Al-Shaer and Hamed, 2004).
The latter anomaly was also supported by (Yuan et al.,
2006) who introduced cross-path as well. In this pa-
per, we adapt shadowing and cross-path to extend the
algorithm of Jeffrey and Samak.
All anomaly encodings follow the same scheme.
They build upon the Kripke Structure encoding and
add the global constraints as well as an anomaly-
specific constraint. All formulas have the form
anomaly(C [, t]) =trans(C )∧
anomaly constraint(C [, t])∧
global constraints(C )
where anomaly constraint∈{reach constraint, cy-
cle constraint, shadow constraint, cross constraint}
and the parameter t applies to reachability and
shadowing.
Reachability. To detect an unreachable state t ∈ S ,
it is sufficient to add a simple constraint
reach constraint(C , t) =∃(s, b, t) ∈ δ.y
(s,b,t)
∨
trans(t, init)
that enforces the existence of an incoming transition.
If it is an initial state, it is reachable by default. Note
that it is necessary to run the detection for each state
of interest. Thus, if all states should be checked the
amount of runs equals the amount of states.
Cyclicity. The detection of cycles needs a constraint
to force the path to be loop-shaped:
cycle constraint(C ) = (
∀(s, b, t) ∈ δ.(y
(s,b,t)
→ ∃(t, c, u) ∈ δ.y
(t,c,u)
)
) ∧ (
∃(s, b, t) ∈ δ.(y
(s,b,t)
∧ trans(s, init))
)
The first part of the constraint ensures that every tran-
sition on the path has a successor which means that
they form a loop. Since the empty path is a trivial so-
lution for first part, the second part ensures that one
of the initial transitions must be true and therefore
enforces a meaningful solution. The original formal-
ism (see (Jeffrey and Samak, 2009) p. 62) allowed the
empty path as trivial solution for cycles.
SECRYPT2015-InternationalConferenceonSecurityandCryptography
214
Shadowing. The shadowing anomaly is caused by
prerequisite rules that filter all packets which are rel-
evant for a subsequent rule. The central constraint is
shadow constraint(C , t) = reach(C , t) ∧ trans(t, γ(t)).
Since an unreachable state t ∈ S is automatically
shadowed, this behaviour is enforced by reusing the
reachability detection as first part of the constraint.
The second part checks upon arrival of the state,
whether there are still packets left that can be matched
by the rule’s body. For shadowed states the same ne-
cessity for multiple runs occurs as for reachability.
Cross-Path. If the Kripke Structure is nondeter-
mistic, which for example can be caused by non-
unique routing in WiFi networks, then a cross-path
anomaly can occur. Depending on the nondeterminis-
tic routing decision the packet can be handled differ-
ently. On one path it is accepted while on another it is
dropped. The constraint is the following:
cross constraint(C ) =
(∃(s, b, t) ∈ δ.(y
(s,b,t)
∧ trans(t, accept)))∧
(∃(s, b, t) ∈ δ.(y
(s,b,t)
∧ trans(t, drop)))
The first part enforces a route to an accepting state
while the second requires a drop. Introduced to the
main formula the conjunction ensures that the con-
straint is met by one single packet.
As our example contains a cycle anomaly we want
to extend the formula with the respective constraint
allowing paths to be loop-shaped only:
cycle
constraintC ) = (y
(output
0
,true,accept
0
)
→ false)∧
(y
(output
0
,false,output
1
)
→ (
y
(output
1
,true,output
0
)
∨ y
(output
1
,false,output
2
)
))∧
(y
(output
1
,true,output
0
)
→ (
y
(output
0
,true,accept
0
)
∨ y
(output
0
,false,output
1
)
))∧
(y
(output
1
,false,output
2
)
→ y
(output
2
,true,drop
0
)
)∧
(y
(output
2
,true,drop
0
)
→ false)∧
(y
(output
0
,true,accept
0
)
∨ y
(output
0
,false,output
1
)
)
The first five implications require every transition to
have a successor. If a path satisfies this constraint,
then it forms a loop. In this example the transi-
tions from output
0
to output
1
(implication 2) and from
output
1
back to output
0
(implication 3) can be set true
while also satisfying their conclusion. The rest of the
implicants can be set false to render their clauses true.
The last line removes the empty path from the solu-
tion space. It is true in this scenario.
The last step for our example is to enforce mu-
tual exclusion for the bits of the packet model. At
this stage it would be possible to i.e. have the propo-
sitions proto
3
= 0 and proto
3
= 1 active at the same
time which is not possible in a real packet. In a net-
work scenario also the occurence of multiple initial
states would need our attention.
3.5 Global Constraints
Bit propositions may occur in three different forms,
namely 0, 1 or don’t care. To ensure mutual exclusion
for every bit proposition there must exist a global con-
straint. This is given by the formula:
global bits(C ) = ∀( f = v) ∈ P .¬(( f = 0) ∧ ( f = 1))
In our example this constraint leads to the formula:
global bits(C ) =¬(proto
0
= 0 ∧ proto
0
= 1)∧
¬(proto
1
= 0 ∧ proto
1
= 1)∧
¬(proto
2
= 0 ∧ proto
2
= 1)∧
¬(proto
3
= 0 ∧ proto
4
= 1)∧
¬(proto
4
= 0 ∧ proto
4
= 1)∧
¬(proto
5
= 0 ∧ proto
5
= 1)∧
¬(proto
6
= 0 ∧ proto
6
= 1)∧
¬(proto
7
= 0 ∧ proto
7
= 1)
Additionally, networks may have undesired be-
haviour if the amount of active init states is not re-
stricted to one. Otherwise multiple paths through the
model may be explored simultaneously. The con-
straint
global inits(C ) =
M
s∈I
(s),
where I ⊆ S is the set of initial states, ensures the lim-
itation of active init states to one (
L
is the cumulative
exclusive-or operator).
By chaining these constraints with AND, they
form a formula
cycle = trans(C )∧cycle constraint(C )∧global bits(C )
that may be transformed into a representation suitable
for a SAT-solver. In many cases this is the conjunc-
tive normal form (CNF). Table 1 shows the solution
assignment for our example. The report includes the
loop-shaped path
output
0
→ output
1
→ output
0
through the model and the packet exploiting this path
including the bits extracted from the variable assign-
ment. It could also be used for an automatically gen-
erated network test. Note that there might be more
than one solution for cycles. Some solvers support
the enumeration of results. This is not feasable for the
cycle detection since the solution space is too large.
PolicyAnomalyDetectionforDistributedIPv6Firewalls
215
For example filter decisions for IPv6 packets are of-
ten based on address prefixes. This leaves the bits
of the postfix as don’t care and thus, makes an enu-
meration exponential in space. All these solutions ap-
ply to the same path and therefore do not improve the
knowledge about the system. A mechanism to further
constrain the formula to forbid already known loops
is out of scope of this paper.
Table 1: Variable assignment that solves the formula for the
cycle detection example.
Variable Value Variable Value
y
(output
0
,true,accept
0
)
false proto
0
= 0 true
y
(output
0
,false,output
1
)
true proto
0
= 1 false
y
(output
1
,true,output
0
)
true proto
1
= 0 true
y
(output
1
,false,output
2
)
false proto
1
= 1 false
y
(output
2
,true,drop
0
)
false proto
2
= 0 true
proto
2
= 1 false
proto
3
= 0 true proto
4
= 0 true
proto
3
= 1 false proto
4
= 1 false
proto
5
= 0 false proto
6
= 0 false
proto
5
= 1 true proto
6
= 1 true
proto
7
= 0 true proto
7
= 1 false
4 IMPLEMENTATION
Our prototype ad6 owns a modular architecture as
shown in Figure 3. The Aggregator uses a parser
for the firewall rulesets which are connected in the
next step to the network configuration. Currently, ad6
supports the rule set of the ip6tables tool (see (Welte
and Ayuso, 2014)). Note that the modular approach
allows to replace the Aggregator with another mod-
ule that allows a top-down modeling. The Instan-
tiator consists of a set of libraries to build Kripke
Structures from configurations and a procedure to
transform them to basic SAT formulas consisting of
trans(C ) and the global constraints. Also the transfor-
mation to CNF is performed here. Afterwards, they
are enriched with the anomaly specific part and solved
by a standard SAT-solver interfaced with an adapter.
Both utilized solvers, MiniSAT (see (Een and Sorens-
Main
Instantiator
Parser &
Aggregator
Solver Reporting
ad6
Redis MiniSAT Clasp
Figure 3: Architecture of ad6.
son, ) and Clasp (see (Kaufmann et al., 2012), lack
a native interface for Python which was the main im-
plementation language. Thus, a workaround for an
adapter including the fork of a subprocess as well as
reading from and writing to files was developed.
Intermediate results of the building process (i.e.
transition encodings of the Kripke Structure) are
stored in a database. So, if a rule is changed, (large)
parts of the Kripke Structure can be reused which
should have a positive effect on the performance. A
scenario where this might be useful applies if an ad-
ministrator changes the input configuration (i.e. by
removing a rule) where most formula parts remain
untouched. We utilized the Redis NoSQL-database
(see (Pivotal Software, 2014)) which is an in-memory
key-value store with a native Python interface.
5 EVALUATION
This section presents the evaluation of ad6. It was
evaluated for different workloads to investigate the
scalability of the presented approach. We measured
the runtime of the different phases, i.e. building and
solving phase, separately. The building phase which
is performed by the Instantiator includes all activi-
ties necessary to provide the formulas that should be
checked in the solving phase. Further, we used two
different solvers, MiniSAT and Clasp.
5.1 Workload and Testbed Description
Table 2 shows the parameters of the tested workloads.
The small workload represents a firewall of a single
multi-service host typical for a small business server
(45 rules). The medium size was inspired by our uni-
versity campus and represents a gateway firewall of
a large organization separating several subnets, hosts,
and services (721 rules). The large configuration in-
cludes the medium and several instances of the small
workload organized in subnets like a DMZ and net-
works of organizational subunits (2044 rules). The
network graph of this scenario is shown in Figure 4.
The corresponding rule sets aimed to be free of
anomalies, but included rules concerning extension
headers which have a share of about 11% for the
small, 0.7% for the medium and 8% for the large
workload. Our firewall policies follow the exemplary
ruleset of the IDSv6 project (see (IDSv6-Project,
2013)).
All measurements were performed on a single ma-
chine. Table 3 shows its technical details. Since ad6 is
implemented single threaded, there are enough cores
SECRYPT2015-InternationalConferenceonSecurityandCryptography
216
2001:abc:def::0/48 gateway
DMZ
clients
sub1
sub24
prex:1::0/64
prex:3::0/64
prex:2::0/64
prex:18::0/64
server clients
server clients
server client
server clientdnsvpn db admin
ldap
web
maille
prex:1::1
prex:1::2
prex:1::3
prex:1::4
prex:1::5
prex:1::6
prex:1::7
prex:1::8
prex:2:1::1 prex:2:1::2
prex:18::1 prex:1018::1
prex:3::1
prex:1003::1
Internet
...
Figure 4: Network topology that forms the basis of the workload. The network prefix is 2001:abc:def::0/48
Table 2: Workload parameters.
workload Rules Kripke Nodes Transitions
small 45 51 84
medium 721 732 1435
large 2044 2328 4097
Table 3: Technical details of the test machine.
CPU Intel i7-3630QM
# of Cores 4
Frequency 2.4GHz
RAM 8GB
OS Arch Linux
Kernel v3.16.2
Python v3.4.1
Redis v2.8.17
MiniSAT v2.2.0
Clasp v3.0.3
left to serve the database and the operating system
without interference.
5.2 Experimental Results
Figure 5 shows the total runtime results for the three
workloads. For each workload, the runtimes for the
different solvers MiniSAT and Clasp are given. Fur-
ther, the runtime of the building phase is given titled
FirstUse.
The intermediate results were finite and steady
with a very low standard deviation. This shows that
the risk of an exponential runtime due to the IPv6
challenges did not occur. Comparing the two solvers,
the runtimes are very similar.
While the total runtime of ad6 (FirstUse plus
solving time) is about 3 seconds for the small
workload, it is 239 seconds for the medium, and
about 37 min for the large rule set. If fit to a quadratic
curve f (x) = ax
2
+ bx + c, the coefficients are
phase a b c
building (FirstUse) 0.0002 -0.06 3.54
solving (Clasp) 0.0004 -0.04 2.85
where x is the number of rules in the input. For
a workload of 3000 rules the estimated runtime is
about 85 min with 27 min for the building and 58 min
for the solving phases. Nevertheless, the performance
behaves clearly superlinear but subquadratic and has
further potential for improvement since the current
implementation is still a prototype.
The major delay is caused by the anomalies reach-
ability and shadowing. Contrary to cycles and cross-
path anomalies which need a single run to be detected
globally they need to be checked nodewise. This in-
cludes the appending of the rule specific constraint
to the base formula (consisting of trans(C ) and the
global constraints) and a solver run. The total number
of runs can be quantified by the formula f (x) = 2x +2
where x is the number of Kripke Nodes. The other
factor influencing the total runtime is the size of the
base formula that causes every run to be longer. The
formula grows with every transition introduced to the
Kripke Structure. As a rule of thump one can say
that most new rules introduce two transitions. One
is taken when the rule matches and the other if not.
Taking both factors into consideration the complexity
of the algorithm is quadratic. To increase the applica-
bility further improvements or even another approach
for these time intensive anomalies are required.
Reuse of Formula: The building phase includes
all activities necessary to provide the formulas that
should be checked in the solving phase. A potential
improvement lays in the reuse of formula parts from
previous runs. This includes all formulas for transi-
tions and rule matching in conjunctive normal form.
In our tests we wanted to quantify the maximal possi-
ble gain of reusage. We enforced this by not changing
any rule after the first run so all formula parts could
be fetched from the database. Figure 5 shows that the
PolicyAnomalyDetectionforDistributedIPv6Firewalls
217
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
2
FirstUse Reuse MiniSAT Clasp
Runtime (in s)
(a) small
60
80
100
120
140
160
180
200
FirstUse Reuse MiniSAT Clasp
Runtime (in s)
(b) medium
0
200
400
600
800
1000
1200
1400
1600
1800
FirstUse Reuse MiniSAT Clasp
Runtime (in s)
(c) large
Figure 5: Total runtimes of the different phases for each workload (in s).
differences between the first use and the reuse during
the building and solving phase are negligible. In that
regard, the most surprising effect is the slightly worse
performance of the reuse of formula parts compared
to a complete rebuild. The database overhead seems
to superseed the benefits. Concerning the migration
from IPv4 to IPv6 this circumstance is not relevant
since the policy anomaly detection is applied once af-
ter the migration.
RAM Consumption: Modern SAT solvers can
handle millions of different boolean variables and are
typically just limited by memory. Normally, the pol-
icy anomaly detection should not exceed this limita-
tion since packet models are rather small depending
on the size of the header chain. The other factor is
the size of the Kripke Structure. Both did not ex-
ceed 10000 propositions in our workload. To quantify
the memory behaviour we periodically measured the
RAM consumption. It was very stable and varied be-
tween 55MB and 322MB. Therefore, the memory is
not regarded as bottleneck for the overall scalability.
5.3 Discussion
The average solving time lays in the same order
of magnitude like the results of Jeffrey and Samak
(see (Jeffrey and Samak, 2009) p.65). Their consider-
ably low initialization runtime includes only the cre-
ating of the model and the base instance without its
conversion to CNF. While Jeffrey and Samak test only
reachability and cyclicity, the presented approach is
also able to test shadowing and cross-path. The dif-
ference would most likely tighten, if native interfaces
for the solvers would be available for ad6.
The building and checking of a large configura-
tion had a total duration of about 37min. Whether
this is acceptable, depends on the use case scenario.
For the migration of IPv4 networks to IPv6, the long
runtime does not matter since the policy anomaly de-
tection is only performed once. Also, classical net-
work setups tend to be relatively static and therefore,
have very few rule changes if no automatic rule gen-
eration mechanisms (i.e. for some UDP services) are
present. On the other hand, very dynamic environ-
ments like Software Defined Networks (SDN) would
require periodic checking.
6 CONCLUSION AND FUTURE
WORK
The main contribution of this paper is the proof that
model checking techniques can also be applied suc-
cessfully for IPv6 firewalls to detect anomalies. The
presented approach is based on the algorithm of Jef-
frey and Samak to test reachability and cyclicity. Ad-
ditionally, we have extended the concept to also detect
shadowing and cross-path. The presented prototype,
the policy anomaly detector ad6, is a useful tool to
increase the semantical assurance of IPv6 firewalls.
The impact of larger addresses and therefore more
boolean variables in the encoding were evaluated ex-
perimentally and did not show the potential exponen-
tial behaviour. Also, it was shown that IPv6 exten-
sion header chains do not break the applicability of
the formalism but may cause a massive but still lin-
ear growth of propositions in the formula. This would
also apply to any other extensional protocol support
and, in a limited way, already occured in the original
algorithm with IPv4 options.
The overall performance of the prototype ad6 is
sufficient for the network migration use case and al-
lows a regular inspection of its sanity. For fast con-
figuration changes, as they may appear in SDN, the
checking cannot be performed rapidly or even in real-
time. But there is much potential for improvements in
the prototype implementation.
Apart from the enhancement of the code quality
and the implementation of native interfaces for the
solvers, there are further improvements intended:
• Learning from intermediate results - The time in-
tensive task of checking for unreachability and
shadowing can be improved by learning from in-
termediate results. So, all nodes that lay on a path
to a reachable rule are reachable as well. Also,
SECRYPT2015-InternationalConferenceonSecurityandCryptography
218
unreachable rules are shadowed by default. The
respective checks for these rules can be skipped.
This is also true for initial rules which are always
reachable and unshadowed.
• Parallelization - The overall performance can be
improved by parallelizing parts of the application.
Especially, the building and solving of unreacha-
bility and shadowing formulas is completely in-
dependent and can be processed in parallel. Also,
parts of the building process may be parallelized
as well.
• Expressiveness - There are further interesting fea-
tures for the policy anomaly detection like the
support for stateful firewalling or the considera-
tion of effects introduced by VPN-tunnels.
REFERENCES
Abedin, M., Nessa, S., Khan, L., and Thuraisingham, B. M.
(2006). Detection and Resolution of Anomalies in
Firewall Policy Rules. In Data and Applications Secu-
rity, 20th Annual IFIP WG 11.3 Working Conference
on Data and Applications Security 2006, Proceedings,
pages 15–29.
Al-Shaer, E. S. and Hamed, H. H. (2003). Firewall Pol-
icy Advisor for Anomaly Discovery and Rule Edit-
ing. In Integrated Network Management VII, Manag-
ing It All, IFIP/IEEE Eighth International Symposium
on Integrated Network Management (IM 2003), pages
17–30.
Al-Shaer, E. S. and Hamed, H. H. (2004). Discovery of
Policy Anomalies in Distributed Firewalls. In INFO-
COM 2004. Twenty-third AnnualJoint Conference of
the IEEE Computer and Communications Societies,
volume 4, pages 2605–2616.
Arkko, J. and Baker, F. (2011). Guidelines for Using
IPv6 Transition Mechanisms during IPv6 Deploy-
ment. RFC 6180.
Baier, C. and Katoen, J.-P. (2008). Principles of model
checking. The MIT Press.
Biere, A., Heljanko, K., Junttila, T. A., Latvala, T., and
Schuppan, V. (2006). Linear Encodings of Bounded
LTL Model Checking. Logical Methods in Computer
Science, 2(5).
Biondi, P. and Ebalard, A. (2006). Scapy and IPv6 network-
ing. Slides from http://www.secdev.org/conf/scapy-
IPv6 HITB06.pdf.
Caicedo, C. E., Joshi, J. B., and Tuladhar, S. R. (2009). IPv6
Security Challenges. Computer, 42(2):36–42.
Cook, S. A. (1971). The Complexity of Theorem-Proving
Procedures. Technical report, University of Toronto.
Een, N. and Sorensson, N. A minimalis-
tic and high-performance SAT solver.
https://github.com/niklasso/minisat.
Emerson, E. A. and Halpern, J. Y. (1986). ”Sometimes”
and ”Not Never” revisited: on branching versus linear
time temporal logic. Journal of the Association for
Computing Machinery (JACM), 33(1):151–178.
Golnabi, K., Min, R., Khan, L., and Al-Shaer, E. (2006).
Analysis of Firewall Policy Rules Using Data Min-
ing Techniques. In Network Operations and Manage-
ment Symposium, 2006. NOMS 2006. 10th IEEE/IFIP,
pages 305–315.
Google (2015). Google IPv6 - Statistics.
https://www.google.com/intl/en/ipv6/statistics.html.
IDSv6-Project (2013). Exemplary ip6tables init script.
http://www.idsv6.de/Downloads/iptables ruleset.sh.
Jeffrey, A. and Samak, T. (2009). Model Checking Fire-
wall Policy Configurations. In POLICY, pages 60–67.
IEEE Computer Society.
Kaufmann, B., Schaub, T., and et. al. (2012). A
conflict-driven nogood learning answer set solver.
http://www.cs.uni-potsdam.de/clasp/.
Kotenko, I. and Polubelova, O. (2011). Verification of secu-
rity policy filtering rules by Model Checking. In IEEE
6th International Conference on Intelligent Data Ac-
quisition and Advanced Computing Systems: Technol-
ogy and Applications, IDAACS 2011, Prague, Czech
Republic, September 15-17, 2011, Volume 2, pages
706–710. IEEE.
Kozen, D. (1983). Results on the Propositional mu-
Calculus. Theor. Comput. Sci., 27:333–354.
Kripke, S. (1963). Semantical Considerations on Modal
Logic. Acta Philosophica Fennica, 16:83–94.
Lorenz, C. (2014). Paper Discussion: Policy Ad-
visor and FIREMAN. Technical report,
University of Potsdam. http://www.cs.uni-
potsdam.de/bs/research/docs/techreports/2014/l14.pdf.
NetCitadel (2012). FirewallBuilder. www.fwbuilder.org.
Pivotal Software (2014). Redis Documentation.
http://redis.io/documentation.
Pnueli, A. (1977). The Temporal Logic of Programs. In
18th Annual Symposium on Foundations of Computer
Science, Providence, Rhode Island, USA, 31 October
- 1 November 1977, pages 46–57. IEEE Computer So-
ciety.
Poole, D. and Mackworth, A. (2010). Lecture
3.2 on Artificial Intelligence. Slides from
http://artint.info/slides/ch03/lect2.pdf.
Welte, H. and Ayuso, P. N. (2014).
The netfilter.org ”iptables” project.
http://www.netfilter.org/projects/iptables/.
Yuan, L., Mai, J., Su, Z., Chen, H., Chuah, C.-N., and Mo-
hapatra, P. (2006). FIREMAN: A Toolkit for FIRE-
wall Modeling and ANalysis. In IEEE Symposium on
Security and Privacy, pages 199–213. IEEE Computer
Society.
PolicyAnomalyDetectionforDistributedIPv6Firewalls
219
