[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                            C. Zhou
Internet-Draft                                                    L. Xia
Intended status: Informational                       Huawei Technologies
Expires: April 21, 2016                                     M. Boucadair
                                                          France Telecom
                                                                J. Xiong
                                                     Huawei Technologies
                                                        October 19, 2015


The Capability Interface for Monitoring Network Security Functions (NSF)
                                in I2NSF
          draft-zhou-i2nsf-capability-interface-monitoring-00

Abstract

   This document focuses on the monitoring aspects of the flow-based
   Network Security Functions (NSFs).  The NSF Capability interface
   between the Service Provider's management system (or Security
   Controller) and the NSFs is meant to enforce the required monitoring
   capability.

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 21, 2016.

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



Zhou, et al.             Expires April 21, 2016                 [Page 1]


Internet-Draft       Monitoring capability of i2nsf         October 2015


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  The Capability Interface for Monitoring . . . . . . . . . . .   3
     3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Traffic Report  . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Policy Enforcement  . . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Rising security problems bring challenges for the security
   enterprises and organizations.  There are already some software and
   hardware devices deployed for these problems, e.g., antivirus,
   firewall, intrusion detection systems (IDS), Web security gateway,
   and DPI, which build up many safety lines accordingly.  However, one
   individual safety line only defenses the security threats of only one
   aspect.  And more seriously, these safety defense devices are
   generating large amount of logs and events in the operating
   procedure, which makes a lot of "information island".  With large
   quantity and isolated security information, it brings low efficiency
   for the security managers who operate on their own control platform
   and warning window of various devices.

   The network security mechanism would be more efficient if the
   Security Controller defined in [I-D.merged-i2nsf-framework] could
   monitor, analyze and investigate the abnormal events and finally
   produce security reports to the security administrators.  The
   security controller should also be able to collect the traffic and
   session information from the NSF, in order to steer the suspected
   attack source or victim traffic to the cleaning center.

   The data mining use case defined in [I-D.xia-dots-extended-use-cases]
   has provided a good example for distributed denial-of-service (DDoS)
   attack monitoring report.  [I-D.reddy-dots-info-model] also describes
   the information model of flow monitoring to help identify DDOS



Zhou, et al.             Expires April 21, 2016                 [Page 2]


Internet-Draft       Monitoring capability of i2nsf         October 2015


   attacks in a network.  This document aims to cover more cases and
   more attack types in the network, e.g., botnets, spam, and spyware.

   This document describes how to use the capability interface to
   collect the security information from the NSFs and which security
   information will be reported using this interface.  The protocol and
   information model will be described for the monitoring aspects of the
   Capability Interface.

2.  Terminology

3.  The Capability Interface for Monitoring

3.1.  Overview

   The capability interface should be able to provide unified event
   format for the logs and warning information of the overall network,
   to facilitate the failure discovery and failure locating timely and
   accurately.  With the unified event format, the security managers
   could run easily and quickly through various security events which
   guarantees the availability of service information system and service
   continuity.  To achieve this, the Security Controller needs to
   collect the detailed information of the network status and traffic
   information from the NSF to make intelligent security decision and to
   dynamically adjust the sampling and steering policy.




                 +---------------------+
                 | Security Controller |
                 +-----+----------+----+
                       ^          |
         Capability    |1.Traffic |2.Policy
         Interface for | report   |Enforcement
          monitoring   |          |
                       |          v
       +---------------+----------------------+
       |                                      |
       |                                      |
    +------+                              +------+
    + NSF-1+ -------  ...       --------- + NSF-n+
    +------+                              +------+



                      Figure 1: Monitoring Interface




Zhou, et al.             Expires April 21, 2016                 [Page 3]


Internet-Draft       Monitoring capability of i2nsf         October 2015


   As described in Figure 1, the traffic monitoring procedure involves
   two network elements: Security Controller (SC) and NSF.  The NSF
   reports the monitoring information to the SC, which provides the
   specific traffic information, e.g., abnormal flows, security logs,
   statistics or the suspicious attack sources or destinations.  The SC
   is responsible for monitoring and collecting traffic information from
   NSFs.  Based on the input from the NSF, the SC could make policy
   enforcement for the specific flows, e.g., traffic steering or
   adjusting the flow sampling policies.

