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

Versions: 00 01 02 03 04 05 06 07

Network Working Group                                           D. Zhang
Internet-Draft                                                     Y. Wu
Intended status: Experimental                             Aliababa Group
Expires: September 18, 2016                                       L. Xia
                                                                  Huawei
                                                          March 17, 2016


 An Information Model for the Monitoring of Network Security Functions
                                 (NSF)
               draft-zhang-i2nsf-info-model-monitoring-00

Abstract

   In this draft, an information model for the capability interface
   monitoring network security functions (NSF) is proposed.

Requirements Language

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

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 September 14, 2016.

Copyright Notice

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



Zhang, et al.          Expires September 18, 2016               [Page 1]


Internet-Draft              Abbreviated-Title                 March 2016


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Common Information  . . . . . . . . . . . . . . . . . . . . .   3
   3.  Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  System Alarm  . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.1.  Memory Alarm  . . . . . . . . . . . . . . . . . . . .   4
       3.1.2.  CPU Alarm . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.3.  DISK Alarm  . . . . . . . . . . . . . . . . . . . . .   4
       3.1.4.  Session Table Alarm . . . . . . . . . . . . . . . . .   5
       3.1.5.  Interface Alarm . . . . . . . . . . . . . . . . . . .   5
     3.2.  Security Event Alarm  . . . . . . . . . . . . . . . . . .   5
       3.2.1.  DDoS Alarm  . . . . . . . . . . . . . . . . . . . . .   5
       3.2.2.  Virus Alarm . . . . . . . . . . . . . . . . . . . . .   6
       3.2.3.  Intrusion Alarm . . . . . . . . . . . . . . . . . . .   7
       3.2.4.  Botnet Alarm  . . . . . . . . . . . . . . . . . . . .   7
       3.2.5.  Web Attack Alarm  . . . . . . . . . . . . . . . . . .   8
   4.  Reports . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Attack Report . . . . . . . . . . . . . . . . . . . . . .   9
       4.1.1.  DDoS Report . . . . . . . . . . . . . . . . . . . . .   9
       4.1.2.  Virus Report  . . . . . . . . . . . . . . . . . . . .  10
       4.1.3.  Intrusion Report  . . . . . . . . . . . . . . . . . .  10
       4.1.4.  Botnet Report . . . . . . . . . . . . . . . . . . . .  10
       4.1.5.  Web Attack Report . . . . . . . . . . . . . . . . . .  11
     4.2.  Service Report  . . . . . . . . . . . . . . . . . . . . .  11
       4.2.1.  Traffic Report  . . . . . . . . . . . . . . . . . . .  11
       4.2.2.  Policy HIT Report . . . . . . . . . . . . . . . . . .  11
       4.2.3.  DPI Report  . . . . . . . . . . . . . . . . . . . . .  11
     4.3.  System Report . . . . . . . . . . . . . . . . . . . . . .  11
     4.4.  Operation Report  . . . . . . . . . . . . . . . . . . . .  11
     4.5.  Running Report  . . . . . . . . . . . . . . . . . . . . .  11
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12






Zhang, et al.          Expires September 18, 2016               [Page 2]


Internet-Draft              Abbreviated-Title                 March 2016


1.  Introduction

   According to [I-D.merged-i2nsf-framework], the interface provided by
   a NSF (e.g., FW, AAA, IPS, Anti- DDOS, or Anti-Virus) for other
   network entities (e.g., I2NSF client, or network/security controller)
   to control and monitor the NSF is referred to as a 'capability
   interface'.  In practice, the NSF can communicate with the network
   entities though the capability interface in either a 'push' or a
   'pull' way.  The NSF can send out a report about its status or about
   certain network event proactively or send out message as a reply to
   network entities who control or monitor it.  This memo will not go
   into the design details of capability interface.  Instead, this draft
   is engaged in specifying the information that a NSF needs to provided
   in the monitoring part of the capability interface.

   In this memo, the following types of reports that a NSF may need to
   provide are considerred:

   o  The alarm triggered by a certain status in NSF

   o  The alarm triggered by a certain security event

   o  The report about the security events occured in a certain period

   o  The report about the status of NSF in a certain period

