Principles of Network Security

Managing and Securing Computer Networks Guy Leduc Chapter 2: Software-Defined Networks (SDN)

Mainly based on: Computer Networks and Internets, 6th Edition Douglas E. Comer Pearson Education, 2015 (Chapter 31)

2: Software-Defined Networks

2-1

Chapter 2 Chapter goals: ❒  The previous chapter introduces the topic of

network management, describes the general idea of element management, and explains the widespread SNMP protocol and related concepts

❒  This chapter addresses a new promising technology

for network management: SDN ❍  Motivation ❍  General approach ❍  Technology


2-2

1

Chapter 2 outline ❒  Motivation ❒  Control plane and data plane division ❒  The SDN paradigm ❒  OpenFlow: A controller-to-device protocol ❒  Classification engines in switches (TCAM) ❒  Extended forms of forwarding ❒  The economics of SDN


2-3

Motivation for a new approach ❒  Why changing the network management

paradigm?

❍  Generalize

element management to network management ❍  Move from proprietary to open standards ❍  Automate and unify network-wide configuration ❍  Change from per-layer to cross-layer control ❍  Accommodate virtualization used in data center


2-4

2

Generalization to network management ❒  Traditional network management (e.g., SNMP) ❍ 

Deals with individual network elements

❍ 

A manager configures a router, measures a leased circuit, detects a failure of a switch, …

❒  Element management is arguably a low-level idea ❒  It should be replaced by a system that allows a manager

to issue commands that control the entire network ❍ 

All elements should not necessarily work exactly the same

❍ 

But they have to work together to achieve a high-level management policy


2-5

Move from proprietary to open standards ❒  Current devices include a vendor-specific

management interface (e.g., specific CLI) ❒  Even when a vendor implements SNMP, it includes special extensions that only apply to the vendor’s hardware ❒  This perpetuates an approach in which individual elements are managed separately ❒  Goal: an open standard would allow the coordination of operations of multiple devices from multiple vendors


2-6

3

Automate and unify network-wide configuration ❒  Configuring individual elements by humans is an error-

prone process!

❒  Configurations may have to be tailored to the location,

the role, and the type of the device ❍ 

Internal device? Edge device?

❒  Network-wide consistency is needed but hard to ensure,

especially at larger scales

❒  Idea: translate a general network-wide policy into

appropriate configurations for each network element


2-7

Change to cross-layer control ❒  Traditional network management divides

responsibilities according to network layers: ❍ 

Layer-2 services: switches, VLANs, bridged networks

❍ 

Layer-3 services: IP address assignment, subnetting, IP routes

❍ 

MPLS

❒  This misses larger cross-layer opportunities, e.g. ❍ 

Creating VLANs for certain types of IP traffic

❍ 

An appendix on VLANs is provided at the end of the chapter


2-8

4

Accommodate Data Center Virtualization ❒  Most data centers use virtualization technology (e.g.,

VMWare) ❍  ❍ 

❍  ❍ 

A physical machine emulates multiple Virtual Machines (VMs) Each VM runs a copy of an OS, and needs its own IP addresses VMs can migrate from one physical computer to another Migrations may occur frequently and in tens of msecs

❒  When a VM moves ❍  Network devices must be reconfigured for correct packet delivery ❍  And conventional network management tools are inadequate to handle frequent high-speed route changes 2: Software-Defined Networks

2-9



2-10

5

Control plane and data plane ❒  Network devices have internal architectures divided

into two parts: ❍  ❍ 

Control plane Data plane

❒  Control plane: ❍  Management functionality (configuration, monitoring, …) ❍  Control functionality (routing protocols, MPLS label distribution, RSVP, …) ❍  In software, slower speed, infrequent, possible human interaction ❒  Data plane: ❍  Packet processing, at line rates ❍  Usually in hardware, highly optimized 2: Software-Defined Networks

2-11

Classical division into control and data planes Control plane (software) a

Packets arrive

b

Data plane (hardware) c

Packets leave

a. data plane passes control packets up to control plane b. control plane loads new configuration into the hardware c. data packets are switched in the data plane, unless errors occur (possibly leading to error reports via ‘a’) 2: Software-Defined Networks

