Polynomial-Time What-If Analysis for Prefix-Manipulating MPLS Networks

Transcription

1 Polynomial-Time What-If Analysis for Prefix-Manipulating MPLS Networks Stefan Schmid University of Vienna, Austria and Segment Routing!... Jiri Srba Aalborg University, Denmark

2 Polynomial-Time What-If Analysis for Prefix-Manipulating MPLS Networks Stefan Schmid University of Vienna, Austria Jiri Srba Aalborg University, Denmark Teaser: Can we verify reachability under k failures without trying exponentially many options? Yes. MUCH FASTER!

3 Polynomial-Time What-If Analysis for Prefix-Manipulating MPLS Networks Stefan Schmid University of Vienna, Austria Jiri Srba Aalborg University, Denmark Teaser: Can we verify reachability under k failures without trying exponentially many options? Yes. MUCH FASTER! An Automata-Theoretic Approach

4 Polynomial-Time What-If Analysis for Prefix-Manipulating MPLS Networks Stefan Schmid University of Vienna, Austria Jiri Srba Aalborg University, Denmark Kudos to collaborators: Jesper Stenbjerg Jensen, Jonas Sand Madsen, Troels Beck Krøgh at Aalborg University, Denmark

5 Configuring Networks is Hard Datacenter, enterprise, carrier networks: mission-critical infrastructures. But even techsavvy companies struggle to provide reliable operations. We discovered a misconfiguration on this pair of switches that caused what's called a bridge loop in the network. A network change was [ ] executed incorrectly [ ] more stuck volumes and added more requests to the re-mirroring storm Service outage was due to a series of internal network events that corrupted router data tables Experienced a network connectivity issue [ ] interrupted the airline's flight departures, airport processing and reservations systems Credits: Nate Foster 1

6 Datacenter Especially Under Failures Example: BGP in Datacenter Internet X Y C D G H A B E F G1 G2 P1 P2 Credits: Beckett et al. (SIGCOMM 2016): Bridging Networkwide Objectives and Device-level Configurations. 2

7 Datacenter Especially Under Failures Example: Cluster BGP with in Datacenter services that should be globally reachable. X Internet Y Cluster with services that should be accessible only internally. C D G H A B E F G1 G2 P1 P2 Credits: Beckett et al. (SIGCOMM 2016): Bridging Networkwide Objectives and Device-level Configurations. 2

8 Datacenter Especially Under Failures X and Y announce to Internet what is from G* (prefix). Example: BGP in Datacenter Internet X and Y block what is from P*. X Y C D G H A B E F G1 G2 P1 P2 Credits: Beckett et al. (SIGCOMM 2016): Bridging Networkwide Objectives and Device-level Configurations. 2

9 Datacenter Especially Under Failures X and Y announce to Internet what is from G* (prefix). Example: BGP in Datacenter Internet X and Y block what is from P*. X Y C D G What can go wrong? H A B E F G1 G2 P1 P2 Credits: Beckett et al. (SIGCOMM 2016): Bridging Networkwide Objectives and Device-level Configurations. 2

10 Datacenter Especially Under Failures X and Y announce to Internet what is from G* (prefix). Example: BGP in Datacenter Internet X and Y block what is from P*. X Y C D G H If link (G,X) fails and traffic from G is rerouted via A Y and BC to X: X announces E (does F not block) G and H as it comes from C. (Note: BGP.) G1 G2 P1 P2 Credits: Beckett et al. (SIGCOMM 2016): Bridging Networkwide Objectives and Device-level Configurations. 2

11 Network Administration Today Policy ok? A B C Many forwarding tables with many rules, distributed across network Sysadmin responsible for: Reachability: Can traffic from ingress port A reach egress port B? Loop-freedom: Are the routes implied by the forwarding rules loop-free? Non-reachability: Is it ensured that traffic originating from A never reaches B? Waypoint ensurance: Is it ensured that traffic from A to B is always routed via a node C (e.g., a firewall)? 3

12 Network Administration Today Policy ok? A B C Many forwarding tables with many rules, distributed across network Sysadmin responsible for: Reachability: Can traffic from ingress port A reach egress port B? Loop-freedom: Are the routes implied by the forwarding rules loop-free? Non-reachability: Is it ensured that traffic originating from A never reaches B? Waypoint ensurance: Is it ensured that traffic from A to B is always routed via a node C (e.g., a firewall)? 3