2.  Common Information

   There are some information that should be provided in each message
   sent from a NSF to the network entity monitoring it.

   o  Time Stampe: indicate the time when the message is generated.

   o  NSF name: the name (or IP) of the device generatign the message.

   o  Vendor name: the name of the NSF vendor

   o  Type of NSF: inidcate what type the NSF is (e.g., firewall, WAF,
      IPS)

   o  NSF model

   o  Vesion: The version of the interface

   o  NSF Version: The software version of the NSF

   o  Type of report: Alarm, periodical report, etc.




Zhang, et al.          Expires September 18, 2016               [Page 3]


Internet-Draft              Abbreviated-Title                 March 2016


3.  Alarm

   An alarm is the message generated by a NSF.  An alarm could be
   triggered by certain abnormal conditions occurred in a NSF (referred
   to as a System Alarm) or a detected network abnormal conditions
   (referred to as a Security Event Alarm).

3.1.  System Alarm

3.1.1.  Memory Alarm

   The following information should be included in a Memory Alarm:

   o  event _Name: MEM_USAGE_HIGH

   o  usage:the usage rate of memory

   o  threshold: the threshold triggering the event

   o  message: The memory usage exceeded the threshold

3.1.2.  CPU Alarm

   The following information should be included in a CPU Alarm:

   o  event _Name: 'MEM_USAGE_HIGH'

   o  usage:the usage rate of CPU

   o  threshold: the threshold triggering the event

   o  message: 'The CPU usage exceeded the threshold'

3.1.3.  DISK Alarm

   The following information should be included in a Disk Alarm:

   o  event _Name: 'MEM_USAGE_HIGH'

   o  usage:the usage rate of disk

   o  threshold: the threshold triggering the event

   o  message: 'The disk usage exceeded the threshold'







Zhang, et al.          Expires September 18, 2016               [Page 4]


Internet-Draft              Abbreviated-Title                 March 2016


3.1.4.  Session Table Alarm

   The following information should be included in a Session
   Table Alarm:

   o  event _Name: 'SESSION_USAGE_HIGH'

   o  current: the number of concurrent sessions

   o  Max:the maximum number of sessions that the session table can
      support

   o  threshold: the threshold triggering the event

   o  message: 'The number of session table exceeded the threshold'

3.1.5.  Interface Alarm

   The following information should be included in a Interface Alarm:

   o  event _Name: 'IFNET_State'

   o  interface_Name:the name of interface

   o  state: 'UP' or'DOWN'

   o  message: 'The disk usage exceeded the threshold'

3.2.  Security Event Alarm

3.2.1.  DDoS Alarm

   The following information should be included in a DDoS Alarm:

   o  event_Name: 'SEC_EVENT_DDoS'

   o  sub_attack_type: any one of Syn flood, ACK flood, SYN-ACK flood,
      FIN/RST flood, TCP Connection flood, UDP flood, Icmp flood, HTTPS
      flood, HTTP flood, DNS query flood, DNS reply flood, SIP flood,
      and etc.

   o  dst_ip: the IP address of a victum under attack

   o  dst_port: the port numbers that the attrack traffic aims at.

   o  start_time: The time stampe indicating when the attack started





Zhang, et al.          Expires September 18, 2016               [Page 5]


Internet-Draft              Abbreviated-Title                 March 2016


   o  end_time:The time stampe indicating when the attack ended.  If the
      attack is still undergoing when sending out the alarm, this field
      can be empty.

   o  attack_rate: the PPS of attack traffic

   o  attack_speed: the bps of attack traffic