2-12

6

Multiple control modules and one common interface CLI WEB SNMP

❒  3 popular external

interfaces:

…

❍  ❍ 

Common interface (internal)

Packets arrive

Data plane (hardware)

❍ 

Common Line Interface (CLI), accessed using ssh WEB interface, accessed via a browser (HTTP) SNMP agent, accessed by SNMP management applications

❒  Each control module Packets leave

invokes the common interface to perform operations ❒  The internal interface is only accessible by the modules sold by the vendor 2: Software-Defined Networks

2-13



2-14

7

SDN model: external controller External controller

❒  SDN moves all control

CLI WEB SNMP SDN

Common interface (internal)

Packets arrive

Data plane (hardware)

Packets leave

plane functions out of each network element and places them in an external controller (typically a PC running Linux) ❒  Light SDN functionality in the node ❒  Applicable to classical embedded control functions such as routing ❍ 

Centralized routing!


2-15

Remaining questions ❒  What is the physical connection between an external

controller and a network element ? ❒  What protocol is used over that connection? More generally

❒  What management software does an external controller

run? Where does it come from? ❒  Does an external controller increase the cost of a network? ❒  How will SDN affect the network industry and network vendors? 2: Software-Defined Networks

2-16

8

Shared controllers ❒  A controller has enough processing power to handle

multiple network elements ❍  ❍ 

❍ 

Most network management applications are not CPU intensive Multiple physical copies of a given device may easily be configured or controlled by a single controller (e.g., a set of wireless APs) Sharing controllers is cost-effective!

❒  How many controllers in a network? ❍  Depends on many factors: •  •  •  •  • 

Size of network Variety of network elements Replication factor of each network element Variety and load of management applications Physical clustering of equipments 2: Software-Defined Networks

2-17

SDN domain Controller 1

Controller 2

Controller 3

Controller to controller

Controller to controller

Controller to element

Controller to element

SDN domain 1

SDN domain 2

SDN domain 3

❒  Arrangement of SDN controllers in a large intranet ❒  Controllers communicate to ensure consistency of

policies and of configurations ❒  C-to-C and C-to-E protocols must be standardized ❍  ❍ 

Application layer protocols (as in SNMP) over TCP/IP Management traffic over the managed network (as in SNMP) 2: Software-Defined Networks

2-18

9



2-19

The OpenFlow protocol ❒  The only SDN protocol with wide acceptance in the

industry ❒  Initiated at Stanford, now controlled by the Open Network Foundation ❒  Communication paradigm: ❍ 

Connection-oriented, over TCP, SSL/TLS allowed for security

❒  Item definition and classification ❍  ❍  ❍ 

Does not follow the SNMP approach of defining a large MIB Focuses on packet forwarding in network elements Based on a flow table model (see later)

❒  Message format ❍  ❍ 

Defines OpenFlow message format and semantics of fields Some encoding predefined (e.g., integers in big endian order) 2: Software-Defined Networks

2-20

10



2-21

Classification engines in switches ❒  OpenFlow designed with Ethernet switches in mind ❒  The data plane in a high-end switch consists of a piece of

hardware known as the classification engine ❍  ❍  ❍  ❍ 

Which decides how to forward arriving packets Pattern-matching system Set of patterns with associated actions Patterns can contain “don’t care” for some bits in header

(headers of) packet to be matched pattern 1

action 1

pattern 2

action 2

pattern N (default that matches any packet)

action N


2-22

11

TCAM and High-Speed Classification ❒  Hardware-based classifiers can perform the

comparisons in one step ❒  TCAM = Ternary Content Addressable Memory ❍ 

❍ 

Content addressable: TCAM does not merely store values, but each memory cell contains logic that can perform bitwise comparison Ternary: three values: 0, 1, don’t care

❒  When a packet has been placed in the TCAM

hardware, all the pattern matchers receive a copy of the bits of the packet and they all act at the same time : complexity O(1) ❒  A match returns the associated action (an integer) ❒  If multiple matches, choose one, typically the lowest position in the list (smallest integer) 2: Software-Defined Networks

