idnits 2.17.1 draft-fu-dots-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 4 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 has text resembling RFC 2119 boilerplate text. -- The document date (March 13, 2017) is 2601 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5474' is defined on line 492, but no explicit reference was found in the text == Unused Reference: 'RFC5475' is defined on line 496, but no explicit reference was found in the text == Unused Reference: 'RFC5476' is defined on line 500, but no explicit reference was found in the text == Unused Reference: 'RFC5477' is defined on line 504, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS 3 INTERNET-DRAFT T. Fu 4 Intended Status: Informational C. Zhou 5 Expires: September 14, 2017 H. Zheng 6 Huawei 7 March 13, 2017 9 IP Flow Information Export (IPFIX) Information Elements Extension 10 for TCP Connection Tracking 11 draft-fu-dots-ipfix-tcp-tracking-00 13 Abstract 15 This document proposes several new TCP connection related Information 16 Elements (IEs) for the IP Flow Information Export (IPFIX) protocol. 17 The new Information Elements can be used to export certain 18 characteristics regarding a TCP connection. Through massive 19 gathering of such characteristics, it can help build an image of the 20 TCP traffics passing through a network. The image will facilitate 21 the detection of anomaly TCP traffic, especially attacks targeting at 22 TCP. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as 32 Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Copyright and License Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions used in this document . . . . . . . . . . . . . . 4 63 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Connection Sampling and new IEs . . . . . . . . . . . . . . . 4 65 3.1. Use Cases for New IEs . . . . . . . . . . . . . . . . . . 4 66 3.1.1. Response Time Calculation . . . . . . . . . . . . . . 4 67 3.1.2. Symptoms of Exceptions . . . . . . . . . . . . . . . . 5 68 4. Application of the New IEs for Attack Detection . . . . . . . 6 69 4.1. Detect Slowloris Attack . . . . . . . . . . . . . . . . . 6 70 4.2. Detect Out-of-order Packets Attack . . . . . . . . . . . . 7 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 75 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 Due to its complex stateful operations, TCP [RFC0793] is especially 82 vulnerable to attacks. The SYN Flood attack is an example, it 83 involves with massive malicious clients attempting to set up 84 connections with a server, but never completing the three-way 85 handshake process, leaving the server-side of the connections in 86 waiting states, eventually exhausting the server resources and no new 87 connection can be created. 89 Attack aiming at TCP can be low and slow in traffic pattern. 90 Sometimes it may not take down the server, but just impair the 91 provided service. Even though a victim server is still operating, its 92 performance can be significantly degraded. Without the insight of 93 what is going on with the TCP traffics, this kind of situation can be 94 very hard to detect and analyze. 96 For a network device, such as a router, to detect anomaly TCP 97 traffics, it has to understand the semantics of TCP operations, more 98 specifically, it has to be able to track TCP connection states. If a 99 router has implemented such ability, it can export characteristics 100 information regarding the TCP connections. By this way, offline 101 analysis can be performed over the gathered information, which will 102 facilitate the detection of anomaly TCP traffics, such as attacks. 104 The IP Flow Information Export (IPFIX) protocol [RFC7011], already 105 defines a generic mechanism for flow information export. This 106 document introduces several new Information Elements of IPFIX, that 107 can be used to export TCP connection characteristics. The proposed 108 Information Elements are listed in Figure 1 below. 110 +---------------------------+------+ 111 | Field Name | IANA | 112 | | IPFIX| 113 | | ID | 114 +---------------------------+------+ 115 |tcpHandshakeSyn2SynAckTime | TBD | 116 |tcpHandshakeSynAck2AckTime | TBD | 117 |tcpHandshakeSyn2AckRttTime | TBD | 118 |tcpConnectionTrackingBits | TBD | 119 |tcpPacketIntervalAverage | TBD | 120 |tcpPacketIntervalVariance | TBD | 121 |tcpOutOfOrderDeltaCount | TBD | 122 +---------------------------+------+ 124 Figure 1: Information Element Table 126 The Information Elements defined in Figure 1 are supposed to be 127 incorporated into the IANA IPFIX Information Elements registry 128 [IPFIX-IANA]. Their definitions can be found at Section 6. 130 2. Conventions used in this document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC-2119 [RFC2119] 136 2.1. Terminology 138 IPFIX-specific terminology (Information Element, Template, Template 139 Record, Options Template Record, Template Set, Collector, Exporter, 140 Data Record, etc.) used in this document is defined in Section 2 of 141 [RFC7011]. As in [RFC7011], these IPFIX-specific terms have the 142 first letter of a word capitalized. 144 This document also makes use of the same terminology and definitions 145 as Section 2 of [RFC5470]. 147 o Victim 149 The target that suffers from DDoS attack. 151 3. Connection Sampling and new IEs 153 3.1. Use Cases for New IEs 155 In this section, several use cases are discussed to identify the 156 requirements where new IEs are desirable for the network attacks 157 detection. 159 3.1.1. Response Time Calculation 161 For other DDoS attacks such as Http slowloris, there will be too many 162 connections that should be kept in the victim (server), which lead to 163 excessive resource consumption. As a result, the response time 164 between client and server will increase greatly. Challenge 165 Collapasar(CC) attack can also exhaust the resources of the server 166 and generate the similar results. Thus, the following IEs are 167 proposed as a symptom of these kinds of attacks: 169 tcpHandshakeSyn2SynAckTime: it denotes the time difference between 170 the time point that the Metering Process detects the SYN packet 171 from client to server and the time point that the observer views 172 the SYN-ACK packet from server to client. 174 tcpHandshakeSynAck2AckTime: it denotes the time difference between 175 the time point that the Metering Process detects the SYN-ACK 176 packet from server to client and the time point that the observer 177 views the ACK packet from client to server. 179 tcpHandshakeSyn2AckRttTime: it denotes The sum of 180 tcpHandshakeSyn2SynAckTime and tcpHandshakeSynAck2AckTime. It is 181 the Round Trip Time (RTT) between client and server. 183 3.1.2. Symptoms of Exceptions 185 In http slowloris attack the client may send packets to victim 186 periodically which can cause the performance lost on the server. The 187 characteristic of the attack is that there are too many connections 188 on the victim. However, the traffic volume for these connections is 189 small. In order to detect this attack, the first step is to get the 190 packets that are belonging to the same connection. The second step is 191 to find the periodicity. Thus the two indices 192 tcpPacketIntervalAverage and tcpPacketIntervalVariance are needed. 193 The index tcpPacketIntervalAverage denotes the average time 194 difference between two successive packets and the index 195 tcpPacketIntervalVariance denotes the variance of multiple time 196 difference. Large tcpPacketIntervalAverage and small 197 tcpPacketIntervalVariance can be a symptom of slow packet attack, 198 since the attacker sends packets in large intervals just as to keep 199 the connection open, and the intervals tend to differ very little in 200 time. 202 To degrade the performance of the victim, the malicious clients may 203 send too many out-of-order packets, which will consume too much 204 memory on the server. Although out-of-order packets are permit in the 205 TCP protocol, it is possible to be leveraged to cause DDoS attack. So 206 the index tcpOutOfOrderDeltaCount is helpful to detect this kind of 207 exception. For observer, it maintains one counter for each TCP 208 connection. The initial sequence number of the client is saved in the 209 counter. The counter increases by the sequence number of the packets 210 it sees from client to server. If the observer sees a packet with 211 lower sequence number than the current counter value, then the packet 212 will be considered as an out-of-order packet. 214 In IPFIX, the index tcpControlBits is used to record the 215 corresponding status bits in TCP header of the packets[IPFIX-IANA]. 216 In order to detect the application attacks which can cause the 217 protocol exception such as the wrong use of the TCP status bits 218 before and after the TCP connection establishment, another index 219 called tcpConnectionTrackingBits is needed. For example, when the 220 observer sees the SYN packet from client to server, it sets 15th bit 221 of tcpConnectionTrackingBits to 1; when it sees the SYN-ACK packet 222 from server to client, it sets 14th bit to 1, and so on. If one 223 endpoint sends the packet with wrong bits during the establishment of 224 the connection, then the observer will identify the exception by the 225 value of tcpConnectionTrackingBits. 227 4. Application of the New IEs for Attack Detection 229 This section presents a number of examples to help for the easy 230 understanding of the application of these new IEs for attack 231 detection. 233 4.1. Detect Slowloris Attack 235 The template for detecting resource exhausting application attack 236 such as http slowloris attack should contain a subnet of IEs shown in 237 Table 4. 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Set ID = 2 | Length = 48 octets | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Template ID TBD | Field Count = 10 | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 |0| sourceIPv4Address | Field Length = 4 | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 |0| destinationIPv4Address | Field Length = 4 | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 |0| protocolIdentifier | Field Length = 1 | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 |0| tcpHandshakeSyn2SynAckTime | Field Length = 2 | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 |0| tcpHandshakeSynAck2AckTime | Field Length = 2 | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 |0| tcpHandshakeSyn2SynAckTime | Field Length = 2 | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 |0| tcpPacketIntervalAverage | Field Length = 4 | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 |0| tcpPacketIntervalVariance | Field Length = 4 | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 |0| flowStartSeconds | Field Length = 4 | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 |0| flowEndSeconds | Field Length = 4 | +- 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Figure 2: Template example for detecting slowloris attack 267 An example of the actual record is shown below in a readable form as 268 below: 270 {sourceIPv4Address = 192.168.0.101, destinationIPv4Address = 271 192.168.0.201, protocolIdentifier = 6, tcpHandshakeSyn2SynAckTime = 272 200, tcpHandshakeSynAck2AckTime = 10, tcpHandshakeSyn2AckRttTime = 273 210, tcpPacketIntervalAverage = 500, tcpPacketIntervalVariance = 274 1000, flowStartSeconds = 100, flowEndSeconds = 200} 276 4.2. Detect Out-of-order Packets Attack 278 The template for detecting out-of-order packets attack should contain 279 IEs shown in Table 5. 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Set ID = 2 | Length = 32 octets | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Template ID TBD | Field Count = 10 | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 |0| sourceIPv4Address | Field Length = 4 | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 |0| destinationIPv4Address | Field Length = 4 | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 |0| protocolIdentifier | Field Length = 1 | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 |0| packetDeltaCount | Field Length = 8 | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 |0| tcpOutOfOrderDeltaCount | Field Length = 4 | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 |0| flowStartSeconds | Field Length = 4 | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 |0| flowEndSeconds | Field Length = 4 | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Figure 3: Template example for detecting out-of-order attack 303 An example of the actual record is shown below in a readable form as 304 below: 306 {sourceIPv4Address = 192.168.0.101, destinationIPv4Address = 307 192.168.0.201, protocolIdentifier = 6, packetDeltaCount =3000, 308 tcpOutOfOrderDeltaCount = 2000, flowStartSeconds = 100, 309 flowEndSeconds = 200} 311 5. Security Considerations 313 No additional security considerations are introduced in this 314 document. The same security considerations as for the IPFIX protocol 315 [RFC7011] apply. 317 6. IANA Considerations 318 The following information elements are requested from IANA IPFIX 319 registry. Upon acceptation, the 'TBD' values of the ElementIds 320 should be replaced by IANA for assigned numbers. 322 Name: tcpHandshakeSyn2SynAckTime 323 Description: 324 The time difference between a SYN and its corresponding SYN-ACK 325 when the Metering Process observes a new TCP connection is 326 going to be set up. 327 Abstract Data Type: dateTimeMicroseconds 328 ElementId: TBD 329 Status: current 330 Units: microseconds 332 Name: tcpHandshakeSynAck2AckTime 333 Description: 334 The time difference between a SYN-ACK and its corresponding ACK 335 when the Metering Process observes a new TCP connection is 336 going to be set up. 337 Abstract Data Type: dateTimeMicroseconds 338 ElementId: TBD 339 Status: current 340 Units: microseconds 342 Name: tcpHandshakeSyn2AckRttTime 343 Description: 344 The time difference between a SYN and its corresponding ACK 345 sent from the same endpoint when the Metering Process observes 346 a new TCP connection is going to be set up. 348 Conceptually tcpHandshakeSyn2AckRttTime can be thought as the 349 sum of tcpHandshakeSyn2SynAckTime and 350 tcpHandshakeSynAck2AckTime, but practically the values may 351 differ. 352 Abstract Data Type: dateTimeMicroseconds 353 ElementId: TBD 354 Status: current 355 Units: microseconds 357 Name: tcpConnectionTrackingBits 358 Description: 359 These bits are used by the Metering Process to track a TCP 360 connection. A bit is set to 1 if the corresponding condition 361 is met. A value of 0 for a bit indicates the corresponding 362 condition was net met. 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 |1|1|1|1|1|1|0|0|0|0|0|0|0|0|0|0| 366 |5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0| 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 |S|S|A|F|A|F|A|R|T|E|END|R|R|E|V| 369 |Y|/|C|I|C|/|C|S|M|N|REA|O|O|R|L| 370 |N|A|K|N|K|A|K|T|R|D|SON|P|D|R|D| 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 Bit 15 (SYN): 374 Set when there is no TCP connection between the endpoints 375 and the Metering Process detects a SYN as it is used to 376 setup a new TCP connection. The Metering Process starts to 377 track the TCP connection. 378 Bit 14 (S/A): 379 Set when bit 15 has been set and the Metering Process 380 detects a SYN-ACK in the flow, which effectively 381 acknowledges the SYN causing bit 15 to be set. 382 Bit 13 (ACK): 383 Set when bit 15 and bit 14 have been set and the Metering 384 Process detects an ACK which effectively acknowledges the 385 SYN causing bit 14 to be set. Upon setting this bit, it 386 means handshake of the TCP connection setup has completed. 387 Bit 12 (FIN): 388 Set when the Metering Process detects the first FIN for the 389 established and tracked TCP connection. It means the TCP 390 connection is going to be closed. 391 Bit 11 (ACK): 392 Set when bit 12 has been set and the Metering Process 393 detects an ACK which effectively acknowledges the FIN 394 causing bit 12 to be set. 395 Bit 10 (F/A): 396 Set when bit 12 has been set and the Metering Process 397 detects a FIN that is from the opposite of the endpoint 398 which sent the FIN causing bit 12 to be set. 399 Bit 09 (ACK): 400 Set when bit 10 has been set and the Metering Process 401 detects an ACK that is from the same endpoint which sent the 402 FIN causing bit 10 to be set. 403 Bit 08 (RST): 404 Set when the Metering Process detects any RST from either 405 party of the tracked TCP connection. 406 Bit 07 (TMR): 407 Set when a flow record report is triggered by a periodic 408 reporting timer. It means the TCP connection is still under 409 tracking. 410 Bit 06 (END): 411 Set when the Metering Process has stopped tracking the TCP 412 connection, as the connection has been closed or aborted. 413 Bit 05 & Bit 04 (END REASON): 414 00: as default value or the tracked TCP connection 415 is closed. 416 01: the tracked TCP connection is aborted. 417 10: the tracked TCP connection is inactive after a period 418 of time. 419 11: reserved. 420 Bit 03 (ROP): 421 Set when the Metering Process detects any SYN or SYNACK, 422 after the both endpoints have sent FIN or an RST has been 423 detected. 424 Bit 02 (ROD): 425 Set when the Metering Process detects at least 50 TCP 426 segments being exchanged, after both endpoints have sent FIN 427 or an RST has been detected. 428 Bit 01 (ERR): 429 Set when the Metering Process detects any of the following 430 abnormal signaling sequences for the TCP connection: 431 SYN/FIN, SYN/FIN/PSH, SYN/FIN/RST, SYN/FIN/RST/PSH. 432 Bit 00 (VLD): 433 Set when the tracked TCP connection is closed normally. 435 Abstract Data Type: unsigned16 436 Data Type Semantics: flags 437 ElementId: TBD 438 Status: current 440 Name: tcpPacketIntervalAverage 441 Description: 442 The average time interval calculated by the Metering Process 443 between two successive packets in the data flow of a TCP 444 connection. 445 Abstract Data Type: unsigned32 446 ElementId: TBD 447 Status: current 449 Name: tcpPacketIntervalVariance 450 Description: 451 The variance of the time intervals calculated by the Metering 452 Process between two successive packets in the data flow of a 453 TCP connection. 454 Abstract Data Type: unsigned64 455 ElementId: TBD 456 Status: current 457 Name: tcpOutOfOrderDeltaCount 458 Description: 459 The number of out of order packets in the data flow of a TCP 460 connection detected at the Observation Point since the previous 461 report. 462 Abstract Data Type: unsigned64 463 Data Type Semantics: deltaCounter 464 ElementId: TBD 465 Status: current 467 7. References 469 7.1. Normative References 471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", BCP 14, RFC 2119, March 1997. 474 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification 475 of the IP Flow Information Export (IPFIX) Protocol for the 476 Exchange of Flow Information", STD 77, RFC 7011, September 477 2013. 479 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 480 "Architecture for IP Flow Information Export", RFC 5470, 481 March 2009. 483 [RFC0793] J. Postel, "Transmission Control Protocol", STD 7, RFC 484 793, September 1981. 486 7.2. Informative References 488 [IPFIX-IANA] 489 IANA, "IPFIX Information Elements registry", 490 . 492 [RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., 493 Grossglauser, M., and J. Rexford, "A Framework for Packet 494 Selection and Reporting", RFC 5474, March 2009. 496 [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. 497 Raspall, "Sampling and Filtering Techniques for IP Packet 498 Selection", RFC 5475, March 2009. 500 [RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet 501 Sampling (PSAMP) Protocol Specifications", RFC 5476, March 502 2009. 504 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 505 Carle, "Information Model for Packet Sampling Exports", 506 RFC 5477, March 2009, 508 8. Acknowledgments 510 The authors would like to acknowledge the following people, for their 511 contributions on this text: DaCheng Zhang, Bo Zhang (Alex), Min Li. 513 Authors' Addresses 515 Tianfu Fu 516 Huawei 517 Q11, Huanbao Yuan, 156 Beiqing Road, Haidian District 518 Beijing 100095 519 China 521 Email: futianfu@huawei.com 523 Chong Zhou 524 Huawei 526 156 Beiqing Road, M06 Shichuang Technology Demonstration Park 527 Haidian, Beijing 100094 528 China 530 Email: mr.zhouchong@huawei.com 532 Hui Zheng (Marvin) 533 Huawei 535 101 Software Avenue, Yuhuatai District 536 Nanjing, Jiangsu 210012 537 China 539 Email: marvin.zhenghui@huawei.com