I2NSF - Interface to Network Security Functions BOF Date: Thursday, November 13 Time: 16:40 - 19:10 Room: Coral 1 Chairs: Dan Romascanu, Joseph Salowey ------------------------------------------------------------------------------ Chair Slides - Dan Romascanu, Joseph Salowey Presentation: http://www.ietf.org/proceedings/91/slides/slides-91-i2nsf-4.pptx Slide 1 - I2NSF BOF Joe - This is a non-working-group-forming BOF. Slide 2 - Note Well Slide 3 - Administrative Tasks Note Takers - Jean Mahoney Jabber scribe - Yoav Nir Slide 4 - Agenda No comments or questions from room Dan - To answer the question, "What's a non-forming BoF?" We won't discuss a charter. We will focus on the problem space, use cases, and what exists for prototypes, deployments. At the end, we should have a better idea of where we are with the problems. ------------------------------------------------------------------------------ 3. Problem Statement - Linda Dunbar, 10 min Document: https://datatracker.ietf.org/doc/draft-dunbar-i2nsf-problem-statement/ Presentation: http://www.ietf.org/proceedings/91/slides/slides-91-i2nsf-9.pptx Slide 1 - Title: Interface to Network Security Functions Slide 2 - Firewall box configuration: ports and links based Linda - Today's firewalls are link- and port-centric. Configuration of IP addresses, ports, vendor-specific configurations. But there are common features. Slide 3 - Challenges Slide 4 - Common Functional Components of FW Linda - Goal - Build a common tree for common features with vendor branches. The operators can offer an interface through a web portal. We need agreed-upon attributes that the client can define. Slide 5 - Goal: a common interface for client to specify desired network security functions Slide 6 - Security Functions Under Consideration Linda - this is not complete. The example is from the OpenStack firewall. Collaborative loop - hope that IETF can support open source communities with defining the interface set. Start a positive loop. There's also open source IPS - snort. Slide 7 - FW as a service: potential attributes Linda - Not complete. The example is from Security Alliance. Slide 8 - Security as a Service: Potential attributes Slide 9 - Relevant Industry initiatives Edward Lopez, a firewall vendor - This is very good, it should move foward. Point out that there's big concern with best-match/first-match. Routers and switches work with best match. Security uses first match. This leads to conflicts and needs to be addressed. 2nd observation - an open-source solution may not be a standard solution. Dan, as chair - How much FW and policy configuration is on open source? Edward - most of the open source capabilities are fairly standard - then it skews wildly beyond policy statements. Some vendors think defining from layer 4 is not appropriate. Vendors deal differently separating network config versus security config. We can talk about common elements, but there has to be flexibility for vendor extensions. Yoav Nir, a firewall vendor - the common functions are what firewalls were doing 10-15 years ago. IPtables for linux - they can't express commonality of several ports using shared service. Beyond layer 4 - no commonalty. Don't rely on any open source. Kathleen Moriarty, as AD - concerns - bi-directional capability, One service provider vendor open to allowing tenants to configure security services. How many vendors want that? We want to make sure there is demand. Edward - my customer base - there is a strong demand area. Want customers to provision and control security functions. This is a strong issue for us. Bob Brisco, British Telecom - Is there demand from tenants? There's not much difference for this group with who would use it. We would need as much standardization as possible to allow us to switch providers and vendors. It's not gating that there are no end customers. Kathleen - Service Providers are open to do this for tenants. Diego Lopez Garcia, Telefonica - This would be of interest to us. Nikolai, Deutsche Telecom - customer as VF or own FW Kathleen - I'm just making sure that service providers were interested in a standard interface. Yoav for Melinda Shore in the Jabber room - So far what's been discussed has not, for the most part, been peculiar to sdn or virtualized security services. We've done quite a bit of work in the IETF on firewall policy communication and it's seen virtually no uptake. It seems to me that what might be interesting here would be the virtualization aspect. Having worked on this in ETSI, there was considerable support from service providers and none from vendors. ------------------------------------------------------------------------------ 4. Use Cases: ------------------------------------------------------------------------------ 4.1 - Access Use Cases for Open OAM Interface to Virtualized Security Services - D.Lopez, 15 min Document: https://datatracker.ietf.org/doc/draft-pastor-i2nsf-access-usecases/ Presentation: http://www.ietf.org/proceedings/91/slides/slides-91-i2nsf-2.pptx Slide 1 - Title: I2NSF Use Cases in Access Networks Slide 2 - Seeking an Open OAM Interface Slide 3 - A Few Examples of vNSFs Diego - with traffic inspection, the DPI is the customer's, not ours. With traffic impersonation, we work with customers to create honeypots to help us detect security threats, the customer will be the admin. Slide 4 - OAM Environments Diego - we're trying to consider the lifecycle. Slide 5 - Operator-Managed Slide 6 - Customer-Managed Diego - With the residential customer, limits have to be carefully crafted. Validation is very important. Slide 7 - Example: The NFV #7 use case for vCPE (technical issues with power point) Slide 8 - Bringing this into reality: The SECURED architecture Slide 9 - Specifying PSAM and PSAR in SECURED Slide 10 - Expressing Policies Diego - We're discussing whether this should be in scope or not. It may not be in IETF tasks. Slide 11 - Thank You Hannes Tschofenig - To see if I understand the idea, I have a question - instead of running a firewall on my PC, I would outsource to it to the access router? Diego - yes Hannes - In addition to the firewall on the PC, you have firewall rules in network for performance reasons. If you push it all into the network - maybe my home router supports it, but not the network? What about incremental deployment? Diego - We want to enhance security in residential environment. You could still have your firewall. Or if you want, you can use this. Hannes - when you use the term managed, for ... Diego - We're offering an additional service. It's not about removing your firewall. We think it will create better security. Hannes - We trick ourselves sometimes - we use new terms but don't see parallels to other work. Melinda mentioned it. We've looked at various solutions. Diego - We plan to do - standardize it right. How to translate policies to low level protocols. No intention in limiting. Ed - I would like to see the provisioning aspects. There's a need to provision these virtual functions very quickly. Methodology needs to be defined. Diego - we have a group working on provisioning API. Ed - a lot of a systems are not designed with security. Bob Briscoe - Are talking about the differences the virtualization makes? Linda's presentation was talking about configuration irrespective of how they booted. Virtualization makes policy control more useful - they come up with different addresses in different places - abstraction is useful. But translating high-level policy to low level - that's not necessary for IETF. Start with low-level then go to the high level. Diego - I wasn't sure that the translation was in scope. If you have virtualized service, you need to configure it. I wanted to show that it wasn't just configuration, but provisioning and also .... The 4th one - about policy - I'm not sure we should work on that. Dan - We need to cut the line. Slide 12 - Disclaimer ------------------------------------------------------------------------------ 4.2 - Integrated Security with Access Network Use Case - M.Qi, 15 min Document: https://datatracker.ietf.org/doc/draft-qi-i2nsf-access-network-usecase/ Presentation: http://www.ietf.org/proceedings/91/slides/slides-91-i2nsf-1.pptx Slide 1 - Title: draft-qi-i2nsf-access-network-usecase-00 Slide 2 - Current Access Network Security Qi - want to make it more flexible and useful for user. Slide 3 - Virtualized Security Function Slide 4 - Use Case 1: security configuration Slide 5 - Use Case 2: Optional security function negotiation Slide 6 - Use Case 3: Security Request from User side Slide 7 - Thank you! Hannes - question on use case 2 - if we have a junk mail filter - the network provider is also the email provider. It happens at a different layer. Is this part of the requirements - signaling at different layers depending on application? On use case 1 - the nest thermostat or philips - these are different ... Qi - in use case 1, the service is provided by the operator network. In 2, the mail service is provided by a 3rd party, but the mail is transferred through the network. In some countries, we've been requested to ... provider check the mails through the network. User can request the operator to check the junk mail otherwise operator is prohibited from doing it. Hannes - you would have difficulties looking at the content if encrypted. Qi - we want to provide the user options. Sam Hartman - What's the difference between use case 2 and 3? Qi - In 2 The operator shows all the options it can do. The user chooses what the network needs to do from that list. In 3 - the user requests what he wants and the network provides a solution. Sam - 3 is more freeform. With 2 the user has to pick Lars Eggert - You will see something about layer 4 in the future. ... unlikely. There aren't useful things you can do at layer 3 and 4. I don't see anything that I want an operator to do for me here. For me personally, we can take these use cases off the table. Qi - these are just examples how the network can provide services... Lars - if those are the best you have, pick something else. It makes me angry. Sam - I'm angry too. It's clear that firewalls do this today. If we buy that firewalls virtualization cfg - they can do all the evil things that firewalls today can. I'm not bothered that I can express what firewalls do here. Make sure that the things you can do - some of the use cases are ones we want to encourage. Dan - We'll close the queue after the next 2 persons. Please limit yourselves to questions about the use cases. There will be more discussion at the end. Kathleen, AD - what are the differences in the use cases? We're talking about client configuration. This draft was too high level. I didn't realize that client configuration was going to be discussed. It could be done in a different working group. Configuration for non-technical people. We walk a fine line. There are concerns. Edward - There's not a real purposes for use case 2. If security is being imposed by the network, don't need to tell the clients. For instance, school security - you don't tell the students. Cases 2 and 3 merge. Qi - 2 is triggered by real requirements. We can talk offline. ------------------------------------------------------------------------------ 4.3 - Data Center Use Cases - N. Leyman, 15 min Document: https://datatracker.ietf.org/doc/draft-zarny-i2nsf-data-center-use-cases/ Presentation: http://www.ietf.org/proceedings/91/slides/slides-91-i2nsf-10.pptx Slide 1 - Title: Data Center Use Cases Slide 2 - On Demand, elastic FWs Slide 3 - Client Specific Security Policies Slide 4 - Role of I2NSF Slide 5 - Key Requirement (1/2) Slide 6 - Key Requirement (2/2) Dave Dolson - I think I saw a dynamic element for DOS? Leyman - yes. During a DOS, you can reconfigure firewalls. Edward - This is very interesting. There are going to be objects - antivirus object - configured via restful APIs. For traffic and security - again it's best match versus first match. It will be hard to solve with single policy. ------------------------------------------------------------------------------ 5. Collaboration with other industry initiatives: ------------------------------------------------------------------------------ 5.1 - ITU-T SG 17: "Requirements for security services based on software-defined networking" - J. Jeong, 10 min Document: https://datatracker.ietf.org/doc/draft-jeong-i2nsf-sdn-security-services/ Presentation: http://www.ietf.org/proceedings/91/slides/slides-91-i2nsf-0.pptx Slide 1 - Title: Requirements for Security Services based on Software-Defined Networking Slide 2 - Contents Slide 3 - Standardization Status in ITU-T Slide 4 - Motivation Slide 5 - Challenges in Firewall Slide 6 - Centralized Network Firewall based on Software-Defined Networking Slide 7 - Expectations for SDN-Based Firewall Slide 8 - SDN-Based Security Services Slide 9 - High-Level Architecture for SDN-Based Security Services Slide 10 - Objectives Slide 11 - Requirements Slide 12 - Use Cases Slide 13 - Centralized Firewall System (1/2) Slide 14 - Centralized Firewall System (2/2) Slide 15 - Centralized DDoS-Attack Mitigator (1/2) Slide 16 - Centralized DDoS-Attack Mitigator (2/2) Slide 17 - Discussion Sam - trying to understand the difference between this presentation and the previous. The level of detail is much different. The end points that are responsive to this use case are much different than the previous use case. Jeong - this is based on OpenFlow - intelligence is lacking in switches and routers. intelligence is in the app layer. Edward - I'm scratching my head - it seems that they don't know what firewall is. Switches don't have state. How does a switch say the flow is suspicious? Jeong - The packets can be analyzed by FW app. Our assumption is that the intelligence in FW application. We can monitor. Edward - the security has gone beyond L3 L4 to look for malware. It has to be in the flow. You end up with buffer bloat and latency issues. There's a lot of traffic that we should be inspecting. I look at SDN open - this needs to be shunted to a inspection device, some don't. I see it more as a configuration orchestration that tells the switch to shunt to the firewall. Flemming Andreason- I agree with the previous speaker. This is just a small fraction of what we have to deal with. ??? Cisco - How does the switch have the intelligence to decide to send the packet to a SDN controller? Jeong - this is based on openflow case. We assume some intelligence. The openflow approach. The network ... function will be promising. ??? Cisco - you can use openflow to tell the switch to block the flow but not the other way around. ------------------------------------------------------------------------------ 5.2 - Open NFV - Chris Downley, 10 min http://www.ietf.org/proceedings/91/slides/slides-91-i2nsf-5.ppt Slide 1 - Title: OPNNFV Slide 2 - OPNFV is a carrier-grade, integrated, open source reference platform for NFV Slide 3 - OPNFV Initial Scope Slide 4 - OPNFV Architecture Framework Slide 5 - Why Open Source Slide 6 - Upstream OSS Projects Integration Slide 7 - Collaboration with I2NSF Slide 8 - Questions? Nikolai - how does this relate to the client/network interface? This work focuses on how to virtualize it. What kind of interface? Chris - we're working on multiple interfaces (pointed at slides). Nikolai - the dark green block? Chris - yes Nikolai - where's the client here? Chris - since this is a virtual infrastructure, some of it will be on client site some in network. Linda Dunbar - the NFVI interface - the IETF could provide guidance on that. Chris - absolutely Edward - I'm happy about this presentation. Many objects can be expressed in the form of yang models. As you pursue this, allow flexibility for vendor extensions. Templates into these interfaces. Chris - we're going to build a common platform that vendors can use. Please join us. ------------------------------------------------------------------------------ 6.2 NeMo API / I2RS - Sue Harris, 10 min Presentation: http://www.ietf.org/proceedings/91/slides/slides-91-i2nsf-8.pptx Slide 1 - I2RS Security Review Sue - Rolled into the architecture draft. Slide 2 - I2RS review Slide 3 - Integrity Protection Slide 1 - Why Intent-driven network interfaces? Slide 2 - 2 sample interfaces Slide 3 - Nemo allows multiservice SDN Slide 4 - NEMO Language No questions. ------------------------------------------------------------------------------ 6. Relationship with IETF existing work ------------------------------------------------------------------------------ 6.1 Analysis of Existing Work for I2NSF - D. Zhang, 10 min Document: https://datatracker.ietf.org/doc/draft-zhang-gap-analysis/ Slide 1 - Analysis of Existing Work for I2NSF Slide 2 - NSIS (1) Slide 3 - NSIS (2) Slide 4 - How NSaaS is different from SACM Slide 5 - PCP Slide 6 - SFC Slide 7 - ANIMA Slide 8 - Thanks Hannes - the info on NSIS provided on the slide was not necessarily correct. It's a generic lower layer signaling mechanism. It doesn't require every node to implement. Zhang - ... Hannes - there are implementations available. Zhang - maybe can support communication between client and SP proxy Hannes - helpful as a building block. If it's bigger data. Not a good choice for... Zhang - for managing data .. you have to communicate with the proxy. Hannes - it's a common problem - the if the FW has to do something. Data has to flow though it. Sam - if we agree it's useful. We're not doing solution here. Let's not rathole. Dan - at the bar BoF, people were asking what other tech could be candidates for a piece of the solution. ------------------------------------------------------------------------------ 7. Discussion and Next Steps - remaining time Dan - Thanks for contributions. This time is for general discussion - do we understand the use cases? Can we identify important subset? Is there commonality? Sam - several use cases are interesting. Something not discussed here, and it would be valuable to publish, are the privacy and perpass implications. When I shovel my data to the cloud, it's easier to passively monitor that data. Even if encrypted, they have the keys. How easy ... how do you handle court orders (if you lost or if you got the court order)? Write a draft on the trade-offs of cloud services with ... Who gets the subpoena for this type of thing? Be very cognizant of privacy implications. Kathleen - I agree with Sam, taking off my AD hat - there are perpass trends as customers move more secure data into cloud. Customers are storing their data encrypted. Huge push to configure encryption sooner. Good to work with open source communities on this - within the right scope. Bob Brisco - people see what they want to see in it. There's a lot of different views. Some people see it as a privacy thing. Others see it as a standardization of vendor configuration. Or see it as virtualization specifics. Why are people seeing different things? Linda - I want to understand privacy - the client can manage their firewall. If you upload content to cloud, you need security services for that. Don't understand. Kathleen - we look at privacy and security considerations in the IETF. Since we're talking about virtualization services, we want to separate out the privacy issues - define a scope. The actual data would be different. I think that's what Sam was getting at. Bob - You're talking about storing data, but we're talking about configuration. Kathleen - I wasn't adding storing data to use cases. Sam - If I invoke a security service in the cloud, this can open an attack vector. Should document. Qi - this is just for virtualization of security services. The customer can use own security services and can tell the operators they don't want to use the operator's services. I don't think privacy will be a problem with virtualization. Eric Dyran ? - How does NFV relate to IETF and security? IETF is going toward end-to-end security. NFV runs services in an untrusted service provider. Not clear how much resolving mismatches was in scope. As opposed data model creation. Joe Salowey - We talked about a lot of use cases. Instead of focusing on security and privacy - and we'll have to do that - but it's not the only issue and we need to identify the use cases. Lars - going back to what Bob said - it looks different to me. I see work proposed but it's not clear. I want to manage security boxes from different vendors and then their virtualized versions. Then the use case on access. Can we find a few that we want to focus on? Management and instantiation of security devices in a virtualized environment - I think there's something there. Steven Wright - as an operator, the use cases from Linda and Diego resonate. The other point that we will have to deal with virtualized firewalls. If the ANIMA work comes forward, how much of this goes away? What's left? Are you coming from the bottom or from the top? Diego - there's a conflict between virtualization and privacy. Virtualization is here to stay, and privacy is here to be preserved. How do you establish trust with virtualized service? How do you find them. How to verify they are behaving as expected? I would focus work on establishing trust. There's some configuration not covered yet also. Dan - you are identifying a work item - the threat model that virtualization adds to privacy. Edward - A lot of middleboxes break the end-to-end principle. They work at a layer below we want them to. I think we should move them out of the way. Need to distribute these functions in NFV and SDN. I want to provide a standard interface for deploying security functions in a distributed environment. Dan - we have management of boxes, but it doesn't have wide deployment. Why would the virtualized version be different? Edward - The underlying assumption of network integration has shifted. It will require this. Dan, as individual - I'd like to see running code - open source or proprietary Dan, as chair - Show of hands - is there enough substance for this effort to continue? Is there enough substance for Bof for formation of working group? Lars - There's too much substance. Conroe? - I"m not concerned about too much. I can see there are aspects that ... Lisa Lorenzin - we don't have to figure out everything, but if we can make improvement Dan - This work will continue. The list is open. Provide opinions on what was contributed - what was useful and what was missing. One item - threat model on privacy. Kathleen - Thanks to Joe and Dan for their work on organizing this. And to Linda.