Software-Defined Security Services Working Group–January 26, 2017 Meeting Notes
By TINA ZHANG, Cisco
S-DSS community members,
Below please find S-DSS community meeting notes held on 1/26:
Time: Jan 26 2017, 11am – 12pm EST.
Nick Lippis, Ali Syndey, Ben Mourad, Hari Krishnan, Jim Guichard, Linda Dunbar, Mukesh Gupta, Pete Kwon, Rakesh Kumar, Scott Bradner, Simon Fiddian; Thom S, Tina Zhang, 8 other Calling-Users.
Host: Nick Lippis.
Agenda #1: Vendor co-chair nomination introduction/briefing/voting:
The three vendor co-chair nominations are:
Community members please use the following link to cast your vote for 2017 vendor co-chair selection: https://PollEv.com/multiple_choice_polls/xfRmkdgP8IrXcpp/web
The voting link will be closed EOD Friday (1/27/17) PST.
Agenda #2: ONUG S-DSS Working Group Use Case Priority Voting
Community members please use the following link to vote top 2 use cases for ONUG S-DSS to focus on: https://pollev.com/multiple_choice_polls/ZreA8ngSJhHpLCL/web
The voting link will be closed EOD Friday (1/27/17) PST.
========Meeting conversation details (credit to Linda Dunbar’s detailed notes)=======
Nominee self intro:
Rakash Kumar: Appreciate Linda’s kindness of receding her nomination. Currently working for Juniper. Worked in Juniper, Cisco, etc. in the past. In networking area for 20 years. Last few years been looking into security in cloud and hybrid cloud areas. Has created Secure Policy. Defined the Client interface that user intent, which doesn’t depend on the ports and addresses.
Hari Krishnan: Currently work in product management in Nuage Networks. Most of the career has been in security areas in network companies, Nuage, Cisco, Nominum, VMware, F5, etc. Defined the managed way to define security. Has been participating in ONUG Security group for last 6 months. This group is great in laying out requirement, use cases and awareness.
Marc Woolward (vArmour): absent.
Mukesh Gupta: have any of the candidates work on security service over cloud, container security,
Rakesh: East – West security becomes more important as more services are moving to cloud. From juniper perspectives, we are definitely look into container security. I2NSF defines the standardized data models for clients (over client facing interface) and for security functions, so that clients can use same policies to applications located in different places (on premises, public cloud or private cloud) and controllers in different domains can use security functions from different vendors.
Hari: from Container perspective, we focus on hybrid work load. How to enforce the rules are vendor specific. Tie with orchestration. Distributed policy systems. We can lay out how the architecture.
Tina: Regarding cloud integration, most members in this community are from vendor community, are we going to work with major cloud providers, such as Amazon AWS, Microsoft Azure, Google, etc.? Or are we more focusing working with tradition network vendors approach?
Nick: at the Spring meeting, Amazon, Azure and IBM will be there. We haven’t actively recruit them. Maybe we should have an outreach campaign.
Linda: Outreach campaign is great idea. We need some white paper to show benefits to Cloud Providers. It is very natural for cloud providers not seeing the benefit of standard policies. It is easy to believe that closed system can lock in their clients.
Rakesh: make sure architecture allows Amazon & Azure to fit in. Second, the vendor’s community can provide the standardized APIs making it easier for integration.
Mukesh: I also believe architecture is very important. What we do in Illumio, the controller can fit into both Amazon and Azure infrastructure.
Hari: Second Rakesh’s point. Having standardized policies is important.
Rakesh: different vendors may have different implementations. The Common interface should allow an enterprise, such as City Bank, move from one controller to another. Vendors should have common north bound policies, so that enterprises can move from one to another.
Rakesh: I2NSF is exactly for that purpose. Framework allow clients to define standardized common data models which allow
Scott: The common interface can bring happy customers.
Linda: there are benefit for offering standard APIs for cloud provider as well. For example, it will be easier for them to get new customers, allow them to choose more cloud DC interconnect suppliers.
Nick: can you work with me and Scott to get a short white paper as the outreach campaign to get cloud providers to join us.
Use cases priority vote:
Nick: we need participants to vote for the highest 2 priority use cases.
Rakesh: some use cases are implementation specific.
Nick: that is why we need brainstorm and narrow down to some useful & meaningful ones.
Rakesh presented New Approach to do Security: Software Defined Secure Network.
Jim Guichard: I don’t see any requirement to carry the policy in the data plane. Is it in the scope?
Rakesh: when one function can’t perform the policy needed, it can orchestrate a service function chain to enforce the policy.
Jim Guichard: we want to simplify the policies.
Rakesh: Juniper can expose policy capability to the controller. The controller can choose
Nick: the work is very much aligned with this group. But some part is very network centric. Missing the whole virtualization part. That is one of my feedback.
Mukesh: moving policy to workload. Need to have requirement on policies that are allocation agnostics
Rakesh: the architecture doesn’t care where the service functions are located. It is controller that orchestrate virtual security functions or
Nick: let’s move this to the discussion list.
Open Networking User Group