13 Network Administration Today What if...?! A B C Many forwarding tables with many rules, distributed across network Sysadmin responsible for: Reachability: Can traffic from ingress port A reach egress port B? Loop-freedom: Are the routes implied by the forwarding rules loop-free? Non-reachability: Is it ensured that traffic originating from A never reaches B? Waypoint ensurance: Is it ensured that traffic from A to B is always routed via a node C (e.g., a firewall)? even under (multiple) failures! 3

14 Network Administration Today k failures = ( n k ) possibilities A B C Many forwarding tables with many rules, distributed across network Sysadmin responsible for: Reachability: Can traffic from ingress port A reach egress port B? Loop-freedom: Are the routes implied by the forwarding rules loop-free? Non-reachability: Is it ensured that traffic originating from A never reaches B? Waypoint ensurance: Is it ensured that traffic from A to B is always routed via a node C (e.g., a firewall)? even under (multiple) failures! 3

15 The Good News Networks are becoming more programmable and logically centralized, have open interfaces, are based on formal foundations researchers develop high-level specification languages such as NetKAT. Enables a more automated network operation and verification! 4

16 The Bad News For many traditional networks (still predominant!), such benefits are not available yet Many existing tools cannot deal with failures Super-polynomial runtime, verification PSPACE-hard Other limitations: e.g., fixed header size 4

17 Tractability of Verification Reachability is undecidable in SDN: Can emulate a Turing machine. Self-loop: could be replaced by dummy switch. in out in out 5

18 Tractability of Verification Reachability is undecidable in SDN: Idea: packet header stores Can emulate a Turing machine. Turing machine configuration (tape, head, state). in out in out 5

19 Tractability of Verification Reachability is undecidable in SDN: Can emulate a Turing machine. in out in out Switch action: each time packet arrives, performs one Turing machine step and updates header. 5

20 Tractability of Verification Reachability is undecidable in SDN: Can emulate a Turing machine. in Only if accept or reject, forwarded to out. Is it ever reached? Undecidable! out in out 5

21 Our Contribution Polynomial-Time What-if Analysis for Prefix Rewriting Networks 6

22 Our Contribution Independently of the number of failures! No need to try combinations. Reachability, loopfreedom, waypointing, etc.! Polynomial-Time What-if Analysis for Prefix Rewriting Networks e.g., MPLS networks or Segment Routing networks Support arbitrary header sizes! 6

23 MPLS Networks MPLS: forwarding based on top label of label stack in v 1 v 2 v 3 v 4 out 1 in 2 22 v 5 v 6 v 7 v 8 out 2 Default routing of two flows 7

24 MPLS Networks MPLS: forwarding based on top label of label stack push swap swap pop in v 1 v 2 v 3 v 4 out 1 in 2 22 v 5 v 6 v 7 v 8 out 2 Default routing of two flows pop 7

25 MPLS Networks MPLS: forwarding based on top label of label stack in v 1 v 2 v 3 v 4 out 1 in 2 22 v 5 v 6 v 7 v 8 out 2 Default routing of two flows 7

26 MPLS Networks: 1 Failure MPLS: forwarding based on top label of label stack in v 1 v 2 v 3 v 4 out 1 in 2 22 Default routing of two flows v 5 v 6 v 7 v 8 out 2 For failover: push and pop label in 1 12 v 1 v 2 v 3 v 4 out 1 in v 5 v 6 v 7 v 8 21 out 2 One failure: push 30: route around (v 2,v 3 ) 8

27 MPLS Networks: 1 Failure MPLS: forwarding based on top label of label stack in v 1 v 2 v 3 v 4 out 1 in 2 22 Default routing of two flows If (v 2,v 3 ) vfailed, 5 v 6 v 7 v 8 out 2 push 30 and forward to v 6. For failover: push and pop label in 1 12 v 1 v 2 v 3 v 4 out 1 in 2 Normal swap v 5 v 6 v 7 v 8 21 Pop out 2 One failure: push 30: route around (v 2,v 3 ) 8

28 MPLS Networks: 1 Failure MPLS: forwarding based on top label of label stack in v 1 v 2 v 3 v 4 out 1 in 2 22 Default routing of two flows If (v 2,v 3 ) vfailed, 5 v 6 v 7 v 8 out 2 push 30 and forward to v 6. What about multiple link failures? For failover: push and pop label in 1 12 v 1 v 2 v 3 v 4 out 1 in 2 Normal swap v 5 v 6 v 7 v 8 21 Pop out 2 One failure: push 30: route around (v 2,v 3 ) 8

