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