2-23

Classification across multiple layers ❒  A single classification pattern can check items from

multiple layers of the protocol stack at the same time

❒  Useful to express policies on flows ❒  Example: web traffic ❍ 

Layer 2 header specifies: “Frame type field = IP”

❍ 

Layer 3 header specifies: “IP protocol field = TCP”

❍ 

Layer 4 header specifies: “Destination port = 80”

❍ 

Could also check that HTTP header is present, etc.

❒  Efficient: Avoids the demultiplexing used in

conventional protocol stacks

❒  However, options in headers make things complex ❍ 

Multiple patterns are needed to accommodate combinations of options


2-24

12

Items OpenFlow can specify ❒  When an external controller sends an OpenFlow message with

values for specific fields, a switch creates a classification pattern

❒  Examples of layer 2 fields: ❍  ❍  ❍  ❍  ❍ 

Ingress port Source and destination MAC addresses Frame type VLAN id and priority ARP opcode

❒  Examples of layer 3 (+ layer 2.5) fields: ❍  ❍  ❍  ❍  ❍ 

IPv4 and IPv6 source and destination addresses, possibly prefixes IPv4 protocol type IPv6 next header IPv4 and IPv6 TOS byte MPLS label and 3-bit traffic class

❒  Examples of layer 4 fields: ❍  ❍ 

TCP/UDP/… source and destination port numbers ICMP type and code 2: Software-Defined Networks

2-25



2-26

13

Traditional and Extended IP forwarding ❒  OpenFlow can configure all the forms of IP

forwarding, including multicast and broadcast ❒  Thanks to “don’t care” bits, a default route can also be specified ❒  But OpenFlow also allows new forms of forwarding ❍  based

on source addresses ❍  based on layer-4 fields ❒  Comparable to MPLS traffic engineering

capabilities


2-27

Other capabilities SDN/OpenFlow can offer ❒  OpenFlow can be used to create MPLS paths

dynamically, and use classifiers to assign IP packets to MPLS paths (also adding label) at ingress (and remove it at egress) ❒  Knowing that IPv4 and IPv6 addresses may change over time, it is weak to define security policies based on source addresses ❍  ❍ 

❍ 

Instead, using source MAC addresses is more robust This also ensures that IPv4 and IPv6 forwarding are consistent VLAN ids may also be used


2-28

14

Dynamic rule creation and control of flows ❒  OpenFlow allows a controller to install or remove classification

rules dynamically

❒  More important, new rules can be created when packets arrive ❒  If the default rule redirects the packets (matching no existing

rules) to the SDN controller, the software on the controller can ❍  ❍  ❍ 

decide how the packet should be processed install a new rule in the switch (and possibly in other switches) forward the packet back to the switch for processing

❒  Subsequent packets from the same “flow” will benefit from the

new rule ❍  ❍ 

Per-flow routing system E.g., load balancing of new TCP connections over multiple paths depending on the current load of the paths (known by the controller) 2: Software-Defined Networks

2-29

A pipeline model for flow tables packets arrive

Data plane Flow table 1

Flow table 2

Flow table 3

packets leave

❒  In addition to hardware-based classification mechanisms, OpenFlow includes

functions that can be used with software-based classification

❒  This adds significant functionality ❒  Example: a pipeline of flow tables ❍ 

❍ 

Each flow table specifies a set of classification rules and actions for each rule, e.g., •  IP datagram encapsulation in MPLS or in another outer IP datagram •  Extracting an inner packet from a previous encapsulation •  Packet inspection, packet encryption, etc. Once a packet has been processed by a flow table, it can be forwarded or passed to the next flow table in the pipeline

❒  OpenFlow also arranges to pass Metadata along with each packet ❍ 

❍ 

This makes it possible for an early stage to gather data from a packet, look up information, and pass the information to successive stages E.g., the 1st stage chooses a next hop for the packet, the 2nd stage can encrypt the packet, and the 3rd stage can forward the encrypted packet to the next hop without decrypting a copy to compute the next-hop address 2-30 2: Software-Defined Networks

15



2-31

SDN’s potential effect on network vendors ❒  In a broad sense, SDN removes control plane functionality from the

