You can keep your firewall (if you want to) Practical, simple and cost saving applications of OpenDaylight you can implement today

Transcription

1 You can keep your firewall (if you want to) Practical, simple and cost saving applications of OpenDaylight you can implement today John Sobanski, Engineer, Solers Inc. July #OpenSDN

2 What You Will Learn today (By Demonstration) 10,000 Foot Views of Software Defined Networking (SDN), OpenDaylight (ODL) and Service Function Chains (SFC) Solve real world data center problems with ODL RESTCONF API ODL Service Function Chaining Feel free to contact me for any details I don't cover here jsobanski@solers.com 2

3 Top three emerging technologies of the decade? My take Big Data DevOps Software Defined Networks Any Others? 3

4 Is SDN Hype? Big Data and DevOps have clear applications and use cases but Software Defined Networks appears to be a solution in search of a problem. Most SDN activity is focused in Academia or dedicated Network Function Virtualization (NFV) shops... not relevant to us. "SDN/ NFV only applies to Greenfield Architectures." These slides will prove these opinions wrong 4

5 Who cares about networks? Answer: You Do! Network latency and/ or loss breaks services. 5

6 Latency and Loss doesn t apply to my Data Center Latency and Loss? I've got dozens of 10GbE ports!!! Layer 2: Spanning tree protocol Blocks all but one path to prevent loops (Enable LACP/ LAG) Layer 3: Shortest path first Sends all traffic through a congested "one hop" path over a wide open "two hop" path (Try Traffic Engineering) Layer 4: Default TCP buffers Small buffers mean more round trips. Latency throttles throughput. (Tune the buffer) You need to care about the network! 6

7 What are Network Services? Familiar Network Services Load Balancing Firewall Deep Packet Inspection (DPI) Access Control Lists Parental Control Other Network Services "Global State" (Routing) Broadcast Domain Scoping (VLAN) Resource Signaling Prioritization and Preemption Multicast N-Cast 7

8 10,000 Foot Overview 10,000 Foot view of SDN At any give time, use a centralized controller to move data through your network equipment as you see fit Doesn't seem like a big deal to non-network types but this is incredibly powerful! 10,000 Foot view of OpenDaylight Allows you to install network services as "Apps" Provides a single REST API to configure heterogeneous hardware This is a no brainer for developers but is HUGE for network engineers 10,000 Foot view of Service Function Chains Service Overlay Divorce Network Services From Topology For more detail see:

9 A Little More Detail: SDN Layers Top Layer Northbound Network Apps & Orchestration Business logic to monitor and control network behavior Thread services together Middle Layer Controller Platform Exposes "Northbound" APIs to the Application layer Lower Layer Southbound Command and control of hardware Network Devices (Physical or Virtual) Switches, Routers, Firewalls etc. 9

10 A Little More Detail: OpenDaylight OpenDaylight Open source project Modular/ Pluggable and flexible controller platform Java Virtual Machine (JVM) Dynamically Pluggable Modules for Network Tasks OSGi framework (local applications)/ bidirectional REST (local or remote) for the northbound API Network Apps House business logic and algorithms Gather network intelligence from the controler Run algorithms to perform analytics Orchestrate new rules (if any) via controller Southbound OpenFlow 1.3, OVSDB, SNMP, CLI Service Abstraction Layer links Northbound to Southbound 10

11 A Little More Detail: ODL 11

12 A Little More Detail: SFC SFC enables a service topology Overlay built on top of existing network topology Use any overlay or underlay technology to create service paths VLAN, ECMP, GRE, VXLAN, etc. SFC provides resources for consumption Service Topology connects those resources Quickly/ Easily add new service functions Requires no underlying network changes 12

13 One Caveat Before we begin WARNING: Software Defined Networking is incredibly powerful! You must protect your Southbound interfaces with the same regard as a firewall or any root privileges ODL accommodates TLS for Southbound interfaces The security, identity and bureaucratic planes are orthogonal to the technology plane we discuss here We do not discuss security, identity or policy but you must consider them when architecting your ODL solution 13

14 One more Caveat WARNING: If you are not a hands-on network engineer, this presentation may "spoil" you. To provide the following two OPSCON using legacy protocols may be impossible and at the very least requires intense, disciplined, meticulous network engineering. 14

15 DPI Bypass Approach #1: RESTCONF API 15

16 OPSCON #1: Deep Packet Inspection Bypass This scenario investigates how to reduce latency You have a data center that performs deep packet inspection (DPI) for inter-network flows DPI injects latency into the end to end (E2E) flow and increases Round Trip Time (RTT) Reminder: Network latency and loss breaks services! 16

17 Topology Network gateways in Firewall/ DPI appliance VLAN steer (bent pipe) traffic through DPI (via gateways) for inter-network flows Can we create logic to DPI only once? 17

