New Directions for Network Verification Aurojit Panda, Katerina - - PowerPoint PPT Presentation

▶
new directions for network verification
SMART_READER_LITE
LIVE PREVIEW

New Directions for Network Verification Aurojit Panda, Katerina - - PowerPoint PPT Presentation

Feb 06, 2024 267 likes •814 views

New Directions for Network Verification Aurojit Panda, Katerina Argyraki, Mooly Sagiv, Michael Schapira, Scott Shenker Brief Summary of This Talk Context : Proliferation of network verification tools. Build on assumption that the

slide-1
SLIDE 1

New Directions for Network Verification

Aurojit Panda, Katerina Argyraki, Mooly Sagiv, Michael Schapira, Scott Shenker

slide-2
SLIDE 2

Brief Summary of This Talk

  • Context:
  • Proliferation of network verification tools.
  • Build on assumption that the network state is immutable.
  • Immutable = Data packets do not change behavior of network
slide-3
SLIDE 3

Brief Summary of This Talk

  • Context:
  • Proliferation of network verification tools.
  • Build on assumption that the network state is immutable.
  • Immutable = Data packets do not change behavior of network
  • My point:
  • Many network elements have mutable state
  • Verifying mutable networks requires new techniques
  • Two technical challenges: Modeling and Scaling
slide-4
SLIDE 4

Outline

  • Background on networks.
  • Background on network verification.
  • Verifying mutable networks.
slide-5
SLIDE 5

Classical Networking

Switch Switch Switch

  • Networks provide end-to-end connectivity.
  • Just contain host and switches.
  • All interesting processing at the hosts.

Alice Bob Trent Mallory

Ted Stevens was right

slide-6
SLIDE 6

Real Networks have Middleboxes!

Switch Switch Switch Alice Bob Trent Mallory

slide-7
SLIDE 7

Real Networks have Middleboxes!

Firewall Switch Switch Switch Alice Bob Trent Mallory

  • Security (firewalls, IDSs,…).
slide-8
SLIDE 8

Real Networks have Middleboxes!

Firewall Cache Switch Switch Switch Alice Bob Trent Mallory

  • Security (firewalls, IDSs,…).
  • Performance (caches, load balancers,…).
slide-9
SLIDE 9

Real Networks have Middleboxes!

Firewall Proxy Cache Switch Switch Switch Alice Bob Trent Mallory

  • Security (firewalls, IDSs,…).
  • Performance (caches, load balancers,…).
  • New functionality (proxies,…).
slide-10
SLIDE 10

Outline

  • Background on networks.
  • Background on network verification.
  • Verifying mutable networks.
slide-11
SLIDE 11

Reachability Invariants

  • Focus on reachability invariants
  • Most important in practice, simple to state but already hard

Balancer Firewall Firewall Mallory S1 S2

slide-12
SLIDE 12

Reachability Invariants

  • Focus on reachability invariants
  • Most important in practice, simple to state but already hard

Balancer Firewall Firewall Mallory S1 S2 Can S2 receive packets of type T from Mallory?

slide-13
SLIDE 13

Reachability Invariants

  • Focus on reachability invariants
  • Most important in practice, simple to state but already hard

Balancer Firewall Firewall Mallory S1 S2 Can S2 receive “infected” packets from Mallory?

slide-14
SLIDE 14

Reachability Invariants

  • Focus on reachability invariants
  • Most important in practice, simple to state but already hard

Balancer Firewall Firewall Mallory S1 S2 Can S2 receive packets from Mallory without a connection?

slide-15
SLIDE 15

Abstractions for Invariants

  • Operators want to specify packet types using abstractions:
slide-16
SLIDE 16

Abstractions for Invariants

  • Operators want to specify packet types using abstractions:
  • “infected”
slide-17
SLIDE 17

Abstractions for Invariants

  • Operators want to specify packet types using abstractions:
  • “infected”
  • from “authenticated user”
slide-18
SLIDE 18

Abstractions for Invariants

  • Operators want to specify packet types using abstractions:
  • “infected”
  • from “authenticated user”
  • from a given application
slide-19
SLIDE 19

Abstractions for Invariants

  • Operators want to specify packet types using abstractions:
  • “infected”
  • from “authenticated user”
  • from a given application
  • How these types are determined in a network varies
