Formal Modeling of an Openflow Switch using Alloy

1. Formal Modeling of an Openflow Switch using Alloy NataliRuchansky and DavideProserpio

2. Outline • Background • Openflow • Alloy • Our model • Inside the switch • Functionalities • Properties (some of them) • Extensions and future work

3. SDN and Openflow • Software Defined Network (SDN) • decoupling between data and control plane access  • Openflow • a standard interface for controlling computer network switches • Simplify networks administration • Very useful for research

4. Openflowscenario (Switch)

5. Alloy • Language and tool for relational models • Mixture of first order logic and relational algebra • Applications • Find security holes • Verify specifications (e.g. switching networks) • …

6. Our switch model • We model a Snapshot • Not a working system! • Possible events at any specific instance • We provide a context network • Network • Controller • End Hosts • Switches • Packets • Simplest network: 2 hosts, a switch and a controller Extend Nodes

7. What the (simplified) model looks like

8. Inside the Switch • Tables • Pipeline line implementation • Exists first/last table, no loops • Entries (flows) • Match fields • Compare to packet headers • Instructions • indicate what to do with packets • Counters • Keep track of statistics • Ports • Connect nodes • Every port has an owner

9. Functionalities • Packet handling • Checking for a match and act accordingly • Table modification • Add and delete • Messaging • Openflow • Controller-to-switch, asynchronous, symmetric • Data

10. Example: Add and Delete • Flow table modification messages • Add • If overlap flag & overlap: drop • No overlap flag: insert (replace if identical) entry • Delete • Strict (delete identical entries) • ..and not strict version (delete all overlapped entries) //Add entry to a table predadd[t,t':Table,e:Entry]{(t'.entries=t.entries+e)} preddelete[t,t':Table,e:Entry] {e instrictEntry =>t'.entries=t.entries-e   elset'.entries=t.entries-findOverlap[e,t]}

11. Properties implemented (some) • NoForwardingLoop • This is ensured by checking that a packet entering a switch has not previously entered the switch. • NoBlackHoles • No packet mysteriously disappears from the system. • EchoAwareness • In our model, the Switch can be in two states – either it has received an echo reply, or it is awaiting one. • NoForgottenPackets • Any packet the Switch receives is eventually processed • CorrectInstall • Upon receipt of a new flow rule, the installation is correct.

12. NoForwardingLoop • We check for every packet if it has already been received/sent by any port of the switch prednoForwardingLoop[s:Switch, p:Packet] {noport:s.ports | port in(p.seen)}

13. EchoAwareness • the Switch can be in two states – either it has received an echo reply, or it is awaiting one. //send echo predSwitch.echoTest[] {this.s2c_sendPacket[s2cPacket,s2cPacket,EchoT3] &&this.connectionStatus=waiting} //change status predSwitch.Echo[type: Type,]{type=EchoT1 => this.s2c_sendPacket[s2cPacket,s2cPacket,HelloT] && type=EchoT2 =>this.connectionStatus=acked}

14. More properties • FIFOprocessing • the model does not have a queue – we chose to set any queueingaside and have Packets processed on a first-come first-serve basis. • InstantOFRespones • When a Switch receives an Openflowmessage from the Controller, it answers right away • NoForgottenPackets • Any packet the Switch receives is eventually processed

15. Extensions • Notion of “time” (Done) • Implemented using module Ordering • Group tables and group types • Test specific applications/protocols

16. Thanks!