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, . [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, . [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, . 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]