[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-baspez-baspez-capabilities) 00 draft-xibassnez-i2nsf-capability

I2NSF                                                          C. Basile
Internet-Draft                                                    PoliTo
Intended status: Experimental                                   D. Lopez
Expires: January 9, 2017                                             TID
                                                            July 8, 2016


    A Model of Security Capabilities for Network Security Functions
                   draft-baspez-i2nsf-capabilities-00

Abstract

   This document presents a model of Security Capabilities.  Security
   Capabilities are intended to describe the potentiality that Network
   Security Functions (NSFs) have for security policy enforcement
   purposes.  Therefore, Security Capabilities are represented as
   abstract functionalities that a NSF owns in terms of enforcement
   actions, conditions that can apply in order to determine to which
   packet or traffic enforce the actions, and other mechanisms that NSF
   use to determine the actions to enforce.  The proposed capability
   model defines without ambiguities the operations a function can do in
   term of security policy enforcement.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on January 9, 2017.

Copyright Notice

   Copyright (c) 2016 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



Basile & Lopez           Expires January 9, 2017                [Page 1]


Internet-Draft       A Capabilities Model for I2NSF            July 2016


   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
   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  3
   3.  Policy model . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Geometric model of policies  . . . . . . . . . . . . . . .  4
     3.2.  Condition types  . . . . . . . . . . . . . . . . . . . . .  7
   4.  Capability Model . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Algebra of capabilities  . . . . . . . . . . . . . . . . .  9
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     5.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11






























Basile & Lopez           Expires January 9, 2017                [Page 2]


Internet-Draft       A Capabilities Model for I2NSF            July 2016


1.  Introduction

   Security Capabilities are intended to describe the potentiality that
   Network Security Functions (NSFs) have for security policy
   enforcement purposes.  Security Capabilities are abstract concepts
   that are independent of the actual security control that will
   implement them.  However, every NSF will be associated to the
   capabilities it owns.  Security Capabilities are required to allow
   interoperability among network functions.  It would be a market
   enabler having a way to substitute a NSF with an equivalent one
   (i.e., having the same functionality).  Moreover, Security
   Capabilities are very useful to reason about generic functions, which
   may be needed at design time.  That is, it is not needed to refer to
   a specific product when designing the network, rather the functions
   characterized by their capabilities are considered.

   Therefore, we have developed another model where Security
   Capabilities determine what a security control can do in terms of
   conditions, actions, resolution strategies, external data, if it
   supports default action, etc.  That is, the Security Capabilities
   model defines without any ambiguity the things a function can do in
   term of security policy enforcement.  The Security Capability model
   is built on a predefined general policy model.  The type of policies
   that a NSF can enforce are obtained by customizing the general policy
   model with the Security Capability information.

   The Capability Model has been designed to support at least capability
   matching, i.e., to identify the NSFs in a catalog that can perform
   the operations required to enforce a high-level policy.

   Moreover, the Capability Model has been preliminarily validated by
   verifying that is allows the correct description of several existing
   security controls.