3.2.  Traffic Report

   The traffic reported from the NSF may contain the information of IP
   addresses, security logs, statistics, warnings, and etc.  The syslog
   protocol [RFC5424] could be used to send event notification messages
   to the SC for traffic collection.  The IP Flow Information Export
   (IPFIX) protocol [RFC5101] may also be adopted for the flow sampling
   information collection.  There are mainly three types of information
   reported using the capability interface:

   o  Traffic Statistics:

      *  Normal traffic statistics based on the source and destination
         address, including byte per second (bps) and packet per second
         (pps).

      *  Abnormal traffic statistics based on the source and destination
         address, including bps and pps.

      *  Traffic statistics based on the network address range
         (including port usage), including bps and pps.

   o  Session Statistics:

      *  Concurrent session statistics based on the source and
         destination address.

      *  New session statistics based on the source and destination
         address.

      *  Abnormal session statistics based on the source and destination
         address, including null link, retransmission session and slow-
         start link.

   o  Abnormal/Attack Event: analysis results of the relevant abnormal/
      attack event, e.g., time, type, level, detail description,
      threshold, source IP address and destination IP address.




Zhou, et al.             Expires April 21, 2016                 [Page 4]


Internet-Draft       Monitoring capability of i2nsf         October 2015


   The NSF could report the accurate source and destination of the
   attack to the security controller for which to make traffic steering
   policy, e.g., steering the bad "botnet" traffic to the cleaning
   center.  The type, size and proportion of the abnormal traffic could
   also be reported to assist the security controller to determine the
   steering priority, e.g., priority traction, large flow cleaning.

3.3.  Policy Enforcement

   The Security Controller is responsible for making policy decisions
   after getting the security information from the NSF (and, typically,
   other instructions from the operator).  It will provide the attack
   mitigation and defense strategy with the acquired sampling traffic
   information for attack detection by the way of dynamically adjusting
   the flow sampling policy, e.g., flow information, sampling ratio,
   sampling encapsulation method and/or sampling point information.  The
   policies may include: traffic cleaning and sampling adjustment.

   o  Traffic cleaning: with the suspicious result of the analyzed
      sampling traffic, the security controller dynamically sends the
      steering policy to the related NSF or sends the flow blocking
      policy to the NSF which is nearest to the attack point, to block
      the attack traffic from the source.  The traffic cleaning policy
      may include the following three ones:

      *  Access Control List (ACL), to block the attack traffic.

      *  Packet hash digest to block the attack traffic.

      *  Traffic steering policy to clean the traffic.

   o  Flow sampling adjustment: after filtering the abnormal object of
      the sampling traffic, the security controller could dynamically
      adjust the sampling policy to improve the sampling rate of the
      TOPN abnormal object, in order to make more accurate attack
      detection.  The abnormal object may include: Top N network address
      range of the abnormal session, Top N IP address of the abnormal
      session and the Top N of abnormal sessions.

4.  Security Considerations

5.  IANA Considerations

   This document has no actions for IANA.







Zhou, et al.             Expires April 21, 2016                 [Page 5]


Internet-Draft       Monitoring capability of i2nsf         October 2015


6.  References

6.1.  Normative References

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

   [RFC5101]  Claise, B., Ed., "Specification of the IP Flow Information
              Export (IPFIX) Protocol for the Exchange of IP Traffic
              Flow Information", RFC 5101, DOI 10.17487/RFC5101, January
              2008, <http://www.rfc-editor.org/info/rfc5101>.

   [RFC5424]  Gerhards, R., "The Syslog Protocol", RFC 5424,
              DOI 10.17487/RFC5424, March 2009,
              <http://www.rfc-editor.org/info/rfc5424>.

6.2.  Informative References

   [I-D.merged-i2nsf-framework]
              Lopez, E., Lopez, D., Zhuang, X., Dunbar, L., Parrott, J.,
              Krishnan, R., and S. Durbha, "Framework for Interface to
              Network Security Functions", June 2015.

Authors' Addresses

   Cathy Zhou
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Email: cathy.zhou@huawei.com


   Liang Xia (Frank)
   Huawei Technologies
   101 Software Avenue, Yuhuatai District
   Nanjing, Jiangsu  210012
   P.R. China

   Email: Frank.xialiang@huawei.com








Zhou, et al.             Expires April 21, 2016                 [Page 6]


Internet-Draft       Monitoring capability of i2nsf         October 2015


   Mohamed Boucadair
   France Telecom
   Rennes  35000
   France

   Email: mohamed.boucadair@orange.com


   Jie Xiong
   Huawei Technologies
   101 Software Avenue, Yuhuatai District
   Nanjing, Jiangsu  210012
   P.R. China

   Email: emma.xiong@huawei.com




































Zhou, et al.             Expires April 21, 2016                 [Page 7]


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