INTERNET-DRAFT E. Lopez Intended Status: Informational Fortinet Expires: September 23, 2015 March 22, 2015 Packet-Based Paradigm For Interfaces To NSFs draft-lopez-i2nsf-packet-00 Abstract In the design of interfaces to allow for the provisioning of network- based security functions (NSFs), a critical consideration is to prevent the creation of implied constraints. This draft makes the recommendation that such interfaces 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. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. E. Lopez Expires September 23, 2015 [Page 1] INTERNET DRAFT draft-lopez-i2nsf-packet-00 March 22, 2015 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. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Packet-Based Paradigm . . . . . . . . . . . . . . . . . . . . . 4 2.1 Packet Headers . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Packet Payloads . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Functional State Information . . . . . . . . . . . . . . . 5 4 Provisioning Interface Structural Overview . . . . . . . . . . 5 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1 Normative References . . . . . . . . . . . . . . . . . . . 6 7.2 Informative References . . . . . . . . . . . . . . . . . . 7 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 E. Lopez Expires September 23, 2015 [Page 2] INTERNET DRAFT draft-lopez-i2nsf-packet-00 March 22, 2015 1 Introduction The emergence of networking paradigms based on the use of devices with programmable forwarding planes, has resulted in the need to create application program interfaces (APIs) in support integration of NSFs within software-defined networking (SDN) and network-function virtualization (NFV) environments. APIs to 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. Configuration API functions may already be part of ongoing efforts associated with other management protocols such as NETCONF. 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. 3) Provisioning - used to control the security functions of 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 standardized functions, without E. Lopez Expires September 23, 2015 [Page 3] INTERNET DRAFT draft-lopez-i2nsf-packet-00 March 22, 2015 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. 1.1 Terminology 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]. 2 Packet-Based Paradigm Conceptually, the packet-based paradigm is that regardless of functional capabilities, NSFs share that same principal capability as all NBFs in processing packets. NSFs process packets based on information from: - the packet header- the packet payload- functional state information on NSFs regarding the packets, or the sessions to which packets belong 2.1 Packet Headers The examination of packet headers is useful in the classification of packets up to the transport layer (IP protocol/port). This information is also used in packet forwarding decisions. For example, [OPENFLOW-1.5] makes use of some packet header fields as match structures in defining match structures for OpenFlow-compatible switches. In a similar way, a provisioning interface for NSFs can make use of packet header field as a 'subject' value, defining the packet header characteristics matching a particular policy statement. 2.2 Packet Payloads The examination of packet payloads is useful in the classification of packets at the application layer. It is assumed that technical means E. Lopez Expires September 23, 2015 [Page 4] INTERNET DRAFT draft-lopez-i2nsf-packet-00 March 22, 2015 exist in which information can be gleaned by NSFs from packet payloads, which can be used to detect application types beyond IP protocol/port, or to look into additional header fields within encapsulated traffic. Payload-based characteristics can also be incorporated as a 'subject' value of a provisioning interface. However, a common syntax for expressing how payload values are matched needs to be clearly defined. 2.3 Functional State Information NSFs not only inspect values within the packet, but also a variety of contexts associated with the packet. Examples include: - An explicit context, such as a user or device authentication state, which may be correlated to an IP address within the packet.- Time- based information, which can be explicitly used to determine the validity of a packet relative to a policy schedule, or implicitly relative to a timer-based psuedo state of a session using a stateless protocol like UDP- An implicit context, such as the session state of a stateful IP protocol such as TCP or SCTP The contextual states employed by an NSF in evaluating packets can be considered to be 'object' values of a provisioning interface. Since many of these are dependant of the capabilities of the NSF, a means of performing a capabilities exchange of 'object' values which can utilized in provisioning policy onto NSFs. 4 Provisioning Interface Structural Overview It is not the intention of this draft to provide technical detail on a provisioning interface to NSFs. Instead, it is intended to suggest that a packet-based paradigm can be used to describe policy statements applied to NSFs. Such policy statements would be based upon four root values: Subject.Object.Function.Action Where: - Subject = Match values based on information carried within the packet header or payload itself.- Object = Match values based on contextual information associated with received packets.- Function = Values with invoke specific security functions provided by the NSF.- Action = Values that determine how packets are handled post security function processing. E. Lopez Expires September 23, 2015 [Page 5] INTERNET DRAFT draft-lopez-i2nsf-packet-00 March 22, 2015 Each of these root values can be defined with additional sub-values to provide required details. For example, a 'function' may have additional object values to provide granular information in how packets are processed. If a NSF function was to perform web filtering, a functional statement may not only state that web- filtering is to be performed, but also which defined filter object is to be employed (Function=:). It is intended that this form of root:branch structure can be easily integrated into normative API structures, such as JSON or RESTful APIs This implies that there are four types of communications used within this provisioning interface: - Exchange - a capabilities exchange between the NSF and the provisioning application- Configure - statement that provide a provisioning application the ability to create and configure objects use in provisioning policy statements- Provision - Policy statements used to provision security functions within NSFs- Query - statements which may either be requests by provisioning applications to query policy statement data from NSFs, or gratuitous information (such as counters) from NSFs to provisioning applications 5 Security Considerations As this draft is focused on the creation of interfaces to NSFs, the security considerations are based on: - Preventing the imposition of constraints which would limit the functionality of NSFs, or the ability to deploy them onto networks. - Ensuring the creation of such interfaces does not create additional security vulnerabilities, including risks associated with their passive surveillance. 6 IANA Considerations This draft does not impose requirements onto IANA. 7 References 7.1 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . E. Lopez Expires September 23, 2015 [Page 6] INTERNET DRAFT draft-lopez-i2nsf-packet-00 March 22, 2015 7.2 Informative References [USECASES] Pastor, A. & Lopez,D., "Access Use Cases for an Open OAM Interface to Virtualized Security", draft-pastor-i2nsf-access- usecases-00, October 2014, [PCI-DSS] PCI Security Standards Council, "Payment Card Industry (PCI) Data Security Standard - Requirements and Security Assessment Procedures - Version 3", November 2013, [OPENFLOW-1.5] Open Networking Foundation, "OpenFlow Switch Specification, Version 1.5.0", December 2014, 8 Acknowledgements The author wishes to thank and acknowledge the support of Linda Dunbar, Diego Lopez Garcia, Dan Romascanu, and Kathleen Moriarty in discussions which led to the creation of this draft. This acknowledgement does not imply agreement with or endorsement of this draft by these individuals. Authors' Addresses Edward Lopez Fortinet 899 Kifer Road Sunnyvale, CA 94086 Phone: +1 703 220 0988 EMail: elopez@fortinet.com E. Lopez Expires September 23, 2015 [Page 7]