IPFIX Working Group T. Fu Internet-Draft Huawei Intended status: Standards Track D. Zhang Expires: October 30, 2015 D. He L. Xia Huawei April 28, 2015 IPFIX Information Elements for inspecting network security issues draft-fu-ipfix-network-security-01 Abstract IPFIX protocol has been used to carry Information Elements, which are defined to measure the traffic information and information related to the traffic observation point, traffic metering process and the exporting process. Network or device status are checked through analysing neccessary observed information. Although most of the existing Information Elements are useful for network security inspection, they are still not sufficient to determine the reasons behind observed events such as for DDOS attack, ICMP attack, and fragment attack. To allow administrators making effective and quick response to the attacks, this document extends the standard Information Elements and describes the formats for inspecting network security. 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 October 30, 2015. Fu, et al. Expires October 30, 2015 [Page 1] Internet-Draft IPFIX IEs for network security April 2015 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 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Information Elements and use cases . . . . . . . . . . . . . 4 3.1. Information Elements . . . . . . . . . . . . . . . . . . 4 3.2. Packet upstream/downstream counters . . . . . . . . . . . 9 3.3. ICMP echo/echo reply counters . . . . . . . . . . . . . . 9 3.4. Fragment statistic . . . . . . . . . . . . . . . . . . . 9 3.5. Application error code . . . . . . . . . . . . . . . . . 10 3.6. Extended value of FlowEndReason . . . . . . . . . . . . . 10 4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. IPFIX . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Terminology IPFIX-specific terminology (Information Element, Template, Template Record, Options Template Record, Template Set, Collector, Exporter, Data Record, etc.) used in this document is defined in Section 2 of [RFC7011]. As in [RFC7011], these IPFIX-specific terms have the first letter of a word capitalized. 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 [RFC2119]. Fu, et al. Expires October 30, 2015 [Page 2] Internet-Draft IPFIX IEs for network security April 2015 2. Introduction As network security issues arising dramatically nowadays, network administrators are eager to detect and identify attacks as early as possible, generate countermeasurements with high agility. Due to the enormous amount of network attack types, metrics useful for attack detection are as diverse as attack patterns themselves. Moreover, attacking methods are evolved rapidly, which brings challenges to designing detect mechanism. The IPFIX requirement [RFC3917] points out that one of the target applications of IPFIX is atack and intrusion detection. The IPFIX Protocol [RFC7011] defines a generic exchange mechanism for flow information and events. It supports source-triggered exporting of information due to the push model approach other than exporting upon flow-end or fixed time intervals.The IPFIX Information Model [RFC5102] defines a list of standard Information Elements (IEs) which can be carried by the IPFIX protocol. Eventhough the existing standard IEs are useful to check the status/events of the traffic, they are not sufficient to help network administrators identify categories of the attacks. The scanty information will result in an inaccurate analysis and slowing down the effective response towards network attacks. For instance, CC (Challenge Collapsar) attack is a typical application layer DDoS attack, which mainly attacks the dynamic pages of web server. It makes the web server's resources exhausted and paralyzed, so the server will be denial of service. Because CC attacker imitates normal users' behavior pretty well by using different real IP addresses with relatively completive access process (even with low speed), it makes the attack concealed well compared with traditional network layer DDoS (e.g. SYN-Flood, etc). In addition, the attacker often manipulates the attack behind the scenes by non-direct communicate with target server, so the attack is not easy to be tracked and discovered. It would be useful to collect application status information for application layer attacks. In this case, CC attack is likely to happen if a large number of non 2XX HTTP status code replied from the server are observed. Fragment attack employs unexpected formats of fragmentation, which will result in errors such as fragmentation buffer full, fragment overlapped, fragment incomplete. Existing IPFIX fragmentation metrics includes fragmentOffset, fragmentIdentification, fragmentFlags, which only indicate the attributes of a single fragment, and are not suitable for attack detection. Integrated measurements are needed to provide an holistic review of the session. Furthermore ICMP flow model has features such as the ICMP Echo/Echo Reply dominate the whole traffic flow, ICMP packet interval is Fu, et al. Expires October 30, 2015 [Page 3] Internet-Draft IPFIX IEs for network security April 2015 usually not too short (normally 1 pkt/s). The current ICMP information elements of IPFIX contains the ICMP type and code for both IPv4 and IPv6, however they are for a single ICMP packet rather than statistical property of the ICMP session. Further metrics like the cumulated sum of various counters should be calculated based on sampling method defined by the Packet SAMPling (PSAMP) protocol [RFC 5477]. Similar problems occur in TCP, UDP, SNMP and DNS attack, it would be useful to derive the number of the upstream and downstream packets separately and over time in order to detect the anomalies of the network. Upon the above discussions and per IPFIX applicability [RFC 5472], derived metrics are useful to provide sufficient evidence about security incident. A wisely chosen sets of derived metrics will allow direct exporting with minimal resource consumption. This document extends the IPFIX Information model and defines Information Elements (IEs) that SHOULD be used to identify different attack categories, the standardization of those IEs will improve the network security and will support the offline analysis of data from different operators in the future. 3. Information Elements and use cases This section presents the information elements that are useful for attack detection, the IPFIX templates could contain a subset of the Information Elements(IEs) shown in Table 1 depending upon the attack under concern of the network administrator. For example a session creation template contains {sourceIPv4Address, destinationIpv4Address, sourceTransportPort, destinationTransportPort, protocolIdentifier, pktUpstreamCount, pktDownstreamCount, selectorAlgorithm, samplingPacketInterval, samplingPacketSpace} An example of the actual event data record is shown below in a readable form {192.168.0.201, 192.168.0.1, 51132, 80, 7, 67, 87, 3, 100,1000} 3.1. Information Elements The following is the table of all the IEs that a device would need to export for attack statistic analysis. The formats of the IEs and the IPFIX IDs are listed below. Most of the IEs are defined in [IPFIX- IANA], while some of the IPFIX IE's ID are not assigned yet, and hence the detailed explanation of these fields are presented in the following sections. The recommended registrations to IANA is described the IANA considerations section. Fu, et al. Expires October 30, 2015 [Page 4] Internet-Draft IPFIX IEs for network security April 2015 +---------------------------+--------------+-------+----------------+ | Field Name | Size (bits) | IANA | Description | | | | IPFIX | | | | | ID | | +---------------------------+--------------+-------+----------------+ | sourceIPv4Address | 32 | 8 | Source IPv4 | | | | | Address | | destinationIPv4Address | 32 | 12 | Destination | | | | | IPv4 Address | | sourceTransportPort | 16 | 7 | Source Port | | destinationTransportPort | 16 | 11 | Destination | | | | | port | | protocolIdentifier | 8 | 4 | Transport | | | | | protocol | | packetDeltaCount | 64 | 2 | The number of | | | | | incoming | | | | | packets since | | | | | the previous | | | | | report (if | | | | | any) for this | | | | | Flow at the | | | | | Observation | | | | | Point | | pktUpstreamCount | 64 | TBD | Upstream | | | | | packet counter | | pktDownstreamCount | 64 | TBD | Downstream | | | | | packet counter | | octetUpstreamCount | 64 | TBD | Upstream octet | | | | | counter | | octetDownstreamCount | 64 | TBD | Downstream | | | | | octet counter | | tcpSynTotalCount | 64 | 218 | The total | | | | | number of | | | | | packets of | | | | | this Flow with | | | | | TCP | | | | | "Synchronize | | | | | sequence | | | | | numbers" (SYN) | | | | | flag set | | tcpFinTotalCount | 64 | 219 | The total | | | | | number of | | | | | packets of | | | | | this Flow with | | | | | TCP "No more | | | | | data from | | | | | sender" (FIN) | | | | | flag set | Fu, et al. Expires October 30, 2015 [Page 5] Internet-Draft IPFIX IEs for network security April 2015 | tcpRstTotalCount | 64 | 220 | The total | | | | | number of | | | | | packets of | | | | | this Flow with | | | | | TCP "Reset the | | | | | connection" | | | | | (RST) flag | | | | | set. | | tcpPshTotalCount | 64 | 221 | The total | | | | | number of | | | | | packets of | | | | | this Flow with | | | | | TCP "Push | | | | | Function" | | | | | (PSH) flag | | | | | set. | | tcpAckTotalCount | 64 | 222 | The total | | | | | number of | | | | | packets of | | | | | this Flow with | | | | | TCP "Acknowled | | | | | gment field | | | | | significant" | | | | | (ACK) flag | | | | | set. | | tcpUrgTotalCount | 64 | 223 | The total | | | | | number of | | | | | packets of | | | | | this Flow with | | | | | TCP "Urgent | | | | | Pointer field | | | | | significant" | | | | | (URG) flag | | | | | set. | | tcpControlBits | 8 | 6 | TCP control | | | | | bits observed | | | | | for packets of | | | | | this Flow | | flowEndReason | 8 | 136 | The reason for | | | | | Flow | | | | | termination | | minimumIpTotalLength | 64 | 25 | Length of the | | | | | smallest | | | | | packet | | | | | observed for | | | | | this Flow | | maximumIpTotalLength | 64 | 26 | Length of the | | | | | largest packet | Fu, et al. Expires October 30, 2015 [Page 6] Internet-Draft IPFIX IEs for network security April 2015 | | | | observed for | | | | | this Flow | | flowStartSeconds | dateTimeSeco | 150 | The absolute | | | nds | | timestamp of | | | | | the first | | | | | packet of this | | | | | Flow | | flowEndSeconds | dateTimeSeco | 151 | The absolute | | | nds | | timestamp of | | | | | the last | | | | | packet of this | | | | | Flow | | flowStartMilliseconds | dateTimeMill | 152 | The absolute | | | iseconds | | timestamp of | | | | | the first | | | | | packet of this | | | | | Flow | | flowEndMilliseconds | dateTimeMill | 153 | The absolute | | | iseconds | | timestamp of | | | | | the last | | | | | packet of this | | | | | Flow | | flowStartMicroseconds | dateTimeMicr | 154 | The absolute | | | oseconds | | timestamp of | | | | | the first | | | | | packet of this | | | | | Flow | | flowEndMicroseconds | dateTimeMicr | 155 | The absolute | | | oseconds | | timestamp of | | | | | the last | | | | | packet of this | | | | | Flow | | applicationErrorCodeCount | 32 | TBD | Number of | | | | | packets with | | | | | application | | | | | error code | | | | | detected | | fragmentFlags | 8 | 197 | Fragmentation | | | | | properties | | | | | indicated by | | | | | flags in the | | | | | IPv4 packet | | | | | header or the | | | | | IPv6 Fragment | | | | | header, | | | | | respectively | | fragmentIncompleteCount | 32 | TBD | Counter of | | | | | incomplete | Fu, et al. Expires October 30, 2015 [Page 7] Internet-Draft IPFIX IEs for network security April 2015 | | | | fragments | | fragmentFirstTooShortCoun | 32 | TBD | Number of | | t | | | packets with | | | | | first fragment | | | | | too short | | fragmentOffsettErrorCount | 32 | TBD | Number of | | | | | fragments with | | | | | offset error | | fragmentFlagErrorCount | 32 | TBD | Number of | | | | | fragments with | | | | | flag error | | icmpTypeIPv4 | 8 | 176 | Type of the | | | | | IPv4 ICMP | | | | | message | | icmpCodeIPv4 | 8 | 177 | Code of the | | | | | IPv4 ICMP | | | | | message | | icmpTypeIPv6 | 8 | 178 | Type of the | | | | | IPv6 ICMP | | | | | message | | icmpCodeIPv6 | 8 | 179 | Code of the | | | | | IPv6 ICMP | | | | | message | | icmpEchoCount | 32 | TBD | The number fo | | | | | ICMP echo. | | icmpEchoReplyCount | 32 | TBD | The number of | | | | | ICMP echo | | | | | reply. | | selectorAlgorithm | 16 | 304 | This | | | | | Information | | | | | Element | | | | | identifies the | | | | | packet | | | | | selection | | | | | methods (e.g., | | | | | Filtering, | | | | | Sampling) that | | | | | are applied by | | | | | the Selection | | | | | Process. | | samplingPacketInterval | 32 | 305 | The number of | | | | | packets that | | | | | are | | | | | consecutively | | | | | sampled | | samplingPacketSpace | 32 | 306 | The number of | | | | | packets | | | | | between two "s | Fu, et al. Expires October 30, 2015 [Page 8] Internet-Draft IPFIX IEs for network security April 2015 | | | | amplingPacketI | | | | | nterval"s. | +---------------------------+--------------+-------+----------------+ Table 1: Information Element table 3.2. Packet upstream/downstream counters A sudden increase of Flow from different sources to one destination may be caused by an attack on a specific host or network node using spoofed addresses. However it may be cased by legitimate users who seek access to a recently published web content. Only reporting the total packet number is not sufficient to indicate whether attacks occur, as it lacks details to separate good packets from abnormoal packets. as a result, upstream and downstream packets should be monitored seperately so that upstream to downstream packet number ratio can be use to detect successful connections. pktUpstreamCount and pktDownstreamCount are added to IPFIX to represent the cumulated upstream and downstream packet number respectively. 3.3. ICMP echo/echo reply counters An unusual ratio of ICMP echo to ICMP echo reply packets can refer to ICMP attack. However the existing set of IPFIX IEs provides the type and code of ICMP packet, countinuously export the information will result in serious resource consumption at the exporter, the collector and the bandwith. The number of echo and echo reply packets in a Flow can be derived for the Observation Domain in a specific time interval or once the ratio exceeds threshold. The basic metrics icmpEchoCount and icmpEchoReplyCount are defined as new IPFIX Information Elements. 3.4. Fragment statistic Typical fragment attack includes fragmentation buffer full, fragment overlapped, fragment incomplete. Existing IPFIX fragmentation metrics includes fragmentIdentification,fragmentOffset, fragmentFlags, which are not sufficient to identify errors, and are not suitable for early attack detection. Integrated measurements are needed to provide an holistic review of the flow. fragmentIncompleteCount checks the number of incomplete fragmentation ,fragmentFirstTooShortCount verifies the number of fragments with first fragment too short, fragmentOffsetErrorCount checks the number of fragments with offset error, and fragmentFlagErrorCount detect early whether the fragmentation is caused by a malicious attack. Fu, et al. Expires October 30, 2015 [Page 9] Internet-Draft IPFIX IEs for network security April 2015 3.5. Application error code The application layer attack requires IPFIX protocol capture packet payload. An initial consideration of the application error code comes from the HTTP status code except 2XX successful code. Other application layer protocol error code are also supported. The error code list can be expanded in the future as necessary. The data record will have the corresponding error code value to identify the error that is being logged. 3.6. Extended value of FlowEndReason There are 5 defined reasons for Flow termination, with values ranging from 0x01 to 0x05: 0x01: idle timeout 0x02: active timeout 0x03: end of Flow detected 0x04: forced end 0x05: lack of resources There is an additional reason caused by state machine anomaly. When FIN/SYN is sent, but no ACK is replied after a waiting timeout, the existing five reasons do not match this case.Therefore, a new value is proposed to extend the FlowEndReason, which is 0x06: protocol exception timeout. 4. Encoding 4.1. IPFIX This document uses IPFIX as the encoding mechanism to monitor security events. However, the information that is logged SHOULD be the same irrespective of what kind of encoding scheme is used. IPFIX is chosen, because it is an IETF standard that meets all the needs for a reliable logging mechanism and one of its targets are for security applications. IPFIX provides the flexibility to the logging device to define the data sets that it is logging. The IEs specified for logging MUST be the same irrespective of the encoding mechanism used. Fu, et al. Expires October 30, 2015 [Page 10] Internet-Draft IPFIX IEs for network security April 2015 5. IANA Considerations The following information elements are requested from IANA IPFIX registry. Name : pktUpstreamCount Description: The number of the upstream packets for this Flow at the Observation Point since the Metering Process (re-)initialization for this Observation Point. Abstract Data Type: unsigned64 Data Type Semantics: TBD Name: pktDownstreamCount Description: The number of the downstream packets for this Flow at the Observation Point since the Metering Process (re-)initialization for this Observation Point. Abstract Data Type: unsigned64 Data Type Semantics: TBD Name: octetUpstreamCount Description: The total number of octets in upstream packets for this Flow at the Observation Point since the Metering Process (re-)initialization for this Observation Point. The number of octets includes IP header(s) and IP payload. Abstract Data Type: unsigned64 Data Type Semantics: TBD Name : octetDownstreamCount Description: The total number of octets in downstream packets for this Flow at the Observation Point since the Metering Process (re-)initialization for this Observation Point. The number of octets includes IP header(s) and IP payload. Abstract Data Type: unsigned64 Data Type Semantics: TBD Name: applicationErrorCodeCount Fu, et al. Expires October 30, 2015 [Page 11] Internet-Draft IPFIX IEs for network security April 2015 Description: This Information Element identifies the number of packets with application layer error code detected. Abstract Data Type: unsigned32 Data Type Semantics: TBD Name: fragmentIncompleteCount Description: This Information Element is the counter of incomplete fragments. Abstract Data Type: unsigned32 Data Type Semantics: TBD Name: fragmentFirstTooShortCount Description: This Information Element indicates the number of packets with first fragment too shortt. Abstract Data Type: unsigned32 Data Type Semantics: TBD Name: fragmentOffsetErrorCount Description: This Information Element specifies number of fragments with offset error. Abstract Data Type: unsigned32 Data Type Semantics: TBD Name: fragmentFlagErrorCount Description: This Information Element specifies number of fragments with offset error.When the DF bit and MF bit of the fragment flag are set in the same fragment, there is an error at the fragment flag. Abstract Data Type: unsigned32 Data Type Semantics: TBD A new values is added to FlowEndReason: 0x06: protocol exception timeout Fu, et al. Expires October 30, 2015 [Page 12] Internet-Draft IPFIX IEs for network security April 2015 The flow was terminated due to protocol state machine anomaly and unexpected timeout. 6. Security Considerations No additional security considerations are introduced in this document. The same security considerations as for the IPFIX protocol [RFC7011] apply. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008. [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009. [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009. [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013. 7.2. Informative References [IPFIX-IANA] IANA, "IPFIX Information Elements registry", . Authors' Addresses Fu, et al. Expires October 30, 2015 [Page 13] Internet-Draft IPFIX IEs for network security April 2015 Tianfu Fu Huawei Q11, Huanbao Yuan, 156 Beiqing Road, Haidian District Beijing 100095 China Email: futianfu@huawei.com Dacheng Zhang Email: dacheng.zhang@gmail.com Danping He Huawei Q14, Huanbao Yuan, 156 Beiqing Road, Haidian District Beijing 100095 China Email: ana.hedanping@huawei.com Liang Xia (Frank) Huawei No.101, Software Avenue, Yuhuatai District Nanjing, Jiangsu 210012 China Email: frank.xialiang@huawei.com Fu, et al. Expires October 30, 2015 [Page 14]