idnits 2.17.1 draft-fu-ipfix-network-security-01.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 1 instance 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 date (April 28, 2015) is 3286 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3917' is mentioned on line 103, but not defined == Missing Reference: 'RFC 5472' is mentioned on line 152, but not defined == Unused Reference: 'RFC3971' is defined on line 584, but no explicit reference was found in the text == Unused Reference: 'RFC5472' is defined on line 591, but no explicit reference was found in the text == Unused Reference: 'RFC5477' is defined on line 595, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5102 (Obsoleted by RFC 7012) ** Downref: Normative reference to an Informational RFC: RFC 5472 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPFIX Working Group T. Fu 3 Internet-Draft Huawei 4 Intended status: Standards Track D. Zhang 5 Expires: October 30, 2015 6 D. He 7 L. Xia 8 Huawei 9 April 28, 2015 11 IPFIX Information Elements for inspecting network security issues 12 draft-fu-ipfix-network-security-01 14 Abstract 16 IPFIX protocol has been used to carry Information Elements, which are 17 defined to measure the traffic information and information related to 18 the traffic observation point, traffic metering process and the 19 exporting process. Network or device status are checked through 20 analysing neccessary observed information. Although most of the 21 existing Information Elements are useful for network security 22 inspection, they are still not sufficient to determine the reasons 23 behind observed events such as for DDOS attack, ICMP attack, and 24 fragment attack. To allow administrators making effective and quick 25 response to the attacks, this document extends the standard 26 Information Elements and describes the formats for inspecting network 27 security. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on October 30, 2015. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Information Elements and use cases . . . . . . . . . . . . . 4 66 3.1. Information Elements . . . . . . . . . . . . . . . . . . 4 67 3.2. Packet upstream/downstream counters . . . . . . . . . . . 9 68 3.3. ICMP echo/echo reply counters . . . . . . . . . . . . . . 9 69 3.4. Fragment statistic . . . . . . . . . . . . . . . . . . . 9 70 3.5. Application error code . . . . . . . . . . . . . . . . . 10 71 3.6. Extended value of FlowEndReason . . . . . . . . . . . . . 10 72 4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 4.1. IPFIX . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 78 7.2. Informative References . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Terminology 83 IPFIX-specific terminology (Information Element, Template, Template 84 Record, Options Template Record, Template Set, Collector, Exporter, 85 Data Record, etc.) used in this document is defined in Section 2 of 86 [RFC7011]. As in [RFC7011], these IPFIX-specific terms have the 87 first letter of a word capitalized. 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 2. Introduction 95 As network security issues arising dramatically nowadays, network 96 administrators are eager to detect and identify attacks as early as 97 possible, generate countermeasurements with high agility. Due to the 98 enormous amount of network attack types, metrics useful for attack 99 detection are as diverse as attack patterns themselves. Moreover, 100 attacking methods are evolved rapidly, which brings challenges to 101 designing detect mechanism. 103 The IPFIX requirement [RFC3917] points out that one of the target 104 applications of IPFIX is atack and intrusion detection. The IPFIX 105 Protocol [RFC7011] defines a generic exchange mechanism for flow 106 information and events. It supports source-triggered exporting of 107 information due to the push model approach other than exporting upon 108 flow-end or fixed time intervals.The IPFIX Information Model 109 [RFC5102] defines a list of standard Information Elements (IEs) which 110 can be carried by the IPFIX protocol. Eventhough the existing 111 standard IEs are useful to check the status/events of the traffic, 112 they are not sufficient to help network administrators identify 113 categories of the attacks. The scanty information will result in an 114 inaccurate analysis and slowing down the effective response towards 115 network attacks. 117 For instance, CC (Challenge Collapsar) attack is a typical 118 application layer DDoS attack, which mainly attacks the dynamic pages 119 of web server. It makes the web server's resources exhausted and 120 paralyzed, so the server will be denial of service. Because CC 121 attacker imitates normal users' behavior pretty well by using 122 different real IP addresses with relatively completive access process 123 (even with low speed), it makes the attack concealed well compared 124 with traditional network layer DDoS (e.g. SYN-Flood, etc). In 125 addition, the attacker often manipulates the attack behind the scenes 126 by non-direct communicate with target server, so the attack is not 127 easy to be tracked and discovered. It would be useful to collect 128 application status information for application layer attacks. In 129 this case, CC attack is likely to happen if a large number of non 2XX 130 HTTP status code replied from the server are observed. 132 Fragment attack employs unexpected formats of fragmentation, which 133 will result in errors such as fragmentation buffer full, fragment 134 overlapped, fragment incomplete. Existing IPFIX fragmentation 135 metrics includes fragmentOffset, fragmentIdentification, 136 fragmentFlags, which only indicate the attributes of a single 137 fragment, and are not suitable for attack detection. Integrated 138 measurements are needed to provide an holistic review of the session. 139 Furthermore ICMP flow model has features such as the ICMP Echo/Echo 140 Reply dominate the whole traffic flow, ICMP packet interval is 141 usually not too short (normally 1 pkt/s). The current ICMP 142 information elements of IPFIX contains the ICMP type and code for 143 both IPv4 and IPv6, however they are for a single ICMP packet rather 144 than statistical property of the ICMP session. Further metrics like 145 the cumulated sum of various counters should be calculated based on 146 sampling method defined by the Packet SAMPling (PSAMP) protocol [RFC 147 5477]. Similar problems occur in TCP, UDP, SNMP and DNS attack, it 148 would be useful to derive the number of the upstream and downstream 149 packets separately and over time in order to detect the anomalies of 150 the network. 152 Upon the above discussions and per IPFIX applicability [RFC 5472], 153 derived metrics are useful to provide sufficient evidence about 154 security incident. A wisely chosen sets of derived metrics will 155 allow direct exporting with minimal resource consumption. This 156 document extends the IPFIX Information model and defines Information 157 Elements (IEs) that SHOULD be used to identify different attack 158 categories, the standardization of those IEs will improve the network 159 security and will support the offline analysis of data from different 160 operators in the future. 162 3. Information Elements and use cases 164 This section presents the information elements that are useful for 165 attack detection, the IPFIX templates could contain a subset of the 166 Information Elements(IEs) shown in Table 1 depending upon the attack 167 under concern of the network administrator. For example a session 168 creation template contains 170 {sourceIPv4Address, destinationIpv4Address, sourceTransportPort, 171 destinationTransportPort, protocolIdentifier, pktUpstreamCount, 172 pktDownstreamCount, selectorAlgorithm, samplingPacketInterval, 173 samplingPacketSpace} 175 An example of the actual event data record is shown below in a 176 readable form 178 {192.168.0.201, 192.168.0.1, 51132, 80, 7, 67, 87, 3, 100,1000} 180 3.1. Information Elements 182 The following is the table of all the IEs that a device would need to 183 export for attack statistic analysis. The formats of the IEs and the 184 IPFIX IDs are listed below. Most of the IEs are defined in [IPFIX- 185 IANA], while some of the IPFIX IE's ID are not assigned yet, and 186 hence the detailed explanation of these fields are presented in the 187 following sections. The recommended registrations to IANA is 188 described the IANA considerations section. 190 +---------------------------+--------------+-------+----------------+ 191 | Field Name | Size (bits) | IANA | Description | 192 | | | IPFIX | | 193 | | | ID | | 194 +---------------------------+--------------+-------+----------------+ 195 | sourceIPv4Address | 32 | 8 | Source IPv4 | 196 | | | | Address | 197 | destinationIPv4Address | 32 | 12 | Destination | 198 | | | | IPv4 Address | 199 | sourceTransportPort | 16 | 7 | Source Port | 200 | destinationTransportPort | 16 | 11 | Destination | 201 | | | | port | 202 | protocolIdentifier | 8 | 4 | Transport | 203 | | | | protocol | 204 | packetDeltaCount | 64 | 2 | The number of | 205 | | | | incoming | 206 | | | | packets since | 207 | | | | the previous | 208 | | | | report (if | 209 | | | | any) for this | 210 | | | | Flow at the | 211 | | | | Observation | 212 | | | | Point | 213 | pktUpstreamCount | 64 | TBD | Upstream | 214 | | | | packet counter | 215 | pktDownstreamCount | 64 | TBD | Downstream | 216 | | | | packet counter | 217 | octetUpstreamCount | 64 | TBD | Upstream octet | 218 | | | | counter | 219 | octetDownstreamCount | 64 | TBD | Downstream | 220 | | | | octet counter | 221 | tcpSynTotalCount | 64 | 218 | The total | 222 | | | | number of | 223 | | | | packets of | 224 | | | | this Flow with | 225 | | | | TCP | 226 | | | | "Synchronize | 227 | | | | sequence | 228 | | | | numbers" (SYN) | 229 | | | | flag set | 230 | tcpFinTotalCount | 64 | 219 | The total | 231 | | | | number of | 232 | | | | packets of | 233 | | | | this Flow with | 234 | | | | TCP "No more | 235 | | | | data from | 236 | | | | sender" (FIN) | 237 | | | | flag set | 238 | tcpRstTotalCount | 64 | 220 | The total | 239 | | | | number of | 240 | | | | packets of | 241 | | | | this Flow with | 242 | | | | TCP "Reset the | 243 | | | | connection" | 244 | | | | (RST) flag | 245 | | | | set. | 246 | tcpPshTotalCount | 64 | 221 | The total | 247 | | | | number of | 248 | | | | packets of | 249 | | | | this Flow with | 250 | | | | TCP "Push | 251 | | | | Function" | 252 | | | | (PSH) flag | 253 | | | | set. | 254 | tcpAckTotalCount | 64 | 222 | The total | 255 | | | | number of | 256 | | | | packets of | 257 | | | | this Flow with | 258 | | | | TCP "Acknowled | 259 | | | | gment field | 260 | | | | significant" | 261 | | | | (ACK) flag | 262 | | | | set. | 263 | tcpUrgTotalCount | 64 | 223 | The total | 264 | | | | number of | 265 | | | | packets of | 266 | | | | this Flow with | 267 | | | | TCP "Urgent | 268 | | | | Pointer field | 269 | | | | significant" | 270 | | | | (URG) flag | 271 | | | | set. | 272 | tcpControlBits | 8 | 6 | TCP control | 273 | | | | bits observed | 274 | | | | for packets of | 275 | | | | this Flow | 276 | flowEndReason | 8 | 136 | The reason for | 277 | | | | Flow | 278 | | | | termination | 279 | minimumIpTotalLength | 64 | 25 | Length of the | 280 | | | | smallest | 281 | | | | packet | 282 | | | | observed for | 283 | | | | this Flow | 284 | maximumIpTotalLength | 64 | 26 | Length of the | 285 | | | | largest packet | 286 | | | | observed for | 287 | | | | this Flow | 288 | flowStartSeconds | dateTimeSeco | 150 | The absolute | 289 | | nds | | timestamp of | 290 | | | | the first | 291 | | | | packet of this | 292 | | | | Flow | 293 | flowEndSeconds | dateTimeSeco | 151 | The absolute | 294 | | nds | | timestamp of | 295 | | | | the last | 296 | | | | packet of this | 297 | | | | Flow | 298 | flowStartMilliseconds | dateTimeMill | 152 | The absolute | 299 | | iseconds | | timestamp of | 300 | | | | the first | 301 | | | | packet of this | 302 | | | | Flow | 303 | flowEndMilliseconds | dateTimeMill | 153 | The absolute | 304 | | iseconds | | timestamp of | 305 | | | | the last | 306 | | | | packet of this | 307 | | | | Flow | 308 | flowStartMicroseconds | dateTimeMicr | 154 | The absolute | 309 | | oseconds | | timestamp of | 310 | | | | the first | 311 | | | | packet of this | 312 | | | | Flow | 313 | flowEndMicroseconds | dateTimeMicr | 155 | The absolute | 314 | | oseconds | | timestamp of | 315 | | | | the last | 316 | | | | packet of this | 317 | | | | Flow | 318 | applicationErrorCodeCount | 32 | TBD | Number of | 319 | | | | packets with | 320 | | | | application | 321 | | | | error code | 322 | | | | detected | 323 | fragmentFlags | 8 | 197 | Fragmentation | 324 | | | | properties | 325 | | | | indicated by | 326 | | | | flags in the | 327 | | | | IPv4 packet | 328 | | | | header or the | 329 | | | | IPv6 Fragment | 330 | | | | header, | 331 | | | | respectively | 332 | fragmentIncompleteCount | 32 | TBD | Counter of | 333 | | | | incomplete | 334 | | | | fragments | 335 | fragmentFirstTooShortCoun | 32 | TBD | Number of | 336 | t | | | packets with | 337 | | | | first fragment | 338 | | | | too short | 339 | fragmentOffsettErrorCount | 32 | TBD | Number of | 340 | | | | fragments with | 341 | | | | offset error | 342 | fragmentFlagErrorCount | 32 | TBD | Number of | 343 | | | | fragments with | 344 | | | | flag error | 345 | icmpTypeIPv4 | 8 | 176 | Type of the | 346 | | | | IPv4 ICMP | 347 | | | | message | 348 | icmpCodeIPv4 | 8 | 177 | Code of the | 349 | | | | IPv4 ICMP | 350 | | | | message | 351 | icmpTypeIPv6 | 8 | 178 | Type of the | 352 | | | | IPv6 ICMP | 353 | | | | message | 354 | icmpCodeIPv6 | 8 | 179 | Code of the | 355 | | | | IPv6 ICMP | 356 | | | | message | 357 | icmpEchoCount | 32 | TBD | The number fo | 358 | | | | ICMP echo. | 359 | icmpEchoReplyCount | 32 | TBD | The number of | 360 | | | | ICMP echo | 361 | | | | reply. | 362 | selectorAlgorithm | 16 | 304 | This | 363 | | | | Information | 364 | | | | Element | 365 | | | | identifies the | 366 | | | | packet | 367 | | | | selection | 368 | | | | methods (e.g., | 369 | | | | Filtering, | 370 | | | | Sampling) that | 371 | | | | are applied by | 372 | | | | the Selection | 373 | | | | Process. | 374 | samplingPacketInterval | 32 | 305 | The number of | 375 | | | | packets that | 376 | | | | are | 377 | | | | consecutively | 378 | | | | sampled | 379 | samplingPacketSpace | 32 | 306 | The number of | 380 | | | | packets | 381 | | | | between two "s | 382 | | | | amplingPacketI | 383 | | | | nterval"s. | 384 +---------------------------+--------------+-------+----------------+ 386 Table 1: Information Element table 388 3.2. Packet upstream/downstream counters 390 A sudden increase of Flow from different sources to one destination 391 may be caused by an attack on a specific host or network node using 392 spoofed addresses. However it may be cased by legitimate users who 393 seek access to a recently published web content. Only reporting the 394 total packet number is not sufficient to indicate whether attacks 395 occur, as it lacks details to separate good packets from abnormoal 396 packets. as a result, upstream and downstream packets should be 397 monitored seperately so that upstream to downstream packet number 398 ratio can be use to detect successful connections. pktUpstreamCount 399 and pktDownstreamCount are added to IPFIX to represent the cumulated 400 upstream and downstream packet number respectively. 402 3.3. ICMP echo/echo reply counters 404 An unusual ratio of ICMP echo to ICMP echo reply packets can refer to 405 ICMP attack. However the existing set of IPFIX IEs provides the type 406 and code of ICMP packet, countinuously export the information will 407 result in serious resource consumption at the exporter, the collector 408 and the bandwith. The number of echo and echo reply packets in a 409 Flow can be derived for the Observation Domain in a specific time 410 interval or once the ratio exceeds threshold. The basic metrics 411 icmpEchoCount and icmpEchoReplyCount are defined as new IPFIX 412 Information Elements. 414 3.4. Fragment statistic 416 Typical fragment attack includes fragmentation buffer full, fragment 417 overlapped, fragment incomplete. Existing IPFIX fragmentation 418 metrics includes fragmentIdentification,fragmentOffset, 419 fragmentFlags, which are not sufficient to identify errors, and are 420 not suitable for early attack detection. Integrated measurements are 421 needed to provide an holistic review of the flow. 422 fragmentIncompleteCount checks the number of incomplete fragmentation 423 ,fragmentFirstTooShortCount verifies the number of fragments with 424 first fragment too short, fragmentOffsetErrorCount checks the number 425 of fragments with offset error, and fragmentFlagErrorCount detect 426 early whether the fragmentation is caused by a malicious attack. 428 3.5. Application error code 430 The application layer attack requires IPFIX protocol capture packet 431 payload. An initial consideration of the application error code 432 comes from the HTTP status code except 2XX successful code. Other 433 application layer protocol error code are also supported. The error 434 code list can be expanded in the future as necessary. The data 435 record will have the corresponding error code value to identify the 436 error that is being logged. 438 3.6. Extended value of FlowEndReason 440 There are 5 defined reasons for Flow termination, with values ranging 441 from 0x01 to 0x05: 443 0x01: idle timeout 445 0x02: active timeout 447 0x03: end of Flow detected 449 0x04: forced end 451 0x05: lack of resources 453 There is an additional reason caused by state machine anomaly. When 454 FIN/SYN is sent, but no ACK is replied after a waiting timeout, the 455 existing five reasons do not match this case.Therefore, a new value 456 is proposed to extend the FlowEndReason, which is 0x06: protocol 457 exception timeout. 459 4. Encoding 461 4.1. IPFIX 463 This document uses IPFIX as the encoding mechanism to monitor 464 security events. However, the information that is logged SHOULD be 465 the same irrespective of what kind of encoding scheme is used. IPFIX 466 is chosen, because it is an IETF standard that meets all the needs 467 for a reliable logging mechanism and one of its targets are for 468 security applications. IPFIX provides the flexibility to the logging 469 device to define the data sets that it is logging. The IEs specified 470 for logging MUST be the same irrespective of the encoding mechanism 471 used. 473 5. IANA Considerations 475 The following information elements are requested from IANA IPFIX 476 registry. 478 Name : pktUpstreamCount 480 Description: The number of the upstream packets for this Flow at the 481 Observation Point since the Metering Process (re-)initialization for 482 this Observation Point. 484 Abstract Data Type: unsigned64 486 Data Type Semantics: TBD 488 Name: pktDownstreamCount 490 Description: The number of the downstream packets for this Flow at 491 the Observation Point since the Metering Process (re-)initialization 492 for this Observation Point. 494 Abstract Data Type: unsigned64 496 Data Type Semantics: TBD 498 Name: octetUpstreamCount 500 Description: The total number of octets in upstream packets for this 501 Flow at the Observation Point since the Metering Process 502 (re-)initialization for this Observation Point. The number of octets 503 includes IP header(s) and IP payload. 505 Abstract Data Type: unsigned64 507 Data Type Semantics: TBD 509 Name : octetDownstreamCount 511 Description: The total number of octets in downstream packets for 512 this Flow at the Observation Point since the Metering Process 513 (re-)initialization for this Observation Point. The number of octets 514 includes IP header(s) and IP payload. 516 Abstract Data Type: unsigned64 518 Data Type Semantics: TBD 520 Name: applicationErrorCodeCount 521 Description: This Information Element identifies the number of 522 packets with application layer error code detected. 524 Abstract Data Type: unsigned32 526 Data Type Semantics: TBD 528 Name: fragmentIncompleteCount 530 Description: This Information Element is the counter of incomplete 531 fragments. 533 Abstract Data Type: unsigned32 535 Data Type Semantics: TBD 537 Name: fragmentFirstTooShortCount 539 Description: This Information Element indicates the number of packets 540 with first fragment too shortt. 542 Abstract Data Type: unsigned32 544 Data Type Semantics: TBD 546 Name: fragmentOffsetErrorCount 548 Description: This Information Element specifies number of fragments 549 with offset error. 551 Abstract Data Type: unsigned32 553 Data Type Semantics: TBD 555 Name: fragmentFlagErrorCount 557 Description: This Information Element specifies number of fragments 558 with offset error.When the DF bit and MF bit of the fragment flag are 559 set in the same fragment, there is an error at the fragment flag. 561 Abstract Data Type: unsigned32 563 Data Type Semantics: TBD 565 A new values is added to FlowEndReason: 567 0x06: protocol exception timeout 568 The flow was terminated due to protocol state machine anomaly and 569 unexpected timeout. 571 6. Security Considerations 573 No additional security considerations are introduced in this 574 document. The same security considerations as for the IPFIX protocol 575 [RFC7011] apply. 577 7. References 579 7.1. Normative References 581 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 582 Requirement Levels", BCP 14, RFC 2119, March 1997. 584 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 585 Neighbor Discovery (SEND)", RFC 3971, March 2005. 587 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 588 Meyer, "Information Model for IP Flow Information Export", 589 RFC 5102, January 2008. 591 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 592 Flow Information Export (IPFIX) Applicability", RFC 5472, 593 March 2009. 595 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 596 Carle, "Information Model for Packet Sampling Exports", 597 RFC 5477, March 2009. 599 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of 600 the IP Flow Information Export (IPFIX) Protocol for the 601 Exchange of Flow Information", STD 77, RFC 7011, September 602 2013. 604 7.2. Informative References 606 [IPFIX-IANA] 607 IANA, "IPFIX Information Elements registry", 608 . 610 Authors' Addresses 611 Tianfu Fu 612 Huawei 613 Q11, Huanbao Yuan, 156 Beiqing Road, Haidian District 614 Beijing 100095 615 China 617 Email: futianfu@huawei.com 619 Dacheng Zhang 621 Email: dacheng.zhang@gmail.com 623 Danping He 624 Huawei 625 Q14, Huanbao Yuan, 156 Beiqing Road, Haidian District 626 Beijing 100095 627 China 629 Email: ana.hedanping@huawei.com 631 Liang Xia (Frank) 632 Huawei 633 No.101, Software Avenue, Yuhuatai District 634 Nanjing, Jiangsu 210012 635 China 637 Email: frank.xialiang@huawei.com