29 MPLS Networks: 2 Failures in v 1 v 2 v 3 v 4 out 1 in 2 22 Original Routing v 5 v 6 v 7 v 8 out 2 in v 1 v 2 v 3 v 4 out 1 in v 5 v 6 v 7 v out 2 in Push v40 1 v 2 v 3 v 4 out 1 in v 5 v 6 v 7 v Push 30 out 2 One failure: push 30: route around (v 2,v 3 ) Two failures: first push 30: route around (v 2,v 3 ) Push recursively 40: route around (v 2,v 6 )

30 MPLS Networks: 2 Failures in v 1 v 2 v 3 v 4 out 1 in 2 22 Original Routing v 5 v 6 v 7 v 8 out 2 in v 1 v 2 v 3 v 4 out 1 in v 5 v 6 v 7 v in Push v40 1 v 2 v 3 v 4 out 1 in v 5 v 6 v 7 v Push 30 out 2 One failure: push 30: route around (v 2,v 3 ) out But masking links one-byone can be inefficient: 2 (v 7,v 3,v 8 ) could be shortcut to (v 7,v 8 ). Two failures: first push 30: route around (v 2,v 3 ) Push recursively 40: route around (v 2,v 6 )

31 MPLS Networks: 2 Failures in v 1 v 2 v 3 v 4 out 1 in 2 22 v 5 v 6 v 7 v 8 out 2 in v 1 v 2 v 3 v 4 out 1 in v 5 v 6 v 7 v in Push v40 1 v 2 v 3 v 4 out 1 in v 5 v 6 v 7 v Push 30 out 2 Original Routing More efficient but also more complex! How complex? One failure: push 30: route around (v 2,v 3 ) out But masking links one-byone can be inefficient: 2 (v 7,v 3,v 8 ) could be shortcut to (v 7,v 8 ). Two failures: first push 30: route around (v 2,v 3 ) Push recursively 40: route around (v 2,v 6 )

32 Forwarding Tables for Our Example Protected link Alternative link Label Failover Tables Flow Table 10

33 Polynomial-Time Verification: An Automata-Theoretic Approach What if...?! Compilation Interpretation px qxx px qyx qy ryy ry r rx px MPLS configurations, Segment Routing etc. Pushdown Automaton and Prefix Rewriting Systems Theory 11

34 Polynomial-Time Verification: Use cases: Sysadmin issues queries An Automata-Theoretic test certain properties, Approach or do it on a regular basis automatically! What if...?! Compilation Interpretation px qxx px qyx qy ryy ry r rx px MPLS configurations, Segment Routing etc. Pushdown Automaton and Prefix Rewriting Systems Theory 11

35 Questions with Answers in Polynomial Time Interface Connectivity Problem Can a packet arriving at interface A with label-stack header h reach an interface B, assuming that at most k links fail at the same time? Does the route avoid a given set of nodes? Push/pop/ swap Blacklisted: avoid D B Will the packet always traverse a given waypoint? A What subset of headers guarantees that a given interface is not reachable under at most k link failures? And everything for up to k failures! Label stack: C: with firewall Waypoint: use! 12

36 Questions with Answers in Polynomial Time Transparency MPLS: transit networks! B Label stack: empty? Will a packet with empty labelstack arriving at ingress interface A always leave at egress interface B also with the empty label-stack? Label stack: empty A Also under k failures? Cyclic and repeated routing Will some server receive a given packet more than r-times during the routing? What is the max stack size during the routing? Under failures as well A B Label stack: size? 13

37 Our Approach The clue: exploit the specific structure of MPLS rules OpenFlow rules: arbitrary rewriting in x L* out x L* vs Header size not fixed! (Simplified) MPLS rules: prefix rewriting FT: in x L out x OP, where OP = {swap,push,pop} FFT: out x L out x OP, where OP = {swap,push,pop} 14

38 A Network Model A general network Links Outgoing interfaces Nodes Incoming interfaces Set of labels in packet header 15

39 A general network A Network Model Interface function Interface function: maps outgoing interface to next hop node and incoming interface to previous hop node That is: and 16

40 A general network A Network Model Routing function Routing function: for each set of failed links routing function, the defines, for all incoming interfaces and packet headers, outgoing interfaces together with modified headers. 17

41 Routing in Network Packet routing sequence can be represented using tuples: on interface forwards it to live next hop given that these links are down. Node receives packet with header with new header.. Packet routing is then (in)finite sequence of tuples 18