slide-20
SLIDE 20

Abstractions for Invariants

  • Operators want to specify packet types using abstractions:
  • “infected”
  • from “authenticated user”
  • from a given application
  • How these types are determined in a network varies
  • Invariants should not depend on these details
slide-21
SLIDE 21

Network Verification Today

  • Switches: Forwarding rules in switches.

HSA, Veriflow, NetKAT, etc.

slide-22
SLIDE 22

Network Verification Today

  • Switches: Forwarding rules in switches.

HSA, Veriflow, NetKAT, etc.

  • SDN Controller: Code generating these rules.

Vericon, FlowLog, etc.

slide-23
SLIDE 23

Network Verification Today

  • Switches: Forwarding rules in switches.

HSA, Veriflow, NetKAT, etc.

  • SDN Controller: Code generating these rules.

Vericon, FlowLog, etc.

  • Firewalls: Verify firewall configuration.

Fang, Margrave, etc.

slide-24
SLIDE 24

Existing Assumptions/Limitations

Switches

  • Limited computational model (rule-based forwarding).
  • Immutable, functionality only changes with new rules.
  • Limited set of invariants enforced by networks.
slide-25
SLIDE 25

Existing Assumptions/Limitations

Switches

  • Limited computational model (rule-based forwarding).
  • Immutable, functionality only changes with new rules.
  • Limited set of invariants enforced by networks.

Controllers

  • All state and actions are centralized. (Globally ordered)
  • Data plane itself is immutable.
slide-26
SLIDE 26

Existing Assumptions/Limitations

Switches

  • Limited computational model (rule-based forwarding).
  • Immutable, functionality only changes with new rules.
  • Limited set of invariants enforced by networks.

Controllers

  • All state and actions are centralized. (Globally ordered)
  • Data plane itself is immutable.

Firewalls

  • Treated as if they contain Immutable state.
  • Assume a particular (simple) computational model.
slide-27
SLIDE 27

Existing Assumptions/Limitations

Switches

  • Limited computational model (rule-based forwarding).
  • Immutable, functionality only changes with new rules.
  • Limited set of invariants enforced by networks.

Controllers

  • All state and actions are centralized. (Globally ordered)
  • Data plane itself is immutable.

Firewalls

  • Treated as if they contain Immutable state.
  • Assume a particular (simple) computational model.

Violated by many middleboxes

slide-28
SLIDE 28

Outline

  • Background on networks.
  • Background on network verification.
  • Verifying mutable networks.
slide-29
SLIDE 29

Verification of Mutable Networks

  • Naive approach
  • Verify a program equivalent to the entire network.
slide-30
SLIDE 30

Verification of Mutable Networks

  • Naive approach
  • Verify a program equivalent to the entire network.
  • Feasibility is not clear
  • Large, proprietary code bases (Bro ~102K lines of code).
slide-31
SLIDE 31

Verification of Mutable Networks

  • Naive approach
  • Verify a program equivalent to the entire network.
  • Feasibility is not clear
  • Large, proprietary code bases (Bro ~102K lines of code).
  • Scalability is crucial
  • Networks contain several 1000 middleboxes or more.
slide-32
SLIDE 32

Modeling Middleboxes

slide-33
SLIDE 33

Modeling Middleboxes

Classify Packet

Determines what application sent a packet, etc. Complex, proprietary processing.

slide-34
SLIDE 34

Modeling Middleboxes

Classify Packet Update Packet

Determines what application sent a packet, etc. Complex, proprietary processing. Updating payload is complex (compression, etc.) Updating header is simple (fixed format).

slide-35
SLIDE 35

Modeling Middleboxes

Classify Packet Update State Update Packet

Determines what application sent a packet, etc. Complex, proprietary processing. Could be simple (remember packets)

  • r complex (update many hash tables).

Updating payload is complex (compression, etc.) Updating header is simple (fixed format).

slide-36
SLIDE 36

Modeling Middleboxes

Classify Packet Update State Update Packet Forward Packet

Determines what application sent a packet, etc. Complex, proprietary processing. Could be simple (remember packets)

  • r

Updating payload is complex (compression, etc.) Updating header is simple (fixed format). Always simple: forward or drop packets.

slide-37
SLIDE 37

