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

Transcription

1 Managing and Securing Computer Networks Guy Leduc Chapter 2: Software-Defined Networks (SDN) Mainly based on: Computer Networks and Internets, 6 th Edition Douglas E. Comer Pearson Education, 2015 (Chapter 31) 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

2 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

3 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

4 Automate and unify network-wide configuration Configuring individual elements by humans is an errorprone 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

5 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-9 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

6 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-11 Classical division into control and data planes a Control plane (software) b a. data plane passes control packets up to control plane b. control plane loads new configuration into the hardware Packets arrive Data plane (hardware) c Packets leave c. data packets are switched in the data plane, unless errors occur (possibly leading to error reports via a )

7 Multiple control modules and one common interface Packets arrive CLI WEB SNMP Common interface (internal) Data plane (hardware) Packets leave 3 popular external interfaces: Common Line Interface (CLI), accessed using ssh WEB interface, accessed via a browser (HTTP) SNMP agent, accessed by SNMP management applications Each control module invokes the common interface to perform operations The internal interface is only accessible by the modules sold by the vendor 2-13 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

8 SDN model: external controller External controller CLI WEB SNMP SDN Common interface (internal) SDN moves all control 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 Packets arrive Data plane (hardware) Packets leave 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?

9 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-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)

10 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-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)

11 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-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

12 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-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

13 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-25 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

14 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

15 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-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 1 st stage chooses a next hop for the packet, the 2 nd stage can encrypt the packet, and the 3 rd stage can forward the encrypted packet to the next hop without decrypting a copy to compute the next-hop address

16 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-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

17 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)

18 VLANs: motivation Computer Science Electrical Engineering Computer Engineering Consider: CS user moves office to EE, but wants to connect to CS switch? single broadcast domain: 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 2-35 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 1 2 Electrical Engineering (VLAN ports 1-8) Computer Science (VLAN ports 9-15) operates as multiple virtual switches Electrical Engineering (VLAN ports 1-8) Computer Science (VLAN ports 9-16)

19 Port-based VLAN 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 1 7 router 9 15 dynamic membership: ports can be dynamically assigned among VLANs forwarding between VLANs: done via routing (just as with separate switches) in practice vendors sell combined switches plus routers 2 Electrical Engineering (VLAN ports 1-8) Computer Science (VLAN ports 9-15) 2-37 VLANs spanning multiple switches 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 frames (must carry VLAN ID info) 802.1q protocol adds/removes additional header fields for frames forwarded between trunk ports

20 802.1Q VLAN frame format Type frame 802.1Q frame When the field following the 2 addresses is 0x8100 (> 1500), it s a 802.1Q frame 3-bit priority field has nothing to do with VLANs, it s used for QoS 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-byte Tag Protocol Identifier (value: 81-00) Recomputed CRC Tag Control Information (12 bit VLAN ID field, 3 bit priority field like IP TOS)