Network Working Group E. Lopez Internet Draft Fortinet Intended status: Informational D. Lopez Expires: December 2015 Telefonica L. Dunbar Huawei X. Zhuang China Mobile J. Parrott BT R Krishnan Dell S. Durbha CableLabs June 8, 2015 Framework for Interface to Network Security Functions draft-merged-i2nsf-framework-02.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt xxx, et al. Expires December 8, 2015 [Page 1] Internet-Draft I2NSF Framework June 2015 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 8, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract In the design of interfaces to allow for the provisioning of network security functions (NSFs), a critical consideration is to prevent the creation of implied constraints. This document makes the recommendation that such interfaces be designed from the paradigm of processing packets and flows on the network. NSFs ultimately are packet-processing engines that inspect packets traversing networks, either directly or in context to sessions to which the packet is associated. This document serves as the framework for detailed work items for I2NSF. Table of Contents 1. Introduction...................................................3 2. Conventions used in this document..............................3 3. Interfaces to Flow-based NSFs..................................4 4. Reference Models in Managing NSFs..............................6 4.1. NSF Facing Interface......................................7 xxx, et al. Expires December 8, 2015 [Page 2] Internet-Draft I2NSF Framework June 2015 4.2. Client Facing Interface...................................7 4.3. Vendor Facing Interface...................................8 4.4. The network connecting the Security Controller and NSFs...8 4.5. Interface to vNSFs........................................9 5. Flow-based NSF Capability Characterization....................10 6. Security Policies Provisioning to NSFs........................13 6.1. Capability Layer Provisioning and Monitoring.............13 6.2. Service Layer Security Policy............................14 7. Capability Negotiation........................................15 8. Types of I2NSF clients........................................16 9. Manageability Considerations..................................16 10. Security Considerations......................................17 11. IANA Considerations..........................................17 12. References...................................................17 12.1. Normative References....................................17 12.2. Informative References..................................17 13. Acknowledgments..............................................18 1. Introduction This document describes the framework for Interface to Network Security Functions (I2NSF) and defines a reference model along with functional components for I2NSF. It also describes how I2NSF facilitates Software-defined network (SDN) and Network Function Virtualization (NVF) control, while avoiding potential constraints which could limit NSFs internal functions. The I2NSF use cases ([I2NSF-ACCESS], [I2NSF-DC] and [I2NSF-Mobile]) call for standard interfaces for customers to control and monitor security functions hosted and managed by service providers. [I2NSF-Problem] describes the motivation and the problem space for Interface to Network Security Functions. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. xxx, et al. Expires December 8, 2015 [Page 3] Internet-Draft I2NSF Framework June 2015 BSS: Business Support System Controller: used interchangeably with Service Provider Security Controller or management system throughout this document. FW: Firewall IDS: Intrusion Detection System IPS: Intrusion Protection System NSF: Network Security Functions, defined by [I2NSF-Problem] OSS: Operation Support System vNSF: refers to NSF being instantiated on Virtual Machines. 3. Interfaces to Flow-based NSFs The emergence of SDN and NFV has resulted in the need to create application programming interfaces (APIs) in support of dynamic requests from various applications. Flow-based NSFs [I2NSF-Problem] inspects packets in the order as they are received without modification to the packets due to the inspection process. The Interface to Flow-based NSFs can be generally grouped into three types: 1) Configuration - deals with the management and configuration of the forwarding functions of the NSF device itself, such as port, addresses configurations. Configuration deals with attributes that are don't change very much. 2) Signaling - which represents logging and query functions between the NSF and external systems. Signaling API functions may also be well defined by other protocols such as SYSLOG, DOTS, etc. xxx, et al. Expires December 8, 2015 [Page 4] Internet-Draft I2NSF Framework June 2015 3) Provisioning - used to control the rules that govern how packets are treated by the NSFs. Due to the lack of standards in the definition and operation of these functions, much of the efforts towards interface development will be in this area. This draft proposes that a provisioning interface to NSFs can be developed on a packet-based paradigm. While there are many classifications of existing and emerging NSFs, a common trait shared by them is in the processing of packets based on the content (header/payload) and context (session state, authentication state, etc) of received packets. An important concept is the fact that attackers do not have standards as to how to attack networks, so it is equally important not to constrain NSF developers to offering a limited set of security functions. Therefore, in constructing standards for provisioning interfaces to NSFs, it is equally important to allow support for vendor-specific functions, to allow the introduction of NSFs that evolve to meet new threats. Proposed standards for provisioning interfaces to NSFs should not: - Narrowly define NSF categories, or their roles when implemented within a network - Attempt to impose functional requirements or constraints, either directly or indirectly, upon NSF developers - Be a limited lowest-common denominator approach, where interfaces can only support a limited set of standardized functions, without allowing for vendor-specific functions - Be seen as endorsing a best-common-practice for the implementation of NSFs By using a packet-based approach to the design of such provisioning interfaces, the goal is to create a workable interface to NSFs which aid in their integration within SDN/NFV environments, while avoiding potential constraints which could limit their functional capabilities. xxx, et al. Expires December 8, 2015 [Page 5] Internet-Draft I2NSF Framework June 2015 Even though security functions come in variety of form factors and have different features, provisioning to Flow-based NSFs can be categorized by - Subject - Match values based on packet data Packet header or Packet payload, - Object - Match values based on context, e.g. State, time, geo- location, etc., - Action- Egress processing, such as Invoke signaling; Packet forwarding and/or transformation; Possibility for SDN/NFV integration, and - Functional Profile - E.g. IPS:, signature file, Anti- virus file, URL filtering file, etc. Integrated and one-pass checks on the content of packets. The functional profile or signature file is one of the key properties that determine the effectiveness of the NSF, and is mostly vendor specific today. 4. Reference Models in Managing NSFs This document only focuses on the framework of provisioning and monitoring of the flow-based NSFs. The following figure shows various interfaces for managing the provisioning & monitoring aspects of flow-based NSFs. xxx, et al. Expires December 8, 2015 [Page 6] Internet-Draft I2NSF Framework June 2015 Client/AppGW | | Client Facing Interface +-----+---------------+ |Service Provider mgmt| +-------------+ | Security Controller | < -------- > | Vendor | +---------------------+ Vendor Facing| Sys | | Interface +-------------+ | | NSF Facing Interface | +------------------------------------------------+ | | | | +------+ +------+ +------+ +------+ + NSF-1+ ------- + NSF-n+ +NSF-1 + ----- +NSF-m + . . . +------+ +------+ +------+ +------+ Vendor A Vendor B Figure 1: Multiple Interfaces 4.1. NSF Facing Interface This is the interface between the Service Provider's management system (or Security Controller) and the NSFs that are selected to enforce the desired network security. This interface is called Capability Interface in the I2NSF context. 4.2. Client Facing Interface This interface is for clients or Application Gateway to express and monitor security policies for their specific flows. The Client Facing interface is called Server Layer Interface in the I2NSF context. A single client layer policy may need multiple NSFs collectively together to achieve the enforcement. xxx, et al. Expires December 8, 2015 [Page 7] Internet-Draft I2NSF Framework June 2015 4.3. Vendor Facing Interface When service providers have multiple types of security functions provided by different vendors, it is necessary to have an interface for vendors to register their NSFs indicating what level can be provisioned or monitored for each of the categories listed above. The Registration Interface can be static or dynamic. When NSFs are upgraded, vendors need to notify the service provider management system or controller of the updated capabilities. 4.4. The network connecting the Security Controller and NSFs Most NSFs are not directly attached to the Security Controller; it is especially true when NSFs are distributed across the network. The network that connects the Security Controller with the NSFs can be the same network that carry the data traffic, or can be a dedicated network for management purpose only. Either case, packet loss could happen due to failure, congestion, or other reasons. Therefore, the transport mechanism used to carry the control messages and monitoring information should provide reliable message delivery. Transport redundancy mechanisms such as Multipath TCP (MPTCP) [MPTCP] and the Stream Control Transmission Protocol (SCTP) [RFC3286] will need to be evaluated for applicability. Latency requirements for control message delivery must also be evaluated. The connection between Security Controller and NSFs could be: - Closed environments where there is only one administrative domain. More permissive access controls and lighter validation is needed inside the domain because of the protected environment. - Open environments where some NSFs (virtual or physical) can be hosted in external administrative domains or reached via external network domains. Then more restrictive security xxx, et al. Expires December 8, 2015 [Page 8] Internet-Draft I2NSF Framework June 2015 controls are required over the I2NSF interface. The information over the I2NSF interfaces must use trusted channels, such as TLS, SASL, or the combination of the two. Over the Open Environment, I2NSF needs to provide the identity frameworks and federations models for authentication and Authorization. 4.5. Interface to vNSFs Even though there is no difference between virtual network security functions (vNSF) and physical NSFs from policy provisioning perspective, there are some unique characteristics in interfacing to the vNSFs: - There could be multiple instantiations of one single NSF being distributed across network. When different instantiations are visible to the Security Controller, different policies may be applied to different instantiations of one single NSF. - When multiple instantiations of one single NSF appear as one single entity to the Security Controller, the policy provisioning has to be sent to the NSF's sub-controller, which in turn disseminate the polices to the corresponding instantiations of the NSF, as shown in the figure below. See Figure 2 below. - Policies to one vNSF may need to be retrieved and move to another vNSF of the same type when client flows are moved from one vNSF to another. - Multiple vNSFs may share the same physical platform - There may be scenarios where multiple vNSFs collectively perform the security policies needed. xxx, et al. Expires December 8, 2015 [Page 9] Internet-Draft I2NSF Framework June 2015 +------------------------+ | Security Controller | +------------------------+ ^ ^ | | +-----------+ +------------+ | | v v + - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - + | NSF-A +--------------+ | | NSF-B +--------------+ | | |Sub Controller| | | |sub Controller| | | +--------------+ | | +--------------+ | | + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + | | |+---------+ +---------+| | | |+---------+ +---------+| | | || NSF-A#1 | ... | NSF-A#n|| | | || NSF-B#1| ... | NSF-B#m|| | | |+---------+ +---------+| | | |+---------+ +---------+| | | | NSF-A cluster | | | | NSF-B cluster | | | + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + | + - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - + Figure 2: Cluster of NSF Instantiations Management 5. Flow-based NSF Capability Characterization There are many types of flow-based NSFs. To prevent constraints on NSF vendors' creativity and innovation, this document recommends the Flow-based NSF interfaces to be designed from the paradigm of processing packets on the network. Flow-based NSFs ultimately are packet-processing engines that inspect packets traversing networks, either directly or in context to sessions to which the packet is associated. Flow-based NSFs differ in the depth of packet header or payload they can inspect, the various session/context states they can maintain, the specific profiles and the actions they can apply. Accordingly, the NSF capabilities are characterized by the level of packet processing and context that a NSF supports, the profiles and the actions that the NSF can apply. Vendors can register their NSFs using the Subject-Object-Action- Function categories described in Section 2, with detailed specification of each category as shown in the table below: xxx, et al. Expires December 8, 2015 [Page 10] Internet-Draft I2NSF Framework June 2015 +-----------------------------------------------------------+ | Subject Capability Index | +---------------+-------------------------------------------+ | Layer 2 | Layer 2 header fields: | | Header | Source/Destination/s-VID/c-VID/EtherType/.| | | | |---------------+-------------------------------------------+ | Layer 3 | Layer header fields: | | | protocol | | IPv4 Header | port | | | src port | | | dscp | | | length | | | flags | | | ttl | | | | | IPv6 Header | | | | addr | | | protocol/nh | | | src port | | | length | | | traffic class | | | hop limit | | | flow label | | | | | TCP | Port | | SCTP | syn | | DCCP | ack | | | fin | | | rst | | | ? psh | | | ? urg | | | ? window | | | sockstress | | UDP | | | | flood abuse | | | fragment abuse | | | Port | | HTTP layer | | | | | hash collision | | | | http - get flood | | | | http - post flood | | | | http - random/invalid url | | | | http - slowloris | | | | http - slow read | | | | http - r-u-dead-yet (rudy) | | | | http - malformed request | | | | http - xss | xxx, et al. Expires December 8, 2015 [Page 11] Internet-Draft I2NSF Framework June 2015 | | | https - ssl session exhaustion | +---------------+----------+--------------------------------+ | IETF PCP | Configurable | | | Ports | | | | +---------------+-------------------------------------------+ | IETF TRAM | profile | | | | | | | |---------------+-------------------------------------------+ +-----------------------------------------------------------+ | Object (context) matching Capability Index | +---------------+-------------------------------------------+ | Session | Session state, | | | bidirectional state | | | | +---------------+-------------------------------------------+ | Time | time span | | | days, minutes, seconds, | | | Events | +---------------+-------------------------------------------+ | Events | Event URL, variables | +---------------+-------------------------------------------+ +-----------------------------------------------------------+ | Action Capability Index | +---------------+-------------------------------------------+ | Ingress port | SFC header termination , | +---------------+-------------------------------------------+ | | Pass | | Egress | Deny | | | Mirror | | | Functional call | | | Encap various header | +---------------+-------------------------------------------+ +-----------------------------------------------------------+ | Functional profile Index | +---------------+-------------------------------------------+ | Profile types | Name, type, or | | Signature | Flexible Profile/signature URL | | | Command for Controller to enable/disable | | | | +---------------+-------------------------------------------+ xxx, et al. Expires December 8, 2015 [Page 12] Internet-Draft I2NSF Framework June 2015 6. Security Policies Provisioning to NSFs +------------------------------------------+ | App Gateway | | (e.g. Video conference Ctrl | | Admin, OSS/BSS, or Service Orchestration | +---------------------+--------------------+ I2NSF |Service Layer Security Policy | +--------------+----------------+ | Security Controller | +--------------+----------------+ I2NSF |Capability Layer Security Policy | +------------------+ | Adapter | +------------------+ | virtual/physical | | NSFs | +------------------+ Figure 3: Multiple Layers of I2NSF interfaces 6.1. Capability Layer Provisioning and Monitoring The Capability Layer is to express the explicit provisioning rules to individual NSFs and methods to monitor the execution status of those functions. This requires the definition of an information model, along with one or more data models, to express the provisioning rules, which are derived from the client facing security policies. This layer will leverage the existing protocols and data models defined by I2RS, Netconf, and NETMOD. [ACL-MODEL] is for expressing the Access Control List supported by most routers/switches that forward packets based on packets' L2, L3, or sometimes L4 headers. The actions for Access Control List include Pass, Drop, or Redirect. xxx, et al. Expires December 8, 2015 [Page 13] Internet-Draft I2NSF Framework June 2015 The functional profiles (or signatures) for NSFs are not present in [ACL-MODEL] because the functional profiles are unique to specific NSFs. Most vendors' IPS/IDS, and HoneyPot have their proprietary functions/profiles. One of the goals of I2NSF is to have common envelop format for exchanging or sharing profiles among different organizations to achieve more effective protection against threats. The "subject" of the policies not only includes the matching criteria specified by [ACL-MODEL] but also the L4-L7 fields depending on the NSF selected. The I2NSF Capability Layer has to specify the "Object" (i.e. the states/contexts surrounding the packets). The I2NSF "actions" are similar to the actions specified by [ACL- MODEL]. This layer also includes the policy monitoring of the individual NSFs and fault management of the policy execution. In NFV environment, policy consistency among multiple security function instances is very critical because security policies are no longer maintained by one central security devices, but instead are enforced by multiple security functions instantiated at various locations. 6.2. Service Layer Security Policy This layer is for customers or Application Gateway to express & monitor the needed security policies for their specific flows. Customers may not have security skills. As such, they are not able to express requirements or security policies that are precise enough. Usually these customers are expressing expectations (that can be viewed as loose security requirements). Customers may also express guidelines such as which critical communications are to be preserved during critical events, which hosts are to service even during severe security attacks, etc. Here are some examples of Service Oriented Security Policies: o Pass FW/IPS for Subscriber "xxx" with Port "y" o enable basic parental control o enable "school protection control" o allow Internet traffic from 8:30 to 20:00 [time = 8:30- 20:00] xxx, et al. Expires December 8, 2015 [Page 14] Internet-Draft I2NSF Framework June 2015 o scan email for malware detection [check type = malware] protect traffic to corporate network with integrity and confidentiality [protection type = integrity AND confidentiality] o remove tracking data from Facebook [website = *.facebook.com] o my son is allowed to access facebook from 18:30 to 20:00 One Service Layer Security Policy may need multiple security functions at various locations to achieve the enforcement. Service layer Security Policy may need to be updated by users or Application Gateway when user's service requirements have been changed. I2NSF will not standardize the Service Layer security policies. IETF SUPA - Shared Unified Policy Automation, if approved and chartered, seems to be a good candidate to play in this space. [I2NSF-Demo] describes an implementation of translating a set of Service Layer policies to the Capability Layer instructions to NSFs. 7. Capability Negotiation When a NSF can't perform the desired provisioning due to resource constraint, it has to inform the controller. The protocol needed for this security function/capability negotiation may be somewhat correlated to the dynamic service parameter negotiation procedure [RFC7297]. The Connectivity Provisioning Profile (CPP) template documented in RFC7297, even though currently covering only Connectivity (but includes security clauses such as isolation requirements, non-via nodes, etc.), could be extended as a basis for the negotiation procedure. Likewise, the companion Connectivity Provisioning Negotiation Protocol (CPNP) could be a candidate to proceed with the negotiation procedure. The "security as a service" would be a typical example of the kind of (CPP-based) negotiation procedures that could take place between a corporate customer and a service provider. However, more security specific parameters have to be considered by this proposed work. xxx, et al. Expires December 8, 2015 [Page 15] Internet-Draft I2NSF Framework June 2015 8. Types of I2NSF clients It is envisioned that I2NSF clients include: - Application Gateway: - For example, Video Conference Mgr/Controller needs to dynamically inform some FW/IPS/IDS security functions on special policies based specific fields in the packets for the specific encrypted flows for a certain time span. Otherwise, some flows can't go through the FW/IPS/IDS because the payload is encrypted. - Security Administrators - Enterprise - Operator Management System dynamically update, monitor and verify the security policies to security functions - Third party system - management system - Security functions send requests for more sophisticated functions upon detecting something suspicious 9. Manageability Considerations Management of NSFs usually include - life cycle management and resource management of vNSFs - configuration of devices, such as address configuration, device internal attributes configuration, etc, - signaling, and - policy provisioning. I2NSF will only focus on the policy provisioning part, i.e. the last bullet listed above. xxx, et al. Expires December 8, 2015 [Page 16] Internet-Draft I2NSF Framework June 2015 10. Security Considerations Having a secure access to control and monitor NSFs is crucial for hosted security service. Therefore, proper secure communication channels have to be carefully specified for carrying the controlling and monitoring information between the NSFs and their management entity (or entities). 11. IANA Considerations This document requires no IANA actions. RFC Editor: Please remove this section before publication. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC7297] Boucadair, M., "IP Connectivity Provisioning Profile", RFC7297, April 2014. 12.2. Informative References [I2NSF-ACCESS] A. Pastor, et al, "Access Use Cases for an Open OAM Interface to Virtualized Security Services", , Oct 2014. [I2NSF-DC] M. Zarny, et al, "I2NSF Data Center Use Cases", , Oct 2014. [I2NSF-MOBILE] M. Qi, et al, "Integrated Security with Access Network Use Case", , Oct 2014 [I2NSF-Problem] L. Dunbar, et al "Interface to Network Security Functions Problem Statement", , Jan 2015 xxx, et al. Expires December 8, 2015 [Page 17] Internet-Draft I2NSF Framework June 2015 [ACL-MODEL] D. Bogdanovic, et al, "Network Access Control List (ACL) YANG Data Model", , Nov 2014. [gs_NFV] ETSI NFV Group Specification, Network Functions Virtualizsation (NFV) Use Cases. ETSI GS NFV 001v1.1.1, 2013. [NW-2011] J. Burke, "The Pros and Cons of a Cloud-Based Firewall", Network World, 11 November 2011 [SC-MobileNetwork] W. Haeffner, N. Leymann, "Network Based Services in Mobile Network", IETF87 Berlin, July 29, 2013. [I2NSF-Demo] Y. Xie, et al, "Interface to Network Security Functions Demo Outline Design", , April 2015. 13. Acknowledgments Acknowledgements to xxx for his review and contributions. This document was prepared using 2-Word-v2.0.template.dot. xxx, et al. Expires December 8, 2015 [Page 18] Internet-Draft I2NSF Framework June 2015 Authors' Addresses Edward Lopez Fortinet 899 Kifer Road Sunnyvale, CA 94086 Phone: +1 703 220 0988 Email: elopez@fortinet.com Diego Lopez Telefonica Email: diego.r.lopez@telefonica.com XiaoJun Zhuang China Mobile Email: zhuangxiaojun@chinamobile.com Linda Dunbar Huawei Email: Linda.Dunbar@huawei.com Joe Parrott BT Email: joe.parrott@bt.com Ramki Krishnan Dell Email: ramki_krishnan@dell.com Seetharama Rao Durbha CableLabs Email: S.Durbha@cablelabs.com xxx, et al. Expires December 8, 2015 [Page 19]