18 One Approach Put logic (i.e. rules) in the DPI appliance to bypass certain flows This, however consumes resources and can saturate the backplane Put logic here? 18

19 Better Approach Use the OpenDaylight controller and put logic in the switch! Put logic here! 19

20 OPSCON #1 Detailed Topology 20

21 DPI Bypass Demo Approach #1: RESTCONF API Note: This section will be a live demonstration 21

22 Step 1: Start ODL Platform via Client Platform includes controller Install Network Apps via command line 22

23 Validate Topology Connect to controller and pingall 23

24 ODL Shows the Layer 2 Interfaces 24

25 Baseline: Two DPI = Severe Latency Ping from Client (h1) to Server (h3) shows 40+ ms latency mininet> h1 ping h3 PING ( ) 56(84) bytes of data. 64 bytes from : icmp_seq=1 ttl=62 time=42.1 ms 64 bytes from : icmp_seq=2 ttl=62 time=41.3 ms 64 bytes from : icmp_seq=3 ttl=62 time=41.1 ms ^C ping statistics packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = /41.546/42.143/0.465 ms 25

26 Baseline: End to End (E2E) Path Traceroute shows a path through the two DPI gateways, as expected mininet> h1 traceroute -n h3 traceroute to ( ), 30 hops max, 60 byte packets ms ms ms ms ms ms 3 * * ms mininet> 26

27 Configure Switch via ODL Platform REST API 27

28 Configure Switch via ODL Platform REST API Use these headers: Accept: application/xml Authorization: Basic YWRtaW46YWRtaW4= Then post the following flows (next slide) to Switch 2's table zero: PUT flow with ID 202 to PUT flow with ID 303 to 28

29 RESTCONF Flows (XML) 29

30 The Switch Accepts the Flows $ sudo ovs-ofctl -O OpenFlow13 dump-flows s2 cookie=0x0, duration= s, table=0, n_packets=0, n_bytes=0, priority=200,ip,nw_dst= actions=set_field:f6:2f:25:06:ab:27- >eth_dst,output:4 cookie=0x1, duration=33.552s, table=0, n_packets=0, n_bytes=0, priority=200,ip,nw_dst= actions=set_field:f2:3e:8d:a4:71:07- >eth_dst,output:5 30

31 Latency Reduced Ping now shows that the second, slow DPI is no longer in the path: mininet> h1 ping h3 PING ( ) 56(84) bytes of data. 64 bytes from : icmp_seq=1 ttl=63 time=21.3 ms 64 bytes from : icmp_seq=2 ttl=63 time=20.9 ms 64 bytes from : icmp_seq=3 ttl=63 time=20.7 ms ^C ping statistics packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = /20.983/21.320/0.252 ms 31

32 Latency Reduced Traceroute Confirms that the flow bypasses the second DPI mininet> h1 traceroute -n h3 traceroute to ( ), 30 hops max, 60 byte packets ms ms ms ms ms * 32

33 DPI Bypass Demo Approach #2: ODL SFC 33

34 A Little More Detail: ODL ODL Provides a Northbound SFC App 34

35 SFC Approach: Create a Service Overlay 1 1. Register Firewalls in service pool Service Functions 2. Configure switches to forward packets based on controller logic Service Function Forwarders 3. Configure SFC Logic Next Slide 2 3 #ODSummit

36 SFC Workflow (Highly Abstracted!) Register (Previous Slide) Service Functions (Appliances) -- AKA Network Services Service Function Forwarders (ODL SFC Controlled Switches) Create Service Function Chains Chain of Network Services I.e. First Firewall, then Apply Parental Control, then Virus Scan etc. Create Service Function Paths and Rendered Service Paths Selects path through actual appliance (SF) instances e.g. RSP-1 = Firewall-1, Parental-Control-1, Virus-Scan-1 RSP-7 = Firewall-3, Patental-Control-1, Virus-Scan-2 Create Classifier Apply SFC to flows #ODSummit

37 DPI Bypass Demo Approach #2: ODL SFC Note: This will be a live demo Based on: by Brady Johnson and Ricardo Noriega at Ericsson.com 37

38 Baseline No Flows in Switch, No Objects in GUI #ODSummit

39 Configure via REST API Add SF, SFF, SFC, SFP and RSP GUI Populated Controller then injects logic into SFF via flows $ sudo ovs-ofctl dump-flows sff1 -OOpenFlow13 #ODSummit

40 Test 1: Configure Classifier to Use RSP-1 tcpdump shows WGET goes through both service functions Total time: seconds SFF-1 Traffic SFF-2 Traffic #ODSummit

41 Test 2: Configure Classifier to Use RSP-3 tcpdump shows WGET goes through only one service functions Total time: seconds SFF-1: No Traffic SFF-2 Traffic #ODSummit

42 Backup Slides #ODSummit

43 OPSCON #2: Egress Bypass #ODSummit