Modeling Middleboxes

Classify Packet Update State Update Packet Forward Packet

Determines what application sent a packet, etc. Complex, proprietary processing. Could be simple (remember packets)

  • r

Updating payload is complex (compression, etc.) Updating header is simple (fixed format). Always simple: forward or drop packets.

Oracle: Specify data dependencies and outputs

slide-38
SLIDE 38

Modeling Middleboxes

Classify Packet Update State Update Packet Forward Packet

Determines what application sent a packet, etc. Complex, proprietary processing. Could be simple (remember packets)

  • r

Updating payload is complex (compression, etc.) Updating header is simple (fixed format). Always simple: forward or drop packets.

Oracle: Specify data dependencies and outputs Forwarding Model: Specify Completely

slide-39
SLIDE 39

Example

Classify Packet Update State Update Packet Forward Packet Oracle: Specify data dependencies and outputs Forwarding Model: Specify Completely

slide-40
SLIDE 40

Example

Classify Packet Update State Update Packet Forward Packet Oracle: Specify data dependencies and outputs Forwarding Model: Specify Completely

Outputs Is packet infected. Dependencies See all packets in connection (flow).

slide-41
SLIDE 41

Example

Classify Packet Update State Update Packet Forward Packet Oracle: Specify data dependencies and outputs Forwarding Model: Specify Completely

Outputs Is packet infected. Dependencies See all packets in connection (flow). if (infected) { infected_connections.add(packet.flow) }

slide-42
SLIDE 42

Example

Classify Packet Update State Update Packet Forward Packet Oracle: Specify data dependencies and outputs Forwarding Model: Specify Completely

Outputs Is packet infected. Dependencies See all packets in connection (flow). if (packet.flow not in infected_connections) { forward (packet); } if (infected) { infected_connections.add(packet.flow) }

slide-43
SLIDE 43

Scaling Verification

slide-44
SLIDE 44

Scaling Verification

  • Middleboxes are “flow-parallel”
slide-45
SLIDE 45

Scaling Verification

  • Middleboxes are “flow-parallel”
  • State is partitioned between “flows.”
slide-46
SLIDE 46

Scaling Verification

  • Middleboxes are “flow-parallel”
  • State is partitioned between “flows.”
  • This enables “compositional verification”
slide-47
SLIDE 47

Scaling Verification

  • Middleboxes are “flow-parallel”
  • State is partitioned between “flows.”
  • This enables “compositional verification”
  • 30,000 middlebox networks verified in 5 minutes
slide-48
SLIDE 48

Compositional Verification

mbox mbox mbox mbox mbox mbox mbox mbox mbox mbox mbox mbox

slide-49
SLIDE 49

Compositional Verification

mbox mbox mbox mbox mbox mbox mbox mbox mbox mbox mbox mbox

slide-50
SLIDE 50

Compositional Verification

mbox mbox mbox mbox mbox mbox mbox mbox mbox mbox mbox mbox

  • Invariants talk about pairs of hosts.
  • When flow-parallel, need-only verify path.
slide-51
SLIDE 51

Conclusion

  • Real networks:
  • Contain mutable middleboxes.
  • Used to enforce rich connectivity invariants.
  • Network verification needs to evolve to handle this.
  • Several challenges
  • Right level of abstraction for specifying middleboxes.
  • Scalability, by leveraging compositional verification.
  • Future: Tractability of verification.

Some pictures taken from the Noun Project

slide-52
SLIDE 52

Backup

slide-53
SLIDE 53

Does State Mutation Matter

  • Do we even need to look at state evolution?
  • Check invariant for all possible states.
  • Approach used in tools like Margrave.
  • # of states is small (just whether connection established).
  • False positives, some states may never occur.
slide-54
SLIDE 54

Does State Mutation Matter

Firewall

  • Do we even need to look at state evolution?
  • Check invariant for all possible states.
  • Approach used in tools like Margrave.
  • # of states is small (just whether connection established).
  • False positives, some states may never occur.

Firewall a b b → a ⇐ ⇒ ⌥conn(a → b) a → b ⇐ ⇒ ⌥conn(b → a) conn(a → b) Connection started by a to b. Requires a to send packet to b, and b to respond Can a packet from 'a' reach 'b'?