3.2.2.  Virus Alarm

   The following information should be included in a Virus Alarm:

   o  event_Name: 'SEC_EVENT_Virus'

   o  virus_type: type of the virus, e.g.,
      trojan,worm,macro Virus type

   o  virus_name

   o  dst_ip: The destination IP address of the packet where the virus
      is found

   o  src_ip: The source IP address of the packet where the virus is
      found

   o  src_port: The source port of the packet where the virus is found

   o  dst_port: The destination port of the packet where the virus is
      found

   o  src_zone: The source security zone of the packet where the virus
      is found

   o  dst_zone: The destination security zone of the packet where the
      virus is found

   o  file_type: The type of the file where the virus is hided within

   o  file_name: The name of the file where the virus is hided within

   o  virus_info: The brief introduction of virus

   o  raw_info: The information describing the packet triggering the
      event.

   o

   o



Zhang, et al.          Expires September 14, 2016               [Page 6]


Internet-Draft              Abbreviated-Title                 March 2016


3.2.3.  Intrusion Alarm

   The following information should be included in a Intrustion Alarm:

   o  event_name: the name of event:SEC_EVENT_Intrusion

   o  sub_attack_type: attack type,e.g., brutal
      force、buffer overflow

   o  src_ip: The source IP address of the packet

   o  dst_ip: The destination IP address of the packet

   o  src_port:The source port number of the packet

   o  dst_port; The destination port number of the packet

   o  src_zone :the source security zone of the packet

   o  dst_zone: the destination security zone of the packet

   o  protocol: The employed transport layer
      protocol,e.g.,TCP、UDP

   o  app: The employed application layer
      protocol,e.g.,HTTP、FTP

   o  rule_id: The ID of the rule being triggered

   o  rule_name: The name of the rule being triggered

   o  intrusion_info: Simple description of intrusion

   o  raw_info: The information describing the packet triggering the
      event.

3.2.4.  Botnet Alarm

   The following information should be included in a Botnet Alarm:

   o  event_name: the name of event:SEC_EVENT_Botnet

   o  botnet_name: The name of the detected botnet

   o  src_ip: The source IP address of the packet

   o  dst_ip: The destination IP address of the packet




Zhang, et al.          Expires September 18, 2016               [Page 7]


Internet-Draft              Abbreviated-Title                 March 2016


   o  src_port: The source port number of the packet

   o  dst_port: The destination port number of the packet

   o  src_zone: the source security zone of the packet

   o  dst_zone: the destination security zone of the packet

   o  protocol: The employed transport layer
      protocol,e.g.,TCP、UDP

   o  app: The employed application layer
      protocol,e.g.,HTTP、FTP

   o  role: The role of the communicating parties within the botnet:

      1.  the packet from zombie host to the attacker

      2.  The packet from the attacker to the zombie host

      3.  The packet from the IRC/WEB server to the zombie host

      4.  The packet from the zombie host to the IRC/WEB server

      5.  The packet from the attacker to the IRC/WEB server

      6.  The packet from the IRC/WEB server to the attacker

      7.  The packet from the zombie host to the victim

   o  botnet_info: Simple description of Botnet

   o  raw_info: The information describing the packet triggering the
      event.

3.2.5.  Web Attack Alarm

   The following information should be included in a Web Attack Alarm:

   o  event_name: the name of event:SEC_EVENT_WebAttack

   o  sub_attack_type: Concret web attack type,e.g.,sql
      injection 、command injection 、XSS、CSRF

   o  src_ip: The source IP address of the packet

   o  dst_ip: The destination IP address of the packet




Zhang, et al.          Expires September 18, 2016               [Page 8]


Internet-Draft              Abbreviated-Title                 March 2016


   o  src_port: The source port number of the packet

   o  dst_port: The destination port number of the packet

   o  src_zone: the source security zone of the packet

   o  dst_zone: the destination security zone of the packet

   o  req_method: the method of requirement.  For instance, 'PUT' or
      'GET' in HTTP.

   o  req_url: Requested URL

4.  Reports

   Different from Alarms, a report normally triggered by a timmer or a
   request from the NE monitoring the device.  So compared to alarms, a
   report contains more statical information.