44 OPSCON #2: Bypass DPI on Egress Scenario: You have a product distribution system where Egress throughput >> Ingress throughput. You perform Deep Packet Inspection on flows between External (EXT) hosts and your Demilitarized Zone (DMZ) Proxies. 44

45 Topology You implement a DPI "router on a stick," to ensure Inter-network communications pass through the DPI. A switch bent pipes the traffic at layer 2 45

46 Scenario The Egress traffic will increase past the capacity of the DPI appliance You realize that there are cheaper methods of securing your egress flows then upgrading to a bigger DPI appliance 46

47 Egress Security With egress flows you want to ensure that return/ ACK traffic does not include exploits and that egress flows do not facilitate zombies or phone home exploits. Some ideas: Ensure only approved ports Access Control Lists iptables Host firewalls Mitigate against malicious code over approved ports: HIDS on Servers Uni-directional bulk data push with Error Detection and Correction over one way fiber TLS with x509 certs 47

48 Trade Solutions END GOAL: You want to have DPI inspection on ingress flows, but not egress, since the other security measures will cover the egress flows. One approach is to put logic on your DPI appliance to say "don't scan egress flows," but that wastes capacity/ resources and could saturate the backplane An approach with legacy Network protocols is very difficult to implement and results in asymmetric routes (will break things) Using OpenDaylight, we have a simple solution that only requires matches/ actions on six (6) flows 48

49 The Goal When EXT initiates, pass through DPI When DMZ initiates: Bypass DPI on PUT (Egress) Scan on GET (Ingress) 49

50 Detailed Diagram 1. ACL 2. Scan all EXT DMZ 3. Bypass DMZ PUT 4. Scan DMZ GET 50

51 OpenFlow Logic 1. ACL only allows permitted flows 2. For Ingress ( EXT-> DMZ ) flows, allow normal path to virus scan via gateway 3. For Egress ( DMZ -> EXT ) PUT flows, intercept packet 1. Change destination MAC from Gateway to EXT 2. Change destination Port from Gateway to EXT 3. Decrement TTL by one 4. For Egress (DMZ -> EXT) GET flows (Treat as ingress) 1. DMZ uses dummy IP for EXT server 2. Switch intercepts packet 3. Switch changes source IP to dummy DMZ address 4. Switch changes dest IP to correct EXT IP 5. Packet continues on its way to gateway 6. Reverse logic for return traffic 51

52 OPSCON #2 Topology 52

53 OPSCON #2 Note: This will be a real time demo 53

54 Setup As before, start ODL, connect switch to controller and pingall 54

55 ODL Shows Connected L2 Interfaces 55

56 Baseline: Push a file from DMZ to EXT mininet> dmz curl --upload-file test.txt EXT Server Shows Successful PUT [10/Jul/ :50:22] "PUT /test.txt HTTP/1.1" TCPDUMP on firewall shows egress scan traffic (as expected) 56

57 Install the Flows via RESTCONF API Either via POSTMAN or CURL curl -v -H "Content-Type: application/xml" -X PUT --data -u admin:admin 2>&1 grep HTTP/1.1 curl -v -H "Content-Type: application/xml" -X PUT --data -u admin:admin 2>&1 grep HTTP/1.1 curl -v -H "Content-Type: application/xml" -X PUT --data -u admin:admin 2>&1 grep HTTP/1.1 curl -v -H "Content-Type: application/xml" -X PUT --data -u admin:admin 2>&1 grep HTTP/1.1 curl -v -H "Content-Type: application/xml" -X PUT --data -u admin:admin 2>&1 grep HTTP/1.1 curl -v -H "Content-Type: application/xml" -X PUT --data -u admin:admin 2>&1 grep HTTP/1.1 57

58 DMZ PUT a file to EXT mininet> dmz curl --upload-file test.txt The EXT server shows this second, successful put [10/Jul/ :50:22] "PUT /test.txt HTTP/1.1" [10/Jul/ :53:05] "PUT /test.txt HTTP/1.1" The firewall TCPDUMP, however does not show additional traffic! 58

59 Plumb Statistics via API You can see a Match on the flow through the REST API: 59

60 Test DMZ to EXT GET (Ingress) Use a Dummy IP to trigger a flow match. The egress port of the switch will NAT it back to the real destination IP. We see instant feedback on the Mininet Console 60

61 EXT Server Shows Successful Get [10/Jul/ :50:22] "PUT /test.txt HTTP/1.1" [10/Jul/ :53:05] "PUT /test.txt HTTP/1.1" [10/Jul/ :01:27] "GET / HTTP/1.1" Note Dummy IP 61

62 FW TCPDUMP Shows DMZ to EXT GET Scan 62

63 Verify All EXT DMZ Traffic Scan Do PUT and GET 63

64 DMZ Server Log Shows Success for Both 64

65 TCPDUMP: All EXT to DMZ traffic scanned 65

66 Thank You #ODSummit