2.  Requirements Language

   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 [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.







Basile & Lopez           Expires January 9, 2017                [Page 3]


Internet-Draft       A Capabilities Model for I2NSF            July 2016


3.  Policy model

   The starting point of the design of our capability model is a simple
   observation.  As human beings, we all understand immediately each
   other when we refer to security controls by just naming their
   category.  For instance, experts agree on what is a NAT, a filtering
   control, or a VPN concentrator.  Network security experts
   unequivocally refer to ``packet filters'' as stateless devices able
   to allow or deny packets forwarding based on conditions on source and
   destination IP addresses, source and destination ports, and IP
   protocol type fields [Alshaer].  Moreover, it is known that packet
   filter rules are prioritized and it is possible to specify a default
   action.  More precisely, packet filters implement the First Matching
   Rule (FMR) or Last Matching Rule (LMR) resolution strategies.

   However, we feel the need for more information in case of other
   devices, like stateful firewalls or application layer filters.  These
   devices filter packets or communications, but there are differences
   among products in the packets and communications that they can
   categorize and the states they maintain.  Analogous considerations
   can be applied for channel protection protocols, where we all
   understand that they will protect packets by means of symmetric
   algorithms whose keys could have been negotiated with asymmetric
   cryptography, but they may work at different layers and support
   different algorithms and protocols.  To ensure protection, these
   protocols apply integrity, optionally confidentiality, apply anti-
   reply protections, and authenticate peers.

3.1.  Geometric model of policies

   We refer in this paper to the policy model defined in [Bas12] as
   geometric model, which is summarized here.  Policies are specified by
   means of a set of rules in the ``if condition then action'' format
   [RFC3198].  Rules are formed by a condition clause and an action
   clause.  All the actions available to the security function are well
   known and organized in an action set A.

   For filtering controls, the enforceable actions are Allow and Deny,
   thus A={Allow,Deny}.  For channel protection controls, they may be
   informally written as ``enforce confidentiality'', ``enforce data
   authentication and integrity'', and ``enforce confidentiality and
   data authentication and integrity''.  However, these actions need to
   be instantiated to the technology used, for instance AH-transport
   mode and ESP-transport mode (and combinations thereof) are a more
   precise and univocal definition of channel protection actions.

   Conditions are typed predicates concerning a given selector.  A
   selector describes the values that a protocol field may take, e.g.,



Basile & Lopez           Expires January 9, 2017                [Page 4]


Internet-Draft       A Capabilities Model for I2NSF            July 2016


   the IP source selector is the set of all possible IP addresses, and
   it may also refer to the part of the packet where the values come
   from, e.g., the IP source selector refers to the IP source field in
   the IP header.  Geometrically, a condition is the subset of its
   selector for which it evaluates to true.  A condition on a given
   selector matches a packet if the value of the field referred to by
   the selector belongs to the condition.  For instance, in Figure
   Figure 1 the conditions are s1 [ S1 (read as s1 subset of S1) and s2
   [ S2 (s1 subset of S2), both s1 and s2 match the packet x1, while
   only s2 matches x2.

     S2 ^ Destination port
        |
        |
        |        x2
        +........o
        |        .
        |        .
      --+..................+------------------------------------+
      | |        .         |                                    |
      s |        .         |                                    |
      e |        .         |            (rectangle)             |
      g |        .         |        condition clause (c)        |
      m |        .         |   here the action a is applied     |
      e |        .         |                                    |
      n |        .         |             x1=point=packet        |
      t +..................|.............o                      |
      | |        .         |             .                      |
      --+..................+------------------------------------+
        |        .         .             .                      .
        |        .         .             .                      .
        |        .         .             .                      .
        |        .         .             .                      .
        |        .         .             .                      .
        |        .         .             .                      .
  +--------------+---------+-------------+----------------------+------>
        |                  |---- segment = condition in S1 -----|     S1
        +                                                      IP source


   Figure 1: Geometric representation of a rule r=(c,a) that matches x1
                          but does not match x2.

   To consider conditions in different selectors, the decision space is
   extended using the Cartesian product because distinct selectors refer
   to different fields, possibly from different protocol headers.
   Hence, given a policy-enabled element that allows the definition of
   conditions on the selectors S1, S2,..., Sm (where m is the number of



Basile & Lopez           Expires January 9, 2017                [Page 5]


Internet-Draft       A Capabilities Model for I2NSF            July 2016


   selectors available at the security control we want to model), its
   selection space is:

   S=S1 X S2 X ...  X Sm

   To consider conditions in different selectors, the decision space is
   extended using the Cartesian product because distinct selectors refer
   to different fields, possibly from different protocol headers.

   Accordingly, the condition clause c is a subset of S:

   c = s1 X s2 X ...  X sm [ S1 \times S1 X S2 X ...  X Sm = S

   S represents the totality of the packets that are individually
   selectable by the security control to model when we use it to enforce
   a policy.  Unfortunately, not all its subsets are valid condition
   clauses: only hyper-rectangles or union of hyper-rectangles (as they
   are Cartesian product of conditions) are valid.  This is an intrinsic
   constraint of the policy languages as they specify rules by defining
   a condition for each selector.  Languages that allow specification of
   conditions as relations over more fields are modelled by the
   geometric model as more complex geometric shapes determined by the
   equations.  However, the algorithms to compute intersections are much
   more sophisticated than intersection hyper-rectangles.  Figure
   Figure 1 graphically represents a condition clause c in a two-
   dimensional selection space.

   In the geometric model, a rule is expressed as r=(c,a), where c [ S
   (the condition clause is a subset of the selection space), and the
   action a belongs to A. A condition clause of a rule matches a packet,
   or briefly a rule matches a packet, if all the conditions forming the
   clause match the packet: in Figure Figure 1, the rule with condition
   clause c matches the packet x1 but not x2.

   The rule set R is composed of n rules ri=(ci,ai).

   The decision criteria for the action to apply when a packet matches
   two or more rules is abstracted by means of the resolution strategy
   RS: Pow(R) -> A, where Pow(R) is the power set of rules in R.

   Formally, given a set of rules, the resolution strategy maps all the
   possible subsets of rules to an action a in A. When no rule matches a
   packet, the security controls may select the default action d in A,
   if they support one.

   Resolution strategies may use, besides intrinsic rule data (i.e.,
   condition clause and action clause), also ``external data''
   associated to each rule, such as priority, identity of the creator,



Basile & Lopez           Expires January 9, 2017                [Page 6]


Internet-Draft       A Capabilities Model for I2NSF            July 2016


   and creation time.  Formally, every rule ri is associated by means of
   the function e(.) to:

   e(ri) = (ri,f1(ri),f2(ri),...)

   where $E={fj:R -> Xj}j$ is the set that includes all the functions
   that map rules to external attributes in Xj.  However, E, e, and all
   the Xj are determined by the resolution strategy used.

   A policy is thus a function p: S -> A that connects each point of the
   selection space to an action taken from the action set A according to
   the rules in R. By also assuming RS(0)=d (where 0 is the empty-set)
   and RS(ri)=ai, the policy p can be described with this formula
   p(x)=RS(match{R(x)}).

   Therefore, in the geometric model, a policy is completely defined by
   the 4-tuple (R,RS,E,d): the rule set R, the resolution function RS,
   the set E of mappings to the external attributes, and the default
   action d.

   Note that, the geometric model also supports ECA paradigms by simply
   modelling events like an additional selector.

3.2.  Condition types

   After having analysed the literature and the existing security
   controls, we have categorized the types of selectors in exact match,
   range-based, regex-based, and custom-match [Bas15][Lunt].

   Exact match selectors are (unstructured) sets: elements can only be
   checked for equality, as no order is defined on them.  As an example,
   the protocol type field of the IP header is a unordered set of
   integer values associated to protocols.

   Range-based selectors are ordered sets where it is possible to
   naturally specify ranges as they can be easily mapped to integers.
   As an example, the ports in the TCP protocol are well represented
   using a range-based selector (e.g., 1024-65535).  We include in the
   range-based selectors all the category of selectors that have been
   defined by Al-Shaer et al. as prefix match [Alshaer].  These
   selectors allow the specification of ranges of values by means of
   simple regular expressions.  The typical case is the IP address
   selector (e.g., 10.10.1.*).  There is no need to distinguish between
   prefix match and range-based selectors as 10.10.1.* easily maps to
   [10.10.1.0, 10.10.1.255].

   Another category of selector types includes the regex-based
   selectors, where the matching is performed by using regular



Basile & Lopez           Expires January 9, 2017                [Page 7]


Internet-Draft       A Capabilities Model for I2NSF            July 2016


   expressions.  This selector type is frequent at the application
   layer, where data are often represented as strings of text.  The
   regex-based selector type also includes as sub-case the string-based
   selectors, where matching is evaluated using string matching
   algorithms (SMA) [Cormen] Indeed, for our purposes, string matching
   can be mapped to regular expressions, even if in practice SMA are
   much faster.  For instance, Squid (http://www.squid-cache.org/), a
   popular Web caching proxy that offers various access control
   capabilities, allows the definition of conditions on URLs that can be
   evaluated with SMA (e.g., dstdomain) or regex matching (e.g.,
   dstdom_regex).

   Finally, we introduce the idea of custom check selectors.  For
   instance the malware analysis looks for specific patterns and returns
   a Boolean value is an example of custom check selector, if the logic
   of checking is not seen (nor really interesting) from the outside.
   In order to be properly used by high-level policy based processed
   (like reasoning systems, refinement systems) these custom check
   selector need at least to be described as black-boxes, that is, the
   list of fields that they process (inputs) in order to return the
   Boolean verdict (output).


4.  Capability Model

   Our model of capabilities is based on actions and traffic
   classification features.  Indeed, the need for enforcing one of the
   actions that a security control can apply to packets/flows is the
   main reason to use a security control.  Moreover, security controls
   have classification features that permit the identification of the
   target packets/flows of the actions enforced, i.e., the selectors
   presented in Section 3.1.  A security manager decides for a specific
   security control depending on the actions and classification
   features.  If the security control can enforce the needed actions and
   has the classification features needed to identify the packets flows
   required by a policy, then the security control is capable of
   enforcing the policy.  Our refinement model needs to know NSFs
   capabilities to perform its operations.

   However, security controls may have specific characteristics that
   automatic processes or administrators need to know when they have to
   generate configurations, like the available resolution strategies and
   the possibility to set default actions.  We have ignored, to simplify
   this presentation, options to generate configurations that may have
   better performance, like the use of chains or ad hoc structures
   [Taylor].  Adding support to these forms of optimization is certainly
   feasible with a limited effort but it was outside the scope of this
   paper, that is, to show that adding security awareness to NFV



Basile & Lopez           Expires January 9, 2017                [Page 8]


Internet-Draft       A Capabilities Model for I2NSF            July 2016


   management and orchestration features is possible.  It is one of the
   task for future work.

   Capabilities can be used for two purposes: describing generic
   security functions, and describing specific products.  With the term
   generic security function (GNSF) we denote known classes of security
   functions.  The idea is to have generic components whose behaviour is
   as well understood as for the network components (i.e., a switch is a
   switch and we know to use it even if it may have some vendor-specific
   functions).  These generic functions can be substituted by any
   product that owns the required capability at instantiation time.

   We have analysed several classes of NSFs to prove the validity of our
   approach.  We found the common features and defined a set of generic
   NSFs, including packet filter, URL filter, HTTP filter, VPN gateway,
   anti-virus, anti-malware, content filter, monitoring, anonymity proxy
   that will be described in a data model TBD.

   Moreover, we have also categorized common extensions of the generic
   NSFs, packet filters that may decide based on time information.
   Moreover, some other packet filters add stateful features at ISO/OSI
   layer 4.

   The next section will introduce our algebra to compose capabilities,
   defined to associate NSFs to capabilities and to check whether a NSF
   has the capabilities needed to enforce policies.

4.1.  Algebra of capabilities

   Our capabilities are defined by a 4-tuple:

   (Ac; Cc; RSc; Dc) [ (AC; CC; RSC; DC)= K

   where AC is the set of all the supported actions, CC is set of all
   the supported conditions types, RSC is the set of all the supported
   resolutions strategies, and Dc [ DC={F} U A, where F indicates that
   the default action is supported and can be freely selected by the
   policy editor, and explicitly indicates the default action if this
   cannot be explicitly configured.

   We defined a syntax to specify:

   o  subsets of actions: Ac={a:action1,a:action2,...} [ AC

   o  subset of conditions: Cc={c:cond1,c:cond2,} [ CC

   o  subset of resolution strategies RSc={rs:res1,rs:res2,...} [ RSC




Basile & Lopez           Expires January 9, 2017                [Page 9]


Internet-Draft       A Capabilities Model for I2NSF            July 2016


   Given cap1=(Ac1,Cc1,RSc1,def1) and cap2=(Ac2,Cc2,RSc2,def2), we
   define

   o  capability addition: cap1+cap2 = (Ac1 U Ac2, Cc1 U Cc2, RSc1,
      def1)

   o  capability subtraction: cap_1-cap_2 = ({Ac1 \ Ac2,Cc1 \
      Cc2,RSc1,def1)

   Note that addition and subtraction do not alter the resolution
   strategy and the default action method, as our main intent was to
   model addition of modules

   As an example, a generic packet filter that supports the first
   matching rule resolution strategies, allows the explicit
   specification of default actions and also supports time-based
   conditions.  The description of its capabilities is the following:

   o  Apf = {a:Allow, a:Deny}

   o  Cpf= {c:IPsrc,c:IPdst,c:Psrc,c:Pdst,c:protType}

   o  Ctime = {c:timestart,c:days,c:datestart,c:datestop}

   o  cap_pf=(Apf; Cpf; {FMR}; F)

   o  cap_pf+time=cap_pf + Ctime

   By abuse of notation, we wrote cap_pf+time=cap_pf + Ctime to shorten
   the more correct expression cap_pf+time=cap_pf +(;Ctime;;)$.


5.  References

5.1.  Normative References

   [I-D.ietf-i2nsf-framework]
              elopez@fortinet.com, e., Lopez, D., Dunbar, L., Strassner,
              J., Zhuang, X., Parrott, J., Krishnan, R., and S. Durbha,
              "Framework for Interface to Network Security Functions",
              draft-ietf-i2nsf-framework-02 (work in progress),
              July 2016.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.




Basile & Lopez           Expires January 9, 2017               [Page 10]


Internet-Draft       A Capabilities Model for I2NSF            July 2016


   [RFC3198]  Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
              M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
              J., and S. Waldbusser, "Terminology for Policy-Based
              Management", RFC 3198, DOI 10.17487/RFC3198,
              November 2001, <http://www.rfc-editor.org/info/rfc3198>.

5.2.  Informative References

   [Alshaer]  Al Shaer, E. and H. Hamed, "Modeling and management of
              firewall policies", 2004.

   [Bas12]    Basile, C., Cappadonia, A., and A. Lioy, "Network-Level
              Access Control Policy Analysis and Transformation", 2012.

   [Bas15]    Basile, C. and A. Lioy, "Analysis of application-layer
              filtering policies with application to HTTP", 2015.

   [Cormen]   Cormen, T., "Introduction to Algorithms", 2009.

   [Lunt]     van Lunteren, J. and T. Engbersen, "Fast and scalable
              packet classification", 2003.

   [Taylor]   Taylor, D. and J. Turner, "Scalable packet classification
              using distributed crossproducting of field labels", 2004.


Authors' Addresses

   Cataldo Basile
   Politecnico di Torino
   Corso Duca degli Abruzzi, 34
   Torino,   10129
   Italy

   Phone: +39 011 090 7173
   Email: cataldo.basile@polito.it


   Diego R. Lopez
   Telefonica I+D
   Zurbaran, 12
   Madrid,   28010
   Spain

   Phone: +34 913 129 041
   Email: diego.r.lopez@telefonica.com





Basile & Lopez           Expires January 9, 2017               [Page 11]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/