Internet Engineering Task Force (IETF) T. Fu Internet-Draft C. Zhou Intended status: Informational H. Zheng Expires: January 4, 2018 Huawei July 03, 2017 IP Flow Information Export (IPFIX) Information Elements Extension for TCP Connection Tracking draft-fu-ipfix-tcp-tracking-00 Abstract This document proposes several new TCP connection related Information Elements (IEs) for the IP Flow Information Export (IPFIX) protocol. The new Information Elements can be used to export certain characteristics regarding a TCP connection. Through massive gathering of such characteristics, it can help build an image of the TCP traffic passing through a network. The image will facilitate the detection of anomaly TCP traffic, especially attacks targeting at TCP. 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 January 4, 2018. Copyright Notice Copyright (c) 2017 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 Fu, et al. Expires January 4, 2018 [Page 1] Internet-Draft IPFIX Extension for TCP Tracking July 2017 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. Conventions used in this document . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. New IEs and Connection Sampling . . . . . . . . . . . . . . . 3 3.1. Proposed New Information Elements . . . . . . . . . . . . 3 3.2. Use Cases for New IEs . . . . . . . . . . . . . . . . . . 4 3.2.1. Response Time Calculation of TCP Handshake . . . . . 4 3.2.2. Symptoms of Exceptions . . . . . . . . . . . . . . . 5 4. Application of the New IEs for Attack Detection . . . . . . . 6 4.1. Detect Slowloris Attack . . . . . . . . . . . . . . . . . 6 4.2. Detect Out-of-order Packets Attack . . . . . . . . . . . 6 4.3. TCP Connection Tracking Status Report . . . . . . . . . . 7 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Due to its stateful operations, TCP [RFC0793] is vulnerable to attacks. The SYN Flood attack is an example. It is sourced from a massive number of malicious clients starting TCP connections with a server, but never completing the three-way handshake process, leaving the server-side of the connections in waiting states, eventually exhausting the server resources and no new connection can be created. Attack aiming at TCP can also be low and slow in traffic pattern. These attacks may not take down the server, but just impair the provided service. Even though a victim server is still operating, its performance can be significantly degraded. Without the insight of what is going on with the TCP traffics, this kind of situation can be very hard to detect and analyze. For a network device, such as a router, to detect anomaly TCP traffics, it has to understand the semantics of TCP operations, more specifically, it has to be able to track TCP connection states. If a Fu, et al. Expires January 4, 2018 [Page 2] Internet-Draft IPFIX Extension for TCP Tracking July 2017 router has implemented such an ability, it can export characteristics information regarding the TCP connections. Offline analysis can be performed over the gathered information, which will facilitate the detection of anomaly TCP traffics and identify attacks. The IP Flow Information Export (IPFIX) protocol [RFC7011] already defines a generic mechanism for flow information export. This document introduces several new Information Elements of IPFIX, that can be used to export TCP connection characteristics. 2. Conventions used in this document 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]. 2.1. Terminology IPFIX-specific terminology (e.g. Information Element, Template, Template Record, Options Template Record, Template Set, Collector, Exporter, Data Record) 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. This document also makes use of the same terminology and definitions as Section 2 of [RFC5470]. o Victim: The target that suffers from DDoS attack. 3. New IEs and Connection Sampling 3.1. Proposed New Information Elements The proposed new Information Elements are listed in Figure 1 below. Fu, et al. Expires January 4, 2018 [Page 3] Internet-Draft IPFIX Extension for TCP Tracking July 2017 +---------------------------+------+ | Field Name | IANA | | | IPFIX| | | ID | +---------------------------+------+ |tcpHandshakeSyn2SynAckTime | TBD | |tcpHandshakeSynAck2AckTime | TBD | |tcpHandshakeSyn2AckRttTime | TBD | |tcpConnectionTrackingBits | TBD | |tcpPacketIntervalAverage | TBD | |tcpPacketIntervalVariance | TBD | |tcpOutOfOrderDeltaCount | TBD | +---------------------------+------+ Figure 1: New Information Elements The Information Elements defined in Figure 1 are proposed to be incorporated into the IANA IPFIX Information Elements registry [IPFIX-IANA] Their definitions can be found at Section 7. 3.2. Use Cases for New IEs Below are several use cases to identify the requirements where new IEs are desirable for the network attacks detection. 3.2.1. Response Time Calculation of TCP Handshake For the DDoS attacks such as http slowloris, there will be many TCP inactive, low traffic connections that are kept in the victim (server), which leads to excessive resource consumption. As a result, the response time between valid clients and the server for even the TCP handshake will increase greatly. The Challenge Collapasar(CC) attack can also exhaust the resources of the server and generate the similar results. In summary, too much resource consumption in the victim will increase the response time of TCP handshake, which is a general network anomaly condition. The following IEs are proposed to report symptoms of these kinds of attacks: tcpHandshakeSyn2SynAckTime: Denotes the time difference between the time point that the Metering Process detects the SYN packet from client to server and the time point that the Metering Process then detects the SYN-ACK packet from server to client. tcpHandshakeSynAck2AckTime: Denotes the time difference between the time point that the Metering Process detects the SYN-ACK packet from server to client and the time point that the Metering Process then detects the ACK packet from client to server. Fu, et al. Expires January 4, 2018 [Page 4] Internet-Draft IPFIX Extension for TCP Tracking July 2017 tcpHandshakeSyn2AckRttTime: Denotes the sum of tcpHandshakeSyn2SynAckTime and tcpHandshakeSynAck2AckTime. It is the Round Trip Time (RTT) of a TCP handshake between client and server. 3.2.2. Symptoms of Exceptions Slow packet attacks at the application layer, such as http slowloris attack, slow http post attack, or slow read attack, the malicious clients may send packets to the victim periodically at a very low rate which causes the performance lost on the server. The characteristic of this kind of attack is that there are too many connections on the victim, while the traffic volume for these connections is small. In order to detect this attack, two new IEs, tcpPacketIntervalAverage and tcpPacketIntervalVariance are helpful. The IE tcpPacketIntervalAverage denotes the average time difference between two successive packets and the IE tcpPacketIntervalVariance denotes the variance of multiple time difference. Large tcpPacketIntervalAverage and small tcpPacketIntervalVariance can be a symptom of slow packet attack, since the attacker sends packets in large intervals just as to keep the connection open, and the intervals tend to differ very little in time. The malicious clients may send too many out-of-order packets, which will consume too much memory on the server, thus degrading performance. Although out-of-order packets are permit in the TCP protocol, it is possible to be leveraged to cause these attacks. The IE tcpOutOfOrderDeltaCount is helpful to detect this kind of exception. The Metering Process maintains one counter for each TCP connection. The initial sequence number of the client is saved in the counter. The counter increases by the sequence number of the packets it sees from client to server. If the Metering Process sees a packet with a lower sequence number than the current counter value, then the packet will be considered as an out-of-order packet. In IPFIX, the IE tcpControlBits is used to record the corresponding status bits in TCP header of the packets. In order to detect the application layer attacks which can cause the protocol exception such as the wrong use of the TCP status bits during the TCP connection establishment, another IE called tcpConnectionTrackingBits is needed. For example, when the Metering Process sees the SYN packet from client to server, it sets 15th bit of tcpConnectionTrackingBits to 1; when it sees the SYN-ACK packet from server to client, it sets 14th bit to 1, and so on. If one endpoint sends the packet with wrong bits during the establishment of the connection, then the Metering Process will identify the exception by the value of tcpConnectionTrackingBits. Fu, et al. Expires January 4, 2018 [Page 5] Internet-Draft IPFIX Extension for TCP Tracking July 2017 4. Application of the New IEs for Attack Detection This section presents a number of examples to help understand the application of these new IEs for attack detection. 4.1. Detect Slowloris Attack The template for detecting resource exhausting application layer attack such as http slowloris attack should contain a subset of IEs shown in Figure 2. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 48 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID TBD | Field Count = 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| sourceIPv4Address | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| destinationIPv4Address | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| protocolIdentifier | Field Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| tcpHandshakeSyn2SynAckTime | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| tcpHandshakeSynAck2AckTime | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| tcpHandshakeSyn2SynAckTime | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| tcpPacketIntervalAverage | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| tcpPacketIntervalVariance | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Template Example for Detecting Slowloris Attack An example of the actual record is shown below in a readable form: {sourceIPv4Address = 192.168.0.101, destinationIPv4Address = 192.168.0.201, protocolIdentifier = 6, tcpHandshakeSyn2SynAckTime = 1, tcpHandshakeSynAck2AckTime = 3, tcpHandshakeSyn2AckRttTime = 4, tcpPacketIntervalAverage = 5635, tcpPacketIntervalVariance = 38216} 4.2. Detect Out-of-order Packets Attack The template for detecting out-of-order packets attack should contain IEs shown in Figure 3. Fu, et al. Expires January 4, 2018 [Page 6] Internet-Draft IPFIX Extension for TCP Tracking July 2017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 32 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID TBD | Field Count = 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| sourceIPv4Address | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| destinationIPv4Address | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| protocolIdentifier | Field Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| packetDeltaCount | Field Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| tcpOutOfOrderDeltaCount | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Template Example for Detecting Out-of-order Attack An example of the actual record is shown below in a readable form as below: {sourceIPv4Address = 192.168.0.101, destinationIPv4Address = 192.168.0.201, protocolIdentifier = 6, packetDeltaCount =3000, tcpOutOfOrderDeltaCount = 2000} 4.3. TCP Connection Tracking Status Report +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 32 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID TBD | Field Count = 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| sourceIPv4Address | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| destinationIPv4Address | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| protocolIdentifier | Field Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| tcpConnectionTrackingBits | Field Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Template Example for TCP Connection Tracking The following text lists several examples. For a TCP connection that ends normally, the bit pattern is: Fu, et al. Expires January 4, 2018 [Page 7] Internet-Draft IPFIX Extension for TCP Tracking July 2017 Bit 15 (SYN) = 1 Bit 14 (S/A) = 1 Bit 13 (ACK) = 1 Bit 12 (FIN) = 1 Bit 11 (ACK) = 1 Bit 10 (F/A) = 1 Bit 09 (ACK) = 1 Bit 08 (RST) = 0 Bit 07 (TMR) = 0 Bit 06 (END) = 1 Bit 05,04 (END REASON) = 00 Bit 03 (ROP) = 0 Bit 02 (ROD) = 0 Bit 01 (ERR) = 0 Bit 00 (VLD) = 1 tcpConnectionTrackingBits = 0b1111111001000001 = 65089 the actual record is shown in a readable form as below: {sourceIPv4Address = 192.168.0.101, destinationIPv4Address = 192.168.0.201, protocolIdentifier = 6, tcpConnectionTrackingBits = 65089 } Another example is an abnormal case, that RST is received after SYN, the bit pattern is: Bit 15 (SYN) = 1 Bit 14 (S/A) = 0 Bit 13 (ACK) = 0 Bit 12 (FIN) = 0 Bit 11 (ACK) = 0 Bit 10 (F/A) = 0 Bit 09 (ACK) = 0 Bit 08 (RST) = 1 Bit 07 (TMR) = 0 Bit 06 (END) = 0 Bit 05,04 (END REASON) = 01 Bit 03 (ROP) = 0 Bit 02 (ROD) = 0 Bit 01 (ERR) = 0 Bit 00 (VLD) = 0 tcpConnectionTrackingBits = 0b1000000100010000 = 33040 the actual record is shown in a readable form as below: Fu, et al. Expires January 4, 2018 [Page 8] Internet-Draft IPFIX Extension for TCP Tracking July 2017 {sourceIPv4Address = 192.168.0.101, destinationIPv4Address = 192.168.0.201, protocolIdentifier = 6, tcpConnectionTrackingBits = 33040 } 5. Summary This document proposes several new TCP connection related IEs of the IPFIX protocol, which can be used to export certain characteristics regarding a TCP connection. Through gathering of such characteristics, an image can be built (normal baseline or anomaly) of the TCP traffics passing through a network. The image will facilitate the detection of the attacks targeting at TCP connections. 6. Security Considerations This document proposes several new TCP connection related IPFIX IEs and their use in the detection of some kinds of TCP connection related attack. Comparing to IPFIX basic protocol [RFC7011] there is no new security threats brought by the new proposed IEs, as long as all the security considerations and mechanisms presented in [RFC7011] are followed. The new proposed IEs and solutions do not cover all the existing TCP connection related attacks, let along those new attacks that will appear in future. DDoS attack and their detection is an 'arms race', useful telemetry information is always needed to protect the network resources better. 7. IANA Considerations The following information elements are requested from IANA IPFIX registry. Upon acceptation, the 'TBD' values of the ElementIds should be replaced by IANA for assigned numbers. Name: tcpHandshakeSyn2SynAckTime Description: The time difference between a SYN and its corresponding SYN-ACK when the Metering Process detects a new TCP connection is going to be set up. Abstract Data Type: dateTimeMicroseconds ElementId: TBD Status: current Units: microseconds Name: tcpHandshakeSynAck2AckTime Description: The time difference between a SYN-ACK and its corresponding ACK Fu, et al. Expires January 4, 2018 [Page 9] Internet-Draft IPFIX Extension for TCP Tracking July 2017 when the Metering Process observes a new TCP connection is going to be set up. Abstract Data Type: dateTimeMicroseconds ElementId: TBD Status: current Units: microseconds Name: tcpHandshakeSyn2AckRttTime Description: The time difference between a SYN and its corresponding ACK sent from the same endpoint when the Metering Process observes a new TCP connection is going to be set up. Conceptually tcpHandshakeSyn2AckRttTime can be thought as the sum of tcpHandshakeSyn2SynAckTime and tcpHandshakeSynAck2AckTime, but practically the values may differ. Abstract Data Type: dateTimeMicroseconds ElementId: TBD Status: current Units: microseconds Name: tcpConnectionTrackingBits Description: These bits are used by the Metering Process to track a TCP connection. A bit is set to 1 if the corresponding condition is met. A value of 0 for a bit indicates the corresponding condition is not met. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1|1|1|1|1|0|0|0|0|0|0|0|0|0|0| |5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|S|A|F|A|F|A|R|T|E|END|R|R|E|V| |Y|/|C|I|C|/|C|S|M|N|REA|O|O|R|L| |N|A|K|N|K|A|K|T|R|D|SON|P|D|R|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bit 15 (SYN): Set when there is no TCP connection between the endpoints and the Metering Process detects a SYN as it is used to setup a new TCP connection. The Metering Process starts to track the TCP connection. Bit 14 (S/A): Set when bit 15 has been set and the Metering Process detects a SYN-ACK in the flow, which effectively acknowledges the SYN (Ack = Seq + 1) causing bit 15 to be Fu, et al. Expires January 4, 2018 [Page 10] Internet-Draft IPFIX Extension for TCP Tracking July 2017 set. Bit 13 (ACK): Set when bit 15 and bit 14 have been set and the Metering Process detects an ACK which effectively acknowledges the SYN-ACK (Ack = Seq + 1) causing bit 14 to be set. Upon setting this bit, it means handshake of the TCP connection setup has completed. Bit 12 (FIN): Set when the Metering Process detects the first FIN for the established and tracked TCP connection. It means the TCP connection is going to be closed. Bit 11 (ACK): Set when bit 12 has been set and the Metering Process detects an ACK which effectively acknowledges the FIN causing bit 12 to be set. Bit 10 (F/A): Set when bit 12 has been set and the Metering Process detects a FIN that is from the opposite of the endpoint which sent the FIN causing bit 12 to be set. Bit 09 (ACK): Set when bit 10 has been set and the Metering Process detects an ACK that is from the same endpoint which sent the FIN causing bit 10 to be set. Bit 08 (RST): Set when the Metering Process detects any RST from either party of the tracked TCP connection. Setting this bit indicates that TCP connection is abnormal and aborted. Bit 07 (TMR): Set when a flow record report is triggered by a periodic reporting timer. It means the TCP connection is still under tracking. Bit 06 (END): Set when the Metering Process has stopped tracking the TCP connection, as the connection has been closed or aborted. Bit 05 & Bit 04 (END REASON): 00: as default value when the TCP connection is not closed, or the tracked TCP connection is closed normally. 01: the tracked TCP connection is aborted. 10: the tracked TCP connection is inactive after a period of time. 11: reserved. Bit 03 (ROP): Set when the Metering Process detects any SYN or SYNACK, after the both endpoints have sent FIN or an RST has been detected. Bit 02 (ROD): Set when the Metering Process detects at least 50 TCP segments being exchanged, after both endpoints have sent FIN Fu, et al. Expires January 4, 2018 [Page 11] Internet-Draft IPFIX Extension for TCP Tracking July 2017 or an RST has been detected. Bit 01 (ERR): Set when the Metering Process detects any of the following abnormal signaling sequences for the TCP connection: SYN/FIN, SYN/FIN/PSH, SYN/FIN/RST, SYN/FIN/RST/PSH. Bit 00 (VLD): When the END bit is set, setting this bit indicates the tracked TCP connection is closed normally. Otherwise, indicates the tracked TCP connection is aborted. Abstract Data Type: unsigned16 Data Type Semantics: flags ElementId: TBD Status: current Name: tcpPacketIntervalAverage Description: The average time interval calculated by the Metering Process between two successive packets in the data flow of a TCP connection. Abstract Data Type: dateTimeMilliseconds ElementId: TBD Status: current Name: tcpPacketIntervalVariance Description: The variance of the time intervals calculated by the Metering Process between two successive packets in the data flow of a TCP connection. Abstract Data Type: unsigned64 ElementId: TBD Status: current Name: tcpOutOfOrderDeltaCount Description: The number of out of order packets in the data flow of a TCP connection detected at the Observation Point since the previous report. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: TBD Status: current Fu, et al. Expires January 4, 2018 [Page 12] Internet-Draft IPFIX Extension for TCP Tracking July 2017 8. Acknowledgments The authors would like to acknowledge the following people, for their contributions on this text: DaCheng Zhang, Bo Zhang (Alex), Min Li, Robert Moskowitz. 9. References 9.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, . [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, DOI 10.17487/RFC5470, March 2009, . [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, . 9.2. Informative References [IPFIX-IANA] IANA, "IPFIX Information Elements Registry", July 2017, . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . Authors' Addresses Tianfu Fu Huawei Q11, Huanbao Yuan, 156 Beiqing Road, Haidian District Beijing 100095 China Email: futianfu@huawei.com Fu, et al. Expires January 4, 2018 [Page 13] Internet-Draft IPFIX Extension for TCP Tracking July 2017 Chong Zhou Huawei 156 Beiqing Road M06 Shichuang Technology Demonstration Park Haidian District Beijing 100094 China Email: mr.zhouchong@huawei.com Hui Zheng (Marvin) Huawei 101 Ruanjian Avenue, Yuhuatai District Nanjing 210012 China Email: marvin.zhenghui@huawei.com Fu, et al. Expires January 4, 2018 [Page 14]