Skip to main content

Framework for Interface to Network Security Functions
draft-merged-i2nsf-framework-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Linda Dunbar , Diego Lopez , Xiaojun Zhuang , Joe Parrott , Ramki Krishnan , Seetharama Rao Durbha
Last updated 2015-04-21
Replaced by draft-ietf-i2nsf-problem-and-use-cases, draft-ietf-i2nsf-framework, RFC 8329
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-merged-i2nsf-framework-00
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:<Profile>, 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", <draft-lopez-i2nsf-packet-00>, in-progress,
             March 2015.

   [I2NSF-ACCESS] A. Pastor, et al, "Access Use Cases for an Open OAM
             Interface to Virtualized Security Services", <draft-
             pastor-i2nsf-access-usecases-00>, Oct 2014.

   [I2NSF-DC] M. Zarny, et al, "I2NSF Data Center Use Cases", <draft-
             zarny-i2nsf-data-center-use-cases-00>, Oct 2014.

   [I2NSF-MOBILE] M. Qi, et al, "Integrated Security with Access
             Network Use Case", <draft-qi-i2nsf-access-network-usecase-
             00>, Oct 2014

   [I2NSF-Problem] L. Dunbar, et al "Interface to Network Security
             Functions Problem Statement", <draft-dunbar-i2nsf-problem-
             statement-01>, Jan 2015

   [ACL-MODEL] D. Bogdanovic, et al, "Network Access Control List (ACL)
             YANG Data Model", <draft-ietf-net-acl-model-00>, 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]