Towards a Lightweight Model of
BGP Safety
Matvey Arye
Princeton University
Joint work with:
Rob Harrison, Richard Wang, Jennifer Rexford (Princeton)
Pamela Zave (AT&T Research)
Why is BGP important
Internet is a network of networks – autonomous
systems
BGP is the routing protocol between AS’s
AS Preferences in BGP
Each AS has a significant amount of freedom in
choosing routes
1
D
3
2
Node 1 may prefer the purple path over the orange
path to node D
BGP Convergence
• An “Instance” is a topology and a set of AS preferences
• Some instances don’t converge (called Gadgets)
– BGP’s routing protocol can oscillate.
• Finding gadgets is hard and has previously been done
by hand
• We use lightweight modeling to automate gadget
generation and analysis
Why Lightweight Model
• Formal modeling aids analysis
– Requires rigorous definition of concepts
• Encoded in a way that is “shareable” between researchers
– Automates analysis
• Lightweight modeling is easier
– Small model of key concepts
– Easier to develop than machine-verified proofs
– Push-button analysis
Stable Path Problem
• Useful Model
– Although static formulation of the BGP, captures
important properties:
• SPP that is “solvable” is a prerequisite for BGP convergence
• Although doesn’t capture dynamic properties fully
– Extensively Studied
• Used in proofs of a lot of previous work
• Our model of SPP (almost) as compact as original
description
• Automatically finding gadgets hard in SPP
Alloy
• Wanted a tool to help us generate SPP gadgets
• Alloy is a declarative modeling language
– Can test assertions on predicates
• Compiles to SAT problem
– SAT solvers are fast (on a lot of cases)
• Given a set of predicates, 2 answers:
– Satisfiable
– Unsatisfiable & Counterexample
Explore All Small SPP Instances
• Small instances are often informative
– SPP gives each node a lot of degrees of freedom
• So properties of small instances are often interesting
• And often generalize to larger ones
– Counterexamples to assertions really useful
• Explores full search space
– Can make generalized assertions
• Although only up to a certain size
Contributions
• Created lightweight model of SPP
– Model very compact, machine and human readable
– Full model in the paper
• Automatically generated unstable SPP gadgets
– Bad Gadget, Disagree, many more
• Classified gadgets
– Full list of interesting gadgets under 4 source nodes
• Verified new and known solvability predicates
– “Absence of dispute wheel implies solvability”
Outline
• Review of SPP and Model
• Use 1: Gadget Generation
• Use 2: Test Known Solvability Predicates
• Discuss Future Work
SPP Topology
Source Node
1
Destination Node
D
3
2
SPP Permitted Paths
1
1d
12d
13d
D
3
2
List of
Permitted
Paths
Representation In Alloy
• DstNode, SrcNode: Node
D
• Path: Sequence of Nodes
– Sequence is an ordered list
1
21d
• SrcNode.PermittedPaths: Sequence of Paths
– First path in list most preferred
1d
13d
Ensure Valid Topology with Facts
• Facts define correctness of construction
– Assertions only run on correct constructions
• Example: ValidNonEmptyPath
– Sequence has at least one element
– No node appears more than once
– Last node is DstNode
• Many more…
SPP Selection
1
1d
12d
13d
D
32d
31d
3d
3
2
Each node selects exactly one path
21d
2d
SPP Solution
1
1d
12d
13d
D
32d
31d
3d
3
2
21d
2d
All nodes happy with their selection simultaneously
Individual Happiness
(within constraints)
• Solution
– Each node has selected the best of its choices.
• Why?
– No node can pick a better choice.
Pred SelectionIsSolution[selected]
{
let choices = GetChoices[selected] |
selected = GetBest[choices]
}
Constraint Dependencies
Choices
Node 1
Selection
Node 1
Selection
Node 2
Choices
Node 2
SPP as a Model
• Each SPP instance has 0, 1, or 1+ solutions
• Having exactly 1 solution is necessary but not
sufficient for safety.
All Instances
1 SPP Solution
Safety
Specify Solvability Predicate
Logically,
Pred OneSolvable:
one selection where SelectionIsSolution
Pred MultiSolvable:
some selection where SelectionIsSolution
Aside:
• Selection is a set
– Quantifying over it requires 2nd order logic
– Hard-code quantifications on a set-size basis for 1st order
No Solution (Bad Gadget)
1
12d
1d
D
31d
3d
3
2
23d
2d
Two Solutions (Disagree)
1
12d
1d
D
3d
3
2
21d
2d
Analysis Using the Model
• We know “all instances are one solvable” is
incorrect
=> We use Alloy to give us example instances
where predicate fails.
• Use model to test solvability predicates
– “absence of dispute wheel implies one solvable”
Use 1: Generating Counterexamples
• Have Alloy Generate Counter Examples
– Gadgets with no (multiple) solutions
– Too Many (10000+ for 4 source nodes)
• Want Interesting Counterexamples
Interesting Gadget
1
12d
1d
D
31d
3d
3
2
23d
2d
Uninteresting Gadget
1
12d
1d
13d
D
31d
3d
3
2
23d
2d
Gadget Generation
• Intuitively, small gadgets are most interesting
• Start small
– Find all gadgets for size
• Size++
• When analyzing bigger gadgets, exclude
gadgets similar to those already found
Gadget Library
pred Gadget123{
}
Predicate detects gadgets similar to the gadget found
• Makes path rankings relative
• Corrects for isomorphic reordering of node #s
Eliminate gadgets matching library predicates in future
Gadgets Found
Unsolvable Gadgets
()*
(*
"
()*
(*
"
#
$
%
$
#
$
$
+( *
+*
(, *
(*
+) ( *
+*
#
"
$
+( *
+*
) +*
)*
)(*
(, *
(*
) +*
)*
)(*
%
"
&
#
, +*
,+)*( *
+*
%
&
, +*
,*
(, )*
()*
"
)*
(, )*
()*
$
%
"
$
$
#
+( ) *
+*
&
#
, +*
, )*
+( ) *
+*
(, )*
()*
#
+( ) *
+) *
()*
(*
%
"
&
#
, +) *
)*
,+() *
+) *
) +, *
()*
(*
%
&
, +) *
, )*
) +, *
)*
"
#
+( *
+, *
%
"
&
#
,*
+( *
+, *
%
&
"
$
$
( , )) **
()*
! "# $$%"# %&'
%
! "# $$%"# %&'
( +*
(*
"
#
+( *
+*
#
+( *
+*
)*
' ()!*%
+,- ./ (0.1!2 (3415
& ,
, +*
, )*
Multiply Solvable Gadgets
( +*
(*
'#()!* +,-+)./((0.1!2
(3415
*
( +* ,
"
+*
()*
+) ( *
+*
( +*
()*
"
$
( +*
(*
"
)*
( +*
(*
$
+( ) *
+*
( +) *
()*
"
#
+( ) *
+*
( +) *
()*
"
$
#
"
#
%
$
)(*
%
$
)(*
"
%
$
#
+( ) *
+) *
#
+( ) *
+) *
$
)*
)*
%
$
# -. "%/ &&
$
$
%
$
# -. "%/ &&
(), *
(*
"
$
#
), *
(), *
(*
%
"
&
#
+( *
( ) +*
(, *
"
, +( *
+(
, **
) +*
( ) +*
(, *
%
"
, +( *
,*
) +*
!
#
&
#
+( , *
+*
(*
,*
+( , *
+*
) , +*
)( *
"
#
()*
(*
"
, )(*
, +*
+*
) +*
()*
(*
, )(*
, +*
) +*
)*
+*
$
%
"
&
#
' 0)!6 7.589.:, *!; - ./ (0.1!2
) , +*(3415,
)(*
&
%
&
)*
%
$
#
+, *
+*
%
"
&
#
, (*
,+,* *
+*
%
&
, (*
,*
$
!
), *
%
!
$
)*
&
%
!
,*
Use 2: Evaluating Constraints
• Test Known Constraints
• Example: Create predicates for the dispute wheel
– Verify “absence of a DW implies solvability”
– Get instances that have a DW but are still solvable
• Quickly explore new conditions for solvability
– See if they are sufficient or necessary
– Get counterexamples of how they don’t fully capture
solvability
Conclusion
• Created a lightweight model of BGP
• Used model to generate gadgets
• Used iterative elimination to get minimal set of
interesting gadgets
• Model could be used for quick “push button”
analysis of new constraints
Future Work
• Develop new solvability predicates and model
existing ones
• Apply the model to checking BGP router
configurations for solvability
• Model the dynamic SPVP
Thanks