Internet DRAFT - draft-lopez-i2nsf-packet

draft-lopez-i2nsf-packet



 



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=<function>:<instance>).  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,
              <http://www.rfc-editor.org/info/rfc2119>.
 


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, <http://datatracker.ietf.org/doc/draft-
   pastor-i2nsf-access-usecases>

   [PCI-DSS]  PCI Security Standards Council, "Payment Card Industry
   (PCI) Data Security Standard - Requirements and Security Assessment
   Procedures - Version 3", November 2013,
   <https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf>

   [OPENFLOW-1.5]  Open Networking Foundation, "OpenFlow Switch
   Specification, Version 1.5.0", December 2014,
   <https://www.opennetworking.org/images/stories/downloads/sdn-
   resources/onf-specifications/openflow/openflow-switch-
   v1.5.0.noipr.pdf>   


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]