Network Working Group L. Dunbar Internet Draft Huawei Intended status: Informational D. Lopez Expires: October 2015 Telefonica X. Zhuang China Mobile J. Parrott BT R Krishnan Brocade S. Durbha CableLabs April 21, 2015 Framework for Interface to Network Security Functions draft-merged-i2nsf-framework-00.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 October 21, 2015 [Page 1] Internet-Draft I2NSF Framework April 2015 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on October 21, 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 This document describes the framework for Interface to Network Security Functions and defines a reference model along with functional components. Table of Contents 1. Introduction...................................................3 2. Conventions used in this document..............................3 3. Multiple Interfaces to NSF.....................................4 3.1. Interface A - Registration Interface......................5 3.2. Interface B - Service Layer Policy Interface..............6 3.3. Interface C - Functional Layer Interface..................6 4. Security Function Capability Registration......................7 5. Security Policies at Service Layer and Function Layer.........10 5.1. Security Policies Service Layer..........................10 5.2. Security Policies at Functional Layer....................11 6. Types of I2NSF clients........................................12 7. Types of Access...............................................12 8. Manageability Considerations..................................13 xxx, et al. Expires October 21, 2015 [Page 2] Internet-Draft I2NSF Framework April 2015 9. Security Considerations.......................................13 10. Conclusion and Recommendation................................13 11. IANA Considerations..........................................14 12. References...................................................14 12.1. Normative References....................................14 12.2. Informative References..................................14 13. Acknowledgments..............................................15 1. Introduction This document describes the framework for Interface to Network Security Functions and defines a reference model along with functional components at various I2NSF interfaces. The goal is to create a workable interface to NSFs which aid in their integration within SDN/NFV environment, while avoiding potential constraints which could limit their functional capabilities. The I2NSF use cases ([I2NSF-ACCESS], [I2NSF-DC] and [I2NSF-Mobile]) call for standard interfaces for customers to utilize 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. BSS: Business Support System FW: Firewall IDS: Intrusion Detection System IPS: Intrusion Protection System xxx, et al. Expires October 21, 2015 [Page 3] Internet-Draft I2NSF Framework April 2015 NBI: Northbound Interface. "Northbound" can be ambiguous because "northbound" to entity A can be southbound to entity B. So we try to avoid using "northbound" in I2NSF. NSF: Network Security Functions OSS: Operation Support System 3. Multiple Interfaces to NSF From the security functions management perspective, three types of interfaces are needed for customers to request their security policies which are effectively enforced by a collection of NSFs (potentially from different vendors): - Capability Registration, - Service Layer Security Policies, and - Functional Layer security policies. From the I2NSF perspective, there is no difference between virtual network security functions (vNSF) and physical network security functions. However, in the environment where "vNSF" are deployed, there is more likelihood that the users/clients security policies are enforced by a collection of NSFs distributed throughout the network. xxx, et al. Expires October 21, 2015 [Page 4] Internet-Draft I2NSF Framework April 2015 Client/AppGW | | Interface B +-----+---------------+ |Service Provider mgmt| +-------------+ | Security Controller | < -------- > | Vendor | +---------------------+ Interface A | Sys | | +-------------+ | | Interface C | +------------------------------------------------+ | | | | +------+ +------+ +------+ +------+ + SF-1 + ------- + SF-n + + SF-1 + ----- + SF-m + . . . +------+ +------+ +------+ +------+ Vendor A Vendor B Figure 1: Multiple Interfaces 3.1. Interface A - Registration Interface Even though security functions come in variety of form factors and have different features, [Packet-based-NSF] advocates that the flow based security functions 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 Functional Profile - E.g. IPS:, signature file, Anti- virus file, URL filtering file, etc. Integrated and one-pass checks on the content of packets. xxx, et al. Expires October 21, 2015 [Page 5] Internet-Draft I2NSF Framework April 2015 The functional profile is vendor specific and differentiates vendor unique innovation. When service providers have multiple types of security functions provided by different vendors, vendors can register their security functions capabilities indicating the available policies that can be provisioned or monitored for each of the categories listed above. 3.2. Interface B - Service Layer Policy Interface This interface is for clients or Application Gateway to express and monitor security policies for their specific flows. A single client layer or service layer policy may need multiple security functions collectively together to achieve the enforcement. 3.3. Interface C - Functional Layer Interface A set of security functions may be needed to enforce the Service Layer Security Policies requested by the users/clients. The service providers' OSS or Security Controller have to terminate the user level security policies, select a set of the security functions collectively together to enforce the user requested security policies, and set the specific security policies to each function being selected. The Functional Layer Interface is between the Service Provider's OSS (or its Security Controller) and the security functions that are selected to accomplish the Service Layer Policies requested by users. Because there are so many security functions, the Network Security functions under I2NSF consideration start with Packet Based Security Functions, commonly supported by FW/IDS/IPS/WebFilter. xxx, et al. Expires October 21, 2015 [Page 6] Internet-Draft I2NSF Framework April 2015 4. Security Function Capability Registration There are many types of network security functions. To prevent constraints on NSF vendors' creativity and innovation, [Packet- Based-NSF] recommends the NSF interfaces to be designed from the paradigm of processing packets 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. Network Security functions differ in the depth of packet header or payload they can inspect, the various session/context states they can maintain, and the actions or specific profiles they can apply. Therefore, the NSF capabilities are characterized by the level of packet processing and context that a NSF supports, the actions and profiles that the NSF can apply. Vendors can register their provided security functions using the Subject-Object-Action-Function categories described by [Packet- based-NSF]. +-----------------------------------------------------------+ | Subject Capability Index | +---------------+-------------------------------------------+ | Layer 2 | Layer 2 header fields: | | Header | Source/Destination/s-VID/c-VID/EtherType/.| | | | |---------------+-------------------------------------------+ | Layer 3 | Layer header fields: | | | protocol | | IPv4 objects | port | | | src port | | | dscp | | | length | | | flags | | | ttl | | | | | IPv6 Object | | | | addr | | | protocol/nh | | | src port | | | length | | | traffic class | xxx, et al. Expires October 21, 2015 [Page 7] Internet-Draft I2NSF Framework April 2015 | | 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 | | | | 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 | xxx, et al. Expires October 21, 2015 [Page 8] Internet-Draft I2NSF Framework April 2015 +---------------+-------------------------------------------+ | 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 | Vendor specific | | | Flexible Profile URL | | | Accept external | | | | +---------------+-------------------------------------------+ xxx, et al. Expires October 21, 2015 [Page 9] Internet-Draft I2NSF Framework April 2015 5. Security Policies at Service Layer and Function Layer +------------------------------------------+ | App Gateway | | (e.g. Video conference Ctrl | | Admin, OSS/BSS, or Service Orchestration | +---------------------+--------------------+ I2NSF |Security Policy at Service Layer | +--------------+----------------+ | Network/Security Controller | +--------------+----------------+ I2NSF |Security Policy at Functional Layer | +------------------+ | Adapter | +------------------+ | virtual/physical | |Security Functions| +------------------+ Figure 1: Multiple Layers of I2NSF interfaces 5.1. Security Policies Service Layer 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 October 21, 2015 [Page 10] Internet-Draft I2NSF Framework April 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. This layer will leverage the existing protocols in NETCONF or RESTconf. 5.2. Security Policies at Functional Layer Security Policies at Functional Layer is to express the explicit policies to individual security functions 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 policies, which are derived from the Service Layer interface commands 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. The "subject" of the I2NSF functional layer not only includes the matching criteria specified by [ACL-MODEL] but also the L4-L7 fields depending on the NSF selected. The I2NSF functional 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]. The functional profiles for I2NSF are not present in [ACL-MODEL] because the functional profiles are unique to specific NSFs. xxx, et al. Expires October 21, 2015 [Page 11] Internet-Draft I2NSF Framework April 2015 Most vendors' IPS/IDS, and HoneyPot have their proprietary functions/profiles. 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. 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 7. Types of Access Depending on the relationship between I2NSF clients and their security functions providers, there could be different types of access: xxx, et al. Expires October 21, 2015 [Page 12] Internet-Draft I2NSF Framework April 2015 - 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. Integration with existing identity management systems is also possible. - Open environments where some network security functions (virtual or physical) can be hosted in external administrative domains, and more restrictive security 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. 8. Manageability Considerations TBD. 9. Security Considerations TBD 10. Conclusion and Recommendation xxx, et al. Expires October 21, 2015 [Page 13] Internet-Draft I2NSF Framework April 2015 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 [Packet-Based-NSF] E. Lopez, "Packet-Based Paradigm For Interfaces to NSFs", , in-progress, March 2015. [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 [ACL-MODEL] D. Bogdanovic, et al, "Network Access Control List (ACL) YANG Data Model", , Nov 2014. xxx, et al. Expires October 21, 2015 [Page 14] Internet-Draft I2NSF Framework April 2015 [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 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 October 21, 2015 [Page 15] Internet-Draft I2NSF Framework April 2015 Authors' Addresses Linda Dunbar Huawei Email: Linda.Dunbar@huawei.com Diego Lopez Telefonica Email: diego.r.lopez@telefonica.com XiaoJun Zhuang China Mobile Email: zhuangxiaojun@chinamobile.com Joe Parrott BT Email: joe.parrott@bt.com Ramki Krishnan Brocade Email: ramk@brocade.com Seetharama Rao Durbha CableLabs Email: S.Durbha@cablelabs.com xxx, et al. Expires October 21, 2015 [Page 16]