42 MPLS Network Model MPLS supports following operations on header sequences: The local routing table can then be defined as Interface + label Maps to next hop and operation Local link protection function suggests backup interface protected backup typically: push 19

43 MPLS Pushdown Prefix Rewriting System Prefix rewriting system is set of rewriting rules We write for generates a transition system such that iff Replace prefix Prefix rewriting system is called pushdown system if and for all Second symbol of v: top of stack label. First symbol of v and w: control state of pushdown system. pop swap push 20

44 MPLS Pushdown Prefix Rewriting System Control states: and Labels: stack symbols and at bottom How many times have we tried to reroute at this node already? Packet with header arriving at interface in at represented as pushdown configuration: Packet to be forwarded at node represented by configuration: to outgoing interface 21

45 Example Rules: Regular Forwarding on Top-Most Label Push: Push label on stack Swap: Swap top of stack Pop: Pop top of stack 22

46 Example Failover Rules Failover-Push: Emumerate all rerouting options Failover-Swap: Failover-Pop: Example rewriting sequence: Try default Try first backup Try second backup 23

47 Why Polynomial Time?! k failures = ( n k ) possibilities Arbitrary number k of failures: How can I avoid checking all 2 k options?! Even if we reduce to push-down automaton: simple operations such as emptiness testing or intersection on push-down automata is computationally nontrivial and sometimes even undecidable! 24

48 Why Polynomial Time?! k failures = ( n k ) possibilities The Clue: this is not how we will use the PDA! Arbitrary number k of failures: How can I avoid checking all 2 k options?! Even if we reduce to push-down automaton: simple operations such as emptiness testing or intersection on push-down automata is computationally nontrivial and sometimes even undecidable! 24

49 Why Polynomial Time?! k failures = ( n k ) possibilities The Clue: this is not how we will use the PDA! Arbitrary number k of failures: How can I avoid checking all 2 k options?! Even if we reduce to push-down automaton: simple operations such as emptiness testing or intersection on push-down automata is computationally nontrivial and sometimes even undecidable! The words in our language are sequences of pushdown stack symbols, not the labels of transitions. 24

50 Time for Automata Theory! Classic result by Büchi 1964: the set of all reachable configurations of a pushdown automaton a is regular set Hence, we can operate only on NFAs when reasoning about the pushdown automata The resulting regular operations are all polynomial time Julius Richard Büchi Swiss logician Important result of model checking 25

51 Preliminary Query Language: Example Question: Beginning with an empty header [], can we get from s1 to s7 in any number of steps, and end with an empty header []? Output: Yes and witness trace (excerpt)! Query: []s1 >> s7[] Take multiple steps Empty header! 26

52 Example 2: Traversal Testing Traversal test: Can traffic starting with [] go through s3, under up to k=1 failures? 1 failure Query: k=1 [] s1 >> s3 >> s7 [] push pop YES! Down! swap swap swap 27

53 Example 3: Traversal with 2 Failures Traversal test with k=2: Can traffic go through s5, under up to k=2 failures? stack size! pop 2 failures Query: k=2 [] s1 >> s5 >> s7 [] push pop YES! push 28

54 Example 4: Transparency Violation Transparency with k=3: Can transparency be violated under up to k=3 failures? 3 failures Query: k=3 [] s1 >> s7 [+] empty non-empty YES! Root cause is a misconfiguration in s5, causing it to swap to 11 instead of popping when doing the failover on s5-s4. 29

55 Preliminary Tool Part 1: Parses query and constructs Push- Down System (PDS) In Python 3 Part 2: Reachability analysis of constructed PDS Using Moped tool query processing flow 30

56 Preliminary Evaluation For small queries fast: 1000s of links, within seconds 100,000s 1000s secs The bottleneck currently are large queries 31

57 Summary Polynomial-time verification of MPLS reachability and policyrelated properties like waypointing For arbitrary number of failures (up to linear in n)! Supports arbitrary header sizes ( infinite ) Also allows to compute headers which do (not) fulfill a property Allows to support a constant number of stateful nodes as well Extends to Segment Routing networks based on MPLS (SR-MPLS) Leveraging theory from Prefix Rewriting Systems and Büchi s classic result 32

58 Future Work Other networks and properties which can be verified in polynomial time? Good tradeoff expressiveness vs polynomial-time verifiability? We re looking for industrial case studies and collaborations Thank you! Questions? 33