underlying network elements, leaving only a data plane technology ❒  But vendors used control plane functionality to differentiate their equipment from competitors’ equipment ❍ 

Leading to homogeneous, easier to manage networks

❒  With SDN, no more motivation to purchase all the equipment from a ❒  ❒  ❒  ❒  ❒ 

single vendor Data plane hardware will become a commodity, only price and performance will matter Vendors accustomed to continual demand and high profit margins may find it difficult to compete in a commodity market SDN has the potential to undercut profits of current network vendors A new industry can arise to build and sell vendor-independent network management software Adoption of SDN will likely mean a move away from the current scheme of proprietary management software and vertical integration 2: Software-Defined Networks

2-32

16

SDN: summary ❒  Control plane removed from network elements and ❒  ❒  ❒  ❒  ❒  ❒ 

placed in separate controllers One part of the SDN paradigm has been defined: OpenFlow protocol Based on (pipelines of) flow tables TCAM-based packet matching New forms of forwarding possible Per-flow routing possible Potential changes in the networking industry


2-33

Chapter 2 – Appendix on VLANs ❒  Switches have been extended by adding

virtualization (VLAN switch) ❒  A VLAN switch emulates multiple, independent switches ❒  We will review ❍  ❍  ❍  ❍ 

The motivation for VLANs Their technology VLANs spanning multiple physical switches The need for an extra field in the frame (VLAN tag)


2-34

17

VLANs: motivation Consider:

❒  CS user moves office to EE,

but wants to connect to CS switch? ❒  single broadcast domain: ❍ 

❍ 

Computer Science

Electrical Engineering

Computer Engineering

all layer-2 broadcast traffic (ARP, DHCP, unknown location of destination MAC address) must cross entire LAN security/privacy, efficiency issues

❒  each lowest level switch may

have only few ports in use


VLANs

Port-based VLAN: switch ports grouped (by switch management software) so that single physical switch …

Virtual Local Area Network Switch(es) supporting VLAN capabilities can be configured to define multiple virtual LANS over single physical LAN infrastructure

2-35

1

7

9

15

2

8

10

16

…

…

Electrical Engineering (VLAN ports 1-8)

Computer Science (VLAN ports 9-15)

… operates as multiple virtual switches 1

7

9

15

2

8

10

16

…

…


Computer Science (VLAN ports 9-16)


2-36

18

Port-based VLAN router

traffic isolation: frames to/ from ports 1-8 can only reach ports 1-8

❒ 

❍ 

can also define VLAN based on MAC addresses of endpoints, rather than switch port

dynamic membership: ports can be dynamically assigned among VLANs

❒ 

1

7

9

15

2

8

10

16

…

… Computer Science (VLAN ports 9-15)


forwarding between VLANs: done via routing (just as with separate switches)

❒ 

❍ 

in practice vendors sell combined switches plus routers 2: Software-Defined Networks

2-37

VLANs spanning multiple switches 1

7

9

15

1

3

5

7

2

8

10

16

2

4

6

8

… Electrical Engineering (VLAN ports 1-8)

❒ 

… Computer Science (VLAN ports 9-15)

Ports 2,3,5 belong to EE VLAN Ports 4,6,7,8 belong to CS VLAN

trunk port: carries frames between VLANs defined over multiple physical switches ❍  ❍ 

frames forwarded within VLAN between switches can’t be vanilla 802.1 frames (must carry VLAN ID info) 802.1q protocol adds/removes additional header fields for frames forwarded between trunk ports 2: Software-Defined Networks

2-38

19

802.1Q VLAN frame format Type

802.1 frame

802.1Q frame When the field following the 2 2-byte Tag Protocol Identifier Recomputed addresses is 0x8100 (> 1500), (value: 81-00) CRC it’s a 802.1Q frame •  3-bit priority field has nothing to do with VLANs, it’s used for QoS Tag Control Information (12 bit VLAN ID field, 3 bit priority field like IP TOS) •  When a frame has no tag on a trunk line, there is a default VLAN id which the frame is considered to be associated with •  Tags can be stacked • 


2-39

20