idnits 2.17.1 draft-zhou-i2nsf-capability-interface-monitoring-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2015) is 3105 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.xia-dots-extended-use-cases' is mentioned on line 93, but not defined == Missing Reference: 'I-D.reddy-dots-info-model' is mentioned on line 95, but not defined == Unused Reference: 'RFC2119' is defined on line 237, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) -- No information found for draft-merged-i2nsf-framework - is the name correct? Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Zhou 3 Internet-Draft L. Xia 4 Intended status: Informational Huawei Technologies 5 Expires: April 21, 2016 M. Boucadair 6 France Telecom 7 J. Xiong 8 Huawei Technologies 9 October 19, 2015 11 The Capability Interface for Monitoring Network Security Functions (NSF) 12 in I2NSF 13 draft-zhou-i2nsf-capability-interface-monitoring-00 15 Abstract 17 This document focuses on the monitoring aspects of the flow-based 18 Network Security Functions (NSFs). The NSF Capability interface 19 between the Service Provider's management system (or Security 20 Controller) and the NSFs is meant to enforce the required monitoring 21 capability. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 21, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. The Capability Interface for Monitoring . . . . . . . . . . . 3 60 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.2. Traffic Report . . . . . . . . . . . . . . . . . . . . . 4 62 3.3. Policy Enforcement . . . . . . . . . . . . . . . . . . . 5 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 6.2. Informative References . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 Rising security problems bring challenges for the security 73 enterprises and organizations. There are already some software and 74 hardware devices deployed for these problems, e.g., antivirus, 75 firewall, intrusion detection systems (IDS), Web security gateway, 76 and DPI, which build up many safety lines accordingly. However, one 77 individual safety line only defenses the security threats of only one 78 aspect. And more seriously, these safety defense devices are 79 generating large amount of logs and events in the operating 80 procedure, which makes a lot of "information island". With large 81 quantity and isolated security information, it brings low efficiency 82 for the security managers who operate on their own control platform 83 and warning window of various devices. 85 The network security mechanism would be more efficient if the 86 Security Controller defined in [I-D.merged-i2nsf-framework] could 87 monitor, analyze and investigate the abnormal events and finally 88 produce security reports to the security administrators. The 89 security controller should also be able to collect the traffic and 90 session information from the NSF, in order to steer the suspected 91 attack source or victim traffic to the cleaning center. 93 The data mining use case defined in [I-D.xia-dots-extended-use-cases] 94 has provided a good example for distributed denial-of-service (DDoS) 95 attack monitoring report. [I-D.reddy-dots-info-model] also describes 96 the information model of flow monitoring to help identify DDOS 97 attacks in a network. This document aims to cover more cases and 98 more attack types in the network, e.g., botnets, spam, and spyware. 100 This document describes how to use the capability interface to 101 collect the security information from the NSFs and which security 102 information will be reported using this interface. The protocol and 103 information model will be described for the monitoring aspects of the 104 Capability Interface. 106 2. Terminology 108 3. The Capability Interface for Monitoring 110 3.1. Overview 112 The capability interface should be able to provide unified event 113 format for the logs and warning information of the overall network, 114 to facilitate the failure discovery and failure locating timely and 115 accurately. With the unified event format, the security managers 116 could run easily and quickly through various security events which 117 guarantees the availability of service information system and service 118 continuity. To achieve this, the Security Controller needs to 119 collect the detailed information of the network status and traffic 120 information from the NSF to make intelligent security decision and to 121 dynamically adjust the sampling and steering policy. 123 +---------------------+ 124 | Security Controller | 125 +-----+----------+----+ 126 ^ | 127 Capability |1.Traffic |2.Policy 128 Interface for | report |Enforcement 129 monitoring | | 130 | v 131 +---------------+----------------------+ 132 | | 133 | | 134 +------+ +------+ 135 + NSF-1+ ------- ... --------- + NSF-n+ 136 +------+ +------+ 138 Figure 1: Monitoring Interface 140 As described in Figure 1, the traffic monitoring procedure involves 141 two network elements: Security Controller (SC) and NSF. The NSF 142 reports the monitoring information to the SC, which provides the 143 specific traffic information, e.g., abnormal flows, security logs, 144 statistics or the suspicious attack sources or destinations. The SC 145 is responsible for monitoring and collecting traffic information from 146 NSFs. Based on the input from the NSF, the SC could make policy 147 enforcement for the specific flows, e.g., traffic steering or 148 adjusting the flow sampling policies. 150 3.2. Traffic Report 152 The traffic reported from the NSF may contain the information of IP 153 addresses, security logs, statistics, warnings, and etc. The syslog 154 protocol [RFC5424] could be used to send event notification messages 155 to the SC for traffic collection. The IP Flow Information Export 156 (IPFIX) protocol [RFC5101] may also be adopted for the flow sampling 157 information collection. There are mainly three types of information 158 reported using the capability interface: 160 o Traffic Statistics: 162 * Normal traffic statistics based on the source and destination 163 address, including byte per second (bps) and packet per second 164 (pps). 166 * Abnormal traffic statistics based on the source and destination 167 address, including bps and pps. 169 * Traffic statistics based on the network address range 170 (including port usage), including bps and pps. 172 o Session Statistics: 174 * Concurrent session statistics based on the source and 175 destination address. 177 * New session statistics based on the source and destination 178 address. 180 * Abnormal session statistics based on the source and destination 181 address, including null link, retransmission session and slow- 182 start link. 184 o Abnormal/Attack Event: analysis results of the relevant abnormal/ 185 attack event, e.g., time, type, level, detail description, 186 threshold, source IP address and destination IP address. 188 The NSF could report the accurate source and destination of the 189 attack to the security controller for which to make traffic steering 190 policy, e.g., steering the bad "botnet" traffic to the cleaning 191 center. The type, size and proportion of the abnormal traffic could 192 also be reported to assist the security controller to determine the 193 steering priority, e.g., priority traction, large flow cleaning. 195 3.3. Policy Enforcement 197 The Security Controller is responsible for making policy decisions 198 after getting the security information from the NSF (and, typically, 199 other instructions from the operator). It will provide the attack 200 mitigation and defense strategy with the acquired sampling traffic 201 information for attack detection by the way of dynamically adjusting 202 the flow sampling policy, e.g., flow information, sampling ratio, 203 sampling encapsulation method and/or sampling point information. The 204 policies may include: traffic cleaning and sampling adjustment. 206 o Traffic cleaning: with the suspicious result of the analyzed 207 sampling traffic, the security controller dynamically sends the 208 steering policy to the related NSF or sends the flow blocking 209 policy to the NSF which is nearest to the attack point, to block 210 the attack traffic from the source. The traffic cleaning policy 211 may include the following three ones: 213 * Access Control List (ACL), to block the attack traffic. 215 * Packet hash digest to block the attack traffic. 217 * Traffic steering policy to clean the traffic. 219 o Flow sampling adjustment: after filtering the abnormal object of 220 the sampling traffic, the security controller could dynamically 221 adjust the sampling policy to improve the sampling rate of the 222 TOPN abnormal object, in order to make more accurate attack 223 detection. The abnormal object may include: Top N network address 224 range of the abnormal session, Top N IP address of the abnormal 225 session and the Top N of abnormal sessions. 227 4. Security Considerations 229 5. IANA Considerations 231 This document has no actions for IANA. 233 6. References 235 6.1. Normative References 237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 238 Requirement Levels", BCP 14, RFC 2119, 239 DOI 10.17487/RFC2119, March 1997, 240 . 242 [RFC5101] Claise, B., Ed., "Specification of the IP Flow Information 243 Export (IPFIX) Protocol for the Exchange of IP Traffic 244 Flow Information", RFC 5101, DOI 10.17487/RFC5101, January 245 2008, . 247 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 248 DOI 10.17487/RFC5424, March 2009, 249 . 251 6.2. Informative References 253 [I-D.merged-i2nsf-framework] 254 Lopez, E., Lopez, D., Zhuang, X., Dunbar, L., Parrott, J., 255 Krishnan, R., and S. Durbha, "Framework for Interface to 256 Network Security Functions", June 2015. 258 Authors' Addresses 260 Cathy Zhou 261 Huawei Technologies 262 Bantian, Longgang District 263 Shenzhen 518129 264 P.R. China 266 Email: cathy.zhou@huawei.com 268 Liang Xia (Frank) 269 Huawei Technologies 270 101 Software Avenue, Yuhuatai District 271 Nanjing, Jiangsu 210012 272 P.R. China 274 Email: Frank.xialiang@huawei.com 275 Mohamed Boucadair 276 France Telecom 277 Rennes 35000 278 France 280 Email: mohamed.boucadair@orange.com 282 Jie Xiong 283 Huawei Technologies 284 101 Software Avenue, Yuhuatai District 285 Nanjing, Jiangsu 210012 286 P.R. China 288 Email: emma.xiong@huawei.com