Splendid(( Isolaon -...
104
Splendid Isola-on HotSDN Cole Schlesinger Aug. 2012 Joint work with: Stephen Gutz Alec Story Nate Foster A Slice Abstrac-on for So4ware Defined Networks
Transcript of Splendid(( Isolaon -...
Splendid
Isola-on HotSDN Cole Schlesinger
Au g . 2 0 1 2
Jo in t work w i th :
S t e phen Gu t z
36 www.cornelllogo.cornell.edu Revised March 2007
One-color printing
When only one-color printing is available, the insignia, logotype, and name of college, school, or unit should be printed positive—in black or Cornell Red.
The insignia, logotype, and name of college, school, or unit also can be reversed out of any color to white, as shown.
36 www.cornelllogo.cornell.edu Revised March 2007
One-color printing
When only one-color printing is available, the insignia, logotype, and name of college, school, or unit should be printed positive—in black or Cornell Red.
The insignia, logotype, and name of college, school, or unit also can be reversed out of any color to white, as shown.
A l e c S t o r y N a t e F o s t e r
A Slice Abstrac-on for So4ware Defined Networks
• How does one read the state of the network? [Foster, et al. Frene-c: A Network Programming Language. ICFP ‘11.]
• How does one read the state of the network? [Foster, et al. Frene-c: A Network Programming Language. ICFP ‘11.]
• How does one write the state of the network? [ReitblaL, et al. Abstrac-ons for Network Update. SIGCOMM ’12]
• How does one read the state of the network? [Foster, et al. Frene-c: A Network Programming Language. ICFP ‘11.]
• How does one write the state of the network? [ReitblaL, et al. Abstrac-ons for Network Update. SIGCOMM ‘12]
• How does one define a new (virtual) network? [Coming soon!]
• How does one read the state of the network? [Foster, et al. Frene-c: A Network Programming Language. ICFP ‘11.]
• How does one write the state of the network? [ReitblaL, et al. Abstrac-ons for Network Update. SIGCOMM ‘12]
• How does one define a new (virtual) network? [Coming soon!]
• How does one compose two network programs? [This talk.]
• How does one compose two network programs?
• How does one compose two network programs?
Define a new slice abstrac-on. Li4 slices (and isola-on) into the language.
Topology
Data Center Isola-on
A2 A1
R1 R2 R3
H11 H12 H21 H22 H31 H32
8
Client 1
A2 A1
R1 R2 R3
H11 H12 H21 H22 H31 H32
9
Policy 1
Client 2
A2 A1
R1 R2 R3
H11 H12 H21 H22 H31 H32
10
Policy 2
Client 1 + Client 2
A2 A1
R1 R2 R3
H11 H12 H21 H22 H31 H32
Overlap
Client 2
Client 1
11
Policy 2 Policy 1 +
Client 2 injects packets into Client 1’s sec-on of the network!
A2 A1
R1 R2 R3
H11 H12 H21 H22 H31 H32
Overlap
Client 2
Client 1
12
Policy 2 Policy 1 +
Client 2 intercepts packets from Client 1’s sec-on of the network!
A2 A1
R1 R2 R3
H11 H12 H21 H22 H31 H32
Overlap
Client 2
Client 1
13
Policy 2 Policy 1 +
Client 1 Client 2
A2 A1
R2 R3
H22 H31 H32
A2 A1
R1 R2
H11 H12 H21
14
Policy 2 Policy 1 |
Our Approach
• Make isola-on part of the language. – For security and modularity.
• Give each client a slice of the network which they can assume complete control over, as if they were alone on the network.
• Given a set of slices and a policy for each slice, compile them into one whole-‐network program that enforces isola-on.
15
Slices
16
A2 A1
R1 R2 R3
Slices
17
A2 A1
R1 R2 R3
A2 A1
R1 R2
Slices
18
A2 A1
R1 R2 R3
A2 A1
R1 R2
Predicate on incoming packets
Predicate on outgoing packets
Slices
19
A2 A1
R1 R2 R3
A2 A1
R1 R2
Client 1 Client 2
A2 A1
R2 R3
H22 H31 H32
A2 A1
R1 R2
H11 H12 H21
20
Policy 2 Policy 1 |
Slice 1 Slice 2
Isola-on as Modularity
21
C2 C12 C11 C13
Mul--‐part Controller Program
Isola-on as Modularity
22
C2 C12 C11 C13
ARP
Isola-on as Modularity
23
C2 C12 C11 C13
ARP MAC Learning
Isola-on as Modularity
24
ARP
Traffic Monitoring
C2 C12 C11 C13
MAC Learning
Implementa-on
25
B A2 A1 A3 A4
Input: a set of slices and NetCore policies. (Must be VLAN-‐independent.)
Implementa-on
26
B A2 A1 A3 A4
Slice Compiler
Input: a set of slices and NetCore policies. (Must be VLAN-‐independent.)
Implementa-on
27
NetCo
re
B A2 A1 A3 A4
Slice Compiler
B A3 A4 A2 A1
Input: a set of slices and NetCore policies.
Output: a single, global NetCore policy.
Implementa-on
28
NetCo
re
B A2 A1 A3 A4
Slice Compiler
B A3 A4 A2 A1
N O X , N e W l e , F l o o d l i g h t , e t c .
Input: a set of slices and policies.
Output: a single, global NetCore policy.
(Must be VLAN-‐independent.)
A2 A1
R1 R2 R3
H11 H12 H21 H22 H31 H32
29
Controller 1 Controller 2
FlowVisor
Verifica-on
30
A2 A1
Slice Compiler
NetCo
re
A2 A1
Verifica-on
31
Model NetCore policies in SMT (Z3). 1 A2 A1
Slice Compiler
NetCo
re
A2 A1
Splendid Isolation: Language-Based Securityfor Software-Defined Networks
Cole SchlesingerPrinceton
Alec StoryCornell
Stephen GutzCornell
Nate FosterCornell
David WalkerPrinceton
AbstractIn many settings, including the college campus, the enterprise, themilitary, and in the datacenter, networks must be shared: numerousentities send and receive many different types of traffic over thesame underlying hardware. This paper analyzes the fundamentalproblem of how to program such networks in a secure and reliablemanner. Our solution involves the development of a new program-ming model that supports the concept of a network slice. Slices actto isolate the traffic of one program from another, and also to iso-late one type of traffic within a program from other traffic withinthat same program. Consequently, slices bring a critical form ofmodularity to network programming that has long been absent. Wedevelop a semantics for slices, illustrate the new kinds of formalmodular reasoning principles that network programmers can nowexploit, provide definitions of the end-to-end security propertiesthat slices entail and prove the correctness of a compiler for anidealized core calculus for slice-based network programming. Wealso describe our implementation, which comes equipped with atranslation validation framework that automatically verifies com-piled programs using the Z3 theorem prover.
1. Introduction� ^ �0
^ 0
The security of many systems depends on keeping one partof a network isolated from another. For example, to protect stu-dent records, universities often use the network to restrict accessto administrative machines; many military and intelligence orga-nizations mandate an “airgap” between devices that process trafficclassified at different levels of confidentiality; in multi-tenant data-centers, service-level agreements stipulate that traffic must not flowbetween the virtual machines leased by different customers. Infor-mally, we define isolation as a pair of properties: (1) confidentiality,a desire to avoid revealing information about one’s own networktraffic to others, and (2) integrity, a desire to exclude the networktraffic of others from your systems.
Unfortunately, implementing isolation in networks today ischallenging. It requires manually configuring a large set of devicesincluding routers, switches, and firewalls, in a way that blocksforbidden traffic but allows other traffic to traverse the network un-hindered. Developing and maintaining these configurations, whichmust be expressed using low-level and vendor-specific configura-tion languages, is tedious work for network operators and mistakesare frequent. Simple errors can (and often do) lead to serious secu-rity breaches. These concerns are not hypothetical: an FBI investi-gation found that a recent break-in at the NASDAQ stock exchangewas due in part to a misconfigured firewall [? ]; a survey of atten-dees at the 2011 DEFCON conference found that networks are “the
easiest IT resource to exploit” and “are misconfigured more thanthree quarters of the time” [? ].
A much better approach would be to use a high-level program-ming language that made it easy to describe forwarding policies andconstruct isolated subnetworks, while leaving the tedious, error-prone work of generating correct and efficient low-level configura-tions to a compiler. These languages could be designed to make iteasy to reason about important security properties such as confiden-tiality, integrity or access control, and they could be accompaniedby mechanical verification tools for checking those properties au-tomatically. Unfortunately, this approach, while attractive in princi-ple, has been difficult to realize because networks have traditionallybeen built out of closed devices that cannot be programmed, exceptthrough proprietary and idiosyncratic interfaces.
Remarkably, this practical limitation has begun to disappearin recent years with the emergence of software-defined networks(SDNs). In an SDN, a controller machine manages a collection ofprogrammable switches. The controller defines the forwarding pol-icy for the network and configures the switches through an openand standard interface. The switches implement the policy using ef-ficient packet-processing hardware. Many commercial switch ven-dors (including IBM, HP, NEC, Dell, Netgear, Juniper, Brocade,Broadcom, and others) already support SDN platforms such asOpenFlow [? ], and prominent organizations including Google andInternet2 have built production networks based on OpenFlow [? ].
But although SDNs make it possible to control the behavior ofthe network in software, current platforms do not make it easy towrite program that work on isolated subnetworks. NOX [? ], oneof the first SDN platforms, provides only a thin veneer over theunderlying hardware, so programmers must manage switch-levelresources such as forwarding rules and virtual LANs (VLANs) byhand. To ensure isolation, programmers must establish and main-tain their own ad hoc conventions without compiler support. Forexample, if two independently-developed NOX programs wish toshare a network, they must agree on some protocol to keep thetraffic of the two networks separate, and NOX provides no helpin ensuring that such agreements will be implemented correctly.NetCore [? ], another language for programming SDNs, also lacksconstructs for expressing or enforcing isolation properties.
Besides needing isolation for security, one often wants to iso-late the behavior of several modules within a single program. Hereagain, languages like NOX and NetCore are no help. For example,the NOX tutorial explains how to develop a basic Ethernet learningswitch module that learns the association of Ethernet addresses toswitch port numbers. However, the learning switch must also oper-ate side-by-side with another module that discovers the topology ofthe network by probing the network with LLDP packets. To avoiddisrupting the discovery module, the learning switch code includesexplicit instructions to ignore LLDP packets:
# don’t forward lldp packets
Splendid Isolation: Language-Based Securityfor Software-Defined Networks
Cole SchlesingerPrinceton
Alec StoryCornell
Stephen GutzCornell
Nate FosterCornell
David WalkerPrinceton
AbstractIn many settings, including the college campus, the enterprise, themilitary, and in the datacenter, networks must be shared: numerousentities send and receive many different types of traffic over thesame underlying hardware. This paper analyzes the fundamentalproblem of how to program such networks in a secure and reliablemanner. Our solution involves the development of a new program-ming model that supports the concept of a network slice. Slices actto isolate the traffic of one program from another, and also to iso-late one type of traffic within a program from other traffic withinthat same program. Consequently, slices bring a critical form ofmodularity to network programming that has long been absent. Wedevelop a semantics for slices, illustrate the new kinds of formalmodular reasoning principles that network programmers can nowexploit, provide definitions of the end-to-end security propertiesthat slices entail and prove the correctness of a compiler for anidealized core calculus for slice-based network programming. Wealso describe our implementation, which comes equipped with atranslation validation framework that automatically verifies com-piled programs using the Z3 theorem prover.
1. Introduction� ^ �0
^ 0
The security of many systems depends on keeping one partof a network isolated from another. For example, to protect stu-dent records, universities often use the network to restrict accessto administrative machines; many military and intelligence orga-nizations mandate an “airgap” between devices that process trafficclassified at different levels of confidentiality; in multi-tenant data-centers, service-level agreements stipulate that traffic must not flowbetween the virtual machines leased by different customers. Infor-mally, we define isolation as a pair of properties: (1) confidentiality,a desire to avoid revealing information about one’s own networktraffic to others, and (2) integrity, a desire to exclude the networktraffic of others from your systems.
Unfortunately, implementing isolation in networks today ischallenging. It requires manually configuring a large set of devicesincluding routers, switches, and firewalls, in a way that blocksforbidden traffic but allows other traffic to traverse the network un-hindered. Developing and maintaining these configurations, whichmust be expressed using low-level and vendor-specific configura-tion languages, is tedious work for network operators and mistakesare frequent. Simple errors can (and often do) lead to serious secu-rity breaches. These concerns are not hypothetical: an FBI investi-gation found that a recent break-in at the NASDAQ stock exchangewas due in part to a misconfigured firewall [? ]; a survey of atten-dees at the 2011 DEFCON conference found that networks are “the
easiest IT resource to exploit” and “are misconfigured more thanthree quarters of the time” [? ].
A much better approach would be to use a high-level program-ming language that made it easy to describe forwarding policies andconstruct isolated subnetworks, while leaving the tedious, error-prone work of generating correct and efficient low-level configura-tions to a compiler. These languages could be designed to make iteasy to reason about important security properties such as confiden-tiality, integrity or access control, and they could be accompaniedby mechanical verification tools for checking those properties au-tomatically. Unfortunately, this approach, while attractive in princi-ple, has been difficult to realize because networks have traditionallybeen built out of closed devices that cannot be programmed, exceptthrough proprietary and idiosyncratic interfaces.
Remarkably, this practical limitation has begun to disappearin recent years with the emergence of software-defined networks(SDNs). In an SDN, a controller machine manages a collection ofprogrammable switches. The controller defines the forwarding pol-icy for the network and configures the switches through an openand standard interface. The switches implement the policy using ef-ficient packet-processing hardware. Many commercial switch ven-dors (including IBM, HP, NEC, Dell, Netgear, Juniper, Brocade,Broadcom, and others) already support SDN platforms such asOpenFlow [? ], and prominent organizations including Google andInternet2 have built production networks based on OpenFlow [? ].
But although SDNs make it possible to control the behavior ofthe network in software, current platforms do not make it easy towrite program that work on isolated subnetworks. NOX [? ], oneof the first SDN platforms, provides only a thin veneer over theunderlying hardware, so programmers must manage switch-levelresources such as forwarding rules and virtual LANs (VLANs) byhand. To ensure isolation, programmers must establish and main-tain their own ad hoc conventions without compiler support. Forexample, if two independently-developed NOX programs wish toshare a network, they must agree on some protocol to keep thetraffic of the two networks separate, and NOX provides no helpin ensuring that such agreements will be implemented correctly.NetCore [? ], another language for programming SDNs, also lacksconstructs for expressing or enforcing isolation properties.
Besides needing isolation for security, one often wants to iso-late the behavior of several modules within a single program. Hereagain, languages like NOX and NetCore are no help. For example,the NOX tutorial explains how to develop a basic Ethernet learningswitch module that learns the association of Ethernet addresses toswitch port numbers. However, the learning switch must also oper-ate side-by-side with another module that discovers the topology ofthe network by probing the network with LLDP packets. To avoiddisrupting the discovery module, the learning switch code includesexplicit instructions to ignore LLDP packets:
# don’t forward lldp packets
Verifica-on
32
Verify isola-on. 2
A2 A1
Slice Compiler
NetCo
re
A2 A1
Splendid Isolation: Language-Based Securityfor Software-Defined Networks
Cole SchlesingerPrinceton
Alec StoryCornell
Stephen GutzCornell
Nate FosterCornell
David WalkerPrinceton
AbstractIn many settings, including the college campus, the enterprise, themilitary, and in the datacenter, networks must be shared: numerousentities send and receive many different types of traffic over thesame underlying hardware. This paper analyzes the fundamentalproblem of how to program such networks in a secure and reliablemanner. Our solution involves the development of a new program-ming model that supports the concept of a network slice. Slices actto isolate the traffic of one program from another, and also to iso-late one type of traffic within a program from other traffic withinthat same program. Consequently, slices bring a critical form ofmodularity to network programming that has long been absent. Wedevelop a semantics for slices, illustrate the new kinds of formalmodular reasoning principles that network programmers can nowexploit, provide definitions of the end-to-end security propertiesthat slices entail and prove the correctness of a compiler for anidealized core calculus for slice-based network programming. Wealso describe our implementation, which comes equipped with atranslation validation framework that automatically verifies com-piled programs using the Z3 theorem prover.
1. Introduction� ^ �0
^ 0
The security of many systems depends on keeping one partof a network isolated from another. For example, to protect stu-dent records, universities often use the network to restrict accessto administrative machines; many military and intelligence orga-nizations mandate an “airgap” between devices that process trafficclassified at different levels of confidentiality; in multi-tenant data-centers, service-level agreements stipulate that traffic must not flowbetween the virtual machines leased by different customers. Infor-mally, we define isolation as a pair of properties: (1) confidentiality,a desire to avoid revealing information about one’s own networktraffic to others, and (2) integrity, a desire to exclude the networktraffic of others from your systems.
Unfortunately, implementing isolation in networks today ischallenging. It requires manually configuring a large set of devicesincluding routers, switches, and firewalls, in a way that blocksforbidden traffic but allows other traffic to traverse the network un-hindered. Developing and maintaining these configurations, whichmust be expressed using low-level and vendor-specific configura-tion languages, is tedious work for network operators and mistakesare frequent. Simple errors can (and often do) lead to serious secu-rity breaches. These concerns are not hypothetical: an FBI investi-gation found that a recent break-in at the NASDAQ stock exchangewas due in part to a misconfigured firewall [? ]; a survey of atten-dees at the 2011 DEFCON conference found that networks are “the
easiest IT resource to exploit” and “are misconfigured more thanthree quarters of the time” [? ].
A much better approach would be to use a high-level program-ming language that made it easy to describe forwarding policies andconstruct isolated subnetworks, while leaving the tedious, error-prone work of generating correct and efficient low-level configura-tions to a compiler. These languages could be designed to make iteasy to reason about important security properties such as confiden-tiality, integrity or access control, and they could be accompaniedby mechanical verification tools for checking those properties au-tomatically. Unfortunately, this approach, while attractive in princi-ple, has been difficult to realize because networks have traditionallybeen built out of closed devices that cannot be programmed, exceptthrough proprietary and idiosyncratic interfaces.
Remarkably, this practical limitation has begun to disappearin recent years with the emergence of software-defined networks(SDNs). In an SDN, a controller machine manages a collection ofprogrammable switches. The controller defines the forwarding pol-icy for the network and configures the switches through an openand standard interface. The switches implement the policy using ef-ficient packet-processing hardware. Many commercial switch ven-dors (including IBM, HP, NEC, Dell, Netgear, Juniper, Brocade,Broadcom, and others) already support SDN platforms such asOpenFlow [? ], and prominent organizations including Google andInternet2 have built production networks based on OpenFlow [? ].
But although SDNs make it possible to control the behavior ofthe network in software, current platforms do not make it easy towrite program that work on isolated subnetworks. NOX [? ], oneof the first SDN platforms, provides only a thin veneer over theunderlying hardware, so programmers must manage switch-levelresources such as forwarding rules and virtual LANs (VLANs) byhand. To ensure isolation, programmers must establish and main-tain their own ad hoc conventions without compiler support. Forexample, if two independently-developed NOX programs wish toshare a network, they must agree on some protocol to keep thetraffic of the two networks separate, and NOX provides no helpin ensuring that such agreements will be implemented correctly.NetCore [? ], another language for programming SDNs, also lacksconstructs for expressing or enforcing isolation properties.
Besides needing isolation for security, one often wants to iso-late the behavior of several modules within a single program. Hereagain, languages like NOX and NetCore are no help. For example,the NOX tutorial explains how to develop a basic Ethernet learningswitch module that learns the association of Ethernet addresses toswitch port numbers. However, the learning switch must also oper-ate side-by-side with another module that discovers the topology ofthe network by probing the network with LLDP packets. To avoiddisrupting the discovery module, the learning switch code includesexplicit instructions to ignore LLDP packets:
# don’t forward lldp packets
Splendid Isolation: Language-Based Securityfor Software-Defined Networks
Cole SchlesingerPrinceton
Alec StoryCornell
Stephen GutzCornell
Nate FosterCornell
David WalkerPrinceton
AbstractIn many settings, including the college campus, the enterprise, themilitary, and in the datacenter, networks must be shared: numerousentities send and receive many different types of traffic over thesame underlying hardware. This paper analyzes the fundamentalproblem of how to program such networks in a secure and reliablemanner. Our solution involves the development of a new program-ming model that supports the concept of a network slice. Slices actto isolate the traffic of one program from another, and also to iso-late one type of traffic within a program from other traffic withinthat same program. Consequently, slices bring a critical form ofmodularity to network programming that has long been absent. Wedevelop a semantics for slices, illustrate the new kinds of formalmodular reasoning principles that network programmers can nowexploit, provide definitions of the end-to-end security propertiesthat slices entail and prove the correctness of a compiler for anidealized core calculus for slice-based network programming. Wealso describe our implementation, which comes equipped with atranslation validation framework that automatically verifies com-piled programs using the Z3 theorem prover.
1. Introduction� ^ �0
^ 0
The security of many systems depends on keeping one partof a network isolated from another. For example, to protect stu-dent records, universities often use the network to restrict accessto administrative machines; many military and intelligence orga-nizations mandate an “airgap” between devices that process trafficclassified at different levels of confidentiality; in multi-tenant data-centers, service-level agreements stipulate that traffic must not flowbetween the virtual machines leased by different customers. Infor-mally, we define isolation as a pair of properties: (1) confidentiality,a desire to avoid revealing information about one’s own networktraffic to others, and (2) integrity, a desire to exclude the networktraffic of others from your systems.
Unfortunately, implementing isolation in networks today ischallenging. It requires manually configuring a large set of devicesincluding routers, switches, and firewalls, in a way that blocksforbidden traffic but allows other traffic to traverse the network un-hindered. Developing and maintaining these configurations, whichmust be expressed using low-level and vendor-specific configura-tion languages, is tedious work for network operators and mistakesare frequent. Simple errors can (and often do) lead to serious secu-rity breaches. These concerns are not hypothetical: an FBI investi-gation found that a recent break-in at the NASDAQ stock exchangewas due in part to a misconfigured firewall [? ]; a survey of atten-dees at the 2011 DEFCON conference found that networks are “the
easiest IT resource to exploit” and “are misconfigured more thanthree quarters of the time” [? ].
A much better approach would be to use a high-level program-ming language that made it easy to describe forwarding policies andconstruct isolated subnetworks, while leaving the tedious, error-prone work of generating correct and efficient low-level configura-tions to a compiler. These languages could be designed to make iteasy to reason about important security properties such as confiden-tiality, integrity or access control, and they could be accompaniedby mechanical verification tools for checking those properties au-tomatically. Unfortunately, this approach, while attractive in princi-ple, has been difficult to realize because networks have traditionallybeen built out of closed devices that cannot be programmed, exceptthrough proprietary and idiosyncratic interfaces.
Remarkably, this practical limitation has begun to disappearin recent years with the emergence of software-defined networks(SDNs). In an SDN, a controller machine manages a collection ofprogrammable switches. The controller defines the forwarding pol-icy for the network and configures the switches through an openand standard interface. The switches implement the policy using ef-ficient packet-processing hardware. Many commercial switch ven-dors (including IBM, HP, NEC, Dell, Netgear, Juniper, Brocade,Broadcom, and others) already support SDN platforms such asOpenFlow [? ], and prominent organizations including Google andInternet2 have built production networks based on OpenFlow [? ].
But although SDNs make it possible to control the behavior ofthe network in software, current platforms do not make it easy towrite program that work on isolated subnetworks. NOX [? ], oneof the first SDN platforms, provides only a thin veneer over theunderlying hardware, so programmers must manage switch-levelresources such as forwarding rules and virtual LANs (VLANs) byhand. To ensure isolation, programmers must establish and main-tain their own ad hoc conventions without compiler support. Forexample, if two independently-developed NOX programs wish toshare a network, they must agree on some protocol to keep thetraffic of the two networks separate, and NOX provides no helpin ensuring that such agreements will be implemented correctly.NetCore [? ], another language for programming SDNs, also lacksconstructs for expressing or enforcing isolation properties.
Besides needing isolation for security, one often wants to iso-late the behavior of several modules within a single program. Hereagain, languages like NOX and NetCore are no help. For example,the NOX tutorial explains how to develop a basic Ethernet learningswitch module that learns the association of Ethernet addresses toswitch port numbers. However, the learning switch must also oper-ate side-by-side with another module that discovers the topology ofthe network by probing the network with LLDP packets. To avoiddisrupting the discovery module, the learning switch code includesexplicit instructions to ignore LLDP packets:
# don’t forward lldp packets
Model NetCore policies in SMT (Z3). 1
Verifica-on
33
Model NetCore policies in SMT (Z3). 1
Verify isola-on. 2
Verify seman-c equivalence. 1
≅
A2 A1
Slice Compiler
NetCo
re
A2 A1
Splendid Isolation: Language-Based Securityfor Software-Defined Networks
Cole SchlesingerPrinceton
Alec StoryCornell
Stephen GutzCornell
Nate FosterCornell
David WalkerPrinceton
AbstractIn many settings, including the college campus, the enterprise, themilitary, and in the datacenter, networks must be shared: numerousentities send and receive many different types of traffic over thesame underlying hardware. This paper analyzes the fundamentalproblem of how to program such networks in a secure and reliablemanner. Our solution involves the development of a new program-ming model that supports the concept of a network slice. Slices actto isolate the traffic of one program from another, and also to iso-late one type of traffic within a program from other traffic withinthat same program. Consequently, slices bring a critical form ofmodularity to network programming that has long been absent. Wedevelop a semantics for slices, illustrate the new kinds of formalmodular reasoning principles that network programmers can nowexploit, provide definitions of the end-to-end security propertiesthat slices entail and prove the correctness of a compiler for anidealized core calculus for slice-based network programming. Wealso describe our implementation, which comes equipped with atranslation validation framework that automatically verifies com-piled programs using the Z3 theorem prover.
1. Introduction� ^ �0
^ 0
The security of many systems depends on keeping one partof a network isolated from another. For example, to protect stu-dent records, universities often use the network to restrict accessto administrative machines; many military and intelligence orga-nizations mandate an “airgap” between devices that process trafficclassified at different levels of confidentiality; in multi-tenant data-centers, service-level agreements stipulate that traffic must not flowbetween the virtual machines leased by different customers. Infor-mally, we define isolation as a pair of properties: (1) confidentiality,a desire to avoid revealing information about one’s own networktraffic to others, and (2) integrity, a desire to exclude the networktraffic of others from your systems.
Unfortunately, implementing isolation in networks today ischallenging. It requires manually configuring a large set of devicesincluding routers, switches, and firewalls, in a way that blocksforbidden traffic but allows other traffic to traverse the network un-hindered. Developing and maintaining these configurations, whichmust be expressed using low-level and vendor-specific configura-tion languages, is tedious work for network operators and mistakesare frequent. Simple errors can (and often do) lead to serious secu-rity breaches. These concerns are not hypothetical: an FBI investi-gation found that a recent break-in at the NASDAQ stock exchangewas due in part to a misconfigured firewall [? ]; a survey of atten-dees at the 2011 DEFCON conference found that networks are “the
easiest IT resource to exploit” and “are misconfigured more thanthree quarters of the time” [? ].
A much better approach would be to use a high-level program-ming language that made it easy to describe forwarding policies andconstruct isolated subnetworks, while leaving the tedious, error-prone work of generating correct and efficient low-level configura-tions to a compiler. These languages could be designed to make iteasy to reason about important security properties such as confiden-tiality, integrity or access control, and they could be accompaniedby mechanical verification tools for checking those properties au-tomatically. Unfortunately, this approach, while attractive in princi-ple, has been difficult to realize because networks have traditionallybeen built out of closed devices that cannot be programmed, exceptthrough proprietary and idiosyncratic interfaces.
Remarkably, this practical limitation has begun to disappearin recent years with the emergence of software-defined networks(SDNs). In an SDN, a controller machine manages a collection ofprogrammable switches. The controller defines the forwarding pol-icy for the network and configures the switches through an openand standard interface. The switches implement the policy using ef-ficient packet-processing hardware. Many commercial switch ven-dors (including IBM, HP, NEC, Dell, Netgear, Juniper, Brocade,Broadcom, and others) already support SDN platforms such asOpenFlow [? ], and prominent organizations including Google andInternet2 have built production networks based on OpenFlow [? ].
But although SDNs make it possible to control the behavior ofthe network in software, current platforms do not make it easy towrite program that work on isolated subnetworks. NOX [? ], oneof the first SDN platforms, provides only a thin veneer over theunderlying hardware, so programmers must manage switch-levelresources such as forwarding rules and virtual LANs (VLANs) byhand. To ensure isolation, programmers must establish and main-tain their own ad hoc conventions without compiler support. Forexample, if two independently-developed NOX programs wish toshare a network, they must agree on some protocol to keep thetraffic of the two networks separate, and NOX provides no helpin ensuring that such agreements will be implemented correctly.NetCore [? ], another language for programming SDNs, also lacksconstructs for expressing or enforcing isolation properties.
Besides needing isolation for security, one often wants to iso-late the behavior of several modules within a single program. Hereagain, languages like NOX and NetCore are no help. For example,the NOX tutorial explains how to develop a basic Ethernet learningswitch module that learns the association of Ethernet addresses toswitch port numbers. However, the learning switch must also oper-ate side-by-side with another module that discovers the topology ofthe network by probing the network with LLDP packets. To avoiddisrupting the discovery module, the learning switch code includesexplicit instructions to ignore LLDP packets:
# don’t forward lldp packets
Splendid Isolation: Language-Based Securityfor Software-Defined Networks
Cole SchlesingerPrinceton
Alec StoryCornell
Stephen GutzCornell
Nate FosterCornell
David WalkerPrinceton
AbstractIn many settings, including the college campus, the enterprise, themilitary, and in the datacenter, networks must be shared: numerousentities send and receive many different types of traffic over thesame underlying hardware. This paper analyzes the fundamentalproblem of how to program such networks in a secure and reliablemanner. Our solution involves the development of a new program-ming model that supports the concept of a network slice. Slices actto isolate the traffic of one program from another, and also to iso-late one type of traffic within a program from other traffic withinthat same program. Consequently, slices bring a critical form ofmodularity to network programming that has long been absent. Wedevelop a semantics for slices, illustrate the new kinds of formalmodular reasoning principles that network programmers can nowexploit, provide definitions of the end-to-end security propertiesthat slices entail and prove the correctness of a compiler for anidealized core calculus for slice-based network programming. Wealso describe our implementation, which comes equipped with atranslation validation framework that automatically verifies com-piled programs using the Z3 theorem prover.
1. Introduction� ^ �0
^ 0
The security of many systems depends on keeping one partof a network isolated from another. For example, to protect stu-dent records, universities often use the network to restrict accessto administrative machines; many military and intelligence orga-nizations mandate an “airgap” between devices that process trafficclassified at different levels of confidentiality; in multi-tenant data-centers, service-level agreements stipulate that traffic must not flowbetween the virtual machines leased by different customers. Infor-mally, we define isolation as a pair of properties: (1) confidentiality,a desire to avoid revealing information about one’s own networktraffic to others, and (2) integrity, a desire to exclude the networktraffic of others from your systems.
Unfortunately, implementing isolation in networks today ischallenging. It requires manually configuring a large set of devicesincluding routers, switches, and firewalls, in a way that blocksforbidden traffic but allows other traffic to traverse the network un-hindered. Developing and maintaining these configurations, whichmust be expressed using low-level and vendor-specific configura-tion languages, is tedious work for network operators and mistakesare frequent. Simple errors can (and often do) lead to serious secu-rity breaches. These concerns are not hypothetical: an FBI investi-gation found that a recent break-in at the NASDAQ stock exchangewas due in part to a misconfigured firewall [? ]; a survey of atten-dees at the 2011 DEFCON conference found that networks are “the
easiest IT resource to exploit” and “are misconfigured more thanthree quarters of the time” [? ].
A much better approach would be to use a high-level program-ming language that made it easy to describe forwarding policies andconstruct isolated subnetworks, while leaving the tedious, error-prone work of generating correct and efficient low-level configura-tions to a compiler. These languages could be designed to make iteasy to reason about important security properties such as confiden-tiality, integrity or access control, and they could be accompaniedby mechanical verification tools for checking those properties au-tomatically. Unfortunately, this approach, while attractive in princi-ple, has been difficult to realize because networks have traditionallybeen built out of closed devices that cannot be programmed, exceptthrough proprietary and idiosyncratic interfaces.
Remarkably, this practical limitation has begun to disappearin recent years with the emergence of software-defined networks(SDNs). In an SDN, a controller machine manages a collection ofprogrammable switches. The controller defines the forwarding pol-icy for the network and configures the switches through an openand standard interface. The switches implement the policy using ef-ficient packet-processing hardware. Many commercial switch ven-dors (including IBM, HP, NEC, Dell, Netgear, Juniper, Brocade,Broadcom, and others) already support SDN platforms such asOpenFlow [? ], and prominent organizations including Google andInternet2 have built production networks based on OpenFlow [? ].
But although SDNs make it possible to control the behavior ofthe network in software, current platforms do not make it easy towrite program that work on isolated subnetworks. NOX [? ], oneof the first SDN platforms, provides only a thin veneer over theunderlying hardware, so programmers must manage switch-levelresources such as forwarding rules and virtual LANs (VLANs) byhand. To ensure isolation, programmers must establish and main-tain their own ad hoc conventions without compiler support. Forexample, if two independently-developed NOX programs wish toshare a network, they must agree on some protocol to keep thetraffic of the two networks separate, and NOX provides no helpin ensuring that such agreements will be implemented correctly.NetCore [? ], another language for programming SDNs, also lacksconstructs for expressing or enforcing isolation properties.
Besides needing isolation for security, one often wants to iso-late the behavior of several modules within a single program. Hereagain, languages like NOX and NetCore are no help. For example,the NOX tutorial explains how to develop a basic Ethernet learningswitch module that learns the association of Ethernet addresses toswitch port numbers. However, the learning switch must also oper-ate side-by-side with another module that discovers the topology ofthe network by probing the network with LLDP packets. To avoiddisrupting the discovery module, the learning switch code includesexplicit instructions to ignore LLDP packets:
# don’t forward lldp packets
Contribu-ons
• A new language for slices.
34
B A2 A1 A3 A4
NetCo
re
Contribu-ons
• A new language for slices.
• A compiler that enforces isola-on.
35
B A2 A1 A3 A4
Slice Compiler
B A3 A4 A2 A1
N O X , N e W l e , F l o o d l i g h t , e t c .
Contribu-ons
• A new language for slices.
• A compiler that enforces isola-on.
• A verifier that guarantees:
36
B A2 A1 A3 A4
Slice Compiler
NetCo
re
B A3 A4 A2 A1
N O X , N e W l e , F l o o d l i g h t , e t c .
Contribu-ons
• A new language for slices.
• A compiler that enforces isola-on.
• A verifier that guarantees: – isola-on
37
B A2 A1 A3 A4
Slice Compiler
NetCo
re
B A3 A4 A2 A1
N O X , N e W l e , F l o o d l i g h t , e t c .
Contribu-ons
• A new language for slices. – Security – Modularity
• A compiler that enforces isola-on.
• A verifier that guarantees: – isola-on, and – seman-c equivalence.
38
B A2 A1 A3 A4
Slice Compiler
NetCo
re
B A3 A4 A2 A1
N O X , N e W l e , F l o o d l i g h t , e t c .
≅
3 9
Thank you! Read the paper:
frene-c-‐lang.org/papers
Get the code: github.com/frene-c-‐lang/netcore
See the demo: Find me a4er the talk!
We wish to thank Shrutarshi Basu, Arjun Guha, Josh Reich, Mark ReitblaL, Jennifer Rexford, and David Walker for many helpful comments and sugges-ons.
THE END
40
Re-‐imagining the fundamentals of network implementa-on from a programming languages point of view: • How does one read the state of the network? • How does one write the state of the network? • How does one define a new (virtual) network? • How does one compose two network programs?
Frene-c is a new programming language we are crea-ng to explore these ques-ons and more
42
T h e S DN C o n t r o l l e r
One program to ru le them a l l …
NetCore: Program Composi-on
PaWern AcZon
inPort = 2 Forward 1
inPort = 1 Forward 2
43
PaWern AcZon
tpSrc = 22 Drop
tpSrc = 80 Drop
Repeater Monitor
NetCore: Program Composi-on
PaWern AcZon
inPort = 2 Forward 1
inPort = 1 Forward 2
44
PaWern AcZon
tpSrc = 22 Drop
tpSrc = 80 Drop
Repeater Monitor
Ne t Co r e
Repeater Monitor
45
S1 S4 S2 S3
S1 S4 S2 S3
S1 S4 S2 S3
VLAN-‐based Isola-on
Slice Compiler
46
S1 S4 S2 S3
S1 S4 S2 S3
S1 S4 S2 S3
VLAN-‐based Isola-on
VLAN=2
VLAN=1
Slice Compiler
47
S1 S4 S2 S3
S2 S3
S2 S3 VLAN=2
VLAN=1
VLAN-‐based Isola-on
Slice Compiler
Topology
Data Center Isola-on
A2 A1
R1 R2 R3
H11 H12 H21 H22 H31 H32
48
Client 1
A2 A1
R1 R2 R3
H11 H12 H21 H22 H31 H32
49
Controller 1
Client 2
A2 A1
R1 R2 R3
H11 H12 H21 H22 H31 H32
50
Controller 2
Client 1 + Client 2
A2 A1
R1 R2 R3
H11 H12 H21 H22 H31 H32
Overlap
Client 2
Client 1
51
Controller 2 Controller 1 +
Client 2 injects packets into Client 1’s sec-on of the network!
A2 A1
R1 R2 R3
H11 H12 H21 H22 H31 H32
Overlap
Client 2
Client 1
52
Controller 2 Controller 1 +
Client 2 intercepts packets from Client 1’s sec-on of the network!
A2 A1
R1 R2 R3
H11 H12 H21 H22 H31 H32
Overlap
Client 2
Client 1
53
Controller 2 Controller 1 +
Client 1 Client 2
A2 A1
R2 R3
H22 H31 H32
A2 A1
R1 R2
H11 H12 H21
54
Controller 2 Controller 1 |
55
Controller 1 Controller 2
A2 A1
R2 R3
H22 H31 H32
A2 A1
R1 R2
H11 H12 H21
Hypervisor
PORT == 80
PORT != 80
Isola-on as Modularity
56
B A2 A1 A3 A4
Mul--‐part Controller Program
Isola-on as Modularity
57
B A2 A1 A3 A4
ARP
Isola-on as Modularity
58
B A2 A1 A3 A4
ARP LLDP
Isola-on as Modularity
59
B A2 A1 A3 A4
ARP LLDP
NAT
Isola-on as Modularity
60
B A2 A1 A3 A4
ARP LLDP
NAT
IP RouZng
Read-‐only Slices
61
• Network monitoring • Usage-‐based billing
B A
Precise Seman-cs
62
Contribu-ons
63
Contribu-ons
• A new language for slices.
64
B A2 A1 A3 A4
Slices
65
A2 A1
R1 R2 R3
Slices
66
A2 A1
R1 R2 R3
A2 A1
R1 R2
Slices
67
A2 A1
R1 R2 R3
A2 A1
R1 R2
Slices
68
A2 A1
R1 R2 R3
A2 A1
R1 R2
Programming with Slices
69
Ethernet type: 0x0806
Programming with Slices
70
Ethernet type: 0x0806
Ethernet type: 0x0800
Programming with Slices
71
Ethernet type: 0x0806
Ethernet type: 0x0800
Contribu-ons
• A new language for slices.
• A compiler that enforces isola-on.
72
B A2 A1 A3 A4
Slice Compiler
73
S1 S4 S2 S3
S1 S4 S2 S3
S1 S4 S2 S3
VLAN-‐based Isola-on
74
S1 S4 S2 S3
S1 S4 S2 S3
S1 S4 S2 S3
VLAN-‐based Isola-on
VLAN=2
VLAN=1
75
S1 S4 S2 S3
S2 S3
S2 S3 VLAN=2
VLAN=1
VLAN-‐based Isola-on
Contribu-ons
• A new language for slices.
• A compiler that enforces isola-on.
76
B A2 A1 A3 A4
Slice Compiler
B A3 A4 A2 A1
NetCo
re
Contribu-ons
• A new language for slices.
• A compiler that enforces isola-on.
77
B A2 A1 A3 A4
Slice Compiler
B A3 A4 A2 A1
NetCo
re
Contribu-ons
• A new language for slices.
• A compiler that enforces isola-on.
78
B A2 A1 A3 A4
Slice Compiler
B A3 A4 A2 A1
N O X , N e W l e , F l o o d l i g h t , e t c .
Contribu-ons
• A new language for slices.
• A compiler that enforces isola-on.
• A verifier that guarantees:
79
B A2 A1 A3 A4
Slice Compiler
B A3 A4 A2 A1
Contribu-ons
• A new language for slices.
• A compiler that enforces isola-on.
• A verifier that guarantees: – isola-on
80
B A2 A1 A3 A4
Slice Compiler
B A3 A4 A2 A1
Contribu-ons
• A new language for slices.
• A compiler that enforces isola-on.
• A verifier that guarantees: – isola-on, and – seman-c equivalence.
81
B A2 A1 A3 A4
Slice Compiler
B A3 A4 A2 A1
≅
Verifying the Results
82
NetCo
re
B A3 A4 A2 A1
Encoded using SMT (Z3)
Encoded using model checking
(NuSMV)
Contribu-ons
• A new language for slices.
• A compiler that enforces isola-on.
• A verifier that guarantees: – isola-on, and – seman-c equivalence.
83
B A2 A1 A3 A4
Slice Compiler
B A3 A4 A2 A1
≅
8 4
Thank you! Read the paper:
frene-c-‐lang.org/papers
Get the code: github.com/frene-c-‐lang/netcore
85
86
A2 A1
R1 R2
H11 H12 H21
Integrity
A2 A1
R1 R2 R3
H11 H12 H21 H22 H31 H32
1 Slice 2 cannot inject packets into Slice 1.
87
A2 A1
R1 R2
H11 H12 H21
Integrity
A2 A1
R1 R2 R3
H11 H12 H21 H22 H31 H32
1 Slice 2 cannot inject packets into Slice 1.
88
A2 A1
R1 R2
H11 H12 H21
Integrity
R1 R3
H11 H12 H21 H22 H31 H32
A2 A1
R2
1 Slice 2 cannot inject packets into Slice 1.
89
A2 A1
R1 R2
H11 H12 H21
Integrity
R1 R3
H11 H12 H21 H22 H31 H32
A2 A1
R2
1 Slice 2 cannot inject packets into Slice 1.
90
Confiden-ality
A2 A1
R1 R2 R3
H11 H12 H21 H22 H31 H32
A2 A1
R2 R3
H22 H31 H32
Slice 2 cannot siphon packets from Slice 1.
91
Confiden-ality
A2 A1
R1 R2 R3
H11 H12 H21 H22 H31 H32
A2 A1
R2 R3
H22 H31 H32
Slice 2 cannot siphon packets from Slice 1.
92
Confiden-ality
A2 A1
R1 R2 R3
H11 H12 H21 H22 H31 H32
A2 A1
R2 R3
H22 H31 H32
Slice 2 cannot siphon packets from Slice 1.
93
Confiden-ality
A2 A1
R1 R2 R3
H11 H12 H21 H22 H31 H32
A2 A1
R2 R3
H22 H31 H32
Slice 2 cannot siphon packets from Slice 1.
Establishing Isola-on
• Confiden-ality and integrity are global, end-‐to-‐end proper-es.
• But we can establish isola-on by enforcing simple, local proper-es.
94
Implementa-on
• VLAN-‐based implementa-on.
95
Verifica-on
• SAT encoding (with Z3) • Separate: given two compiled slices, guarantee that they are separate.
• SemanZcs-‐preserving: given a source slice + program and a compiled program, verify that they are seman-cally equivalent.
96
Read the paper: hLp://www.cs.princeton.edu/~cschlesi Download the code: hLps://github.com/frene-c-‐lang/netcore
97
98
Isola-on as Modularity
• Queries/network monitoring. • ARP
99
PORT != 80
A2 A1
R2 R3
H22 H31 H32
A2 A1
R1 R2
H11 H12 H21
PORT == 80
100
Controller 1 Controller 2
One approach: like SFI
• Draw a box around each network program and prevent them from broaching their respec-ve boxes (slices). – Absolute. – Says nothing about what happens within a slice.
• FlowVisor takes this approach.
101
Problem: Very Coarse-‐grained
• 1: We want isola-on and seman-cs preserving by construc-on.
• 2: We want read-‐only slices. – Consider an admin/billing slice that monitors use. Isola-on is too strong, but without isola-on, what do we have?
• 3: Isola-on as modularity.
102
Limita-ons
• Isola-on as modularity.
• Inter-‐slice interac-on.
• Intra-‐slice seman-cs.
103
?
B A
ARP A2 A3 A4
Splendid
Isolation HotSDN Cole Schlesinger
Au g . 2 0 1 2
Jo in t work w i th :
D a v i d Wa l k e r S t e phen Gu t z A l e c S t o r y N a t e F o s t e r
36 www.cornelllogo.cornell.edu Revised March 2007
One-color printing
When only one-color printing is available, the insignia, logotype, and name of college, school, or unit should be printed positive—in black or Cornell Red.
The insignia, logotype, and name of college, school, or unit also can be reversed out of any color to white, as shown.
36 www.cornelllogo.cornell.edu Revised March 2007
One-color printing
When only one-color printing is available, the insignia, logotype, and name of college, school, or unit should be printed positive—in black or Cornell Red.
The insignia, logotype, and name of college, school, or unit also can be reversed out of any color to white, as shown.
