Formal Modeling of an Openflow Switch using Alloy Natali Ruchansky and Davide Proserpio

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

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 3

Openflow scenario (Switch) 4

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)  … 5

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 6

What the (simplified) model looks like 7

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 8

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

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) 10 //Add entry to a table pred add[t,t':Table,e:Entry]{(t'.entries=t.entries+e)} pred delete[t,t':Table,e:Entry] {e in strictEntry =>t'.entries=t.entries-e else t'.entries=t.entries-findOverlap[e,t]}

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

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

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

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

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

Thanks! 16