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)
Internet is a network of networks – autonomous systems BGP is the routing protocol between AS’s Why is BGP important
Each AS has a significant amount of freedom in choosing routes Node 1 may prefer the purple path over the orange path to node D AS Preferences in BGP D 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 D D Source Node Destination Node
SPP Permitted Paths D D 1d 12d 13d List of Permitted Paths
Representation In Alloy DstNode, SrcNode: Node Path: Sequence of Nodes – Sequence is an ordered list SrcNode.PermittedPaths: Sequence of Paths – First path in list most preferred 1 1 D D 1d 13d 21d
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 D D 1d 12d 13d 21d 2d 32d 31d 3d Each node selects exactly one path
SPP Solution D D 1d 12d 13d 21d 2d 32d 31d 3d 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 2 Selection Node 1 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 2 nd order logic – Hard-code quantifications on a set-size basis for 1 st order
No Solution (Bad Gadget) D D 12d 1d 23d 2d 31d 3d
Two Solutions (Disagree) D D 12d 1d 21d 2d 3d
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 ( for 4 source nodes) Want Interesting Counterexamples
Interesting Gadget D D 12d 1d 23d 2d 31d 3d
Uninteresting Gadget D D 12d 1d 13d 23d 2d 31d 3d
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 Multiply Solvable Gadgets
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