You can keep your firewall (if you want to ) Practical, simple and - - PowerPoint PPT Presentation

▶
you can keep your firewall if you want to
SMART_READER_LITE
LIVE PREVIEW

You can keep your firewall (if you want to ) Practical, simple and - - PowerPoint PPT Presentation

Dec 12, 2023 205 likes •874 views

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 2015 @OpenDaylightSDN #OpenSDN What You Will Learn today (By

slide-1
SLIDE 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 2015 @OpenDaylightSDN #OpenSDN

slide-2
SLIDE 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 https://ask.opendaylight.org/users/420/runamuck/

2

slide-3
SLIDE 3

Top three emerging technologies of the decade?

  • My take…
  • Big Data
  • DevOps
  • Software Defined Networks

3

Any Others?

slide-4
SLIDE 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."

4

These slides will prove these opinions wrong

slide-5
SLIDE 5

“Who cares about networks?”

  • Answer: You Do! Network latency and/ or loss breaks services.

5

slide-6
SLIDE 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)

6

You need to care about the network!

slide-7
SLIDE 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

slide-8
SLIDE 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:
  • https://www.opennetworking.org/sdn-resources/sdn-definition
  • http://www.opendaylight.org/project/technical-overview
  • https://wiki.opendaylight.org/view/Service_Function_Chaining:Main

8

slide-9
SLIDE 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

slide-10
SLIDE 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

slide-11
SLIDE 11

A Little More Detail: ODL

11

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

slide-13
SLIDE 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

slide-14
SLIDE 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

slide-15
SLIDE 15

DPI Bypass

Approach #1: RESTCONF API

15

slide-16
SLIDE 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)

16

Reminder: Network latency and loss breaks services!

slide-17
SLIDE 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

slide-18
SLIDE 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

18

Put logic here?

slide-19
SLIDE 19

Better Approach

  • Use the OpenDaylight controller and put logic in the switch!

19

Put logic here!

slide-20
SLIDE 20

OPSCON #1 Detailed Topology

20

slide-21
SLIDE 21

DPI Bypass Demo

Approach #1: RESTCONF API Note: This section will be a live demonstration

21

slide-22
SLIDE 22

Step 1: Start ODL Platform via Client

  • Platform includes controller
  • Install Network Apps via command line

22

slide-23
SLIDE 23

Validate Topology

  • Connect to controller and “pingall”

23

slide-24
SLIDE 24

ODL Shows the Layer 2 Interfaces

24

slide-25
SLIDE 25

Baseline: Two DPI = Severe Latency

  • Ping from Client (h1) to Server (h3) shows 40+ ms latency

mininet> h1 ping h3 PING 10.0.3.101 (10.0.3.101) 56(84) bytes of data. 64 bytes from 10.0.3.101: icmp_seq=1 ttl=62 time=42.1 ms 64 bytes from 10.0.3.101: icmp_seq=2 ttl=62 time=41.3 ms 64 bytes from 10.0.3.101: icmp_seq=3 ttl=62 time=41.1 ms ^C

  • -- 10.0.3.101 ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 41.119/41.546/42.143/0.465 ms

25

slide-26
SLIDE 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 10.0.3.101 (10.0.3.101), 30 hops max, 60 byte packets 1 10.0.1.1 21.180 ms 21.028 ms 20.837 ms 2 10.0.2.1 42.565 ms 42.482 ms 42.418 ms 3 * * 10.0.3.101 43.144 ms mininet>

26

slide-27
SLIDE 27

Configure Switch via ODL Platform REST API

27

slide-28
SLIDE 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 http://<controller_ip>:8181/restconf/config/opendaylight- inventory:nodes/node/openflow:2/table/0/flow/202 PUT flow with ID 303 to http://<controller_ip>:8181/restconf/config/opendaylight- inventory:nodes/node/openflow:2/table/0/flow/303

28

slide-29
SLIDE 29

RESTCONF Flows (XML)

29

slide-30
SLIDE 30

The Switch Accepts the Flows

$ sudo ovs-ofctl -O OpenFlow13 dump-flows s2 cookie=0x0, duration=350.260s, table=0, n_packets=0, n_bytes=0, priority=200,ip,nw_dst=10.0.3.101 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=10.0.1.101 actions=set_field:f2:3e:8d:a4:71:07- >eth_dst,output:5

30

slide-31
SLIDE 31

Latency Reduced

  • Ping now shows that the second, slow DPI is no longer in the path:

mininet> h1 ping h3 PING 10.0.3.101 (10.0.3.101) 56(84) bytes of data. 64 bytes from 10.0.3.101: icmp_seq=1 ttl=63 time=21.3 ms 64 bytes from 10.0.3.101: icmp_seq=2 ttl=63 time=20.9 ms 64 bytes from 10.0.3.101: icmp_seq=3 ttl=63 time=20.7 ms ^C

  • -- 10.0.3.101 ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 20.713/20.983/21.320/0.252 ms

31

slide-32
SLIDE 32

Latency Reduced

  • Traceroute Confirms that the flow bypasses the second DPI

mininet> h1 traceroute -n h3 traceroute to 10.0.3.101 (10.0.3.101), 30 hops max, 60 byte packets 1 10.0.1.1 21.117 ms 20.796 ms 20.423 ms 2 10.0.3.101 24.597 ms 24.477 ms *

32

slide-33
SLIDE 33

DPI Bypass Demo

Approach #2: ODL SFC

33

slide-34
SLIDE 34