4.1.  Attack Report

4.1.1.  DDoS Report

   Besides the fields in an DDoS Alarm, the following information should
   be included in a DDoS Report:

   o  attack_type: attack type: DDoS

   o  attack_ave_rate: The average pps of the attack traffic within the
      recorded time

   o  attack_ave_speed: The average bps of the attack traffic within the
      recorded time

   o  attack_pkt_ num: The number attack packets within the recorded
      time

   o  rule_id: The ID of the rule being triggered

   o  rule_name: The name of the rule being triggered

   o  attack_ src_ip: The source IP addresses of attack traffics.  If
      there are a large amount of IP addresses, then pick a certain
      number of resources according to different rules.







Zhang, et al.          Expires September 18, 2016               [Page 9]


Internet-Draft              Abbreviated-Title                 March 2016


4.1.2.  Virus Report

   Besides the fields in an Virus Alarm, the following information
   should be included in a Virus Report:

   o  attack_type: attack type: Virus

      *

   o  protocol The transport layer protocol

   o  app The name of the application layer protocol

   o  times The time of detecting the virus

   o  action The actions dealing with the virus, e.g.,
      alert,block os The OS that the virus will affect, e.g.,
      all,android,ios,unix,windows

4.1.3.  Intrusion Report

   Besides the fields in an Intrusion Alarm, the following information
   should be included in a Intrusion Report:

   o  attack_type: attack type: Intrusion

   o  times: The times of intrusions happened in the recorded time
      action STRING The actions dealing with the intrusions, e.g.,
      alert,block

   o  os: The OS that the intrusion will affect, e.g., all, android,
      ios, unix, windows

   o  action: The actions dealing with the intrusions, e.g., alert,
      block

   o  attack_rate: NUM the pps of attack traffic

   o  attack_speed: NUM the bps of attack traffic

4.1.4.  Botnet Report

   Besides the fields in an Botnet Alarm, the following information
   should be included in a Botnet Report:

   o  attack_type: attack type: Botnet





Zhang, et al.          Expires September 18, 2016              [Page 10]


Internet-Draft              Abbreviated-Title                 March 2016


   o  botnet_pkt_num:The number of the packets sent to or from the
      detected botnet

   o  action: The actions dealing with the detected packets, e.g.,
      alert,block

   o  os: The OS that the attack aiming at, e.g., all,android&#65
      292;ios,unix,windows等。

4.1.5.  Web Attack Report

   Besides the fields in an Web Attack Alarm, the following information
   should be included in a Web Attack Report:

   o  attack_type: attack type: Web Attack

   o  rsp_code: response code

   o  req_clientapp: the client application

   o  req_cookies: Cookies

   o  req_host: The domain name of the requested host

   o  raw_info: The information describing the packet triggering the
      event.

4.2.  Service Report

4.2.1.  Traffic Report

   TBD

4.2.2.  Policy HIT Report

   TBD

4.2.3.  DPI Report

4.3.  System Report

4.4.  Operation Report

4.5.  Running Report







Zhang, et al.          Expires September 18, 2016              [Page 11]


Internet-Draft              Abbreviated-Title                 March 2016


5.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

6.  Security Considerations

   TBD

7.  Acknowledgements

8.  References

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

8.2.  Informative References

   [I-D.merged-i2nsf-framework]
              Ed, E., Lopez, D., Dunbar, L., Strassner, J., Zhuang, X.,
              Parrott, J., Krishnan, R., and S. Durbha, "Framework for
              Interface to Network Security Functions", draft-merged-
              i2nsf-framework-04 (work in progress), October 2015.

Authors' Addresses

   Dacheng Zhang
   Aliababa Group

   Email: dacheng.zdc@alibaba-inc.com


   Yi Wu
   Aliababa Group

   Email: anren.wy@alibaba-inc.com


   Liang Xia
   Huawei

   Email: frank.xialiang@huawei.com



Zhang, et al.          Expires September 18, 2016              [Page 12]


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