idnits 2.17.1 draft-fu-ipfix-tcp-tracking-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 : ---------------------------------------------------------------------------- == There are 8 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 03, 2017) is 2488 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force (IETF) T. Fu 3 Internet-Draft C. Zhou 4 Intended status: Informational H. Zheng 5 Expires: January 4, 2018 Huawei 6 July 03, 2017 8 IP Flow Information Export (IPFIX) Information Elements Extension for 9 TCP Connection Tracking 10 draft-fu-ipfix-tcp-tracking-00 12 Abstract 14 This document proposes several new TCP connection related Information 15 Elements (IEs) for the IP Flow Information Export (IPFIX) protocol. 16 The new Information Elements can be used to export certain 17 characteristics regarding a TCP connection. Through massive 18 gathering of such characteristics, it can help build an image of the 19 TCP traffic passing through a network. The image will facilitate the 20 detection of anomaly TCP traffic, especially attacks targeting at 21 TCP. 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 January 4, 2018. 40 Copyright Notice 42 Copyright (c) 2017 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. Conventions used in this document . . . . . . . . . . . . . . 3 59 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. New IEs and Connection Sampling . . . . . . . . . . . . . . . 3 61 3.1. Proposed New Information Elements . . . . . . . . . . . . 3 62 3.2. Use Cases for New IEs . . . . . . . . . . . . . . . . . . 4 63 3.2.1. Response Time Calculation of TCP Handshake . . . . . 4 64 3.2.2. Symptoms of Exceptions . . . . . . . . . . . . . . . 5 65 4. Application of the New IEs for Attack Detection . . . . . . . 6 66 4.1. Detect Slowloris Attack . . . . . . . . . . . . . . . . . 6 67 4.2. Detect Out-of-order Packets Attack . . . . . . . . . . . 6 68 4.3. TCP Connection Tracking Status Report . . . . . . . . . . 7 69 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 75 9.2. Informative References . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 Due to its stateful operations, TCP [RFC0793] is vulnerable to 81 attacks. The SYN Flood attack is an example. It is sourced from a 82 massive number of malicious clients starting TCP connections with a 83 server, but never completing the three-way handshake process, leaving 84 the server-side of the connections in waiting states, eventually 85 exhausting the server resources and no new connection can be created. 87 Attack aiming at TCP can also be low and slow in traffic pattern. 88 These attacks may not take down the server, but just impair the 89 provided service. Even though a victim server is still operating, 90 its performance can be significantly degraded. Without the insight 91 of what is going on with the TCP traffics, this kind of situation can 92 be very hard to detect and analyze. 94 For a network device, such as a router, to detect anomaly TCP 95 traffics, it has to understand the semantics of TCP operations, more 96 specifically, it has to be able to track TCP connection states. If a 97 router has implemented such an ability, it can export characteristics 98 information regarding the TCP connections. Offline analysis can be 99 performed over the gathered information, which will facilitate the 100 detection of anomaly TCP traffics and identify attacks. 102 The IP Flow Information Export (IPFIX) protocol [RFC7011] already 103 defines a generic mechanism for flow information export. This 104 document introduces several new Information Elements of IPFIX, that 105 can be used to export TCP connection characteristics. 107 2. Conventions used in this document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC-2119 [RFC2119]. 113 2.1. Terminology 115 IPFIX-specific terminology (e.g. Information Element, Template, 116 Template Record, Options Template Record, Template Set, Collector, 117 Exporter, Data Record) used in this document is defined in Section 2 118 of [RFC7011]. As in [RFC7011] these IPFIX-specific terms have the 119 first letter of a word capitalized. 121 This document also makes use of the same terminology and definitions 122 as Section 2 of [RFC5470]. 124 o Victim: The target that suffers from DDoS attack. 126 3. New IEs and Connection Sampling 128 3.1. Proposed New Information Elements 130 The proposed new Information Elements are listed in Figure 1 below. 132 +---------------------------+------+ 133 | Field Name | IANA | 134 | | IPFIX| 135 | | ID | 136 +---------------------------+------+ 137 |tcpHandshakeSyn2SynAckTime | TBD | 138 |tcpHandshakeSynAck2AckTime | TBD | 139 |tcpHandshakeSyn2AckRttTime | TBD | 140 |tcpConnectionTrackingBits | TBD | 141 |tcpPacketIntervalAverage | TBD | 142 |tcpPacketIntervalVariance | TBD | 143 |tcpOutOfOrderDeltaCount | TBD | 144 +---------------------------+------+ 146 Figure 1: New Information Elements 148 The Information Elements defined in Figure 1 are proposed to be 149 incorporated into the IANA IPFIX Information Elements registry 150 [IPFIX-IANA] Their definitions can be found at Section 7. 152 3.2. Use Cases for New IEs 154 Below are several use cases to identify the requirements where new 155 IEs are desirable for the network attacks detection. 157 3.2.1. Response Time Calculation of TCP Handshake 159 For the DDoS attacks such as http slowloris, there will be many TCP 160 inactive, low traffic connections that are kept in the victim 161 (server), which leads to excessive resource consumption. As a 162 result, the response time between valid clients and the server for 163 even the TCP handshake will increase greatly. The Challenge 164 Collapasar(CC) attack can also exhaust the resources of the server 165 and generate the similar results. In summary, too much resource 166 consumption in the victim will increase the response time of TCP 167 handshake, which is a general network anomaly condition. The 168 following IEs are proposed to report symptoms of these kinds of 169 attacks: 171 tcpHandshakeSyn2SynAckTime: Denotes the time difference between the 172 time point that the Metering Process detects the SYN packet from 173 client to server and the time point that the Metering Process then 174 detects the SYN-ACK packet from server to client. 176 tcpHandshakeSynAck2AckTime: Denotes the time difference between the 177 time point that the Metering Process detects the SYN-ACK packet 178 from server to client and the time point that the Metering Process 179 then detects the ACK packet from client to server. 181 tcpHandshakeSyn2AckRttTime: Denotes the sum of 182 tcpHandshakeSyn2SynAckTime and tcpHandshakeSynAck2AckTime. It is 183 the Round Trip Time (RTT) of a TCP handshake between client and 184 server. 186 3.2.2. Symptoms of Exceptions 188 Slow packet attacks at the application layer, such as http slowloris 189 attack, slow http post attack, or slow read attack, the malicious 190 clients may send packets to the victim periodically at a very low 191 rate which causes the performance lost on the server. The 192 characteristic of this kind of attack is that there are too many 193 connections on the victim, while the traffic volume for these 194 connections is small. In order to detect this attack, two new IEs, 195 tcpPacketIntervalAverage and tcpPacketIntervalVariance are helpful. 196 The IE tcpPacketIntervalAverage denotes the average time difference 197 between two successive packets and the IE tcpPacketIntervalVariance 198 denotes the variance of multiple time difference. Large 199 tcpPacketIntervalAverage and small tcpPacketIntervalVariance can be a 200 symptom of slow packet attack, since the attacker sends packets in 201 large intervals just as to keep the connection open, and the 202 intervals tend to differ very little in time. 204 The malicious clients may send too many out-of-order packets, which 205 will consume too much memory on the server, thus degrading 206 performance. Although out-of-order packets are permit in the TCP 207 protocol, it is possible to be leveraged to cause these attacks. The 208 IE tcpOutOfOrderDeltaCount is helpful to detect this kind of 209 exception. The Metering Process maintains one counter for each TCP 210 connection. The initial sequence number of the client is saved in 211 the counter. The counter increases by the sequence number of the 212 packets it sees from client to server. If the Metering Process sees 213 a packet with a lower sequence number than the current counter value, 214 then the packet will be considered as an out-of-order packet. 216 In IPFIX, the IE tcpControlBits is used to record the corresponding 217 status bits in TCP header of the packets. In order to detect the 218 application layer attacks which can cause the protocol exception such 219 as the wrong use of the TCP status bits during the TCP connection 220 establishment, another IE called tcpConnectionTrackingBits is needed. 221 For example, when the Metering Process sees the SYN packet from 222 client to server, it sets 15th bit of tcpConnectionTrackingBits to 1; 223 when it sees the SYN-ACK packet from server to client, it sets 14th 224 bit to 1, and so on. If one endpoint sends the packet with wrong 225 bits during the establishment of the connection, then the Metering 226 Process will identify the exception by the value of 227 tcpConnectionTrackingBits. 229 4. Application of the New IEs for Attack Detection 231 This section presents a number of examples to help understand the 232 application of these new IEs for attack detection. 234 4.1. Detect Slowloris Attack 236 The template for detecting resource exhausting application layer 237 attack such as http slowloris attack should contain a subset of IEs 238 shown in Figure 2. 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Set ID = 2 | Length = 48 octets | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Template ID TBD | Field Count = 10 | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 |0| sourceIPv4Address | Field Length = 4 | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 |0| destinationIPv4Address | Field Length = 4 | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 |0| protocolIdentifier | Field Length = 1 | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 |0| tcpHandshakeSyn2SynAckTime | Field Length = 2 | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 |0| tcpHandshakeSynAck2AckTime | Field Length = 2 | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 |0| tcpHandshakeSyn2SynAckTime | Field Length = 2 | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 |0| tcpPacketIntervalAverage | Field Length = 4 | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 |0| tcpPacketIntervalVariance | Field Length = 4 | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Figure 2: Template Example for Detecting Slowloris Attack 264 An example of the actual record is shown below in a readable form: 266 {sourceIPv4Address = 192.168.0.101, destinationIPv4Address = 267 192.168.0.201, protocolIdentifier = 6, tcpHandshakeSyn2SynAckTime = 268 1, tcpHandshakeSynAck2AckTime = 3, tcpHandshakeSyn2AckRttTime = 269 4, tcpPacketIntervalAverage = 5635, tcpPacketIntervalVariance = 270 38216} 272 4.2. Detect Out-of-order Packets Attack 274 The template for detecting out-of-order packets attack should contain 275 IEs shown in Figure 3. 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Set ID = 2 | Length = 32 octets | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Template ID TBD | Field Count = 10 | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 |0| sourceIPv4Address | Field Length = 4 | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 |0| destinationIPv4Address | Field Length = 4 | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 |0| protocolIdentifier | Field Length = 1 | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 |0| packetDeltaCount | Field Length = 8 | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 |0| tcpOutOfOrderDeltaCount | Field Length = 4 | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Figure 3: Template Example for Detecting Out-of-order Attack 295 An example of the actual record is shown below in a readable form as 296 below: 298 {sourceIPv4Address = 192.168.0.101, destinationIPv4Address = 299 192.168.0.201, protocolIdentifier = 6, packetDeltaCount =3000, 300 tcpOutOfOrderDeltaCount = 2000} 302 4.3. TCP Connection Tracking Status Report 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Set ID = 2 | Length = 32 octets | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Template ID TBD | Field Count = 10 | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 |0| sourceIPv4Address | Field Length = 4 | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 |0| destinationIPv4Address | Field Length = 4 | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 |0| protocolIdentifier | Field Length = 1 | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |0| tcpConnectionTrackingBits | Field Length = 8 | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Figure 4: Template Example for TCP Connection Tracking 320 The following text lists several examples. For a TCP connection that 321 ends normally, the bit pattern is: 323 Bit 15 (SYN) = 1 324 Bit 14 (S/A) = 1 325 Bit 13 (ACK) = 1 326 Bit 12 (FIN) = 1 327 Bit 11 (ACK) = 1 328 Bit 10 (F/A) = 1 329 Bit 09 (ACK) = 1 330 Bit 08 (RST) = 0 331 Bit 07 (TMR) = 0 332 Bit 06 (END) = 1 333 Bit 05,04 (END REASON) = 00 334 Bit 03 (ROP) = 0 335 Bit 02 (ROD) = 0 336 Bit 01 (ERR) = 0 337 Bit 00 (VLD) = 1 339 tcpConnectionTrackingBits = 0b1111111001000001 = 65089 341 the actual record is shown in a readable form as below: 343 {sourceIPv4Address = 192.168.0.101, destinationIPv4Address = 344 192.168.0.201, protocolIdentifier = 6, 345 tcpConnectionTrackingBits = 65089 } 347 Another example is an abnormal case, that RST is received after SYN, 348 the bit pattern is: 350 Bit 15 (SYN) = 1 351 Bit 14 (S/A) = 0 352 Bit 13 (ACK) = 0 353 Bit 12 (FIN) = 0 354 Bit 11 (ACK) = 0 355 Bit 10 (F/A) = 0 356 Bit 09 (ACK) = 0 357 Bit 08 (RST) = 1 358 Bit 07 (TMR) = 0 359 Bit 06 (END) = 0 360 Bit 05,04 (END REASON) = 01 361 Bit 03 (ROP) = 0 362 Bit 02 (ROD) = 0 363 Bit 01 (ERR) = 0 364 Bit 00 (VLD) = 0 366 tcpConnectionTrackingBits = 0b1000000100010000 = 33040 368 the actual record is shown in a readable form as below: 370 {sourceIPv4Address = 192.168.0.101, destinationIPv4Address = 371 192.168.0.201, protocolIdentifier = 6, 372 tcpConnectionTrackingBits = 33040 } 374 5. Summary 376 This document proposes several new TCP connection related IEs of the 377 IPFIX protocol, which can be used to export certain characteristics 378 regarding a TCP connection. Through gathering of such 379 characteristics, an image can be built (normal baseline or anomaly) 380 of the TCP traffics passing through a network. The image will 381 facilitate the detection of the attacks targeting at TCP connections. 383 6. Security Considerations 385 This document proposes several new TCP connection related IPFIX IEs 386 and their use in the detection of some kinds of TCP connection 387 related attack. Comparing to IPFIX basic protocol [RFC7011] there is 388 no new security threats brought by the new proposed IEs, as long as 389 all the security considerations and mechanisms presented in [RFC7011] 390 are followed. 392 The new proposed IEs and solutions do not cover all the existing TCP 393 connection related attacks, let along those new attacks that will 394 appear in future. DDoS attack and their detection is an 'arms race', 395 useful telemetry information is always needed to protect the network 396 resources better. 398 7. IANA Considerations 400 The following information elements are requested from IANA IPFIX 401 registry. Upon acceptation, the 'TBD' values of the ElementIds 402 should be replaced by IANA for assigned numbers. 404 Name: tcpHandshakeSyn2SynAckTime 405 Description: 406 The time difference between a SYN and its corresponding SYN-ACK 407 when the Metering Process detects a new TCP connection is 408 going to be set up. 409 Abstract Data Type: dateTimeMicroseconds 410 ElementId: TBD 411 Status: current 412 Units: microseconds 414 Name: tcpHandshakeSynAck2AckTime 415 Description: 416 The time difference between a SYN-ACK and its corresponding ACK 417 when the Metering Process observes a new TCP connection is 418 going to be set up. 419 Abstract Data Type: dateTimeMicroseconds 420 ElementId: TBD 421 Status: current 422 Units: microseconds 424 Name: tcpHandshakeSyn2AckRttTime 425 Description: 426 The time difference between a SYN and its corresponding ACK 427 sent from the same endpoint when the Metering Process observes 428 a new TCP connection is going to be set up. 430 Conceptually tcpHandshakeSyn2AckRttTime can be thought as the 431 sum of tcpHandshakeSyn2SynAckTime and 432 tcpHandshakeSynAck2AckTime, but practically the values may 433 differ. 434 Abstract Data Type: dateTimeMicroseconds 435 ElementId: TBD 436 Status: current 437 Units: microseconds 439 Name: tcpConnectionTrackingBits 440 Description: 441 These bits are used by the Metering Process to track a TCP 442 connection. A bit is set to 1 if the corresponding condition 443 is met. A value of 0 for a bit indicates the corresponding 444 condition is not met. 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 |1|1|1|1|1|1|0|0|0|0|0|0|0|0|0|0| 448 |5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0| 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 |S|S|A|F|A|F|A|R|T|E|END|R|R|E|V| 451 |Y|/|C|I|C|/|C|S|M|N|REA|O|O|R|L| 452 |N|A|K|N|K|A|K|T|R|D|SON|P|D|R|D| 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Bit 15 (SYN): 456 Set when there is no TCP connection between the endpoints 457 and the Metering Process detects a SYN as it is used to 458 setup a new TCP connection. The Metering Process starts to 459 track the TCP connection. 460 Bit 14 (S/A): 461 Set when bit 15 has been set and the Metering Process 462 detects a SYN-ACK in the flow, which effectively 463 acknowledges the SYN (Ack = Seq + 1) causing bit 15 to be 464 set. 465 Bit 13 (ACK): 466 Set when bit 15 and bit 14 have been set and the Metering 467 Process detects an ACK which effectively acknowledges the 468 SYN-ACK (Ack = Seq + 1) causing bit 14 to be set. Upon 469 setting this bit, it means handshake of the TCP connection 470 setup has completed. 471 Bit 12 (FIN): 472 Set when the Metering Process detects the first FIN for the 473 established and tracked TCP connection. It means the TCP 474 connection is going to be closed. 475 Bit 11 (ACK): 476 Set when bit 12 has been set and the Metering Process 477 detects an ACK which effectively acknowledges the FIN 478 causing bit 12 to be set. 479 Bit 10 (F/A): 480 Set when bit 12 has been set and the Metering Process 481 detects a FIN that is from the opposite of the endpoint 482 which sent the FIN causing bit 12 to be set. 483 Bit 09 (ACK): 484 Set when bit 10 has been set and the Metering Process 485 detects an ACK that is from the same endpoint which sent the 486 FIN causing bit 10 to be set. 487 Bit 08 (RST): 488 Set when the Metering Process detects any RST from either 489 party of the tracked TCP connection. Setting this bit 490 indicates that TCP connection is abnormal and aborted. 491 Bit 07 (TMR): 492 Set when a flow record report is triggered by a periodic 493 reporting timer. It means the TCP connection is still under 494 tracking. 495 Bit 06 (END): 496 Set when the Metering Process has stopped tracking the TCP 497 connection, as the connection has been closed or aborted. 498 Bit 05 & Bit 04 (END REASON): 499 00: as default value when the TCP connection is not closed, 500 or the tracked TCP connection is closed normally. 501 01: the tracked TCP connection is aborted. 502 10: the tracked TCP connection is inactive after a period 503 of time. 504 11: reserved. 505 Bit 03 (ROP): 506 Set when the Metering Process detects any SYN or SYNACK, 507 after the both endpoints have sent FIN or an RST has been 508 detected. 509 Bit 02 (ROD): 510 Set when the Metering Process detects at least 50 TCP 511 segments being exchanged, after both endpoints have sent FIN 512 or an RST has been detected. 513 Bit 01 (ERR): 514 Set when the Metering Process detects any of the following 515 abnormal signaling sequences for the TCP connection: 516 SYN/FIN, SYN/FIN/PSH, SYN/FIN/RST, SYN/FIN/RST/PSH. 517 Bit 00 (VLD): 518 When the END bit is set, setting this bit indicates the 519 tracked TCP connection is closed normally. Otherwise, 520 indicates the tracked TCP connection is aborted. 522 Abstract Data Type: unsigned16 523 Data Type Semantics: flags 524 ElementId: TBD 525 Status: current 527 Name: tcpPacketIntervalAverage 528 Description: 529 The average time interval calculated by the Metering Process 530 between two successive packets in the data flow of a TCP 531 connection. 532 Abstract Data Type: dateTimeMilliseconds 533 ElementId: TBD 534 Status: current 536 Name: tcpPacketIntervalVariance 537 Description: 538 The variance of the time intervals calculated by the Metering 539 Process between two successive packets in the data flow of a 540 TCP connection. 541 Abstract Data Type: unsigned64 542 ElementId: TBD 543 Status: current 545 Name: tcpOutOfOrderDeltaCount 546 Description: 547 The number of out of order packets in the data flow of a TCP 548 connection detected at the Observation Point since the previous 549 report. 550 Abstract Data Type: unsigned64 551 Data Type Semantics: deltaCounter 552 ElementId: TBD 553 Status: current 555 8. Acknowledgments 557 The authors would like to acknowledge the following people, for their 558 contributions on this text: DaCheng Zhang, Bo Zhang (Alex), Min Li, 559 Robert Moskowitz. 561 9. References 563 9.1. Normative References 565 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 566 Requirement Levels", BCP 14, RFC 2119, 567 DOI 10.17487/RFC2119, March 1997, 568 . 570 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 571 "Architecture for IP Flow Information Export", RFC 5470, 572 DOI 10.17487/RFC5470, March 2009, 573 . 575 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 576 "Specification of the IP Flow Information Export (IPFIX) 577 Protocol for the Exchange of Flow Information", STD 77, 578 RFC 7011, DOI 10.17487/RFC7011, September 2013, 579 . 581 9.2. Informative References 583 [IPFIX-IANA] 584 IANA, "IPFIX Information Elements Registry", July 2017, 585 . 587 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 588 RFC 793, DOI 10.17487/RFC0793, September 1981, 589 . 591 Authors' Addresses 593 Tianfu Fu 594 Huawei 595 Q11, Huanbao Yuan, 156 Beiqing Road, Haidian District 596 Beijing 100095 597 China 599 Email: futianfu@huawei.com 600 Chong Zhou 601 Huawei 602 156 Beiqing Road 603 M06 Shichuang Technology Demonstration Park 604 Haidian District 605 Beijing 100094 606 China 608 Email: mr.zhouchong@huawei.com 610 Hui Zheng (Marvin) 611 Huawei 612 101 Ruanjian Avenue, Yuhuatai District 613 Nanjing 210012 614 China 616 Email: marvin.zhenghui@huawei.com