idnits 2.17.1 draft-claise-export-application-info-in-ipfix-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5102], [RFC5101]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 441 has weird spacing: '...512/tcp rem...' == Line 444 has weird spacing: '...512/udp use...' == Line 448 has weird spacing: '...513/tcp rem...' == Line 453 has weird spacing: '...513/udp mai...' == Line 457 has weird spacing: '...514/tcp cmd...' == (4 more instances...) -- The document date (October 16, 2010) is 4941 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) ** Obsolete normative reference: RFC 5102 (Obsoleted by RFC 7012) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPFIX Working Group B. Claise 3 Internet-Draft P. Aitken 4 Intended Status: Informational N.ir Ben-Dvora 5 Expires: April 16, 2011 Cisco Systems, Inc. 6 October 16, 2010 8 Export of Application Information in IPFIX 9 draft-claise-export-application-info-in-ipfix-00 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance 14 with the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet 17 Engineering Task Force (IETF), its areas, and its working 18 groups. Note that other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as "work 25 in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on April 16, 2011. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described 47 in Section 4.e of the Trust Legal Provisions and are provided 48 without warranty as described in the Simplified BSD License. 50 Abstract 52 This document specifies an extension to the IP Flow Information 53 eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX 54 information model specified in [RFC5102] to export application 55 information. 57 Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 60 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 61 "OPTIONAL" in this document are to be interpreted as described 62 in RFC 2119 [RFC2119]. 64 Table of Contents 66 1. Overview................................................. 4 67 1.1. IPFIX Documents Overview............................ 4 68 2. Introduction............................................. 4 69 2.1. Application Information Use Case....................... 6 70 3. Terminology.............................................. 7 71 3.1. New Terminology..................................... 7 72 4. applicationTag Information Element Specification......... 7 73 4.1. Existing Classification Engine IDs.................. 9 74 4.2. Options Template Record for the Application Name... 11 75 4.3. Resolving IANA L4 port collisions.................. 11 76 5. Application Tag Examples................................ 13 77 5.1. Example 1: Layer 2 Protocol........................ 13 78 5.2. Example 2: Standardized IANA Layer 3 Protocol...... 14 79 5.3. Example 3: Cisco Systems Proprietary Layer 3 Protocol15 80 5.4. Example 4: Standardized IANA Layer 4 Port.......... 17 81 5.5. Example 4: Layer 7 Application..................... 18 82 5.6. Example: port Obfuscation.......................... 19 83 5.7. Example: Application Mapping Options Template...... 20 84 6. IANA Considerations..................................... 21 85 6.1. applicationDescription............................. 21 86 6.2. applicationTag..................................... 22 87 6.3. applicationName.................................... 22 88 7. Security Considerations................................. 22 89 8. References.............................................. 22 90 8.1. Normative References............................... 22 91 8.2. Informative References............................. 23 92 9. Acknowledgement......................................... 23 93 10. Authors' Addresses..................................... 24 94 Appendix A. Additions to XML Specification of IPFIX 95 Information Elements....................................... 25 97 List of Figures 99 Figure 1: applicationTag Information Element ............... 8 100 Figure 2: Selector ID encoding ............................. 9 101 Table 1: Existing Classification Engine IDs ............... 10 102 Table 2: IANA layer 4 port collisions ..................... 12 103 Table 3: Resolving layer 4 UDP ports ...................... 12 105 1. Overview 107 1.1. IPFIX Documents Overview 109 The IPFIX Protocol [RFC5101] provides network administrators with 110 access to IP Flow information. 112 The architecture for the export of measured IP Flow information 113 out of an IPFIX Exporting Process to a Collecting Process is 114 defined in the IPFIX Architecture [RFC5470], per the requirements 115 defined in RFC 3917 [RFC3917]. 117 The IPFIX Architecture [RFC5470] specifies how IPFIX Data Records 118 and Templates are carried via a congestion-aware transport 119 protocol from IPFIX Exporting Processes to IPFIX Collecting 120 Processes. 122 IPFIX has a formal description of IPFIX Information Elements, 123 their name, type and additional semantic information, as specified 124 in the IPFIX information model [RFC5102]. 126 In order to gain a level of confidence in the IPFIX 127 implementation, probe the conformity and robustness, and allow 128 interoperability, the Guidelines for IPFIX Testing [RFC5471] 129 presents a list of tests for implementers of compliant Exporting 130 Processes and Collecting Processes. 132 The Bidirectional Flow Export [RFC5103] specifies a method for 133 exporting bidirectional flow (biflow) information using the IP 134 Flow Information Export (IPFIX) protocol, representing each Biflow 135 using a single Flow Record. 137 The "Reducing Redundancy in IP Flow Information Export (IPFIX) and 138 Packet Sampling (PSAMP) Reports" [RFC5473] specifies a bandwidth 139 saving method for exporting Flow or packet information, by 140 separating information common to several Flow Records from 141 information specific to an individual Flow Record: common Flow 142 information is exported only once. 144 2. Introduction 146 Today service providers and network administrators are looking for 147 visibility into the packet content rather than just the packet 148 header. Some network devices Metering Processes inspect the 149 packet content and identify the applications that are utilizing 150 the network traffic. Applications in this context are defined as 151 the user processes that exchange packets between them (such as the 152 web applications, peer to peer applications, file transfer, e- 153 mail applications, etc.) 155 The application identification is based on different kind of 156 methods or even a combination of such methods: 157 1. L2 protocols (such as ARP, PPP, LLDP) 158 2. IP protocols (such as ICMP, IGMP, GRE) 159 3. TCP or UDP ports (such as HTTP, Telnet, FTP) 160 4. Application headers 161 5. Packet content signatures 162 6. Traffic behavior 164 The exact application identification methods are part of the 165 Metering Process internals that aims to provide an accurate 166 identification with a minimum false identification. This task 167 requires a sophisticated Metering Process since the protocols do 168 not behave in a standard manner. 169 1. Applications use port obfuscation where the application run on 170 different port than the IANA assigned one. For example a HTTP 171 server might run a TCP port 23 (assigned to telnet in [IANA- 172 PORTS]) 173 2. IANA does not accurately reflect how certain ports are 174 "commonly" used today. Some ports are reserved, but the 175 application either never became prevalent or is not in use 176 today. 177 3. The signatures become more and more complex 179 For that reason, such Metering Processes usually detect 180 application based on multiple mechanisms in parallel. Detecting 181 applications based only on port matching might wrongly identify 182 the traffic. Note that this example stresses the need for the 183 engine strength. If the Metering Process is capable of detecting 184 applications more accurately it is considered as stronger and more 185 accurate. 187 Similarly, a reporting mechanism that uses L4 port based 188 applications only, such as L4:, would have a similar 189 issues. The reporting system should be capable of reporting the 190 applications classified using all types for mechanisms. In 191 particular applications that does not have any IANA port 192 definition. While a mechanism to export application information 193 should be defined, the L4 port being in use must be exported using 194 the destination port (destinationTransportPort at [IANA-IPFIX]) in 195 the corresponding NetFlow record. 197 Cisco Systems uses the IPFIX application tag as described in 198 section 4. to export the application information with the IPFIX 199 protocol [RFC5101]. 201 Application could be defined at different OSI layers, from the 202 layer 2 to the layer 7. Examples: Cisco Discovery Protocol is 203 layer 2 application, ICMP is layer 3 application [IANA-PROTO], 204 HTTP is layer 4 application [IANA-PORTS], and skype is layer 7. 206 While an ideal solution would be an IANA registry for applications 207 above (or inside the payload of) the well known ports [IANA- 208 PORTS], this solution is not always possible as the some 209 applications require well known specifications. Therefore, some 210 reverse engineering is required, as well as a ubiquitous language 211 for application signature. Clearly not realistic. 213 As this specification focuses on the application information 214 encoding, this document doesn't contain an application registry 215 for non IANA applications. However, a reference to the Cisco 216 assigned numbers can be found at [CISCO]. 218 2.1. Application Information Use Case 220 There are several use cases on which the application information 221 is used: 223 1. Network Visibility 225 This is one of the main use cases for using the application 226 information. This use case is also called application 227 visibility. Network administrators are using such application 228 visibility to understand the main network consumers, network 229 trends and user behavior. 231 2. Billing Services 233 In some cases, network providers are willing to bill different 234 applications differently. For example, provide different 235 billing for VoIP and Web browsing. 237 3. Congestion Control 239 While the traffic demand is increasing (mainly due to the high 240 usage of peer to peer applications, video applications and web 241 download applications), the providers revenue doesn't grow. 242 Providers are looking at a more efficient way to control and 243 prioritize the network utilization. An application aware 244 bandwidth control system is used to prioritize the traffic based 245 on the applications, giving the critical applications priority 246 over the non-critical applications. 248 4. Security Functions 250 Application knowledge is sometimes used in security functions in 251 order to provide comprehensive functions such as Application 252 based firewall, URL filtering, Parental control, Intrusion 253 detection, etc. 255 All of the above use cases require exporting of application 256 information to provide the network function itself or to log the 257 network function operation. 259 3. Terminology 261 IPFIX-specific terminology used in this document is defined in 262 Section 2 of the IPFIX protocol specification [RFC5101]. As in 263 [RFC5101], these IPFIX-specific terms have the first letter of a 264 word capitalized when used in this document. 266 3.1. New Terminology 268 Application Tag 270 A unique identifier for an application. The Application Tag 271 consists of a Classification Engine ID and a Selector ID 272 [RFC5476]. 274 4. applicationTag Information Element Specification 276 This document specifies the applicationTag Information Element, 277 which is composed of two parts: 279 1. 8 bits of Classification Engine ID. 280 2. m bits of Selector ID. The Selector ID length varies 281 depending on the engine. 283 0 1 2 3 284 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Class. Eng. ID| Selector ID ... | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | ... | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Figure 1: applicationTag Information Element 293 Classification Engine ID 295 A unique identifier for the engine which determined the 296 Selector ID. Thus the Classification Engine ID defines the 297 context for the Selector ID. 299 Selector ID 301 A unique identifier of the application for a specific 302 Classification Engine ID. 304 Note that the Selector ID term is in sync with the PSAMP 305 terminology. See [RFC5476], Packet Sampling (PSAMP) Protocol 306 Specifications. 308 When an application is detected, the most granular application 309 is encoded in the Application Tag: for example, ICMP would be 310 encoded as layer 3 value 1, SNMP as layer 4 value 161, bittorent 311 as layer 7 value 69. 313 The overall length of the applicationTag Information Element may 314 be specified either in the IPFIX Template Record or by using an 315 IPFIX Variable-Length Information Element. The receiver / 316 decoder must respect this length rather than using the 317 Classification Engine ID to make an assumption about the 318 Selector ID size. 320 When exporting applicationTag information in IPFIX, the 321 applicationTag SHOULD be encoded in a variable-length 322 Information Element [RFC5101]. However, if a legacy protocol 323 such as NetFlow version 9 is used, and this protocol doesn't 324 support variable length Information Elements, then either 325 multiple templates (one per applicationTag length), or a single 326 template corresponding to the maximum sized applicationTag MUST 327 be used. This avoids the need for multiple Template Records with 328 different applicationTag lengths when the IPFIX variable length 329 encoding [RFC5101] is not available. 331 As a consequence, although some Application Tags can be encoded 332 in a smaller number of bytes (eg, an IANA L3 protocol encoding 333 would take 2 bytes, while an IANA L4 port encoding would take 3 334 bytes), nothing prevents an Exporting Process from exporting all 335 Application Tags with a larger fixed length. 337 Note that the Selector ID value is always encoded in the least 338 significant bits as shown: 340 0 1 2 3 341 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 |Class. Eng. ID | zero-valued upper-bits ... | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | ... Selector ID | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Figure 2: Selector ID encoding 350 4.1. Existing Classification Engine IDs 352 The following Engine IDs have been allocated by Cisco Systems. 354 Name Valu Description 355 e 356 0 Invalid. 357 IANA- 1 The IANA protocol (layer 3) number is 358 L3 exported in the Selector ID. 359 See 360 http://www.iana.org/assignments/protocol- 361 numbers. 362 CANA- 2 Cisco Systems proprietary layer 3 363 L3 definition. Cisco Systems can still export 364 its own layer 3 protocol numbers, while 365 waiting for IANA to assign it. The Selector 366 ID has a global significance for all Cisco 367 Systems devices under CANA governance. 368 Hopefully the same IDs will be maintained 369 after the IANA standardization. 370 IANA- 3 IANA layer 4 well-known port number is 371 L4 exported in the Selector ID. 372 See http://www.iana.org/assignments/port- 373 numbers. 374 Note: as a flow is unidirectional, it 375 contains the destination port in a flow 376 from the client to the server. 377 CANA- 4 Cisco Systems proprietary layer 4 378 L4 definition. Cisco Systems can still export 379 its own layer 4 port numbers, while waiting 380 for IANA to assign it. The Selector ID has 381 global significance for all Cisco Systems 382 devices under CANA governance. Hopefully 383 the same ID will be maintained after the 384 IANA standardization. Example: IPFIX had 385 the port 4739 pre-assigned in the IETF 386 draft for years. While waiting for the IANA 387 registration, we could use this Selector 388 ID. 389 5 Reserved. 390 6 Reserved. 391 7 Reserved. 392 8 Reserved. 393 9 Reserved. 394 10 Reserved. 395 11 Reserved. 396 CANA 12 The Selector ID represents the Cisco 397 -L2 Systems unique global layer 2 applications. 398 The Selector ID has a global significance. 399 CANA 13 The Selector ID represents the Cisco 400 -L7 Systems unique global ID for the layer 7 401 applications. The Selector ID has global 402 significance for all Cisco Systems devices. 403 14 Reserved. 404 15 Reserved. 405 16 Reserved. 406 17 407 to Available. 408 254 409 MAX 255 255 is the maximum Engine ID. 411 Table 1: Existing Classification Engine IDs 413 Note 1: "CANA = Cisco Systems Assigned Number Authority", Cisco 414 Systems's version of IANA for internal IDs. 416 Note 2: This is an extensible list, and new Classification 417 Engine IDs may be allocated at any time. See [CISCO] for the 418 latest version. 420 4.2. Options Template Record for the Application Name 422 For engines which specify locally unique Application Tags (which 423 means unique per engine and per router), an Options Template 424 Record (see [RFC5101]) MUST be used to export the correspondence 425 between the Application Tag, the Application Name, and the 426 Application Description. This is called the "options 427 application-table". For engines which specify globally unique 428 Application Tags, an Options Template Record SHOULD be used to 429 export the correspondence between the Application Tag, the 430 Application Name and the Application Description, unless the 431 mapping is hardcoded in the NetFlow Collector, or known out of 432 band (for example, by polling a MIB). 434 4.3. Resolving IANA L4 port collisions 436 Even if the IANA L4 ports usually point to the same protocols 437 for both UDP and TCP, there are some exceptions. 10 ports in the 438 first 1K range of ports have different protocols assigned for 439 TCP and UDP: 441 exec 512/tcp remote process execution; 442 # authentication performed using 443 # passwords and UNIX login names 444 comsat/biff 512/udp used by mail system to notify users 445 # of new mail received; currently 446 # receives messages only from 447 # processes on the same machine 448 login 513/tcp remote login a la telnet; 449 # automatic authentication performed 450 # based on priviledged port numbers 451 # and distributed data bases which 452 # identify "authentication domains" 453 who 513/udp maintains data bases showing who's 454 # logged in to machines on a local 455 # net and the load average of the 456 # machine 457 shell 514/tcp cmd 458 # like exec, but automatic 459 authentication 460 # is performed as for login server 461 syslog 514/udp 462 oob-ws-https 664/tcp DMTF out-of-band secure web services 463 # management protocol 464 # Jim Davis 465 466 # June 2007 467 asf-secure-rmcp 664/udp ASF Secure Remote Management 468 # and Control Protocol 469 rfile 750/tcp 470 kerberos-iv 750/udp kerberos version iv 471 submit 773/tcp 472 notify 773/udp 473 rpasswd 774/tcp 474 acmaint_dbd 774/udp 475 entomb 775/tcp 476 acmaint_transd 775/udp 477 busboy 998/tcp 478 puparp 998/udp 479 garcon 999/tcp 480 applix 999/udp Applix ac 482 Table 2: IANA layer 4 port collisions 484 Instead of imposing the protocol (UDP/TCP) in the scope of the 485 "options application-table" Options Template for all 486 applications (on top of having the protocol as key-field in the 487 Flow Record definition), we define that the L4 application is 488 always TCP related, by convention. So, whenever the collector 489 has a conflict in looking up IANA, it would choose the TCP 490 choice. The following UDP L4 applications are assigned in the 491 Cisco L7 Application Tag range (ie, under Classification Engine 492 ID 13): 494 comsat/biff 256/udp used by mail system to notify users 495 who 257/udp maintains data bases showing who's 496 syslog 41/udp 497 asf-secure-rmcp 258/udp ASF Secure Remote Management and 498 # Control Protocol 499 kerberos-iv 259/udp kerberos version iv 500 notify 260/udp 501 acmaint_dbd 261/udp 502 acmaint_transd 262/udp 503 puparp 263/udp 504 applix 264/udp Applix ac 506 Table 3: Resolving layer 4 UDP ports 508 5. Application Tag Examples 510 The following examples are created solely for the purpose of 511 illustrating how the extensions proposed in this document are 512 encoded. 514 5.1. Example 1: Layer 2 Protocol 516 From the list of Classification Engine IDs in Table 1, we can 517 see that the layer 2 Classification Engine ID is 12: 519 L2 12 The Selector ID represents the layer 2 520 applications. The Selector ID has a global 521 significance. 523 From the list of layer 2 protocols at [cisco], we can see that 524 PPP has the value 24: 526 NAME Selector ID 527 ppp 24 529 So, in the case of layer 2 protocol PPP, the Classification 530 Engine ID is 12 while the Selector ID has the value 24. 532 Therefore the Application Tag is encoded as: 534 0 1 535 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | 12 | 24 | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 So the Application Tag has the value of 3097. Instead of 541 representing the Application Tag in hexadecimal format, the 542 format '12...24' is used for simplicity in the examples below. 544 Flexible NetFlow creates a Template Record with a few 545 Information Elements: amongst other things, the Application Tag. 546 For example: 548 - sourceIPv4Address (key field) 549 - destinationIPv4Address (key field) 550 - ipDiffServCodePoint (key field) 551 - applicationTag (key field) 552 - octetTotalCount (non key field) 554 For example, a Flow Record corresponding to the above Template 555 Record may contain: 557 { sourceIPv4Address=1.1.1.1, destinationIPv4Address=2.2.2.2, 558 ipDiffServCodePoint=0, applicationTag='12...24', 559 octetTotalCount=123456 } 561 The Collector has all the required information to determine that 562 the application is PPP, because the Application Tag uses a 563 global and well know registry, ie the IANA protocol number. 564 The 24 value is globally unique within Cisco Systems for 565 Classification Engine ID 12, so the Collector can determine 566 which application is represented by the Application Tag by 567 loading the registry out of band. 569 5.2. Example 2: Standardized IANA Layer 3 Protocol 571 From the list of Classification Engine IDs in Table 1, we can 572 see that the IANA layer 3 Classification Engine ID is 1: 574 IANA- 1 The IANA protocol (layer 3) number is 575 L3 exported in the Selector ID. 576 See 577 http://www.iana.org/assignments/protocol- 578 numbers.. 580 From the list of IANA layer 3 protocols (see [IANA-PROTO]), we 581 can see that ICMP has the value 1: 583 Decimal Keyword Protocol Reference 584 1 ICMP Internet Control Message [RFC792] 586 So in the case of the standardized IANA layer 3 protocol ICMP, 587 the Classification Engine ID is 1, and the Selector ID has the 588 value of 1. 590 Therefore the Application Tag is encoded as: 592 0 1 593 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | 1 | 1 | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 So the Application Tag has the value of 257. Instead of 599 representing the Application Tag in hexadecimal format, the 600 format '1...1' is used for simplicity in the examples below. 602 Flexible NetFlow creates a Template Record with a few 603 Information Elements: amongst other things, the Application Tag. 604 For example: 606 - sourceIPv4Address (key field) 607 - destinationIPv4Address (key field) 608 - ipDiffServCodePoint (key field) 609 - applicationTag (key field) 610 - octetTotalCount (non key field) 612 For example, a Flow Record corresponding to the above Template 613 Record may contain: 615 { sourceIPv4Address=1.1.1.1, destinationIPv4Address=2.2.2.2, 616 ipDiffServCodePoint=0, applicationTag='1...1', 617 octetTotalCount=123456 } 619 The Collector has all the required information to determine that 620 the application is ICMP, because the Application Tag uses a 621 global and well know registry, ie the IANA L3 protocol number. 623 5.3. Example 3: Cisco Systems Proprietary Layer 3 Protocol 625 Assume that Cisco Systems has specified a new layer 3 protocol 626 called "foo". 628 From the list of Classification Engine IDs in Table 1, we can 629 see that the Cisco Systems layer 3 Classification Engine ID is 630 2: 632 CANA- 2 Cisco Systems proprietary layer 3 633 L3 definition. Cisco Systems can still export 634 its own layer 3 protocol numbers, while 635 waiting for IANA to assign it. The 636 Selector ID has a global significance for 637 all Cisco Systems devices under CANA 638 governance. Hopefully the same IDs will be 639 maintained after the IANA standardization. 641 A global registry within Cisco Systems specifies that the "foo" 642 protocol has the value 90: 644 Protocol Protocol Id 645 foo 90 647 So in the case of Cisco Systems layer 3 protocol foo, the 648 Classification Engine ID is 2, and the Selector ID has the value 649 of 90. 651 Therefore the Application Tag is encoded as: 653 0 1 654 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | 2 | 90 | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 So the Application Tag has the value of 602. Instead of 660 representing the Application Tag in hexadecimal format, the 661 format '2..90' is used for simplicity in the examples below. 663 Flexible NetFlow creates a Template Record with a few 664 Information Elements: amongst other things, the Application Tag. 665 For example: 667 - sourceIPv4Address (key field) 668 - destinationIPv4Address (key field) 669 - ipDiffServCodePoint (key field) 670 - applicationTag (key field) 671 - octetTotalCount (non key field) 673 For example, a Flow Record corresponding to the above Template 674 Record may contain: 676 { sourceIPv4Address=1.1.1.1, destinationIPv4Address=2.2.2.2, 677 ipDiffServCodePoint=0, applicationTag='2...90', 678 octetTotalCount=123456 } 680 Along with this Flow Record, a new Options Template Record would 681 be exported, as shown in Section 5.7. 683 5.4. Example 4: Standardized IANA Layer 4 Port 685 From the list of Classification Engine IDs in Table 1, we can 686 see that the IANA layer 4 Classification Engine ID is 3: 688 IANA- 3 IANA layer 4 well-known port number is 689 L4 exported in the selector ID. 690 See http://www.iana.org/assignments/port- 691 numbers. 693 Note: as a flow is unidirectional, it 694 contains the destination port in a flow 695 from the client to the server. 697 From the list of IANA layer 4 ports (see [IANA-PORTS]), we can 698 see that SNMP has the value 161: 700 Keyword Decimal Description 701 snmp 161/tcp SNMP 702 snmp 161/udp SNMP 704 So in the case of the standardized IANA layer 4 SNMP port, the 705 Classification Engine ID is 3, and the Selector ID has the value 706 of 161. 708 Therefore the Application Tag is encoded as: 710 0 1 711 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | 3 | 161 | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 Flexible NetFlow creates a Template Record with a few 717 Information Elements: amongst other things, the Application Tag. 718 For example: 720 - sourceIPv4Address (key field) 721 - destinationIPv4Address (key field) 722 - protocol (key field) 723 - ipDiffServCodePoint (key field) 724 - applicationTag (key field) 725 - octetTotalCount (non key field) 726 For example, a Flow Record corresponding to the above Template 727 Record may contain: 729 { sourceIPv4Address=1.1.1.1, destinationIPv4Address=2.2.2.2, 730 protocol=17, ipDiffServCodePoint=0, 731 applicationTag='3..161', octetTotalCount=123456 } 733 The Collector has all the required information to determine that 734 the application is SNMP, because the Application Tag uses a 735 global and well know registry, ie the IANA L4 protocol number. 737 5.5. Example 4: Layer 7 Application 739 In this example, the Metering Process has observes some Citrix 740 traffic. 742 From the list of Classification Engine IDs in Table 1, we can 743 see that the L7 unique Engine ID is 13: 745 L7 13 The Selector ID represents the Cisco Systems 746 unique global ID for the layer 7 747 application. The Selector ID has a global 748 significance for all Cisco Systems devices. 750 Suppose that the Metering Process returns the ID 10000 for 751 Citrix traffic. 753 So, in the case of this Citrix application, the Classification 754 Engine ID is 13 and the Selector ID has the value of 10000. 756 Therefore the Application Tag is encoded as: 758 0 1 2 3 759 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | 13 | | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | 10000 | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 So the Application Tag has the value of '13..10000'. 768 Note that the figure shows that the Exporting Process exports 769 the value 10000 in 7 bytes: this is pure speculation. However, 770 it doesn't matter as the applicationTag would be exported in a 771 variable length Information Element. 773 Flexible NetFlow creates a Template Record with a few 774 Information Elements: amongst other things, the Application Tag. 775 For example: 777 - sourceIPv4Address (key field) 778 - destinationIPv4Address (key field) 779 - ipDiffServCodePoint (key field) 780 - applicationTag (key field) 781 - octetTotalCount (non key field) 783 For example, a Flow Record corresponding to the above Template 784 Record may contain: 786 { sourceIPv4Address=1.1.1.1, destinationIPv4Address=2.2.2.2, 787 ipDiffServCodePoint=0, applicationTag='13...10000', 788 octetTotalCount=123456 } 790 The 10000 value is globally unique within Cisco Systems, so the 791 Collector can determine which application is represented by the 792 Application Tag by loading the registry out of band. 794 Along with this Flow Record, a new Options Template Record would 795 be exported, as shown in Section 5.7. 797 5.6. Example: port Obfuscation 799 For example, a HTTP server might run a TCP port 23 (assigned to 800 telnet in [IANA-PORTS]). If the Metering Process is capable of 801 detecting HTTP in the same case, the Application Tag 802 representation must contain HTTP. However, if the reporting 803 application wants to determine whether or the default HTTP port 804 80 or 8080 was used, it must export the destination port 805 (destinationTransportPort at [IANA-IPFIX]) in the corresponding 806 NetFlow record. 808 In the case of a standardized IANA layer 4 port, the 809 Classification Engine ID is 2, and the Selector ID has the value 810 of 80 for HTTP (see [IANA-PORTS]). 812 Therefore the Application Tag is encoded as: 814 0 1 2 815 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | 3 | 80 | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 Flexible NetFlow creates a Template Record with a few 821 Information Elements: amongst other things, the Application Tag. 822 For example: 824 - sourceIPv4Address (key field) 825 - destinationIPv4Address (key field) 826 - protocol (key field) 827 - destinationTransportPort (key field) 828 - applicationTag (key field) 829 - octetTotalCount (non key field) 831 For example, a Flow Record corresponding to the above Template 832 Record may contain: 834 { sourceIPv4Address=1.1.1.1, destinationIPv4Address=2.2.2.2, 835 protocol=17, destinationTransportPort=23, 836 applicationTag='3..80', octetTotalCount=123456 } 838 The Collector has all the required information to determine that 839 the application is HTTP, but runs on port 23. 841 5.7. Example: Application Mapping Options Template 843 Along with the Flow Records shown in the above examples, a new 844 Options Template Record would be exported to express the 845 Application Name and Application Description associated with 846 each Application Tag. 848 The Options Template Record would contain the following 849 Information Elements: 851 1. Scope = applicationTag. 853 From RFC 5101: "The scope, which is only available in the 854 Options Template Set, gives the context of the reported 855 Information Elements in the Data Records." 857 2. applicationName. 859 3. applicationDescription. 861 The Options Data Record associated with the examples above would 862 contain, for example: 864 { scope=applicationTag='2...90', 865 applicationName="foo", 866 applicationDescription="The Cisco foo protocol", 868 scope=applicationTag='13...10000', 869 applicationName="Citrix", 870 applicationDescription="A Citrix application" } 872 When combined with the example Flow Records above, these Options 873 Template Records tell the NetFlow collector: 875 1. A flow of 123456 bytes exists from sourceIPv4Address 1.1.1.1 876 to destinationIPv4address 2.2.2.2 with a DSCP value of 0 and an 877 applicationTag of '12...90', which maps to the "foo" 878 application. 880 2. A flow of 123456 bytes exists from sourceIPv4Address 1.1.1.1 881 to destinationIPv4address 2.2.2.2 with a DSCP value of 0 and an 882 Application Tag of '13...10000', which maps to the "Citrix" 883 application. 885 6. IANA Considerations 887 This document specifies three new IPFIX Information Elements: the 888 applicationDescription, applicationTag and the applicationName. 890 New Information Elements to be added to the IPFIX Information 891 Element registry at [IANA-IPFIX] are listed below. 893 EDITOR'S NOTE: the XML specification in Appendix A must be updated 894 with the elementID values allocated below. 896 6.1. applicationDescription 898 Name: applicationDescription 899 Description: 900 Specifies the description of an application. 901 Abstract Data Type: string 902 Data Type Semantics: 903 ElementId: 94 904 Status: current 906 6.2. applicationTag 908 Name: applicationTag 909 Description: 910 Specifies an Application Tag. 911 (EDITOR'S NOTE: reference this document). 912 Abstract Data Type: octetArray 913 Data Type Semantics: identifer 914 ElementId: 95 915 Status: current 917 6.3. applicationName 919 Name: applicationName 920 Description: 921 Specifies the name of an application. 922 Abstract Data Type: string 923 Data Type Semantics: 924 ElementId: 96 925 Status: current 927 7. Security Considerations 929 The same security considerations as for the IPFIX Protocol 930 [RFC5101] apply. 932 8. References 934 8.1. Normative References 936 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 937 Requirement Levels, BCP 14, RFC 2119, March 1997. 939 [RFC5101] Claise, B., Ed., "Specification of the IP Flow 940 Information Export (IPFIX) Protocol for the Exchange of 941 IP Traffic Flow Information", RFC 5101, January 2008. 943 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and 944 J. Meyer, "Information Model for IP Flow Information 945 Export", RFC 5102, January 2008. 947 8.2. Informative References 949 [RFC792] J. Postel, Internet Control Message Protocol, RFC 792, 950 September 1981. 952 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 953 Requirements for IP Flow Information Export, RFC 3917, 954 October 2004. 956 [RFC5103] Trammell, B., and E. Boschi, "Bidirectional Flow 957 Export Using IP Flow Information Export (IPFIX)", RFC 958 5103, January 2008. 960 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. 961 Quittek, "Architecture for IP Flow Information Export", 962 RFC 5470, March 2009. 964 [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines 965 for IP Flow Information Export (IPFIX) Testing", RFC 966 5471, March 2009. 968 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing 969 Redundancy in IP Flow Information Export (IPFIX) and 970 Packet Sampling (PSAMP) Reports", RFC 5473, March 2009. 972 [RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) Protocol 973 Specifications", RFC 5476, March 2009. 975 [IANA-IPFIX] http://www.iana.org/assignments/ipfix/ipfix.xhtml 977 [IANA-PORTS] http://www.iana.org/assignments/port-numbers 979 [IANA-PROTO] http://www.iana.org/assignments/protocol-numbers 981 [CISCO] http://www.cisco.com 983 9. Acknowledgement 985 The authors would like to thank their many colleagues across Cisco 986 Systems who made this work possible. 988 10. Authors' Addresses 990 Benoit Claise 991 Cisco Systems Inc. 992 De Kleetlaan 6a b1 993 Diegem 1813 994 Belgium 996 Phone: +32 2 704 5622 997 EMail: bclaise@cisco.com 999 Paul Aitken 1000 Cisco Systems (Scotland) Ltd. 1001 96 Commercial Quay 1002 Commercial Street 1003 Edinburgh, EH6 6LX, United Kingdom 1005 Phone: +44 131 561 3616 1006 EMail: paitken@cisco.com 1008 Nir Ben-Dvora 1009 Cisco Systems Inc. 1010 32 HaMelacha St., 1011 P.O.Box 8735, I.Z.Sapir 1012 South Netanya, 42504 1013 Israel 1015 Phone: +972 9 892 7187 1016 EMail: nirbd@cisco.com 1017 Appendix A. Additions to XML Specification of IPFIX Information 1018 Elements 1020 This appendix contains additions to the machine-readable 1021 description of the IPFIX information model coded in XML in 1022 Appendix A and Appendix B in [RFC5102]. Note that this appendix 1023 is of informational nature, while the text in section Error! 1024 Reference source not found.(generated from this appendix) is 1025 normative. 1027 The following field definitions are appended to the IPFIX 1028 information model in Appendix A of [RFC5102]. 1030 1034 1035 1036 Specifies the description of an application. 1037 1038 1039 1041 1046 1047 1048 Specifies an Application Tag. 1049 1050 1051 1053 1057 1058 1059 Specifies the name of an application. 1060 1061 1062