A Little More Detail: ODL ODL Provides a Northbound SFC “App”

34

slide-35
SLIDE 35

SFC Approach: Create a “Service Overlay”

  • 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

#ODSummit

1 2 3

slide-36
SLIDE 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

slide-37
SLIDE 37

DPI Bypass Demo

Approach #2: ODL SFC Note: This will be a live demo

37

Based on: https://lists.opendaylight.org/pipermail/sfc-dev/2015-July/001408.html by Brady Johnson and Ricardo Noriega at Ericsson.com

slide-38
SLIDE 38

Baseline

  • No Flows in Switch, No Objects in GUI

#ODSummit

slide-39
SLIDE 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

slide-40
SLIDE 40

Test 1: Configure Classifier to Use RSP-1

tcpdump shows WGET goes through both service functions Total time: 0.341 seconds

#ODSummit

SFF-1 Traffic SFF-2 Traffic

slide-41
SLIDE 41

Test 2: Configure Classifier to Use RSP-3

tcpdump shows WGET goes through only one service functions Total time: 0.178 seconds

#ODSummit

SFF-1: No Traffic SFF-2 Traffic

slide-42
SLIDE 42

Backup Slides

#ODSummit

slide-43
SLIDE 43

#ODSummit

OPSCON #2: Egress Bypass

slide-44
SLIDE 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

slide-45
SLIDE 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

slide-46
SLIDE 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

slide-47
SLIDE 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

slide-48
SLIDE 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

slide-49
SLIDE 49

The Goal

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

49

slide-50
SLIDE 50

Detailed Diagram

  • 1. ACL
  • 2. Scan all EXT  DMZ
  • 3. Bypass DMZ PUT
  • 4. Scan DMZ GET

50

slide-51
SLIDE 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

slide-52
SLIDE 52

OPSCON #2 Topology

52

slide-53
SLIDE 53

OPSCON #2

Note: This will be a real time demo

53

slide-54
SLIDE 54

Setup

  • As before, start ODL, connect switch to controller and “pingall”

54

slide-55
SLIDE 55

ODL Shows Connected L2 Interfaces

55

slide-56
SLIDE 56

Baseline: Push a file from DMZ to EXT

mininet> dmz curl http://10.0.1.102 --upload-file test.txt

  • EXT Server Shows Successful PUT

10.0.2.101 - - [10/Jul/2015 14:50:22] "PUT /test.txt HTTP/1.1"

  • TCPDUMP on firewall shows egress scan traffic (as expected)

56

slide-57
SLIDE 57

Install the Flows via RESTCONF API

  • Either via POSTMAN or CURL

curl -v -H "Content-Type: application/xml" -X PUT --data "@fw_demo_404.xml" -u admin:admin http://localhost:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:3/table/0/flow/404 2>&1 | grep HTTP/1.1 curl -v -H "Content-Type: application/xml" -X PUT --data "@fw_demo_505.xml" -u admin:admin http://localhost:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:3/table/0/flow/505 2>&1 | grep HTTP/1.1 curl -v -H "Content-Type: application/xml" -X PUT --data "@fw_demo_606.xml" -u admin:admin http://localhost:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:3/table/0/flow/606 2>&1 | grep HTTP/1.1 curl -v -H "Content-Type: application/xml" -X PUT --data "@fw_demo_707.xml" -u admin:admin http://localhost:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:3/table/0/flow/707 2>&1 | grep HTTP/1.1 curl -v -H "Content-Type: application/xml" -X PUT --data "@fw_demo_808.xml" -u admin:admin http://localhost:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:3/table/0/flow/808 2>&1 | grep HTTP/1.1 curl -v -H "Content-Type: application/xml" -X PUT --data "@fw_demo_909.xml" -u admin:admin http://localhost:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:3/table/0/flow/909 2>&1 | grep HTTP/1.1 57

slide-58
SLIDE 58

DMZ PUT a file to EXT

mininet> dmz curl http://10.0.1.102 --upload-file test.txt

  • The EXT server shows this second, successful put

10.0.2.101 - - [10/Jul/2015 14:50:22] "PUT /test.txt HTTP/1.1" 200 - 10.0.2.101 - - [10/Jul/2015 14:53:05] "PUT /test.txt HTTP/1.1" 200 -

  • The firewall TCPDUMP, however does not show additional traffic!

58

slide-59
SLIDE 59

Plumb Statistics via API

  • You can see a Match on the flow through the REST API:
  • http://<controller_IP>:8181/restconf/operational/opendaylight-

inventory:nodes/node/openflow:3/table/0/flow/404/flow-statistics/

59

slide-60
SLIDE 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

slide-61
SLIDE 61

EXT Server Shows Successful Get

10.0.2.101 - - [10/Jul/2015 14:50:22] "PUT /test.txt HTTP/1.1" 200 - 10.0.2.101 - - [10/Jul/2015 14:53:05] "PUT /test.txt HTTP/1.1" 200 - 6.6.6.6 - - [10/Jul/2015 15:01:27] "GET / HTTP/1.1" 200 -

  • Note Dummy IP

61

slide-62
SLIDE 62

FW TCPDUMP Shows DMZ to EXT GET Scan

62

slide-63
SLIDE 63

Verify All EXT  DMZ Traffic Scan

  • Do PUT and GET

63

slide-64
SLIDE 64

DMZ Server Log Shows Success for Both

64

slide-65
SLIDE 65

TCPDUMP: All EXT to DMZ traffic scanned

65

slide-66
SLIDE 66

Thank You

#ODSummit