FWaaS German EichbergerSridar KandaswamyVishwanath Jayaraman

Let’s get this started Introduction Team Motivation Objectives for Today There is no demo at the end Core dump of what the team has been doing Connect with deployers and users Roadmap

Where is FWaaS today ? Support for Perimeter N – S Firewalling Issues on DVR interaction for E – W traffic so not applied on namespaces for E – W. Firewall can be associated with Router(s). In retrospect, applying on Router interfaces makes more sense. Not on VM Ports for Firewalling VM – VM traffic Intersect with Security Groups – there is some ongoing discussion. No support to plug in to Service Chains, Containers, Provider Nets …

API Evolution Unified model to apply at different points in the network (Router Port, VM Port) Managing interplay between admin enforcement and user defined rules Grouping mechanisms (Address groups/Port Groups) SG intersect

DVR interaction E-W Firewalling Model is Routing on the local Node and bridge on the Remote. We have an asymmetric scenario and issues with connection tracking on iptables implementation. Options to go thru on the IR on the remote or other models that can impose a performance cost when FWaaS is configured. Still early and in discussions with DVR team.

Where some clarity is emerging Moving from Routers to Router interfaces for perimeter use cases Grouping models Service Groups Zones

Zone Based Firewalls Ordinary Firewalls: Ordinary firewall rule sets are applied on per-interface basis Acts as a packet filter for the interface. Zone Based firewall Interfaces are grouped into security zones Each interface in a zone has the same security level Packet-filtering policies are applied to traffic flowing between zones. Traffic flowing between interfaces that lie in same zone is not filtered

Zone Based Firewalls Additional points related to Zone Based Firewall By default, all traffic coming into router and originating from router is allowed An interface can be associated with only one zone An interface that belongs to a zone cannot have a per-interface firewall rule set applied to it and conversely Traffic between interfaces that do not belong to any zone flows unfiltered, and per-interface firewall rule sets can be applied to those interfaces.

Some other generic cleanup that is needed L3 Agent interactions for Observer hierarchy More Test Coverage + move test in tree FWaaS Gate setup

Trello Board

Component Design API server (FWaaS) API server (SG) FWaaS Backend Packet Filtering (e.g dropping, rejecting, etc.) Plugin FW insertion Plugin Packet Capture Plugin

FWaaS Api deprecated in Liberty This doesn’t mean it’s going away immediately But signals that this is being changed in the next cycle Likely some Backward compatibility

Roadmap MitakaNO Enhance test coverage API redesign ●Port based ●Can augment SecurityGroups ●IPTables based reference implementation ●Service Groups Improve reference implementation ●Scalability ●HA Zones ●SFC support ●Common classifiers ●Common backend for SG and FWaaS ●Pay off tech debt

How to contribute ●Get a good irc client. You’ll need it ○Join #openstack-fwaas and introduce yourself :-) ●Attend the weekly IRC meetings ○Wednesdays 18:30 UTC alternating with Thursdays 0:00 UTC ○Agenda: ●File a bug/RfE for your idea - Then add it to the agenda… ○It’s ok to only have a rough sketch of the idea and this is actually encouraged in the RfE ●Sign the Contributor’s license agreement (CLA) ○Developer Certificate of Origin has been discussed as replacing the CLA ●Get familiar with Gerrit. Code review, write code, write documentation, help... ●Attend the midcycle!

Q&A Questions?