[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01 02 03 04 05 06                                          
Network Working Group                                           H.Rafiee
INTERNET-DRAFT                                                  D. Zhang
Intended Status: Informational                       Huawei Technologies
Expires: April 27, 2015                                 October 27, 2014


                   Analysis of Existing Work for I2NSF
                    <draft-zhang-gap-analysis-00.txt>

Abstract

   This document analysis the status of the arts in industries and the
   existing IETF work/protocols that are relevant to I2NSF.





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 April 27, 2015.





Copyright Notice

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


Rafiee & Zhang       Expires April 27, 2015                     [Page 1]


INTERNET DRAFT                            NFV Security  October 27, 2014

   described in the Simplified BSD License.



Table of Contents

   1.  Introduction   . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used In This Document  . . . . . . . . . . . . . .  4
   3.  Analysis of NFV Status of the Arts in Industry   . . . . . . .  5
   4.  Comparison of Current IETF Works   . . . . . . . . . . . . . .  5
     4.1.  NSIS   . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.2.  SACM   . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  MIDCOM   . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.4.  PCP  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.5.  SFC & VNFpool  . . . . . . . . . . . . . . . . . . . . . .  8
     4.6.  ANIMA  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Conclusion and Recommendation  . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1.  Normative  . . . . . . . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11

































Rafiee & Zhang       Expires April 27, 2015                     [Page 2]


INTERNET DRAFT                            NFV Security  October 27, 2014


1.  Introduction

   This document has two purposes ? analyzes Network Virtualized
   Function (NFV)/ Software Defined Network (SDN) status of the art in
   industries (security architectures) to compare available features,
   and analyzes the existing IETF work/protocols that are relevant to
   I2NSF. The result of this work can assist to understand the status of
   the arts and understand the requirements for the features that need
   to be standard (or addressed during standardization) because of
   possible interoperability and orchestration of the services among
   different players.

   One of the I2NSF goals is to develop application or user oriented
   policies (or the descriptors) of the network security functions that
   clients can request and query from 3rd party providers. Another goal
   is to have proper mechanism to carry the policies between clients and
   providers.

   There are many network security functions being deployed and new ones
   are popping up with business and application demands. In order to
   have a concrete context for the protocols discussion, we start with
   the following network security related functions:

   - Firewall

   - DDOS/Anti-DOS

   - Access control/Authorization/Authentication

   - Remote identity management

   - Secure Key management

   - Intrusion Detection System/ Intrusion Prevention System (IDS/IPS)

   It is envisioned that clients of the I2NSF interfaces include
   management applications, service orchestration systems, network
   controllers, or user applications that may solicit network security
   resources.

   Various aspects to I2NSF include:

   * The mechanism for clients (applications) to
   request/negotiate/validate security functions those are not
   physically located on the local premises,

   * The mechanism for creating virtual security functions on physical
   appliances, and

   * Application/user oriented rules/policies to instantiate virtual
   security functions as VMs on common compute servers (NFV initiative).



Rafiee & Zhang       Expires April 27, 2015                     [Page 3]


INTERNET DRAFT                            NFV Security  October 27, 2014

   The objective of the proposed work is to standardize the protocols
   (or the interface) and architecture for Requester and Provider to
   negotiate the functions needed as well as the associated attributes.

   The proposed protocols between requester and provider can be used for
   the following scenarios:

   * A Client requests a certain network security function from a
   provider

   * The provider fulfills the request for example, by instantiating an
   instance of the service in question, or configures an additional rule
   in an already provisioned service.


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.

   - Cloud DC: The data centers that are not on premises of enterprises
   yet have the compute/storage resources that can be requested or
   purchased by the enterprises. What the enterprises actually get is
   Virtual Data Centers.

   - DC: Data Center

   - Domain: The term ?Domain? in this draft has different connotations
   in different scenarios:

   - Client <-> Provider relationship, i.e. client requesting some
   network functions from its provider;

   - Domain A <-> Domain B relationship, i.e. one operator domain
   requesting some network functions from another operator domain; or

   - Applications <-> Network relationship, i.e. an application (e.g.
   cluster of servers) requesting some functions from network, etc.

   - Virtual Security Function: a security function that can be
   requested by one domain but may be owned or managed by another
   domain.

   - Cloud-based security functions: used interchangeably with the
   ?Virtual Security Functions? in this draft.

   - NBI: Northbound Interface. ?Northbound? can be ambiguous because
   ?northbound? to entity A can be southbound to entity B. So we try to


Rafiee & Zhang       Expires April 27, 2015                     [Page 4]


INTERNET DRAFT                            NFV Security  October 27, 2014

   avoid using ?northbound? in I2NSF.


3.  Analysis of NFV Status of the Arts in Industry

   Network Function Virtualization (NFV) provides the service providers
   with flexibility, cost effective and agility to offer their services
   to customers. However, there might be different trends or policies to
   offer the services to end users. This might prevent end users to
   receive services from different service providers because of no
   possible interoperability between the service providers. It might
   also confuse end users to ask services from service providers. There
   are several players that offer provide their services to different
   service providers that here we only list some of them. For example,
   one of players focused on the mechanisms to provide orchestration
   between programmable networking technologies and other powerful
   services. Simplifying the management tasks, traffic virtualization,
   advanced flow control, Improved Converged Network agility, Security
   as a Service (deep packet inspection and Network Admission Control)
   and Network more programmable is some of the features. The others
   focus on the combination of Software Defined Network (SDN) approaches
   with NFV. Some of the features are flexibility in distributing over
   the virtual infrastructure in WAN and the use of visualized network
   functions (VNF), easily adaptability with different networks, the
   possibility to run an application on different hardware platform and
   data centers are close to the point of data consumption. One more
   example is a player who offers a platform on which network functions
   can become more secure than ever, provide the security as a service,
   improve automation, easily upgradable,



   Therefore, in industries, the current architectures don?t mostly
   maintain interoperability and there might be no clear policies on how
   two/many service providers suppose to interact with eachother to
   provide a service to end users. This is because the assumptions often
   are that end users use services from the same service providers, data
   centers are close to service providers so that end users can easily
   be verified and simply access different services on data centers and
   data centers belong to the same service providers. This is why there
   is a missing common language for exchanging policies and
   automatically allowing several authorized services from different
   service providers to work with eachother. This is especially critical
   and complex where some of these virtualized services should provide
   end users with security functions (such as a firewall).


4.  Comparison of Current IETF Works


4.1.  NSIS

   NSIS is for standardizing an IP signaling protocol (RSVP) along data


Rafiee & Zhang       Expires April 27, 2015                     [Page 5]


INTERNET DRAFT                            NFV Security  October 27, 2014

   path for end points to request its unique QoS characteristics, unique
   FW policies or NAT needs (RFC5973) that are different from the FW/NAT
   original setting. The requests are communicated directly to the
   FW/NAT devices. NSIS is like east-west protocols that require all
   involved devices to fully comply to make it work.

   NSIS is path-coupled, it's possible to message every participating
   device along a path without having to know its location, or its
   location relative to other devices (this is particularly a pressing
   issue when you've got one or more NATs present in the network, or
   when trying to locate appropriate tunnel endpoints).



   Here are some aspects that I2NSF is different from NSIS:

   - The I2NSF requests from clients don?t usually go directly to
   network security devices, but instead to controller or orchestrator
   that can translate the application/user oriented policies to the
   involved devices in the interface that they support.

   - The I2NSF doesn?t require all network functions to comply.

   - I2NSF is to define clients (applications) oriented descriptors
   (profiles, or attributes) to request/negotiate/validate network
   security functions that are not physically located on the local
   premises.

   Why we believe I2NSF has higher chance to be deployed than NSIS:



   1- OpenStack already has preliminary implementation, but the
   specification is not complete. IETF can play an active role to make
   the specification complete. Extend what OpenStack has to more
   comprehensive specifications that can meet operators requirement, and
   then have operators encourage their suppliers to contribute open
   source per IETF specifications to the OpenStack community. As the
   software development cycle: Architecture, Design specification, and
   coding: IETF can take the ownership of the first two steps.



   2- The requests are to controllers, instead of to devices. It doesn?t
   require all middle boxes to be changed to make it work. The security
   can be better controlled by the controllers.



   3- There is very strong momentum to make virtualized network
   functions to be deployed by operators (NFV initiative).




Rafiee & Zhang       Expires April 27, 2015                     [Page 6]


INTERNET DRAFT                            NFV Security  October 27, 2014

4.2.  SACM

   IETF SACM (Security Assessment and Continuous Monitoring) specifies
   the mechanisms to assess end point security. The end points can be
   routers, switches, clustered DB, installed piece of software. SACM is
   about ?How to encode that policy in a manner where assessment can be
   automated?.

   Here are the major differences between SACM and I2NSF:

   SACM:

   * End points can be routers, switches, clustered DB, installed piece
   of software

   * How to encode policies in a manner where assessment can be
   automated

   Example:

   - a Solaris 10 SPARC or Window 7 system used in a environment that
   requires adherence to a policy of Mission Critical Classified.

   - rules like "The maximum password age must be 30 days" and "The
   minimum password age must be 1 day"

   I2NSF:

   - Protocols for clients to request/query/verify Security related
   functions from Network Providers

   - Firewall

   - DDOS/Anti-DOS

   - Access control/Authorization/Authentication

   - Remote identity management

   - Secure Key management

   - Intrusion Detection System/ Intrusion Prevention System (IDS/IPS)

   Example:

   * vCPE needs vFW that are hosted in the network.

   * vCPE provides the ?Group Policies? for the vFW, like A can talk to
   B & C, but B can?t talk to C.


4.3.  MIDCOM



Rafiee & Zhang       Expires April 27, 2015                     [Page 7]


INTERNET DRAFT                            NFV Security  October 27, 2014

   To be added.


4.4.  PCP

   As indicated by the name, the Port Control Protocol (PCP) enables an
   IPv4 or IPv6 host to flexibly manage the IP address and port mapping
   information on Network Address Translators (NATs) or firewalls, to
   facilitate communication with remote hosts.

   Here are some aspects that I2NSF is different from PCP:

   ?    PCP only support the management of port and address information
   rather than any other security functions


4.5.  SFC & VNFpool

   IETF SFC is about mechanism of chaining together service functions;
   IETF SFC treats all those ?Service Functions? as black box, i.e. SFC
   doesn?t care what actions those functions are performing. SFC defines
   the SFC header to carry Metadata with payload to those functions. But
   SFC itself doesn?t specify what content is encoded in the metadata.

   I2NSF is targeted to define the descriptor (the actual rules &
   policies) of the network security functions needed and the
   negotiation scheme.

   Those policies or descriptors don?t usually go with user payload.

   VNFpool is about the reliability and availability of the virtualized
   network functions. But none of them address how service functions are
   requested, or how service functions are fulfilled.

   VNFpool does not cover in-depth specification (e.g. rules for the
   requested FW) for clients to request its needed functions. In SFC &
   VNFpool, FW function is a black box, that is treated in same way as
   Video Optimization function. SFC/VNFpool don?t cover the negotiation
   part, e.g. Client needs Rule x/y/z for FW, but the Provider can only
   offer x/z.


4.6.  ANIMA

   ANIMA (Autonomic Networking Integrated Model and Approach) introduces
   a control paradigm where network processes, driven by objectives (or
   intent), coordinate their local decisions, autonomically translate
   them into local actions, and adapt them automatically according to
   various sources of information including external information and
   protocol information bases.

   ANIMA will develop protocols to achieve auto discovery among
   management system and devices. The listed drafts proposed ?The


Rafiee & Zhang       Expires April 27, 2015                     [Page 8]


INTERNET DRAFT                            NFV Security  October 27, 2014

   Configuration Discovery and Negotiation protocol designed to be a
   generic platform, which is independent from the negotiation
   contents.? There are also the Security aspects being discussed in the
   ANIMA drafts (like secure messages, or keys, among the parties (to be
   discovered).

   I2NSF is to develop application /user oriented policies (the
   attributes, the profiles, or the descriptors) of the network security
   functions that clients can request/query from 3rd party providers.



   There might be some elements/protocols developed by ANIMA that can be
   used by I2NSF.




5.  Conclusion and Recommendation

   In industries there is a missing common language that can help
   service providers to inter-operate with eachother. For having this
   common language (standard), the mechanism to carry the policies
   between clients and providers can be built upon the past IETF work
   and protocols.

6.  Security Considerations

   There is no security consideration



7.  IANA Considerations

   There is no IANA consideration





8.  References

8.1.  Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to
             Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.









Rafiee & Zhang       Expires April 27, 2015                     [Page 9]


INTERNET DRAFT                            NFV Security  October 27, 2014
























































Rafiee & Zhang       Expires April 27, 2015                    [Page 10]


INTERNET DRAFT                            NFV Security  October 27, 2014

Authors' Addresses

      Hosnieh Rafiee
      HUAWEI TECHNOLOGIES Duesseldorf GmbH
      Riesstrasse 25, 80992,
      Munich, Germany
      Phone: +49 (0)162 204 74 58
      Email: ietf@rozanak.com


      Dacheng Zhang
      HUAWEI TECHNOLOGIES
      Q14 huawei campus, Beiqing Rd., Haidian Dist.,
      Beijing, China
      E-mail: zhangdacheng@huawei.com






































Rafiee & Zhang       Expires April 27, 2015                    [Page 11]